MoE 不是把参数做大就结束了：推理中的路由抖动、专家负载均衡与 Serving 工程取舍

很多人第一次接触 MoEMixture 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 / 推理优化面试这篇文章会比较有用。目录为什么 MoE 的真实难点不在“参数大”而在“流量不均”先统一概念MoE 在推理时到底发生了什么Dense 模型的稳定世界和 MoE 的动态世界有什么不同路由抖动为什么会直接打坏吞吐和尾延迟专家负载不均到底体现在哪些层面MoE 推理为什么天然更依赖通信系统为什么 continuous batching 到了 MoE 这里会变复杂专家并行、张量并行、数据并行应该怎么组合理解容量规划不能只看平均值要看热点 expert 的峰值MoE Serving 常见优化手段分别在解决什么问题vLLM、SGLang、TensorRT-LLM 里应如何理解 MoE 支持线上排障时该盯哪些指标工程落地建议什么时候该上 MoE什么时候不该面试里怎么把 MoE 推理讲得像真的做过总结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 层通常可以粗略理解为token 先经过共享 attention 或共享主干router 为每个 token 打分为每个 token 选择 top-1 或 top-2 experttoken 被分发到对应 expertexpert 完成前馈计算结果再聚合回原序列注意这里真正改变系统行为的不是“专家很多”这件事而是下面两点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-batchGEMM 效率下降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 跨 NUMAexpert 跨 PCIe root complexexpert 跨机部署那么 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 会越来越像一个系统工程题而不只是一个模型结构题。