1.8%就够了：K3的896个MoE专家，为什么激活率这么低反而是好事？

注意力机制演进系列第三篇。

第一篇讲了序列方向（横向）：GPT-2的全量注意力→KV Cache→线性注意力→KDA，一串七年的进化。第二篇讲了层间方向（纵向）：残差简单求和→Attention Residuals→Depth-Attention，零代价做选择性跨层通信。

本文是第三个维度：正交方向------当Transformer遇到"让模型变大但推理不慢"的需求，答案就是"大部分参数不用"。这就是稀疏注意力→MoE→Stable LatentMoE的主线。用一个数字打开：K3有896个expert，推理时每token只激活16个------1.8%。

一、问题的原点：All-or-Nothing的诅咒

标准Transformer有一个隐含假设：每个token在每个layer都要通过所有参数运算。

yaml 复制代码

Layer 0: Token → (Attention + FFN) → hidden state
Layer 1: Token → (Attention + FFN) → ...
...
Layer 92: Token → (Attention + FFN) → 预测下一个token

每一层的FFN要处理所有token。"让你回答一道小学数学题"和"让你写一篇Operating System内核代码"，你用的脑区不一样------但Transformer被迫用同一套参数。

这有两个致命后果：

参数量受限。 参数越多，每次推理必须调用的参数就越多→推理成本线性增长。想让模型更聪明？加参数=加钱。
浪费算力。 最简单的token和最难的token，消耗完全一样多的FLOPs。

MoE的解法粗暴而有效：多准备几套"脑区"（expert），每个token只调用其中一小部分。

听起来像常识。但把这个"常识"变成工业级训练稳定、推理高效的模型，花了好几年。

二、MoE演进的三张牌

第一张牌：Switch Transformer（2021，Google）------把MoE从实验室搬到工厂

MoE本身是个老想法（最早1991年---Jacobs et al.），但在LLM时代之前一直被"训练不稳定"困在实验室里。

Switch Transformer（Fedus et al., JMLR 2022）干了两件关键的事：

搞定了大规模训练的稳定性。 用capacity factor控制每个expert处理token的上限，用auxiliary loss平衡路由负载
在C4数据集上训练了万亿参数模型（1.6T params），推理时激活的参数量远小于总参数量

但Switch用的是Top-1路由------每个token只送一个expert。优势是极端稀疏（激活率极低），问题也很明显：如果一个expert挂了（过载或掉线），整个token就没输出了------因为没备胎。

第二张牌：Mixtral 8×7B（2023，Mistral）------Top-2成为工业标准

Mistral在2023年底发的Mixtral 8×7B，用了Top-2路由 ------每token激活8个expert里的2个。

这是一个关键的设计决策转移。Top-1是"把所有鸡蛋放一个篮子里"，Top-2开始接受"稍微多算一点，但稳定性和效果提升明显"。8个expert的配置也足够简洁------能用consumer级GPU跑。

Mixtral在多个benchmark上以46.7B总参数（12.9B激活参数）的规模，用显著少于同等dense模型的计算量，跑出了旗鼓相当的性能。这证明了"MoE不是只能做超大模型，中等规模也赚"。

第三张牌：DeepSeek-MoE（2024，DeepSeek）------细粒度专家 + 共享专家

DeepSeek-MoE（ACL 2024）做了两个MoE史上最重要的架构创新：

细粒度专家（Fine-grained expert segmentation）： 把N个expert拆成mN个更小的expert，每token激活mK个。让组合更灵活------不用少数几个超大expert负责大块知识，而是用更多小expert做精密组合。
共享专家（Shared experts）： 从总expert池中隔离出K_s个"共享专家"，始终激活。这些专家处理的是所有token都需要的基础知识（语法结构、常见句式、基本推理框架），而路由专家专注领域差异化的知识。

这个设计解决了MoE最大的矛盾------"知识冗余"。

早期MoE的每个expert都可能学到相同的基础知识（比如"the"后面可以接名词），因为路由只根据token特征选择expert，而所有expert都见过这些高频模式。这不就是浪费参数吗？

共享专家的想法："把这部分拆出来，让所有人共享，让路由专家们别重复学基础。"

DeepSeek-MoE 16B用约40%的计算量达到了LLaMA2 7B的性能。145B用28.5%的计算量追平DeepSeek 67B。这是第一次有论文清楚证明了："细粒度+共享专家"的双轨架构在算力效率上有碾压优势。

这也是K3 MoE架构的直接前身。

三、K3的Stable LatentMoE：把DeepSeek-MoE的三条路推到极致

K3的技术报告详细描述了Stable LatentMoE的设计。在DeepSeek-MoE的基础上，它推了三条路：

路径一：专家数量从64跳到896

DeepSeek-MoE已经把expert做小做多了，但K3把这个数字推到了另一个数量级。

vbnet 复制代码

DeepSeek-MoE 16B:    约64 routing experts + shared experts
K3:                   896 routing experts + 2 shared experts

关键不是"896很多"，而是896意味着每个expert小到什么程度。

计算一下。K3每层有896个路由专家，hidden dim = 7168，latent dim（送入routing expert前的压缩维度）= 3584，每个expert的intermediate dim = 3072。

一个expert = 两个权重矩阵（3584→3072 + 3072→3584）= 约22M参数。

K3总共2.78T参数。每层896个expert × 93层 = 约83,328个expert。每个22M参数，那expert这部分的参数是...远不到2.78T。因为expert只是FFN里的替换件------总参数量包括了embedding、所有层的attention权重、shared experts等更大块的东西。

但核心逻辑不变：当expert小到一定程度，路由就不再是"请最懂Python的专家来"的语义分配，而变成了"从碎片池里组装最合适这套特征的FFN"。

这引出了K3最关键的设计哲学，也是lilting文章最精彩的分析------

路由器不是"分类器"，是"算力分配器"

标准MoE的理解："路由器把每个token分类到某个领域专家。"这种理解是错的------至少对896个expert的K3来说。

K3的路由器只有一行：

ini 复制代码

scores = Sigmoid(W_r × x)   # W_r: 896 × 7168, x: 隐藏状态
# 取Top-16, 按归一化scores加权组合输出

一个线性投影 → Sigmoid → Top-16。没有任何复杂操作。

但这能work，不是因为路由器"聪明"，而是因为x本身已经被前面层的Attention和FFN充分加工过。 就像BERT隐藏态已经足够好到让最简单的线性分类器也能做NLU任务------K3的hidden state在进入路由器前经过了几十层加工，已经是一个高度结构化的表示空间。一个线性投影就足够做最后的"分流决策"。

换个角度：如果有896个expert，期望一个简单的线性分类器正确地把每个token分给"恰好正确的16个expert"------这显然过于理想化。路由器的真正工作不是"找到最合适的16个"------而是"让负载均衡的前提下，给大部分token找到一组过得去的16个"。

这就是为什么K3投入了大量工程精力在负载均衡上------

Quantile Balancing：896个expert的负载均衡难题

MoE的路由训练有一个经典困局：

不干预路由→token涌向少数expert→GPU负载不均→有些expert饿死（训练数据不足）
强制均衡→同一输入在不同训练步被分到不同expert→expert学到的东西高度相似→伪均衡（Pseudo-balance）

K3的解决方案是Quantile Balancing：在每个训练步，从路由器分数的分布中计算分位数阈值------在这个阈值以上的expert获得目标数量的token。然后根据偏离目标的程度，更新per-expert选择bias。

关键：这个bias只在训练时使用。推理时固定。

这意味着K3在训练时已经有了"如何在896个选择中做到负载均衡"的完整经验，推理时直接用一个固定bias来保证不发生灾难性的负载倾斜。

路径二：Latent压缩 + 2 Shared Experts

Stable LatentMoE的另一个关键设计：进入routing experts之前，先把7168维的hidden state压缩到3584维的latent space。

scss 复制代码

x (7168) → W_down → z (3584) → 16 routing experts → u (3584) → W_up → RMSNorm → 输出

为什么？两个原因：

降低每个expert的参数量和计算量（输入维度减半）
减少路由器需要处理的信息维度

但压缩会丢信息。所以K3保留了2个始终激活的shared expert------它们在完整的7168维hidden space上运行，不经过latent压缩。

最终输出：

scss 复制代码

y = E1_shared(x) + E2_shared(x) + W_up(RMSNorm(u))

2个shared expert负责"每个人都需要的基础特征"，16个routed experts负责"特定token的差异化特征"。分工明确。

路径三：1.8%的激活率------这不是bug，是feature

回到那个数字：896个expert，只激活16个。1.8%。

为什么不是更多？比如32个（3.6%）？

K3的技术报告没有直接给出这个消融实验，但从架构设计可以推断：

latent空间的容量瓶颈。 latent dim = 3584，16个expert就已经接近这个维度的信息饱和了。再加expert→额外供应的FFN容量无法被latent bottleneck有效传递→边际收益递减。
跨GPU通信成本。 896个expert分布在多张GPU上。每增加一个激活的expert，就要在更多GPU间做all-to-all通信。K3的官方文档明确建议64+加速器部署------当你已经在这么大的集群上做all-to-all，每多一个expert就是实打实的延迟增长。
DeepSeek-MoE已经验证过：细粒度+少量激活>粗粒度+大量激活。 与其激活40个expert每人学一点，不如让16个小的expert每个学好自己那部分。

1.8%不是设计目标，而是被latent bottleneck、通信成本和专家粒度共同收敛出来的最优解。

四、一图看演进：从dense到896-expert

css 复制代码

年份    模型                     路由策略        每层专家数    激活数    共享专家

2021    Switch Transformer      Top-1路由        64-2048       1        无
2023    Mixtral 8×7B            Top-2路由        8             2        无
2024    DeepSeek-MoE 16B        细粒度Top-K       ~64           ~6        K_s个
2024    DeepSeek-MoE 145B       细粒度Top-K       ~192          ~18       K_s个
2026    Kimi K3                 Quantile Top-16  896           16        2

趋势是清晰的：

专家数量在增加，但激活数保持在一个稳定区间（1-16个）------不是因为16是魔数，而是latent bottleneck和通信成本做了一个无形的上限
共享专家的引入是分水岭------DeepSeek之前没人做，DeepSeek之后K3直接沿用
负载均衡从"aux loss辅助"进化到"quantile直接调控"------控制精度从"惩罚不平衡"进化到"直接分配"
每个专家在变小------从几个大expert变成几百个小expert，路由的意义从"领域分类"变成"特征组装"

五、K3 MoE的实际表现

从官方Blog和技术报告中提取的数据：

总参数：2.78T，激活参数：104.2B（约3.7%）
推理效率： 尽管有896个expert的routing开销，K3团队声称通过Mooncake解耦推理架构实现了90%+的cache命中率（编程场景），以$0.30/M token（cache-hit）的价格提供百万token上下文服务
训练效率： 引入fully balanced expert-parallel训练，静态shape、无需host同步的关键路径，使得896-expert规模下的训练可行

更重要的是MoE和其他创新的协同效应：KDA（第一篇讲）+ Attention Residuals（第一篇提及）+ Stable LatentMoE（本文主角）的组合→Kimi K3对比K2实现了约2.5倍的整体scaling效率提升。

这不是某一个组件的神奇效果，是三个正交维度的优化叠在一起：更便宜的长上下文（KDA）、更智能的层间通信（AttnRes）、算力集中于最需要的参数（LatentMoE）。

六、MoE的在路上：下一步是什么

K3已经在FFN层做了条件计算（conditional compute）------每个token用不同的FFN专家组合。这只是第一步：

当前K3仍然是93层固定顺序的Transformer------每个token，不管难易，都要走完93层。未来可能的进化方向：

动态深度： 简单token提前退出（early exit），困难token多走几层（ADEPT, 2026）
Attention的MoE化： 不是所有token都需要全量attention------SALSA用router决定用attention还是recurrent（2026）
层级的MoE： 不同层可能有不同的expert架构------靠近输入的层用共享型，靠近输出的层用路由型
从FFN路由到全模块路由： 不只是选expert，而是选"这一层该用attention、SSM、还是跳过"，把模型变成一个token-level动态计算图

如果MoE的本质是"大部分参数不用"，那这些方向的核心是"大部分计算不用"。两者的工程实现完全不同，但哲学同源。

七、这对你意味着什么

三个"不要"：

不要用"领域分类"理解MoE。 想到"数学专家""代码专家"就偏离了本质。expert是FFN的碎片------路由器分配的不是语义角色，是计算资源。这个理解直接决定了你是否能写出高效的路由策略。
不要把"更多expert"等同于"更好"。 K3用896不是因为它"需要896"，而是因为在细粒度+latent压缩+负载均衡的约束下，896是训练和推理效率的最优折衷。盲目加expert→负载均衡崩溃→伪均衡→浪费参数。
不要把MoE看成独立模块。 K3的2.5倍scaling效率提升来自KDA+AttnRes+LatentMoE的协同。MoE和注意力机制之间的关系不是"这个替代那个"，而是"在多层面同时优化"------横向（序列注意力的压缩）、纵向（层间信息的流通）、正交（参数的选择性激活）。

三个"要记住的数字"：

1.8%（K3每token的FFN激活率）------这是目前最强开源模型的稀疏效率上限
28.5%（DeepSeek-MoE 145B达到67B Dense性能所需的算力比例）------这是fine-grained MoE的算力效率基线
90%（K3 API在编程场景的cache命中率）------如果没有这个级别的缓存优化，2.78T的模型根本做不到$0.30/M token

参考来源

Kimi K3: Open Frontier Intelligence --- Kimi Team, 2026年7月，技术报告 + 开源权重
Kimi K3 Tech Blog --- Moonshot AI官方博客
K3's router picks 16 of 896 experts: an allocator, not a classifier --- lilting channel, 深入架构分析
DeepSeekMoE: Towards Ultimate Expert Specialization --- Damai Dai et al., ACL 2024
Switch Transformers: Scaling to Trillion Parameter Models --- Fedus et al., JMLR 2022
Mixtral of Experts --- Jiang et al., Mistral AI, 2024
The Illusion of Specialization --- ACL 2026，MoE专家实际行为分析
GPT-2 × 22580 = Kimi K3（注意力机制演进系列第一篇） --- 知乎「AICDragon」专栏
$续\cdot注意力机制进化：Depth-Attention（系列第二篇）$ --- 微信公众号「AICDragon」

这是「注意力机制演进」系列第三篇，也是"正交维度"的第一篇。三篇一起构成一个完整的坐标系：横（序列注意力）→纵（层间通信）→正交（参数选择性激活）。后续还会有：如果MoE解耦了"参数量"和"推理成本"，那下一个被解耦的维度是什么？