GPU 发起通信：把 IBGDA 拆到骨头
一句话结论
GPU 线程直接向 NIC 投递 RDMA（IBGDA）是 NVSHMEM、NCCL GIN、DeepEP 的底座。本文用 mini-gda / mini-proxy 两个最小传输把”硬件机制成本”与”库成本”分开：最小 GPU 路径 发起 0.7 µs、完成 4.0 µs，各库额外最多 4.6 µs 发起开销；调优 CPU proxy 空闲时可持平或胜过 GPU 路径；结论是 提交路径本身不能预测通信性能。
动机
- MoE EP 的细粒度、延迟敏感通信依赖 GPU-initiated RDMA，但其性能特征多只存在于源码；库之间的对比混淆了机制与实现。
方案
- 梳理 GPU 侧网络路径：队列放置、WR 构造、doorbell 顺序、完成语义。
- 实现 mini-gda（GPU 提交）与 mini-proxy（CPU proxy 提交）最小传输。
- 在 H100 / H200 / B200 / GB200 上对比 NVSHMEM IBGDA、NCCL GIN、DeepEP、UCCL-EP、MSCCL++、fabric-lib。
效果（仅论文数字）
| 发现 | 数字 |
|---|---|
| 最小 GPU 路径 发起 / 完成 | 0.7 µs / 4.0 µs |
| 库额外发起开销（队列管理、内存序、完成作用域） | 最高 4.6 µs；发起时间随 SM 频率缩放 |
| 调优 CPU proxy | 空闲时持平或胜过 GPU 路径，代价是独占一核，其运行状态决定延迟/吞吐 |
| 与 bulk 流量共享队列 | 延迟升 1–3 个数量级（两条路径皆然） |
| 达到 IB 平台 260 M msg/s 上限 | 需 doorbell 批处理 + 队列并行（有资源代价） |
| 通信代码对 occupancy | 即使未用也可能降低 GPU block 驻留 |
| all-to-all 在 ~3,000 活跃连接 | NIC 消息率损失 59% |
与 wiki 的关系
- ThunderEP — 无 RDMA/P2P 的另一极端；本文是 RDMA 有但需 GPU 直驱的一端
- Purlin — 集体 datapath 可换；本文给出 datapath 底层的量化边界
- LLM Distributed Training Collectives — EP All-to-All 消息率与连接规模
- Network Interface and System Design — NIC 队列/doorbell/完成语义的经典 NI 问题在 GPU 上重现
开放问题
- 连接数扩展的 NIC 状态瓶颈（QP 缓存）是否需要硬件侧改进（如共享 QP / 无连接传输）？
- GPU 侧通信与计算争 SM/寄存器的设计空间。
Citations
[1] arXiv PDF — Baydamirli et al., arXiv:2610.01380 [2] raw stub