一个更现实的降本方向，不是重练 MoE，而是先让一半专家别上场
论文 ：Post-Trained MoE Can Skip Half Experts via Self-Distillation
作者：清华大学、上海 AI Lab、微信 AI、快手等团队
一句话看懂：已经训完的 MoE，不用推倒重来，也有机会把一半专家计算先省下来。
这两天看到一篇论文，我第一反应不是「这个方法真巧」。
而是，终于有人开始认真解决一个特别现实的问题了。
很多 MoE 大模型，训练的时候已经花了大钱，后训练也做完了，效果也跑出来了。
可一到线上，账单开始说话。
你会发现，模型能力是上去了，推理成本也跟着上去了。
这时候最难受的地方在于，你并不是没有一个好模型。
你是已经有了一个好模型，但它太贵了。
更麻烦的是，很多动态 MoE 的思路，默认你要从头重新预训练，或者至少大改训练流程。
说白了，这对很多团队都不现实。
已经训完的模型，能不能别推倒重来，直接在现有成果上做一次「后装式降本」？
这篇论文《Post-Trained MoE Can Skip Half Experts via Self-Distillation》，做的就是这件事。
先把结论放这儿。
它想办法让一个已经训练好的静态 MoE，在不明显掉能力的前提下，跳过超过一半的专家计算。
而且端到端推理速度，能提到大约 20%。
这就不是实验室里那种「好像有点意思」的小优化了。
这已经是很典型的工程价值。
😮 这篇论文到底在解决什么
如果你平时不太盯 MoE，可以先用大白话理解一下。
MoE 模型有点像一个公司里养了很多专家团队，每次来一个请求，不是所有人都一起上，而是路由器挑几个人出来干活。
这本来已经比「全员上场」省很多了。
但论文作者盯上的，是下一步。
有些 token，其实没那么难。
它可能根本不需要叫满那么多专家。
如果这些简单 token 能少叫点人，整套系统的计算量就还能继续往下砍。
这就是动态 MoE 的核心直觉。
问题也正出在这儿。
直觉很顺。
落地很难。
因为一个已经做完预训练、SFT、RL、蒸馏这些流程的 MoE，它内部的路由分工，已经被调得很细了。
你这时候再硬改架构，最容易发生的事，不是省钱成功。
而是模型先废一半。
所以这篇论文真正有价值的地方，不是又发明了一个更炫的动态 MoE 概念。
而是它回答了一个更实在的问题。
怎么在「模型都已经训好了」的前提下，再把它改造成一个更省的动态版本。
🧠 他们的办法，其实挺妙，也挺克制
这篇论文的方法叫 ZEDA。
名字不重要，先说它到底干了什么。
最核心的一步，是往每一层 MoE 里塞进一批「零专家」。
这个零专家很有意思。
它不输出任何有效结果。
你可以把它理解成一个真正意义上的空专家，输出恒等于 0。
这样一来，路由器还是照常选 top-k。
但现在候选池里，除了正常专家，还多了一批「选中也几乎不花计算」的零专家。
结果就是，简单 token 如果被分到一些零专家上，它真正唤起的正常专家数量，就会自然下降。
省算力这件事，也就发生了。
这个想法为什么好？
因为它不是去重写专家模块本身。
它是在尽量少碰原模型能力结构的前提下，给路由器新增了一个「别干活也行」的选项。
这个味道很重要。
很多降本方案，一上来就是大开大合。
砍层、砍头、砍参数、重训练。
ZEDA 不是。
它更像是在原来的公司架构里，给每个任务分发节点多加了一个按钮。
这个按钮叫，没必要就别把人都叫来。
🔧 但只加零专家还不够，直接上很容易翻车
如果事情到这里就结束，那这篇论文也没那么值钱。
因为你很快会想到另一个问题。
原来路由器已经学会怎么分配专家了。
你突然塞一堆新选项进去，它凭什么还能分得稳？
一个处理不好，路由分布就乱了。
模型以前积累出来的能力，也可能一起乱。
所以作者又做了两件事。
第一件事，是拿原来的静态 MoE 当老师。
新模型先做一轮 SFT，学老师吐出来的答案。
然后再做一轮 on-policy distillation，也就是让学生按自己的分布去生成，再让老师盯着它纠偏。
你可以把这理解成两步。
先别跑偏。
再慢慢学会自己走。
第二件事，我觉得更关键。
他们没有用那种「把所有专家都尽量拉平均」的普通负载均衡思路。
因为这对一个已经训练完成的 MoE 来说，破坏性太大了。
原模型里，不同正常专家之间本来就不是平均分工。
有些专家擅长代码，有些擅长推理，有些在某些 token 分布下更容易被激活。
你硬把它们拉平，等于把旧秩序先打碎。
所以论文这里用了一个组级别的 balancing loss。
不是逼每个专家都平均。
而是只控制两大组之间的比例。
一组是正常专家。
一组是零专家。
这一下就很聪明。
因为它保住了正常专家内部原本学好的分工关系，只去调「干活的专家」和「不干活的专家」之间的竞争。
这才像在修系统。
不是在拆系统。
📊 结果怎么样，不是神话级，但非常实用
先看最重要的部分。
作者在 Qwen3-30B-A3B 和 GLM-4.7-Flash 两个后训练完成的 MoE 模型上测了 11 个 benchmark，覆盖数学、代码和指令跟随。
结论很直接。
超过 50% 的专家 FLOPs 被省掉了
端到端推理速度大约提升 20%
平均准确率只出现边际损失
相比现有动态 MoE 基线，整体表现还更稳
这张图我建议你多看一眼。
不是因为它有多炸裂。
而是因为它透露出一个很成熟的信号。
这套方法不是只在某一个点上赢得很漂亮。
它是在数学、代码、指令跟随这几类任务里，都没有明显崩盘。
这对线上系统特别重要。
因为企业真正怕的，不是某个 benchmark 少 1 分。
而是某一类任务突然塌掉，然后你根本不知道塌在哪。
更实在的是，它的改造成本也不算离谱。
论文里给的数据是，在 8 张 H200 上，Qwen 这边总适配时间大约 30 小时，GLM 这边大约 61 小时。
你拿这个时间去对比一次完整预训练或者一轮重型后训练，差别就很明显了。
这不是重建一栋楼。
更像是楼已经建完了，你再做一次结构加固和线路改造。
⚡ 为什么它的行业启示，比论文分数更重要
我觉得这篇论文真正狠的地方，不是「MoE 又提速了」。
而是它在提醒大家一件事。
模型训练结束，不等于优化结束。
很多团队默认会把模型发布，当成一个分界点。
前面是训练问题。
后面是部署问题。
中间像是断开的。
但这篇论文其实在说，不是。
在训练和部署之间，还有一层非常值钱的事情。
那就是，面向真实推理成本，再做一次结构级适配。
这个思路一旦成立，影响不会只停在 MoE。
你往大一点看，它其实在告诉开发者和企业，后训练时代的优化对象，已经不只是参数了。
还包括计算路径。
包括路由策略。
包括哪些输入该走重路线，哪些输入该走轻路线。
这跟今天很多团队做智能体、做多模型调度，其实是同一个方向。
不是所有请求都值得走最贵那条链路。
不是所有 token 都值得把专家叫满。
不是所有步骤都应该默认开最高配。
谁该省，怎么省，省到什么程度还不掉关键质量，这会越来越像系统设计问题，而不是单纯模型选型问题。
这张图也很说明问题。
提速是有的，而且 prefill 和 decode 都有收益。
但它也没有吹得特别满。
序列变长以后，提速会慢慢衰减。
这反而让我更愿意信它。
因为真实世界里，真正能用的方法，通常都不是完美的。
它只是边界清楚，收益清楚，代价也清楚。
这种方法，才最容易进工程。
🛠️ 如果你是开发者，能从这篇论文里拿走什么
我觉得至少有三件事特别值得记住。
第一，别把「已经训完」理解成「已经没法改」。
很多团队现在一看到模型账单高，第一反应还是换模型、压参数、上量化。
这些当然都能做。
但这篇论文提醒你，架构后适配也是一条线。
尤其是你已经在用某个后训练完成的大模型，又不想推倒重来时，这条线很值钱。
第二，做效率优化时，别动不动就追求全局平均。
论文这里特别有启发的一点，就是它没有粗暴追求「所有专家更均匀」。
它知道老模型原来的专家分工，本身就是能力的一部分。
这和很多 agent 系统也一样。
别为了让流程看起来整齐，就把原本有效的非均匀结构抹平。
第三，降本最怕的，不是方法不新。
是方法对旧系统侵入太大。
ZEDA 这套思路为什么讨巧，就在于它很克制。
它没有要求你从零再来一次。
它是顺着已有系统往前拱一步。
很多能真正上线的改进，最后拼的就是这个。
🏢 如果你是企业，更该看懂这背后的第二层意思
企业做 AI，最容易踩的一个坑，是把注意力全放在模型能力排行榜上。
今天看 Qwen，明天看 Claude，后天看 GPT。
这当然重要。
但真到了业务里，最后会越来越卡在另一层。
同样的模型能力，能不能被你用更低成本、更稳速度、更可控的方式跑出来。
这篇论文本质上就在证明，答案是能。
而且这件事，值得被单独当成一个优化层来做。
你往后看，很多企业级 AI 系统都会遇到类似问题。
哪些请求该走高配模型。
哪些步骤该并行。
哪些节点必须复核。
哪些路径要做降级。
哪些输入可以走便宜路线。
这些问题表面看不如「模型又涨了几分」那么热闹。
但它们才真正决定一套 AI 系统能不能规模化。
📌 最后一句
所以我看完这篇论文，脑子里留下来的不是一个学术名词。
而是一句特别工程的话。
别总想着把模型做得更强。
很多时候，更值钱的是把算力花得更像个样子。
如果你最近正好在做多模型协作、MoE 推理优化，或者企业里的 AI 系统降本，这篇论文很值得精读。
它给的不是一个花哨故事。
它给的是一条很现实的路。
顺着这条路往下走，后面就不只是论文问题了。
会变成工程平台问题。
比如模型路由、失败重试、链路观测、权限治理、成本控制，这些东西最后都得补上。
这也是为什么，像胜算云这样的平台型思路会越来越重要。
不是因为它替你发明模型。
而是因为当你真的把 AI 用进业务里，很多团队缺的不是再多一个 demo。
缺的是把这些能力接起来、稳下来、跑起来的底层支撑。
如果你也在看这条线，可以顺手看看胜算云。
有些问题，越早按系统工程来解，后面越省事