GPU 自己敲响网卡门铃：NCCL 这轮换代改写了多卡通信的账，但 2.31 的新算法为什么默认关着

装了一排 400G 网卡、换了新交换机、整机预算大头从"算"挪到"网"——然后 NCCL Tests 跑出来那条总线带宽，还是不满。

过去两年，对这个现象的标准答案是"互连带宽追不上算力"，8 卡集群的增速账也早有人算过。那是带宽的账。这篇说另一件刚发生的事：过去不到一年，多卡通信的发起模型被换了一遍——从"CPU 替 GPU 打包寄件"，变成"GPU 自己驱动网卡"；而 NCCL 2.31.2 落地的节点内 NVLS、节点间 PAT 分层通信，眼下默认还关着。谁该第一时间上车、谁该观望、谁压根不用动，按配置分是三本不同的账。

老模型的三笔税：卡的往往不是带宽

很多人以为多卡通信就是"把数据从 A 卡搬到 B 卡"。但在老 NCCL 的机制里，这条路上有三个容易被忽略的固定成本。

第一笔：CPU 中转税。 传统 NCCL 是主机发起的：GPU kernel 把"要发什么"写进队列，CPU 上的代理线程读队列、再向网卡提交 RDMA 请求。这条路有微秒级的固定开销，而且要求 CPU 在通信开始前就知道每次要发多少。这对训练里的全尺寸 AllReduce 不算事——但对 MoE 推理是致命的：dispatch 发多少，路由算完才知道；decode 一步总共才几毫秒，里面要做几十次这种小通信。先同步 token 数回 CPU、再由 CPU 组织 all-to-all，一来一回几十微秒，卡就在等。知乎

第二笔：SM 占用税。 NCCL 的通信 kernel 本身要占计算资源：NCCL 把每个集合操作切成若干通道，每个通道是一个独立的 CUDA 线程块（Simple 协议 512 线程）。通道数的原则是"刚好够打满链路"——因为每一个都是从计算那里抢来的。单机 8 卡里这笔税不显眼；放到 MoE 专家并行的账上，它是实打实的"通信抢核心"。知乎

第三笔：同步粒度税。 主流做法是把计算、通信切成两个算子挂到不同 CUDA stream 上并发，但算子边界会强制执行设备级全局同步：当前波次的 Tile 必须等最慢的那块算完，通信尾部还有一长段几乎无法重叠。OSDI’26 论文 Syncopate 的判断很直接：通信已成为大规模 GPU 工作负载中的第一等瓶颈。知乎

时间线：这一年多，NCCL 每一步改了什么

把散落在一堆源码解读和版本笔记里的信息串起来，这条线其实很清楚：2.23 引入 PAT 伸缩算法，解决的是卡更多时集合通信怎么组织；2.28 引入 Device API，把设备侧发起的通信原语第一次纳入 NCCL 自己的体系。2.30 上齐了对称内存框架，通信数据面分成 CE、RMA、GIN 三种模式，GIN 让机间通信的控制面不再经过 CPU。到 8 月 11 日发布的 2.31.2，节点内 NVLS、节点间 PAT 的分层通信正式落地。知乎知乎哔哩哔哩

另一条线是 DeepEP：v1 靠 NVSHMEM+IBGDA 实现 GPU 线程直接写网卡门铃；v2 在 2026 年 4 月发布，全面迁移到 NCCL-GIN，被社区称为行业分水岭。官方口径是对比 v1 峰值吞吐最高 1.3x、同时最多省 4x 的 SM 数，分 direct 和 hybrid 两种模式。两版 README 的实测数字放在一起看更有体感：一份口径是 dispatch 带宽 90 GB/s、只占 12 个 SM。知乎知乎知乎

另一份在 EP 8×4 配置下是 6 个 SM 吃满 400Gbps InfiniBand，而 H100 一共 132 个 SM，通信只占 4.5% 的计算资源。注意这是不同版本、不同配置的数，别混成一句话讲。知乎

GIN 自己的数字：GDAKI 后端小消息（4~128 字节）往返延迟 16.7 µs，两节点带宽约 84 GB/s，多节点低延迟 kernel 比 NVSHMEM 低约 9%，DeepEP 迁移过去后 dispatch/combine 性能相当、改动很小。所以 GIN 的意义不是"比 NVSHMEM 更快"，而是把主机发起和设备发起两种模式统一进同一个运行时——以前 NCCL 和 NVSHMEM 混用是两套初始化、两套内存注册，资源互相看不见，这种内耗直接没了。知乎

顺带纠正一个常见口径错误：NVLink 的"每 GPU 900 GB/s"是双向合计，Ring 这种一方向发、一方向收的用法，每个方向只有一半——H100 每方向 450 GB/s；把 900 当单向用，是最常见的口径错误。知乎

作为参照，H100 的 NVLink 约是 PCIe 5.0 x16 双向带宽的 7 倍，Rubin 是它的近 30 倍——“能放进 NVLink 域的通信绝不出域”，是张量并行、专家并行摆放的第一原则。知乎

先泼冷水：新算法默认关着，这不是 bug

看到"分层通信落地"就准备开 NVLS 或 PAT 的，先停手。NCCL 成本模型里给这类候选挂的默认罚项是 FLT_MAX/2——这不是真实耗时，是"先别选我"。哔哩哔哩

更实际的一盆冷水：2.31.2-1 的发布说明列有 H100 性能回退，而且不代表所有尺寸与拓扑都有相同结果。哔哩哔哩

沿固定源码把这套机制逐行拆开的那位作者，自己也标了边界：实际执行的是源码与文档静态核验，没有运行 GPU/MPI 性能实验。换句话说：特定卡、特定消息尺寸段里有实打实的收益，但跨代跨拓扑，还没有人替你背书。按配置分三类人：哔哩哔哩

1. 单机多卡、通信不出 NVLink 域的（两张 4090/5090，或一台 8 卡整机）：GIN 的收益你基本吃不到，NCCL 正常升级即可，别为了尝鲜手动改算法参数；

2. 跑 MoE 推理 / 大专家并行部署的（SGLang、vLLM 的 EP 路径）：DeepEP v2 + GIN 已是事实标杆，吞吐和 SM 两项同时占便宜，值得主动跟进；

3. 多机 RoCE/IB 训练集群的：你最该做的不是开哪个新开关，而是先把整条链路审计一遍——新算法必须等"正确性+实测"两道关过了再谈启用。

网卡跑不满的正确排查姿势：先看谁在寄件，再看路有多宽

出自 AI 集群项目一线的经验帖给了同一个判断：NCCL 通信效率取决于整个通信链路，问题通常不在单个硬件。GPU→PCIe→CPU/NUMA→网卡→光模块→交换机→对端，任何一环没调好，表现出来都是"带宽不满"。知乎

多网卡并行还有 rail 设计问题：GPU 到各自 NIC 的路径不均衡，部分链路压满、部分闲着，单纯增加网卡数量并不会线性提升性能。知乎

服务器内部先看 GPU 和网卡的 NUMA 亲和、PCIe 链路有没有降速、GPUDirect RDMA 是不是真的生效——设备看起来都正常、系统不报错、性能就是差一截，是这类问题的常态形态。RoCE 环境再加四样：MTU、PFC、ECN、拥塞控制。知乎

排查路线反而朴素：不要一上来就跑几十台机器，先两台、再四台、再八台十六台逐步增加。两台之间就跑不满，优先查服务器内部、PCIe、网卡和 RDMA。知乎

两台正常、节点一多性能跳水，才轮到怀疑交换网络——拥塞、ECMP 是否均衡、PFC Pause 有没有过多、Leaf-Spine 是否超订阅。这套顺序比任何环境变量都值钱。知乎

更远处的风向：重叠的终点在 kernel 内部

GIN 是厂商过去一年的动作，研究端的刀已经捅进了单个 kernel 里面。OSDI’26 的 Syncopate 是一个编译器和运行时系统，能够在单个融合计算算子内部实现自动的细粒度计算与通信重叠。它和 Flux、Comet、TritonDistributed 是同一路线：不再在 stream 层重叠两个算子，而是从融合算子内部按"通信块"直接发起传输，编译器自动选 Copy Engine、TMA 还是 CUDA Core Load/Store，并调块大小、SM 分配和 Tile 执行顺序。此前的细粒度重叠全靠专家逐个算子手写，换个模型或换代卡就难以移植——"自动化"才是这篇论文的关键词，代码已经开源。知乎

翻译成人话：过去靠改环境变量、调通道数吃到的通信红利正在变薄，接下来吃红利要看得懂 tiling、同步和网卡队列了。这个趋势比"我今天要不要开 NVLS"重要得多。

收尾：三个观察哨

这套换代目前最值得盯的三个信号：NCCL 下一个版本会不会把 PAT/NVLS 从默认罚项改成按实测成本自动选用；DeepEP v2 的 direct 和 hybrid 两种模式在生产里差距稳不稳定；以及迁移 GIN 之后，官方会不会补一轮跨拓扑的实测数字。

至于手里那台"网卡跑不满"的集群——先按 2→4→8 台把链路审计走完，再来谈上车换代。顺序反了，新算法也救不了老拓扑。