ValueError: Some modules are dispatched on the CPU or the disk…` from `quantizer_bnb_4bit.validate_environment` (via `integrations/accelerate._get_device_map`). The model is far under the 1.

快速结论：该报错通常发生在使用 load_in_4bit=True 配合 device_map="auto" 和自定义 max_memory 加载模型时，即使显存总预算远大于模型大小，自动设备映射仍将部分模块错误地分配到 CPU 上。优先排查是否因 embedding / lm_head 等大模块（4-bit 不压缩）超出单 GPU 平衡预算导致溢出。

问题场景

用户在使用 Transformers 加载 MiniMaxAI/MiniMax-M3（428B 稀疏 MoE 视觉语言模型）时，配置了 4-bit 量化（nf4, double-quant）、device_map="auto" 和 max_memory={i: "165GiB" for i in range(8)}（总计约 1.3TB），模型大小远低于预算，但自动映射仍将部分模块分配到 CPU 上，触发 ValueError: Some modules are dispatched on the CPU or the disk... 报错。环境为 transformers 5.12.1, deepspeed 0.18.9, torch 2.12.0+cu130, peft 0.19.1, bitsandbytes 0.49.2, accelerate 1.14.0；8× B200 (178GB) / 2TB RAM。

报错原文

ValueError: Some modules are dispatched on the CPU or the disk. Make sure you have enough GPU DRAM to fit the quantized model. If you want to dispatch modules on CPU or disk, set `llm_int8_enable_fp32_cpu_offload=True` or `load_in_4bit=True` and `bnb_4bit_quant_type="fp4"`

原因分析

根本原因在于 Transformers 集成的设备映射逻辑中存在两个设计缺陷（可 CPU 复现，无需 8×B200 环境即可触发）：

get_balanced_memory 对每张 GPU（最后一张除外）的内存上限设置为 total/num_gpus + 1.25 × buffer，其中 buffer 仅测量 _no_split_modules（即 decoder layer）的大小，忽略了 embed_tokens / lm_head 等未参与拆分的大模块。这些模块在 4-bit 量化下不会缩小，因此在设备映射中体积占主导。
infer_auto_device_map 采用单调递增的设备遍历策略：当一个模块大于当前设备的容量上限时，会永久跳过该设备（不回填）。因此，单个大叶子模块（如 embedding）——大于经过平滑后的微小平衡上限，但远小于用户指定的单 GPU 预算——会依次跳过 GPU 0..n-2，最终所有后续模块堆积到最后一张 GPU（唯一保留用户原始预算的设备）上，溢出后分配到 CPU，而此时大部分 GPU 实际上几乎是空的。

注意：修复 #47203 仅解决了 no-split 模块内部的体积差异问题，但对于 embedding / lm_head 这类不在 no-split 块中且不被 4-bit 压缩的模块，仍然可能因体积大于平衡上限而触发同样报错。后续修复 #47211 进一步将 buffer 大小调整为最大叶子模块的体积。

环境排查

Python 版本：确认 3.10+
CUDA 版本：与 torch 2.12.0+cu130 对应的 CUDA 13.0
PyTorch：2.12.0+cu130
Transformers：5.12.1（问题版本），建议升级到包含 #47203 和 #47211 修复的版本
Accelerate：1.14.0
bitsandbytes：0.49.2
peft：0.19.1
显卡：8× B200 (178GB) 或类似高显存配置，但此问题在任意多 GPU 环境中均可复现
模型：MiniMaxAI/MiniMax-M3 或类似大型稀疏 MoE 模型/大词汇表模型（如 Llama-3-8B 也受影响）

解决步骤

升级 Transformers 到修复版本：确保版本包含 PR #47203（修复 no-split 模块不同层体积差异问题）和 PR #47211（修复大叶子模块溢出问题，将 buffer 大小调整为最大叶子模块的体积）。截至 2026-07-09 Issue 关闭时，需从 main 分支安装或等待后续稳定版。
手动调整设备映射：作为临时解决方案，可以尝试不依赖 device_map="auto"，而是显式指定设备映射策略，或使用 device_map="sequential" 强制按顺序分配。
增大最后一张 GPU 的 max_memory：如果无法升级，可以尝试为最后一张 GPU 保留更多内存，以容纳堆积的模块。
环境验证（可优先尝试）：用小型 meta 模型（如随机模型）配合缩减的 max_memory 复现问题，确认修复是否生效。即使总预算为模型体积的 6 倍，原逻辑仍会触发相同错误。
注意：如果确实无法将所有模块分配到 GPU（例如某个大叶子模块大于任何单张 GPU 的 max_memory），修复后的逻辑会给出清晰警告而非静默失败。

验证方法

加载目标模型并检查日志，确认设备映射中不再包含 CPU 设备。如果使用的是修复版本，即使总预算远大于模型大小（如 6×、3×、2× 预算），也应能正常分配。对于极端情况（单个模块大于任何单设备预算），应看到明确警告而非报错。

参考来源

huggingface/transformers #46823

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

ValueError: Some modules are dispatched on the CPU or the disk…` from `quantizer_bnb_4bit.validate_environment` (via `integrations/accelerate._get_device_map`). The model is far under the 1.