企业官网建设流程全解析

很多人第一次接触 MoE（Mixture of Experts）模型时，最先记住的是“总参数很大，但每个 token 只激活少量 expert，所以推理成本不按总参数线性增长”。这句话没错，但它只解释了为什么 MoE 在论文和 benchmark 里看起来很有吸引力，没有解释为什么很多团队把 MoE 真正上线后，会遇到吞吐不稳、单卡热点、尾延迟变差、扩容收益不线性的问题。

MoE 的难点不只是模型结构，而是路由带来的动态不均匀性。不同 token 会命中不同 expert，不同请求的分布会不断变化，最终让推理系统面对一个比 dense model 更难调度、更难做容量预算、也更难稳定优化的运行时。

本文从 AI Infra 和 LLM Serving 的工程视角，系统拆解 MoE 推理里最关键但最容易被低估的主题：路由抖动、专家负载均衡、all-to-all 通信、batch 退化、缓存与调度耦合，以及上线时应该如何做系统取舍。如果你最近在看 DeepSeekMoE、Mixtral、专家并行、EP、TP、vLLM/SGLang/TensorRT-LLM 的 MoE 支持，或者准备 AI Infra / 推理优化面试，这篇文章会比较有用。

目录

1. 为什么 MoE 的真实难点不在“参数大”，而在“流量不均”
2. 先统一概念：MoE 在推理时到底发生了什么
3. Dense 模型的稳定世界，和 MoE 的动态世界有什么不同
4. 路由抖动为什么会直接打坏吞吐和尾延迟
5. 专家负载不均到底体现在哪些层面
6. MoE 推理为什么天然更依赖通信系统
7. 为什么 continuous batching 到了 MoE 这里会变复杂
8. 专家并行、张量并行、数据并行应该怎么组合理解
9. 容量规划不能只看平均值，要看热点 expert 的峰值
10. MoE Serving 常见优化手段分别在解决什么问题
11. vLLM、SGLang、TensorRT-LLM 里应如何理解 MoE 支持
12. 线上排障时该盯哪些指标
13. 工程落地建议：什么时候该上 MoE，什么时候不该
14. 面试里怎么把 MoE 推理讲得像真的做过
15. 总结

1. 为什么 MoE 的真实难点不在“参数大”，而在“流量不均”

MoE 很容易给人一种错觉：既然每个 token 只走 top-k 个 expert，那推理成本应该天然更低，系统只要把 expert 分散到多张卡上就行。

问题在于，MoE 的计算不是均匀洒在所有设备上的，而是被 router 动态分流到少数 expert 上。这意味着：

• 不同 token 的计算路径不一样
• 不同请求在同一时刻会打到不同 expert
• 热门 expert 会成为局部热点
• 某些 GPU 很忙，某些 GPU 在等
• 通信量不只取决于 batch size，还取决于路由结果

Dense 模型的问题通常是“总算力不够”或者“显存不够”；MoE 更常见的问题是：总资源看着够，但资源打得不均匀。

这也是为什么 MoE 推理的系统难点，往往不在模型定义本身，而在运行时如何应对这种动态不均匀性。

2. 先统一概念：MoE 在推理时到底发生了什么

一个典型的 Transformer MoE 层，通常可以粗略理解为：

1. token 先经过共享 attention 或共享主干
2. router 为每个 token 打分
3. 为每个 token 选择 top-1 或 top-2 expert
4. token 被分发到对应 expert
5. expert 完成前馈计算
6. 结果再聚合回原序列

注意这里真正改变系统行为的，不是“专家很多”这件事，而是下面两点：

• token 到 expert 的映射是动态的
• expert 计算之前和之后都需要重排与聚合

所以从 Serving 视角看，MoE 层不是简单的 FFN 替换，而是把原本相对规则的算子流，变成了：

• 一次路由决策
• 一次 token dispatch
• 一组不均匀 expert 计算
• 一次 token combine

这让系统从“稳定的大矩阵计算”部分变成了“带有稀疏路由和通信重排的混合流程”。

3. Dense 模型的稳定世界，和 MoE 的动态世界有什么不同

Dense 模型即使也有动态 batch、长短请求混跑这些问题，但至少每个 token 经过的层和算子路径高度一致。对于运行时来说：

• 每层工作量更容易预估
• batch 合并后的 shape 更稳定
• 单卡负载分布更平滑
• 容量模型更容易建立

MoE 则不同。哪怕 batch size 相同、token 数相同，只要路由分布不同，实际运行代价就可能明显不同。

典型差异包括：

• 某一轮 decode 命中了更多热点 expert，局部 GPU 瞬时拥塞
• top-2 路由比 top-1 多出更多 dispatch/combine 开销
• 同一个 batch 里 token 被打散成很多小 expert micro-batch，GEMM 效率下降
• all-to-all 代价随路由离散度上升

所以 Dense 模型的优化，很多时候是在优化“确定性瓶颈”；MoE 的优化，则更像是在处理“分布波动下的瓶颈”。

4. 路由抖动为什么会直接打坏吞吐和尾延迟

所谓路由抖动，可以理解为：相邻时间窗口内，token 命中 expert 的分布显著波动。

它带来的直接后果有三类。

第一类是热点迁移。

上一秒 expert 3 很忙，下一秒 expert 11 很忙；如果系统没有足够快地吸收这种变化，就会出现局部排队、局部显存水位升高、局部通信放大。

第二类是 batch 退化。

Dense FFN 往往能形成较大的连续矩阵乘；MoE 中一个 batch 经过 router 后，可能被拆成很多碎的小批次。小批次会带来：

• Tensor Core 利用率下降
• launch overhead 占比上升
• kernel 更难打满
• workspace 复用变差

第三类是尾延迟变坏。

请求的完成时间通常取决于最慢那部分 expert 路径。只要某个热点 expert 被打爆，整个请求就会被那条慢路径拖住，表现为 P95/P99 抖动。

所以 MoE 的问题不只是平均吞吐，而是goodput 和 tail latency。

5. 专家负载不均到底体现在哪些层面

很多人把专家负载不均理解成“某个 expert token 更多”。这只是表层。

真实系统里，负载不均至少有四层：

1. token 数不均

最直接。某些 expert 被命中的 token 远多于其他 expert。

2. 计算量不均

即使 token 数相同，不同请求长度、不同并发时刻，也会让某些 expert 的有效 micro-batch 更难处理。

3. 通信路径不均

如果 expert 分布在不同 GPU 或不同节点上，热点 expert 不只会吃计算，还会放大 NVLink、PCIe 甚至 RDMA 通道上的压力。

4. 生命周期不均

在线服务不是单轮静态计算。某些长请求会持续多轮命中少数 expert，造成持续热点，而不是瞬时波动。

因此，负载均衡不能只看训练时的 auxiliary loss，也不能只看平均 expert hit ratio。上线后必须看时序分布、峰值分布和跨设备分布。

6. MoE 推理为什么天然更依赖通信系统

Dense 模型多卡推理的通信，很多时候主要体现在 attention、FFN 的 TP 同步或者 KV 相关路径；MoE 则额外引入了 token dispatch/combine。

如果 expert 不全在本地卡上，就很容易出现：

• token 先被 router 判给远端 expert
• 激活需要 all-to-all 发给目标设备
• expert 算完后结果再回传

这意味着在某些 MoE 实现里，通信不再只是配角，而是前向主路径的一部分。

一旦拓扑不理想，例如：

• expert 跨 NUMA
• expert 跨 PCIe root complex
• expert 跨机部署

那么 MoE 的收益会被通信迅速侵蚀。

所以 MoE Serving 的工程判断里，一个非常关键的问题不是“模型能不能跑”，而是“router 的自由度会不会把通信系统打成主瓶颈”。

7. 为什么 continuous batching 到了 MoE 这里会变复杂

continuous batching 的核心目标，是持续把新请求并入运行中的 batch，提高设备利用率。

Dense 模型里，这件事已经不简单；到了 MoE，还要多考虑一层：并入 batch 之后，router 会把 token 再次打散。

这会带来几个新问题：

• batch 虽然变大了，但每个 expert 的局部 batch 不一定变大
• 新加入请求可能把原本平稳的 expert 分布打乱
• 某些 expert 突然过载，导致整个 step 被拖慢
• 调度器为了追求吞吐，可能反而制造更大的尾延迟

换句话说，MoE 场景里的 batching 不是简单的“越大越好”，而是要看：

• 扩大的 batch 是否真的提高了 expert 侧 GEMM 效率
• 是否显著放大了路由不均
• 是否让最热 expert 成为系统时钟

因此 MoE runtime 更需要路由感知的调度，而不是纯 token 数驱动的调度。

8. 专家并行、张量并行、数据并行应该怎么组合理解

MoE 线上部署最容易把人绕晕的地方，是并行策略叠在一起之后，很难判断瓶颈到底来自哪里。

可以用一个更工程化的方式理解：

• TP解决单个 dense 子计算太大，单卡放不下或算不快
• EP解决 expert 太多，想把不同 expert 分散到不同设备
• DP解决副本扩展和吞吐扩展

但这三者不是免费叠加的。

EP带来的好处是 expert 可以横向摊开，代价是 dispatch/combine 通信会变重。
TP带来的好处是单 expert 计算可进一步并行，代价是 expert 内部又引入额外同步。
DP带来的好处是整体副本数增加，代价是流量一旦路由偏斜，副本之间也可能冷热不均。

所以真实系统设计里，常见的权衡是：

• 单机内优先把 EP 放在高速互联域里
• 除非 expert 本身仍过大，否则谨慎把 TP 和 EP 同时堆高
• 先确认热点是算力瓶颈还是通信瓶颈，再决定并行度

不是并行维度越多越高级，而是要看哪种维度在当前拓扑上最便宜。

9. 容量规划不能只看平均值，要看热点 expert 的峰值

很多 MoE 容量评估失败，都是因为沿用了 dense 模型的平均思路：

• 平均每 token 激活 2 个 expert
• 平均每个 expert 分到总 token 的若干比例
• 平均通信量在链路承受范围内

问题在于线上容量往往不是被平均值打穿，而是被峰值打穿。

更准确的容量问题应该写成：

• P95/P99 时间窗口内最热 expert 的 token 峰值是多少
• 峰值窗口内最热链路的 all-to-all 流量是多少
• 热点 expert 所在 GPU 的显存水位和 kernel 排队多高
• 路由偏斜时是否会触发 admission control

如果你只根据平均 hit ratio 规划资源，压测可能很好看，真实流量一来就会露馅。

MoE 容量规划本质上更像是做热点系统，而不是平均系统。

10. MoE Serving 常见优化手段分别在解决什么问题

很多优化名词看起来都在“加速 MoE”，但它们解决的问题其实不同。

1. 路由负载均衡

目标是降低热点 expert 被打爆的概率。它解决的是分布问题，不直接解决单 expert 算得慢的问题。

2. expert placement 优化

目标是把高相关、高频共现的 expert 尽量放在更近的拓扑内，减少远距离 dispatch。

3. token regroup / packing

目标是把分散 token 尽量重新打包，恢复大矩阵计算效率，减少碎 micro-batch。

4. fused MoE kernel

目标是减少 dispatch、gather、GEMM、combine 之间的中间开销，提高 kernel 级效率。

5. 路由感知调度

目标是不让调度器为了追求表面 batch size，制造更严重的 expert 热点。

6. admission control 与 backpressure

目标是在热点 expert 已经拥塞时限制继续灌流量，避免全局雪崩。

可以看到，MoE 优化不是单点技术，而是一整条链路：模型路由、运行时、拓扑、kernel、调度都要配合。

11. vLLM、SGLang、TensorRT-LLM 里应如何理解 MoE 支持

这三类系统都可以讨论 MoE，但理解角度不同。

vLLM更容易让人从通用 Serving runtime 的角度思考问题：请求调度、KV 管理、批处理和运行时效率。讨论 MoE 时，可以重点关注它如何把 MoE 融进现有 batch 和执行框架。

SGLang更适合从复杂推理流程与结构化执行角度思考：当 MoE 模型和多轮 Agent/长上下文/结构化生成叠加时，路由波动会不会被进一步放大。

TensorRT-LLM则更偏向高性能运行时与内核实现：它的价值常常体现在更强的图优化、kernel 融合和更接近硬件上限的执行路径。

但无论具体框架怎样，判断 MoE 支持是否“真能上线”，核心都不是看 feature list，而是看这些问题：

• 对 expert dispatch/combine 的路径优化得怎样
• 对不均匀 micro-batch 的处理效率怎样
• 对多卡拓扑是否敏感
• 路由偏斜时 tail latency 会怎么变
• 监控与回压机制是否足够工程化

12. 线上排障时该盯哪些指标

如果线上 MoE 服务表现不稳定，不要只看总吞吐和nvidia-smi。

更值得盯的是：

• 每层、每个 expert 的 token 命中分布
• expert hit ratio 的时间窗口波动
• 热点 expert GPU 的 SM 利用率与显存水位
• dispatch/combine 通信耗时
• all-to-all 流量与链路带宽占用
• expert micro-batch size 分布
• 请求级 P50/P95/P99 延迟
• admission failure 或队列堆积情况
• decode step 的最慢 expert 路径耗时

如果这些指标没有打出来，很多 MoE 问题会被误判成：

• 模型太大
• GPU 不够强
• 框架不稳定
• batch 开太小

但实际上，真正的原因可能是某个 expert 长期过热，或者某条通信路径已经先爆了。

13. 工程落地建议：什么时候该上 MoE，什么时候不该

MoE 不是越早上越好。

更适合上 MoE 的场景通常是：

• 你确实需要更高参数规模和能力上限
• 你有足够多的多卡资源与高速互联
• 你能接受更复杂的运行时和监控系统
• 业务规模足以摊薄额外工程复杂度

不太适合急着上 MoE 的场景通常是：

• 单机单卡或弱互联环境
• 服务还在早期验证阶段
• 团队对 dense serving 还没有跑稳
• 监控、排障、回压体系还很薄弱

一个很现实的判断标准是：如果 dense 模型的 batching、KV cache、显存稳定性、尾延迟治理都还没做明白，那么直接上 MoE 往往只会把问题复杂度再乘一层。

14. 面试里怎么把 MoE 推理讲得像真的做过

如果你在 AI Infra 或推理优化面试里讲 MoE，不要只停留在“稀疏激活、参数大但计算省”这种课本答案。

更像做过工程的人，通常会这样组织表达：

第一，先说明系统本质。
MoE 推理的核心不是少算几个 expert，而是 router 让运行时变成动态不均匀系统。

第二，再说明真实瓶颈。
瓶颈通常不是总 FLOPs，而是热点 expert、all-to-all、micro-batch 退化和 tail latency。

第三，给出排障与优化路径。
先看 expert hit 分布，再看通信，再看 kernel packing，最后才决定调度或并行度怎么改。

第四，说出工程取舍。
MoE 不一定天然比 dense 更便宜，它可能是“平均成本更优，但系统复杂度和峰值风险更高”。

这类表达会明显比只背概念更有说服力。

15. 总结

MoE 的价值，不只是用更少激活参数换更大模型容量；MoE 的代价，也不只是多一些路由逻辑。对 AI Infra 来说，它真正改变的是推理系统的运行时性质：

• 计算路径更动态
• 负载分布更不均
• 通信更容易进入主路径
• batch 更容易碎片化
• 尾延迟和热点治理变得更重要

所以，MoE Serving 的关键问题从来不是“模型能不能跑起来”，而是：

在真实流量、真实拓扑、真实调度下，你能不能把这套动态不均匀系统跑稳、跑快、跑得可预测。

如果把 dense LLM Serving 的重点概括为KV Cache + batching + 调度 + 显存，那么 MoE Serving 则是在这套问题之上，再叠加一层router + expert hotspot + dispatch/combine + 路由感知容量治理。

这也是为什么 MoE 会越来越像一个系统工程题，而不只是一个模型结构题。