分布式训练入门：DeepSpeed ZeRO2与FSDP对比分析-平芜编程栈

分布式训练入门：DeepSpeed ZeRO2与FSDP对比分析

在大模型时代，百亿甚至千亿参数的模型已成为常态。然而，这样的庞然大物一旦进入训练阶段，立刻暴露出一个根本性问题——显存不够用了。哪怕你手握多张A100，也可能在加载Llama3-70B时被OOM（内存溢出）拦腰截断。这已经不是“能不能跑起来”的问题，而是“怎么才能让它活下去”的生存挑战。

正是在这种背景下，分布式训练不再是一个可选项，而成了必修课。PyTorch原生的DDP（DistributedDataParallel）虽然能实现基本的数据并行，但每张卡都保存完整模型副本的设计，在面对大模型时显得力不从心。于是，两种更高级的解决方案浮出水面：DeepSpeed的ZeRO系列和PyTorch内置的FSDP。

它们都试图解决同一个核心矛盾：如何在有限的GPU资源下，塞进越来越大的模型？但走的路子却截然不同。本文将深入拆解这两种主流方案的技术内核，并结合ms-swift框架的实际应用，帮你搞清楚什么时候该用哪个。

显存瓶颈的本质：为什么一张卡装不下一个模型？

要理解这些优化技术的价值，得先算一笔账。以一个13B参数的Transformer模型为例：

参数本身（FP16）：13e9 × 2 bytes ≈26GB
梯度（FP16）：同样约26GB
Adam优化器状态（动量+方差，FP32）：13e9 × 4 × 2 ≈104GB

加起来就是接近156GB的显存需求——这还只是单卡！传统DDP模式下，每个GPU都要存这一整套数据，四张A100（每张80GB）也扛不住。

所以关键思路就出来了：别让每张卡都存全量数据，把冗余干掉。这就是ZeRO和FSDP共同的出发点，只不过执行方式大相径庭。

DeepSpeed ZeRO2：稳扎稳打的实用派

如果你是第一次尝试大规模模型训练，ZeRO2大概率是你最顺手的选择。它属于DeepSpeed提出的三阶段零冗余优化策略中的第二阶段，主打一个“降本增效但不过激”。

它的核心操作有三项：

优化器状态分片：Adam里的动量、方差这些状态不再每张卡全存，而是按rank切开，各管一段；
梯度分片：反向传播产生的梯度也是分着存，谁算的谁负责；
参数保留完整副本：重点来了——模型权重仍然在每张卡上保持完整。

这意味着什么？你在调试时依然可以随时打印某一层的权重，不需要跨设备拼接；前向传播也不需要额外通信去拉参数。这种设计牺牲了一部分显存节省空间（毕竟参数没分），换来的是极高的稳定性和易用性。

举个例子，在使用QLoRA微调Llama3-8B时，基础模型已经是int4量化过的了，再加上LoRA适配器注入。此时如果再上ZeRO3或FSDP对参数进行分片，反而可能因为频繁的AllGather引入额外开销。而ZeRO2只处理优化器状态和梯度，刚好够用又不至于太复杂，简直是黄金平衡点。

而且ms-swift对它的支持非常友好，只需一个JSON配置文件就能启用：

{ "zero_optimization": { "stage": 2, "offload_optimizer": { "device": "cpu" }, "overlap_comm": true, "contiguous_gradients": true }, "fp16": { "enabled": true } }

其中offload_optimizer是个杀手锏——把优化器状态卸载到CPU内存。哪怕你的GPU只有16GB显存，也能靠系统内存撑住训练过程。当然代价是速度会慢一些，但在资源受限场景下，活着最重要。

另一个细节是overlap_comm，即通信与计算重叠。现代GPU支持异步传输，当一部分梯度正在通过NCCL同步时，另一部分已经开始计算下一个op了。这个开关一开，吞吐量立马提升10%~20%，属于典型的“免费性能”。

FSDP：彻底分片的激进路线

如果说ZeRO2像个谨慎的老工程师，那FSDP更像是追求极致的极客。它是PyTorch官方推出的Fully Sharded Data Parallel机制，名字就很直白：“完全分片”。

它的口号是：一切皆可分。

不仅优化器状态和梯度要分，连模型参数本身也要被打散。每一层在前向传播时，只有需要用到的时候才通过AllGather把完整的权重拉回来，算完立即释放。反向传播同理，按需重建、动态管理。

这就带来了惊人的显存压缩效果。同样是上面那个13B模型，在FSDP + FP16 + CPU offload组合下，单卡显存占用可以从上百GB压到30GB以内。这意味着你可以在8卡A100服务器上跑通原本需要数十张卡的任务。

更重要的是，FSDP深度集成进了PyTorch生态。你可以放心大胆地用torch.compile()加速模型，配合autocast做混合精度，还能无缝接入gradient checkpointing来进一步降低激活值占用。这些都是生产级项目非常看重的能力。

在ms-swift中启用FSDP也很简单：

from torch.distributed.fsdp import FullyShardedDataParallel as FSDP trainer = Trainer( model=model, fsdp=["transformer"], # 对指定模块启用FSDP包装 fsdp_config={ "use_orig_params": True, # 避免_flat_param带来的兼容问题 "cpu_offload": CPUOffload(offload_params=True), "mixed_precision": None, }, )

这里有个关键参数叫use_orig_params=True，这是PyTorch 2.0之后才有的特性。早期版本为了效率会把所有参数 flatten 成一个大tensor，结果导致无法按原始module结构访问参数，给调试和兼容HuggingFace模型带来很大麻烦。现在这个问题基本解决了。

不过FSDP也不是没有缺点。由于每次前向都要AllGather，通信开销明显高于ZeRO2。如果你的网络带宽不足（比如万兆以太网而非InfiniBand），很容易陷入“算五分钟，传两分钟”的窘境。这时候就得靠BackwardPrefetch这类技巧来预取下一层参数，缓解等待时间。

实战选型指南：到底该用谁？

理论讲完，回到现实。我们到底该怎么选？

小模型（<13B）+ LoRA/QLoRA → 优先选 ZeRO2

这类任务通常目标明确：快速迭代、低成本微调。你可能只有一两张消费级卡，或者想在云上省钱。ZeRO2凭借其低通信成本、高稳定性、良好的调试体验，几乎是首选。

而且ms-swift已经封装好了全流程：从int4模型加载、LoRA注入、ZeRO2配置到最终权重合并导出，一条命令搞定。适合大多数开发者日常使用。

大模型（≥13B）+ 全参微调 → 上 FSDP

当你真的要 fine-tune Llama3-70B 或 Qwen-110B 的时候，ZeRO2就不够看了。即使参数不分片，仅优化器状态+梯度也有上百GB，普通集群根本撑不住。

这时必须上FSDP，配合torch.compile和activation checkpointing才有可能跑通。尤其是你在A100/H100集群上做长期训练项目，FSDP的扩展性和工程整合优势会越来越明显。

另外，FSDP对模型结构改动小，更适合纳入CI/CD流程。相比之下，DeepSpeed需要维护独立的JSON配置文件，容易成为运维盲点。

硬件条件决定下限

如果你是T4/V100 用户，显存紧张是常态，建议 ZeRO2 + CPU Offload 组合，求稳为主。
如果你有A100/H100 多机多卡 + InfiniBand，那就放开手脚上 FSDP，充分发挥硬件潜力。

ms-swift 如何简化这一切？

真正让这些技术落地的，是像ms-swift这样的统一训练平台。它把底层复杂的分布式逻辑封装成简洁接口：

# 使用ZeRO2 swift train --model_type llama3-8b --lora_rank 64 --deepspeed ds_z2_config.json # 使用FSDP swift train --model_type llama3-70b --parallel_method fsdp --fsdp_config fsdp_config.py

一句话切换后端，自动处理模型并行、数据加载、检查点保存等琐事。甚至连训练完成后LoRA权重的合并、模型上传魔搭社区的操作，都有对应工具链支持。

更重要的是，它允许自由组合各种技术：
- ZeRO2 + LoRA
- FSDP + QLoRA
- FSDP + DPO/PPO 强化学习

无论你是要做轻量微调、全参训练还是人类偏好对齐，都能找到合适的路径。