125B 的 MoE 在我机器上反而比 27B 快三倍
上一篇写了 Qwen3.8-27B 稠密模型的部署，那篇的结论是 41-55 tok/s 就是这台机器（2×RTX 3090）的日常水位。本来我以为这就是上限，直到假期里试了 125B 级的 MoE——结果反而更快。
MoE 为什么"参数大、算得少"
MoE（Mixture of Experts）的思路是把前馈层拆成很多个"专家"，每个 token 只激活其中一小撮。我跑的这个 Qwen3.8 Flash-Next 有两万多个专家，每个 token 只激活 10 个左右：总参数 125B，单 token 实际计算量约 13B——比 27B 稠密还小。
所以"又大又快"在 MoE 这里不矛盾：大的是容量（记住的东西多），小的是每次的计算量。
但 MoE 有个致命的工程问题
计算量小了，麻烦转移到了内存：两万多个专家的权重加起来约 50G，塞不进 24G 显存。传统推理引擎（llama.cpp 的 offload）的做法是专家驻留内存、每个 token 把激活的专家权重搬运过 PCIe——每层、每 token 都在搬运，速度被 PCIe 带宽钉死，这就是"MoE 本地跑起来慢得没法用"的根源。
新一代引擎换了个思路：算力去守数据，而不是数据去找算力。以 STRATA 为例：
- 专家的使用频率分布极不均匀，把最热的专家常驻显存，实测 99.1% 的专家计算直接在 VRAM 里完成；
- 冷专家不搬运，全部常驻内存（我用的是 IQ3_XXS 量化，约 47G，mlock 锁定），由 CPU 并行就地计算；
- GPU 算 attention 和 CPU 算冷专家流水并行，互不等待；再加 MTP 投机解码乘个 1.6-1.8 倍。
实测结果
- 生成速度 141 tok/s，对比 27B 稠密的 41-55，快了近三倍，参数量却接近五倍；
- Prompt 处理 1919 tok/s，1.3 万 token 的长文 7 秒处理完；
- 质量是实打实的 125B 水位，复杂推理和代码明显强于 27B。
代价
也别只看速度：
- 47G 内存被长期锁定——128G 内存的机器扛得住，64G 就别想了；
- 引擎目前只支持 Qwen3.8 Flash-Next 家族，其他 MoE 模型（GLM、MiniMax 之类）得回 llama.cpp 的慢速 offload；
- 首次加载要锁 47G 内存，机器会卡顿约一分钟；
- 有个隐蔽的坑：Linux 默认每进程只能 mlock 8MB 内存，失败报出来的错误是 “out of memory”——跟显存毫无关系，得在 systemd 里设
LimitMEMLOCK=infinity。
结论
内存够大（64G 以上）的话，MoE 档位是"高质量重推理"场景的明显升级：写代码、复杂分析这类任务里，125B 对 27B 的能力差是能感觉出来的，而速度还不掉。代价是内存被吃掉一大块、以及模型选择被锁死在一个家族上。
在我的路由器里（见这篇），它就是那个"想认真干活时才切过去"的高档位。
参考
- STRATA — MoE 热专家缓存推理引擎
- llama.cpp — 对照组：传统 offload 路线
- ISTA-DASLab — MoE 权重的 GSQ 量化