故障排查 / 速度不对
MoE 模型快得离谱或慢得离谱:你在用总参数量估速度
本站未复现 推导 影响:llama.cpp / Ollama 支持 MoE 的近期版本 · Windows / Linux / macOS
现象
30B-A3B 跑出 100+ tok/s 让你怀疑测速坏了;或者 235B-A22B 只跑到 20 tok/s 让你以为配置出错。
原因
MoE 每个 token 只激活一小部分专家,所以速度按激活参数量决定,而显存按总参数量决定。Qwen3-30B-A3B 总 30B 但每 token 只激活 3B(约 1/10);Qwen3-235B-A22B 总 235B 激活 22B。拿总量算速度会低估 10 倍;拿总量算显存反而是对的。
按这个顺序处理
- 分开两个数:显存/内存占用看总参数量,速度看激活参数量。
- 确认专家权重放在哪:全部在显存最快;放内存大约 25–35 tok/s(本站按内存带宽 55GB/s 的一半效率估算);这个信息在 llama.cpp 的 --n-cpu-moe 参数与日志里。
- 别把本站的上限钳制当 bug:本站对单流解码设了经验上限(高带宽卡 200 tok/s,其余 140),因为纯带宽公式对小激活模型会算出四五百这种不可能的数。
- 如果速度比激活参数估算还快很多,先怀疑测的是不是缓存复读或者输出被截断了。
怎么确认解决了
把实测 tok/s 和『带宽 × 0.7 ÷ 每 token 激活权重的 GB 数』对一下,量级对得上就是正常状态。
来源与可信度
条目性质本站依据容量与速度公式推导撰写
是否已在本站机器复现否——请把这条当线索而不是结论
- https://github.com/ggml-org/llama.cpp/discussions/15013 — 讨论:MoE/稀疏模型'参数多'不等于'计算多',对应'MoE 看激活参数非总参'纠偏
- https://huggingface.co/blog/peft-beyond-lora — HF 官方:稀疏/MoE 结构激活参数远低于总参,支撑'别用总参判断速度'