← 返回 PaperDaily 大模型与智能体

ETH Zurich×NVIDIA新作：AllReduce为何能贴近SoL下界

这篇论文很像在GPU通信里“抠微秒”。看起来只是把延迟从 11.0 微秒压到 2.37 微秒，背后其实是在逼近硬件下限；一旦放进大模型推理链路，省下来的就不只是时间，还有真金白银。

龙哥读论文发布于 2026-08-14 21:47:07 阅读 3 查看原文

#人工智能 #AI应用 #大语言模型 #模型训练

原论文信息如下：

论文标题:
Every µs Matters: Achieving Near Speed-of-Light Latency in GPU Collectives
发表日期:
2026年07月
发表单位:
ETH Zurich / NVIDIA Corporation
原文链接:
https://arxiv.org/pdf/2607.15628v1.pdf

通信延迟“秒杀”大模型：一个微秒值多少钱？

图1：长上下文、小批量的张量并行大模型推理里，很多小规模 AllReduce 都卡在关键路径上。论文要解决的，不是“能不能通信”，而是“能不能把通信压到离硬件极限只差一点点”。

这篇论文的切口很狠：GPU 集合通信过去主要盯着带宽，但在长上下文、解码密集型的大模型推理里，真正先把系统拖慢的往往是延迟。因为每生成一个 token，模型都要走一串通信小动作；动作不大，次数却很多，像一群人排队过安检，单次只耽误几微秒，排多了就能把整趟航班拖黄。

论文给出的数字很有冲击力：在 4 张 GB200 上，小消息 AllReduce 的平均延迟从 NCCL ring 的 11.0 µs 降到 2.37 µs，已经逼近所谓的 Speed-of-Light, SoL（速度上限下界）。这里的 SoL 不是科幻设定，而是指由互连与内存系统共同决定的绝对硬件下限。换句话说，论文不是在“优化一点点”，而是在逼着通信往“物理极限”贴脸走。

一个很现实的问题：如果一次 AllReduce 只省 1 微秒，值不值得折腾？论文的回答是：单次看起来像“蚊子腿”，但放到大模型服务的亿级、万亿级 token 规模里，蚊子腿也能长成一条腿。

论文还把这个问题算得很直白：按照云上 4 张 GB200 的价格和输出吞吐换算，每去掉 1 微秒 AllReduce 延迟，成本大约能下降 0.9%。这类数字最扎心，因为它把“工程优化”直接翻译成“账单优化”。对推理服务来说，这不是学术洁癖，而是财务报表。

瓶颈分析：内存屏障——通信延迟的隐形杀手

先把背景说人话：AllReduce就是把多张 GPU 上的同一份数据做归约，再把结果发回每一张卡。它是分布式训练里最常见的通信之一，在推理里也经常出现在张量并行的关键路径上。只要模型一大、上下文一长、批量一小，这个动作就会频繁出现，而且每次都很难“顺手做完”。

论文先做了一件很工程的事：不是拍脑袋说“延迟高”，而是去拆它到底高在哪。结果发现，很多现有的一-shot、two-shot 方案虽然已经把通信轮数压得很少，但仍然依赖显式的内存屏障来同步各个参与者。问题就出在这里——屏障本质上是在等大家都到了再继续，听上去公平，实际上很贵。

图3：GB200 上屏障延迟随 GPU 数量变化的结果。无论是单播还是多播，屏障都不是“免费午餐”，每次同步都要付出超过 1 微秒的代价。

这张图的意思很直接：当一个小消息 AllReduce 本身也就几微秒时，屏障一插进去，等于给本来就不宽裕的预算再加一笔“隐形税”。论文测到的结论很扎眼——不少实现里，两次屏障就能吃掉总延迟的相当大一部分。也就是说，很多方案不是输在通信本体，而是输在“先等等大家”的同步礼节上。

论文进一步把问题归纳成一句话：如果目标是逼近 SoL，那么任何额外的全局等待都很难容忍。于是，后面的设计思路就非常明确了——不是继续把屏障做得更漂亮，而是干脆把它从流程里抹掉。

“无墙”设计：四大技巧实现逼近物理极限的集合通信

论文的核心不是发明一种“更玄学”的 AllReduce，而是把已有的低延迟组件重新组合，目标只有一个：不靠全局屏障，也能保证正确性。这就像搭积木，难点不在于某一块积木有多神，而在于怎么拼到既快又不塌。

图2：NCCL 中设备发起通信与对称内存概览。GPU 不再只是“等 CPU 指挥”的执行者，而是可以直接发起通信、直接轮询、直接同步。

先看第一招 LL。这里的 LL 是 Low Latency，中文就是“低延迟协议”。它的思路很粗暴：把 8 字节数据和 8 字节标志打包成 16 字节，一次性发过去，接收端看标志就知道数据到了，不需要另起炉灶做同步。优点是快，缺点也很现实：有效带宽会被标志吃掉一半，scratch buffer 也更占地方。所以它只适合特别小的消息，属于“快是快，就是有点费料”。

第二招是 sentinel，也就是“哨兵值”同步。英文原意是守卫、哨兵，论文里具体做法是：先把接收缓冲区填成一个不太可能自然出现的值，比如 -NaN，然后发送端直接写数据，接收端不断轮询，直到发现值不再是哨兵，就说明数据到了。这个方法比 LL 更省带宽，也更省 scratch buffer，但代价是管理更麻烦，而且如果真实计算结果碰巧等于哨兵值，系统就会“装看不见”。所以它不是万能钥匙，更像一把适合中等消息的轻量扳手。

图4：双缓冲下的双向通信示意。这里最关键的不是“快传”，而是“别把下一轮要用的缓冲区提前踩坏”。双缓冲把时间切开，让一轮通信与下一轮准备尽量错峰。

第三招是 双向通信 + 双缓冲。前面两种方法能解决“单次交换怎么同步”，但一旦消息被切成多个 chunk，问题就来了：上一轮还没完全读完，下一轮就想写同一个位置，缓冲区立刻打架。论文的处理方式很巧：把 scratch space 分成两个 buffer，轮流使用。当前轮在 Buffer 0 上跑，下一轮切到 Buffer 1；等对端确认读完当前轮，才允许覆盖。这样一来，每次收到对端的数据，就等于获得了下一次发送的“通行证”，不需要全局屏障来统一放行。

第四招是这篇论文最像“真刀真枪改算法”的部分：two-shot LL128 atomic AllReduce。这里的 LL128 指的是 NCCL 里一种面向 128 字节 cache line 的低延迟协议；atomic 则表示它利用原子加法来做归约。论文给它的中文理解可以很简单：不是等所有数据都堆齐了再统一开算，而是按 cache line 粒度边收边加，尽量把同步成本压到最低。

图5：two-shot LL128 atomic AllReduce 算法概览。线程块被拆成常规线程和额外线程两组，前者处理主数据，后者处理被“挤出去”的元素，避免 cache line 粒度上的错位。

这套设计的关键点在于：每 8 个线程协作处理 128 字节，正好对齐 cache line；每个参与者把自己的第一项当作 flag carrier，最后通过原子加法把同一行的数据累到一起。当某个 cache line 的 flag 变成 GPU 数量 N，就说明这一行已经齐活，可以进入 AllGather 阶段。这个想法的妙处是，它把“同步是否完成”嵌进了数据本身，不再单独搞一个屏障线程去看门。

图6：低延迟 API 总览。论文不是只给出一个算法，而是把这些机制封装成 NCCL 设备端 API，方便直接拼装成自定义通信内核。

更值得注意的是，论文没有停在“算法灵感”层面，而是把它们做成了 API。核心对象叫 ncclLLBuffer，可以理解成一个包装好的对称内存缓冲区。它支持 LL 和 sentinel 两种同步模式，还能通过 epoch 机制把不同轮次的数据切到不同子缓冲区里，避免反复覆盖。对开发者来说，这相当于把“怎么同步、怎么轮转、怎么复用缓冲”这些脏活累活交给库，自己更专注于算法本身。

图7：ncclLLBuffer 的构造与布局。每个 CTA 在每个 epoch 内拿到固定区域，advanceEpoch() 会切换到下一轮子缓冲区。

图8：ncclLLBuffer 的 send() 与 recv()。send 负责写入，recv 负责轮询与读取；如果是 sentinel 模式，就等值不再是哨兵；如果是 LL 模式，就等 flag 对上当前 epoch。

论文还给出了一张很有用的对比表，把不同低延迟 AllReduce 的通信量、同步次数、scratch space 和确定性问题摆在一起。这里不需要死背公式，最重要的是看懂它传达的工程判断：LL 适合极小消息，sentinel 适合中小消息，LL128 atomic 更像性能优先但不追求完全确定性的方案。也就是说，论文不是迷信单一方案，而是按消息大小和硬件特性做分层选择。

表1：低延迟 AllReduce 算法对比。这里能看出不同方案在通信量、同步轮数、缓冲需求和确定性上的明显差异。

论文还解释了一个容易被忽略的细节：为什么这些设计大多基于 NVIDIA 的 NCCL？原因不是“只会这一家”，而是 NCCL 在深度学习框架和科学计算库里实在太常见了，落地价值更高。更重要的是，LL、sentinel、双缓冲这些思路并不完全依赖某一家硬件，只要系统支持 GPU 发起访问、远端可见的写入和必要的栅栏/顺序保证，很多平台都能照着思路实现。

实测验证：微秒级延迟降低如何转化为千万元级成本节省

图11：不同 GPU 数量下的 AllReduce 延迟对比。论文把 NCCL、NVSHMEM、MSCCL++、vLLM 等方案都拉出来比较，重点看小消息区间谁更接近 SoL。

实验结果最能说明问题：在多个 GPU 配置下，论文提出的低延迟内核在小消息和中等消息区间里，普遍能把延迟压到现有实现之下，而且不少点已经非常接近图中的 SoL 下界。这里的“接近”不是修辞，而是意味着再往下压，能拿走的就不只是软件优化空间，而是硬件物理边界本身。

更有意思的是，论文没有只停留在 microbenchmark。它把方法塞进了真实系统里：一边是 vLLM 推理，一边是 cuSOLVERMp。这一步很关键，因为很多论文的悲剧都出在“实验室里很美，线上一跑就散”。这篇没有那么飘，它确实看到了更低的 inter-token latency（ITL，token 间延迟）和更高的吞吐。

图13：低延迟集合通信对 vLLM 推理的影响。表里直接给出 ITL、吞吐和每百万输出 token 的成本变化，已经不是“学术上更好看”，而是“业务上更好算账”。

从业务视角看，这类收益非常实在。长上下文、低批量推理时，模型每生成一个 token 都要和其他 GPU 交换信息，通信延迟会被不断放大。论文显示，低延迟内核能带来可观的 ITL 降低和输出吞吐提升，换算到成本上，就是每百万 token 的单价往下掉。对大模型服务来说，这种优化不一定上新闻，但一定会上财务表。

图14：对 cuSOLVERMp 的性能影响。这个结果说明，低延迟集合通信不是“只对大模型有用”，传统 HPC 的同步密集型场景同样能吃到红利。

对 HPC 来说，这个意义也不小。很多求解器和模拟程序的关键循环里，都藏着频繁的小规模归约，通信一慢，强扩展性就被卡住。论文把 cuSOLVERMp 的结果拿出来，等于告诉大家：低延迟通信不是 AI 圈的“专属外挂”，传统科学计算也能分一杯羹。

看到这里，最让人服气的不是“又快了一点”，而是论文把优化逻辑讲得很完整：先证明屏障贵，再把屏障拿掉，再把拿掉后的机制封装成 API，最后把 API 塞进真实工作负载里验证。这个链条很顺，没有那种“方法很花、结果很虚”的味道。

总结与展望：从LLM到HPC，低延迟集合通信的未来

这篇论文最值得记住的，不是某一个花哨算法名，而是一个朴素但很硬的判断：在小消息集合通信里，微秒级延迟就是实打实的生产力。当模型推理越来越长、并行切得越来越细，通信已经不是后台杂务，而是前台业务的一部分。

不过，这篇工作也不是“无敌”。LL128 atomic 方案对硬件有要求，主要依赖 NVLink，并且只覆盖单精度和半精度，且在浮点原子顺序上不保证确定性。sentinel 方案也有自己的小脾气：哨兵值不能和真实数据撞车，缓冲区还得额外管理。换句话说，它们都很强，但都不是“随便搬到哪儿都能无脑起飞”的万能件。

更现实的展望是，这类方法很可能继续沿着两个方向演进：一边是更深地和大模型推理框架融合，把通信内核做成“开箱即用”的默认选项；另一边是向更广的 HPC 和多 GPU 科学计算扩展，把低延迟通信从“AI 优化技巧”变成基础设施能力。只要系统还在追求更小的 batch、更长的上下文、更细的并行切分，这条路就不会过时。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是 GPU 集合通信里“小消息太慢”的问题，尤其是长上下文、低批量大模型推理里那些卡在关键路径上的 AllReduce。核心目标不是单纯提吞吐，而是把延迟尽量逼近硬件下限。

LL、sentinel、LL128 atomic 分别是什么意思？LL 是 Low Latency 低延迟协议，把数据和标志一起传；sentinel 是哨兵值同步，先填一个特殊值再轮询；LL128 atomic 是一种基于 128 字节 cache line 和原子加法的两阶段 AllReduce，能把同步和归约揉到一起。

为什么论文一直强调内存屏障很贵？因为在微秒级通信里，屏障本身就可能带来超过 1 微秒的额外开销，而很多小消息 AllReduce 本来就只有几微秒。对这种场景来说，屏障不是“保险”，更像是额外的税单。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

创新点不在“发明新宇宙”，而在把低延迟同步、双缓冲、原子归约和 NCCL API 组合成一套能落地的体系，工程味很足。

实验合理度：★★★★★

既做了微基准，又进了 vLLM 和 cuSOLVERMp，结果链条完整；还把 SoL 下界和成本收益都摆出来了，比较有说服力。

学术研究价值：★★★★☆

它把“延迟优先”的集合通信问题讲透了，对后续 GPU 通信库设计和大模型推理优化都有参考价值。

稳定性：★★★☆☆

LL128 atomic 和 sentinel 都有条件约束，前者有硬件和数值确定性限制，后者有哨兵值碰撞风险，离“到处通吃”还有距离。

适应性以及泛化能力：★★★★☆

在同类 GPU 集群和低延迟同步场景里适应性不错，但对硬件特性和消息类型仍有依赖，不是所有平台都能直接照搬。

硬件需求及成本：★★★☆☆

性能很强，但要吃到最完整收益，还是得依赖较新的 NVIDIA 互连和 NCCL 设备端能力；不是低配机器也能随手复刻的类型。

复现难度：★★★☆☆

论文给了 API 思路和实现方向，但要完整复现需要较新的硬件、通信栈和系统环境，门槛不算低。

产品化成熟度：★★★★☆

已经非常接近实际可用，尤其适合 LLM 推理和部分 HPC 任务；但确定性、硬件约束和缓冲管理仍需要进一步工程打磨。

可能的问题：方法很强，但对硬件和同步语义依赖明显；LL128 atomic 的非确定性与 sentinel 的值域约束，都会限制它的通用部署。

主要参考文献

[1] Siyuan Shen, Anton Korzh, John Bachan, et al. Every µs Matters: Achieving Near Speed-of-Light Latency in GPU Collectives. arXiv:2607.15628v1, 2026.

[2] NCCL 2.28 device-side communication APIs and symmetric memory related documentation, NVIDIA.

[3] vLLM, TensorRT-LLM, SGLang and related inference systems cited in the paper.

*微秒级优化听起来像抠细节，实际常常就是省钱省时省命。想继续围观这类“把GPU榨到极限”的论文，欢迎加入龙哥读论文粉丝群，和一群爱抠性能、爱拆系统的同好一起聊。扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper，备注“研究方向+地点+学校/公司+昵称”更快通过～

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。本期如果也在和 GPU 延迟、推理吞吐、HPC 通信较劲，群里正好能找到同路人。
wechat_helper