← 返回 PaperDaily
大模型与智能体
ETH Zurich×NVIDIA：微秒级抠延迟，推理成本再降一截
GPU 推理最怕的不是算力不够，而是通信那点“看起来不大、实则很贵”的微秒级开销。NVIDIA 这篇论文把 AllReduce 往硬件极限推，最好只剩约 7% 的误差，vLLM 推理和 cuSOLVERMp 都能吃到红利，属于非常典型的“抠延迟抠出真金白银”的工作。
龙哥读论文
发布于 2026-08-14 09:11:17
阅读 5
查看原文
原论文信息如下：
GPU通信延迟的“隐形杀手”：为什么每一微秒都至关重要？ 很多人盯着大模型推理，第一反应是“算力够不够”。这篇论文的视角更狠一点：真正拖慢多卡推理的，常常不是算不动，而是卡在通信那几微秒上
论文开头给了一个非常直白的现实：像 Llama-3.1-70B 这种级别的推理，已经不是“单卡跑不跑得动”的问题，而是“多卡之间谁先把那点通信抠掉”的问题。作者把目标定得很硬——不是把延迟降一点点，而是尽量逼近硬件允许的速度之光（Speed-of-Light, SoL）下界
这类工作最有意思的地方就在于，它看起来只是在“抠微秒”，但落到真实业务里，可能就是服务吞吐、延迟 SLA 和推理成本的差别。论文里甚至给出一个很有画面感的估算：在 4 张 GB200 上，AllReduce 每少掉 1 微秒，推理成本大约能再降 0.9%。单看不惊人，放到万亿 token 的规模上，就很难继续装作“微秒不重要”了。
AllReduce 是分布式训练和推理里最常见的集体通信之一，作用很朴素：把多个 GPU 上的张量做归约，再让每个 GPU 都拿到同样的结果。对大模型推理来说，它经常出现在张量并行的中间层，属于那种“平时不显山露水，关键时刻一脚刹车”的模块。
揭秘“速度之光”：如何量化GPU集体通信的物理极限？ 作者没有停留在“感觉很慢”这种模糊判断上，而是先把问题钉死：SoL 下界到底怎么算
这里的核心前提是 NCCL 最新的设备侧通信能力，以及对称内存（symmetric memory）机制。对称内存可以理解成：每个 GPU 上都有一块布局一致、地址可预测的“共享工作台”，这样设备端就能直接按逻辑地址访问彼此的数据，不必每次都绕一大圈回到主机。论文利用这一点，把很多原本要靠 CPU 或显式同步完成的动作，尽量搬到 GPU 自己手里。
SoL 下界的推导也很直接。对于最小化数据搬运的 AllReduce，理想情况下它的延迟可以写成：LSoL = 2LL2_RTT + Lremote_store
这套定义很重要，因为它把优化目标从“比别人快”变成了“离硬件极限还差多少”。论文后面所有设计，都是围绕这个目标展开的：减少同步次数、减少屏障、减少无效搬运
打破瓶颈：四种革命性技术，彻底消除内存屏障造成的延迟 论文最有意思的部分，恰恰不是某个单点技巧，而是把几种“小招数”拼成了一个无屏障、低等待、可组合
第一招叫 LL，英文全称是 low latency
第二招叫 sentinel，中文可以理解成“哨兵值同步”。它不是把标志位包进数据里，而是先把接收缓冲区填成一个不太可能出现的特殊值，比如 -NaN，然后轮询等它变掉。这样数据本身就能完整保留，不会像 LL 那样把有效载荷掰成两半。缺点也很现实：缓冲区复用前必须重置，而且数据里不能真的出现这个哨兵值，不然接收端会装瞎。
第三招是双向通信加双缓冲。这个设计的妙处在于，它专门针对“消息太大，得分多轮传”的场景。传统做法会在每轮之间插屏障，怕上一轮的数据还没读完就被下一轮覆盖。作者把缓冲区拆成两个交替使用的区间，让一边发、另一边读，谁也别抢谁的地盘。逻辑上就像两个人轮流搬箱子：一个箱子搬走前，另一个箱子先别乱放新货。
第四招最“工程味”，叫两次传输的 LL128 原子 AllReduce。它不是简单把前面的方法拼起来，而是重新设计了一条更适合 NVLink 的路径：利用 cache line 级别的原子加，把归约和同步揉到一起。为了让线程协作更顺，CTA 里还拆成普通线程和额外线程，专门处理被“挤出去”的元素。这个方法的优点是 scratch buffer 更省，带宽浪费也更少；缺点则是限制明显，只支持 NVLink、只支持加法、只支持单精度和半精度，而且结果还不保证确定性
为了让这些技巧不只是论文里的“手工活”，作者还在 NCCL 上做了一层低延迟 API，把 buffer、发送、接收、重置这些动作封装成可复用接口。这样做的意义很现实：以后写自定义通信 kernel，不需要每次都从裸同步和裸内存地址开始硬啃。工程上最怕的不是复杂，而是复杂得没法复用；这套 API 的价值就在于把“低延迟技巧”变成了“能拼装的积木”。
这里还有一个值得注意的细节：论文并没有把所有方案都吹成“银弹”。比如 LL128 原子法虽然很快，但牺牲了确定性；sentinel 虽然省带宽，但对数据范围有要求；LL 虽然同步干脆，但占带宽。这种写法比较诚实，也更像真正做系统的人：不是所有场景都该追求同一种最优
实践出真知：从微基准测试到vLLM和cuSOLVERMp的真实性能飞跃 论文最值得看的地方，不是“理论上能不能”，而是“放进真实系统以后到底有没有用”。这部分实验设计很对路：先用微基准测试把通信本身的极限摸清，再把 kernel 接到 vLLM 和 cuSOLVERMp 里，看它是否真的能改善端到端表现。这样的顺序很重要，因为系统论文最怕只在小黑屋里跑得漂亮，一进业务就原形毕露。
微基准结果先证明了一个事实：作者提出的方案确实能把小消息和中等消息的延迟压得很低，已经非常接近硬件 SoL 下界。尤其在 128B 这种典型小消息场景里，传统 NCCL ring 的延迟明显更高，而新 kernel 则把差距压到了一个很小的范围内。论文里最醒目的说法是，某些配置下开销已经可以收敛到距离绝对下界7%
更妙的是，这些收益不是只停留在“通信测试”里。接到 vLLM 之后，低延迟 AllReduce 直接改善了 inter-token latency，也就是每个 token 之间的等待时间。对用户来说，这比“峰值吞吐涨了多少”更有体感，因为聊天、代码补全、长上下文问答都更在乎响应是否顺滑。论文里还给出了成本收益估算：延迟少一点，吞吐高一点，单个输出 token 的成本也跟着下降，这才是服务端真正关心的结果。
cuSOLVERMp 的结果则说明，这套方法并不只服务于大模型。传统 HPC 工作负载里同样有很多“频繁小通信”的场景，尤其是矩阵分解、迭代求解这种循环紧、同步密的任务。论文里 mp_sygvd 的测试显示，接入新 kernel 后，每 GPU 的 GFLOPS 有明显提升，说明低延迟集体通信对科学计算同样有实际意义。说得直白一点：这不是只给 AI 圈子准备的“专属补药”
实验还专门看了 scratch buffer 大小对性能的影响，这一点很工程。因为低延迟协议往往不是“白捡”的，缓冲区分配不够，设计再漂亮也会被卡住。结果表明，不同 kernel 对缓冲需求不同，达到单轮完整处理所需的最小缓冲后，延迟才会真正进入理想区间。换句话说，想要接近 SoL，不只是算法要聪明，内存预算也得跟上。
如果把整篇工作压缩成一句话，那就是：它不是在发明一种新的通信范式，而是在把现有硬件能做的事情榨到更接近极限
未来展望与开放问题：我们能无限接近光速吗？ 这篇论文最强的地方，不是“某个 kernel 特别快”，而是它把 GPU 集体通信的优化目标重新定义了：不是追求某个 benchmark 的漂亮数字，而是追求离物理下界有多近
但它也不是万能钥匙。LL128 原子法有确定性问题，sentinel 法有数据约束，LL 法有带宽代价，而这些限制在不同业务里可能会被放大。更现实一点说，真正落地时还要看模型类型、消息分布、GPU 拓扑、缓冲预算，以及上层框架愿不愿意配合。系统优化常常不是“有最优算法就行”，而是“最优算法能不能被正确接上”。
从行业角度看，这类低延迟通信会越来越重要。模型越大、上下文越长、服务越实时，通信就越不像“辅助项”，而更像决定用户体验的主角。未来如果 GPU 域继续扩展、设备侧原语继续增强、更多框架愿意拥抱这些低延迟 API，那么今天这些“抠微秒”的工作，可能会变成明天默认的基础设施。
龙迷三问 这篇论文到底解决了什么问题？
SoL 下界是什么意思？
LL、sentinel、LL128 atomic 三者有什么区别？
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评
论文创新性分数： ★★★★☆ 不是凭空发明新通信，而是把低延迟协议、双缓冲、原子归约和 NCCL 设备侧接口组合成一套更接近硬件极限的系统方案，创新点扎实。
实验合理度： ★★★★★ 先测 SoL 下界，再做微基准，最后落到 vLLM 和 cuSOLVERMp，链路完整，结论也比较能站住脚。
学术研究价值： ★★★★☆ 价值在于把“延迟优化”从经验活儿变成可量化、可复用的方法论，对后续 GPU 通信研究很有启发。
稳定性： ★★★☆☆ LL128 atomic 有确定性和类型限制，sentinel 也有数据约束，说明它不是一把梭的通用解。
适应性以及泛化能力： ★★★☆☆ 对长上下文推理和小规模频繁通信很合适，但并不适合所有消息模式和所有拓扑。
硬件需求及成本： ★★★☆☆ 需要较强的 NVIDIA 平台能力，尤其是 NVLink、对称内存和设备侧通信支持；对普通设备不算轻量。
复现难度： ★★★☆☆ 思路清楚，但强依赖特定 NCCL 版本和硬件环境，真正复现到同样效果不算轻松。
产品化成熟度： ★★★★☆ 已经能嵌入 NCCL 并在真实 workload 里见效，离可用很近，但不同方案的约束要按场景选。
可能的问题： 追求极致低延迟的代价是复杂度和约束上升，尤其是确定性、数据类型和硬件绑定问题，不能把它当成万能模板。
主要参考文献
[1] Shen, S., Korzh, A., Bachan, J., et al. Every µs Matters: Achieving Near Speed-of-Light Latency in GPU Collectives. arXiv:2607.16100v1, 2026. [2] NCCL Documentation and device-side communication APIs, referenced in the paper. [3] vLLM, SGLang, TensorRT-LLM and related low-latency inference frameworks cited in the paper. GPU 推理里， 每一微秒都在烧钱 。想继续追这种“把延迟抠到骨头里”的论文，欢迎加入龙哥读论文粉丝群，一起拆方法、看实验、聊落地，少走弯路，多看门道。
欢迎加入龙哥读论文粉丝群，
扫描下方二维码或者添加龙哥助手微信号加群 ：kangjinlonghelper。
一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥） ，根据格式备注，可更快被通过且邀请进群。『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
