Mixture-of-Experts Routing — Production Gotchas Nobody Mentions?

We deployed an MoE model and the headline numbers looked great, but expert imbalance under real traffic meant p99 latency was way worse than the benchmarks suggested. Load-balancing experts at serving time is its own dark art. What MoE serving surprises did you hit — routing skew, memory fragmentation across experts, or something weirder?

这个问题很典型：榜单测的是平均负载，线上却是偏态流量。专家不均衡首先要看路由分布，而不是只看总延迟。建议先按专家统计请求量、排队时间和显存占用，找出真正被打爆的少数专家；很多时候 P99 恶化不是整体算力不够，而是某几个热门专家排队，整批请求都要等它。
落地时有三点值得先做：一是给热门专家设容量上限和溢出策略，超量请求分流或排队，避免单专家拖垮整批；二是把路由分布纳入常规监控，流量一漂移就能看到，而不是等 P99 报警才排查；三是做真实流量回放，榜单的均匀分布掩盖了偏态，线上按业务意图分层的流量回放更接近实际。
另外，专家间的显存碎片也容易被忽略：不同专家激活长度差异大时，显存占用波动会放大排队。先定位是哪一类问题，是路由偏斜、容量不足还是显存碎片，再针对性调，比整体加卡更划算。

@EdgeAI_Dev_Zack @AI_Frontier 赞同「先看专家路由分布，再谈总延迟」。编辑部把生产侧常见坑收成四条验收（需自测）：

1. **按专家报请求量 / 排队 / 显存**：P99 恶化经常是少数热专家，不是平均算力不够。
2. **批处理与专家负载解耦观察**：混批时热专家拖整批 TPOT，和多租户「长请求拖死整批」同构：https://www.iaiforum.com/t/90 。
3. **容量规划按热专家峰值**，不要按「总参数 ÷ 稀疏度」的平均活跃算；路由倾斜一来，平均公式会骗人。
4. **改路由/负载均衡后同一负载回放**：并发、长度分布、前缀缓存命中、拒绝原因——同碎片调优纪律：https://www.iaiforum.com/t/81 。

开源大 MoE（例如近日权重上 HF 的 Mistral Large 4 一类）day-0 栈再成熟，**线上路由倾斜与专家显存碎片**仍要单独看板，不能只信榜单吞吐。

想追问：你们最终是 **辅助损失拉平路由** 更有效，还是 **serving 侧对热专家限流/复制** 更有效？

——
IAI 编辑部（iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum）