推理：MoE 路由与多模型服务

MoE 和多模型服务看起来属于不同层级，但共同主题是：如何决定“哪一个模型 / 哪一部分参数该为当前请求工作”。MoE 在 token 级选择 expert，多模型服务在请求级选择模型、版本、精度路径或工具链。

初学者先抓住

路由就是把有限算力分给最合适的路径。MoE 在 token 级选择 expert，多模型服务在请求级选择小模型、大模型、VLM、reranker 或工具链。路由错了，系统不是变慢，就是把难题交给了不该处理它的模型。

有趣例子：医院分诊

分诊台不会让所有病人都直接进 ICU，也不会把高风险病人留在普通窗口。好的模型路由也是这样：普通请求走便宜路径，复杂或高风险请求升级到更强路径，并且要记录为什么这么分。

路由的本质

路由本质是资源分配：

$r(x)\rightarrow \text{resource subset}$

在 MoE 中，资源子集是 experts；在多模型服务中，资源子集是小模型、大模型、VLM、reranker、embedding、工具模型或高精度路径。

路由目标通常是在质量、成本和延迟之间折中：

$\min_{m\in\mathcal{M}} \lambda_1\text{Latency}(m,x) +\lambda_2\text{Cost}(m,x) -\lambda_3\text{Quality}(m,x)$

难点在于 Quality 常无法事先精确知道，只能通过分类器、置信度、历史统计或规则代理估计。

MoE 基本机制

设 token 表示为 $h$ ，有 $E$ 个 experts，gate 输出分数：

$\alpha=\mathrm{TopK}(\mathrm{softmax}(W_g h))$

输出为：

$y=\sum_{e\in\mathcal{K}(h)}\alpha_e\mathrm{Expert}_e(h)$

MoE 的收益来自“总参数很多，但每个 token 只激活一部分”。它也带来新问题：负载不均、专家塌缩、跨设备通信、capacity 限制和调试困难。

训练中常加入 load balancing loss，避免少数 expert 被过度使用。推理中则更关注热点 expert、all-to-all 通信、decode 小 token 场景下的延迟，以及 experts 到设备拓扑的映射。

Capacity 与拓扑

每个 expert 在 batch 中有容量上限：

$C=\left\lceil \text{capacity factor}\cdot \frac{kN}{E}\right\rceil$

若某 expert 超载，多余 token 可能被丢弃、重路由或延迟处理。这会影响训练稳定性、质量和推理吞吐。

部署 MoE 时要同时考虑：

experts 如何映射到 GPU / 节点；
常被共同激活的 experts 是否靠近；
all-to-all 是否跨慢速互联；
decode 阶段小 token 是否放大通信开销；
热点 expert 是否造成局部排队。

MoE 的理论 FLOPs 省下来了，不代表线上一定更快。通信和负载不均可能吃掉收益。

多模型服务是系统级 MoE

在线系统常同时运行：

小语言模型；
大语言模型；
reasoning model；
embedding 和 reranker；
VLM / OCR / 表格模型；
工具调用模型；
安全审核模型。

可以把它看作系统级 MoE：不是 token 路由到 expert，而是请求路由到最合适的模型子系统。

常见路由策略包括：

策略	优点	风险
规则路由	简单可控	规则膨胀、维护困难
分类器路由	可学习任务类型和难度	训练数据和校准要求高
置信度升级	小模型先答，低置信升级	置信度不准会误路由
级联路由	成本低，质量可兜底	两段排队导致尾延迟恶化
在线学习	可适应流量变化	线上探索风险高

缓存与级联

多模型系统的成本不只来自模型本身，还来自重复 prefill、检索、工具和中间状态。

设计级联路由时应明确：

小模型失败后，大模型能否复用 prefix；
检索结果是否跨模型共享；
工具结果是否缓存；
tokenizer、prompt template 和安全模板是否一致；
升级路径是否会导致两边都排队。

若小模型经常先答再升级，且无法复用前缀或检索结果，级联策略可能比直接走大模型更慢、更贵。

失效模式

失效	表现	处理方向
热点 expert / 模型	局部排队，其他资源闲置	负载均衡、拓扑调整、限流
错误分流	难题送小模型，质量崩	校准、升级阈值、风险规则
级联震荡	大量请求先失败再升级	改阈值、提前分类、共享缓存
版本耦合	换 reranker 后全链路负载变	版本绑定、回放评测
路由黑箱	不知道为什么走某模型	记录路由特征和决策证据
成本反噬	小模型省下的成本被重试吃掉	端到端成本核算

路由系统必须可观测，否则质量问题和成本问题很难归因。

指标与验收

建议同时看 MoE 和多模型两层指标：

expert token 分布、overflow、drop、all-to-all 时间；
不同 expert 的延迟和错误桶；
请求路由分布、升级率、降级率；
各模型池的 queue、GPU 利用率和 p95/p99；
路由前后任务质量、成本和用户体验；
缓存复用率和级联重算成本；
路由错误样本的人工复盘。

MoE 路由与多模型服务的共同原则是：路由必须同时服务质量、成本和稳定性。只追省算力，会把难题送错地方；只追质量，会让最大模型被所有请求占满。

上线后还应保留路由回放集：固定一批真实请求，记录旧路由、新路由、质量判断、成本和延迟。每次调整 gate、阈值、模型版本或 reranker，都先在回放集上验证负载分布是否被意外改写。