31.5B 用 33.3% 更少 GPU 小时——一行配置换一年算力？
乍一听像营销话术，但这篇论文的论据其实挺硬的。Simeng Sun + Roger Waleffe 这俩名字，搜一下背景——都是 NVIDIA Research 的核心研究员，做过 Mamba 系列后期工作。这个 CE-MoE 的思路，本质上就是承认「专家层越密集越好」是个幻觉。
原帖没说清楚的 4 个问题。
1）33.3% 这个数不是单卡省下来的，是 all-to-all 通信的总耗时占比抹掉的结果。 当 MoE 层数从「每层一个」压缩到「少而精」，collective 通信次数成比例下降——但单次 token 量也变了。所以更准确的比较是「总 GPU 小时 / 单位 validation loss」，光看比例容易踩坑。
2）「在匹配的总参数和激活参数下」是个非常苛刻的对照。 现实部署里，「激活参数」是个宣传数字，你真正部署时是 moe_router 替你不激活部分专家，理论值与实测存在 gap。文章说「下游基准匹配」，但没说哪些基准。最可能被掉包的是 MMLU 这种偏语言理解的——而 MoE 的真正战场（推理、数学、代码）通常单 token 步的 expert 协同比 dense FFN 复杂，对稀疏化的敏感度更高。
3）CE-MoE 的「token mixing 深度补足」是结构性妥协。 它说「我们用更多 attention / Mamba-2 层来补深度」，听起来免费，实际上密集 FFN 的每次前向都把所有 expert 跑一遍——每层全通道激活，能耗不比专家少。换言之，结构成本被转嫁到稠密层，时间不在这省就在那省。「33.3% 更少 GPU 小时」是总量级，不是细账。
4）它没公开代码就别过头。 截至 2026-08-28 上 arXiv，repo 还没出。我搜不到 github.com/simengsun/CE-MoE 这种典型命名。这意味着实验可复现性是 0——别人想接入，得自己把层模式重写一遍。这种程度的工程创新，三个月不发代码是信号：要么在憋 Nature / ICLR，要么被 NVIDIA 内部 reviewer 拒了。
我的判断：这是一个对训练基础设施团队而言聪明、对学术研究社区而言半成品的设计。等代码放出后再看。
收尾钉子：省 GPU 小时的代价是把代码复杂度转嫁给后人——能不能拐进主流，得看仓库链接 90 天内出不出来。