十款开放 MoE 模型的路由机制对照
文章基于模型配置核对十款开放 MoE 模型，比较总参数与激活参数、专家数量、每次选择的专家数及共享专家设置。还整理了门控函数和负载均衡方法，覆盖 DeepSeek、Qwen、Mixtral 等系列。
AI 深度解读
「激活参数只有十几 B」不足以说明一个 MoE 模型跑起来要多少资源。每个 token 选几个专家、是否经过共享专家、专家怎样分布，都会改变计算量、显存占用和跨卡通信。
MarkTechPost 对比了 10 个开放 MoE 模型，结论是：选模型不能只看总参数和激活参数，还得读路由配置。这份整理适合拿来建立部署检查表，但它不是统一环境下的性能评测，部分模型的公开信息也不完整。
同样是 MoE，差别藏在哪些配置里
混合专家模型（Mixture-of-Experts，MoE）会为不同 token 调用不同的专家网络。原文列出的模型都采用 token-choice routing，即每个 token 选择自己要经过的专家。
看懂它们，需要区分五件事：可选专家数量、每个 token 选择的数量 top-k、是否有始终参与计算的共享专家、如何给专家打分，以及如何避免请求集中到少数专家。
原文给出的对比如下。参数单位 B 表示十亿，T 表示万亿；专家数只统计路由专家，共享专家单列。
| 模型 | 总参数 / 激活参数 | 专家数 / top-k / 共享专家 |
|---|---|---|
| Mixtral 8x7B | 47B / 13B | 8 / 2 / 0 |
| gpt-oss-120b | 117B / 5.1B | 128 / 4 / 0 |
| Qwen3-235B-A22B | 235B / 22B | 128 / 8 / 0 |
| Qwen3.6-35B-A3B | 35B / 3B | 256 / 8 / 1 |
| Llama 4 Maverick | 400B / 17B | 128 / 1 / 1 |
| DeepSeek-V3 | 671B / 37B | 256 / 8 / 1 |
| DeepSeek-V4-Pro | 1.6T / 49B | 384 / 6 / 1 |
| DeepSeek-V4-Flash | 284B / 13B | 256 / 6 / 1 |
| Kimi K2 | 1.04T / 32B | 384 / 8 / 1 |
| GLM-4.5 | 355B / 32B | 160 / 8 / 1 |
用「路由专家数 ÷ top-k」计算，Mixtral 的路由稀疏度是 4x，Llama 4 Maverick 是 128x。但这个比值没有计入共享专家和其他计算，不能直接当成整模型的提速倍数。
激活参数描述一次计算涉及的规模，不能单独回答模型需要多少显存。
DeepSeek 的路由为什么要把选专家和混合权重分开
DeepSeek-V3 用 sigmoid 给 256 个专家打分，选择其中 8 个，再归一化选中专家的分数。它还给每个专家维护一个偏置，用来调整专家被选中的机会，但不改变最终混合输出时使用的权重。
大白话解释：某个专家太忙，就降低后续 token 选中它的倾向；这个调节不直接改写它在输出里占多大比重。这是其基于偏置的 noaux_tc 均衡机制。
V3 还把专家分成 8 组，先保留 4 组。按原文转述的技术报告，每个 token 最多到达 4 个节点，另有 1 个共享专家始终运行。这里不仅在选计算路径，也在约束跨节点通信范围。
DeepSeek-V4-Pro 将路由专家增至 384 个，却把 top-k 从 8 降到 6；Flash 则是 256 个专家、top-6。两者评分函数改成 sqrtsoftplus，继续使用 noaux_tc，前 3 个 MoE 层采用 hash routing，也就是固定的 token 到专家映射。
这些变化不能仅凭配置判断效果优劣。它们明确展示的是：增加可选专家，与减少每次实际调用的专家，可以同时发生。
其他模型是在不同成本之间做选择
Qwen3 的两个原始 MoE 模型都采用 128 个专家、top-8，取消了 Qwen2.5-MoE 的共享专家，并使用系数为 0.001 的全局批次辅助均衡损失。Qwen3.6-35B-A3B 又改为 256 个专家、top-8，加回 1 个共享专家；配置中的辅助损失系数仍为 0.001，但评分函数未披露。
Llama 4 Maverick 交替使用稠密层和 MoE 层。每个 MoE 层里，一个 token 经过 1 个共享专家，再选择 128 个路由专家中的 1 个。它以 top-1 控制计算量，但公开配置没有给出评分函数和均衡方法。
gpt-oss-120b 使用线性路由器，从 128 个专家中选 4 个，没有共享专家，选中分数经过 softmax。原文称，其 MoE 权重采用 MXFP4，使 117B 模型能够放进单张 80 GB GPU；均衡方法未披露。这里的单卡条件包含权重量化，不能套给其他精度或任意上下文长度。
Mixtral 对 top-k 分数使用 softmax，辅助损失系数为 0.02。Kimi K2 和 GLM-4.5 则使用 sigmoid：前者沿用 DeepseekV3ForCausalLM 架构类，采用 noaux_tc，并加入 alpha 为 0.001 的序列辅助损失；后者采用免辅助损失的均衡路由。
Kimi K2 报告提供了文中少数明确的效果证据：达到相同验证损失时，稀疏度 48 比稀疏度 8 所需 FLOPs 少 1.69 倍。GLM-4.5 则选择 160 个专家并增加层数，侧重深度。两者代表不同取舍，原文没有提供统一条件下的横向胜负。
我的判断
这篇最有用的地方，是把「模型多大」拆成了可以逐项核对的配置。原文标注核验日期为 2026 年 11 月 7 日，但其证据主要来自 config.json、模型卡和技术报告，没有展示作者亲自完成的统一部署测试。
因此，「配置可审计」需要加上信息公开程度这个前提。Qwen3.6 和 Llama 4 缺评分细节，gpt-oss 和 Llama 4 缺均衡细节；原文开头还笼统称 gpt-oss 未公开 gating，但表格又列出了 softmax。更稳妥的读法是按字段确认来源，不把汇总表当作完整实现。
更高稀疏度不等于更低端到端延迟。
更多专家通常增加常驻权重和跨卡 all-to-all 通信；共享专家则让每个 token 都承担一条固定计算路径。Kimi 的结果支持其特定实验条件下的计算收益，无法证明所有模型、硬件和请求负载都获益。原文也没有与同等效果的稠密模型做系统对照。
能拿来做什么
- 自部署前，把总参数、激活参数、专家数、top-k、共享专家和权重精度列成检查表，再核对 GPU 显存与并行方案。原文指出，DeepSeek-V4-Pro 和 Kimi K2 需要多 GPU 专家并行。
- 给 Node 服务选择自托管推理后端时，用实际上下文长度和并发量测延迟、吞吐与显存，不要拿「17B active」直接推算服务成本。
- 比较日常 AI 编程所用模型时，把这份表用于理解部署约束；代码质量、工具调用效果和交互速度，仍需用自己的任务另行验证。