3.2 路由决策：在成本、延迟、质量间找最优解

文档摘要

3.2 路由决策：在成本、延迟、质量间找最优解读完这一节，你应该能向团队讲明白："智能路由的本质，是把'每次请求都用最贵最好的模型'换成'按请求难度自动选模型'，它的降本不靠省掉重复，而靠让简单请求别花大钱。" 缓存解决"重复请求"，路由解决"单次请求的选型浪费"——这一节我们拆开路由的目标函数和几种典型策略。一、路由在优化什么：一个多目标问题缓存的优化目标是单一清晰的（提升命中率 r），路由要难得多，因为它同时被三个彼此打架的目标拉扯：成本（Cost）：越低越好。延迟（Latency）：用户要快，尤其 C 端。质量（Quality）：答案得够用，不能为了省钱答非所问。任何路由策略，都是在给定的成本和延迟约束下，尽量保住质量；或者在保住质量底线时，把成本和延迟压到最低。

3.2 路由决策：在成本、延迟、质量间找最优解

读完这一节，你应该能向团队讲明白："智能路由的本质，是把'每次请求都用最贵最好的模型'换成'按请求难度自动选模型'，它的降本不靠省掉重复，而靠让简单请求别花大钱。" 缓存解决"重复请求"，路由解决"单次请求的选型浪费"——这一节我们拆开路由的目标函数和几种典型策略。

一、路由在优化什么：一个多目标问题

缓存的优化目标是单一清晰的（提升命中率 r），路由要难得多，因为它同时被三个彼此打架的目标拉扯：

成本（Cost）：越低越好。
延迟（Latency）：用户要快，尤其 C 端。
质量（Quality）：答案得够用，不能为了省钱答非所问。

任何路由策略，都是在给定的成本和延迟约束下，尽量保住质量；或者在保住质量底线时，把成本和延迟压到最低。写成一个约束优化：

最小化 Cost(route)
满足 Latency(route) ≤ L_max
且 Quality(route) ≥ Q_min

这里 L_max 是用户能忍受的延迟上限，Q_min 是业务能接受的质量下限。路由器的全部聪明，都在于找到满足这两个约束、且成本最低的"那一个模型"。

```mermaid graph TD A[新请求] --> B[难度预估] B --> C{质量底线 Q_min
能否用廉价模型满足?} C -- 能 --> D[选廉价小模型
成本低/延迟低] C -- 不能 --> E{延迟上限 L_max
是否允许大模型?} E -- 允许 --> F[选大模型
质量高/成本高] E -- 不允许 --> G[选中型模型
折中] ```

二、模型成本阶梯：为什么"一刀切用大模型"是浪费

主流 LLM 供应商的模型是分层的：小模型便宜快但能力弱，大模型贵而慢但能力强。以典型档位为例（具体价格以官方为准，这里只讲结构）：

小型模型：处理简单分类、抽取、改写，成本约为大型模型的 1/10 ~ 1/20。
中型模型：处理多数常规对话、摘要，成本约为大型模型的 1/3 ~ 1/5。
大型模型：处理复杂推理、长上下文、高准确率要求的任务。

真实流量里，大量请求其实是简单的："把这句话翻译成英文""提取这段的用户名""判断这条评论是正还是负"。这些用小型模型就够了，却常被默认路由到大模型，等于用跑车送外卖。路由的第一桶金，就是把这类"简单请求"识别出来，丢给小模型。

三、策略一：规则路由（确定性决策树）

最朴素也最可控的路由，是人工写规则：按请求类型、长度、是否含代码、是否要求推理，映射到模型。

优点：可解释、好调试、上线即稳定。缺点：规则要人维护，遇到新请求类型得手动加，且"难度"往往不是几个字段能判定的。


def route_by_rule(request):
    # 简单文本分类/抽取，直接小模型
    if request.task in ("classify", "extract", "translate"):
        return "small-model"
    # 长上下文或要求高准确
    if request.context_len > 8000 or request.need_reasoning:
        return "large-model"
    # 其余走中型
    return "mid-model"

规则路由适合请求结构清晰、类型有限的内部系统。它不聪明，但够稳，是很多团队的第一版。

四、策略二：级联路由（Cascade）——性价比最高的实战打法

级联路由的思想极其实用：先用最便宜的小模型试，它答得够好就结束；答不好，再升级到大模型。 这像"先看社区医院，不行再转专家号"。

关键在"小模型答得好不好"怎么判。常见判据：

置信度分数（小模型自带，低于阈值就升级）。
自检：让小模型先给答案，再用一个判别器判断答案是否可信。
长度/格式校验：抽取类任务若没抽全，视为失败升级。

```mermaid graph TD A[请求] --> B[小模型] B --> C{答案可信?} C -- 是 --> D[直接返回
成本≈1/15] C -- 否 --> E[中模型] E --> F{答案可信?} F -- 是 --> G[返回
成本≈1/4] F -- 否 --> H[大模型
成本最高但兜底] ```

级联的妙处：大部分简单请求停在第一级，只花小模型的钱；只有真正难的才逐级上升到贵模型。实测里，60%~80% 的请求可能在小模型一层就结束，整体成本能砍掉一半以上，而用户端质量几乎无感——因为难的请求最终还是大模型的答案。

五、策略三：学习式/预测式路由

当"难度"无法用简单规则判定时，可以训练一个轻量分类器，输入请求特征（长度、是否含代码、历史相似请求的质量反馈），输出"该用哪个模型"。

这类路由更自适应，但需要标注数据（哪些请求用小模型就够了）和持续评估，防止分类器漂移。对多数团队来说，规则 + 级联已经能拿下降本的大头，学习式路由是锦上添花，不是前提。

```mermaid graph LR A[请求特征] --> B[轻量分类器] B -->|简单| C[小模型] B -->|中等| D[中模型] B -->|困难| E[大模型] C --> F[质量反馈回流] D --> F E --> F F --> B ```

六、多目标权衡：帕累托前沿

把"成本"和"质量"画成二维，每个模型是一个点。帕累托前沿就是"在不牺牲质量的前提下，成本最低的那条边界"。路由的目标，是让每个请求都落在这条前沿上——既不花冤枉钱，也不掉质量。

现实里没有"全能最优模型"，只有"对这类请求最优的模型"。路由做的，就是按请求类型把流量分到前沿上不同的点。

```mermaid xychart-beta title "模型在成本-质量平面上的帕累托前沿" x-axis "单次成本(相对)" 0 --> 100 y-axis "质量评分" 0 --> 100 line [10, 60, 25, 75, 50, 85, 90, 95] ```

七、延迟约束常常比成本更硬

很多团队只考虑成本，却忽略延迟。C 端对话超过 3 秒用户就跑了，这时候"为了省钱用慢的小模型"可能是负优化。所以路由必须带延迟约束：

实时交互 → 优先中模型（快且够用），大模型只做离线批处理。
异步任务（摘要、归类、报告生成）→ 可以放心用大模型慢慢跑，甚至挑闲时调用享受更低单价。

把"实时/离线"分开路由，是很多人漏掉的一层降本。 离线任务对延迟零敏感，完全可以排队到低价时段或用最便宜的档位，省下的钱常常比在线优化还多。

八、路由和缓存怎么配合

回到全书主线：缓存和路由是两套互补杠杆。它们配合时的典型顺序是——

先查缓存：命中就直接返回，连路由都省了（最便宜）。
未命中，再路由：按难度选模型，简单请求走小的，难的走大的。
回源结果写回缓存，下次同类请求直接命中。

```mermaid graph TD A[请求] --> B[缓存命中?] B -- 是 --> Z[返回成本≈0] B -- 否 --> C[路由选模型] C --> D{难度} D -- 简单 --> E[小模型] D -- 难 --> F[大模型] E --> G[写回缓存] F --> G G --> Z ```

这一章我们讲了两个数学内核：命中率决定了缓存能省多少（S≈r），而路由把"每个请求的成本"按难度重新分配。下一章（实战案例）我们会把这两套杠杆，放进三个规模不同的真实系统里，看它们到底省下多少钱、踩过哪些坑。