LLM Model Routing 实战：用评估驱动成本、延迟与质量的动态选择

背景：所有请求都打到最强模型，是最稳也最贵的方案

很多团队上线大模型应用时，会先选择一个”足够强”的模型作为统一入口。这个方案早期确实简单：接口少、评估少、排障路径短。但业务量上来后，问题会快速暴露——简单问答、格式转换、分类、摘要、代码解释和复杂推理被送到同一个高价模型，导致 平均成本过高；同时高峰期所有请求争抢同一类模型资源，导致 尾延迟不可控。

LLM Model Routing 要解决的不是”便宜模型替代贵模型”，而是在每次请求进入推理系统前，判断它应该由哪个模型、哪种推理模式、哪个供应商或哪个集群承接。2026 年的动态路由综述将这个问题概括为：模型能力、成本、领域和请求复杂度已经高度分化，静态部署无法根据请求特征做选择，容易带来质量与成本的双重浪费。

因此，模型路由的核心目标应当是：在可接受质量损失范围内，用更低成本和更低延迟完成更多请求；在高风险或高价值请求上，保留强模型、人工兜底和可追踪解释。

核心原理：路由不是 if-else，而是信号、策略和评估的组合

一个可落地的路由系统通常由四层组成。

信号层：先判断请求是什么

信号可以分为轻量信号和语义信号。

轻量信号包括：

• prompt 长度、上下文长度、是否包含附件
• 是否需要工具调用、代码执行或联网检索
• 用户等级、业务线、租户预算
• 请求语言、敏感词、PII、合规标记
• 当前模型健康状态、限流状态、队列长度

语义信号包括：

• 任务类型：分类、摘要、问答、推理、代码、翻译、数据抽取
• 难度判断：是否需要多步推理、跨文档综合、数学或代码能力
• 风险判断：是否涉及医疗、法律、金融、政策、隐私
• 与历史成功样本的相似度

vLLM Semantic Router 的思路就是把启发式特征、分类器、模态、安全信号等组合成可配置的路由决策，而不是把路由写死在业务代码里。

策略层：把信号转换成模型选择

生产中常见的策略有三类。

规则路由：普通 FAQ 走小模型；合同审查走强模型；含代码执行走代码模型；敏感业务走私有化模型。它可解释、易上线，但容易遗漏边界场景。

学习型路由：RouteLLM 使用偏好数据学习强模型与弱模型在不同请求上的胜负关系，目标是把能由弱模型完成的请求转走，同时保持接近强模型的质量。这类方案适合已有评估数据和历史调用数据的团队。

级联路由：先让小模型回答，再用判别器、规则或 LLM-as-a-Judge 判断是否升级到强模型。这种方式更稳，但会增加一次额外调用，适合高质量要求但可接受轻微延迟增加的场景。

网关层：把路由结果变成稳定执行

模型路由不能只停留在算法层。真正上线时，还需要 AI Gateway 承担统一接口、鉴权、限流、成本统计、回退、重试和观测。LiteLLM 这类网关文档中就强调了统一 OpenAI 风格接口、跨供应商调用、异常映射、重试/回退、成本跟踪和预算控制。

一个可靠的网关至少要支持：

routing_policy:
  default_model: strong-general
  candidates:
    - small-fast
    - medium-balanced
    - strong-general
    - code-specialist
  constraints:
    max_latency_ms: 3000
    max_cost_usd: 0.02
    require_private_model_for_pii: true
  fallback:
    on_rate_limit: medium-balanced
    on_timeout: strong-general
    on_quality_risk: strong-general
  logging:
    record_signals: true
    record_decision_reason: true
    record_final_model: true

关键是要把路由策略从代码里抽出来，变成可灰度、可审计、可回滚的配置。

评估层：路由策略必须持续校准

路由最容易犯的错误，是只看”调用了多少次便宜模型”。如果小模型回答导致重试、投诉、人工兜底或关键业务失败，表面省下的推理成本会被后续成本吞掉。

评估层至少要比较四组指标：

维度	指标
质量指标	准确率、任务完成率、格式正确率、人工通过率
成本指标	输入成本、输出成本、重试成本、兜底成本
延迟指标	平均延迟、P95/P99、升级链路耗时
稳定性指标	超时率、限流率、供应商故障率、回退命中率

如果没有离线评估集，路由策略只能作为灰度实验，不能直接全量替换固定模型。

工程落地：推荐从”三段式路由”开始

对多数团队来说，不建议一开始就训练复杂路由器。更稳的做法是三段式。

第一段：规则兜底

先把明显场景分开：

• 高风险场景固定强模型
• 结构化抽取和分类走小模型
• 代码任务走代码模型
• 超长上下文走支持长上下文且成本可控的模型
• 含隐私数据走私有化或合规供应商

这一阶段重点不是省最多钱，而是建立路由日志、决策解释和回滚能力。

第二段：评估驱动

在日志中记录每次路由的输入摘要、信号、候选模型、实际模型、延迟、成本、用户反馈和人工审核结果。然后构建离线评估集，把同一批请求分别跑多个候选模型，比较质量与成本。

可以把评估结果整理成这样的表：

request_id	task_type	risk	chosen_model	strong_model_score	small_model_score	cost_saved	should_escalate
req-001	qa	low	small-fast	4.5	4.3	0.008	false
req-002	contract	high	strong-general	4.8	3.1	-0.015	true

当评估集积累到一定规模后，再训练分类器、相似度路由器或偏好路由器。

第三段：动态预算

固定规则容易在业务高峰期失效。更成熟的做法是引入预算和队列状态：

• 当强模型 P95 延迟过高时，把低风险请求降级
• 当租户月预算接近上限时，提高升级阈值
• 当某供应商错误率上升时，自动切到备用模型
• 对高价值客户或关键任务降低降级概率

这时路由器已经不是单纯的模型选择器，而是推理资源调度器。

适用场景

模型路由特别适合以下场景：

1. 企业内部 Agent 平台：不同部门任务差异大，既有简单问答，也有复杂分析
2. 内容生产系统：标题、摘要、改写可走便宜模型，深度研究和最终审校走强模型
3. 客服与知识库问答：FAQ、工单分类、标准回复可低成本处理，投诉和高风险问题升级
4. 代码助手：语法解释、注释生成、简单脚本可轻量处理，架构设计和复杂调试走强代码模型
5. 多供应商容灾：同一业务需要跨 OpenAI、Anthropic、Gemini、私有模型或本地 vLLM 集群执行

常见误区

误区一：只按 prompt 长度路由

短 prompt 不一定简单，长 prompt 也不一定困难。一个短的数学题、漏洞分析或法律判断可能比长篇摘要更难。长度可以作为成本信号，但不能作为唯一质量信号。

误区二：小模型便宜，所以越多越好

如果小模型导致更多重试，或者让用户修改提示词再问一次，真实成本会上升。路由评估必须统计端到端成本，而不是单次 API 价格。

误区三：路由器可以一次训练后长期不变

模型能力、价格、上下文长度、限流策略都会变化。路由器必须和模型目录、价格表、评估集一起版本化。每次新增模型或调整价格，都应重新跑回归评估。

误区四：路由决策不需要解释

生产事故排查时，必须知道为什么某个请求被送到某个模型。最低要求是记录信号、命中规则、候选模型、最终模型、回退原因和质量结果。

上线检查清单

上线前至少检查以下项目：

• 是否有固定模型回滚开关
• 是否记录每次路由的信号与决策原因
• 是否有离线评估集和灰度对照组
• 是否单独统计升级率、降级率、重试率和人工兜底率
• 是否为高风险业务设置强模型或人工审核兜底
• 是否为供应商限流、超时、错误码配置回退
• 是否区分成本预算和质量底线，避免为了省钱牺牲关键请求
• 是否对模型价格、上下文窗口、输出限制做版本管理
• 是否把路由策略纳入发布审批，而不是由单个开发直接改配置

FAQ

模型路由和 MoE 是一回事吗？

不是。MoE 是模型内部的专家路由，通常发生在单个模型的网络结构内。这里讨论的模型路由是系统层路由，在多个独立模型、供应商、集群或推理模式之间做选择。

规则路由会不会太粗糙？

早期不会。规则路由的价值是建立可解释的基线。如果连规则路由的日志、回滚和评估都没有，直接上学习型路由反而更难排查。

是否应该让 LLM 自己决定调用哪个模型？

可以作为信号之一，但不建议完全交给 LLM 自决。路由决策涉及成本、权限、合规、供应商健康状态和预算，这些信息不应全部暴露给普通生成模型。更好的方式是让 LLM 参与难度判断或质量评估，由网关执行最终策略。

结论

LLM Model Routing 的本质是把”每个请求都用最强模型”的静态架构，改造成 信号驱动、评估闭环、成本可控、故障可回退 的动态推理系统。

落地时不要从复杂算法开始，而应先做三件事：第一，把路由信号和决策日志记录完整；第二，建立离线评估集与灰度对照；第三，把路由策略配置化、版本化、可回滚。只有当这些基础设施稳定后，学习型路由、语义路由和动态预算才会真正产生收益。

参考资料

• Dynamic Model Routing and Cascading for Efficient LLM Inference: A Survey
• vLLM Semantic Router: Signal Driven Decision Routing for Mixture-of-Modality Models
• Red Hat: Bringing intelligent, efficient routing to open source AI with vLLM Semantic Router
• RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing
• RouteLLM GitHub
• LiteLLM Documentation
• Semantic Router GitHub
• SEAR: Schema-Based Evaluation and Routing for LLM Gateways
• When Routing Collapses: On the Degenerate Convergence of LLM Routers