4.1 多模型路由决策与小模型分流降本

4.1 多模型路由决策与小模型分流降本

我做过一次很有意思的成本拆解：一个大模型服务平台 80% 的请求，其实都是"你好""帮我写个问候语""解释一下这个词"这类简单问题，但平台只有一台旗舰模型服务所有请求。结果是，为了应付那 20% 的复杂请求（推理、创作、长文分析），平台养着昂贵的旗舰集群，而 80% 的简单请求本来用成本只有旗舰 1/10 的小模型就能完美解决。等于用大炮打蚊子，还打了八万次。

这一节讲多模型路由——怎么根据请求特征，把每个请求路由到"刚好够用又最省钱"的模型。这是编排层降本的核心手段，合理分流下，整体成本能降 40% 到 60%。

为什么要多模型路由

单一旗舰模型有三个问题。第一是贵，所有请求都用最贵的模型，成本爆炸。第二是慢，旗舰模型参数多、推理慢，简单请求也被拖。第三是浪费，"你好"这种请求用千亿参数模型回答，是大材小用。

多模型路由的价值就是让简单请求走小模型（省），复杂请求走旗舰模型（保质量）。一个典型的多模型部署会有三档：旗舰模型处理复杂请求（推理、创作、长上下文分析），标准模型处理中等复杂度请求（多轮对话、知识问答），小模型处理简单请求（寒暄、短回答、格式转换）。三档模型的成本通常呈数量级差异——旗舰可能是小模型的 10 到 20 倍成本。

路由策略的三种实现

规则路由

按显式规则分流：含特定关键词或长度的请求走旗舰，短请求或 FAQ 走小模型，付费用户走旗舰免费走小模型。

优点是简单可控、可解释——出问题时你能立刻看出"这个请求为什么被路由到这个模型"，因为规则是白盒的。缺点是规则难覆盖所有情况，请求的"复杂度"很难用几个关键词或长度阈值精确刻画。一个 20 个 token 的请求可能是"帮我证明哥德巴赫猜想"（极复杂），也可能是"你好"（极简单），纯靠长度规则会误判。

规则路由适合起步阶段，先把最明显的分流规则立起来，积累数据后再上更智能的策略。

给一个起步阶段的规则配置示例（伪配置，类似我们用的 YAML 规则引擎）：

router_rules:
  - name: vip_user_to_flagship      # 高价值用户无脑旗舰
    condition: { user_tier: [enterprise, pro] }
    route: flagship
  - name: short_simple_to_small      # 短请求走小模型
    condition: { input_tokens_lt: 30, not_contains_keyword: [证明, 推理, 代码, 分析] }
    route: small
  - name: faq_cache_hit_to_small     # 命中 FAQ 库走小模型
    condition: { faq_match: true }
    route: small
  - name: long_context_to_flagship   # 长上下文走旗舰
    condition: { input_tokens_gt: 4000 }
    route: flagship
  - name: default_standard           # 兜底走标准模型
    condition: {}
    route: standard
​

规则要按顺序匹配，命中即停。这个配置上线后我们看了两周数据，约 45% 的请求被前两条规则截走（小模型），20% 走旗舰，剩下 35% 走标准——光这一套粗规则就降了 30% 成本。规则路由的天花板大概就在 30%-35% 的降本幅度，再往上要靠分类器。

分类器路由

训练一个轻量分类器（甚至一个小 LLM），预测请求的"难度"或"类型"，按预测结果路由。分类器的输入是请求文本，输出是"该用哪个档次的模型"。

优点是比规则灵活，能捕捉语义特征——分类器能理解"帮我证明哥德巴赫猜想"是复杂请求，哪怕它很短。缺点是分类器有误差，误判会伤体验（复杂请求被误分给小模型，质量崩塌）。分类器本身也要一次推理，有开销，虽然比旗舰模型便宜得多。

分类器路由是成熟阶段的主流方案。生产里通常会组合规则和分类器——先用规则处理明确的简单情况（命中 FAQ 库的直接走小模型），规则没覆盖的再走分类器精细判断。

分类器选型上我们踩过坑。一开始想用一个小 BERT（几十 M 参数）做三分类，准确率只有 82%，意味着 18% 的请求误判，复杂请求被分到小模型的"质量崩塌率"有 5%——用户投诉明显增多。后来换成蒸馏的小 LLM（1-3B 参数，从旗舰模型蒸馏的"难度判断"能力），准确率到 93%，质量崩塌率降到 1.5%。分类器本身的延迟要从 50ms 压到 20ms 以内（用 INT8 量化 + 批处理），否则会拖累 TTFT。还有一个细节：分类器的训练数据要从你们自己平台的真实请求里标，不要用公开数据集——公开数据集的"难度分布"和你们业务不一样，标出来分类器在生产里不准。

强化学习/学习型路由

根据历史反馈（用户满意度、实际成本、是否需要重试）自动学习最优路由策略。这是数据驱动的，长期来看最优，因为它能持续从反馈中优化。

优点是长期最优，能发现人工设计不出来的路由规律。缺点是复杂、需要大量数据、决策过程难解释（"为什么这个请求被路由到小模型"变成黑盒）。适合超大规模、有专职数据团队的场景，中小团队不建议碰。

生产通常的演进路径是从规则起步，积累几个月的路由决策和反馈数据后，逐步引入分类器，RL 是远期目标。一步到位上 RL 的团队，大多因为数据不足和工程复杂度而失败。

成本/延迟/质量三角权衡

路由本质是在成本、延迟、质量这个三角中找平衡。简单请求偏成本（走小模型），复杂请求偏质量（走旗舰），实时性强的请求偏延迟（走最快可用的模型）。

这个三角的权重不是固定的，要按业务线、用户等级配置。比如一个面向企业的 to B 产品，质量权重最高（企业客户为质量付费），可以接受较高成本；而一个 to C 的免费产品，成本权重最高（要控制亏损），可以容忍质量略降。路由策略的可配置性很重要——同一套路由引擎，不同业务线用不同的权重配置，互不影响。

小模型分流降本实战

经典的分流策略有几招。长度过滤：输入很短（比如 < 50 token）且无复杂推理特征的，走小模型。意图分类：闲聊、FAQ、简单查询走小模型；推理、创作、代码生成走旗舰。置信度回退：小模型响应的置信度低时，自动回退到旗舰重试，保质量。

其中置信度回退是关键的安全网——它让"小模型分流"敢于激进，因为即使误判（简单请求其实不简单），也有回退兜底。没有回退机制的小模型分流，团队会保守地不敢把请求分给小模型，分流比例上不去，降本效果就有限。

展开讲讲置信度回退的工程实现。第一步要拿到小模型响应的"置信度"信号，有几种来源：小模型输出的 logprob 均值（vLLM 可以开启 return_token_logprob，把生成 token 的对数概率取出来求平均，低于阈值就判低置信度）；或者用一个小判别模型评估"这个回答是否完整、是否答非所问"。第二步是回退逻辑，伪代码大致这样：

response = small_model.generate(prompt)
avg_logprob = response.avg_logprob  # 小模型返回的置信信号
if avg_logprob < THRESHOLD or is_evasive(response.text):  # 阈值如 -1.5
    # 低置信度或疑似回避("我不知道""无法回答")，回退旗舰
    response = flagship_model.generate(prompt)
    metrics.fallback_count.inc()
return response
​

阈值要按业务调——我们用过 -1.2（激进，回退多，质量好但省钱少）和 -1.8（保守，回退少，省钱多但偶尔质量崩）两个值，最后定在 -1.5，回退率约 8%，刚好平衡。还有一个细节：回退会增加一次旗舰调用，所以"低置信度的请求"整体延迟会比直走旗舰还高（先小模型再旗舰）。对延迟敏感的场景，可以用"小模型置信度低 → 直接拒答并提示用户换个问法"，而不是无脑回退旗舰，省下那一次旗舰调用。

收益上，合理分流下 60% 的请求可以走小模型，整体成本下降 40% 到 60%（小模型成本通常是旗舰的 1/10 到 1/5）。这是非常可观的节省——等于把旗舰集群的规模砍掉一大半，而用户感知不到差异（因为分流的都是简单请求，小模型质量够用）。

给一组真实案例数据。我们给一个 to C 平台做分流优化，三档模型分别是：旗舰（175B，约 0.02 元/千 token）、标准（35B，约 0.003 元/千 token）、小（7B，约 0.0008 元/千 token）。上线前月成本 120 万，分流比例做到旗舰 22%、标准 38%、小 40%（剩下是缓存命中），月成本降到 53 万，降幅 56%。同期用户满意度指标（点赞率、投诉率）几乎没变——投诉率甚至略降，因为小模型对简单请求响应更快，用户体感更流畅。关键变量是分到小的 40% 请求里有约 7% 触发了置信度回退到标准或旗舰，这部分是保质量的兜底。

路由层的坑

误判伤体验是首要风险。复杂请求被误分给小模型，质量崩塌，用户会觉得"这个 AI 突然变笨了"。对策是置信度回退兜底，以及对高价值用户默认走旗舰（不参与激进分流）。

路由本身的开销也要控制。路由判定（尤其分类器）耗时间，要控制在 50ms 以内，否则路由延迟会叠加到 TTFT 上。轻量分类器（比如一个小的 fastText 或蒸馏的小模型）通常能满足这个延迟要求，但要注意别用太重的路由模型。

模型一致性是容易被忽视的点。同一会话在不同模型间跳来跳去，风格和记忆可能不一致——第 1 轮走旗舰回答得很详细，第 2 轮被分到小模型回答得很简短，用户会困惑。要有会话级路由粘性，同一会话尽量固定在一个模型档次，避免风格漂移。

会话粘性的实现：会话的第一个请求按正常路由决策选模型，把这个选择记到会话上下文里（如 session.model_tier = "standard"），后续同一会话的请求直接复用这个 tier，不再重新判定。只有在两种情况下允许变更：一是用户显式切换（点"深度思考"按钮强制升旗舰），二是当前 tier 触发了置信度回退（说明这会话其实更复杂，把整会话升一档）。粘性让 95% 的多轮会话稳定在一个模型上，风格漂移投诉清零。

这一节的关键结论

多模型路由让简单请求走小模型，整体降本 40% 到 60%。三种策略按成熟度演进：规则起步，分类器是主流，RL 是远期。三角权衡（成本/延迟/质量）按业务配置。最关键的两个保障是置信度回退（兜底质量）和会话粘性（保一致性）。

回到开头那个案例，我们给那个平台上了三档模型 + 分类器路由 + 置信度回退，旗舰集群的请求量从 100% 降到 25%，整体 GPU 成本降了 55%，而用户满意度指标几乎没变（因为分流掉的都是简单请求，小模型答得够好）。这就是多模型路由的威力。

下一节 4.2 讲 Agent 这种重请求怎么不拖垮全局——它们是路由的特例，需要专门的处理。