Every Microsecond Matters: Achieving Near Speed-of-Light Latency in GPU Collectives
Siyuan Shen, Anton Korzh, John Bachan, Tiancheng Chen, Arnav Goel, Ludwig Schneider, Pouya Kousha, Zhenhao He, Sylvain Jeaugey, Kamil Iskra, Nishank Chandawala, Jeff R. Hammond, Torsten Hoefler
cs.DC
2026-07-18
NVIDIA 重写 NCCL 的低延迟集合通信,把小消息 AllReduce 从 11 微秒压到 2.4 微秒,逼近硬件光速下界;接入 vLLM 后张量并行推理每 token 快 7-13%。
GPU 之间的集合通信(AllReduce、AllGather 这类把多卡数据聚起来再分发的操作)过去十年都是按“带宽”优化的:训练时梯度同步动辄几百 MB,把管道塞满就行,谁也不在意几个微秒的固定开销。
长上下文、小 batch 的推理把这张牌桌掀了。大模型一张装不下,得靠张量并行(TP)把每一层切到多张卡上,而每次生成一个 token,都要在卡之间做一轮小 AllReduce 把分片输出合起来。这些消息常常只有几 KB,带宽根本用不满,真正卡住的是固定延迟。在 decode 的关键路径上,每多一微秒都直接变成用户多等的等待。
作者测下来,即便是当前最快的实现,也远高于硬件本身的“光速下界”(speed-of-light, SoL),也就是线缆、L2 缓存往返和内存写入给定的物理下限。他们把多出来的开销定位到一个具体的东西:全局内存屏障(global memory barrier)。每做一步同步,旧实现都要插一道屏障,逼所有 GPU 排队等到最慢的那个,这一等就是几微秒。
四个技术,目标都是干掉全局内存屏障。
LL(Low-Latency):把就绪信号塞进数据里。 旧做法是先写数据、再单独发一个表示数据就绪的信号,两次写之间要屏障对齐。LL 把一个 8 字节的标志位和 8 字节数据打包成一次 16 字节的原子写,接收方读到标志位就知道数据到了,省掉单独的信号步骤。代价是有效带宽减半、暂存区翻倍,所以只适合很小的消息。
Sentinel(哨兵值):用数据本身的值当信号。 接收缓冲区预先填一个不太可能出现的哨兵值(比如 -NaN),数据写进来值就变了,接收方轮询到值变化就知道到了。带宽不损失、暂存也省,但每次用完要把缓冲区重置,而且数据里不能恰好出现这个哨兵值。消息稍大、参与卡数稍多时,它比 LL 划算。
双向通信 + 双缓冲:消灭迭代之间的屏障。 当消息要分块多次传输,LL 和 sentinel 解决了单次同步,但迭代之间还有屏障。双向通信让“从对端收到一块”自动成为“可以发下一块”的许可(类似信用量流控),配合双缓冲交替读写,迭代之间不再需要屏障。
Two-shot LL128 原子 AllReduce:本文的核心新算法。 把 AllReduce 拆成 ReduceScatter + AllGather 两步。归约阶段,线程按每 8 个一组操作 128 字节的缓存行,组里第一个线程先把自己的元素置 1 当标志,然后 8 个线程一起对暂存区做原子加;当标志位累加到等于 GPU 数 N,说明所有卡的贡献都到了。它只需要大约 D/N 的暂存空间(D 是每轮要归约的数据量),FP16 下只浪费约 1.5% 带宽(FP32 约 3%)。前提也硬:要 NVLink 保证缓存行级原子加,只支持加法(因为靠交换律的原子累加),只支持 FP32/FP16/BF16,而且因为浮点原子累加的顺序不确定,结果是非确定的。
这些原语被封装成一个低层 API ncclLLBuffer,供写自定义 kernel 的人直接调用。
作者先算了光速下界到底是多少:一次 AllReduce 的理论下限 = 2×(L2 往返延迟) + 一次远端写。在两块 GB200 上实测,L2 往返 0.306 微秒,远端写 0.792 微秒,下界 = 1.404 微秒。
| 设置 | 基线 | 新 kernel | 距光速下界 |
| 小消息 AllReduce(4 GPU) | NCCL ring 11.0 微秒 | 2.37 微秒 | 约 7% |
| 2 GPU,128 字节 one-shot | n/a | LLBuffer | 约 7% |
| 64 GPU,组播变体 | n/a | n/a | 约 70% |
小规模下已经几乎贴着物理下限;放大到 64 卡、上组播,还剩约 70% 的余地。
落到真实负载(vLLM,GB200):
| 指标 | 4 GPU(TP=4) | 8 GPU(TP=8) |
| ITL(每 token 延迟)降幅 | 7-13% | 9-11% |
| 吞吐增幅 | 相当 | 相当 |
覆盖稠密(Llama-3.1-70B)、MoE(DeepSeek-V3)、混合注意力(Qwen3-Next)三种架构。摘录用 Llama-3.1-70B 在 4 卡上的例子:ITL 降 8.7%,折算到成本(按 CoreWeave 每份 4 GB200 报价 42 美元/小时)省约 0.9%。大模型在 8 卡上绝对成本更高:DeepSeek-V3 每百万输出 token 约 11.78 美元,优化后降到约 10.88 美元,绝对值省得更多。
传统 HPC 也没落下。在 Alps 超算(Grace Hopper 节点)上跑 cuSOLVERMp 的分布式特征值求解,矩阵 m=32768 时提升更明显,因为通信占运行时间的比例更大。
这张卡的关键在“关键路径”。训练时集合通信藏在计算后面,可以靠计算与通信重叠藏起来;decode 时每生成一个 token 就要同步一次,躲不掉,延迟直接变成用户看到的打字速度和服务成本。把这一步从 11 微秒压到 2.4 微秒,对单次 token 是微秒级,对长输出和大规模部署是实打实的钱。
作者是 NVIDIA 团队(Torsten Hoefler 在内),实现进了 NCCL。它会随驱动和库更新落到大多数人的推理栈里,不是停留在论文上的方案。对任何用张量并行服务大模型、尤其是长上下文和推理模型(reasoning,decode 重)的团队,这都是值得跟进的:一旦你的 NCCL 版本带上 low-latency kernel,ITL 和吞吐都会改善,不用改业务代码。
要泼一盆冷水:7-13% 的 ITL 提升是真实但不颠覆的。它的价值更多在于“把延迟逼近物理下限”这个方法论,以及证明了屏障是可以被系统性消除的,而不在于某个单点数字。