文章

LLM Model Routing 生产落地实战：别把所有请求都交给最贵模型

系统拆解 LLM Model Routing 的生产工程价值，覆盖强弱模型路由、级联调用、质量评估、成本预算、延迟 SLO、Provider 回退与对抗路由风险，帮助团队建立可观测、可回退、可评估的大模型调用中间层。

为什么模型路由正在成为 LLM 工程基础设施

过去做 LLM 应用，很多团队习惯固定调用一个默认模型。简单问答、复杂推理、低风险改写、高风险合规判断全部走同一个端点。这种方式实现简单，但会带来三个隐性成本：能力浪费（简单任务用贵模型）、延迟不可控（单一供应商排队），以及供应商或模型故障时缺少回退路径。

随着模型生态快速分化——小模型、通用模型、强推理模型、代码专精模型、长上下文模型、视觉模型和私有部署模型并存——关键问题不再是”选一个最强模型”，而是：

每个请求应该交给哪个模型？为什么？失败后怎么办？质量如何证明？

这正是 LLM Model Routing 要解决的问题：把模型选择从业务代码中抽象出来，变成一个可配置、可观测、可评估的中间层。

一句话理解 LLM Model Routing

LLM Model Routing 的核心逻辑可以概括为：在请求到达模型之前，先判断任务类型、难度、风险等级、延迟目标和成本预算，再匹配合适的模型或模型链路。

User Request
  → Task / Risk / Complexity Scoring
    → Model Router
      → Provider Router
        → Fallback / Retry
          → Quality Evaluation
            → Logs & Feedback Loop

举例来说：

  • 简单任务交给小模型：「把这句话改写得更礼貌。」
  • 高风险复杂任务交给强模型：「根据合同条款判断这笔赔付是否符合责任范围，并列出依据。」

路由的目标不是让所有请求都变便宜，而是让每个请求使用足够但不过度的模型能力。

核心知识结构

可以把 LLM Model Routing 拆成 6 个核心模块：

模块职责关键问题
Task Classification判断请求属于哪类任务摘要、分类、代码、数学、RAG、工具调用、Agent？
Difficulty Estimation评估任务难度和风险简单 FAQ 还是多步推理 + 长上下文 + 合规约束？
Quality-Cost Tradeoff在质量和成本之间做平衡什么质量阈值下允许省钱？省钱会不会转移成本给人工？
Latency & Provider Routing选择供应商和区域同一模型不同 provider 的延迟、稳定性、配额是否不同？
Fallback & Retry处理失败和降级超时、限流、结构化输出失败后如何无副作用回退？
Router Evaluation评测路由器本身路由器选错模型的代价有多大？是否有离线集和回归测试？

三类常见路由策略

策略一：规则路由（Rule-Based）

规则路由最容易落地，可解释性强，适合起步阶段：

rules:
  - if: task == "rewrite" and risk == "low"
    model: small_fast_model
  - if: task == "code" or task == "math"
    model: strong_reasoning_model
  - if: context_tokens > 64000
    model: long_context_model
  - if: risk == "high"
    model: strong_model_with_audit

优点：可解释、可控、便于审计。
缺点：规则维护成本随模型和任务类型增长，难以覆盖真实请求的复杂变化。

策略二：级联调用（Cascade）

先用便宜模型尝试，再根据置信度、校验结果或 Judge 评分决定是否升级到强模型：

Small Model → Validate Output → If Failed → Call Strong Model

适合结构化抽取、分类、低风险问答等场景。
注意：升级会增加延迟，且需要设计可靠的失败检测机制，避免”看起来正确但实际错误”的输出绕过升级。

策略三：学习型路由（Learned Router）

用历史样本、偏好数据或质量标签训练分类器，预测某个请求是否需要强模型。

RouteLLM 是代表性工作：将路由建模为强模型与弱模型之间的二元选择，用偏好数据训练路由器。LMSYS 博客报告，在保持 GPT-4 约 95% 性能的前提下，MT-Bench、MMLU、GSM8K 上分别实现了显著的成本降低。

FrugalGPT 则从 prompt adaptation、LLM approximation 和 LLM cascade 三类策略讨论成本优化，其中 cascade 在特定实验中可大幅降本或提准确率。

优点：比纯规则更灵活，能适应请求分布变化。
风险：需要持续评估，因为模型能力、价格和用户行为都会漂移。

推荐流程：把 Model Router 当成模型网关

生产级 LLM Routing 不应只是 SDK 里的 if-else，而应接近一个模型网关。推荐流程如下：

  1. 接收用户请求和业务上下文
  2. 做任务分类、风险识别和复杂度评分
  3. 根据策略选择候选模型池
  4. 根据成本、延迟、区域、可用性选择 provider
  5. 执行模型调用
  6. 对结果做格式、事实、安全和质量校验
  7. 失败时按无副作用策略 fallback 或升级
  8. 记录完整 trace：输入特征、路由决策、成本、延迟、质量分数
  9. 将失败样本回流到评测集和路由器训练集

核心原则：路由决策必须可解释，路由结果必须可评估，路由失败必须可回退。

为什么不能只按成本路由

“便宜模型优先”看起来很合理，但生产中极容易踩坑：

陷阱说明
任务难度被低估用户提问表面简单，实际需要业务知识、长上下文或多步推理。弱模型回答流畅但错误，后续人工成本更高。
输出格式不稳定小模型在 JSON Schema、工具调用、代码 diff、复杂表格等结构化场景中稳定性不足。
安全与合规风险不同法律、医疗、金融、合规、删除、发送、支付等动作，不应仅由成本决定，必须强制进入高能力模型和审批链路。
低价 ≠ 低总成本弱模型失败率高，二次调用、人工修复、用户重试累加后，总成本可能超过直接用强模型。

因此，更合理的目标是 quality-aware cost optimization（质量感知的成本优化），而不是单纯的 cheapest-first。

路由器的 8 类评测指标

LLM Router 不能只看省钱比例，至少需要关注以下维度：

指标含义为什么重要
Quality Retention相对全量强模型的质量保留率省钱不能以显著牺牲质量为代价
Net Cost Reduction含重试和人工的净成本节省首次调用便宜但重试多可能更贵
Latency Impact路由器自身延迟 + 升级延迟 + 回退延迟P95 延迟直接影响用户体验
Strong Model Call Rate强模型调用比例过低可能说明困难任务被误分给弱模型
Escalation Accuracy升级请求是否真的需要升级精确率低浪费成本，召回率低损害质量
Fallback Success Rate主模型失败后回退成功率回退失败意味着请求丢失
Safety Routing Accuracy高风险请求是否进入正确路径安全误路由的代价远高于成本浪费
Robustness对关键词扰动和对抗攻击的抵抗力路由器自身也是攻击面

一个简化的监控看板示例：

metrics:
  quality_retention_vs_strong_model: 0.96
  cost_reduction: 0.48
  router_latency_ms_p95: 38
  strong_model_call_rate: 0.31
  fallback_success_rate: 0.982
  safety_misroute_rate: 0.001
  adversarial_reroute_rate: 0.024
  human_acceptance_rate: 0.91

Provider Routing：不要和 Model Routing 混在一起

Model Routing 解决「哪个模型回答」，Provider Routing 解决「同一个模型由哪个供应商服务」。这两层必须分开：

Model Routing:   用强推理模型处理此请求
Provider Routing: 选择 Provider A，因为延迟更低且配额充足

混在一起的后果：回答质量差可能是模型选错了，请求超时可能是 provider 负载高，价格异常可能是供应商路由策略变了——责任边界模糊，排查困难。

生产日志中应分别记录：

selected_model    selected_provider    routing_reason
provider_latency  provider_error       fallback_path
cost_estimate     actual_cost

路由安全：Router 自身也是攻击面

当路由器决定成本、能力和安全路径时，它本身就是攻击面。近年研究（Router-LLM Robustness、RerouteGuard、Route-to-Rome）揭示了多种风险：

攻击类型手法后果
Cost Escalation诱导简单请求进入昂贵模型成本失控
Quality Hijacking诱导复杂请求进入弱模型回答质量下降
Safety Bypass让敏感请求绕过安全模型/审批链路合规风险
Keyword Manipulation加入 coding、math、legal 等关键词改变路由路由偏差
Adversarial Suffix在请求后添加优化过的后缀操控路由边界系统性误路由

防护措施：

  • 不要仅用关键词判断任务难度
  • 高风险意图使用独立安全分类器
  • 路由决策保留可审计特征
  • 对异常成本上涨设置告警
  • 建立 adversarial regression test 集
  • 限制用户可直接影响路由策略的字段

生产落地 Checklist

上线前逐项确认：

  • 是否区分 Model Routing 和 Provider Routing 两层
  • 是否为任务类型、风险等级和复杂度建立分类规则
  • 是否有强模型基线，用于衡量质量保留率
  • 是否统计净成本（含重试与人工），而非仅首次调用成本
  • 是否为低置信度输出设计了升级路径
  • 是否为结构化输出、工具调用和高风险任务设置了强制模型策略
  • 是否记录完整 trace：路由特征、模型、provider、成本、延迟、质量分数
  • 是否建立离线评测集，覆盖简单、困难、边界和安全样本
  • 是否测试关键词扰动、对抗前缀和后缀带来的误路由
  • 是否有 fallback、retry、timeout 和 budget guardrail
  • 是否监控模型价格、限流、延迟和质量漂移
  • 是否允许人工或业务策略快速关闭某个模型或 provider

结论

LLM Model Routing 的本质，不是把请求发给最便宜的模型，而是把模型能力变成可调度资源：

  • 🟢 小模型 → 低风险、低难度、高频任务
  • 🔵 强模型 → 复杂推理、代码、长上下文、高风险任务
  • 🟡 Provider Routing → 可用性、延迟、供应商故障切换
  • 📊 Evaluation → 证明路由没有牺牲质量
  • 🔄 Fallback → 保证失败时仍可恢复
  • 🛡️ Security Test → 防止路由被操控

对工程团队最实用的原则：先建立强模型质量基线，再逐步把低风险流量迁移给便宜模型。每一次节省成本，都要用质量、延迟、安全和人工接受率来证明它是有效节省，而不是把问题转移给用户或人工运营。

参考来源：RouteLLM · LMSYS Blog · FrugalGPT · OpenRouter Blog · LiteLLM · Router-LLM Robustness · RerouteGuard · Route-to-Rome

常见问题

LLM Model Routing 和普通负载均衡有什么区别？
普通负载均衡在同类服务实例之间分发请求，目标是均摊负载或就近接入。LLM Model Routing 则要在能力、价格、延迟、上下文窗口和安全等级各不相同的模型之间做选择，还需同时考虑任务难度、质量阈值、成本预算和失败回退路径。
模型路由是否一定会降低回答质量？
不一定。合理设计的路由器会把简单、低风险任务交给性价比高的模型，把复杂、高风险或合规敏感任务交给强模型，并通过质量评测和回退机制兜底。但如果路由器未经校准或仅依赖关键词启发式做决策，确实可能误将困难任务分配给能力不足的模型，导致质量下降。
生产环境中如何全面评估 LLM Router？
至少应关注 8 类指标：质量保留率（相对全量强模型）、净成本节省（含重试与人工）、P95 延迟（含路由器自身开销）、强模型调用率、升级准确率、回退成功率、安全路由准确率，以及对抗路由鲁棒性。不能只看平均省钱比例。
Model Routing 和 Provider Routing 有什么区别？
Model Routing 决定「由哪个模型回答」，根据任务类型、难度和风险选择合适模型。Provider Routing 决定「由哪个供应商服务同一个模型」，根据延迟、可用区、配额和价格选择最优供应商。两层应分开记录和排查，否则出问题时难以定位根因。
特效配置