快速结论:这个报错通常出现在用 Transformers 5.13 + DeepSpeed ZeRO-3 加载 Qwen3-235B-A22B 这类 MoE 大模型时,表现为主机 CPU 内存持续上涨直到约 1 TB 被 OOM 杀掉;优先排查 Transformers 版本是否回落到 4.51.0,以及是否命中 5.x 新增的 MoE 专家动态融合加载路径。
适用环境:Transformers 5.13.0(对照版本 4.51.0)、Python 3.12.3、huggingface_hub 1.22.0、Safetensors 0.8.0、Accelerate 1.14.0、DeepSpeed 0.19.2、PyTorch 2.8.0+cu128(CUDA)、Linux(glibc2.34)、NVIDIA A100-SXM4-80GB、分布式多卡(16×A100)、ZeRO stage 3、CPU offload 关闭、BF16。
最快修复方案:Issue 中明确验证过的方式是只把 Transformers 降级到 4.51.0,CPU 内存保持有界,模型可以在 16×A100 上正常加载。
注意事项:降级只是绕过而非修复,会失去 5.x 的 MoE 加载改造;Issue 中提出的“按融合单元(一层专家的分片组)流式加载”方案仅属推测性建议,维护者也表示修复可能非常复杂,尚未合并,可优先尝试但不要当作已确认方案。
问题场景
用户在分布式环境下用 DeepSpeed ZeRO-3 加载并训练 Qwen/Qwen3-235B-A22B(MoE 模型),脚本沿用 PEFT 的 SFT 训练示例,配合自定义 ds_zero3.json。DeepSpeed 能正常初始化,全局 world size 和 ZeRO-3 参数分区都正确,GPU 显存分配也能完成(每卡约 35 GB reserved),但随后主机 CPU 内存不断增长,最终逼近约 1 TB 被 OOM 杀掉。同一套 DeepSpeed 配置在 Transformers 5.13.0 下加载 gpt-oss-120b-bf16 是成功的,说明问题更偏向 Qwen3 / GLM 这类 MoE 的加载路径。
报错原文
Transformers 5.13 CPU memory growth loading Qwen3-235B-A22B with DeepSpeed ZeRO-3; 4.51.0 remains bounded
原因分析
最可能的原因来自 5.x 引入的 MoE 权重动态加载与在线专家融合。评论中指出,Transformers 5.x 在 core_model_loading.py 中新增了 MergeModulelist + Concatenate 操作,通过 WeightConverter 把每层的 experts.{i}.{gate,up,down}_proj 融合成堆叠的 gate_up_proj / down_proj 参数,而 4.51.0 完全没有这套逻辑。融合要求同一层的全部专家同时驻留内存,而由于 checkpoint 分片边界会落在层中间(对 model.safetensors.index.json 已确认),5.x 选择了“先整体合并、再分区”的做法来保证融合正确性,代价就是在大型模型 + ZeRO-3 加载时失去了 CPU 内存上界。相对地,4.51.0 的按分片流式加载虽然内存有界,但面对跨分片的专家会融合出不完整或错误形状的结果,所以 5.x 才改成了全量合并。以上为社区分析,属于可能原因,未获得官方最终定性。
环境排查
- 确认 Transformers 版本:5.13.0 会复现,4.51.0 不复现。
- 确认 DeepSpeed 版本与 ZeRO stage:Issue 中为 0.19.2、stage 3,且 CPU offload 关闭。
- 确认 PyTorch / CUDA:2.8.0+cu128(CUDA)。
- 确认 Python 3.12.3、huggingface_hub 1.22.0、Safetensors 0.8.0、Accelerate 1.14.0。
- 确认显卡与规模:NVIDIA A100-SXM4-80GB,16×A100 分布式。
- 确认 dtype 为 BF16,并核对全局 ZeRO 分区比例为 1/world_size。
- 确认模型是否属于 MoE 结构(Qwen3-235B-A22B、GLM 类),非 MoE 模型(如 gpt-oss-120b-bf16)在同一版本下正常,可作为对照实验。
解决步骤
- 先做对照验证:保持 DeepSpeed 配置、脚本和数据不变,仅把 Transformers 从 5.13.0 降到 4.51.0,观察任务是否能在 16×A100 上正常加载。
- 如果需要继续使用 5.13.0,可先确认报错模型是否为 MoE 结构,并用 gpt-oss-120b-bf16 在同一版本下做对照,判断是否命中 Qwen3 / GLM 的 MoE 加载路径。
- 可优先尝试 Issue 评论中提出的思路:把加载粒度从“单个分片”或“整个 checkpoint”改成“一个融合单元”,即融合某一层全部专家所需的分片组,加载并释放该组后再处理下一组;评论认为 _load_state_dict_into_zero3_model 与权重转换路径已支持部分 state dict,理论上无需改动融合逻辑本身。
- 关注该 Issue 的后续状态与是否有人提交 PR;维护者已表示修复可能非常复杂,且该 Issue 已被自动标记为 stale。
验证方法
在相同节点数、相同 ZeRO-3 配置和相同数据下重新加载 Qwen3-235B-A22B,观察主机 CPU RSS 是否保持有界而不再持续增长到约 1 TB;若使用 4.51.0 能稳定完成加载、5.13.0 复现 OOM,即可确认命中的是该版本回归。采用融合单元流式加载等推测方案时,还需额外确认融合后的 gate_up_proj / down_proj 形状正确、无静默错位,再判断是否真正解决问题。
参考来源
huggingface/transformers #47514
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。

![[BUG]remove model](https://www.chat-gpts.plus/wp-content/uploads/2026/09/41570-bab8c28c-768x403.jpg)
