让多机协同 · 集合通信与互联

0. 切开之后,真正的麻烦才开始

上一章我们一直在切:把一个模型从四个维度切开,分散到很多张卡上。但我故意把一件事压着没讲透,那就是切开只是上半场。张量并行算完一层要把碎块合并、专家并行要把 token 送到专家卡再收回来,这些「合并」和「送回来」全都意味着卡与卡之间要搬数据;模型切得越细,要搬的次数就越多。这一章就把这个被一直压着的下半场打开,看清这些数据到底是怎么在卡之间流动的、又为什么这件事这么要命。

这件麻烦,其实你在第一章就见过它的影子。当时认知弧的第三条说:曾以为堆更多 GPU 就能更快,撞的墙是卡间搬数据比算还慢,于是通信成了新的瓶颈。那时我只丢给你一个结论,这一章要把机制补上 —— 通信到底是怎么发生的、它为什么慢、以及工程上是怎么跟它死磕的。把这一章读完,你回头看第一章那句话,就不再是一句口号,而是一台你能拆开看的机器。

1. 为什么切开就必须通信

先建立一个最朴素的直觉:为什么一旦把计算切开,通信就变得不可避免。拿上一章的张量并行当例子,想象它把一层的矩阵乘法切给两张卡,算完之后,每张卡手里都只有最终结果的一半。但问题来了,下一层需要的是完整的结果,不是两个半块;所以这两个半块必须先合并成一个完整块,数据才能继续往上一层流。这个「合并」就是一次实打实的通信:一张卡显存里的半块,必须搬到另一张卡的显存里去拼。你切得越细、这种合并就发生得越频繁,通信也就越多;而这还只是两张卡、一层的情况,真实的大模型有成百上千张卡、几十上百层,每一层、每一种并行切法都在不停地制造这种合并的需求,通信量会迅速堆成一座山。

把这个道理推广开,你就得到一条贯穿全章的判断:通信不是分布式额外背上的开销,而是「把计算切开」这一刀必然要付的账。你切开是为了装得下、为了算得快,但切开的同时,也就制造了「碎片必须重新拼起来」的义务,而拼起来就得搬数据。所以一个分布式系统的性能,常常不取决于每张卡单独算得多快,而取决于卡与卡之间数据搬得多顺 —— 算力堆得再高,数据卡在搬运的路上,整个系统照样快不起来。

通信是「把计算切开」必然要付的账 —— 分布式系统的瓶颈,常常不在算,而在搬。

既然搬数据这么关键,工程上就需要一套高效、标准的搬法,而不是每次都临时手写一遍。这套标准动作,就叫集合通信。它把「很多张卡一起搬数据」这件事,抽象成几个固定的、被反复打磨优化过的原语;你只要说一句「我要做一次 all-reduce」,底层的库就会用针对当前硬件的最优方式,把数据在所有卡之间搬好。下一节我们就来看这几个最常用的原语,各自到底把数据搬成了什么样。

2. 三个原语 · 各把数据怎么搬

集合通信的原语有好几个,但你只要先吃透三个最常用的,就足以理解上一章那四种并行背后的通信长什么样。我用同一个画面来讲它们:四张卡,编号 R0 到 R3,每张卡手里有一块数据,而一个原语,就是「这四张卡协同把数据搬成某个新格局」的一个标准动作。先看下面这张图把三个动作放在一起,然后我们逐个拆开。

2.1 all-reduce:各卡的部分,合成人人都有的整体

第一个、也是最重要的一个,叫 all-reduce。它干的事是:四张卡每张手里有一个部分结果,all-reduce 把这些部分按某种规则(最常见的是求和)归并成一个完整结果,再让每一张卡都拿到这份完整结果。打个比方,四个人各自数了房间里一部分的人头,all-reduce 就是把四个数加起来得到总人头,再确保四个人手里都写着这个总数。它为什么最重要?因为它恰好就是张量并行合并碎块、数据并行平均梯度时要做的那件事 —— 上一章那两个「合并」的动作,落到通信这一层,名字就叫 all-reduce。你每次在系统报告里看到它,基本都意味着「有一堆卡正在把各自的部分凑成一个整体」。

2.2 all-gather 与它的反操作:收齐与切散

第二个叫 all-gather。它的场景是:四张卡每张手里有一块不同的数据(比如各自持有模型的一部分),all-gather 让每一张卡最后都收齐全部四块。打个比方,四个人各写了一份报告里的一章,all-gather 就是让四个人最后手里都拿到完整的四章。它还有一个方向相反的兄弟,叫 reduce-scatter,做的是先把各卡的数据归并,再把归并后的结果切成四份、各分一块下去。这俩为什么值得放一起记?因为有一个很漂亮的事实:一次 all-reduce,恰好等于先做一次 reduce-scatter、再做一次 all-gather。看清这层关系,你就不会把这些原语当成互不相干的咒语去背,而是理解它们其实是同一组积木的不同搭法 —— 这也是为什么高效实现一次 all-reduce,本质是在高效实现这两个更小的动作。

2.3 all-to-all:人人对人人的全交换

第三个叫 all-to-all,它是这三个里最「热闹」的一个。前两个原语里,每张卡要发出去的东西对所有人都是一样的;但 all-to-all 不一样,每张卡要发给其他每一张卡的,是各不相同的一份,同时它也从其他每一张卡各收一份不同的。打个比方,四个人交换礼物,但每个人给另外三个人准备的礼物各不相同,交换完每个人手里都是一堆从别人那儿收来的、各不一样的东西。这种「人人对人人、且份份不同」的全交换,通信代价很高,而它恰好就是上一章专家并行路由 token 时要做的事:每个 token 要被送到它该去的那个专家所在的卡,而不同 token 去的专家又不一样,这汇总起来正好是一次 all-to-all。所以上一章埋的那个伏笔,现在能接上了 —— 专家并行那种特别的通信,名字就叫 all-to-all,它也是本章最后 DeepSeek 那套精巧设计要拼命优化的头号对象。

2.4 谁来真正干这件事:NCCL 与 RCCL

你可能会问,这些原语究竟是谁来实现的?答案是一类叫集合通信库的软件,在英伟达的 GPU 上是 NCCL,在 AMD 的 GPU 上是与之对应的 RCCL。它们的角色,是把「在这一堆卡之间做一次 all-reduce」这样一句请求,翻译成针对具体硬件拓扑的最优搬运方案 —— 哪两张卡之间是高速直连、哪两张之间要走网络,都由它来盘算,而你写训练或推理框架时只管调用,不必关心底层怎么走线。这个名字记住就好:当你日后在一份系统报告或一条报错里看到 NCCL,它指的就是这一层,卡间集合通信的发动机。

3. 互联的两个层级 · 一道数量级的鸿沟

上面讲的是「搬什么、怎么搬」,这一节讲「搬得多快」。而搬得多快,根本上取决于卡与卡之间是用什么线连起来的。这里有一个最关键的事实,你必须装进脑子,因为它从根上塑造了后面一切的设计:卡间互联其实分成两个层级,而这两个层级的带宽,差了大约一个数量级。先把这两层分清楚,你才看得懂为什么系统设计师那么在意「谁和谁在同一台机器里」。

第一个层级是节点内。一台服务器(也就是一个节点)里通常塞了 8 张 GPU,这 8 张卡之间用一种叫 NVLink 的高速直连连起来,再通过一块叫 NVSwitch 的交叉开关芯片,组成「任意两张卡都能同时全速对话」的网络。这一层有多快?在 H100 上,每张卡的 NVLink 带宽约是 900 GB/s。打个比方,这就像同一栋楼里的几个办公室之间拉了专用的高速光纤,串个门几乎不花时间,数据在节点内的 8 张卡之间流动,是相当奢侈的。

这里要顺手拆掉一个特别常见的混淆:NVLink 和 NVSwitch 不是一回事。NVLink 是卡与卡之间的那条「路」,是链路本身;NVSwitch 是一块「立交桥」芯片,它把这些路连成一个谁都能直达谁的交叉网络。区别在哪?没有 NVSwitch,8 张卡只能两两点对点地连,每张卡的带宽要被分摊到和多张卡的连接上;有了 NVSwitch,任意两张卡之间才能同时跑满全速。一句话记住:NVLink 是路,NVSwitch 是那座让所有车都能同时直达目的地的立交桥,两者配合,才有了节点内那个奢侈的全速网络。

第二个层级是节点间。当你的计算大到一台 8 卡服务器都装不下、必须用很多台机器一起上时,机器和机器之间靠的是另一种网络,叫 InfiniBand(常和前面说的 RDMA 一起出现)。它有多快?当下主流的一代,每张卡分到的跨机带宽约是 50 GB/s。把它和节点内那个 900 GB/s 放在一起,你立刻就看到那道鸿沟了:节点内比节点间快了将近二十倍;即便在互联被特意砍过的 H800 上(节点内约 400 GB/s),也还有约八倍的差距。下面这张图把这道鸿沟按真实比例画出来,你扫一眼就忘不掉。

这里得插一句诚实话,免得你日后被几个数字绕晕。你可能会在 DeepSeek 的报告里读到「NVLink 160 GB/s」这种说法,和我刚说的 900 对不上 —— 那是因为 900 是 H100 的硬件规格上限,而 160 是 DeepSeek 在被砍过互联的 H800 上、实际能稳定吃到的有效带宽,两者本来就不是一个口径。你不用记那么多数字,记住硬件规格这套数量级关系就够了:节点内是几百 GB/s 这个量级(H100 约 900、H800 约 400),节点间是几十 GB/s 这个量级(约 50),前者比后者快一个数量级。顺带再补一个名词:让网络能直接把数据写进 GPU 显存、不必绕一圈 CPU 的技术,叫 RDMA,以及它面向 GPU 的加强版 GPUDirect 和 IBGDA,DeepSeek 那套通信魔法的底下,踩的就是它们。

还要再说一层时间上的话,免得你把具体数字当成永恒。本章这些带宽(NVLink 900 与 400、IB 50)是 Hopper 世代、也就是 DeepSeek-V3 用的那批卡的数字;到 2026 年,英伟达已经出到 Blackwell Ultra、Rubin 这些新几代,节点内的 NVLink 涨到了约 1.8TB/s、跨机的网络也涨到约 200GB/s。但你真正要带走的不是这些会过期的绝对值,而是那个不变的比例:节点内永远比节点间快上大约一个数量级。卡每换一代,两个数字一起变大,这道鸿沟却始终都在,所以下面所有的设计直觉,在新硬件上照样成立。

把这道鸿沟记牢,因为它是后面无数设计决策的根因。当节点内比节点间快了整整一个数量级,系统设计的第一原则几乎是自动浮现的:凡是能在节点内解决的通信,就绝不要轻易跨出节点;一旦非跨节点不可,也要把跨出去的数据量压到尽可能小。这一条直觉,你会在这条路书后面反复用到,它几乎是一切大规模分布式设计的出发点。

节点内(NVLink)比节点间(InfiniBand)快约一个数量级 —— 于是「能不跨节点就不跨」成了分布式设计的第一直觉。

4. 带宽差怎么塑造一切上层设计

抽象的原则,不如一个真实的例子有冲击力。我们来看 DeepSeek-V3 是怎么被这道带宽鸿沟逼出一套精巧设计的 —— 这个例子也正好把本章的两条线(集合通信和互联)拧成一股,落到一个真实的顶级系统上,让你看清前面那些概念合在一起是什么样子。

还记得专家并行要做的那次 all-to-all 吗?每个 token 要被路由到它的专家所在的卡,而专家散布在很多个节点上,这就意味着海量的跨节点通信,正好一头撞在那道最慢的 InfiniBand 鸿沟上。DeepSeek 的应对分两步走。第一步,它给每个 token 立了一条硬规矩:最多只能被发往 4 个节点,从源头上就把昂贵的跨节点流量摁住。第二步更巧:当一个 token 要去某个节点时,它先用一次 IB 把这个 token 发到目标节点上一张「同号」的落地卡上,再由这张落地卡,用快得多的节点内 NVLink,把它转发给真正持有那个专家的卡。下面这张图把这条路径画了出来。

这套绕来绕去的设计,本质其实只有一句话:用便宜的快通道,去替昂贵的慢通道分担工作。跨节点这一步贵,那就尽量少走、而且走最短的一跳;一旦数据进了目标节点,剩下的转发就交给快十几倍的节点内通道去完成。再配上一个狠招:把每张 GPU 上 132 个计算单元(SM)里的 20 个专门划出来,只负责通信,还配上手写的底层指令,让这部分通信和正常的计算同时进行、彼此藏在对方背后。这么一来,本该拖慢一切的通信耗时,就被悄悄「藏」进了计算的时间里,几乎看不见了 —— 这就是工程师们常说的「通信与计算重叠」。

你不需要记住这些细节,真正要带走的是这套设计「为什么长成这样」:它每一个看似古怪的选择,都是被那道节点内快、节点间慢的带宽鸿沟逼出来的。这恰恰就是第一章认知弧第三条那堵「卡间搬数据比算还慢」的墙,在一个真实顶级系统里被解开的样子。它还教给你一个能反复迁移的判断:以后再看任何分布式系统的设计,先别管它的名词多炫,先问一句 —— 它到底在拿什么便宜的资源,去替什么昂贵的资源分担压力?想清楚这一句,你往往就抓住了那个设计的灵魂。而这种拿快资源去替慢资源分担的腾挪,并不是 DeepSeek 独有的小聪明,你在这条路书后面讲推理服务的调度、讲存储的分层时,还会一次次遇到它的变体。

还有一个值得记住的后续,它正好印证了这门工程怎么自我纠正:这套「每个 token 最多只碰 4 个节点」的约束,是 V3 在 2024 年的解法;而 DeepSeek 在 2026 年的新旗舰 V4 里,已经把这个约束整个移除了,靠的是一套更聪明、把通信更彻底地藏进计算的新方案。你看,这又是一次撞墙开新轴:V3 用一条约束绕开「IB 太慢」这堵墙,V4 干脆用新方案让那条约束本身变得不再必要。领域就是这样一轮一轮往前纠的,它也提醒你,本章的每个具体数字都会被更新,但「为什么这么设计」的那套推理方式不会。

综合 · 你现在懂了「多机怎么协同」

回头看这一章你拿到了什么。你先想通了一件根上的事:通信不是分布式额外背上的开销,而是「把计算切开」这一刀必然要付的账,所以一个分布式系统的性能,常常不取决于每张卡单独算得多快,而取决于卡与卡之间数据搬得多顺。你还认识了三个最常用的搬法:all-reduce 把各卡的部分合成人人都有的整体(张量并行、数据并行靠它),all-gather 让人人收齐每一块,all-to-all 是人人对人人的全交换(专家并行路由 token 靠它),而这些动作底下,由 NCCL 这类集合通信库来真正执行。

你更拿到了这一章里最值钱的那个数量级:卡间互联分节点内和节点间两层,节点内的 NVLink 比节点间的 InfiniBand 快约一个数量级。正是这道鸿沟,逼出了像 DeepSeek-V3 那样的精巧设计:把每个 token 限制在 4 个节点内、先用 IB 落地再用 NVLink 转发、还划出 20 个计算单元专做通信、把通信藏进计算。你也顺手学会了那个可迁移的判断:看任何分布式系统,先问它在拿什么便宜的资源,替什么昂贵的资源分担 —— 这一个问题,几乎能帮你看穿这条路书后面绝大多数大规模系统的设计动机。

学完这一章,你已经握住了「分布式基石」这一站的两块地基:上一章的「怎么把模型切开」,和这一章的「切开之后,多机怎么协同」。带着这两块地基,你已经准备好走进这条路书真正的主脊了。从下一章起,我们离开「训练和推理共享的底层」,正式走进推理服务:当亿万个请求涌进来,一个被切开、铺在整个集群上的模型,到底是怎么一次又一次地把它们服务好的。这就是你该合上书、准备迈进第三站的地方。

本章关键术语

本章引入的 canonical 术语,点进术语表看更完整的解释:

• 集合通信 collective communication 一组让多张卡协同搬运数据的标准原语;是「把计算切开后必须把碎片合起来」的工程化答案
• all-reduce 把各卡的部分结果归并(常为求和)成完整结果、再让每卡都拿到;张量并行合并、数据并行平均梯度用它
• all-to-all 人人对人人的全交换:每卡给每卡各发一份不同的、也各收一份;MoE 专家并行路由 token 的核心原语
• NVLink 节点内 GPU 之间的高速直连(H100 每卡约 900 GB/s,H800 约 400);比节点间快约一个数量级
• NVSwitch 把多条 NVLink 连成「任意两卡全速直达」的交叉开关芯片;NVLink 是路,它是立交桥
• InfiniBand 节点间的高速网络(每卡约 50 GB/s);跨机通信的主力,也是那道带宽鸿沟里慢的一侧
• RDMA 让网络直接读写远端内存、不绕 CPU 的技术;面向 GPU 的加强版是 GPUDirect / IBGDA
• NCCL 英伟达的集合通信库(AMD 对应 RCCL):把一句 all-reduce 翻译成针对硬件拓扑的最优搬运方案

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• NCCL · Collective Operations 文档(NVIDIA)· all-reduce / all-gather / reduce-scatter / all-to-all / broadcast 的权威定义
• NVIDIA NVLink & NVSwitch(NVIDIA)· 第四代 NVLink 每卡 900 GB/s(双向)的硬件依据
• NVIDIA Quantum-2 InfiniBand + ConnectX-7· NDR 400 Gb/s(每卡 50 GB/s)的节点间带宽依据
• DeepSeek-V3 Technical Report(DeepSeek, 2024-12)· 第 3.2 节:20/132 SM 专做通信 + 定制 PTX + 每 token ≤4 节点 + IB→NVLink 转发 + 有效带宽 160 GB/s
• GPUDirect RDMA 文档(NVIDIA)· 让网卡直接读写 GPU 显存、绕开 CPU 的机制

深 dive 资源(可选 · 想往下走再看)

• NVIDIA Hopper Architecture In-Depth(NVIDIA, 2022)· H100/H800 的 132 个 SM、NVSwitch 拓扑等硬件细节
• DeepEP(DeepSeek, 2025)· DeepSeek 开源的专家并行通信库,把本章 all-to-all + IBGDA 的优化做成了可读的真实代码
• Ring All-Reduce 图解(Horovod / Uber)· all-reduce 为什么等于 reduce-scatter + all-gather 的直观推演

说明:本章同样没有 Mode B 视频站 —— 集合通信与互联这类硬核系统主题,目前缺少合格的、人讲解的系统化教学长视频;深入的会议论文与 NVIDIA 官方文档在上方按需列出,由 Mode A 原创讲解扛主线。

下一章

下一章 Ch4 把我们带进第三站,也是这条路书真正的主脊:推理服务。前两章你学的是训练和推理共享的底层 —— 怎么把模型切开、切开后怎么协同;从这一章起,焦点转向「服务」。我们会把一次 LLM 推理请求彻底解剖开,看清它其实分成性格截然相反的两个阶段(并行处理整段提示的 prefill,和逐字往外蹦的 decode),看清那块叫 KV cache、会主宰显存的东西到底是什么,以及为什么 decode 阶段是被显存带宽卡住、而不是被算力卡住的。这是你真正开始理解「一个模型怎么被服务给亿万人」的起点。