K3模型MoE稀疏性：896专家仅激活1.8%

这是注意力机制演进系列的第三篇文章。

第一篇涵盖了序列维度：从 GPT-2 的全注意力到 KV Cache、线性注意力再到 KDA——七年的进展。第二篇涵盖了层间维度：从简单的残差求和到 Attention Residuals 再到 Depth-Attention——以近乎零成本实现的跨层选择性通信。

本文探讨第三个维度：正交计算——当 Transformer 面临"在不减慢推理速度的前提下把模型做大"的需求时，答案是"大多数参数保持空闲"。这是从稀疏注意力到 MoE 再到 Stable LatentMoE 的故事。先从一个数字开始：K3 有 896 个专家，但推理时每个 token 只激活 16 个——仅占 1.8%。

1. 问题的起源：全或无的诅咒

标准 Transformer 隐含一个假设：每个 token 在每一层都必须经过所有参数。

Layer 0: Token -> (Attention + FFN) -> hidden state
Layer 1: Token -> (Attention + FFN) -> ...
...
Layer 92: Token -> (Attention + FFN) -> predict next token

每一层的 FFN 都处理每个 token。"回答一道小学数学题"和"编写操作系统内核代码"激活的是完全不同的认知回路——然而 Transformer 被迫使用相同的参数来处理两者。

这产生了两个致命后果：

参数数量受到约束。 更多参数意味着每次推理需要更多操作——计算成本线性增长。想要更智能的模型？加参数 = 加成本。

计算浪费。 最简单的 token 和最难的 token 消耗完全相同的 FLOPs。

MoE 的解决方案粗暴而有效：准备多组"认知回路"（专家），让每个 token 只调用一小部分。

听起来像常识。但将这种常识转化为工业级稳定、推理高效的模型，花了数年时间。

2. MoE 演进中的三张牌

第一张牌：Switch Transformer（2021，Google）——将 MoE 从实验室搬进工厂

MoE 本身是一个古老的想法（Jacobs 等，1991），但在 LLM 时代之前，由于训练不稳定，它一直困在实验室里。

Switch Transformer（Fedus 等，JMLR 2022）做了两个关键工作：

1. 解决了大规模训练稳定性问题。使用 capacity factor 限制每个专家的 token 数量，用辅助损失来平衡路由负载。
2. 在 C4 上训练了一个 1.6T 参数的模型，推理时激活的参数远少于总数。

但 Switch 使用的是 Top-1 路由——每个 token 只到一个专家。优势是极致的稀疏性（最小激活率）。问题显而易见：如果那个专家失败了（过载或被丢弃），这个 token 就不会产生输出——没有备份。

第二张牌：Mixtral 8x7B（2023，Mistral）——Top-2 成为行业标准

Mistral 于 2023 年底发布的 Mixtral 8x7B 使用了 Top-2 路由——每个 token 从 8 个专家中激活 2 个。

这标志着一个关键设计理念的转变。Top-1 是"把所有鸡蛋放在一个篮子里"。Top-2 开始接受"多花一点计算换取显著更好的稳定性和性能"的理念。8 专家的配置也足够简洁，可以在消费级 GPU 上运行。

Mixtral，总参数 46.7B（活跃 12.9B），在多个基准测试中匹配或接近可比拟的密集模型，同时使用少得多的计算。这证明了 MoE 不仅仅适用于巨型模型——它在中等规模上同样有效。

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

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

细粒度专家分割： 将 N 个专家拆分为 mN 个更小的专家，每个 token 激活 mK 个。这实现了更灵活的组合——不再是由几个大专家处理广泛的知识领域，而是由许多小专家进行精确组装。

共享专家： 从专家池中隔离出 K_s 个"共享专家"，始终激活。这些专家处理每个 token 都需要的基础知识（语法结构常用表达、基本推理框架），而路由专家则专注于领域差异化知识。

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

在早期的 MoE 中，由于路由根据 token 特征选择专家，而所有专家都能看到这些高频模式，所以每个专家都可能学到相同的基础知识（例如，"the"后面可以跟名词）。这不是在浪费参数吗？

共享专家的理念是："把这部分共享的东西抽出来，让所有人使用，不要让路由专家冗余地学习基础知识。"

DeepSeek-MoE 16B 以约 40% 的计算量达到了 LLaMA2 7B 的性能。DeepSeek-MoE 145B 仅使用 28.5% 的计算量就匹配了 DeepSeek 67B。这是第一篇清楚证明"细粒度 + 共享专家"双轨架构在计算效率上具有压倒性优势的论文。

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

3. K3 的 Stable LatentMoE：将 DeepSeek-MoE 的三条路径推向极限

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

路径 1：专家数量从 64 跃升至 896

DeepSeek-MoE 已经让专家变得更小、更多，但 K3 将这一点推到了另一个数量级。

DeepSeek-MoE 16B:   ~64 个路由专家 + 共享专家
K3:                  896 个路由专家 + 2 个共享专家

关键不在于"896 是个大数字"——而在于 896 意味着每个专家有多小。

来算一下。K3 每层有 896 个路由专家，hidden dim = 7168，进入路由专家前的压缩维度 latent dim = 3584，每个专家的中间维度 = 3072。

一个专家 = 两个权重矩阵（3584->3072 + 3072->3584）≈ 22M 参数。

K3 总参数 2.78T。896 专家 × 93 层 ≈ 83,328 个专家。按每个 22M 计算，专家部分……远低于 2.78T。因为专家只是 FFN 的替代品——总参数数量包含了 embedding、所有层的注意力权重、共享专家和其他更大的组件。

但核心逻辑成立：当专家变得足够小，路由不再是语义分配（"叫 Python 专家来"），而是从碎片池中进行特征组装。

这就引出了 K3 最重要的设计理念，也是来自 lilting 频道最有见地的分析——

路由不是"分类器"——而是"计算分配器"

标准的 MoE 理解是："路由器将每个 token 分类到某个领域专家。"这个理解是错误的——至少对于拥有 896 个专家的 K3 来说是这样。

K3 的路由只是一行代码：

scores = Sigmoid(W_r x x)   # W_r: 896 x 7168, x: hidden state
# 取 Top-16，按归一化分数加权组合

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

但这之所以有效，不是因为路由器"智能"，而是因为 x 本身已经被前面各层的 Attention 和 FFN 充分处理过了。正如 BERT 的隐藏状态足够好，好到简单的线性分类器就能完成 NLU 任务——K3 的隐藏状态在到达路由器之前已经通过了数十层处理，本身就是一个高度结构化的表示空间。一个简单的线性投影就足以完成最终的"路由决策"。

从另一个角度看：面对 896 个专家，期望一个简单的线性分类器正确地将每个 token 分配到"完全正确的 16 个专家"，显然过于理想化。路由器的真正工作不是"找出最好的 16 个"——而是在负载均衡约束下，给大多数 token 一个合理的 16 个组合。

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

分位数均衡：896 个专家的负载均衡挑战

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

不干预路由 -> token 涌入少数专家 -> GPU 负载不均衡 -> 一些专家饿死（训练数据不足）

强制均衡 -> 同一输入在训练步骤中被路由到不同专家 -> 专家学到高度相似的东西 -> 伪均衡

K3 的解决方案是分位数均衡：在每个训练步骤中，从路由器分数分布计算分位数阈值——高于此阈值的专家接收目标数量的 token。然后根据与目标的偏差更新每个专家的选择偏置。

关键在于：这个偏置只在训练期间使用。推理时固定。

这意味着 K3 在训练阶段已经完整学习了"如何在 896 个选项中实现负载均衡"，推理时只需用固定偏置来防止灾难性的负载倾斜。

路径 2：潜空间压缩 + 2 个共享专家

Stable LatentMoE 中的另一个关键设计：在进入路由专家之前，将 7168 维的隐藏状态压缩到 3584 维的潜空间。

x (7168) -> W_down -> z (3584) -> 16 routing experts -> u (3584) -> W_up -> RMSNorm -> output

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

但压缩会丢失信息。因此 K3 保留了 2 个始终激活的共享专家——它们在完整的 7168 维隐藏空间上运作，不经过潜空间压缩。

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

2 个共享专家负责"每个人都需要的基础特征"。16 个路由专家负责"每个 Token 特有的差异化特征"。清晰的分工。

路径 3：1.8% 激活率——这不是 bug，这是特性

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

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

K3 的技术报告没有直接提供这个消融实验，但我们可以从架构中推断：

潜空间容量瓶颈。潜空间维度 = 3584。16 个专家已经接近这个维度的信息饱和度。添加更多专家 → 额外的 FFN 容量无法有效通过潜空间瓶颈传输 → 边际收益递减。

跨 GPU 通信成本。896 个专家分布在多个 GPU 上。每个额外激活的专家意味着更多的 GPU 间全互联通信。K3 官方文档明确建议部署需要 64+ 加速器——当你已经在一个如此大规模的集群上做全互联时，每个额外的专家都会增加真实的延迟。

DeepSeek-MoE 已经验证：细粒度 + 少激活 > 粗粒度 + 多激活。与其让 40 个专家每个学一点，不如让 16 个小专家每个把自己负责的部分学好。

1.8% 不是设计目标——它是潜空间瓶颈、通信成本和专家粒度共同塑造的最优收敛点。

4. 一览进化：从 Dense 到 896 专家

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

2021    Switch Transformer    Top-1             64-2048       1         无
2023    Mixtral 8x7B          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               分位数 Top-16     896           16        2

专家数量在增加，但激活数量保持在稳定范围（1-16）——不是因为 16 是什么神奇数字，而是因为潜空间瓶颈和通信成本施加了一个无形的上限

共享专家是一个分水岭——DeepSeek 之前没人这么做；K3 直接继承了这一做法

负载均衡从"辅助损失辅助"演变为"分位数直接控制"——控制精度从"惩罚不平衡"到"直接分配"

每个专家都在变小——从少数几个大专家变成数百个小专家，路由的意义从"领域分类"转变为"特征组装"

5. K3 MoE 的实际性能

数据来自官方博客和技术报告：

总参数量：2.78T，激活参数量：104.2B（约 3.7%）

推理效率：尽管有 896 个专家的路由开销，K3 团队声称通过 Mooncake 解耦推理架构在编程场景下达成了 90%+ 的缓存命中率，以 $0.30/M tokens 的价格（缓存命中定价）提供百万 token 上下文服务

训练效率：引入了完全平衡的专家并行训练，具有静态形状且无主机同步关键路径，使 896 专家规模的训练变得可行

更重要的是，MoE 与其他创新之间的协同效应：KDA（第一部分）+ 注意力残差（第一部分提及）+ Stable LatentMoE（本文主角）→ Kimi K3 相比 K2 实现了约 2.5 倍的整体扩展效率提升。

这不是某个组件的魔法——而是三个正交优化维度的叠加：更便宜的长上下文（KDA）、更智能的层间通信（AttnRes）、以及将计算集中在最需要的参数上（LatentMoE）。

6. 接下来：MoE 的前进之路

K3 已经在 FFN 层实现了条件计算——每个 token 使用不同的 FFN 专家组合。但这只是第一步：

当前的 K3 仍然是 93 层固定深度的 Transformer——每个 token，无论难度如何，都必须穿越全部 93 层。可能的发展方向：

动态深度：简单的 token 提前退出，困难的 token 走得更深（ADEPT，2026）

MoE 化的 Attention：不是所有 token 都需要完整的注意力——SALSA 使用路由器来决定是使用注意力还是循环（2026）

层级别 MoE：不同层可能具有不同的专家架构——靠近输入的层使用共享型，靠近输出的层使用路由型

从 FFN 路由到全模块路由：不仅是选择专家，还要选择"这一层应该使用注意力、SSM 还是跳过"——将模型转变为 token 级动态计算图

如果 MoE 的本质是"大多数参数保持空闲"，那么这些方向的本质就是"大多数计算保持空闲"。工程实现完全不同，但哲学上同源。

7. 这对你意味着什么

不要通过"领域分类"来理解 MoE。认为有"数学专家"和"代码专家"的说法是偏离本质的。专家是 FFN 片段——路由器分配的并非语义角色，而是计算资源。这种理解直接决定了你能否设计出高效的路由策略。

不要把"更多专家"等同于"更好"。K3 使用 896 不是因为"需要 896"，而是在细粒度 + 潜空间压缩 + 负载均衡的约束下，896 是训练和推理效率的最优权衡。盲目增加专家 → 负载均衡崩溃 → 伪均衡 → 参数浪费。

不要把 MoE 当作孤立模块。K3 的 2.5 倍扩展效率提升来自 KDA + AttnRes + LatentMoE 的协同效应。MoE 与注意力机制的关系不是"谁取代谁"——而是"多维度同时优化"：水平方向（序列注意力压缩）、垂直方向（层间信息流）、正交方向（选择性参数激活）。

记住三个数字：

1.8% — K3 每个 token 的 FFN 激活率。当前最强开源模型的稀疏性-效率天花板。

28.5% — DeepSeek-MoE 145B 匹配 DeepSeek 67B Dense 所需的计算量分数。细粒度 MoE 的计算效率基准。

90% — K3 API 在编程场景下的缓存命中率。没有这种级别的缓存优化，2.78T 参数的模型绝不可能实现 $0.30/M token 的定价。

Kimi K3: Open Frontier Intelligence — Kimi 团队，2026 年 7 月，技术报告 + 开源权重

Kimi K3 技术博客 — Moonshot AI 官方博客

K3 的路由器从 896 个专家中选取 16 个：一个分配器，而非分类器 — lilting channel，深度架构分析

DeepSeekMoE: Towards Ultimate Expert Specialization — Damai Dai 等，ACL 2024

Switch Transformers: Scaling to Trillion Parameter Models — Fedus 等，JMLR 2022

Mixtral of Experts — Jiang 等，Mistral AI，2024

专业化的幻象 — ACL 2026，实际 MoE 专家行为分析

这是"注意力机制演进"系列的第 3 篇，也是"正交维度"的首篇。三部分共同构成一个完整的坐标系统：水平方向（序列注意力）→ 垂直方向（层间通信）→ 正交方向（选择性参数激活）。下期预告：如果 MoE 将"参数数量"与"推理成本"解耦，下一个被解耦的维度是什么？