MoE 专家路由如何实现稀疏激活：从 Router 到专家并行的工程权衡

一个超大模型最容易让人产生的误解，是把“总参数量”直接等同于“每生成一个 Token 都要计算全部参数”。对于 Dense Transformer，这种直觉大体成立：每个 Token 经过每一层时，都会执行同一套 Attention 和前馈网络参数。模型越宽、前馈层越大，单 Token 需要完成的矩阵运算也随之增加。

Mixture of Experts，简称 MoE，改变的是前馈网络这一段的执行方式。模型仍然可以拥有很大的总参数容量，但 Router 会为每个 Token 选择少量 Expert，只有被选中的专家参与本次前向计算。DeepSeek-V3 技术报告给出的模型配置就是一个典型例子：报告描述其总参数规模为 671B，而单 Token 激活参数约为 37B。这个数字来自该模型的具体结构，不能推广为所有 MoE，但它清楚展示了稀疏激活希望解决的问题——扩大模型容量时，不让每个 Token 的计算成本与总参数量同步增长。

真正困难的部分也由此出现。Router 必须决定 Token 去哪里；专家分布在不同设备时，系统还要把 Token 搬到正确的 GPU；如果大量 Token 同时命中同一个专家，理论上的稀疏计算优势会被排队、通信和设备空闲吞掉。因此，MoE 的工程问题从来不只是“少算几个 FFN”，而是如何让路由决策、专家专业化和分布式执行同时成立。

MoE 改变的是 FFN 的执行路径，而不是整个 Transformer

标准 Transformer Block 通常可以粗略拆成 Attention 和 FFN 两部分。Attention 负责让当前 Token 与上下文交换信息，FFN 则对每个 Token 的表示做非线性变换。Dense 模型中，同一层里的所有 Token 都经过同一个 FFN 参数集合。

MoE 通常把这个 Dense FFN 替换为一组结构相似的 Expert，并在前面加入 Router。Router 接收当前 Token 的隐藏状态，计算它对不同专家的路由分数，再根据 Top-K 规则选出少量专家。假设一层有 64 个专家，而配置为 Top-2，那么某个 Token 在这一层只需要经过两个被选中的专家，而不是执行全部 64 个专家。

被选中的专家输出通常还要按照路由权重组合，再回到 Transformer 主干继续后续层。这里的稀疏性是“按 Token、按层”发生的：同一个请求里的不同 Token 可以命中不同专家，同一个 Token 在不同 MoE 层也可能走完全不同的专家组合。因此，MoE 并不是把整个请求固定交给某个子模型，也不是简单把模型切成几个互斥分区。

flowchart TD
  A[一批 Token 进入 MoE 层] --> B[Router 计算专家分数]
  B --> C[为每个 Token 选择 Top-K 专家]
  C --> D[按目标专家重新分组 Token]
  D --> E{专家是否在本地 GPU}
  E -->|是| F[本地 Expert 计算]
  E -->|否| G[All-to-All 发送到目标 GPU]
  G --> H[远端 Expert 计算]
  H --> I[结果跨卡返回]
  F --> J[按路由权重合并输出]
  I --> J
  J --> K[进入下一层]

这张图里，Router 的矩阵计算只是开始。真正部署到多卡环境后，Token 还会经历分桶、跨卡发送、专家计算、返回和重组。只看“每个 Token 激活几个专家”无法判断服务是否真的高效，因为稀疏计算节省的是算术量，而数据交换和负载不均可能成为新的最长路径。

Top-K Routing 如何把总参数容量转化为稀疏计算

Router 可以理解为一个轻量的分配器。它根据 Token 当前隐藏表示，为每个专家产生分数，然后选出分数最高的 K 个专家。Top-1 Routing 只选择一个专家，执行路径简单；Top-2 或更大的 K 会让一个 Token 同时利用多个专家，通常能提供更丰富的组合，但计算量和通信量也随之增加。

Switch Transformer 是 Top-1 路由的代表性工作之一。其设计重点之一就是简化稀疏模型的路由和通信：每个 Token 只进入一个专家，使每层的专家计算更接近一次明确的分派。这个选择不是说明 Top-1 在所有任务上都最好，而是展示了 MoE 的一个核心工程旋钮——K 越小，每个 Token 激活的专家越少，计算和通信通常越低；K 越大，模型可以组合更多专家表示，但每个 Token 的实际执行成本也会上升。

Router 分数本身还不能完全决定系统行为。训练和推理实现通常还要考虑每个专家一次能接收多少 Token，也就是容量约束。如果一个 Batch 中大量 Token 都想进入同一个专家，而该专家的容量有限，多出来的 Token 必须采用特定处理策略。不同模型和框架可能选择丢弃、重路由、扩大容量或等待，因此“Top-2”并不意味着所有 Token 永远都能无条件执行最理想的两个专家。

在在线推理中，Router 还有一个额外特点：请求分布会持续变化。白天流量可能以编程问答为主，晚上转为通用聊天；某个热点事件也可能让输入模式突然集中。即使训练阶段整体专家利用率均衡，某一个时间窗口里的真实 Batch 仍可能强烈偏向少数专家。这也是训练损失上的均衡指标不能直接代表生产系统负载的原因。

专家并不等于“数学专家”或“编程专家”

解释 MoE 时，经常把 Expert 比作数学、编程、语言等不同领域的专家。这种类比可以帮助理解“参数分工”，但不能当成真实结构描述。实际训练中，专家学习到的分工往往由数据、优化过程和路由机制共同决定，未必对应人类可命名的学科边界。

某些专家可能更敏感于特定语法模式、表示空间区域、语言特征或中间计算需求，也可能存在多个专家学习到相似模式。Router 的目标不是先理解“这是数学题”再寻找一个名为数学的模块，而是根据隐藏表示学习一个能改善训练目标的稀疏分配规则。

专家重复学习相似知识会降低参数利用效率。DeepSeekMoE 所讨论的 Fine-Grained Expert Segmentation 和 Shared Expert Isolation，正是试图重新组织这种分工。细粒度专家把较大的专家拆成更多较小单元，使 Router 能组合更灵活的专家集合；Shared Expert 则把一部分更通用的能力放到始终参与计算的共享路径，让 Routed Expert 更专注于差异化表示。

这种设计仍然存在成本。Shared Expert 始终执行，因此它属于每个 Token 的固定计算；细粒度专家增加后，路由、专家映射和设备放置也会更复杂。论文中报告的模型质量和计算量结果应理解为具体实验配置下的证据，而不是“只要增加 Shared Expert 就一定更快”。工程上需要一起评估激活专家数量、每个专家规模、Router 开销和专家并行方式。

负载均衡为什么同时是模型问题和系统问题

假设 8 个专家平均分布在 8 张 GPU 上。理想情况下，一个 Batch 的 Token 大致均匀地落到各专家，每张卡收到相近工作量，计算完成时间也比较接近。现实中 Router 可能让一个专家收到远多于平均值的 Token。此时即使其他 GPU 已经完成计算，它们也必须等待最忙的设备，整个 MoE 层才能继续。

训练阶段的第一类风险是专家利用不均。少数专家持续收到大量样本，会得到更频繁的参数更新；其他专家长期接收不到足够 Token，可能难以形成有效分工。传统 MoE 因此常加入辅助负载均衡损失，让 Router 在优化主任务之外，还承担“不要把所有 Token 都送到少数专家”的约束。Switch Transformer 使用的负载均衡设计就属于这一类思路。

但辅助损失也引入了目标冲突。Router 认为某个专家最适合当前 Token，而均衡目标可能希望它选择另一个较空闲的专家。平衡系数太弱，热点仍然明显；太强，则可能让路由更多服务于统计均匀，而不是模型任务。DeepSeek-V3 技术报告描述了通过路由偏置调节专家负载的策略，希望降低对额外辅助损失的依赖。这里更值得关注的不是某个具体方法是否“彻底解决”均衡，而是负载控制可以作用在不同层面：训练目标、Router 分数、专家容量和运行时调度都能改变最终分布。

所附 2026 年研究进一步把问题延伸到运行时：训练时均衡，并不能保证后训练或线上请求中的每个 Batch 都均衡。真实流量可能造成持续热点，系统因此开始探索根据当前专家负载动态调整执行或放置策略。另一类工作则继续改进训练阶段的长期均衡目标。两条路线分别处理“模型学会怎么分”和“系统面对已经发生的不均衡怎么办”。

Expert Parallelism 把少计算变成了更多通信

超大 MoE 的全部专家权重往往无法合理放在一张 GPU 上。Expert Parallelism，简称 EP，会把不同专家分配到不同设备。这样每张 GPU 只保存一部分专家，整体集群共同承载完整模型容量。

问题在于 Router 的选择不受物理位置限制。GPU 0 上产生的 Token 可能命中 GPU 5 上的专家，同一个 Batch 的 Token 也可能散落到多张卡。系统必须先按专家目标重新排列 Token，再执行 All-to-All 通信，把它们发送到对应设备；专家计算完成后，还需要进行反向的数据交换，把结果送回原来的序列位置。

这使 MoE 具有一个看似矛盾的性质：与同等总参数规模的 Dense 模型相比，它可以减少每个 Token 的有效专家计算，但通常会增加跨设备数据交换和调度复杂度。当网络带宽不足、设备拓扑不合适或路由分布偏斜时，通信时间可能抵消稀疏计算节省。

DeepSpeed-MoE、FasterMoE 以及后续推理系统关注的重点之一，就是如何把专家放置、通信和批处理做得更高效。用户提供的 vLLM Expert Parallel Deployment 文档也说明了现代推理系统已经把 EP 作为 MoE 部署能力的一部分。但“支持 EP”只代表具备执行路径，不代表任何集群配置都能获得理想吞吐。GPU 间互联、节点间网络、专家数量、Top-K、Batch 规模和请求分布都会改变最终结果。

Dense、MoE 和不同路由配置该怎么比较

MoE 的优势常被压缩成一句“参数很多但计算很少”，这不足以支持架构决策。真正需要同时考虑总权重存储、激活参数、跨卡通信、负载波动和部署复杂度。

方案	单 Token 参数执行特征	权重存储	主要优势	主要风险	更适合的条件
Dense Transformer	每层执行固定完整参数路径	需要保存全部模型权重	执行规则稳定，批处理和并行相对直接	总参数扩大时计算成本同步增长	模型规模可控，追求部署简单和稳定延迟
Top-1 MoE	每个 Token 每层选择一个 Routed Expert	仍需保存全部专家权重	激活计算较低，路由和通信相对简化	单专家容量与热点更敏感	希望扩大参数容量，同时严格控制激活专家数
Top-2/Top-K MoE	每个 Token 组合多个专家输出	仍需保存全部专家权重	专家组合更灵活	激活计算、通信和结果合并成本更高	模型质量收益能覆盖额外系统成本
Shared + Routed Experts	共享专家固定执行，路由专家稀疏执行	保存共享与全部路由专家	通用能力与差异化专家可分开承载	固定计算增加，结构与部署更复杂	模型设计阶段能够联合训练并验证专业化效果
多机 Expert Parallel	专家分散到多个设备	集群共同保存全部专家	单设备不必容纳所有专家	All-to-All、跨节点带宽和热点决定性能	具备高带宽互联并能持续优化专家放置

这张表也解释了一个常见误区：MoE 并不会让总权重显存按激活比例自动缩小。一个 6000 亿级总参数模型，即使单 Token 只激活一小部分专家，完整专家权重仍然必须存在于某种可访问的存储层级中。可以通过 Expert Parallelism 把权重摊到多张 GPU，也可以结合其他存储策略，但“本次没有执行”不等于“不需要存储”。

因此，MoE 更准确的价值是提高“参数容量与单 Token 计算量”的解耦程度。它让增加模型容量不必等比例增加每次前向的专家计算，却把原本较简单的 Dense 矩阵路径换成了路由、分派和分布式通信问题。

动态 Batch 下，路由热点会怎样拖慢整个请求

离线训练通常有较大的 Batch，可以在统计上平滑部分专家波动。在线推理则更棘手。连续批处理会不断加入新请求、移除完成请求，每一轮参与计算的 Token 集合都可能变化。Router 对这些 Token 做出决策后，某一轮可能相对均匀，下一轮却突然集中到少数专家。

如果专家容量固定，热点专家会出现排队或容量溢出；如果容量预留过大，又会降低资源利用率。若专家跨节点部署，热点还可能把某条网络链路推到瓶颈。此时 GPU 利用率看起来甚至可能不低，但端到端延迟仍然恶化，因为部分设备在忙于通信或等待最慢专家完成。

Dynamic batching 也不能自动解决这个问题。批量变大可以提高矩阵计算效率，但更大的 Batch 也可能一次产生更多跨卡 Token。是否收益取决于 Router 分布与硬件拓扑。系统需要把“Batch 大小”和“专家负载分布”一起观察，而不是只追求每次塞入更多 Token。

更进一步，专家放置可以根据历史热点做优化。例如把经常同时被访问的专家放到通信成本较低的位置，或者复制少数热点专家以增加服务能力。这类策略会引入模型副本一致性、显存占用和调度复杂度，因此通常需要基于实际流量决定，而不是在模型发布前静态假设哪个专家一定热门。

生产环境应该观察哪些信号

MoE 服务上线后，只看整体 GPU 利用率很难定位问题。至少需要把观测拆成路由层、专家层、通信层和请求层。

路由层应记录每个专家接收的 Token 数、Top-K 选择分布、专家负载方差以及热点持续时间。平均值可能掩盖问题：一天整体均匀，不代表某个五分钟窗口没有严重倾斜。对于动态流量，按请求类型、时间窗口和模型层拆分更有价值。

专家层需要观察各专家执行时间、队列长度、容量利用率和溢出情况。如果某个专家持续慢于其他专家，原因可能不只是被选中次数更多，也可能是它所在设备同时承载了其他工作，或者专家放置造成了不利的内存和计算竞争。

通信层应观察 All-to-All 耗时、发送和接收数据量、跨节点流量以及不同链路的拥塞。MoE 的单 Token FLOPs 下降后，通信占比通常会更值得关注。如果增加 GPU 后吞吐没有线性改善，应检查新增设备是否让更多通信跨越了较慢链路。

请求层仍然要回到用户看到的指标：首 Token 延迟、每输出 Token 延迟、完整响应时间和整体吞吐。一个负载均衡策略可能让专家利用率更漂亮，却增加额外重路由或通信；最终是否值得，必须看这些系统级指标有没有改善。

哪些情况下 MoE 的稀疏优势会明显退化

第一类退化来自小 Batch 或低并发。专家计算被切得太碎时，单个专家收到的 Token 太少，矩阵运算难以充分利用 GPU。Dense 模型虽然计算更多，却可能拥有更规则、更大的矩阵形状，因此在某些负载下实际硬件效率并不差。

第二类来自路由偏斜。少数专家成为热点后，系统性能由最忙的专家决定。即使理论总计算量下降，其他设备空闲等待仍会拉高延迟。训练阶段的辅助均衡只能降低风险，无法保证任何线上流量都不会触发热点。

第三类来自通信。专家跨 GPU、跨节点分布后，Top-K 越大，每个 Token 可能需要发送到更多位置。网络带宽和延迟无法跟上时，All-to-All 会成为主瓶颈。此时增加更多专家或更多设备未必继续提升吞吐。

第四类来自权重容量。稀疏激活减少的是执行计算，不会让未激活专家的权重自动消失。若集群显存不足以合理承载所有专家，就需要更多设备或其他权重存储方案。模型可能“算得起”，但仍然“放不下”。

第五类来自模型与系统目标冲突。为了保持专家均衡而过度干预 Router，可能改变模型原本倾向的专家选择；为了追求模型路由自由，又可能让硬件负载失衡。MoE 部署因此很少存在一个只靠单项指标就能确定的最佳配置。

如何判断一个 MoE 模型是否真的更适合当前服务

首先比较的对象不应只是“671B 总参数对多少 B Dense 参数”，而应是满足相近业务质量要求的具体模型配置。需要测量每 Token 激活计算、完整权重占用、实际 Batch 下专家利用率和跨设备通信。总参数量更大只说明容量更大，并不自动说明服务效率更高。

第二步应在目标硬件上做包含真实路由的基准测试。测试至少覆盖单请求、稳定高并发和混合流量。单请求可以暴露小 Batch 下专家 kernel 效率；稳定并发观察理想批处理能力；混合流量则更容易触发真实专家热点和动态调度问题。

第三步要改变网络边界做对照。如果单机多卡表现很好，扩展到多节点后吞吐明显下降，应重点检查 Expert Parallelism 的通信路径。MoE 对硬件拓扑比普通 Dense 推理更敏感，不能把单机结果直接外推到整个集群。

最后才是讨论是否需要更复杂的动态均衡。运行时重调度、热点专家复制或最少负载路由都有可能改善特定瓶颈，但它们也会增加系统状态和资源成本。只有当观测已经证明专家热点是主要限制因素时，引入动态机制才有明确收益路径。

MoE 真正改变的不是 Transformer 必须完成的所有工作，而是把原本固定的 Dense FFN 路径变成“Router 选择少量参数子集执行”。这使模型可以扩大总参数容量，同时把单 Token 的专家计算控制在较小范围。然而，当专家分布到多张 GPU 后，省下来的计算会转化为新的调度责任：Token 要被准确路由，专家不能长期过载，All-to-All 不能吞掉节省的时间，完整权重还必须被集群容纳。

因此，评价 MoE 推理系统最有价值的问题不是“这个模型总共有多少参数”，而是：在真实请求分布下，每个 Token 实际激活多少专家，路由是否持续均衡，跨设备发送了多少数据，以及最慢专家是否正在决定整个 Batch 的完成时间。只有这几项同时受控，稀疏激活才会从模型结构上的理论优势，变成生产环境中的实际吞吐和成本优势。