Model Routing / Semantic Cache：Frugal AI 与成本质量路由
FrugalGPT、RouteLLM 和 semantic cache 的共同价值不是“用便宜模型省钱”，而是把每一次 AI 请求变成可治理的路由决策：这个请求在当前风险等级、质量要求、延迟预算、成本上限和数据边界下，应该走小模型、大模型、专用模型、RAG、缓存、级联、人审还是拒绝。
Model Routing / Semantic Cache / Frugal AI 解读
本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。
Source Anchors
| Source | Link | 读它要抓住什么 |
|---|---|---|
| FrugalGPT | https://arxiv.org/abs/2305.05176 | LLM cascade 如何用多模型组合降低成本并保持质量（论文 2023-05） |
| RouteLLM | https://github.com/lm-sys/RouteLLM | 根据请求难度路由到强/弱模型的工程框架（访问日期: 2026-07-01） |
| RouteLLM Paper | https://arxiv.org/abs/2406.18665 | Router 训练、偏好数据和质量/成本权衡（论文 2024-06，后发表于 ICLR 2025） |
| GPTCache | https://github.com/zilliztech/GPTCache | 语义缓存、相似查询复用和成本降低（访问日期: 2026-07-01；仓库已声明不再新增模型/API 支持，见 SOTA 检查） |
| LMSYS Chatbot Arena | https://chat.lmsys.org/ | 模型相对质量和偏好比较的评估背景（访问日期: 2026-07-01；平台已多次更名，见 SOTA 检查） |
核心导读
FrugalGPT、RouteLLM 和 semantic cache 的共同价值不是“用便宜模型省钱”，而是把每一次 AI 请求变成可治理的路由决策：这个请求在当前风险等级、质量要求、延迟预算、成本上限和数据边界下，应该走小模型、大模型、专用模型、RAG、缓存、级联、人审还是拒绝。
路由层的机制价值在于把质量、成本、延迟和风险从静态模型选择改造成运行时决策。架构上需要监控升级率、漏升率、缓存命中质量、语义相似误判、供应商集中度和单位任务成本，防止成本优化侵蚀证据质量和安全边界。
1. 核心问题：企业 AI 不能只有一个默认模型
AI 平台进入生产后，最大的问题往往不是“能不能接上最强模型”，而是默认路径太粗。
如果所有请求都打最强模型，会得到较高平均质量，但成本、延迟、供应商依赖和容量压力很快失控。如果所有请求都打便宜模型，简单场景能跑，复杂场景、客户权益、合规解释和高风险操作会变得不可接受。
真实平台需要回答的是：
| 路由问题 | 例子 |
|---|---|
| 这个请求难不难？ | FAQ、复杂政策冲突、跨文档综合、推理规划完全不同 |
| 风险等级是什么？ | 内部草稿、客户外发、资金动作、信贷解释不能同路由 |
| 有没有可复用答案？ | 标准 FAQ、政策解释、重复工单可缓存 |
| 是否需要最新事实？ | 账户余额、政策版本、KYC 状态不能用旧缓存 |
| 是否需要人审？ | 高风险客户影响路径不应只靠模型置信度 |
| 成本和延迟预算是多少？ | 实时客服和后台批处理的策略不同 |
Frugal AI 的成熟理解不是“少花 token”，而是建立 AI delivery 的单位经济和风险控制面。
2. FrugalGPT：级联不是降级，而是条件升级
FrugalGPT 的基本思想是 cascade：先用便宜路径处理请求，如果质量信号不够，再升级到更强、更贵或更慢的路径。
request
-> cheap model / cache / template
-> quality check
-> pass: return
-> fail: stronger model / RAG / human review
这个设计有效，是因为请求难度分布不均。大量企业 AI 请求是重复、低风险、格式稳定的；少量请求复杂、高风险、需要深推理或多源证据。用同一个模型处理所有请求，会把长尾复杂度的成本摊到全部流量。
级联设计的关键不是模型顺序，而是升级条件。
| 设计点 | 需要定义 |
|---|---|
| First path | 哪些请求先走缓存、小模型、模板或规则 |
| Quality signal | 用什么判断结果足够好：置信度、引用、schema、judge、规则 |
| Escalation path | 失败后升级到更大模型、RAG、工具、专家或人审 |
| Stop rule | 何时停止继续尝试，避免无限重试 |
| Audit | 记录为什么没有走最强模型，为什么升级或未升级 |
在高风险业务中，cascade 不能只由模型自评决定。质量门禁必须结合规则、证据、权限、风险等级和人工责任。
3. RouteLLM：路由是预测“够不够”，不是 if-else
RouteLLM 代表另一条路线：训练或配置一个 router，根据请求判断便宜模型是否足够，如果不够就路由到强模型。
可以理解为：
input -> router -> cheap model or strong model
router 的难点是它预测的不是“请求属于哪个主题”，而是“在这个请求上，弱模型相对强模型是否会失败”。这需要偏好数据、历史评测和任务难度信号。
一个企业 router 可能使用这些特征：
| 特征 | 说明 |
|---|---|
| Task type | FAQ、摘要、抽取、推理、规划、代码、政策解释 |
| Risk tier | 内部辅助、客户可见、监管记录、资金/信用影响 |
| Input complexity | 长度、多文档、表格、冲突、缺失信息 |
| Required freshness | 是否依赖实时数据或当前政策版本 |
| User segment | 员工、客户、审计、外部合作方 |
| Historical failure | 类似请求过去是否容易出错 |
| Cost/SLO | 当前租户预算、延迟目标和容量状态 |
Router 本身也要评估。错误路由到便宜模型会造成质量风险；错误路由到强模型会造成成本浪费。成熟平台会把路由准确率、升级率、漏升率和单位成本一起监控。
4. Semantic Cache：缓存语义，不是缓存字符串
传统缓存要求 key 完全一致。语义缓存更进一步：如果两个问题语义相近，可以复用已有答案或中间结果。
例子：
- “信用卡年费可以免吗？”
- “我的信用卡 annual fee 有没有办法 waive？”
- “年费减免条件是什么？”
这类请求可能可以复用同一个政策解释。但语义缓存非常危险，因为“相似”不等于“同一业务上下文”。
缓存是否可用，至少取决于：
| 维度 | 例子 |
|---|---|
| 语义相似度 | 问题是否真正同义 |
| 数据版本 | 政策、利率、活动、监管要求是否更新 |
| 用户上下文 | 不同客户等级、地区、产品可能答案不同 |
| 权限边界 | A 客户的答案不能因语义相似泄露给 B 客户 |
| 风险等级 | 客户外发和内部草稿的缓存策略不同 |
| 可解释性 | 是否能说明缓存命中依据和来源 |
因此，semantic cache 更适合缓存低风险、通用、公开或内部标准化内容。对客户特定、实时、敏感、合规和资金相关内容，应缓存中间检索结果或模板，而不是直接缓存最终答案。
5. 路由控制面的架构位置
模型路由不是某个 SDK 参数，而应是 AI 平台控制面的一部分。
Request
-> Policy and Risk Classifier
-> Cache Lookup
-> Retrieval / Tool Need Classifier
-> Model Router
-> Model / RAG / Tool / Human Path
-> Output Quality Gate
-> Escalation or Response
-> Telemetry and Cost Ledger
关键组件：
| 组件 | 作用 |
|---|---|
| Request classifier | 判断任务类型、风险等级、租户、数据敏感度 |
| Cache policy | 判断是否允许缓存、缓存什么、多久失效 |
| Router | 选择模型或能力路径 |
| Quality gate | 检查引用、schema、拒答、风险、业务规则 |
| Escalation manager | 失败后升级到强模型、人审或拒绝 |
| Cost ledger | 按租户、产品、场景记录 token 和模型成本 |
| Eval loop | 用线上样本回放验证路由策略 |
这套架构让 AI 平台从“模型调用网关”升级为“能力编排和成本治理平台”。
6. 金融零售系统案例
6.1 客服 Copilot
客服场景流量大、重复高、风险分层明显。
可设计为：
| 请求类型 | 路由策略 |
|---|---|
| 通用产品 FAQ | semantic cache 或小模型 + 当前知识库引用 |
| 客户特定账户问题 | RAG + 实时账户 API，不使用最终答案缓存 |
| 投诉或监管关键词 | 强模型 + policy guardrail + 人工确认 |
| 资金、信用、费用承诺 | 必须使用批准话术或升级，不让模型自由生成 |
价值在于：大部分低风险问题低成本处理，高风险问题自动升级，避免所有流量都压到最强模型。
6.2 AML Alert Copilot
AML 场景不能把省钱放在第一位，但仍然需要路由。
| Case 类型 | 路由策略 |
|---|---|
| 低风险重复 alert | 小模型结构化摘要 + 规则校验 |
| 跨账户复杂网络 | 强模型 + GraphRAG + 人工复核 |
| SAR narrative draft | 强模型 + evidence gate + reviewer |
| 数据缺失或冲突 | 不生成结论，返回 evidence gap |
路由目标不是减少模型费，而是把昂贵推理资源用在真正复杂的 case 上，同时保留审计和复核边界。
6.3 平台 FinOps
AI 平台团队应把 routing policy 做成产品能力。
需要提供：
- 每个 use case 的单位成本。
- 路由分布：cache / small / large / human。
- 升级原因。
- 质量和风险指标。
- 租户预算和限流策略。
- 模型供应商切换和 fallback。
这让产品团队能讨论“业务价值是否覆盖单位成本”，而不是只看 token 总账单。
7. 评估 Model Routing
路由策略要用离线和线上两套方式评估。
| 评估维度 | 问题 |
|---|---|
| Quality retained | 与全量强模型相比，质量损失是多少 |
| Cost saved | 单请求和月度成本下降多少 |
| Latency impact | p50 / p95 / p99 延迟是否改善 |
| Wrong downgrade | 本该用强模型却用了弱模型的比例 |
| Over-escalation | 本可便宜处理却升级的比例 |
| Risk compliance | 高风险请求是否按 policy 路由 |
| Cache safety | 缓存命中是否造成过期、越权或错误复用 |
一个好的 routing eval set 应覆盖：
- 简单重复问题。
- 复杂但低风险问题。
- 简单但高风险问题。
- 长上下文问题。
- 政策版本冲突。
- 客户特定敏感问题。
- 需要拒答或升级的问题。
只看平均成本下降是危险的。必须同时看错路由造成的风险成本。
8. 常见误读
| 误读 | 更准确的理解 |
|---|---|
| 路由就是大模型太贵时用小模型 | 路由是质量、风险、成本、延迟和数据边界的联合决策 |
| 语义缓存可以缓存所有相似问题 | 客户特定、实时、敏感和高风险内容必须谨慎缓存 |
| Router 判断错也没关系 | 错误降级可能造成客户损害或合规风险 |
| 只要有 LLM judge 就能判断是否升级 | 高风险升级要结合业务规则、证据和人工责任 |
| 平台只需要暴露多个模型 | 平台还需要 policy、eval、telemetry、budget 和 fallback |
9. 学习验证
读完这组研究后，建议产出一张 AI routing policy。
最小内容：
| 部分 | 内容 |
|---|---|
| Request taxonomy | 请求按任务、风险、数据敏感度、实时性分类 |
| Routing matrix | 每类请求默认走 cache、小模型、大模型、RAG、工具或人审 |
| Escalation rules | 哪些信号触发升级或拒答 |
| Cache policy | 哪些内容可缓存，TTL、scope 和禁止缓存项 |
| Eval plan | 如何衡量成本节省、质量损失、错误降级和缓存风险 |
| Runtime telemetry | 每次请求记录 route、cost、latency、quality gate 和结果 |
真正掌握 Frugal AI 的标志，是能解释为什么“省钱”只是结果，核心能力是让 AI 平台按业务价值和风险动态分配模型能力。
SOTA 检查 (2026-07-01)
- RouteLLM 的核心结论仍成立且已获同行评审背书：RouteLLM 论文（arXiv 2406.18665，2024-06）发表于 ICLR 2025，其 matrix factorization router 用 26% 的强模型（GPT-4，论文基线）调用保住 95% 质量，配合 LLM judge 数据增广后降到 14% 强模型调用（约 75% 成本削减）。它仍是开源自托管 router 的参考基线，但已从“唯一选项”变成路由谱系中的一员。
- 路由层的当前主流形态是“语义路由器/AI 网关”而非独立 router 库：vLLM 官方孵化的 vllm-project/semantic-router 于 2026-01-05 发布首个大版本 v0.1 "Iris"（600+ PR、50+ 贡献者），2026-03 发布 v0.2 "Athena"，把模型选择、安全过滤、语义缓存、幻觉检测合并为一个系统级 mixture-of-models 控制面——与本篇第 5 节“路由控制面”的架构判断一致，且验证了路由与缓存正在收敛进同一层。
- 托管路由已商品化：OpenRouter（2026 年在管 400+ 模型）把路由拆成模型路由（哪个模型答）与 provider 路由（哪家供应商服务该模型）两个独立层；LiteLLM 等网关内置负载均衡路由与（含语义的）缓存。企业做 build-vs-buy 时，本篇的 routing matrix / escalation rules 框架直接可复用为选型评审维度。
- GPTCache 已进入事实维护状态：仓库自述“不再新增新模型/新 API 支持”（访问 2026-07-01），应视为语义缓存的概念参考实现而非现役选型；语义缓存能力如今主要由 AI 网关层提供（如 LiteLLM 的 Redis/语义缓存、vLLM Semantic Router 内置缓存，均支持按类别区分相似度阈值与 TTL）。本篇第 4 节的缓存安全维度（数据版本/权限边界/租户上下文）不随实现更迭过时，实测记录见库内
docs/aipa/day45-semantic-cache.md（2026-07-29，双层判定与假阳代价）。 - LMSYS Chatbot Arena 链接已过时：平台 2024-09 更名 LMArena（lmarena.ai），2025-04 独立注册为 Arena Intelligence Inc.，2026-01 再更名 Arena；chat.lmsys.org 仅存 legacy 入口。引用竞技场偏好数据时应指向新域名。
- 不随版本过时的框架性结论：路由是质量×风险×成本×延迟×数据边界的联合运行时决策（而非 if-else 选模型）、cascade 的关键在升级条件与 stop rule、缓存最终答案与缓存中间产物的风险差异、以及“监控升级率/漏升率/缓存误命中”的评估清单——这些在 2026 年的网关产品中均已成为标配能力面。库内工程化落地见
docs/aipa/day46-gateway-routing.md（2026-07-30，fallback 链与预算闸）与docs/aipa/day89-unit-cost.md（单位成本核算）。