2.2 智能路由：按成本 / 延迟 / 质量自动选路

文档摘要

2.2 智能路由：按成本 / 延迟 / 质量自动选路上一节我们把「重复请求」挡在了模型门外。但真实流量里，还有大量一次性、差异化的请求——缓存帮不上忙，它们终归要落到某个模型上。问题来了：落到哪个模型？如果全扔给最贵最强的大模型，成本直接爆；如果全用 cheapest 小模型，质量又塌方。这一节要解决的，就是「未命中缓存的那部分请求，如何自动选到最划算的模型」——智能路由。读完这一节，你应能一句话概括：路由的本质是一棵「任务难度 → 模型档位」的决策树，它在成本、延迟、质量三者之间替你做权衡，而不是无脑全上大模型。先破除一个误区：不是「大模型一定更好」很多团队一开始把所有请求都发给旗舰大模型，理由是「质量最稳」。

2.2 智能路由：按成本 / 延迟 / 质量自动选路

上一节我们把「重复请求」挡在了模型门外。但真实流量里，还有大量一次性、差异化的请求——缓存帮不上忙，它们终归要落到某个模型上。问题来了：落到哪个模型？ 如果全扔给最贵最强的大模型，成本直接爆；如果全用 cheapest 小模型，质量又塌方。这一节要解决的，就是「未命中缓存的那部分请求，如何自动选到最划算的模型」——智能路由。

读完这一节，你应能一句话概括：路由的本质是一棵「任务难度 → 模型档位」的决策树，它在成本、延迟、质量三者之间替你做权衡，而不是无脑全上大模型。

先破除一个误区：不是「大模型一定更好」

很多团队一开始把所有请求都发给旗舰大模型，理由是「质量最稳」。但事实是：相当一部分请求，小模型（或开源/廉价模型）完全能胜任，质量差距肉眼难辨，成本却差几倍到几十倍。

举几个真实画像：

「把这段中文翻译成英文这句简单标语」——小翻译模型足矣。
「判断这条用户评论是正面还是负面」——一个轻量分类模型或规则就能搞定。
「从 200 字摘要里提取 3 个关键词」——小模型秒出，没必要动用推理大模型。
「根据用户问题检索知识库并返回出处」——检索本身不烧大模型，大模型只负责最后的总结，且总结难度不高。

这些请求如果全走大模型，等于用牛刀杀鸡，且牛刀按次计费，刀刀都是钱。路由的价值，就是识别「哪些该用牛刀，哪些用菜刀就行」。

flowchart TD A[未命中缓存的请求] --> B{任务难度预估} B -- 极简/结构化 --> C[小模型/规则引擎] B -- 中等/单轮生成 --> D[中档模型] B -- 复杂/多步推理 --> E[大模型/旗舰模型] C --> F[返回] D --> F E --> F

一个具体例子：客服问答里的路由实战

光说概念容易飘，给一个真实感强的场景。假设你是某电商的客服助手，每天几万条用户问句。我们抽样发现：约五成是「订单到哪了」「怎么退货」「优惠券怎么用」这类高度标准化问题；三成是「帮我对比两款手机」「写一段催付短信」这类中等生成任务；两成是「我这个纠纷该怎么维权」「根据我的账户给理财建议」这类复杂或高风险任务。

如果不路由，全扔旗舰大模型，账单最贵。路由后：那五成标准化问题用便宜的小模型/专用问答服务就够了（用户根本分不出差别）；三成中等任务走中档；只有两成复杂或高风险走旗舰。算下来整体成本砍掉一大截，而用户满意度几乎没动——因为简单问题本就用不上大模型的能力。这个例子想说明：路由省的钱，来自「承认大部分请求其实不值那个价」。

路由决策的三个维度：成本、延迟、质量

路由不是单看价格。它是一个三目标权衡，不同业务对三者的权重不同：

成本（Cost）：单次调用的 Token 单价 × 预估消耗。这是本教程的核心目标。
延迟（Latency）：用户能接受多久出结果。实时对话要快，离线批处理可以慢。
质量（Quality）：输出能否满足业务标准。错误率、格式合规、事实准确。

三者经常打架：大模型质量高但贵且慢；小模型便宜快但可能错。路由的功夫，就是给每类任务找到「质量达标前提下，成本和延迟最优」的那一档。

我的主张：先用「质量下限」切一刀

我建议的优先级是：先保证质量达标，再在达标的模型里挑最便宜最快的。 不要为了省钱去用一个「经常答错」的模型——省下的 Token 钱，可能赔进客诉和返工。所以路由的第一步不是比价，而是给每类任务设一条「质量红线」：低于这条线的模型，直接失去候选资格。

路由怎么「看」任务难度：四类信号

路由器要替你选路，得先判断「这条请求难不难」。常见有四类信号，可以组合使用：

信号一：规则/关键词硬路由（最便宜、最稳）

对结构化、可预判的请求，直接用规则分流，根本不调模型判断：

命中「翻译」「分类」「提取」等明确意图词 → 走对应小模型/专用服务。
请求长度极短且模式固定 → 走轻量通道。
带了特定业务标签（如 tier=internal_batch）→ 走批处理廉价模型。

规则路由零延迟、零额外成本，但只能覆盖「你能预见」的部分。它是路由的第一道闸门。

信号二：用一个小模型做「难度分类器」

对无法用规则预判的，可以先用一个便宜的小模型给请求打难度标签（简单/中等/复杂），再据此选路。这相当于「花一分钱请个调度员」。只要分类器准，整体比「全部上大模型」省得多。注意：分类器本身也要评估准确率，分错了会错配。

flowchart TD A[请求] --> B[小模型分类器] B -- 简单 --> C[廉价模型] B -- 中等 --> D[中档模型] B -- 复杂 --> E[大模型] C --> F[结果+质量抽查] D --> F E --> F F --> G{质量是否达标?} G -- 否 --> H[升级到更高档模型重算] G -- 是 --> I[返回]

信号三：用元特征（长度、类型、历史）粗筛

很多任务可以从「元特征」直接猜难度，比调分类器还省：

输入特别长 + 要求「总结」→ 通常中等，可走中档。
要求「逐步推理/写代码/多步骤规划」→ 偏复杂，走大模型。
该用户/该类目历史命中率高且简单 → 默认走低档，偶尔升级抽查。

信号四：级联（cascade）——从便宜试到贵

这是我最推荐的工程套路：先用最便宜的模型试，质量不达标就升级一档，直到达标。 因为大量请求其实简单，便宜模型就搞定了；只有少数难的才需要逐级升级。级联把「为简单请求多付的钱」压到最低。

但要注意级联的额外开销：每升一档都要重算一次，且升级判断本身需要标准。所以级联适合「简单请求占比高」的业务；若请求普遍很难，级联反而因反复升级更费钱。

延迟与成本的隐藏账：重试、超时、降级

路由不只是「选哪个模型」，还要管「选了之后怎么办」：

超时与降级：廉价模型若超时，应自动降级到更稳的模型，而不是让用户干等或报错。
质量兜底：关键业务可设「双通道校验」——小模型出结果，大模型抽样复核，发现偏差再纠正（成本高但只抽样，可控）。
成本封顶：单请求预估 Token 超过阈值时，强制走更经济的拆分或摘要策略，避免一条巨长请求把账单击穿。

sequenceDiagram participant R as 路由器 participant S as 廉价模型 participant B as 大模型 R->>S: 先发廉价模型 alt 质量达标/未超时 S-->>R: 返回结果 else 超时或质量不达标 R->>B: 升级到大模型 B-->>R: 返回结果 end R-->>用户: 返回(已自动选路)

路由配置的「可直接复用模板」

为了让你能直接落地，我给你一个配置骨架（伪代码/配置思路，按你的技术栈替换）：

定义模型档位：cheap（小模型，单价最低）、mid（中档，性价比）、flagship（大模型，质量最强）。
定义意图规则：translate/classify/extract → cheap；summarize under 500字 → mid；reasoning/codegen → flagship。
定义级联顺序：cheap → mid → flagship，每级设质量判官（规则或校验模型）。
定义红线：涉及「删除/支付/医疗/法律」的请求，绕过廉价档，直接 flagship，宁可贵不冒险。
定义监控：记录每档的实际命中率、平均成本、质量抽查通过率，每周回看调参。

一张对照表：路由策略怎么选

把前面几种路由方式摊开对比，照着对号入座：

路由方式	额外成本	准确率依赖	适用场景	风险
规则硬路由	零	不依赖模型	意图明确、结构化请求	覆盖不了长尾
小模型分类器	极低（一次小调用）	依赖分类器准度	意图多样、可预估	分错会错配
元特征粗筛	零	启发式	有规律可循的请求	边界模糊会误判
级联 cascade	低（仅升级时多算）	依赖质量判官	简单请求占比高	普遍难时反复升级更费

我推荐的组合拳是：规则硬路由做第一闸门（零成本覆盖大头），元特征粗筛补一层，剩下的交给级联（便宜先试、不行升级）。分类器是可选增强，当你发现规则+粗筛误判太多再上。

flowchart TD A[请求] --> B[规则硬路由] B -- 命中规则 --> C[直达指定档位] B -- 未命中 --> D[元特征粗筛] D -- 命中特征 --> E[预判档位] D -- 仍不确定 --> F[级联: cheap→mid→flagship] C --> G[返回] E --> G F --> G

路由的质量判官：怎么知道「达标了」

级联和降级都依赖一个东西——「质量判官」：判断当前模型输出是否达标。判官可以有三档：

规则判官：检查输出格式、必填字段、是否包含违禁词。零成本，但只能查表面。
校验模型：用一个便宜模型给输出打分/复核。有成本，但能查语义合理性。
人工抽检：对关键业务抽样人工评测，反哺阈值。慢，但最可靠，用于校准前两者。

我的主张：先用规则判官拦明显错误，再用校验模型查语义，关键类目保留人工抽检通道。 没有判官，级联就是「瞎升级」，路由的质量红线会塌。

一个真实成本账：路由省了多少

假设每天 10 万次请求，其中 40% 是简单任务（本可走廉价模型，单价约为大模型的 1/10），30% 中等，30% 复杂必须大模型。若全部走大模型，日成本记为 100 单位。路由后：简单档成本≈4 单位，中等档≈30 单位（假设中档单价为 1/3），复杂档≈30 单位，合计≈64 单位。一天省 36%，一个月省下的量相当可观——而用户感知到的质量几乎不变，因为简单任务本就用不上大模型。

pie title 路由后成本结构(示意) “简单档 cheap(1/10价)” : 4 “中等档 mid(1/3价)” : 30 “复杂档 flagship” : 30

常见误配置清单：90% 的团队踩过这些坑

讲完怎么做，必须讲「别怎么做」。以下是我在真实项目里反复见到的路由翻车现场：

坑一：全量走大模型「图省事」。理由往往是「先跑起来再说」，结果量一上来账单吓人。正确姿势：上线第一天就接路由，哪怕规则简单。
坑二：级联无判官，只看「有没有返回」。模型返回了不等于答对了，没判官就永远升不到对的档。必须配质量判官。
坑三：阈值一刀切，不分业务域。客服问答和代码生成用同一套路由，结果代码生成被低价模型搞坏。应按业务域分别配档位与红线。
坑四：忽略延迟预算。批处理可以慢，实时对话不行。路由只比价格不比延迟，会让实时体验崩。延迟要作为路由的硬约束。
坑五：路由决策本身不监控。不知道每档实际命中率、不知道分错率，调参全靠拍脑袋。路由层必须埋点。

自检：这一节你带走了什么

回到开头的那句话——路由是一棵「任务难度 → 模型档位」的决策树。你今天至少该带走两个判断：第一，先划质量红线，再在达标模型里挑便宜的；第二，优先用级联（便宜先试、不行再升），而不是无脑全上大模型。 缓存管「重复」，路由管「差异」，两者都就位了，下一节我们把它们拼成一道完整的中间层闸门。