Mixture of Experts / Sparse Scaling 与企业模型架构

本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

• Sparsely-Gated MoE: Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer（论文 2017-01）
• GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding（论文 2020-06）
• Switch Transformer: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity（论文 2021-01）
• ST-MoE: Designing Effective Sparse Expert Models（论文 2022-02）

核心导读

MoE 的原理是用 router 为每个 token 选择少数 expert 子网络，让模型拥有很大的总参数容量，但每次推理只激活一部分参数。这是一种 sparse scaling：总模型很大，active computation 相对受控。Switch Transformer 等工作进一步用 top-1 routing 简化了条件计算和分布式服务复杂度。

它的价值在于突破 dense scaling 中“参数越多、每 token 计算越大”的线性压力，但代价也随之转移。MoE 把成本问题变成 router、expert capacity、load balancing、token dropping、expert parallelism、通信开销、尾延迟和可观测性问题。是否更便宜、更快、更强，必须在真实 workload 下验证，而不能只看总参数量或 benchmark。

金融零售架构可以借用“按任务、风险、成本和 SLO 路由”的思想，但不能把 MoE expert 当成业务专家、权限边界、合规隔离或人工责任主体。底层模型是否是 MoE，只是某条 route 的实现选择；数据权限、RAG 过滤、规则校验、人工复核、审计日志和高风险发布门禁仍必须在系统层显式设计。

核心问题

Dense model 的扩展路径很直接。 增加参数，通常会增加每个 token 的计算量。 模型能力可能提升，但训练成本、推理成本、显存需求和服务复杂度也一起上升。 MoE, Mixture of Experts, 试图回答另一个问题： 能否让模型拥有非常大的总参数容量，但每个 token 只使用其中一小部分参数？ 这就是 sparse scaling。 模型整体很大，但单次激活是稀疏的。 企业关心的问题不是 MoE 是否听起来先进，而是：

• 它是否降低真实 workload 下的 cost per task？
• 它是否稳定满足 p95 / p99 latency？
• 高峰期是否出现 expert hotspot？
• 供应商是否能解释容量、降级和版本变更？
• 它和企业的 model routing、权限隔离、RAG、审计如何配合？

MoE 是模型内部的条件计算架构，不是企业业务路由系统。 这个边界必须一开始就清楚。

论文和技术贡献

Sparsely-Gated MoE 论文提出用 gating network 在大量 experts 中选择少数几个参与计算，使模型容量可以大幅扩展，而每个样本只激活部分专家。 GShard 把条件计算和自动分片结合起来，展示了大规模 MoE 模型在分布式训练中的可行路径。 Switch Transformer 进一步简化路由，使用 top-1 routing，让每个 token 只发送到一个 expert，从而降低通信和计算复杂度。 ST-MoE 关注 sparse expert model 的训练稳定性和实践设计，提醒 MoE 不只是把专家数堆上去。 这些工作共同推动了一个思路： 模型规模扩展不必总是 dense activation。 可以通过 conditional computation，让不同 token 走不同参数路径。

MoE 的基本结构

在标准 Transformer block 中，attention 后通常有 feed-forward network, FFN。 Dense 模型中，每个 token 都经过同一个 FFN。 MoE Transformer 通常把部分 FFN 替换成多个 expert FFN。 每个 token 先经过 router 或 gating network。 Router 根据 token 表示为 experts 打分，选择 top-k experts。 被选中的 experts 计算输出，再按权重合并。

Token representation
  -> router / gating
  -> select top-k experts
  -> expert FFN computation
  -> combine outputs
  -> next layer

flowchart LR
    T[Token representation] --> R[Router / gating]
    R --> E1[Expert 1]
    R --> E2[Expert 2]
    R -. not selected .-> E3[Expert 3]
    R -. not selected .-> EN[Expert n]
    E1 --> C[Combine]
    E2 --> C
    C --> O[Output representation]

这里的 expert 是神经网络子模块。 它不是显式业务专家。 它可能学到某些语言、模式或 token 分布上的专门化，但不等于“AML expert”“信贷 expert”或“客服 expert”。

Sparse Activation

Sparse activation 指每个 token 不激活所有 expert。 如果一个 MoE 层有 64 个 experts，每个 token 只选 top-2，那么该层每个 token 只计算 2 个 expert。 总参数容量很大，但单 token 计算只使用其中一小部分。 这带来两个看似矛盾的事实： MoE 可以拥有非常大的总参数量。 MoE 的激活参数量可能远低于总参数量。 企业选型时不能只看“总参数量”。 更有意义的是：

• active parameters。
• tokens per second。
• p95 / p99 latency。
• memory footprint。
• route stability。
• cost per successful task。
• quality under peak load。

未激活参数也不是零成本。 它们仍需要存储、加载、分片、部署、监控和升级。

Router / Gating 的作用

Router 是 MoE 的交通调度器。 它为每个 token 计算 expert 得分，并选择 top-k experts。 Top-k 可以是 top-1、top-2 或更多。 Switch Transformer 的关键简化是 top-1 routing。 每个 token 只发送到一个 expert，减少通信和组合复杂度。 Router 的质量决定了 MoE 的效率和稳定性。 如果 router 总是选择少数 expert，会造成 expert overload。 如果 router 过于随机，expert 难以形成稳定专长。 如果 router 对输入噪声敏感，推理延迟和输出质量会更不稳定。 训练中通常会加入 load balancing loss，引导 token 在 experts 间更均衡地分布。 但这个 loss 是模型训练目标的一部分，不是企业业务层面的负载均衡。

Expert Capacity

Expert capacity 指一个 expert 在一个 batch 中最多处理多少 token。 为什么需要容量上限？ 因为 router 可能把大量 token 发给同一个 expert。 如果没有上限，该 expert 会成为瓶颈，破坏并行效率。 Capacity factor 控制每个 expert 可以接收多少超过平均负载的 token。 容量太小，token 更容易被丢弃、跳过或降级，质量可能下降。 容量太大，又会增加内存、计算和空闲浪费。 容量设计是 MoE 的核心系统参数。 它影响训练稳定性、吞吐、尾延迟和质量。 企业虽然通常不会直接调底层 capacity factor，但应关心供应商或平台如何处理容量溢出。

Load Balancing

MoE 的效率依赖负载均衡。 理想状态是 token 分布相对均衡，同时 experts 能形成有用分工。 训练中，auxiliary load balancing loss 用于避免 router collapse。 Serving 中，负载均衡影响 p95 / p99 latency。 如果某类请求、语言、长上下文或业务数据总是打到同一组 experts，系统可能出现 hotspot。 平均延迟看起来不错，但尾延迟很差。 金融零售系统往往关心尾部。 客服高峰、工资日支付高峰、欺诈攻击波峰、监管报送截止日前，都可能使真实流量分布偏离训练和压测样本。 因此 MoE 选型必须做 workload-specific pressure test。

Token Dropping 与降级

当某个 expert 达到容量上限时，后续 token 可能被丢弃、跳过 expert 路径、走 residual/fallback，或通过其他机制处理。 在论文和训练系统中，这属于容量控制问题。 在企业生产中，它对应质量和一致性风险。 如果高负载下 token dropping 或内部降级增加，模型可能更容易遗漏长文档摘要中的关键点，生成不完整 JSON，或在高风险拒答上不稳定。 使用商业 API 时，企业未必能看到底层 token dropping。 但可以要求供应商或平台提供：

• 高峰负载质量回归结果。
• p95 / p99 latency。
• timeout、截断和重试语义。
• 版本变更说明。
• 容量和限流策略。
• 是否存在内部降级路径。

如果供应商无法披露内部细节，企业仍可通过黑盒压测评估质量漂移。

Expert Parallelism 和通信成本

MoE 引入 expert parallelism。 不同 experts 可能分布在不同 GPU 或节点上。 Token 需要根据 router 结果跨设备发送到对应 expert，计算后再合并。 这带来并行潜力，也带来 all-to-all communication 成本。 通信可能成为瓶颈。 尤其当 experts 跨节点、batch 分布不均、序列很长或 top-k 较大时。 因此 MoE 的成本不能只看 FLOPs。 还要看：

• GPU memory。
• network bandwidth。
• routing overhead。
• batch scheduling。
• KV cache。
• expert placement。
• failure recovery。

这也是为什么自托管 MoE 的门槛比调用一个 dense model 更高。

为什么 MoE 有效

MoE 有效的第一层原因是条件计算。 不是每个 token 都需要同样的参数路径。 如果模型可以根据 token 表示选择相关 expert，就能在单次计算预算相对受控的情况下提高总容量。 第二层原因是专门化。 不同 experts 可能在训练中承担不同模式、语言、任务片段或表示区域。 这种专门化不是人为命名的业务专长，而是神经网络内部的分工。 第三层原因是规模扩展。 Dense model 扩参数通常提高每 token 计算。 MoE 让总参数量增长更快，而每 token 激活计算增长较慢。 第四层原因是分布式并行。 Experts 可以分布到不同设备上计算，提高大规模训练和服务的可能性。 但有效并不意味着总是更好。 如果路由不稳定、通信昂贵、尾延迟不可控、压测不足或供应商透明度低，MoE 的系统代价可能超过收益。

Dense Model 与 MoE 的取舍

企业模型选型应从 workload 出发。 短问答、长摘要、多轮对话、结构化抽取、代码生成、政策解释、AML narrative 的成本和延迟曲线不同。 MoE 是否适合，需要在这些真实任务上比较。

企业选型要问的问题

选择 MoE 模型或供应商时，不应只问 benchmark。 更关键的问题包括：

• 每次推理的 active parameter 规模大概是多少？
• 是 top-1 routing 还是 top-2 routing？
• 长上下文下 p95 / p99 latency 如何？
• 高峰期是否有内部容量降级？
• 是否支持 streaming、batching、tool use、JSON mode 和 RAG？
• 是否有模型卡、风险说明和版本变更记录？
• 是否能提供按任务的成本和质量指标？
• 是否能在事故时回滚到上一模型版本？
• 多租户数据和权限隔离由哪一层实现？

如果供应商无法解释尾延迟和降级语义，金融零售生产使用要谨慎。

MoE 与企业 Model Routing 的区别

MoE router 是模型内部的神经网络路由。 Enterprise model routing 是系统架构层的业务路由。 二者不能混淆。 企业 model routing 会根据任务、风险、权限、成本、SLO 和用户角色选择模型、工具、RAG 或人审。 MoE router 根据 token 表示选择专家参数。 企业不能假设投诉 token 自动进入“投诉 expert”，AML token 自动进入“AML expert”。 企业风险控制必须在 AI Gateway、IAM、RAG、规则、validator 和 workflow 中显式实现。

flowchart TB
    REQ[Business request] --> BR[Business route: risk / SLO / permission]
    BR -->|Low risk| FAST[Small model / cache]
    BR -->|Policy| RAG[RAG + model]
    BR -->|High risk| STRONG[Strong model + validator + HITL]
    STRONG --> MODEL[Underlying model may be dense or MoE]
    RAG --> MODEL
    FAST --> MODEL
    MODEL --> OUT[Controlled output]

金融零售案例一：客服多任务路由

客服系统包含余额查询、收费解释、投诉、信用卡、贷款、欺诈、密码重置和弱势客户支持。 可以用 MoE 的思想理解“不同输入走不同路径”。 但生产架构应使用显式业务路由：

• 高频 FAQ 走缓存或小模型。
• 政策问答走 RAG + medium model。
• 投诉和争议走 strong model + QA review。
• 账户动作走 tool workflow + approval。
• 弱势客户场景触发特殊服务策略和人工支持。

这里的专家是流程和系统能力，不是 MoE 内部 expert。 这种区分决定了可审计性。

金融零售案例二：AML Investigation

AML investigation 需要多种能力：

• evidence retrieval。
• transaction timeline summarization。
• counterparty network analysis。
• typology checklist。
• policy citation。
• narrative drafting。
• quality and safety review。

这些能力可以通过 workflow 编排、工具、RAG、规则和人工复核组合。 底层模型可以是 dense，也可以是 MoE。 关键不是模型内部是否有专家，而是调查证据、typology、人工责任和 SAR 决策边界是否清楚。 MoE 模型如果用于 narrative drafting，需要验证长文本遗漏率、引用准确率、高风险拒答一致性和 p99 延迟。

金融零售案例三：信贷辅助

信贷流程包含资料完整性检查、收入解释、政策匹配、风险摘要、拒绝原因草稿和客户沟通。 这些子任务可以走不同系统路径：

• 数值和硬规则由 deterministic services 完成。
• 政策来源由 RAG 提供。
• 模型生成摘要和解释草稿。
• validator 检查 fair lending 和 prohibited factors。
• underwriter 做最终判断。

MoE 不能替代这条责任链。 如果供应商宣传“专家模型更懂信贷”，也必须通过业务 eval 和模型风险验证，而不是接受命名。

金融零售案例四：多租户 AI 平台

大型金融集团可能让零售银行、信用卡、财富、支付、风控、合规共用 AI 平台。 MoE 内部 experts 不是多租户隔离。 隔离必须在平台层实现：

• tenant-level auth。
• data access policy。
• retrieval index isolation。
• prompt and tool isolation。
• per-tenant rate limit。
• budget quota。
• audit log。
• encryption and retention policy。

成本分摊也不能只按模型名。 应按 route、token、latency、tool cost、human review 和 business outcome 记录。

评测和压测

MoE 评估不能只看静态 benchmark。 需要真实 workload 下的质量、成本和 SLO 测试。 建议测试集包括：

• 高频 FAQ。
• 长政策问答。
• 投诉争议。
• AML narrative。
• 信贷政策解释。
• 多轮长上下文。
• 结构化 JSON 输出。
• 高风险拒答和升级。

指标包括：

• p50 / p95 / p99 latency。
• time to first token。
• tokens per second。
• timeout rate。
• fallback route rate。
• JSON schema failure。
• citation correctness。
• long-summary omission rate。
• high-risk recall。
• cost per successful task。

如果可能，还要比较低负载和高负载下的质量差异。 这可以间接发现容量溢出、路由热点或内部降级风险。

架构和产品价值

MoE 对企业最大的启发是把“一个模型处理所有任务”的想法拆开。 它说明大规模能力可以通过条件计算和动态路由实现。 但在企业架构层，真正可控的路由应发生在系统边界：

• 任务路由。
• 风险路由。
• 模型路由。
• 工具路由。
• 人工复核路由。
• 成本和配额路由。

MoE 可以是某条 route 背后的底层模型形态。 它不应成为产品需求的起点。 更好的需求写法是： 该任务需要什么质量、延迟、成本、证据、权限、降级和人工责任？ 然后再判断 dense model、MoE model、small model、RAG、规则或 workflow 哪种组合最合适。

局限和误用

第一类误用是把 expert 当业务专家。 MoE expert 是神经网络子模块，不承担业务责任，也不提供显式合规解释。 第二类误用是把 MoE 当天然更便宜。 总参数、激活参数、通信成本、尾延迟、batching 和供应商定价都会影响实际成本。 第三类误用是只看平均延迟。 金融零售工作流常被 p95 / p99 决定体验和 SLA。 第四类误用是把 sparse activation 当质量无损。 路由错误、expert undertraining、capacity overflow 和 token dropping 都可能影响质量。 第五类误用是把 MoE 当多租户隔离。 租户隔离必须由身份、数据、检索、缓存、审计和网络层实现。 第六类误用是认为选了 MoE 就不需要 model routing。 MoE 是模型内部路由。 企业 model routing 是业务风险和成本路由。 层级不同，不能互相替代。

ADR 示例

引入 MoE 模型应形成明确架构决策记录。

这个 ADR 不应把“参数量更大”写成充分理由。 必须证明真实业务任务上的质量、成本和风险改进。

学习验证

读完这篇后，应能完成以下任务：

1. 画出一个 MoE Transformer block，标出 router、top-k experts、combine 和未激活 experts。

2. 解释 top-1 routing、top-2 routing、expert capacity、capacity factor 和 load balancing loss 的作用。

3. 为客服 copilot 比较 dense strong model、dense small model + RAG、MoE model + RAG 和 model routing 混合方案。

4. 设计一组高峰压测样本，覆盖 FAQ、投诉、信贷政策问答、AML narrative 和多轮长上下文。

5. 写一份风险隔离检查，证明系统没有把 MoE expert 当成权限边界。

6. 设计 token dropping 或内部降级的黑盒检测方案，比较低负载和高负载下的遗漏率、JSON failure、拒答一致性和答案漂移。

7. 写一个 ADR，说明是否在企业 AI 平台引入托管 MoE 模型，并明确回滚和高风险 route 的限制。

关键结论

MoE 的核心是 sparse scaling。 模型拥有多个 experts，但每个 token 只通过 router 激活少数 experts。 这样可以扩大总参数容量，同时控制单 token 计算。 它的系统代价是 router、capacity、load balancing、token dropping、expert parallelism、通信和尾延迟治理。 Dense model 更简单，MoE 可能更高效，但是否适合企业要看真实 workload、SLO、成本、供应商透明度和治理能力。 MoE expert 不是权限边界、租户隔离、业务专家或合规责任主体。 金融零售中的风险控制仍必须依赖 AI Gateway、IAM、permission-aware RAG、规则、validator、human review、audit log 和 release gate。 MoE 给架构的启发是条件路由和按需计算，但企业可治理的路由必须在系统层显式设计。

---

SOTA 检查 (2026-07-01)

• MoE 已从"可选架构"变成前沿开源模型的默认形态：2026 年主流开源旗舰几乎全部是 sparse MoE——DeepSeek-V3（671B 总参 / 37B 激活，2024-12）、Llama 4 Maverick（400B / 17B 激活，2025-04）、Kimi K2（1T 总参 / 32B 激活，384 experts 选 8 + 1 shared，MuonClip 优化器，2025-07）；2026-05 的开源模型盘点进一步列出 DeepSeek V4-Pro（1.6T / 49B 激活）、Qwen 3.5（397B / 17B）、Mistral Large 3（675B / 41B）等新一代 MoE 旗舰。本篇"看激活参数而非总参数"的选型原则在这些模型上完全适用。
• 架构主线已从本篇的 Switch top-1 大专家演进为"细粒度专家 + 共享专家"：DeepSeekMoE（2024-01, arXiv 2401.06066）提出 fine-grained expert segmentation + shared expert isolation，DeepSeek-V3（2024-12）实测为 256 routed experts 选 8 + 1 shared expert、sigmoid 门控，并用 auxiliary-loss-free 的 bias 调节负载均衡替代了本篇正文所述的 auxiliary load balancing loss——本篇的 load balancing loss 应视为历史机制，当前 SOTA 是无辅助损失方案。库内配套精读见 docs/llm/day46-finegrained-moe-shared-expert.md（2026-06-30）与 docs/llm/day42-deepseek-v3-deep-dive.md（2026-06-26）。
• Serving 侧的 token dropping / expert capacity 问题已有工程化解法：当前主流是 dropless MoE + 专家并行负载均衡——DeepSeek 开源的 EPLB（Expert Parallelism Load Balancer）已被 vLLM 和 SGLang 集成（按专家激活统计做热点专家复制/重排）；NVIDIA TensorRT-LLM 的 Wide-EP 在 GB200 NVL72 上做大规模专家并行（较小 EP 配置最高 1.8x 单 GPU 吞吐，Red Hat 的 vLLM+llm-d Wide-EP 实践发布于 2025-09）；vLLM 于 2026-05-14 发布 Elastic Expert Parallelism。本篇"要求供应商披露容量溢出与降级语义"的检查项依然成立，但技术上"高峰必然丢 token"的假设已弱化。
• 本篇的框架性结论不随版本过时：MoE expert 不是业务专家/权限边界/租户隔离；企业 model routing（按任务/风险/成本/SLO）与 MoE 内部路由是两个层级；选型看 active parameters、p95/p99 尾延迟、cost per successful task 而非总参数量；高低负载对比的黑盒压测方法——这些是系统层结论，在 2026 年的 MoE 生态中反而更重要（专家并行让尾延迟和热点问题更显性）。
• 新增风险面：MoE 路由本身成为攻击研究对象（如 RouteHijack 等 2026 年 routing-aware attack 论文），印证本篇"router 对输入敏感会带来稳定性风险"的判断——企业侧应把路由稳定性纳入对抗性测试范围。