这两年做大模型训练MoE 架构的讨论热度一直很高但真正下手训练过 MoE 模型的人多少都经历过显存爆炸、通信卡死、负载失衡之类的“折磨”。我自己在训练稀疏模型的时候从最初的 Dense 模型迁移到 MoE第一次跑起来就差点被显存搞崩溃。后来把 DeepSpeed 的 ZeRO-3 彻底吃透才算把 MoE 训练这摊子事理顺。这篇东西就是把我踩过的坑、试对的路子以及 ZeRO-3 在 MoE 场景下到底怎么工作的一次性讲清楚。先说结论MoE 架构不需要把全部参数塞进显存。ZeRO-3 的分区策略就是把参数、梯度、优化器状态统统切成碎片分散到各个 GPU 上谁用谁取。这个机制配上 MoE 的稀疏激活特性恰好能解决大规模专家网络带来的显存墙问题。下面我把原理、配置、实操和排障一条条拆开讲适合那些准备把模型从 Dense 往 MoE 迁移或者已经在 MoE 训练里挣扎的工程师参考。1. 整体设计思路为什么 ZeRO-3 天生适合 MoE 训练1.1 MoE 到底在解决什么问题又引入了什么麻烦MoE 的核心逻辑很简单把一个大模型拆成若干“专家”子网络每次推理时只激活其中一小部分专家而不是让所有参数都参与计算。这听起来很省算力但真正实现起来问题就来了。拿一个常见的 MoE 模型举例。假设有 64 个专家每个专家是 2 层 MLP每层隐层维度 4096单专家参数量大概在 3000 万到 5000 万左右。64 个专家加起来就是 20 亿到 30 亿参数再加上共享的注意力层和嵌入层总体参数量轻松突破 30 亿。如果用传统的 Dense 训练方式这 30 亿参数都得放进显存加上梯度、优化器状态单卡 80GB 根本扛不住——这是 MoE 带来的第一个麻烦存储开销大。第二个麻烦来自动态路由。每个 token 经过门控网络时会被分派到不同的专家专家负载天然不均衡。有的专家被频繁选中有的专家几乎没人理。负载不均衡不仅浪费算力还会让部分 GPU 的通信量暴涨形成热点。我见过一个 16 卡训练任务因为负载严重倾斜某个 GPU 的利用率冲到 95%旁边的 GPU 却趴在 20% 附近整个训练效率被拖垮。第三个麻烦是通信开销。token 被分派到不同专家后数据不得不在各个 GPU 之间传输这个操作叫 All-to-All。专家越多、分布越散通信量就越大。通信和计算如果不重叠好训练吞吐量会因为等待而大幅下降。1.2 ZeRO-3 的分区哲学把“装不下”变成“分得开”Dense 模型训练时显存占用主要来自三块模型参数、梯度、优化器状态。ZeRO-3 的思路不是像流水线并行那样把层切开也不是像张量并行那样把矩阵切开而是把这三样东西全部做横向切分让每个 GPU 只保存完整状态的 1/N。用生活化一点的话说传统 Dense 训练相当于一个人管一整栋楼的钥匙所有钥匙都得揣在自己兜里。ZeRO-3 相当于把楼拆成 N 个区每个 GPU 只拿自己那个区的钥匙需要用哪个区的钥匙时再临时找对应的同事要。用完即还不长期霸占。这一招对 MoE 尤其关键。因为 MoE 的专家层天然是“谁激活谁干活”那些没被激活的专家参数在传统数据并行下也得驻留在显存里白白占空间。而 ZeRO-3 把专家参数分区后每个 GPU 只留一部分专家的参数被激活的专家才需要跨卡 gather 全量参数进行计算。稀疏激活 参数分区两件事叠加起来显存需求直线下降。有一些人问MoE 架构要全部参数进显存吗答案是不需要也不应该。MoE 的价值就在于稀疏激活如果你把全部专家参数都塞进每个 GPU那和 Dense 模型有什么区别显存照样爆炸通信照样疯狂。正确姿势就是用 ZeRO-3 把参数分出去配合路由机制按需拉取。1.3 为什么选 DeepSpeed 而不是其他方案市面上能做 MoE 训练的框架不止 DeepSpeed 一家比如 HuggingFace Accelerate、FairScale、Megatron 也都有各自的手段。但我个人在实践中的体感是DeepSpeed 在 MoE 训练这条路上走得最系统。一是 DeepSpeed 的 ZeRO-3 不仅可以分区 Dense 层的参数还提供了一套统一的 MoE 支持逻辑。从 DeepSpeed 1.0 开始PyTorch 的 MoE 层可以配合 ZeRO-3 一起工作不需要自己手写分布式通信原语。二是 DeepSpeed 提供了专门的负载均衡损失aux loss工具和 All-to-All 调度优化。MoE 训练最头疼的负载均衡问题DeepSpeed 在框架层就帮你设计好了接口不需要自己从零造轮子。三是 DeepSpeed 的训练引擎engine把数据并行、ZeRO 分区、混合精度、梯度累积都封装在了一起。配置好了之后训练脚本的改造成本很低。我之前用原生 PyTorch 写 MoE 训练通信逻辑自己写Bug 一堆换到 DeepSpeed删掉几百行手动通信代码瞬间清爽。2. ZeRO-3 核心机制拆解参数分区与通信细节2.1 ZeRO-1、ZeRO-2、ZeRO-3 的演进关系很多资料喜欢把 ZeRO 三个阶段混在一起讲但实际上它们的优化深度差得很远。我在这里做个清晰的对比优化阶段分区内容显存节省效果通信开销ZeRO-1只分区优化器状态约 4 倍几乎无额外通信ZeRO-2优化器状态 梯度约 8 倍通信量较小ZeRO-3优化器状态 梯度 模型参数与 GPU 数成正比通信开销显著增加为什么 ZeRO-1 和 ZeRO-2 在 MoE 场景下不够用因为 MoE 的参数量大头在专家参数上而 ZeRO-1 不分区参数专家的全部参数仍然要在每个 GPU 上驻留。ZeRO-2 虽然把梯度分区了但前向传播时参数还是得全量存在。只有 ZeRO-3 把参数本身也分掉了才会真正影响“参数是否全部进显存”这个问题的答案。但 ZeRO-3 不是没有代价。参数既然分到了各个 GPU前向计算时就需要临时把参数 gather 回来。每层 forward 之前得做一次 all-gatherbackward 之后还得做一次 reduce-scatter。这个通信量比 ZeRO-1、ZeRO-2 大得多。通信和计算如果不能重叠好训练吞吐量会因此下降。所以 MoE ZeRO-3 的调优核心之一就是想办法把通信压在计算后面。2.2 前向传播中的 all-gather 与参数生命周期理解 ZeRO-3 的前向过程是掌握它的关键。假设我们有 8 卡模型里有一个 MoE 层包含 64 个专家每个 GPU 分区持有 64 个专家的 1/8 参数也就是每卡实际只存了 8 个专家的权重。前向传播时门控网络输出每个 token 的专家分配结果。某个 GPU 发现自己需要专家 3、专家 17、专家 42 的参数但这些参数分散在其他 GPU 上。ZeRO-3 在计算专家 3 前触发一次 all-gather把专家 3 的完整参数从持有它的那张卡广播到所有相关卡。计算完成后立即释放临时 gather 出来的参数内存。这里有个容易忽略的细节参数的临时全量副本是放在“计算用”的内存池里不是常驻内存。ZeRO-3 内部有一个内存缓存机制专门管理临时 gather 出来的参数。如果缓存没设置好频繁的 gather 会导致内存碎片和频繁分配释放训练速度大打折扣。我调 ZeRO-3 配置时的经验是zero_optimization里的reduce_bucket_size和stage3_prefetch_bucket_size这两个参数对通信微调很重要。stage3_prefetch_bucket_size控制预取参数桶的大小调大一点可以让参数提前开始传输减少等待。我在 8 卡 A100 上把预取桶从默认的 5e7 调到 2e8训练 step time 缩短了大约 15%。2.3 后向传播中的 reduce-scatter 与梯度累积反向传播的逻辑跟前向是对称的。每个 GPU 算出一部分梯度之后因为梯度也要分区存储所以得做一次 reduce-scatter把梯度汇总起来再切分每个 GPU 只保留属于自己的那 1/N。这里有一个我在实际训练中踩过的坑梯度累积的交互。如果开了梯度累积gradient accumulationZeRO-3 并不是每个 micro step 都做完整的 reduce-scatter。它是先累积局部梯度等累积次数到了再做一次完整的 reduce-scatter。这个逻辑本身是合理的但如果 micro batch size 太小而梯度累积步数又很大会导致通信批量化不足GPU 在累积阶段有一半时间是闲置的。我一般建议 micro batch size 不要小于 2梯度累积步数在 4 到 8 之间比较平衡。另外要特别注意gradient_accumulation_dtype。早期版本默认用 FP32 累积梯度后来有些版本改成 BF16如果你的 loss 曲线出现奇怪的抖动检查一下这个配置是不是被隐式改了。我遇到过一次 loss 异常波动排查半天最后发现是框架配置里梯度累积用了 BF16精度不足导致。2.4 ZeRO-3 的 CPU offload 与 MoE 的兼容性ZeRO-3 有一个重要扩展能力把参数或者优化器状态 offload 到 CPU 内存。这在单机多卡显存不够时很管用尤其是消费级显卡总量不大又想要跑大模型。但 MoE 训练时CPU offload 要慎用。因为 MoE 的参数使用是稀疏的gather 已经很频繁了如果参数再从 CPU 和 GPU 之间来回搬运通信开销会翻倍。我在 4 卡 RTX 4090 上试过开启offload_param跑 30B 的 MoE 模型结果一个 step 的时间从 3 秒直接涨到 40 秒基本没法训练。如果你真的显存不够还想训 MoE我更建议先砍专家数量或减小专家隐层维度而不是依赖 CPU offload。模型小一点训练快一点迭代效率反而高。等到正式大规模训练时再上多卡集群。3. MoE 训练实操要点从配置到负载均衡3.1 DeepSpeed 配置文件核心参数逐个拆解DeepSpeed 用 JSON 配置文件来控制训练引擎。我用过一个比较顺手的 MoE 训练配置核心部分长这样{ train_batch_size: 32, gradient_accumulation_steps: 4, train_micro_batch_size_per_gpu: 1, zero_optimization: { stage: 3, reduce_bucket_size: 5e8, stage3_prefetch_bucket_size: 5e8, stage3_param_persistence_threshold: 1e6 }, fp16: { enabled: true, auto_cast: true, loss_scale: 0 }, communication_data_type: fp16 }逐个说一下关键参数train_micro_batch_size_per_gpu设为 1意味着每个 GPU 每次只处理 1 个样本。配合 4 步梯度累积实际上每 4 个 step 做一次参数更新。这样做的原因是 MoE 的 All-to-All 通信会随 batch size 增大而放大micro batch 太大容易卡在通信上。但 micro batch 太小又会导致梯度噪声大所以累积步数必须配合。stage3_param_persistence_threshold这个参数很多人没注意到。它控制那些参数量小于阈值的参数不分区直接常驻在每张卡上。比如 embedding 层的参数如果很小可以设成常驻避免每次用的时候还要 gather。这个值设得太大会损失 ZeRO-3 的省显存效果设得太小embedding 和 layer norm 这类小参数也会频繁触发通信。我通常设在 1e5 到 1e6 之间。3.2 MoE 层的实现与 DeepSpeed 的 MoE 接口DeepSpeed 提供了两层抽象一层是DeepSpeedMoE可以直接替换普通的 MLP 层另一层是更底层的MoE模块可以自定义 top-k 路由逻辑。我自己的经验是先用 DeepSpeed 提供的现成 MoE 层跑通流程再考虑自定义不要一上来就自己写路由逻辑。一个最简单的 DeepSpeed MoE 配置from deepspeed.moe.layer import MoE moe_layer MoE( hidden_size4096, expertExpertModule, num_experts64, top_k2, use_residualTrue, capacity_factor1.25, eval_capacity_factor2.0 )这里capacity_factor是专家容量的缩放因子。它控制每个专家最多能处理多少个 token。设成 1.25 意味着专家容量比理论负载多 25%这样即使路由分布有点偏也不会因为某个专家被打满而丢弃 token。但注意这个值设得越大计算浪费越多不是越大越好。为什么需要用这个接口而不是自己写的路由因为 DeepSpeed 的 MoE 层内部已经做了 All-to-All 的优化以及辅助损失aux loss的记录。自己写路由逻辑这些坑全得自己踩。像我早期有一个版本的自定义路由在 2 卡上跑好好的扩到 8 卡之后梯度聚合逻辑出错loss 直接变成 NaN排查了一整天才发现是跨卡 token 统计的方式不对。3.3 负载均衡MoE 训练的命门MoE 训练的负载均衡问题通俗点说就是门控网络容易“偏心”。某些专家持续被选中另一些专家则被冷落。这会导致两类问题一是训练效果差。被冷落的专家几乎没有梯度更新形同虚设模型整体参数量虽然上去了但有效容量并不高。二是分布式效率差。token 分布不均不同 GPU 之间的计算量差异很大有的卡忙死有的卡闲死整体训练吞吐量被拖累。传统做法是加一个 aux loss用来惩罚负载不均匀。DeepSpeed 里可以这样开moe_layer MoE( ..., use_load_balancingTrue, load_balance_loss_weight0.01 )load_balance_loss_weight的取值非常微妙。设得太小负载均衡不起来设得太大模型会牺牲原生能力去迎合均衡loss 曲线可能变得“平滑但降不动”。我实测的经验是 0.005 到 0.02 之间比较稳。具体怎么判断看训练时的 aux loss 数值如果它一直很大比如超过模型主 loss 的 10%说明均衡惩罚太强需要调小。还有一个更进阶的做法是专家容量控制expert capacity。当一个专家被分配的 token 超过容量时超出的 token 会被丢弃或者走残差路径跳过这个 MoE 层。这本质上是在强制均衡。这个策略我用下来觉得适合训练初期但到了后期模型逐渐收敛时严格容量控制反而会限制模型的学习能力。我一般前 20% 的训练进度开强容量控制后面逐步放宽。3.4 增量训练与 LoRA 的配合如果你的场景是从已有模型基础上继续训练 MoE 或微调比如热词里提到的“增量训练”“LoRA 训练”那么 ZeRO-3 的配置会有一些调整。增量训练时原始模型参数可能已经很大不适合全部重新训练。LoRA 的做法是冻结原参数只训练插入的低秩适配器。改成 MoE 架构后有两种路数一种是冻结 MoE 专家层只训练路由网络。这种方案显存压力最小因为专家参数不用更新梯度ZeRO-3 甚至可以把专家参数直接 offload 到 CPU。路由网络更新量少收敛快但模型能力提升有限。另一种是冻结大部分层但让专家层继续微调。这种方案下专家层的梯度还是要分区ZeRO-3 的 reduce-scatter 仍然要做。配置上建议把stage3_param_persistence_threshold调高让 LoRA 的 tiny 权重常驻显存避免频繁 gather。我最近在用 Qwen 系模型做视觉层微调时就是把视觉塔的 Dense 层切成了小规模 MoE配合 LoRA 只微调专家层的低秩分支。显存占用从原本的 62GB 降到 41GB而且由于稀疏激活推理速度还有一点提升。这里的关键是把 LoRA 的 rank 控制在 8 到 16 之间太大会让微调部分的反向传播显存占用量飙升。3.5 训练过程中的显存观测与动态调整训练跑到一半怎么知道显存分配是不是合理我最常用的办法是看 DeepSpeed 的运行时日志它会打印ZeRO相关的显存存储布局。具体来说关注两个数字参数的常驻内存和临时 gather 缓冲内存。如果常驻内存占比很高说明大部分参数没被分区ZeRO-3 的效果没完全发挥。如果临时缓冲内存很大说明 prefetch 桶设得太大或者参数 gather 的频率太高需要调小stage3_prefetch_bucket_size。实时看显存占用我一般用nvidia-smi配合一个简单的 Python 脚本轮询记录每隔 30 秒打一次快照。这样能看出显存是稳定在一个水平还是在每个 step 之间有明显的“锯齿形”波动。如果锯齿特别大说明临时 gather 的内存在频繁分配和释放就应该把参数 persistence threshold 调大让这些小参数常驻平滑波动。4. 实操过程实录从模型改造到训练跑通的完整链路4.1 第一步把 Dense 模型改成 MoE 模型改造流程我会按这样走识别模型中计算量最大的 Feed-Forward 层通常是注意力层之后的 MLP。把这块 MLP 替换成 DeepSpeed 的 MoE 层。第一轮实验只替换 1 到 2 层控制变量。保持其他层不变跑通一个小规模训练验证流程比如用 2 个卡训练 200 步确认输出 shape 正确、loss 能下降。逐步增加替换层数观察显存和训练吞吐量的变化。我强烈建议不要一口气替换全部层。曾经我图省事一下把 12 层全换成了 MoE结果模型直接训飞了——loss 不降反升原因是路由网络初始化的随机性太大了。后来每次只换 4 层先跑 500 步确认稳定性再继续换效果好很多。4.2 第二步配置并行策略与数据加载MoE ZeRO-3 的组合里并行策略不是非此即彼可以混着用。DeepSpeed 支持 ZeRO-3 和模型并行或流水线并行共同工作。我的最常用组合是数据并行维度ZeRO-3 本身就是数据并行的一种延伸所有 GPU 都处理不同的数据。专家并行维度MoE 层的专家参数天然分布在各个 GPU 上这就是专家并行的雏形。如果模型太大还可以叠加流水线并行把不同层分到不同 GPU 组。数据加载方面MoE 训练对 batch size 比较敏感。大 batch 有助于路由网络学会更稳定的分配。但如果显存实在有限就不要硬撑大 batch。我用过一个经验公式专家数乘以每个专家的 batch 容量 ≈ 全局 batch size。64 个专家、每专家容量 8 个 token那么全局 batch 至少要有 512 个 token才不至于让有些专家完全闲置。4.3 第三步设置混合精度与通信数据类型混合精度在 MoE 训练中非常关键。FP16 训练时激活值和梯度都用 FP16 存储ZeRO-3 的通信量减半对训练吞吐量的提升很明显。BF16 则更稳适合训练过程中梯度变化范围较大的场景。但注意FP16 的 loss scaling 机制在 MoE 场景下偶尔会出问题。因为 MoE 层的输出经过路由和 All-to-All数值分布可能不太规律固定loss_scale反而容易炸。DeepSpeed 里我推荐把loss_scale设为 0即开启动态 loss scaling让框架自己找到合适的缩放因子。通信的类型也值得单独设置。communication_data_type如果是 FP16通信量小但可能有精度损失如果是 FP32通信量翻倍但精度保险。我训练 MoE 时的选择是如果模型规模在 10B 以下优先用 FP32 通信图个稳超过 10B再考虑 FP16 通信否则通信瓶颈会非常明显。4.4 第四步训练过程的关键指标监控跑起来之后不能光盯着 total loss。MoE 训练需要额外监控这些指标aux loss负载均衡损失判断路由是否均匀的关键指标。通常来说训练稳定后 aux loss 应该在 0.01 左右震荡如果持续高于 0.1说明负载严重失衡。token dropped 比例当专家容量不足时超容量的 token 会被丢弃。这个比例如果超过 1%就要警惕信息丢失。我遇到过一次 token drop 率到了 5%模型效果明显变差。路由熵衡量路由分布的平均程度。如果熵太小说明门控网络变得“太自信”总把 token 送给少数专家熵太大则说明路由近似随机专家的专业性发挥不出来。DeepSpeed 的训练日志会输出部分信息但更细致的监控我建议自己加回调。比如在 MoE 层 forward 之后记录一下各专家的 token 计数每隔 100 步打印一次分布一目了然。4.5 第五步模型保存与加载的特殊处理MoE 模型因为参数分区存储保存和加载时要格外小心。DeepSpeed 的 checkpoint 机制会记录 ZeRO 分区信息但如果你想把模型导出为普通的单卡权重文件需要先把参数全部 gather 回来。我在实践中用这样的流程训练结束后关掉 ZeRO-3 分区加载 checkpoint将所有参数合并到单卡再用torch.save输出一个完整的权重文件。具体来说在 DeepSpeed 的配置文件中临时把stage改为 0然后加载原来的 checkpointDeepSpeed 会自动做参数合并。这个操作在模型很大时比较耗时但对于部署上线是必须的。我踩过的一个坑是直接加载 ZeRO-3 的 checkpoint 做推理结果推理脚本不支持 MoE 层的参数重复广播导致路由计算全部出错。后来养成了“训练保存 ZeRO 格式导出时合并成单卡权重”的习惯再没出过问题。5. 常见问题与排查技巧实录5.1 MoE 训练中常见的显存爆炸和卡死问题显存爆炸的问题我分两类来排查。第一类是模型加载时的 OOM。这种情况多半是 ZeRO-3 配置没生效。常见原因是在构造 model 之后才初始化 DeepSpeed 引擎导致框架没有正确识别 MoE 层的参数分区规则。正确顺序是先定义模型马上用deepspeed.initialize()包裹再开始前向传播。如果先跑了一个 dummy forward 再去 initialize参数已经被塞进显存ZeRO-3 来不及分区必然 OOM。第二类是训练中途 OOM。这种情况更隐蔽。大概率是某个张量的生命周期出了问题比如 gather 出来的参数没有被释放。可以是用torch.cuda.memory_summary()看内存快照或者用py-spy dump查看 Python 进程的调用栈定位是哪个层出的问题。我遇到过一次是自定义 MoE 层里手动调用了 all-gather 后没有 detach导致计算图把临时参数全部引用住了显存越涨越高。训练卡死则多半是通信问题。All-to-All 通信在 MoE 中非常容易死锁。最常见的原因是不同 GPU 上的 token 路由数量不同导致某个 GPU 在等待其他 GPU 发送数据时对方还没算完。这时候检查一下各卡的 GPU 利用率如果有卡利用率偏低而其他卡忙碌十有八九是通信等待。解决方法是调大capacity_factor或者检查路由器是否能保证每个专家至少有最少数量的 token。5.2 负载不均导致 loss 异常的处理思路昨天还跑得好好的今天 loss 突然飙升第一种排查方向就是看负载均衡有没有崩溃。我之前遇到过一次loss 从 2.3 突然涨到 6.7查看 aux loss 才知道从 0.01 跳到了 0.8。原因是训练配置里load_balance_loss_weight被同事不小心改成了 0门控网络完全放飞所有 token 都涌向同一个专家。遇到这种情况我的处理方案是先把load_balance_loss_weight调回到 0.01然后把专家容量临时收紧强制丢 token。跑几百步让路由分布恢复均匀之后再把容量放宽。这个过程有点像“复位”虽然会损失一点训练进度但比让模型彻底崩掉要好得多。还有一个容易被忽略的因素不同专家的初始化差异。我在做增量训练时发现如果某个专家的参数初始化和主流分布差太远这个专家从一开始就接不到 token后面也很难翻身。这种情况下与其靠负载均衡损失慢慢拉回来不如直接把这个专家的参数重初始化一次。我在代码里加了一段逻辑每训练 1000 步检查一次专家利用率低于 1% 就触发重初始化实测模型收敛速度提升明显。5.3 常见问题速查表现象可能原因排查方向解决建议模型加载时 OOMZeRO-3 未生效检查 initialize 调用时机确保模型构造后立即 initialize训练中途 OOM临时 gather 参数未释放查看显存快照减少 prefetch bucket size训练卡死All-to-All 死锁查看各卡利用率差异调大 capacity_factorloss 飙升负载不均衡检查 aux loss 和 token drop调大 load_balance_loss_weightloss 为 NaN混合精度溢出检查 loss scale 变化开启动态 loss scaling吞吐量显著下降通信耗时过大观察通信和计算重叠情况调整 micro batch 和 prefetch保存权重过大ZeRO 分区格式检查 checkpoint 结构导出时合并参数到单卡5.4 一个实测调优案例最后分享一个我近期实际调优的案例。任务是在 8 卡 A100每卡 80GB上训练一个 32B 的 MoE 模型包含 128 个专家每个专家隐层 2048top-2 路由。初始配置跑起来每个 step 耗时 24 秒。显存峰值 73GB勉强不爆但负载均衡很烂aux loss 一直在 0.2 左右token drop 率经常到 2%。我做了三步调整第一步把capacity_factor从默认的 1.0 调到 1.3token drop 率立刻降到 0.2% 以下。这一步就花了 10 分钟但效果立竿见影。第二步把stage3_prefetch_bucket_size从 5e7 调到 2e8prefetch 提前量更足。step time 从 24 秒降到 20 秒吞吐量提升约 20%。第三步调load_balance_loss_weight从 0.001 升到 0.01跑了两百步后 aux loss 降到了 0.03token drop 率保持稳定。最终 step time 稳定在 17 秒左右显存峰值约 68GB负载均衡恢复正常。整个过程大概花了一个小时没有改任何代码逻辑纯调配置就解决了训练卡点和显存压力。6. 从 ZeRO-3 到 MoE 训练的进阶建议6.1 继续增大模型的路径选择当你已经能在单机 8 卡上用 ZeRO-3 跑 MoE 模型接下来无非就两个方向一是继续增加专家数量扩大模型稀疏容量。此时 ZeRO-3 的通信开销会逐渐超过计算开销需要考虑把专家层单独做专家并行而不是让 ZeRO-3 统一管理所有参数。DeepSpeed 也提供了一种折中方案让专家参数走 ZeRO-3 分区但路由网络参数常驻每卡。二是放大单专家的隐层规模。这种情况下单个专家内部的矩阵乘会变得更大更适合用 Megatron 式张量并行把专家的内部矩阵切开到多卡。ZeRO-3 和张量并行可以同时启用但配置复杂度会上升需要仔细测试两种并行的切割维度是否冲突。我个人的建议是先保住训练吞吐量再追求模型规模。很多团队一上来就想冲几百 B 的 MoE结果训练效率只有理论峰值的 25%得不偿失。不如先在一个可控模型上把 ZeRO-3 和负载均衡调到最优化再逐步放规模。6.2 推理阶段的 MoE 模型部署提示训练只是前半段部署推理是另一半。MoE 模型在推理时如果还用 ZeRO-3 那种参数随用随取的方式延迟会高到没法用。推理引擎通常要预先加载全部专家参数或者做专家参数的内存映射只加载被路由到的那部分。我自己实践下来MoE 推理的第一个优化点是缓存。因为推理时 token 的路由结果相对稳定很多专家在连续多次推理中都会被反复选中。把这些专家的参数预加载到显存缓存中能大幅减少重复加载开销。第二个优化点是异步预取。门控网络输出的路由结果可以先发出一条专家参数预取指令再执行其他层计算。当计算完前面的层时专家参数可能已经到了延迟就被隐藏掉了。这个思路跟 ZeRO-3 的prefetch_bucket_size本质上是一回事只是应用在推理侧。6.3 与社区模型和热点的交汇最近社区里讨论的 Qwen 系列、DeepSeek 系列模型很多都已经用上了 MoE 架构。比如 Qwen 的视觉语言模型里有视觉塔微调DeepSeek 公开的智能体训练方法里也频繁提到稀疏激活和 MoE 的增量训练。这些都是 ZeRO-3 MoE 的落地场景。如果你关注的是视觉模型的微调训练比如 YOLO 系列或其他检测模型的训练虽然它们不一定是严格的 MoE 架构但 ZeRO-3 的参数分区思想同样适用。我在训练一些视觉模型时也会用 ZeRO-3 来节省显存尤其是当 backbone 很大、batch size 受限于显存的时候。节省下来的显存可以开更大的 batch反而把训练速度提上去了。从 2025 年的视角看MoE 不再只是大厂才能玩的东西开源社区的生态已经让中等规模的团队也能在消费级显卡上尝试 MoE 训练。DeepSpeed ZeRO-3 在其中扮演的角色就是那个让“显存不够”不再是第一道门槛的关键技术。我个人这几年跑模型训练最大的感受是真正难的不是某一个算法本身而是把算法、框架、硬件、数据这四样东西协同调优的过程。ZeRO-3 和 MoE 的组合恰好给了一套在这个协同中极其好用的方法论——参数分区解决了显存稀疏激活解决了算力负载均衡解决了分布式效率。顺着这个思路去配置和调优即使模型规模再大心里也会比较有底。最后再分享一个小技巧如果你准备试 MoE 训练但还没有现成的 MoE 模型别急着去写一个完整的自定义模型。先把一个比较小的模型比如 1B 到 3B 规模的其中一层改成 MoE配合 ZeRO-3 跑通完整流程。这个最小的闭环验证完再放到大模型上整个训练链路出现问题时你就有足够的知识储备去定位和解决了。