拆解混合专家模型的七种路由机制

MoE 模型每处理一个 token，都要决定把它交给哪些专家网络。MarkTechPost 这篇指南梳理了 7 类路由策略：有的让 token 挑专家，有的让专家挑 token，还有的直接按 token ID 分配。它们影响的不只是回答质量，还有 GPU 之间的通信量和部署成本。

对多数程序员，最有用的结论是：选定模型权重时，你通常已经选定了路由机制。部署前读懂配置，比临时调小激活专家数更靠谱。不过，原文把架构、评分和部署优化放进同一张清单，阅读时需要分清它们解决的问题。

每次只用几个专家，为什么还会贵？

MoE，即混合专家模型（Mixture-of-Experts），会让路由器给专家打分，只运行其中少数，再按权重合并输出。原文以 Mixtral 8x7B 为例：每个 token 可访问的参数规模为 47B，实际激活约 13B。

专家数量可以从 Mixtral 的 8 个，到原文所列 DeepSeek-V4-Pro 的 384 个；每个 token 通常激活 1 到 8 个。模型总参数多，并不代表每次计算都要用上全部参数。

最常见的基线是 softmax top-k：每个 token 给全部专家打分，选出前 k 个，再对选中分数做 softmax，得到混合权重。Mixtral 选 2/8，gpt-oss-120b 选 4/128，Qwen3-235B-A22B 选 8/128。训练时通常加辅助损失，避免少数专家过忙。

Switch Transformer 把 k 降到 1，并为每个专家设置固定缓冲区：

专家容量 = 每批 token 数 ÷ 专家数 × capacity factor。

超出容量的 token 通过残差连接跳过这一层。Llama 4 Maverick 也为每个 token 选择 1 个路由专家，同时运行一个共享专家。

代价不只在计算。多 GPU 专家并行时，token 要被发送到专家所在设备，形成 all-to-all 通信。专家选得越分散，网络开销越难藏进计算过程里。

共享专家、偏置和分组，各自在解决什么？

这几种机制可以叠加使用，并不是互斥选项。

共享专家负责始终运行的公共能力，路由专家负责稀疏激活后的分工。DeepSeek-V3 配置了 1 个共享专家和 256 个路由专家，每个 token 激活 8 个路由专家。原文将 DeepSeek-V4、Kimi K2、GLM-4.5、Qwen3.6-35B-A3B 和 Llama 4 也归入共享加路由的路线，但指出 Qwen3 移除了共享专家。公共能力有人兜底，代价是始终存在一部分计算。

另一个问题是负载均衡。辅助损失能让专家分配更平均，但它的梯度也会参与训练，可能与语言建模目标互相牵制。

DeepSeek-V3 使用 sigmoid 给专家评分，再给每个专家维护一个偏置：忙的降低，闲的提高。偏置只参与 top-k 选择，输出混合权重仍取自未经偏置调整的原始分数。

原文给出的 loss-free balancing 数据是：在 1B 规模下，负载不均衡指标 MaxVio 从 0.72 降到 0.04，困惑度也更低。但文章没有交代完整实验配置，不能据此推算其他规模的收益。GLM-4.5 采用 sigmoid 加无损失均衡；DeepSeek-V4 则把评分函数改为 sqrtsoftplus，保留偏置均衡。

分组限制解决的是通信位置。DeepSeek-V3 将专家分成 8 组，先保留 4 组，再做最终 top-8 选择，并限制每个 token 最多访问 4 个节点。原文转述 DeepSeek 的说法，称这样能让训练计算与通信近乎完全重叠。代价是限制候选专家范围。Kimi K2 则取消分组，设置 n_group=1。

负载分配得整齐，为什么仍可能出问题？

Expert choice 把选择方向反过来：每个专家挑自己的 top-k token。专家拿到固定大小的桶，负载天然整齐，但一个 token 获得的专家数量可以变化。

原文援引论文称，这种方式的训练收敛速度超过 2 倍。问题出在因果语言模型：当前 token 能否被专家选中，可能取决于后续 token 的竞争情况，间接泄漏未来信息。DeepSeek 研究者测得约 10% 的异常损失下降。

训练损失降低，未必代表模型真的学得更好。

原文也承认，配套表格的 10 个模型没有采用 expert choice，它主要用于研究和非因果场景。因此，标题中的「7 种生产策略」需要打个问号。

最后一类其实又包含两件事。Hash routing 按 token ID 分配专家，不使用学习型路由器；原文称 DeepSeek-V4 的前 3 个 MoE 层采用它。Dynamic top-k 则允许每个 token 激活不同数量的专家。SMIDT 将其接入 SGLang，报告 P99 首 token 延迟改善 1.21 至 1.26 倍，但文章没有给出硬件、流量和质量对照条件。

我的判断

这篇指南最有价值的地方，是把质量、均衡和通信成本放到一起看。只比较总参数量和激活参数量，很容易遗漏跨设备传输与热点专家造成的等待。

但这 7 类并不处于同一层级：top-k 是选择规则，sigmoid 是评分方式，共享专家是架构安排，节点限制是通信约束。一个模型完全可以同时采用其中几种。

作者将 sigmoid 加偏置均衡称为 2026 年前沿开放 MoE 的主流方案，这是原文基于所列模型作出的判断，不是本文独立验证的结论。相对辅助损失，它避免了额外均衡梯度；相对固定容量，它也不靠溢出 token 跳层来处理热点。但训练整体均衡，不保证单条序列或线上请求均衡，服务时仍需处理负载问题。

文章没有提供统一条件下的横向测试，不能按表格直接排出优劣。模型配置、论文实验和部署系统的性能结果，也不能当成同一种证据。

能拿来做什么

• 自建模型服务前，先读 config.json，检查专家总数、每个 token 的专家数、共享专家以及 topk_method，再评估显存、并行和通信需求。
• 遇到响应慢或尾延迟高，除了观察计算利用率，也检查专家负载和跨节点通信；训练采用无辅助损失均衡，不代表线上分配一定均匀。
• 想通过降低 top-k 节省成本时，把它作为模型质量实验。原文明确指出，推理时改变 top-k 会改变模型行为，需要同时比较任务效果和延迟。
• 前端或 Node 应用若只是调用模型 API，可将这些知识用于理解选型差异；不要默认接口暴露了路由参数，原文没有提供这类能力说明。