稀疏模型没有消灭复杂度：它把大模型推理变成了调度战争

一台大模型芯片真正要解决的，可能不是“算得有多快”，而是一个更棘手的问题：它能否在正确的时刻，把正确的数据送到正确的计算单元，并且让所有环节同时不被饿死？

这正是稀疏专家混合模型，也就是 Sparse MoE，带来的关键变化。它表面上是一种模型架构，实际上却重新定义了推理硬件的任务。模型不再要求每个 token 经过同一条固定的计算路径，而是先由路由器做判断，再把 token 分发给少数专家。于是，模型获得了更大的参数容量，却不必为每一个 token 激活全部参数。

这听起来像是一次简单的节省计算。但更准确的说法是：MoE 没有消灭复杂度，而是把复杂度从乘加运算转移到了调度、存储、通信和负载平衡。

这也解释了为什么大模型推理芯片很难靠单项指标取胜。算力只是整个系统中的一个水管。模型参数容量、显存带宽、芯片之间的互联、数据输入输出、软件编程能力，以及任务变化时的灵活性，必须彼此配平。任何一项过强，其他环节跟不上，最终都只能得到一台局部极其优秀、整体却无法高效工作的机器。

MoE 的核心不是“专家”，而是选择

理解 MoE 最容易犯的错误，是把它想象成一个密集模型的隐藏层被切成了几块。这个比喻有一定帮助，但并不完整。实际的专家通常是相对完整的前馈神经网络，每个专家都具备自己的参数集合。路由器则根据 token 的表示，为不同专家分配权重，并决定哪些专家真正参与计算。

可以把它想象成一家拥有数百名专科医生的医院。患者进入医院后，并不是所有医生都一起会诊，而是先由分诊台判断患者更适合心脏科、神经科还是感染科。医院因此可以拥有极大的专业能力，但每位患者只占用少数医生的时间。

这里最重要的并不是医生数量，而是分诊台的质量。路由器决定了三件事：某个 token 去哪里，训练过程中哪些专家获得更多机会，以及整个系统的计算资源是否被合理使用。

在许多稀疏 MoE 架构中，路由器会采用 KeepTopK 一类的策略，只保留得分最高的少数专家。假设一个模型拥有 64 个专家，每个 token 只激活其中 2 个，那么从理论上看，单个 token 的专家计算量可以显著下降。但这个“下降”成立的前提是，路由结果能够被高效地执行。

如果一个批次中的 token 被平均分配到各个专家，系统可以像一条组织良好的流水线一样运行。可是，如果大量 token 同时涌向同一个专家，那个专家就会成为拥堵的收费站，其他专家则在等待。此时，模型虽然激活参数很少，却未必能够获得相应的速度收益。

因此，MoE 的稀疏性不是简单地少算一点，而是建立了一种新的计算逻辑：先判断，再计算；先分发，再聚合。 这是一种条件计算，也是一种动态调度。

稀疏模型节省的不是所有计算，而是把计算集中在被认为最有价值的路径上。真正困难的是，判断价值本身也需要系统成本。

“活跃参数少”不等于“系统负担小”

MoE 经常被描述为拥有大量稀疏参数和较少活跃参数。这个区分非常重要，但也容易造成误解。

例如，一个 MoE 模型可能拥有数千亿参数，但每个 token 实际只激活其中的一小部分。推理时，计算单元确实不必对所有专家执行矩阵乘法。然而，为了随时响应路由结果，整个模型的专家参数通常仍然需要加载在设备或设备集群中。这意味着，计算量减少了，容量需求却没有按同样比例减少。

这类似于一家大型图书馆。某位读者只借两本书，并不代表图书馆可以只保存两本书。为了在未来响应不同读者的需求，图书馆仍然要保留完整的藏书。MoE 的优势在于每次只翻开少数几本书，但它的仓库、索引系统和书籍调度网络仍然必须存在。

这形成了一个看似矛盾的硬件需求：

• 模型希望拥有更多专家，以扩大总参数容量。
• 推理过程希望每个 token 只调用少数专家，以降低计算量。
• 系统又必须迅速访问这些分散的专家参数。
• 不同 token 的路由结果可能完全不同，导致内存访问和通信模式高度动态。

在密集模型中，数据流通常比较规整。每个 token 大体经过相同的层，硬件可以提前安排矩阵乘法和内存访问。MoE 则更像一座不断改变路线的城市：每辆车都要先决定去哪个区域，然后穿过相应的道路，最后再汇合到主干道。

所以，MoE 对硬件提出的挑战，不只是峰值算力，而是不规则访问下的有效带宽。如果专家参数放在远端设备，路由后的 token 需要跨芯片传输。如果参数放在本地，又会增加显存容量压力。即使计算单元足够多，若互联带宽不足，专家之间的分发和结果回收仍会成为瓶颈。

这就是“算力、容量、带宽配平”的真正含义。系统不是只要拥有更多发动机就能跑得更快。油箱太小，发动机无法持续工作；道路太窄，车辆无法抵达；仓库太远，装卸时间超过了运输时间，整辆车的性能就没有意义。

负载平衡是一种模型约束，也是一种基础设施约束

MoE 训练中的辅助损失常被理解为一种模型层面的技巧。它鼓励不同专家获得相对均匀的路由负载，避免某些专家过度繁忙，另一些专家长期闲置。

但从系统角度看，负载平衡远不只是为了让训练更稳定。它实际上是在告诉模型：你的选择必须服从底层基础设施能够承受的形状。

假设 1 万个 token 进入一个批次，64 个专家平均分配时，每个专家大约处理 156 个 token。如果路由器把一半 token 都送往其中两个专家，那么这两个专家可能出现排队、缓存溢出和通信拥堵，而其他 62 个专家几乎没有工作。即便总计算量没有改变，系统的完成时间也会由最拥堵的专家决定。

这可以用并行计算中的一个基本事实来表达：整体速度往往由最慢的分支决定，而不是由平均速度决定。

辅助损失试图让路由器避免这种极端集中。它通常会结合路由概率和实际分配情况，对专家的重要性与负载进行约束。这个约束的本质，是在模型的预测目标之外，额外加入一个系统目标：不要让所有 token 都争抢同一个专家。

这里出现了一个深刻的张力。模型可能认为某一专家对当前任务最有帮助，但硬件可能承受不了所有 token 都走这条路径。于是，训练不再只是寻找最准确的函数，也是在寻找一条准确性、稀疏性和可执行性之间的折中路径。

这与现实中的城市交通非常相似。所有车辆都选择理论上最快的道路，未必会得到最快的城市交通。因为当所有车辆同时作出同一个局部最优选择，局部最优就会制造全局拥堵。一个好的路由器不仅要判断“哪个专家最适合这个 token”，还要判断“如果所有相似 token 都这样选择，整个系统是否还能运行”。

因此，MoE 的专家并不一定表现出人类意义上的清晰专业化。某些专家可能在特定 token 类型上表现得更一致，但它们未必分别对应数学、代码、语言或知识等明确领域。专家更像是若干种分布式的计算倾向，路由器则学会在不同上下文中组合这些倾向。

这提醒我们不要用过于简单的方式解释模型内部结构。专家的价值不一定来自标签化的专长，也可能来自它们对某些表示模式、语法关系或上下文状态的稳定响应。

芯片设计的真正对象，是“动态数据流”

如果 MoE 只是减少矩阵乘法，专门优化乘法吞吐的芯片就可能解决大部分问题。但事实并非如此。MoE 把推理变成了一个动态数据流问题，而动态数据流要求硬件具备更广泛的能力。

第一是容量。所有专家参数需要被放置在某处。模型越大，显存、内存或分层存储的压力越高。第二是带宽。路由后的 token 要访问不同专家，参数和激活值必须及时搬运。第三是互联。当专家分布在多个设备上时，路由和聚合会产生大量跨设备通信。第四是灵活性与可编程性。路由模式会随模型结构、批次大小和工作负载变化，固定的数据通路很难覆盖所有情况。

还要加上 IO 带宽。现实中的推理不是芯片在真空中处理一个静态矩阵，而是不断接收请求、读取缓存、生成 token、返回结果。对于长上下文、多用户并发和批处理场景，数据如何进入系统、如何停留在缓存、如何在不同请求之间复用，都会改变实际吞吐。

这也是为什么某个单点指标极高，并不能自动转化为产品竞争力。一块芯片可以拥有极高的计算峰值，却因为内存访问不规则而无法喂饱计算单元；也可以拥有很大的内存容量，却因为互联带宽不足而让专家之间彼此等待；还可以在固定工作负载上表现出色，却在真实模型变化后缺乏编程灵活性。

评估 MoE 硬件时，一个更有用的思路是观察四个连续环节：

1. 选择：路由器能否快速决定 token 的去向。
2. 搬运：token 和专家参数能否以足够低的成本移动。
3. 执行：专家计算单元能否保持高利用率。
4. 汇合：不同专家的结果能否及时聚合，并返回后续层。

任何一个环节的延迟，都可能吞掉稀疏计算节省下来的时间。于是，所谓“MoE 加速”不能只看专家矩阵乘法用了多少周期，而要看一个 token 从进入路由器到完成聚合的全链路成本。

真正高效的推理系统，不是拥有最多的计算单元，而是让计算、存储、通信和调度在同一节奏上工作。

从“峰值性能”转向“可持续性能”

这套分析也给模型工程带来一个直接启示：设计模型时，不能把硬件适配放到最后。专家数量、每个 token 激活的专家数、批次大小、路由策略和容量因子，都会影响实际部署成本。

例如，增加专家数量可能提升参数容量，但也可能造成更分散的访问模式。增加每个 token 激活的专家数，可能提升表达能力，却会增加计算与通信。强行追求完全均匀的负载，也可能损害模型在某些复杂样本上的选择能力。工程上不存在脱离约束的“最优架构”，只有针对特定场景的系统性平衡。

这意味着模型评估至少需要区分三种性能：

理论性能，例如参数量、峰值算力和每秒运算次数。

局部性能，例如专家矩阵乘法的吞吐、单层延迟和显存读写效率。

端到端性能，例如真实请求下的首 token 延迟、每 token 延迟、并发吞吐、能耗和成本。

用户最终感知的是第三种。一个模型即使活跃参数很少，如果路由通信、缓存失配和设备等待占据了大部分时间，稀疏性就只存在于论文的计算量统计中，而不存在于实际服务体验里。

对系统设计者而言，最值得追踪的指标也许不是“芯片理论上能做多少计算”，而是以下几个问题：

• 计算单元有多长时间在等待数据？
• 专家之间的负载差异有多大？
• 路由和聚合占据总延迟的比例是多少？
• 参数容量增加后，带宽和互联是否同步增长？
• 模型更换专家数量或路由策略后，软件是否仍然能够高效执行？

这些问题把注意力从单个部件拉回整个系统。它们也揭示了一个常被忽略的事实：稀疏模型的最大收益，取决于硬件是否擅长处理变化。

Key Takeaways

1. 把 MoE 看成动态调度系统，而不只是参数压缩技术。 评估收益时，同时计算路由、分发、通信和聚合成本。
2. 区分稀疏参数与活跃参数。 每次只激活少数专家，不代表设备只需保存少数专家，也不代表内存容量压力同步下降。
3. 优先观察负载均衡，而不是平均利用率。 最拥堵的专家、最慢的通信链路和最热的缓存路径，往往决定端到端延迟。
4. 用全链路指标评价芯片。 峰值算力必须与容量、内存带宽、互联带宽、IO 和软件灵活性一起考察。
5. 在模型设计阶段引入硬件约束。 专家数量、激活比例和路由策略应当与目标部署平台共同优化，而不是训练完成后再被动适配。

MoE 最值得关注的地方，不是它让模型拥有了多少专家，而是它改变了计算发生的方式。传统模型像一条固定的装配线，每个零件按照相同顺序经过相同工位。MoE 则更像一个庞大的城市交通系统，每个 token 都要在途中选择路线，而全局效率取决于这些局部选择能否彼此协调。

这也重新定义了“更强芯片”的含义。未来的竞争未必属于拥有最高峰值算力的设备，而更可能属于那些能够理解数据流、预测拥堵、管理层级存储，并在动态工作负载下保持稳定效率的系统。

换句话说，大模型推理的终局不是把更多计算塞进更小的芯片，而是让计算不再彼此等待。真正的智能基础设施，最终比拼的不是某个部件能跑多快，而是一整个系统能否在变化中持续保持秩序。