RDMA 可靠性：从队列对、背压到 AI Fabric 的尾延迟

1. 问题定义：可靠传输不是“绝不丢包”这么简单

AI 训练和推理的数据面既有每层必须按序完成的 collective，也有可分块、可流水的 KV、checkpoint 和存储流。可靠性在这里有明确的应用语义：字节、版本和完成顺序都要正确；路径异常后，系统还要在已知时间内完成重试、隔离或失败，不能无限等待。

因此需要区分四件事：链路是否可靠、传输是否可靠、操作是否幂等、应用状态是否可恢复。一个 packet 被重传成功，不代表目标 buffer 仍属于同一个模型 epoch；一个 RDMA write 到达，不代表 decode worker 已经可以读取那段 KV。把这些层混在一起，是 AI 集群最危险的正确性漏洞之一。

2. 数据路径与控制路径：谁在搬字节，谁在授予权限

简化地看，一次 GPU 到远端 GPU 或存储节点的传输可包含 GPU memory、PCIe/CXL 设备路径、NIC DMA engine、网络、远端 NIC 和远端 memory。GPUDirect RDMA 类路径可减少 host bounce，但不消除内存映射、DMA 权限、队列提交和完成通知。

控制路径应尽量不处于 token 临界路径，但它必须先于数据路径建立正确的权限与版本。数据路径应避免每次传输都进行昂贵的全新注册或 host 同步。好的设计把长期存在的 buffer pool、队列对和 communicator 预建好，只在每次请求中交换短小的 descriptor 与 completion state。

3. 基本对象：MR、QP、WQE、CQ 与 completion 的含义

Memory region 描述已注册、可被 DMA 的一段内存；访问密钥限制对方可以读或写什么。Queue pair 提供发送/接收或一侧 RDMA 操作的队列语义。应用将 work queue element 投递给 NIC，NIC 在完成队列中报告成功、失败或异步事件。不同栈的名称与细节有差异，但这些对象共同决定了 buffer 生命周期。

高性能不是把每个操作都等待 completion。常用方式是批量投递、对关键操作 signaled、在 GPU/CPU 侧异步轮询或事件驱动地收割完成；但必须保留明确的回收界限。未完成前重用发送 buffer，或在远端还可能 DMA 时释放目标 buffer，都会制造难以复现的数据损坏。

4. 一次可恢复传输的状态机

以 P/D 分离中的 KV block 为例，传输协议应将“字节已到达”与“block 可被 decode 使用”分开。发送方和接收方都要持有同一个 request、model epoch、block range 和 generation；任何一端发现版本不匹配，都应拒绝提交而不是尝试猜测。

ALLOCATED → ADVERTISED → POSTED → IN_FLIGHT
          → REMOTE_DONE → VERIFIED → COMMITTED
          ↘ TIMEOUT / RETRYABLE_ERROR → RETRYING
          ↘ EPOCH_MISMATCH / FATAL_ERROR → ABORTED → RELEASED

decode 可见条件：
completion == COMMITTED
AND model_epoch matches
AND block checksum/version matches

该状态机不是要求每个 tensor 都算 checksum；关键是让协议能区分“未开始”“已到网络”“远端 DMA 已完成”“应用已提交”。需要精确一次效果的应用通常还要用 request id 和 generation 做去重；只要求至少一次的预取则可以在失败后丢弃并重新取数。

5. 可靠性机制：端到端、链路级和应用级各管什么

端到端可靠传输由协议序列号、确认、超时和重传保障；链路级机制可在短路径故障时更快恢复；应用级机制负责语义正确性，例如模型版本、幂等、事务提交和资源回收。三层不是互斥替代：只做链路重试无法处理远端进程重启，只做应用重试又会把短暂拥塞放大成不必要的复制流量。

可靠、无序与可靠、有序也是不同服务。某些 all-to-all buffer 可以按 chunk 到达并在最后聚合，某些控制消息则必须严格按序。把所有流量强制为最强顺序语义会造成额外等待；把需要顺序的 KV metadata 当作无序 best-effort，又会破坏可见性。因此服务类别需要显式存在于 runtime，而不应藏在某个 NIC 默认值中。

6. 拥塞、背压与重传：为什么平均带宽足够仍会超时

AI 流量的危险模式是同步 burst：多个 rank 同时进入 collective，多个 prefill 同时完成并向同一 decode pool 发送 KV，或训练 checkpoint 与在线请求共享上行。队列积压会造成 ECN 标记、显式拥塞通知、速率降低、PFC pause 或超时；重传若没有节制，又会让拥塞雪上加霜。

正确的背压应从接收端资源开始：decode worker 没有可用 KV page、NIC RX queue 逼近水位或 expert 输出尚未被消费时，发送方得到 credit 限制。应用层 admission control、RDMA queue depth 和交换网络 QoS 必须协调，否则某一层的“允许继续发送”会压垮下一层。

7. 性能模型：低 CPU 利用率不等于低延迟

RDMA 往往减少 CPU data copy 与内核协议处理，但端到端延迟仍包含 PCIe/NIC DMA、packetization、fabric hop、远端内存写入、completion 聚合和软件调度。小消息被固定开销支配；大消息被有效带宽和拥塞支配；大量中等消息则常被 queue depth、CQ polling 与 buffer 管理支配。

benchmark 必须至少区分单流与多流、同机架与跨机架、均匀与 incast、独占与混合业务。只报告最大 GB/s 会隐藏小消息 tail、credit stall 和重传造成的业务损失。

8. AI 中的四条 RDMA 路径：不要用同一策略处理

9. 部署例子：8 个 prefill worker 向 16 个 decode worker 转 KV

假设每个 prefill worker 在长 prompt 后生成多个 KV block，decode worker 只接受与当前模型 epoch 匹配的 block。router 先挑有 KV reuse 或余量的目标，再向目标申请 credit；发送方把 block descriptor、generation 和 deadline 写入控制队列，随后分块投递数据。接收端在所有 block 到达、版本匹配后一次性提交 block table。

若某个 decode worker 的 RX queue 或 HBM 水位过高，它就减少 credit，阻止发送方继续灌入数据。链路出现 transient error 时，发送方可在 deadline 内重发缺失 block；模型热更新或目标重启时，epoch mismatch 触发 abort，旧 block 被回收，router 重新选择目标。整条流程必须保证未提交的数据不会暴露给 decode，至于使用哪个库 API，是下一层实现选择。

10. 观测：把一次超时拆成可验证的阶段

• 应用事件：descriptor 创建、credit 获得、post、remote completion、commit、abort 的时间戳。
• NIC：send/receive bytes、completion delay、retry、RNR/timeout、ECN/CNP、PFC pause、队列水位。
• GPU：通信 kernel 时长、等待事件、SM 占用、DMA 相关 stall。
• 网络：端口利用率、buffer watermark、drop/mark、链路错误、路径不均衡。
• 正确性：epoch mismatch、重复提交、未释放 buffer、checksum/version reject。

建议以 request_id + transfer_id + model_epoch 做跨层关联。这样可以区分“网络没有丢包但目标没有 credit”“DMA 完成但控制面没有 commit”“GPU kernel 等待另一个 rank”等表面相似、处理完全不同的问题。

11. 不变量与失败模式：性能优化不能破坏生命周期

典型失败包括：同一队列被不同线程无序写入、CQ 没有及时 drain 导致完成积压、PFC pause 从一个流量类扩散到所有请求、NIC 健康检查正常但某条 rail 长期偏载、或在模型切换时把旧 KV 当作新版本复用。

12. 2026 公开状态：可靠性正在成为 AI Ethernet 的一等接口

UEC 的公开规范历史显示 1.0.2 是 2026 年 1 月公开版本，其中明确列出不同可靠性与排序服务模式。OCP ESUN 1.0 的公开说明将无损 Ethernet、链路级 retry、拥塞管理和小消息效率放进 scale-up 网络需求中。它们共同说明：可靠性不再只是传统数据中心网络的后台属性，而是 AI 端点、NIC、交换机和 runtime 的共同契约。

这不表示任何现有 RoCE、IB 或专有 fabric 会立即被替换。生产系统仍需按硬件、驱动、通信库、交换 ASIC、协议互操作与 SLO 做验证。标准文字说明目标和接口方向，不能直接代替实际 cluster 的 failure injection 与 benchmark。

13. 验证计划：先测正确性，再测快

1. 用固定大小 buffer 验证 registration、权限和 completion 生命周期。
2. 注入丢包、延迟、目标拒绝、rank 重启、模型 epoch 切换，验证状态机不会泄漏或误提交。
3. 做 4KB 到 GB 级的点对点和并发 sweep，记录 P50/P95/P99 与 NIC counter。
4. 加入 EP all-to-all、KV burst、checkpoint 三类混合流量，验证 QoS 与 credit。
5. 把传输 trace 接到 TTFT/TBT，检查网络指标的改善是否同时降低了服务延迟。

14. 与 Mainline 和相关文章索引的连接

15. 来源与版本边界