在单张 H100 上部署一个 200 亿参数的模型，听起来像是把大象塞进冰箱。传统稠密模型如 Qwen3-32B 需要约 64GB 显存才能放下权重，而 GPT-OSS-20B 虽然总参数达到 20.9B，却只激活其中约 3.61B 参数，峰值显存占用比 Qwen3-32B 低约 31.7%。这个差距来自混合专家（MoE）架构：每个 token 只经过少数专家，而不是全部参数。但 MoE 并非没有代价——路由决策、负载均衡和专家并行都会引入额外开销，甚至可能让首 token 延迟（TTFT）高于稠密模型。
GPT-OSS 是 OpenAI 发布的开源权重 MoE 模型，其配置显示每个 token 会路由到 128 个专家中的 4 个（num_experts_per_tok=4），同时每个注意力头附加了可学习的 attention sinks 以支持最长 131k token 的序列。本文以 GPT-OSS-20B 为例，拆解它的路由机制如何工作，稀疏专家与共享专家如何分工，以及这些设计在推理部署中如何影响显存、吞吐与质量。我们会看到一个贯穿全文的场景：一家公司希望用单张 H100 提供高并发的代码补全服务，它需要在延迟、吞吐和显存之间做出选择。
为什么需要 MoE：稠密模型的算力浪费
稠密 Transformer 的每一层都对所有 token 执行相同的矩阵乘法，无论这个 token 是常见的标点符号还是复杂的数学表达式。这导致两个问题：一是模型总参数越大，推理时的计算量越大，即使许多参数对当前 token 的贡献微乎其微；二是显存必须容纳全部参数，而激活的参数比例却很低。工程上通常用“激活参数”衡量推理成本，但稠密模型的激活参数等于总参数，没有任何节省。
MoE 的直觉是：让不同的专家网络专门处理不同类型的 token，路由网络决定每个 token 应该交给哪些专家。这样，总参数可以做得很大（提升容量），但每个 token 只激活一小部分（控制计算量）。GPT-OSS-20B 的激活参数仅占总参数的 17.3%，意味着大部分权重在推理时处于休眠状态。
然而，MoE 引入了一个关键问题：如果路由分配不均，某些专家会过载，而其他专家闲置，导致计算资源浪费，甚至影响模型质量。传统 MoE 如 Switch Transformer 使用辅助负载均衡损失来缓解，但 GPT-OSS 采用了不同的设计——共享专家与稀疏专家的组合，我们稍后会看到它如何改变路由的负担。
GPT-OSS 的 MoE 层结构：稀疏专家与共享专家的分工
GPT-OSS 的每个 Transformer 块中，注意力层之后是一个 MoE 前馈层。根据其配置，MoE 层包含 128 个专家，每个 token 选择其中 4 个。但与经典 MoE 不同，GPT-OSS 的专家分为两类：稀疏专家和共享专家。
稀疏专家是传统意义上的专家，每个 token 只激活其中少数几个。共享专家则不同——它始终被激活，不参与路由选择，相当于一个稠密前馈网络。这种设计最早在 DeepSeekMoE 中提出，其论文指出，将公共知识（如语法规则、常见搭配）压缩到共享专家中，可以让稀疏专家更专注于细粒度的专门知识，从而提升专家专业化程度。
在 GPT-OSS 中，共享专家的数量并没有在公开配置中单独列出，但可以推断其 MoE 层包含一个共享专家和 127 个稀疏专家，或者类似的比例。这种结构的关键在于：共享专家承担了所有 token 都会用到的通用计算，而稀疏专家则根据 token 的内容进行分流。
这种分工对推理的影响是双面的。一方面，共享专家的存在确保了每个 token 至少经过一个稳定的计算路径，避免了路由错误导致的灾难性遗忘；另一方面，共享专家始终参与计算，增加了每个 token 的固定计算量，使得激活参数比例并不完全等于稀疏专家的激活比例。GPT-OSS-20B 的激活参数为 3.61B，如果共享专家参数较大，那么实际计算量会比纯稀疏路由更高，但换来的是更稳定的质量。
路由机制：从 Token 到专家的决策过程
路由机制是 MoE 的核心决策点。GPT-OSS 使用 TokenChoiceTopKRouter，这是一种基于 token 选择的 Top-K 路由。每个 token 的隐藏状态通过一个线性层（router）映射为 128 个专家上的 logits，然后取最高的 4 个作为激活专家。这个过程可以形式化为：
对于 token 的隐藏状态 ，路由器计算 ，其中 是路由权重矩阵， 是长度为 128 的向量。然后取 中最大的 4 个值对应的专家索引，并将这些专家的输出加权求和，权重为 softmax 归一化后的路由概率。
这个流程中，路由决策发生在每个 token 上，而不是每个序列。这意味着同一序列中的不同 token 可能被路由到不同的专家，导致专家间的计算负载不均衡。为了缓解这个问题，GPT-OSS 在训练时使用了辅助负载均衡损失（router_aux_loss_coef=0.001），该损失鼓励每个专家接收大致相同数量的 token。
在推理时，路由决策是确定性的（greedy），但负载均衡损失已经影响了训练后的路由器分布，因此推理时通常不会出现极端不平衡。然而，如果输入分布与训练分布差异较大（例如代码补全场景中大量出现特定语法），某些专家可能仍然会被过度使用，导致计算热点。
负载均衡与路由质量：质量与效率的平衡
负载均衡不仅影响计算效率，还影响模型质量。如果某些专家过载，它们的输出可能不够稳定，因为训练时这些专家看到的 token 分布较窄；而如果某些专家几乎不被使用，它们的参数可能没有得到充分训练，导致路由到它们的 token 质量下降。
GPT-OSS 的辅助损失系数为 0.001，相对较小，这表明它更倾向于优化路由质量而非严格均衡。相比之下，Switch Transformer 曾使用更高的系数来强制均衡，但可能牺牲了路由的准确性。GPT-OSS 的设计权衡是：允许一定程度的负载不均，以换取更精准的专家选择。
在推理部署中，负载不均会直接影响吞吐。如果 128 个专家分布在多个 GPU 上，某个 GPU 上的专家过载会导致该 GPU 成为瓶颈，拖慢整体生成速度。因此，在生产环境中，负载均衡不仅是一个训练目标，还需要在部署时通过专家并行策略来应对。
推理中的专家并行与显存优化
GPT-OSS-20B 的总参数为 20.9B，在 bf16 精度下权重占用约 42GB，单张 H100（80GB）可以放下，但加上 KV Cache 和激活值后，显存会变得紧张。专家并行（Expert Parallelism）是 MoE 模型常用的分布式策略：将不同的专家放置在不同的 GPU 上，每个 GPU 只存储一部分专家权重，从而降低单卡显存压力。
在 GPT-OSS 中，由于专家数量多达 128，专家并行可以很自然地切分。例如，使用 8 张 GPU，每张 GPU 放置 16 个专家。但专家并行需要处理 all-to-all 通信：每个 token 的路由结果可能指向不同 GPU 上的专家，因此需要将 token 的隐藏状态发送到对应的 GPU，计算后再收集回来。这种通信开销是 MoE 推理延迟的重要来源，尤其在单机多卡场景下。
对于单卡部署，专家并行不适用，但可以利用 MoE 的稀疏性来降低显存。GPT-OSS-20B 在单张 H100 上可以运行，因为激活参数只有 3.61B，计算量远小于稠密模型，但权重仍然需要全部加载。如果使用更小的专家并行度，例如将专家分布在多张卡上，可以进一步降低单卡显存，但会增加通信延迟。
一个部署决策是：选择单卡运行全部权重，还是多卡专家并行。单卡简单，但显存占用高，且无法利用多卡的计算能力；多卡专家并行可以提升吞吐，但通信开销可能抵消计算优势。GPT-OSS 的部署分析论文指出，在单张 H100 上，GPT-OSS-20B 的解码吞吐比 Qwen3-32B 高约 31.8%，但 TTFT 更高，因为路由和专家调度增加了预填充阶段的计算。
与传统 MoE 的对比：共享专家的价值
传统 MoE（如 Mixtral 8x7B）没有共享专家，所有专家都是稀疏的。GPT-OSS 引入共享专家后，与经典 MoE 相比有几个关键差异：
- 计算模式：经典 MoE 中每个 token 只经过 Top-K 个专家，而 GPT-OSS 额外经过一个共享专家，因此计算量略高，但共享专家可以处理通用特征，减少稀疏专家需要覆盖的范围。
- 路由压力：经典 MoE 的路由器需要区分所有 token 的细微差别，而 GPT-OSS 的路由器只需要将 token 分派到专门化的专家，因为通用部分已被共享专家吸收。这可以降低路由难度，提升路由准确性。
- 显存占用：共享专家增加了总参数，但激活参数也相应增加。GPT-OSS-20B 的激活参数为 3.61B，如果去掉共享专家，激活参数可能更低，但质量可能下降。
下表总结了 GPT-OSS 与传统 MoE 在关键维度上的对比：
| 维度 | GPT-OSS（共享专家） | 传统 MoE（如 Mixtral） |
|---|---|---|
| 专家类型 | 稀疏专家 + 共享专家 | 全部稀疏专家 |
| 每 token 计算 | Top-4 稀疏专家 + 1 共享专家 | Top-2 稀疏专家（Mixtral） |
| 路由难度 | 较低（共享专家承担通用知识） | 较高（需要区分所有 token） |
| 激活参数比例 | 17.3%（GPT-OSS-20B） | 约 12.5%（Mixtral 8x7B） |
| 显存占用 | 较高（总参数更大） | 较低 |
| 质量表现 | 相同激活参数下可能更优 | 依赖路由质量 |
| 部署复杂度 | 共享专家增加少量计算 | 纯稀疏路由更简单 |
这个对比显示，GPT-OSS 选择了用更多激活参数换取更稳定的路由质量，而传统 MoE 则更激进地追求稀疏性。在代码补全场景中，如果输入包含大量重复的语法结构，共享专家可以高效处理这些模式，而稀疏专家则专注于特定 API 调用或逻辑片段，从而提升生成质量。
推理流程中的路由与专家计算
下图展示了 GPT-OSS 在推理时单个 token 的完整流动过程：
flowchart TD
A[输入 token] --> B[注意力层]
B --> C[路由计算]
C --> D{选择 Top-4 稀疏专家}
D --> E[稀疏专家 1]
D --> F[稀疏专家 2]
D --> G[稀疏专家 3]
D --> H[稀疏专家 4]
B --> I[共享专家]
E --> J[加权求和]
F --> J
G --> J
H --> J
I --> J
J --> K[输出]
在这个流程中，token 首先经过注意力层，然后并行计算路由 logits 和共享专家的前馈输出。路由 logits 经过 softmax 后选择 Top-4 稀疏专家，这些专家的输出与共享专家的输出相加（或拼接后线性变换），得到 MoE 层的最终输出。
值得注意的是，共享专家的计算与路由决策是并行的，因为它不依赖路由结果。这可以在一定程度上隐藏路由延迟，但稀疏专家的计算必须等待路由完成。在预填充阶段，由于需要处理大量 token，路由和专家计算可以批量进行，但每个 token 的路由结果不同，导致专家计算需要按 token 分组，增加了调度复杂度。
在解码阶段，每个 step 只生成一个 token，路由和专家计算串行执行，因此路由开销直接增加延迟。GPT-OSS 的 TTFT 较高，部分原因正是路由和专家调度的额外计算。
部署中的权衡：显存、吞吐与质量
在实际部署中，选择 MoE 模型需要权衡三个维度：显存占用、吞吐量和生成质量。GPT-OSS-20B 在单张 H100 上提供了比稠密模型更高的解码吞吐和更低的能耗，但它的 TTFT 较高，且总参数较大，显存占用依然不低。
以下对比表总结了 GPT-OSS-20B 与稠密基线在部署关键指标上的差异（基于 H100 bf16 单卡测试）：
| 指标 | GPT-OSS-20B | Qwen3-32B | Yi-34B |
|---|---|---|---|
| 总参数 | 20.9B | 32B | 34B |
| 激活参数 | 3.61B | 32B | 34B |
| 峰值显存 | 较低（约低 31.7%） | 高 | 高 |
| 解码吞吐 | 高（约高 31.8%） | 基准 | 接近基准 |
| TTFT | 较高 | 较低 | 较低 |
| 能耗/千 token | 低（约低 25.8%） | 基准 | 接近基准 |
这些数字来自一篇部署分析论文，它只评估了部署特性，没有评估质量。因此，我们不能断言 GPT-OSS-20B 的质量优于 Qwen3-32B，但可以确定在单卡推理时，MoE 的稀疏性带来了显著的吞吐和显存优势。
然而，这些优势是有条件的。论文的测试上下文长度为 2048 token，解码 64 token。如果上下文更长，KV Cache 会占用更多显存，MoE 的优势可能缩小，因为 KV Cache 的大小与总参数无关。此外，如果使用采样而非 greedy 解码，路由的随机性可能增加，但吞吐差异不大。
路由机制的失败模式与可观测性
MoE 路由机制并非没有缺陷。在推理部署中，常见的失败模式包括：
- 路由分布偏移：如果输入分布与训练分布不同（例如代码补全中出现了训练时罕见的语言），路由器可能产生不准确的 logits，导致 token 被路由到不合适的专家，生成质量下降。
- 专家过载：即使有负载均衡损失，某些专家仍可能因输入模式而过度使用，导致计算热点，降低吞吐。
- 路由抖动：在采样解码时，同一个前缀可能产生不同的 token，导致路由决策不稳定，影响生成的连贯性。
为了监控这些失败模式，生产环境需要观察以下信号：
- 专家利用率：统计每个专家接收的 token 数量，如果某个专家显著高于平均水平，可能需要调整负载均衡策略或重新训练。
- 路由熵：计算路由概率的熵，如果熵过低（总是选择同一个专家），可能表示路由过于确定，缺乏多样性；如果熵过高，则可能路由不准确。
- 端到端延迟：TTFT 和 TPOT 的波动可以反映路由和专家调度的效率。
GPT-OSS 的 Hugging Face 文档提到，由于 attention sinks 需要访问完整的注意力 logits，SDPA 不被支持，必须使用 Flash Attention 或 Flex Attention。这提示我们，MoE 模型的部署还受到注意力机制实现的约束，路由机制并非唯一的性能瓶颈。
结论：MoE 路由的工程启示
GPT-OSS 的 MoE 架构展示了稀疏专家与共享专家结合的设计思路：共享专家降低路由难度，稀疏专家保持容量扩展。这种设计在推理部署中带来了显著的吞吐和显存优势，但也引入了路由开销和负载均衡问题。
对于工程实践者，选择 MoE 模型时不应只看总参数，而应关注激活参数、路由机制和部署硬件。GPT-OSS-20B 适合单卡或小规模多卡部署，因为它能在显存受限的情况下提供高吞吐。但如果应用对 TTFT 敏感（如交互式对话），MoE 的路由开销可能成为瓶颈，此时稠密模型或更小的 MoE 模型可能更合适。
路由机制的未来改进方向包括：更细粒度的专家划分、动态路由（根据输入调整专家数量）、以及更高效的负载均衡算法。GPT-OSS 的开放权重为社区提供了研究这些问题的平台，但任何改进都需要在质量和部署效率之间重新寻找平衡。