DeepSpeed集成前必须确认三件事：CUDA可用且驱动≥525.60.13；模型已封装为torch.nn.Module；训练循环未手动调用.to(device)或.cuda()，否则张量跨设备错误。
DeepSpeed集成前必须确认的三件事
不装DeepSpeed就直接改代码，大概率白忙活。它不是“加个装饰器就能省显存”的轻量工具，而是要重走训练流程的系统级改造。
先检查这三项是否全部满足：
-
torch.cuda.is_available()返回True，且驱动版本 ≥ 525.60.13（DeepSpeed v0.14+ 强制要求） - 模型已用
torch.nn.Module封装，不能是裸函数或动态exec构建的结构 - 训练循环中没有手动调用
.to(device)或.cuda()—— DeepSpeed 会接管设备分配，混用会导致张量跨设备错误
zero_stage=1/2/3 的真实差异和选型依据
很多人以为 stage 越高越省显存，其实 stage=3 在单卡上反而可能更耗显存，因为通信缓冲区开销压过了参数分片收益。
按实际场景选：
立即学习“Python免费学习笔记（深入）”；
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 单卡微调 7B 模型 → 用
zero_stage=1：只做梯度分片，启动快、调试稳，显存降约 25% - 单卡训 13B 或 2×A100 微调 72B → 选
zero_stage=2：梯度 + 优化器状态分片，显存再降 30%~40%，但需注意all-gather临时显存峰值 - 8×A100 全量微调 72B → 才考虑
zero_stage=3：参数、梯度、优化器全分片，但必须配offload_optimizer或offload_param，否则 CPU-GPU 频繁搬运反而拖慢 3 倍以上
容易被忽略的 deepspeed_config.json 关键字段
官方示例里一堆注释掉的配置项，但以下三个不显式写死，DeepSpeed 就不会按你预期工作：
-
"train_micro_batch_size_per_gpu": 1—— 不是 batch size，是每个 GPU 上每次 forward 的样本数；设错会导致OOM或梯度累积失效 -
"gradient_accumulation_steps": 8—— 和 PyTorch 原生的grad_acc行为不同：DeepSpeed 在 accumulation 阶段不释放激活值，所以显存占用≈单步 × 1.2，不是线性叠加 -
"fp16": {"enabled": true, "loss_scale": 0}——loss_scale=0表示启用动态缩放；若写成固定值（如 1024），在长序列训练中极易因梯度下溢中断
漏掉任一字段，deepspeed.initialize() 可能静默回退到基础模式，你以为开了 zero-3，其实只是 zero-1。
模型加载阶段的显存陷阱
DeepSpeed 的 engine.module 是包装后的模型，但很多人还在用原始方式加载权重：
- 错：用
torch.load(..., map_location="cpu")后.load_state_dict()→ 权重全进 CPU 内存，再被 DeepSpeed 分片搬运，触发多次显存暴涨 - 对：用
engine.load_checkpoint("ckpt_dir", load_module_only=True)→ 权重直通分片逻辑，跳过 CPU 中转 - 特别注意：如果 checkpoint 是 HuggingFace 格式（含
pytorch_model.bin），必须先用from_pretrained(..., device_map="auto")加载到 CPU，再传给 DeepSpeed；直接torch.load(..., map_location="cuda")会绕过分片，显存瞬间打满
最隐蔽的问题是：哪怕你所有配置都对，只要 checkpoint 里有未参与训练的 buffer（比如 model.rotary_emb.inv_freq），DeepSpeed 默认也会把它分片 —— 这部分显存不计入 profile 报告，但真实存在。解决方法是在 deepspeed_config.json 里加 "ignored_parameters": ["rotary_emb.*"]。
