fabric-lib: RDMA Point-to-Point Communication for LLM Systems #
§1 TL;DR #
fabric-lib 抽象 ConnectX-7 与 EFA 的共同语义（可靠无序传输 + WriteImm），通过 ImmCounter 原语实现无序完成通知，为 LLM 系统提供可移植的 RDMA P2P 通信库。三个生产系统验证：KvCache 传输（1.9% TTFT 开销）、RL 权重更新（1T 模型 1.3s）、MoE dispatch（CX-7 上匹配/超越 DeepEP decode 延迟）。
§2 Q1 / Q2 / Q3 #
Q1 — 痛点 #
LLM 新兴工作负载（disaggregated inference、MoE routing、异步 RL fine-tuning）需要灵活的点对点通信，但现有方案被绑定到特定 NIC：
| 方案 | 限制 |
|---|
| DeepEP | 依赖 IBGDA（仅 ConnectX） |
| NVSHMEM | EFA 上性能严重退化 |
| Mooncake / NIXL | 缺少 EFA 支持或仅初步 |
| NCCL / torch.distributed | 固定成员、同步初始化、顺序约束、均匀缓冲区 |
核心矛盾：云供应商部署异构 RDMA 硬件（ConnectX RC 有序 vs EFA SRD 无序），无统一抽象可用。
Q2 — 方法 #
核心洞察：ConnectX RC 与 EFA SRD 共享一个交集语义——可靠但无序传输 + WriteImm 操作。fabric-lib 在此最小公共语义之上构建统一接口。
关键设计：
- TransferEngine — 每 GPU 一个 DomainGroup worker，管理 1–4 个 NIC Domain；锁无队列跨线程通信；NUMA 感知内存分配。
- ImmCounter — 基于 WriteImm 32-bit 立即值的无序完成通知。不依赖消息顺序，正确性建立在 PCIe 写序保证之上（NIC→GPU 数据先于 NIC→CPU 立即值被 PCIe switch 序列化）。
- 三个应用层：
- KvCache Transfer：layer-by-layer paged write + UVM watcher（CUDA Graph 兼容）
- RL Weight Transfer：全集群带宽一侧 RDMA Write + 4 阶段流水线
- MoE Dispatch/Combine：host proxy + 两轮投机发送 + NVLink intra-node
核心技术壁垒：ImmCounter 的正确性论证——在无序传输下，利用 PCIe ordering guarantee 跨 CPU/GPU 边界建立 data-before-notification 语义。这需要理解 RDMA spec（WriteImm payload 先于 immediate 发出）、PCIe switch ordering（同设备写有序）、以及 host-proxy 架构（CPU 观察到 ImmCount 后发起的 CPU→GPU 事务被 PCIe switch 排在 NIC→GPU 数据写之后）。这一论证不出现在标准 RDMA 编程指南中。
Q3 — 结果 #
| 指标 | 数值 |
|---|
| 峰值吞吐 | 400 Gbps（CX-7 & EFA 均达到） |
| KvCache 128K TTFT 开销 | +1.9%（monolithic→disaggregated） |
| RL 权重更新（1T, 256→128 GPU） | 1.3 s（>100× faster than existing RL frameworks） |
| MoE decode tok/s CX-7 EP64 batch=2 | 78.4（vs DeepEP 73.8） |
| MoE decode tok/s EFA EP64 batch=2 | 66.8（vs pplx-kernels 21.0, 3.2×） |
| RDMA 在 RL 总时间中占比 | 2.1%（瓶颈是 FSDP unsharding 42%） |
§3 架构 / 方法图 #
flowchart TB
subgraph Node["Node (multi-GPU)"]
subgraph GPU0["GPU 0"]
UVM0["UVM Watcher"]
end
subgraph GPU1["GPU 1"]
UVM1["UVM Watcher"]
end
TE["TransferEngine Instance"]
subgraph DG0["DomainGroup 0 (GPU0)"]
D0a["Domain 0\n(NIC 0)"]
D0b["Domain 1\n(NIC 1)"]
D0c["Domain 2\n(NIC 2)"]
D0d["Domain 3\n(NIC 3)"]
end
subgraph DG1["DomainGroup 1 (GPU1)"]
D1a["Domain 0"]
D1b["Domain 1"]
D1c["Domain 2"]
D1d["Domain 3"]
end
IC["ImmCounter\n(per-NUMA)"]
CB["Callback Thread"]
end
GPU0 --> TE
GPU1 --> TE
TE --> DG0
TE --> DG1
DG0 --> IC
DG1 --> IC
IC --> CB
D0a & D0b & D0c & D0d -->|"RDMA\nWriteImm"| Remote["Remote Peers"]
TransferEngine 内部数据流：应用通过 API 提交请求 → TransferEngine 路由至服务对应 GPU 的 DomainGroup → DomainGroup worker（NUMA-pinned 线程）将请求分片到多个 Domain（每个管理一个 NIC）→ Domain 提交 WR 到 NIC 发送队列 → 完成事件从 CQ 中 poll 回 → ImmCounter 累加 → 回调线程通知应用。
sequenceDiagram
participant App as Application
participant TE as TransferEngine
participant DG as DomainGroup Worker
participant NIC as NIC (Domain)
participant Remote as Remote GPU
App->>TE: submit_paged_writes(src, dst, imm)
TE->>DG: enqueue (lock-free)
DG->>NIC: post_send(WriteImm, shard_0)
DG->>NIC: post_send(WriteImm, shard_1)
NIC->>Remote: RDMA Write payload
NIC->>Remote: Immediate value delivery
Remote-->>DG: CQ completion (imm value)
DG->>DG: ImmCounter++
DG-->>App: callback / flag
§4 作者证明 #
符号表 #
| 符号 | 含义 |
|---|
| RC | Reliable Connection（RDMA传输类型，有序可靠） |
| SRD | Scalable Reliable Datagram（EFA 专有协议，无序可靠） |
| WriteImm | RDMA Write with Immediate（写 + 32-bit 立即值通知） |
| ImmCounter | 每 immediate 值计数器，累计 CQ 事件 |
| DomainGroup | 每 GPU 的 NIC 管理单元 |
| Domain | 单 NIC 抽象 |
| MrDesc | 可序列化的内存注册描述符 |
| QP | Queue Pair（RDMA 通信端点） |
| CQ | Completion Queue |
| WR | Work Request |
方程物理意义 #
本文为系统论文，无编号公式。关键定量关系：
- MoE dispatch buffer上界：$N \cdot T \cdot \max(R, E/N)$，其中 $N$ 为节点数，$T$ 为每专家 token 数，$R$ 为路由专家数，$E$ 为总专家数
- 带宽聚合：EFA 通过 4×100 Gbps NIC 聚合至 400 Gbps；ConnectX-7 单 NIC 400 Gbps
6 项最低检查 #
- ImmCounter 正确性：声称无序传输下 ImmCounter 安全 → 依赖 (a) RDMA spec: WriteImm data 先于 immediate 发出, (b) PCIe switch: 同目标设备写有序, (c) host-proxy: CPU→GPU 事务排在 NIC→GPU 之后。✓ 三层论据完整。
- 400 Gbps 峰值吞吐：Figure 7/8 显示 single write ≥16 MiB 饱和、paged write ≥32-64 KiB 饱和。物理上限 = 线速 400 Gbps。✓ 与硬件线速一致。
- 1.3s RL 权重传输：Table 5 分解 = 184(H2D) + 518(full_tensor) + 18(fuse) + 88(quant) + 26(RDMA) + 357(barrier) + 42(其他) = 1233ms。✓ 各项加和一致。
- MoE host proxy 与 DeepEP 性能对比：Table 6 CX-7 batch=2: 78.4 vs 73.8 tok/s。声称 host proxy 不劣于 GPU-initiated RDMA。✓ 数据支持。但 prefill 模式下 DeepEP 胜出（Figure 10），论文承认此限制。
- EFA 多 NIC 聚合必要性：p5 实例 4×100 Gbps → 400 Gbps。声称单 NIC 不够 → ✓ 硬件规格确认。p5en 为 2×200 Gbps。
- Two-round dispatch 延迟隐藏：Figure 11 ablation 显示 private buffer = 24-32 tokens 最优。✓ 投机发送量过小不足以隐藏 10-30 µs routing 交换，过大浪费带宽。
集群专项检查 #
- 带宽预算：KvCache 传输 layer-by-layer 与 prefill 重叠 → 网络传输完全被计算隐藏（128K TTFT +1.9%）。RL 权重传输中 RDMA 仅占 2.1% → 带宽足够大，瓶颈在计算侧。✓ 一致。
- Tail 延迟模型：本文未显式建模 p99。Table 3 UVM Watcher latency = 6.3 ± 1.3 µs，标准差小，暗示低尾延迟。MoE 延迟 breakdown (Table 8/9) 提供 p50 数据，未提供 p99。⚠️ 不完整。
- Loss / retransmit accounting：依赖 RC 和 SRD 的内建可靠性（重传由传输层处理）。论文未讨论重传开销对尾延迟的影响。⚠️ 未覆盖。
- Scaling formula：MoE dispatch 为 all-to-all 模式，$O(N)$ 总消息数（每节点向 $N-1$ 个对端发送）。CPU proxy overhead 线性增长（Table 9: post time ~28 µs at EP64）。✓ 与 EP size 线性关系一致。
§5 实验与数据 #
| 平台 | Single Write 饱和点 | Paged Write 饱和点 | 峰值 |
|---|
| ConnectX-7 | ≥16 MiB | ≥32 KiB | ~400 Gbps |
| EFA | ≥16 MiB | ≥64 KiB | ~400 Gbps |
fabric-lib 在两平台略优于 NIXL。EFA paged write 需要更大页以饱和（64K vs 32K），反映 SRD 协议的 per-message overhead 更高。
关键结果 2: RL 权重传输分解 (Table 5) #
| 阶段 | 耗时 | 占比 |
|---|
| full_tensor() (FSDP unsharding) | 518 ms | 42.0% |
| 跨 rank 同步等待 | 357 ms | 28.9% |
| H2D memcpy | 184 ms | 14.9% |
| 量化 | 88 ms | 7.1% |
| Remaining | 42 ms | 3.4% |
| RDMA submit | 26 ms | 2.1% |
| Fuse projections | 18 ms | 1.5% |
关键洞察：4 阶段流水线成功将 RDMA 传输完全隐藏在 FSDP unsharding 计算之下。实际瓶颈是 PyTorch FSDP 的 full_tensor() 及集群同步。
关键结果 3: MoE Decode 端到端 (Table 6) #
| 平台 | 方案 | batch=2 | batch=8 | batch=32 |
|---|
| H200 EFA | fabric-lib | 66.8 | 56.5 | 32.0 |
| H200 EFA | pplx-kernels | 21.0 | 11.6 | 4.9 |
| H100 CX-7 | fabric-lib | 78.4 | 67.7 | 36.1 |
| H100 CX-7 | DeepEP | 73.8 | 65.8 | 36.3 |
EFA 上 fabric-lib 3–6× 优于 pplx-kernels（NVSHMEM 基础）；CX-7 上 host proxy 匹配或超越 GPU-initiated DeepEP。这证明 host proxy 开销可被两轮投机策略完全抵消。
关键结果 4: Dual-batch Overlap (Table 7, EFA) #
| batch | No overlap | Dual-batch | 增益 |
|---|
| 128 | 11.8 | 13.9 | +18% |
| 96 | 14.3 | 16.5 | +15% |
| 64 | 21.3 | 21.4 | ~0% |
| 32 | 32.0 | 30.2 | -6% |
大 batch 受益于 overlap；小 batch 已经 communication-bound，overlap 开销反而有害。pplx-kernels 在所有 batch 下 overlap 无效或负效果。
关键结果 5: KvCache Transfer (Table 4) #
Qwen3-235B，128K 序列，disaggregated 模式 TTFT = 17056ms vs monolithic 16735ms，增量仅 +321ms (+1.9%)。layer-by-layer transfer 通过 UVM watcher + CUDA Graph 兼容性实现了与 chunked prefill 的完全重叠。
§6 论证链 #
| 步骤 | 论点 | 支撑证据 | 依赖 |
|---|
| 1 | LLM 新兴负载需要 P2P 通信而非仅 collective | disaggregated inference、MoE routing、async RL 均需动态成员、异步、非均匀 buffer | §1 四条 collective 限制 |
| 2 | 现有 P2P 方案被锁定到特定 NIC | DeepEP→IBGDA, NVSHMEM→EFA退化, Mooncake/NIXL→无EFA | §1-§2 逐方案分析 |
| 3 | ConnectX RC 与 EFA SRD 共享"可靠无序"语义 | Table 1 特性矩阵交集 | §2.1 RDMA transport分析 |
| 4 | ImmCounter 在无序传输上构建安全的完成通知 | PCIe ordering: data先于imm到达目标设备; host-proxy后续事务排在数据之后 | §3.3 PCIe ordering论证 |
| 5 | TransferEngine 实现跨硬件 400 Gbps 线速 | Figure 7/8: CX-7 和 EFA 均达到线速 | §7.2 microbenchmark |
| 6 | 三个生产系统验证 P2P 比集合通信更优 | KvCache: +1.9% TTFT; RL: 1.3s (100×); MoE: 匹配DeepEP + 首次EFA可用 | §7.3-§7.5 |
| 7 | Host proxy 可匹配甚至超越 GPU-initiated RDMA | Table 6: CX-7 decode fabric-lib ≥ DeepEP | §7.5.1 + two-round策略 |
§7 实现 cross-reference #
开源地址：https://github.com/perplexityai/pplx-garden/
- TransferEngine 核心: Rust 实现，per-DomainGroup worker 线程 NUMA-pinned，lock-free queue 通信
- EFA Domain: libfabric API, 每 NIC 一个 fabric domain, WR templating
- ConnectX-7 Domain: libibverbs, 2 RC QPs per peer (Send/Recv 与 WriteImm 分离), WR chaining (up to 4 WRs linked),
IBV_ACCESS_RELAXED_ORDERING
- UVM Watcher: GDRCopy polling 线程, CUDA Graph 兼容
- MoE kernels: host proxy thread + NVLink intra-node + two-round dispatch
关键实现细节 #
- Two RC QPs per peer on CX-7：Send/Recv 与 WriteImm 必须分开 QP，因为 Recv 和 WriteImm completions 均按 posting order 消耗 work requests，混用会互相干扰。这是一个非显而易见的工程约束。
- Two-round speculative dispatch：第一轮投机发送少量 token 到 private buffer（无需路由信息），与路由信息交换并行；第二轮在路由信息到达后精确 scatter 到 shared buffer。Private buffer 最优 24-32 tokens（Figure 11 ablation），恰好隐藏 10-30 µs 路由交换延迟。
§8 System Scope (cluster-specific) #
- Scale: 多节点 pod 级（评测最大 EP=DP=64，即 64 节点 × 8 GPU = 512 GPU；RL 场景 256 training + 128 inference = 384 GPU）
- Workload: 推理为主（disaggregated inference P2P，MoE all-to-all），兼顾训练→推理异步 RL 权重同步
- Generation: InfiniBand ConnectX-7 400 Gbps / AWS EFA SRD 4×100 Gbps (p5) 或 2×200 Gbps (p5en)；GPU 为 H100/H200；NVLink 用于 intra-node
§9 Topology & Physical Architecture #
flowchart TB
subgraph CX7_Node["H100 Node (ConnectX-7)"]
direction LR
G0["GPU 0"] --- NIC0["CX-7\n400G"]
G1["GPU 1"] --- NIC0
G2["GPU 2"] --- NIC0
G3["GPU 3"] --- NIC0
G4["GPU 4"] --- NIC0
G5["GPU 5"] --- NIC0
G6["GPU 6"] --- NIC0
G7["GPU 7"] --- NIC0
G0 ---|NVLink| G1 & G2 & G3 & G4 & G5 & G6 & G7
end
subgraph EFA_Node["H200 Node (AWS p5, EFA)"]
direction LR
E0["GPU 0"] --- ENIC0["EFA\n100G"] & ENIC1["EFA\n100G"]
E1["GPU 1"] --- ENIC0 & ENIC1
E2["GPU 2"] --- ENIC2["EFA\n100G"] & ENIC3["EFA\n100G"]
E3["GPU 3"] --- ENIC2 & ENIC3
E4["GPU 4"] --- ENIC0 & ENIC1
E5["GPU 5"] --- ENIC0 & ENIC1
E6["GPU 6"] --- ENIC2 & ENIC3
E7["GPU 7"] --- ENIC2 & ENIC3
end
| 属性 | H100 CX-7 集群 | H200 EFA 集群 (p5) |
|---|
| GPU/node | 8 | 8 |
| NIC/node | 8 (1 per GPU) | 32 (4 per GPU) |
| 单 NIC 带宽 | 400 Gbps | 100 Gbps |
| 聚合带宽/GPU | 400 Gbps | 400 Gbps (4 NIC) |
| 传输协议 | RC (有序可靠) | SRD (无序可靠) |
| GPUDirect RDMA | ✓ | ✓ |
| GPU-initiated (IBGDA) | ✓ | ✗ |
| Intra-node | NVLink | NVLink |
关键拓扑约束：fabric-lib 要求所有 peer 每 GPU NIC 数相同（用于分片/负载均衡）。EFA 多 NIC 聚合对于达到线速是必要的。
§10 Collective Communication #
- 使用的集合操作: 无。fabric-lib 明确定位为 P2P 补充而非替代 collectives。RL 场景中最后的 global barrier 使用 GLOO over Ethernet。
- P2P 操作: Send/Recv (RPC 式)、WriteImm (单写/分页写/scatter/barrier)
- 算法: 无 ring/tree 拓扑 — 纯点对点 direct RDMA Write
- 层级: intra-node 用 NVLink (MoE)；inter-node 用 RDMA WriteImm
- GPU-direct 路径: ConnectX-7 使用 GPUDirect RDMA (host-initiated，非 IBGDA)；EFA 使用 GPUDirect RDMA
- 库: 自研 fabric-lib (Rust)；底层 libibverbs (CX-7) / libfabric (EFA)
§11 Congestion & Traffic Engineering #
论文未显式讨论拥塞控制，这是一个值得注意的缺失：
- MoE dispatch 在 EP=64 时产生大量并发 all-to-all 式流量
- 依赖底层传输协议内建机制：ConnectX RC 的 link-level flow control；EFA SRD 的内建拥塞管理
- 无 ECN/DCQCN/HPCC 参数讨论
- 负载均衡：fabric-lib 的 multi-NIC 分片自然分散流量（round-robin across Domains），但无 flowlet/packet-spray 讨论
- 无死锁避免讨论（RC 点对点不需要 PFC 优先级管理）
§12 Fault Tolerance & Reliability #
- 传输可靠性: RC 和 SRD 均提供可靠传输（丢包由传输层重传）
- KvCache 错误处理: 心跳检测通信故障；decoder 超时取消；per-request cancellation token 停止后续传输并等待 pending 操作完成后发送确认
- RL 权重传输: 全局 barrier 通过 GLOO (TCP/Ethernet) 实现同步，隐含对断联的容忍（GLOO 会超时）
- 无量化: 论文未量化 time-to-detect / time-to-recover
§13 Cost & Efficiency #
论文未提供成本数据。隐含信息：
- EFA p5 实例使用 4 个 100G NIC/GPU 达到与单 CX-7 400G 同等带宽 → 光学/NIC 成本不同但被 AWS 抽象
- fabric-lib 的价值命题之一是避免 vendor lock-in → 允许在成本更优的平台间迁移
§14 Deployment Context (实践上下文) #
- Deployer profile: Perplexity AI（specialized AI cloud / inference provider）。生产部署在 AWS (EFA) 和自有/租赁 CX-7 集群。
- Workload mix: 推理为主（disaggregated serving, MoE decode），RL fine-tuning 为辅（异步权重同步）。
- Greenfield vs retrofit: 库层抽象，可叠加在现有集群上（不需改拓扑/交换机）。仅需已有 RDMA 能力（CX-7 或 EFA）。
- Failure model: 论文未量化，但 KvCache 的心跳+取消机制暗示面向中等规模（数百 GPU）的偶发故障。
- Vendor dependency: 明确去绑定。支持 NVIDIA ConnectX-7 和 AWS EFA。论文讨论 eRDMA / Broadcom / AMD 未来扩展。
§15 Scalability / Future-proofing #
- EP scale 限制: CPU proxy overhead 随 EP 线性增长 (Table 9: ~28 µs at EP64)。EP=128+ 时 proxy 开销可能成为新瓶颈。
- GB200 NVL72: 72 GPU NVLink domain 使 MoE intra-rack 无需 RDMA，但 inter-rack P2P 仍需。
- GPU-initiated RDMA on EFA: p5en 实例可能支持 → fabric-lib 可从 host proxy 切换至 GPU-initiated，进一步降低延迟。
- 800G+ NIC: 下一代 NIC 可能单端口即可覆盖目前多 NIC 聚合场景，简化 Domain 分片逻辑。
- 更多 RC 兼容 NIC: eRDMA、Broadcom、AMD — RC 兼容即可适配。
§16 Software → Hardware Reverse Implication #
fabric-lib 的设计隐含以下对 NIC/fabric 硬件的期望：
| 软件需求 | 硬件期望 |
|---|
| ImmCounter 正确性 | NIC 必须保证 WriteImm data 先于 immediate 到达 PCIe |
| 多 NIC 聚合透明化 | 期望 NIC 支持 multi-path load-balance 或至少不干扰软件层 round-robin |
| Host proxy 低延迟 | 期望 NIC doorbell 和 CQ poll 延迟极低（sub-µs） |
| GPUDirect RDMA | 必须支持 NIC 直接访问 GPU memory via PCIe BAR |
IBV_ACCESS_RELAXED_ORDERING | CX-7 需支持 PCIe 乱序写以提升吞吐 |
| 无序可靠传输 | 新 NIC 应暴露 reliable-unordered mode（不强制排序开销） |
| 最终消除 host proxy | 期望 EFA 类 NIC 支持 GPU-initiated RDMA (IBGDA) |
| Per-flow 不阻塞 | WriteImm 到不同 peer 应互不阻塞（connectionless / parallel QP） |
显著缺失：论文未要求 in-network reduction (SHARP)、P4 可编程交换、或硬件加速 collective — 这与其"P2P 补充 collective"定位一致。
Pre-Save Self-Check #
- [x] §1-§7 (base) all present and non-empty
- [x] §8-§16 (cluster-specific) all present
- [x] 无
[内容未抓取]
- [x] §4 has 6+ checks (6 base + 4 cluster-specific)
- [x] §6 论证链 ≥3-step numbered table (7 steps)
- [x] §7 has code citation (open-source URL + implementation details)
- [x] No figure_files provided → Mermaid diagrams used for architecture
- [x] KaTeX: buffer formula uses
$...$ inline math
- [x] Swap-entity-name test: all paragraphs reference fabric-lib-specific content
- [x] No skill-doc citations, rule-tag acronyms, or self-referential format descriptions