EXAONE 2.0 的技术报告前几天刚出来（8 月 5 号，LG 那边的），我扫了一眼参数表就停住了：总参数 750B，每 token 激活 37B。
就这两个数字。我先撂一句：MoE 被讲得太玄了，它其实没那么难——但“750B 里只用 37B”这句话，我第一次听到是真没懂。账对不上啊，剩下那 713B 在干嘛？睡觉？
先看我第一版画的图。错的。
大模型 750B
│
├── 专家A ┐
├── 专家B ├─ 每次挑一个干活，其它歇着
├── 专家C ┘
...
我当时以为 MoE 是“一堆专家排队，路由器每次派一个最懂的出来答题”。画完自己看着也觉得顺。然后我去想 37B 这个数，卡住了——如果是“每次派一个专家”，激活量应该等于单个专家的大小才对。可报告说容量是前代三倍以上，激活量没跟着涨。我盯着这图看了半天，不对劲。脑内只有羊叫。重画。
真正的结构长这样：
输入一个 token
│
▼
共享部分（每个 token 都走）──► 路由器
│
┌─────────────┼─────────────┐
▼ ▼ ▼
专家① 专家③ 专家⑦
37B 里的一块 37B 里的一块 37B 里的一块
└─────────────┴─────────────┘
│
▼
加起来 ≈ 37B，输出
关键差别就一处：不是“派一个专家”，是每个 token 从一柜子专家里抓几个，把输出加起来。750B 是柜子总库存，37B 是这个 token 实际拎出门的那一袋。下一个 token 来了，拎的可能是另外几件。
懂了那一刻真的咔哒一下扣上了。为什么 750B 跑起来不像 750B 那么贵——算力账只看拎出门那袋，库存再大也不烧卡。为什么容量翻三倍激活量不涨——“见多识广”靠库存，“干活速度”靠袋子大小，两本账分开记的。
打个比方：MoE 是个大律所。客户每来一个问题（一个 token），律所不用全员到场，派三四个最对口的律师来答——但律所的水平，是挂墙上全部律师的总量。所越大，刁钻问题有人对口的概率越高；可你付的律师费，只按出场那几位算。
这比喻有个地方明显漏风，老实标出来：律所里“谁对口派谁”，人是排他的；MoE 里一个专家可以被很多 token 反复抓。而且“加起来”在律所里没有对应物——四位律师不是把意见平均一下出一份稿子，是数学上真的叠加。抓大方向用律所，抠细节回到上面那张图。
顺便说个我之前一直没想通的怪现象，这次一起通了：为什么大家反复念叨 MoE “参数量不等于算力成本”。以前我把这两句当口号分别背，现在看就是同一张图的两条边——750B 那条边决定装了多少知识，37B 那条边决定跑一个 token 烧多少算力。评测涨了不代表推理变贵，容量和成本在这个架构里是松开的。各家都往 MoE 上走也说得通：谁不想库存无限大、袋子不变沉。
报告其它部分我扫得快：256K context，语言从六种扩到十种，Apache 2.0 放权重。都挺扎实，但说实话我兴趣不大——让我停下来画图的就那两个数字。训练流程里有个“面向难度的中期训练”的说法，我还没画明白具体指哪一段，先放这儿，懂了再补。
照例留个自检：现在你能不能不查资料，给一个同行讲明白“为什么 750B 的模型可以只按 37B 的成本跑”？如果讲到一半卡在路由器那格——正常，那格是 MoE 真正的工程难点，路由策略好不好直接决定这柜子专家是宝库还是摆设。下期我打算单独把那格画开。
这玩意儿真的太酷了，一个“抓几个加起来”的设计，把容量和成本两本拧在一起的账拆开了。下期画路由器，想一起琢磨的先自己动手抓个 MoE 的推理 trace 看看，回头对答案。