arXiv 7 月 21 日挂出的新论文把 MoE 训练里最贵的那笔账——optimizer state——拆成了三份。论文标题《Where Should Optimizer State Live? Tiered State Allocation for Memory-Efficient Mixture-of-Experts Training》，作者 Nuemaan Malik，GitHub 已开源（nuemaan/skewadam）。 **问题在哪。** 6.78B 参数的 MoE 语言模型，权重本身只有 12.6 GB（bfloat16），但 AdamW 的一阶加二阶动量要 50.6 GB——是参数的四倍。整轮训练峰值 81.4 GB，40 GB 的卡根本塞不下。这是 MoE 训练被锁在大厂手里最直接的理由之一。 **SkewAdam 的关键观察很朴素**：MoE 里的三种参数本来就不该吃同一种 optimizer 待遇。占比 5% 的 dense backbone 负责绝大部分梯度信号、占比 95% 的 experts 是被稀疏激活的、占比不到 0.01% 的 router 只做路由决策——三种在梯度统计量和样本量上根本不在一个量纲。论文把三组各自配上最合适的状态格式：backbone 保留 float32 动量加 factored 二阶矩、experts 只保留 factored 二阶矩（不要动量，因为它们是被路由器稀疏挑出来的）、router 虽然小但决策敏感，保留完整二阶矩。 **结果数字很硬。** 同样的初始化、同样跑 82M token 的 controlled comparison：optimizer state 从 50.6 GB 掉到 1.29 GB，是 AdamW 的 2.6%；训练峰值从 81.4 GB 降到 31.3 GB，稳稳塞进 40 GB 加速器。验证 perplexity：SkewAdam 108.4，AdamW 126.8，Muon 120.2，Lion 393.7；router load balance 收敛到距离均匀分布不到 1% 的水平。论文做了关键消融：把三种状态都拉满到 backbone 同款、参数内存直接放大 20 倍，perplexity 几乎不变；换成 Adafactor（共用 factored 但丢动量），perplexity 直接 plateau 在落后 40 分的位置。两刀切出结论很清楚：**省下来的内存来自分档设计，保住的精度来自没丢动量**。结尾那句 "where optimizer state lives matters at least as much as how much of it there is" 是全文的题眼。 **对从业者的含义**有三层。第一，多 B 参的 MoE 训练门槛直接降到单卡 40 GB——以前必须堆 A100/H100 80GB 的预算，现在消费级 4090/5090 集群也能扛，开源社区做 MoE 后训练可以绕开大厂算力壁垒。第二，分档策略是思路而非数字：未来 MoE 出现新参数子群（共享 expert、retrieval head）都可以按「梯度样本量决定状态精度」的逻辑继续拆。第三，optimizer state 占的显存比权重本身还重，所有想压显存的人应该先压它，再压激活值，最后才是权重。 代码纯 PyTorch 单文件实现，可直接 drop-in 到现有训练脚本里。