简介：面对大模型训练中的显存不足与训练缓慢问题，分布式训练成为关键解法。本文将围绕分布式数据并行与分片优化器两种核心方案，从架构、显存占用、通信开销、实现复杂度等维度进行系统对比，帮助读者理解两者在“用多卡分担计算”与“用多卡分担存储”上的本质差异，以及在不同资源条件下如何组合选型。
在大型语言模型的训练过程中，单设备方案通常会遇到两个相互叠加的瓶颈。
第一是显存瓶颈。模型参数、梯度、优化器状态和前向激活值都需要驻留在显存中。以混合精度训练为例，参数本身、对应梯度和 Adam 类优化器维护的一阶与二阶动量，会共同形成数倍于参数量的显存需求。当模型规模上升到数十亿参数时，仅优化器状态就可能占用数十 GB 显存，单卡往往无法容纳。
第二是算力瓶颈。即使模型能够装入单卡，海量训练样本的前向计算、反向传播和参数更新也会让单卡吞吐接近上限。训练周期从几天拉长到数周甚至更久，直接拖慢迭代节奏。
因此，分布式训练不是可选项，而是让大模型训练进入可行区间的必要条件。当前最常被讨论的两类方案，分别是从数据维度切分的分布式数据并行，以及从模型状态维度切分的分片优化器。两者解决的核心问题并不完全相同，理解这个差异是做好选型的前提。
分布式数据并行，下文简称数据并行，其核心思想是将一个小批次数据继续切分成若干微批次，分发给不同计算设备。每个设备上保存一份完整模型副本，独立完成前向和反向计算，得到各自的局部梯度。随后所有设备通过通信操作对梯度做聚合平均，再使用相同结果更新本地参数。
可以把它理解成多名厨师各自拥有一套完整厨房，菜单相同，只是每人负责一部分食材。最终通过合并各自的烹饪结果，保证所有厨房端出的菜品一致。
分片优化器并不对输入数据做切分，而是对训练过程中的模型状态做切分。模型状态通常包括参数、梯度和优化器状态。每个设备只保存其中一片，计算时按需临时汇聚，计算完成后释放不必要的数据。
更直观的类比是，多名厨师共享一个大型中央厨房。每个厨师只负责保管一部分调料和食材，烹饪某道菜时需要临时向其他厨师借用材料，用完后归还。厨房总面积没有减少，但每个厨师实际占用的储物空间大幅下降。
虽然切入角度不同，但数据并行与分片优化器在目标层面高度一致。
首先，两者都试图通过增加设备数量突破单卡限制。其次，两者都遵循“计算本地化、必要信息全局化”的基本逻辑：大部分计算在本地完成，只有部分状态或梯度需要跨卡协调。最后，两者在训练语义上都目标接近单卡训练，即在增加资源的同时尽量保持模型收敛行为不发生明显变化。
数据并行不会降低单卡模型状态占用。每张卡仍然保存完整的参数、梯度和优化器状态，因此单卡显存压力并未消失。它主要缓解的是算力瓶颈，而不是显存瓶颈。
分片优化器则直接削减单卡模型状态。参数、梯度和优化器状态被分散到不同设备，单卡只保留一片。激活值仍然需要完整保存，因此显存占用下降主要来自优化器状态、梯度和参数部分的释放，并非所有显存都会按设备数量线性下降。
数据并行的核心通信发生在反向传播完成之后。各卡需要对梯度做全局归约，常见的实现方式是环形通信或参数服务器聚合。通信量与模型参数规模成正比，与数据批次大小关系较弱。
分片优化器的通信则发生在计算过程中。当某张卡需要用到不属于本地的参数分片时，必须临时从其他设备获取；当参数更新完成后再分发回对应分片的持有者。其通信模式更频繁但单次数据量更小，具体开销取决于分片策略和计算调度方式。
实现一个基础版数据并行，核心在于处理梯度同步。理解通信原语、保证不同设备间的梯度一致性、避免死锁，是主要难点。
实现分片优化器则更复杂。除了梯度同步，还需要设计分片映射关系，决定参数、梯度和优化器状态分别落在哪些设备上；需要管理临时重建与释放逻辑；还需要处理不同分片之间的数据依赖。从工程实现角度看，分片优化器的状态管理和边界情况明显多于数据并行。
数据并行在梯度同步阶段对通信带宽要求较高，但因为同步集中，通信模式相对规律。分片优化器由于通信嵌入计算过程，对通信延迟更敏感。跨节点的低带宽环境可能显著拉长分片优化器的单步时间，因此在实际部署中，分片优化器更适合节点内高速互联场景，数据并行则相对更容易扩展到多节点。
| 对比维度 | 分布式数据并行 | 分片优化器 |
|---|---|---|
| 核心切分对象 | 数据批次 | 模型参数、梯度、优化器状态 |
| 单卡是否保留完整模型 | 是 | 否，仅保留部分分片 |
| 主要缓解问题 | 训练速度慢、算力不足 | 显存不足、模型状态过大 |
| 单卡显存占用 | 与单卡训练相当，未降低 | 显著降低，尤其优化器状态 |
| 通信发生时机 | 反向传播后的梯度归约阶段 | 计算过程中按需获取分片 |
| 通信量特征 | 集中且较大 | 分散且频繁 |
| 对通信延迟敏感度 | 中等，受带宽影响较大 | 较高，跨节点性能波动更明显 |
| 实现复杂度 | 中等 | 较高 |
| 典型适用条件 | 单卡能放下模型但训练慢 | 单卡无法容纳完整模型状态 |
如果单卡能够容纳完整模型和优化器状态，只是训练太慢，数据并行是最直接的方案。它代码改造相对较少，训练行为接近单卡，调试成本较低。
如果单卡连优化器状态都放不下，数据并行解决不了问题。这时需要引入分片优化器来降低单卡模型状态占用，才能让训练启动。
当模型规模继续扩大，即使引入分片优化器，单卡激活值仍然可能成为瓶颈。此时还需要结合激活检查点等技术，用计算换显存。选择方案时不能只看模型参数是否放下，而应完整评估参数、梯度、优化器状态和前向激活值的整体占用。
在实际大模型训练中，数据并行和分片优化器通常不是二选一。常见做法是先通过分片优化器将单卡模型状态压到可接受范围，再在多个设备组之间做数据并行，让训练吞吐随设备数量近似线性提升。理解两者各自解决的问题，才能合理组合。
如果团队处于早期验证阶段，模型规模暂时可控，优先选择实现更简单的数据并行。它的语义更接近单卡训练，排查问题更直观，可以让团队快速跑通流程。
如果模型规模已经明确超出单卡显存，且短期内无法更换更高显存设备，应提前设计分片优化器的引入路径。实现时建议从优化器状态分片入手，因为这部分在显存中占比通常最高，收益明显。
如果训练环境跨节点较多，需要重点评估通信延迟对分片优化器的影响。在条件允许时，尽量将使用同一组分片的设备调度到同一高速互联域内，减少跨节点状态交换。
从单卡训练迁移到数据并行时，需要重点检查数据加载的划分方式、随机种子的设置以及梯度同步的初始化时机。不同设备上的批归一化或退化层行为可能存在差异，需要根据模型结构做适配。
从数据并行进一步引入分片优化器时，模型状态管理方式和检查点保存格式都会发生变化。原有的模型保存与恢复逻辑通常无法直接复用，需要重新设计分片状态的合并与拆分流程。建议在方案切换前明确检查点格式的兼容性，避免训练中断后无法恢复。
监控层面，除了传统的吞吐和显存占用外，还应关注通信耗时在单步训练中的占比。如果通信占比持续偏高，需要调整分片大小、并行度或设备拓扑，而不是简单增加卡数。
数据并行和分片优化器解决的不是同一个问题：前者主要用多卡并行处理更多数据，后者主要用多卡分担更大的模型状态。前者实现简单、训练语义更贴近单卡，但不降低单卡显存占用；后者显存收益明显，却带来更频繁的通信和更高的工程复杂度。
是否选择分片优化器，取决于模型是否超出单卡承载能力；是否选择数据并行，取决于是否需要在承载能力范围内继续提升训练速度。两者在不同条件下各有其不可替代的位置，综合使用才是大模型训练走向更大规模的真实路径。