Paper 09: Mixture of Experts and Sparse Scaling

面向对象: AI PM / AI BA / AI Architect / Enterprise AI Platform Owner。 核心问题: 为什么有些大模型参数量很大, 但每次推理只激活其中一部分? 这种 sparse scaling 对成本、延迟、吞吐、治理和企业架构意味着什么? 一句话结论: MoE 用 router/gating 把 token 路由到少量 expert, 用稀疏激活换取更高参数容量和更低单位计算, 但它把训练稳定性、负载均衡、部署、SLO 和多租户治理变成更复杂的系统问题。

---

Source Anchors

本文重点不是推导训练细节, 而是把 MoE 的底层机制翻译成企业模型选型、成本治理、SLO、风险隔离和金融零售落地判断。

---

核心问题

Dense model 的扩展路径很直观: 参数越多, 每个 token 都要经过更多参数计算。模型能力可能增强, 但训练和推理成本也一起上升。

MoE, Mixture of Experts, 想解决的问题是: 能否让模型拥有很大的总参数容量, 但每个 token 只调用少数几个专家网络, 从而降低每次前向计算的成本?

这就是 sparse scaling 的核心: 总模型很大, 但单次激活是稀疏的。

对企业团队来说, 关键问题不是“MoE 是否更先进”, 而是:

• MoE 是否真的降低你的单位任务成本?
• 路由和专家负载是否稳定?
• 高峰期是否会因为专家热点造成 p95/p99 延迟波动?
• 供应商是否能给出可观测的路由、容量和降级策略?
• 在金融零售场景中, 多任务、多部门、多租户是否需要风险隔离和成本分摊?

一句话结论

MoE 的价值是用 sparse activation 扩大模型容量, 让不同 token 或任务动态调用不同 expert; 它的代价是 router、capacity、load balancing、token dropping、expert parallelism 和 serving 调度都必须被治理。

对 PM/BA/架构师的实用判断是: MoE 不是“免费更大模型”, 而是一种把模型能力扩展问题转成路由、容量、稳定性和平台治理问题的架构选择。

机制解释

1. MoE 是什么

MoE 可以理解为在 Transformer 的某些层里, 把普通的 feed-forward network 替换成多个 expert feed-forward networks。

Dense Transformer block 中, 每个 token 都经过同一组 FFN 参数。

MoE Transformer block 中, 每个 token 先经过 router。Router 根据 token 表示计算应该交给哪些 experts。通常只选择 top-1 或 top-2 expert, 而不是激活全部 experts。

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

这使模型拥有更多参数容量, 但每个 token 的实际计算量只接近少量 expert 的成本。

2. Sparse Activation

Sparse activation 指一次请求并不激活整个模型的所有专家参数。

如果一个 MoE 层有 64 个 expert, 每个 token 只走 top-2 expert, 那么该层每个 token 只使用 2/64 的专家计算路径。模型总参数可能很大, 但激活参数只是一小部分。

这对成本有吸引力, 但也带来一个现实问题: 参数不激活不等于没有系统成本。未激活专家仍要存储、加载、分片、同步、监控和部署。

3. Router / Gating

Router, 也叫 gating network, 是 MoE 的交通调度器。

它为每个 token 计算每个 expert 的得分, 再选择 top-k experts。Top-k 的选择可以是 top-1, top-2 或更多。Switch Transformer 的代表性简化是 top-1 routing, 让每个 token 只去一个 expert, 以降低通信和计算复杂度。

Router 的质量很关键:

• 路由太集中, 某些 expert 过载, 其他 expert 空闲。
• 路由太随机, 专家难以形成稳定专长。
• 路由对噪声敏感, 会带来训练不稳定和推理抖动。
• 路由不可观测, 企业难以解释成本和延迟。

PM 可以把 router 理解为一个“动态分流策略”, 但它不是业务规则引擎。Router 学到的是神经网络内部的 token 表示分配, 不是显式的“投诉去客服专家、AML 去合规专家”规则。

4. Expert Capacity

Expert capacity 是每个 expert 在一个 batch 内最多处理多少 token 的容量上限。

为什么需要容量上限? 因为如果 router 把大量 token 都发给同一个 expert, 该 expert 会成为瓶颈。容量上限用于控制单个 expert 的负载, 保持批处理和并行计算可控。

常见概念是 capacity factor。它决定每个 expert 相对于平均负载可以多接收多少 token。

容量太小:

• token 更容易被丢弃或走 fallback。
• 质量可能下降。
• 训练信号不完整。

容量太大:

• 计算和内存浪费增加。
• 长尾专家过载风险仍可能存在。
• 吞吐优化难度变高。

企业类比: 坐席队列不是无限的。即使有很多专科团队, 每个团队也有并发处理上限。容量设计决定高峰期是否排队、丢单或降级。

5. Load Balancing

Load balancing 是 MoE 稳定训练和高效 serving 的核心。

理想状态是 token 分布相对均衡, 每个 expert 都能学到有用模式, 同时不会出现少数 expert 过热。

训练中常用 auxiliary load balancing loss, 让 router 不要总是选择同一批 experts。它不是业务负载均衡器, 而是训练目标的一部分。

企业架构师要关心的是 serving 侧负载:

• 不同 expert 是否跨 GPU / 节点分布?
• 某些语言、任务或客户类型是否造成 expert hotspot?
• p95/p99 延迟是否被少数 expert 拖慢?
• 高峰期是否有 capacity overflow 或 token dropping?

6. Token Dropping

Token dropping 指当某个 expert 已达到容量上限时, 后续被路由到该 expert 的 token 可能被丢弃、跳过 expert 计算、走 residual/fallback, 或被转给其他路径。

这在训练中可作为容量控制机制, 但在企业生产理解上非常重要: 如果高负载下 token 被丢弃或降级, 质量和一致性可能受影响。

企业不一定能直接看到底层 token dropping, 尤其使用商业 API 时。但架构师应至少要求供应商或平台提供:

• 高峰期质量回归测试。
• 容量和限流说明。
• p95/p99 latency 指标。
• 请求失败、截断、降级和重试语义。
• 模型版本变更说明。

7. Expert Parallelism

Expert parallelism 是把不同 experts 放在不同 GPU 或节点上并行计算。

Dense model 常见并行包括 data parallelism、tensor parallelism、pipeline parallelism。MoE 额外引入 expert parallelism: token 需要根据路由结果跨设备发送到对应 expert, expert 计算后再把结果聚合回来。

这带来吞吐潜力, 也带来通信成本:

• All-to-all communication 可能成为瓶颈。
• 批大小、序列长度、expert 数量会影响通信效率。
• 跨节点部署增加网络延迟和故障面。
• Serving runtime 需要更复杂的调度。

所以 MoE 的推理成本不只看 FLOPs。通信、内存、调度、batching、cache 和负载分布同样重要。

Dense Model vs MoE

关键结论: MoE 更像一种规模化工程架构, 不等于天然更便宜、更快或更安全。是否适合企业, 要看具体模型、平台、请求分布、SLO 和治理能力。

架构映射

1. 模型选型

企业选模型时, 不应只比较 benchmark 分数。对 MoE 模型要额外问:

• 这是 top-1 还是 top-2 routing?
• 每次推理的激活参数量大概是多少?
• 对长上下文、多语言、结构化输出的稳定性如何?
• 高并发时 p95/p99 延迟是否稳定?
• 是否支持批处理、streaming、tool use、JSON mode、RAG 场景?
• 是否有模型卡、风险说明、eval 报告和版本变更记录?

PM 的需求写法应该从“使用最强模型”改成“按任务风险、SLO、成本和质量选择模型路线”。

2. SLO

MoE 的 SLO 要关注平均延迟以外的尾延迟。

建议指标:

• p50 / p95 / p99 latency。
• time to first token。
• tokens per second。
• throughput under peak load。
• timeout rate。
• fallback route rate。
• cost per successful task。
• high-risk task quality score。

如果 MoE 在平均速度上很好, 但尾延迟不稳定, 它可能不适合实时坐席辅助、支付异常处理或交易风险提示。

3. 成本治理

MoE 的成本治理要按任务而不是按模型名粗略估算。

需要记录:

• input tokens / output tokens。
• route distribution。
• model version。
• latency breakdown。
• retry count。
• fallback model。
• cache hit rate。
• business outcome。

对企业 AI 平台, 更实用的成本指标是 cost per resolved case、cost per approved draft、cost per correct classification, 而不是单纯 cost per token。

4. 多租户

MoE 内部的 expert 不是企业多租户隔离机制。

多租户隔离仍应在平台层实现:

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

不要假设“不同租户会被路由到不同 expert”。Router 没有这种合规承诺。

5. 风险隔离

金融零售中, 风险隔离靠 workflow、policy、human approval 和 system boundary, 不是靠 MoE expert。

例如:

• 客服 FAQ 可以走低风险快速模型。
• 投诉、欺诈、信贷、AML 进入强控制 route。
• 高风险输出必须经过 validator 和人工复核。
• 写操作必须由权限系统和审批系统控制。

MoE 可以作为底层模型形态, 但风险边界必须在企业架构中显式设计。

PM/BA 视角

PM 要问的问题

• 这个任务需要更大参数容量, 还是需要更好知识检索、工具调用和流程控制?
• 用户体验瓶颈是模型能力、延迟、证据缺失, 还是人工复核?
• MoE 带来的单位成本下降是否能被平台复杂度抵消?
• 低风险和高风险任务是否需要不同模型路线?
• 成本是否能按产品线、部门、租户分摊?

BA 要写清楚的需求

• 任务分类: FAQ、摘要、分类、抽取、建议、行动执行。
• 风险等级: 低风险辅助、中风险建议、高风险决策支持。
• SLO: 首 token、总延迟、超时、并发、降级。
• 输出要求: 格式、引用、置信度、拒答、升级条件。
• 验收指标: 质量、成本、延迟、人工改写率、失败类型。

BA 不需要写“使用 MoE”, 但需要写出能判断 MoE 是否合适的业务约束。

金融零售案例: 多任务专家路由的类比

重要说明: 下面是企业架构类比, 不等于直接训练一个金融 MoE 模型, 也不等于 MoE expert 天然对应业务专家团队。

客服多任务

客服系统里, 用户问题可能涉及余额、收费、投诉、信用卡、贷款、欺诈、密码重置。

企业架构可以做显式路由:

• 高频 FAQ -> cache / small model。
• 政策问答 -> RAG + medium model。
• 投诉和争议 -> strong model + human review。
• 账户动作 -> tool workflow + approval。

这类似 MoE 的“不同输入走不同专家路径”, 但企业路由是可解释的业务规则和风险策略, 不是神经网络 router。

AML Investigation

AML case 包含交易时间线、对手方网络、KYC 信息、制裁筛查、typology checklist 和 investigator notes。

架构上可以分多个专门能力:

• evidence retrieval expert。
• transaction narrative summarizer。
• typology checklist assistant。
• policy citation assistant。
• quality and safety judge。

这是一种 agent/workflow 层的专家编排。它不要求训练 MoE, 更适合用工具、RAG、规则和人工审批组合。

信贷多任务

信贷场景中有资料完整性检查、收入解释、政策匹配、风险摘要、拒绝原因草稿、客户沟通。

可以做:

• deterministic calculation 负责硬规则和数值。
• RAG 负责政策来源。
• LLM 负责材料摘要和解释草稿。
• validator 检查 fair lending 和 prohibited factors。
• underwriter 做最终判断。

这同样是架构类比: 多专家协作不等于把审批交给 MoE。客户权益相关决策必须保留可解释规则、审计和人工责任。

ADR 草稿

ADR: 是否在企业 AI 平台引入 MoE 模型

Eval 练习

Exercise 1: MoE vs Dense 选型矩阵

为客服 copilot 设计一个评估表, 至少比较:

• dense strong model。
• dense small model + RAG。
• MoE model + RAG。
• model routing 混合方案。

每项写出质量、p95 延迟、p99 延迟、成本、引用正确率、人工改写率和降级策略。

Exercise 2: SLO 压测设计

设计一组高峰期压测样本:

• 高频 FAQ 1000 条。
• 投诉争议 200 条。
• 信贷政策问答 200 条。
• AML narrative 100 条。
• 多轮长上下文 100 条。

要求记录 p50/p95/p99 latency、timeout、输出长度、质量分和人工拒绝率。

Exercise 3: 风险隔离检查

写一份检查清单, 证明你的系统没有把 MoE expert 当成权限边界。至少包含:

• tenant auth。
• document permission filtering。
• prompt isolation。
• cache key isolation。
• audit log。
• human approval。
• model fallback。

Exercise 4: Token Dropping 影响评估

假设供应商说明高负载下可能发生内部容量降级。设计验证方法:

• 对比低负载和高负载输出质量。
• 检查长文本摘要遗漏率。
• 检查结构化 JSON 失败率。
• 检查高风险拒答一致性。
• 检查 retry 后答案漂移。

面试表达

30 秒版本

MoE, Mixture of Experts, 是一种 sparse scaling 方法。模型有很多 expert, 但每个 token 只通过 router 激活少数 expert, 例如 top-1 或 top-2。它能提高总参数容量并降低单 token 计算, 但会带来 load balancing、expert capacity、token dropping、expert parallelism 和 serving 复杂度。企业里不能把 expert 当成权限隔离或业务专家, 仍然要靠 AI Gateway、RAG、权限、eval、SLO 和人工审批治理。

2 分钟版本

Dense model 每个 token 通常走同一套参数路径, 参数越大成本越高。MoE 把部分层替换成多个专家网络, 用 router 为每个 token 选择少数专家, 因此总模型可以很大, 但单次激活较小。这对扩展模型容量有价值, 也是很多大规模模型采用 sparse activation 的原因。

MoE 的挑战是工程和治理。Router 可能负载不均, expert 有 capacity 限制, 高峰期可能出现 token dropping 或尾延迟波动。Expert parallelism 还会带来跨 GPU 通信成本。对企业架构师来说, 需要验证 p95/p99 latency、吞吐、成本、fallback 和供应商可观测性。

在金融零售中, 可以用 MoE 类比“客服、AML、信贷多任务专家路由”, 但这只是架构类比。真实系统应该在 workflow 层做显式路由, 用权限、RAG、规则、validator 和人工审批控制风险, 不能假设 MoE 内部 expert 自带合规隔离。

常见误区

1. 误区: MoE 参数量大, 所以一定比 dense model 更贵。 修正: MoE 总参数大, 但每次只激活少量 expert; 单次计算可能更低, 但通信和部署成本要一起算。

2. 误区: MoE 一定更快。 修正: 平均吞吐可能高, 但 router、expert hotspot、all-to-all communication 和 capacity overflow 可能影响尾延迟。

3. 误区: Expert 就是业务专家。 修正: MoE expert 是神经网络参数子模块, 不等于客服专家、AML 专家或信贷专家。

4. 误区: MoE 可以天然做多租户隔离。 修正: 租户隔离必须在身份、数据、检索、缓存、审计和网络层实现。

5. 误区: Sparse activation 没有质量代价。 修正: 路由错误、负载不均、token dropping 和专家欠训练都可能影响质量。

6. 误区: 选 MoE 就不需要 model routing。 修正: MoE 是模型内部路由, enterprise model routing 是业务风险和成本路由, 两者层级不同。

7. 误区: PM/BA 不需要理解 MoE。 修正: PM/BA 不需要训练 MoE, 但要把延迟、成本、风险、fallback 和验收指标写清楚, 否则无法判断模型路线是否适合生产。

1-Page Executive Summary

MoE 的核心是 sparse scaling: 模型拥有多个 expert, router 为每个 token 选择少数 expert, 从而让总参数容量扩大, 但每次计算只激活部分参数。

MoE 的关键术语包括 router/gating、top-k routing、expert capacity、load balancing、token dropping 和 expert parallelism。

Dense model 的路径更固定, serving 更简单; MoE 可能在单位计算和吞吐上有优势, 但训练稳定性、部署复杂度、通信成本和尾延迟治理更难。

企业选型时, 不能只看模型参数量或 benchmark。要看真实 workload 下的 p95/p99 latency、cost per task、fallback、质量回归、供应商透明度和上线治理。

MoE 不等于权限隔离、多租户隔离或业务专家系统。金融零售中的风险控制仍必须依赖 AI Gateway、IAM、permission-aware RAG、rules、validator、human review、audit log 和 release gate。

在客服、AML、信贷场景中, 可以用“多任务专家路由”帮助理解 MoE, 但实际落地更常见的是 workflow 层的显式 model routing 和 agent orchestration, 不一定需要直接训练 MoE。

一句话: MoE 把大模型扩展从“所有 token 都走所有参数”改成“token 动态选择少数专家”, 但企业要为这种动态性建立 SLO、成本、风险和可观测治理。

与现有学习资料的连接

• docs/ai-foundations/papers/01-attention-is-all-you-need.md: 理解 Transformer block 和 FFN, MoE 通常替换的是其中部分 FFN 层。
• docs/ai-foundations/papers/07-inference-optimization-kv-cache-flashattention-speculative.md: 理解 MoE 推理仍要和 latency、throughput、cache、batching 一起设计。
• docs/AI_VENDOR_BUILD_BUY_ADOPTION_PLAYBOOK.md: 用 vendor due diligence 判断 MoE API 或自托管路线。
• docs/AI_ARCHITECTURE_REVIEW_GATE_CHECKLISTS.md: 把 MoE 引入模型平台时纳入架构评审门禁。