设计题 05：多模型路由与 AI 网关

权重：★★　形式：45 分钟系统设计轮
素材来源：Own — QueWI 的 AI 网关、多模型动态路由、Qwen2.5-4B 意图识别 SFT、误判回流
相关知识点：06-agent-infra/gateway-routing.md、latency-cost.md、05-agent-evaluation/agent-eval.md、02-interview/projects/quewi-chatbot.md

1. 题干#

「我们公司内部现在有五六个 LLM 应用，每个团队各自接模型、各自管密钥、各自的账单也看不清楚。老板觉得这样不行，想统一收拢成一层入口。你来做这个 AI 网关 —— 顺便看看能不能把成本降下来。」

注意这个题干有多模糊：没说几个模型、是自建还是 API、没说「降成本」是硬指标还是随口一提、没说谁拥有配额、没说多租户与合规要求。这不是题干写得差，这是刻意的。 而且这里埋了一个陷阱 —— 「网关」和「路由」是两件事，很多人上来就把两者混着讲。

2. 第一步：澄清（这一轮最重要的动作）#

绝对不要听完就开始画网关的分层图。开场第一句应该是：

「在动手之前我想先确认几件事 —— 因为这几个答案会决定这层网关值不值得建、以及路由到底是不是它该承担的东西。」

必问清单（按对方案的影响排序）#

面试技巧：先问 1、2、8。第 1 问甚至可能直接得出「你们现在不该建网关」的结论 —— 敢说这句话是加分项。

3. 参考架构#

假设澄清后得到：6 个应用、自建 + 外部 API 混合、成本压力为主、需要按团队归集成本、有数据合规要求。

┌─ 控制面（低频变更，不承载请求）───────────────────────┐
│  模型注册表（能力/上下文/价格/限流档位/状态）            │
│  租户与配额管理 · 路由策略配置 · 评测与回放工具           │
└───────────────────────────────────────────────────────┘
                        ↓ 热加载下发
┌─ 数据面（每个请求必经）───────────────────────────────┐
│  ① 认证：虚拟 key → 应用 / 租户身份                     │
│  ② 准入：配额 · 限流（RPM/TPM）· 内容与 PII 审核         │
│  ③ 缓存：精确缓存 → 语义缓存（保守，按场景开关）         │
│  ④ 路由：信号 → 档位（小 / 中 / 大 + 备用）             │
│  ⑤ 适配：统一协议（OpenAI 兼容）→ 各上游                │
│  ⑥ 韧性：超时 · 重试（退避 + 上限）· 熔断 · 降级        │
│  ⑦ 观测：trace · token · 成本 · 延迟 · 结果             │
└───────────────────────────────────────────────────────┘
                        ↓
  多模型：自建 vLLM（连续批处理） / 外部 API
                        ↓
  trace → 误判 case → 路由策略回放与评测 → 训练数据

画图时要讲的三个点：

• 控制面 / 数据面分离。 模型上下架、配额调整、路由策略变更属于控制面，不应该要求改数据面代码或重启网关。但也要承认：多数场景下配置热加载（一份受控的配置文件 + 版本化）就已经够用，不必一上来做一套完整的控制面服务。
• 路由决策必须在数据面内、且本地可算。 因为路由结果决定这次请求发给谁，它不能是异步旁路的；也不能为了路由再发一次远程调用。这一点直接推出下面 4.3 的约束。
• 观测层不是附加项，它是路由策略唯一的评估数据来源。 网关顺手记的 trace，正好是后面评测路由策略、捞误判 case 的原料 —— 这两个功能要一起设计，不要事后补。

4. 关键决策与权衡#

4.1 网关集中什么、明确不解决什么#

主动强调三条「不解决」（这才是资深信号）：接口统一 ≠ 行为统一（上下文长度、参数支持、工具格式仍不同，上层仍要做能力探测与按模型降级）；网关不提升应用自己的 prompt 质量，它是基础设施不是质量保证；网关不替代业务权限模型 —— 它能拦越权调用，但「谁能看哪份数据」仍由业务系统定义。

4.2 路由信号，以及 router 放在哪#

信号（可组合）：

• 意图 / 任务类型：闲聊、检索问答、代码生成、多步工具调用、结构化抽取 —— 不同任务对能力的需求差异极大；配合预估难度 / 复杂度（推理步数、是否多跳、上下文长度）判断该用哪一档
• 成本预算与延迟 SLO：这个租户 / 这次请求能承受多贵的模型；交互式请求更匹配小模型
• 可用性：某个上游故障或被限流时切走

实现方式（从简单到复杂，面试要能排这个序）：

位置：路由是同步在数据面关键路径内的决策（不能旁路异步）；但路由策略的评估可以也应当旁路 —— 用历史 trace 离线回放（见 4.5）。

4.3 为什么路由决策本身必须便宜（核心约束，必须能当场论证）#

路由在每个请求的关键路径上，所以：它的延迟会加到所有请求的体感延迟上，它的成本要乘以总请求量（被请求量放大的开销）。

量级对比（这是论证的关键，不要含糊说「开销很小」）：路由是一次短的分类前向，小模型（几 B 参数）+ 输出几十个 token 量级；它省下的是一次长上下文的生成，输入几千到几万 token、输出几百到几千 token。两侧的 token 量级差一两个数量级，所以净收益为正。

推论：路由模型必须小而快 —— 如果为了决定用哪个模型而先调用了一个大模型，这个设计本身就是错的，收益会被自己的开销吃掉。 这正是 QueWI 里选 Qwen2.5-4B 做意图识别的关键原因（配合「意图识别是分类任务、输出空间小、必须可定制」一起说才完整，只说「便宜」是初级答案）。

一个更弱但完全合法的起点：先用规则 + 语义路由（一次 embedding + 近邻）跑起来，等有了真实的误判数据再决定要不要上分类器。先能用，再好用。

4.4 误判代价不对称（第二个核心结论）#

路由必然会有误判，重要的是两类误判的代价完全不同：

推论：决策阈值应偏保守 —— 宁可多花钱走大模型，也不要把复杂请求判简单。兜底机制：

• 置信度阈值：低置信时不赌，直接升配；低置信升级重试：小模型答得不对劲时用大模型重做
• 误判回流：把误判 case 记录并回灌评测 / 训练数据（前提是 trace 里记了路由判定结果与置信度）

反向警告（很加分）：如果团队把路由的 KPI 定成「路由准确率越高越好」，就会不自觉地把阈值往省钱的方向调 —— 这是指标设计错误。路由的目标是「整体质量不降的前提下降成本」，准确率只是中间量。评估时也必须把两类误判分开统计。

4.5 怎么评一个路由策略（不是一个数字）#

• 分桶评测：按请求类型 / 难度分桶，看每桶的质量与成本。总体指标好可能掩盖某一桶的严重退化 —— 最容易被忽略也最重要的一条。
• 分流比例分布：九成请求都走大模型 → 路由等于没起作用；只有百分之几走大模型 → 要检查是不是把难请求也判简单了。
• 单位成本变化 + 净收益：分摊后的每请求成本，以及「省下的成本 − 路由自身的开销」。
• 质量与成本联合看：路由的目标是质量不降的前提下降成本，只看一边都会得出错的结论。
• 两类误判分开统计（一个是质量问题、一个是成本问题），外加线上反馈（点赞点踩、追问率、转人工率、重试率）。

最重要的工程前提：路由策略必须能离线回放。 用历史 trace 的输入跑新策略，看分流比例与成本会怎么变。没有回放能力，改路由策略就等于拿线上做实验。

同时要主动说出回放的固有局限：你只观测到了实际执行的那个模型的结果；没走的那条路是反事实，它的质量你并不知道。要么离线补跑（贵，且分布与当时不同），要么用置信度模型估计。这是 routing 评测绕不开的难点 —— 主动指出它比假装能算出「如果当时走大模型会怎样」更可信。

4.6 什么不该建（资深信号）#

• 不要一上来做学习式 router。 它需要大量标注与持续维护，上限未必比「规则 + 小模型分类」高多少。等前两种跑不动了再说。
• 请求分布集中时不要做路由。 没有可分流的水位，做出来的只是一个更复杂的转发层。
• 语义缓存要谨慎。 误命中（把不同问题判成同一个）的代价取决于场景；合规、医疗、法律类场景宁可不用。要用就必须有保守阈值、按场景开关，并监控命中率与后续追问率（用户马上追问往往是误命中的信号）。
• 不要自创协议（用 OpenAI 兼容，生态现成）；不要把网关做成有状态的编排引擎 —— 一旦它维护会话状态、做多步编排，它自己就成了瓶颈和单点。
• 不要一次上全部能力。 先解决最痛的那块；网关是渐进长出来的。

4.7 网关是高可用关键路径（容易被忽略的一节）#

• 网关故障 = 全部应用故障。 所以它的可用性要求高于任何单个业务应用：无状态多副本、跨可用区部署、配置中心故障时回落到最后一次已知良好配置、路由决策本地化（不依赖外部服务）。
• 网关不能成为延迟瓶颈。 一次认证 + 一次缓存查询 + 一次（可选）小模型前向是可接受的；任何形式的「额外一次大模型调用」都不可接受。路由服务不可用时还要有安全默认（比如统一走一个稳定的中档模型），而不是直接报错。

5. 容量与成本直觉#

• 网关自身的开销可以忽略。 每请求一次认证 + 一次缓存查询 +（可选）一次小模型前向，相对模型调用不构成瓶颈。真正的成本永远是 token —— 别把优化精力花在网关的 CPU 上。
• 成本归集是降本的前提。 没有按应用 / 租户 / 模型的归集，你不知道钱花在哪，「降成本」就只是一句口号。所以网关的第一价值其实是让成本可测量。
• 隐性成本最容易被漏掉：重试、失败重跑、agent 的多步调用（一次任务可能十几次模型调用）、评测与标注成本。只算首轮调用的账单会严重低估。
• 路由的收益是结构性的：收益 ≈ 分流比例 × 单请求成本差，两个数都要在真实分布上量出来 —— 不要编百分比。语义缓存的收益 = 命中率 × 单次调用成本 − 误命中的代价，命中率必须实测。
• 自建推理 vs API：网关的隐藏价值是让这个决策可以按应用分别做、且随时可换供应商 —— 这个选择不该被某个应用的代码绑定死。

说出「这个规模下网关的主要价值是让成本可见，而不是省下多少 token」比说「我做了个网关」更能体现工程判断。

6. 面试官会怎么往下挖#

第一层：澄清与动机#

• Q：你会先问我什么？ ← 见第 2 节，这是开场题
• Q：为什么不让每个应用各接各的？ ← 会退化成 M×N：M 个应用 × N 个模型/供应商各写一套适配、各管密钥、各做限流重试；换模型要改所有应用、密钥散落、成本无法归集、日志分散无法定位。网关把 M×N 压成 M+N
• Q：网关会不会成为单点和瓶颈？ ← 会，见 4.7 —— 它的可用性要求比任何单个应用更高

第二层：技术细节#

• Q：路由判断错了怎么办？错误会怎么传播？ ← 见 4.4：代价不对称 → 阈值偏保守 → 置信度阈值 + 升级重试 + 误判回流
• Q：路由本身的开销会不会抵消收益？ ← ⚠️ 这题答不上，前面全部失效。见 4.3 的量级论证
• Q：用 embedding 语义路由还是小模型分类器？ ← 各有取舍：语义路由便宜、可在线更新，但边界模糊时不准、要维护意图样本；小模型语义理解好、可定制，但要在关键路径承担一次前向。可以先用前者跑起来
• Q：级联（先小后大）和路由（直接选）怎么选？ ← cascade 平均成本低，但「先答错再重试」让延迟不可预测，用户还可能已经看到差答案；路由的延迟可预测。交互式场景路由更稳，离线批处理更适合 cascade
• Q：统一接口是否意味着上层不用管模型差异了？ ← 不是（见 4.1），统一的是调用协议不是行为

第三层：工程与生产#

• Q：上游模型故障 / 限流，网关怎么办？ ← 超时与重试（带退避与上限）、熔断（连续失败快速失败）、降级到备用模型或供应商、必要时排队限流。并且要说清降级后的质量损失怎么和用户沟通 —— 显式提示降级，而不是静默给次的结果
• Q：怎么评估路由策略的好坏？ ← 见 4.5，重点是分桶、分流比例、净收益、两类误判分开统计，以及离线回放能力
• Q：怎么把一个新模型接进来？ ← 注册表登记能力与价格 → 能力探测 → 小比例灰度验证行为 → 再纳入路由候选，不要直接全量切换
• Q：有人绕过网关直接调模型，怎么办？ ← 这是组织问题不是技术问题：真实密钥只签给网关、上游侧做来源校验、成本归集让绕过者无处隐藏。承认这一点比假装技术上能完全封死更可信

第四层：反思与边界#

• Q：这个网关什么时候不值得建？ ← 应用少、模型少、没有成本压力时，多一跳和多一个故障点的代价大于收益。主动说出这一条很加分
• Q：如果某个供应商明天涨价三倍，你怎么应对？ ← 这正是网关的价值：换供应商只改适配层与路由策略，不改应用代码。但要注意「接口统一 ≠ 行为统一」，切换仍必须做回归评测再放量
• Q：如果重做，你会改什么？ ← 路由评估更细（分桶 + 成本联合优化 + 回放）；意图识别做成闭环（误判自动回流）；路由策略可配置而非硬编码；更早建成本归集与合规流程

7. 自测#

1. 为什么路由判断必须便宜？给出量级论证。如果路由用大模型会怎样？

2. 为什么路由的决策阈值应该偏保守（宁可多花钱走大模型）？

3. 怎么评估一个路由策略？为什么「路由准确率」这个单一数字不够？

4. 你为什么不做学习式 router？什么条件下你会做？

5. 网关集中了什么、明确不解决什么？至少说出三件它不解决的事。