第4章-模型路由与编排
第 4 章 · 模型路由与编排
前面三章，我们把请求接进来、挡在门外、又把上下文和缓存这条"降本生命线"讲透了。但还有一个无法回避的现实：今天的 AI 对话产品，几乎不可能只跑一个模型。
你需要大模型的推理质量，也需要小模型的响应速度和成本；你需要国内合规的部署，也可能要接境外的尖端能力；你希望新模型灰度验证，又必须保证老模型随时能兜底。把这些诉求硬塞进一个模型，结果通常是"用旗舰模型的预算，干着轻量模型的活儿"，或者反过来——该用大模型的地方抠成本用了小模型，用户直接流失。
本章要解决的，就是如何用一层"模型路由与编排"，把正确的请求交给正确的模型，在成本、质量、延迟、合规之间做出可工程化的取舍。
为什么一定要做模型路由
把路由当成"可选项"是很多团队早期最容易犯的错。等到模型账单按月翻倍、或者某个供应商半夜故障导致全站瘫痪时，才回头补这一层，代价极高。
从架构视角看，路由层至少承担四类不可替代的职责：
- 成本治理：同一句话，小模型能答好的就不必调用旗舰模型。在百万 QPS 规模下，哪怕只有 20% 的流量从小模型分流，账单差异也是天文数字。
- 质量保障：复杂推理、代码生成、长链条任务交给强模型；闲聊、兜底、格式化交给轻模型，整体体验不降反升。
- 容灾与韧性：单一供应商的可用性永远不是 100%。路由层让你在 A 挂掉时秒级切到 B，用户几乎无感。
- 合规与本地化：数据出境、等保、行业监管，决定了某些请求必须落在指定地域或指定模型上。
路由和前面章节的关系
这一章不是孤立的，它和前面的内容有清晰的咬合关系：
- 与第 2 章（接入与限流层）的关系：限流决定"能不能调"，路由决定"调哪个"。限流挡住的是超出系统承载的洪峰，路由优化的是承载之内每一份算力的去向。
- 与第 3 章（上下文与缓存）的关系：缓存决定"调了能不能省"，路由决定"调不调、调谁"。一个设计良好的系统里，先做路由判断（简单请求也许连缓存命中即可返回，复杂请求才进强模型），再做缓存协同，两者叠加才是可控的成本结构。
理解这层关系很重要：路由不是"又加一层复杂度"，而是把前几章省下来的钱和人，进一步精细化地分配到对的模型上。你可以把它理解为"成本与质量的调度中枢"。
一个真实的两难
讲个常见的场景，帮你在动手前建立直觉。某产品上线初期只用一款旗舰模型，月账单 80 万，用户满意度不错。团队觉得"既然满意度好，就别动"。直到一次竞品用低价模型把同类服务价格打到三分之一，他们才慌忙接入小模型，却因为没有路由层，只能"全量切小模型"，结果满意度暴跌、用户流失。
反过来的成功路径是：从第一天就保留路由层，让简单请求自然流向小模型，旗舰模型只服务真正需要的那 20% 复杂请求。账单可能直接降到 35 万，而用户侧几乎无感。这个差距，就是"有没有把路由当架构一等公民"的差距。本章的目标，就是让你能亲手搭出后一种结构。
动手前的自检清单
在写任何一行路由代码前，先回答这几个问题，它们决定了你这章该做到多深：
- 你的流量里，简单请求占比大概多少？有没有数据支撑？
- 你接了几家供应商？任何一家挂掉，业务会不会全停？
- 有没有合规要求强制某些请求不能出境？
- 当前切换模型，是一次配置变更，还是一次代码发布？
如果后三题你的答案都是"没有/会停/是代码发布"，那么本章对你不是优化，而是刚需。
本章路线图
本章分两节展开：
- 4.1 多模型路由策略：讲清楚"按什么维度路由"以及"怎么工程化地做路由决策"，包括难度路由、成本路由、延迟/合规路由，路由矩阵的写法、分类器冷启动，以及路由质量的度量与常见坑。
- 4.2 编排与容灾：讲路由之后的"稳定性保障"——重试与跨供应商故障转移、熔断、灰度发布、统一协议抽象、多区域容灾与预算护栏，以及可观测性。
读完这两节，你应该能画出自己产品的模型拓扑，知道每一类请求该落在哪条链路上，并且明白当某条链路挂掉时系统会如何自救。
一个贯穿全章的思维框架
在动手之前，建议你先记住一句话：路由解决"去对的地方"，编排保证"到了也能稳稳回来"。 4.1 偏"选择题"，4.2 偏"保障题"。两者缺一不可——只有路由没有编排，一次供应商抖动就前功尽弃；只有编排没有路由，等于花大价钱买韧性却没把算力用在刀刃上。
需要强调的是，路由与编排不是第 3 章缓存的替代，而是协同。把"路由判断 → 缓存命中 → 模型调用 → 结果回流"串成一条 pipeline，才是百万 QPS 下真正可控、可观测、可演进的成本与质量结构。
最后明确一下边界：本章聚焦"调用侧的路由与编排"，不涉及模型训练、微调与评测体系本身——那些是另一个庞大的话题。我们只关心"手里已有的若干模型，如何被聪明地调度"，这也是后端架构师最能直接发力的地方。
一个小提醒：本章两节都会涉及具体代码片段与配置示例，它们用于说明结构与思路，并非可直接粘贴生产用的完整实现。真实落地时请结合你所使用平台的官方接口文档核实参数与错误码，避免凭示例臆造。
读完本章，你不必立刻把所有供应商、所有模型、所有灰度全都接上。工程上更稳妥的节奏是：先搭最小可用路由（难度 + 成本两维），跑出成本节省的数据，再逐步补齐容灾编排与合规路由。架构是长出来的，不是一次画完整的。