1. 这个专题到底在讲什么“十年十篇”这个系列很多人第一反应是年度盘点或者论文合集但《分布式技术在大模型训练和推理中的应用》放在这个框架下其实是把十年来分布式系统领域积累的工程范式重新放到大模型这个新场景里做一次系统性回炉。大模型不是突然冒出来的它的训练和推理之所以能跑起来底层靠的全是分布式计算那套老本事只不过规模、粒度、故障模型全变了。这篇内容的核心脉络可以浓缩成三个问题大模型训练为什么必须分布式分布式推理和训练的技术选型有什么本质区别以及十年沉淀下来的那些经典手段在今天还灵不灵。围绕这三个问题专题拆成了几个层次先是讲数据和模型并行怎么切、怎么合再讲通信拓扑和集群调度怎么兜住万卡规模的压力最后落到推理场景下的显存优化和延迟控制。如果你正在做大模型相关的工程落地或者想从系统层面理解大模型为什么这么“吃”分布式这篇内容基本把主干框架都覆盖到了。我自己的感觉是这个专题最适合两类人看。一类是已经有分布式系统基础、想快速迁移到大模型场景的工程师另一类是被各种大模型框架绕晕、想搞清楚底层原理的技术管理者。它不会手把手教你调某个框架的某个参数但能帮你把散落的知识点串成一张网知道遇到瓶颈时该往哪个方向查。2. 分布式技术在大模型训练里的核心价值2.1 单机算力见顶之后分布式是唯一出路先看一组最直观的数字。一个千亿参数的大模型光参数用FP16存储就要占用大约200GB显存这还不算梯度、优化器状态和中间激活值。即便是目前最强悍的单个加速卡显存容量也远远够不上这个量级。再加上训练过程中的前向计算、反向传播、梯度同步单卡连一个完整的小批次都塞不进去。这就是分布式训练最原始也最硬核的驱动力显存放不下算力不够堆。十年前做分布式训练大家面对的是百亿参数以下的模型分布式更多是“锦上添花”能加速当然好单机多卡也能凑合跑。但到了大模型时代分布式从可选变成了必选而且是万卡规模、月级别的持续运行。训练一个千亿模型哪怕集群利用率只掉几个百分点折算下来的算力成本都是天文数字所以这个专题把分布式放在大模型训练的第一顺位一点都不意外。2.2 数据并行、模型并行、流水线并行的分工逻辑分布式训练有三板斧数据并行、模型并行、流水线并行。很多人一开始容易混淆其实它们的切分维度完全不同。数据并行是每个计算节点都持有一份完整的模型副本只把训练数据切成多份分发给各节点每个节点算完自己的梯度之后再做一次全局梯度同步。它的优点是实现简单、扩展性好缺点是模型本身必须能塞进单卡显存。大模型时代纯数据并行几乎不存在因为它连最基础的显存门槛都过不了。模型并行解决的就是“模型放不下”的问题。它把模型参数按层或者按张量切分到多张卡上每张卡只负责一部分参数的计算。按层切分就是流水线并行按张量切分就是张量并行。流水线并行的特点是卡与卡之间只传递激活值通信量相对小张量并行则需要在每次前向和反向计算时做大量集合通信对网络带宽极其敏感。实际训练千亿模型时这三种并行不是互斥的而是混合使用。数据并行负责扩大整体吞吐张量并行负责拆解超大单层流水线并行负责把超深网络分层安置。专题里有一个非常实用的判断标准优先用显存占用大的并行策略解决容量问题再用通信开销小的策略解决扩展效率问题。2.3 混合并行策略的切分逻辑具体到工程落地怎么把这三种并行组合起来我自己实践下来比较通用的思路是四步走。第一步先评估单卡显存能容纳多大的模型分片。如果模型单层就超过单卡显存张量并行是首选因为它能把一个层的计算拆到多张卡上协同完成。第二步如果模型层数特别多引入流水线并行。把网络按层切成多个阶段每个阶段放几张卡卡之间串行执行但不同微批次可以交错流动避免流水线气泡过大。第三步在所有张量并行和流水线并行组之上叠加数据并行。数据并行的粒度是整个“模型副本组”每组内部处理不同的数据批次这样吞吐量可以随着卡数近似线性增长。第四步根据集群的拓扑结构调整并行策略的通信域。比如同一台物理机内部的卡走NVLink跨机走RDMA网络张量并行的通信域尽量收敛在机内数据并行的通信域可以跨机这是减少通信瓶颈的关键。这套逻辑看起来不复杂但实际调起来非常考验对集群拓扑的熟悉程度。专题里给了一个很形象的类比张量并行是“多人抬一块巨石”必须步调一致流水线并行是“工厂流水线”每个工位只管自己的工序数据并行是“多副本并行抄写”只要最后对一遍答案就行。这个类比我印象很深也推荐给刚接触分布式训练的同学。3. 分布式推理与训练的技术分野3.1 推理场景的显存瓶颈比训练更尖锐训练阶段可以接受高延迟因为目标是吞吐和收敛但推理阶段直接面向用户请求延迟是硬指标。大模型推理时的显存占用主要来自两部分一是模型参数本身二是KV Cache。KV Cache是推理过程中缓存历史注意力计算结果的数据结构序列越长、并发越高它占的显存就越大。一个几千亿参数的模型KV Cache甚至能占到总显存的一半以上。这就带来了一个训练场景不太会遇到的矛盾显存既要装模型又要装动态增长的KV Cache还得留出足够的计算空间。如果只是简单地把模型塞进去并发稍微一高KV Cache就会挤爆显存。所以分布式推理的第一要务不是加速计算而是把显存压力分散出去。3.2 张量并行在推理里的重新定位在训练场景张量并行是为了解决单层参数放不下的问题在推理场景张量并行更多地是为了摊薄KV Cache的存储压力。把同一个Transformer层切成多份每张卡只存自己负责的那个注意力头对应的KV Cache这样单卡显存压力大幅下降同时也能支持更长的上下文长度。但推理场景用张量并行有一个代价每次生成一个Token都需要在张量并行的多张卡之间做一次AllReduce同步。这意味着卡数越多单次Token生成的通信延迟越高。所以推理场景必须在“显存容量”和“通信延迟”之间做权衡。实际部署中张量并行度通常设为1、2、4、8这几个档位超过8之后通信开销会明显吃掉性能红利。3.3 推理引擎里的分布式调度策略大模型推理服务的主流架构是“调度器加推理引擎”的模式。调度器负责接收请求、排队、动态组Batch推理引擎负责真正的模型计算。分布式在这个环节主要体现在两个层面。一个层面是请求级别的分布式。多个推理实例组成一个服务集群前端负载均衡把请求分发给不同实例。这个层面相对简单本质上和传统微服务的水平扩展没有区别只要模型能完整放进单机显存就可以用这种方式横向扩容。另一个层面是模型级别的分布式。当单机放不下模型或者单机推理延迟不达标时同一个模型会跨多张卡部署推理引擎内部用张量并行或流水线并行来协同计算。这也是目前大模型服务的主流形态。更进阶的做法是分离式部署把Prefill阶段和Decode阶段拆到不同的计算节点上执行。Prefill阶段计算密集、需要高吞吐Decode阶段访存密集、需要低延迟两者对硬件资源的需求曲线完全不同。通过分布式调度把两个阶段分开可以让各自资源利用率都更高。这种架构实现复杂度高但已经是头部推理系统在走的方向。4. 通信拓扑与集群调度容易被忽视的隐形瓶颈4.1 集合通信是大模型分布式的中枢神经无论训练还是推理分布式系统都依赖节点间的集合通信原语最常见的包括AllReduce、AllGather、ReduceScatter。训练时每步都要同步梯度推理时张量并行每生成一个Token都要同步中间结果。通信效率直接决定集群利用率这是大模型分布式和传统分布式最大的不同点之一。举个例子AllReduce是数据并行里同步梯度的核心操作它的实现方式从最早的Reduce加Broadcast两步式演化到Ring AllReduce再到Tree AllReduce和分层AllReduce。Ring AllReduce的核心思想是把所有节点组织成一个环让数据沿环流动每个节点只和自己的邻居通信从而把通信量从O(N)降到O(N)数量级下的常数项优化。今天主流框架默认使用的NCCL底层就是对这些算法的工程实现。专题里特别点出了一个关键结论通信拓扑决定扩展上限。如果集群的叶脊网络带宽不足或者机架之间的收敛比过高那么无论并行策略设计得多完美实际训练效率都会被通信拖垮。这也是为什么大模型集群建设特别强调高速网络因为大模型训练本质上是一个“通信密集型”任务。4.2 故障恢复万卡集群的日常必修课单机训练遇到故障重启就行万卡集群训练每时每刻都有硬件故障的概率。大规模训练任务如果不做容错设计一个节点宕机就可能导致整个训练任务回到数小时之前损失不可接受。所以分布式训练框架普遍引入了周期性的Checkpoint机制定期把模型状态保存到持久化存储。但Checkpoint也是一把双刃剑。状态保存得越频繁故障恢复的损失越小但保存本身会打断训练流程、占用大量磁盘IO和网络带宽。实际项目中Checkpoint频率通常在“故障恢复时间”和“保存开销”之间折中。比较常见的做法是异步Checkpoint把状态保存操作放到后台线程执行减少对训练主流程的影响。除了周期性保存现在更前沿的做法是弹性训练。集群中某个节点挂了调度器自动把任务重新调度到空闲节点上训练任务不会整体重启而是只重建丢失的那部分状态继续跑。这种弹性能力在云原生环境下容易实现但在物理机集群里仍然依赖调度器对节点状态的精确感知。4.3 调度系统如何分配异构资源大模型训练集群通常不是完全同构的。不同年代的加速卡混用、不同机型混部都是常态。调度系统需要感知每张卡的显存容量、计算能力、网络位置然后根据训练任务的并行策略把合适的卡组合分配给合适的任务。这里有一个经常踩坑的地方单纯按卡数分配资源是不够的。张量并行要求组内卡之间的通信延迟尽量低如果调度器把同一个张量并行组的卡分散在不同机架上训练性能会急剧恶化。所以主流调度器都会支持拓扑感知调度尽量把一个并行组分配到同一台物理机或同一个接入交换机下。专题里还提到了一组经验数据可供参考当集群规模超过一千张卡时调度系统本身的可靠性就会成为新的瓶颈。调度器挂了整个集群的训练任务都会停摆。因此生产环境通常会给调度器做主备部署同时把调度决策做成可重放的事件日志方便故障后的状态恢复。5. 工程落地的关键技术清单5.1 框架选型从Megatron-LM到主流分布式中间件眼下大模型分布式训练和推理工程上绕不开的框架主要有几类。一类是Megatron-LM这类专注模型并行原语的框架它对张量并行、流水线并行、序列并行的支持非常底层和精细适合研究机构和有深度定制能力的技术团队。另一类是更上层的分布式中间件把并行策略封装成API开发者只需要描述模型结构框架自动决定怎么切分、怎么通信大幅降低上手成本。推理侧的框架选择逻辑又不太一样。推理框架更强调延迟控制、动态Batch、KV Cache管理和连续批处理等能力和训练框架关注点差异很大。选型时不要盲目追求功能最全的框架而要看它在你实际部署的硬件和网络环境下能否稳定发挥出预期性能。我个人在选型时有一个习惯先写一个最小化验证脚本在目标集群上分别跑一遍纯数据并行的小模型训练、单卡推理、多卡张量并行推理对比吞吐和延迟再用真实模型做扩缩测试。框架的文档写得再好都不如这一轮实测来得直接。5.2 显存优化三件套重计算、混合精度、内存碎片治理大模型训练和推理的显存优化绕不开三个手段。重计算Activation Checkpointing的核心是“用算力换显存”前向传播时丢弃中间激活值反向传播需要时再重新计算一遍。代价是增加了约30%的计算量但可以减少数倍显存占用。在模型规模大、显存吃紧的训练场景重计算几乎是必开选项。混合精度Mixed Precision是利用FP16或BF16的存储和计算效率配合FP32的Master Weight来保证收敛精度。BF16因为动态范围和FP32一致在大模型训练中比FP16更受欢迎。这一项技术本身不复杂但实际使用中经常出问题的是梯度溢出和损失震荡需要搭配动态损失缩放或梯度裁剪来稳定训练。显存碎片治理是推理场景特有的难题。训练时显存分配模式相对固定碎片问题不明显推理时KV Cache动态增长、请求并发波动、批大小变化都会造成显存碎片。处理手段包括显存池化、KV Cache分页管理以及按请求大小动态分配块。这些细节直接影响推理服务的并发上限是性能调优的必争之地。5.3 性能调优的经验指标我在实操中积累了几个比较核心的性能指标供参考。第一个是模型浮点利用率MFU它衡量的是模型实际计算吞吐与硬件理论峰值之比。训练千亿模型时MFU能到45%到55%就算相当不错低于30%基本说明并行策略或通信配置出了问题。第二个是训练稳定性也就是训练过程中Loss是否出现异常波动。Loss突然飙升往往不是模型问题而是通信超时、某个节点降频或者数据加载抖动。第三个是推理场景的TTFTTime To First Token和ITLInter-Token Latency。TTFT决定了用户首字响应速度ITL决定了生成过程的流畅度两者分别对应算力瓶颈和显存带宽瓶颈。调优时不要只看单一指标要结合并行策略、网络拓扑、显存占用一起看。最典型的例子张量并行度提高后TFLOPS可能上升但ITL因为通信开销增加而恶化这时候就需要在“吞吐”和“延迟”之间重新找平衡点。6. 实践中的常见问题与排查思路6.1 训练效率上不去时先查通信再查计算遇到训练性能不达标我的排查顺序固定是“通信优先于计算”。先用性能分析工具看集合通信耗时占比如果通信占比超过30%优先优化并行组的通信域配置。常见问题是并行组跨了机架、网络收敛比过高、NCCL使用的网络接口和实际业务网络不一致。这些问题的修复成本很低但对性能的影响非常大。通信没问题再看计算侧。这时候要看每一步的计算时间是否均匀如果某些节点明显慢于其他节点大概率是硬件降频、散热问题或者被其他任务抢占资源。训练集群出现“木桶效应”的时候最快的优化手段反而是把最慢的节点摘除而不是整体降速迁就它。6.2 推理延迟抖动不全是模型的错推理服务延迟抖动很多人第一反应是模型推理引擎调参不够但实际排查下来根因经常在网络或调度层。比如请求经过负载均衡转发时如果长尾请求被分配到已经过载的实例就可能拖慢整体延迟。这时需要给负载均衡加“最小连接数”或者“最少活跃请求数”的策略而不是简单轮询。另一个隐蔽问题是显存碎片导致的OOM。服务跑一段时间之后明明总显存还有富余却分配不出连续显存块。这种问题靠重启服务只能临时解决根治方案是给KV Cache使用分页管理或者定期整理显存池。我建议线上推理服务一定要配置告警同时保留最近半小时的显存快照方便OOM之后快速定位。6.3 分布式任务的排错日志怎么看分布式任务日志量巨大出错时如果漫无目的地翻日志效率极低。我的习惯是先看任务级日志确认是哪个阶段失败再定位到具体节点再查该节点上的通信库日志和内核日志。大部分分布式训练失败要么是某个节点心跳超时要么是通信库报错要么是存储IO卡住。还有一个小技巧在跑大规模任务之前先在小规模集群上做一次完整演练记录正常的日志格式和关键指标基线。这样等大任务出问题时就能通过对比快速发现异常点。很多看起来玄学的问题最后发现只是环境变量配置不一致或者某台机器时间不同步。7. 十年沉淀给我留下的几个启示分布式技术在大模型训练和推理中的应用本质上不是新造轮子而是把十年前已经成型的并行计算、通信调度、容错恢复等基础能力放到新的规模层级上重新打磨。这个专题真正有价值的地方在于它没有堆砌框架名和参数而是把“为什么需要分布式”和“分布式到底解决了什么”讲透了。我在实践中的体会是分布式系统的核心难点从来不是某个算法的复杂度而是工程落地时各种因素交织在一起的耦合问题。显存不够、通信太慢、节点不稳定这些问题单独看都有成熟解法但当它们同时出现时就需要从系统层面做全局权衡。这也是为什么专题最后落脚在工程经验上而不是算法原理上。如果你正准备进入这个方向我的建议是先把手上的小模型分布式训练跑通再把并行策略一个一个加上去观察每个策略带来的收益和代价。不要一开始就追求万卡规模先把千卡规模下的通信与调度逻辑吃透大集群的坑很多在小集群里就已经埋下种子了。