AI 网关与模型路由 AI Gateway & Model Routing

所属：01-fundamentals / 06-agent-infra
面试权重：★★★
来源：通用领域知识；未做一手考证
相关项目：Own — QueWI（AI 网关 + 多模型动态路由 + Qwen2.5-4B 意图识别 SFT）→ 见 02-interview/projects/quewi-chatbot.md

一句话#

AI 网关把「接模型」这件事的所有横切关注点（统一接口、密钥、配额、限流、日志、降级、路由）收拢成一层；模型路由在这一层按请求意图/难度把请求分派给最合适的模型以平衡质量与成本 —— 但路由判断本身必须便宜，否则它省下的钱会被自己吃掉。

为什么重要（面试角度）#

这是 QueWI 项目的主线之一，也是「平台思维 vs 应用思维」的分界线。面试官想听：

你能逐条说清网关集中了什么，以及没有网关会怎样（不是背功能列表）
你能说清「路由判断必须便宜」这条设计约束，并推出"路由模型必须小而快"
你能讲误判代价不对称，并推出"阈值要偏保守"这条产品结论
你知道怎么评路由策略的好坏 —— 不是只看路由准确率，而是分桶评测

这题答得好，直接把你的项目从"我做了个 chatbot"抬到"我建了一层让后续应用更快落地的基础设施"。你的 vLLM 部署经验也在这条线上。

核心内容#

没有网关会怎样#

假设三个应用各接两个模型：

每个应用各自实现模型适配层 → 换模型/加模型要改全部应用的代码
每个应用各自管密钥 → 密钥散落各处，泄露面变大，轮换成本高
每个应用各自做重试/降级 → 逻辑重复且质量参差
成本无法按应用/客户归集 → 预算与配额管不起来
日志分散 → 出问题无法定位，也无法作为路由与评测的数据来源

这就是 M×N 问题：M 个应用 × N 个模型/供应商 = M×N 套对接代码；网关把它压成 M+N。

网关集中了什么#

职责	解决什么	不解决什么
统一接口	多供应商/自建模型统一成同一套调用协议（常见做法是 OpenAI 兼容），换模型不改上层应用	不保证不同模型行为一致（能力、上下文长度、工具调用格式差异仍在）
密钥与凭证管理	用虚拟 key / 按应用或客户签发，真实密钥不落到业务代码里	不解决应用侧逻辑漏洞造成的滥用
配额与预算	按应用/客户/团队设 token 或金额上限，成本可归集	不替你决定该给谁多少预算
限流（RPM / TPM）	保护上游、防止单个应用打满配额	不解决上游供应商自身的限流与故障
重试 / 超时 / 熔断 / 降级	上游抖动或限流时优雅降级、自动切换备用模型	降级带来的质量损失仍需和用户沟通（既是技术也是产品问题）
路由策略	按意图/难度/成本预算选择模型（见下节）	不解决"模型选得对不对"的评测问题（那是评测的活）
缓存	精确缓存（相同请求）与语义缓存（近似请求）降低重复调用	语义缓存有误命中风险，需要保守策略与命中率监控
日志与链路追踪	每个请求的模型、token、成本、延迟、结果都留痕，可定位可归因	需要配脱敏与留存策略
安全接入	PII 脱敏、内容审核、越权工具调用的拦截	不能替代业务侧的权限模型

面试价值点：讲网关时要让它听起来像一期工程而不是一个代理；主动说"我建的不是一个 chatbot，是让后续 chatbot 都能更快建起来的基础设施"。

模型路由：按什么路由#

路由信号（常见几类，可组合）：

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

实现方式（从简单到复杂）：

方式	说明	特点
静态规则	按关键词、租户、接口路由	简单可预测，但泛化差
语义路由	用 embedding 相似度把 query 匹配到最近的"路由意图"	便宜（一次编码 + 近邻），可在线更新；需要维护意图样本
小模型分类器	用一个小 LLM（如微调过的 4B）做意图/复杂度分类	语义理解好、可定制；需要在关键路径上承担一次小前向
级联（cascade）	先用小模型答，低置信或校验不过再升级大模型	平均成本低；但可能"先答错再重试"，延迟不确定
学习式路由	用数据训练一个 router 预测"哪个模型答得好"	上限高，但需要大量标注与持续维护，工程代价大

路由判断必须便宜（核心设计约束）#

论证：路由在每个请求的关键路径上，所以：

它的延迟直接加到所有请求的体感延迟上。
它的成本要乘以总请求量 —— 这是被请求量放大的开销。

因此两条推论：

路由模型必须小而快。一次短分类前向（小模型、几十个 token 输出）的开销，对比它省下的"一次长上下文大模型生成"，差着量级。这就是用 Qwen2.5-4B 做意图识别的原因（配合"意图识别是分类任务而非生成任务、输出空间小、必须可定制"这几条一起说才完整）。
如果为了决定用哪个模型而先调用了大模型，设计就错了 —— 收益会被路由开销抵消，甚至为负。

自检问题：如果有人质疑"路由本身的开销会不会抵消收益"，答不上来就等于前面全部失效。正确答法是给出量级对比，而不是含糊说"开销很小"。

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

路由一定会有误判，重要的是两类误判代价不同：

误判方向	后果	严重性
难请求 → 小模型（漏判为简单）	直接给出低质量/错误回答，用户可感知，伤害信任，可能触发重试与投诉	严重
简单请求 → 大模型（过度升配）	只是多花了算力和钱，体验无损	轻微

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

置信度阈值：低置信时不赌，直接升配
低置信升级重试：小模型答得不对劲时用大模型重做
误判回流：把误判 case 记录并回灌训练/评测数据（→ 见 observability.md）

这条"代价不对称 → 阈值偏保守"的推理是产品思维的体现，面试里主动讲很加分。

怎么评路由策略（不是只看路由准确率）#

分桶评测：按请求类型分桶，看每桶的质量与成本。总体指标好可能掩盖某一桶的严重退化 —— 这是最容易被忽略也最重要的一条。
分流比例分布：是否符合预期？如果 90% 请求都走了大模型，路由等于没起作用；如果只有 2% 走了大模型，要检查是不是把难请求也判简单了。
单位成本变化：分摊后的每请求成本，以及"省下的钱 vs 路由自身的开销"。
质量不降的验证：路由的目标是"整体质量不降的前提下降成本"，所以必须同时监控质量（用离线评测 + 线上反馈）。
线上反馈：点赞点踩、追问率、转人工率、重试率。
不对称错误分开统计：把"难判简单"和"简单判难"分开算，因为它们的代价完全不同（前者是质量问题，后者是成本问题）。

常见面试问法#

Q：为什么要做 AI 网关？直接每个应用各接各的不行吗？ A：会退化成 M×N 的对接复杂度：M 个应用 × N 个模型/供应商都要各写一套适配、各管密钥、各做限流重试，换模型要改所有应用，密钥散落、成本无法归集、日志分散无法定位。网关把这些横切关注点收拢到一层，变成 M+N，且换模型/加模型不改业务代码。它的价值不在"省了几行代码"，而在于它是一层可复用的基础设施。

Q：为什么要做模型路由？全用大模型不行吗？ A：请求难度差异极大，全用大模型在大量简单请求上双重浪费 —— 浪费钱和延迟；复杂的请求又可能因为排队或成本挤压而得不到足够算力。路由把大模型的算力集中到真正需要的请求上，在整体质量不降的前提下降低单位成本、降低简单请求的延迟。要给出结构性描述（简单请求分流、单位成本下降），不要编具体百分比。

Q：路由判断错了怎么办？错误会怎么传播？ A：代价不对称。把复杂请求误判为简单（走小模型）会直接产生低质量回答，用户可感知、伤害信任；把简单请求误判为复杂（走大模型）只是多花算力，体验无损。所以阈值应偏向保守（宁可升配），并配以置信度阈值、低置信升级重试、以及把误判 case 记录下来回灌训练数据。评估时也要把两类误判分开统计。

Q：路由本身的开销会不会抵消收益？ A：不会 —— 前提是设计正确。路由是每个请求一次短的分类前向（小模型，输出几十个 token 量级），它省下的是一次长上下文的大模型生成，量级差很明显。这就是路由模型必须小而快的原因（也是选 4B 小模型做意图识别的关键）。如果为了决定用哪个模型而先调用大模型，那这个设计本身就是错的 —— 收益会被自己的开销吃掉。

Q：怎么评估路由策略的好坏？ A：不能只看路由准确率。要看：① 分桶评测 —— 按请求类型分桶看质量与成本，总体指标好可能掩盖某桶退化；② 分流比例分布是否符合预期；③ 单位成本变化，以及路由自身开销与省下成本的净收益；④ 线上反馈（点赞点踩、追问率、转人工率、重试率）；⑤ 把"难判简单"和"简单判难"两类错误分开统计，因为一个是质量问题、一个是成本问题。核心目标是"质量不降的前提下降成本"，所以质量与成本必须联合看。

Q：上游模型故障/限流，网关怎么办？ A：超时与重试策略（带退避与重试上限）、熔断（连续失败时快速失败，避免拖垮整体）、降级到备用模型或备用供应商、必要时排队与限流保护下游。同时要能说清降级后的质量损失怎么和用户沟通 —— 这是产品问题也是技术问题（比如显式提示服务降级，而不是静默给次的结果）。

易错点#

❌ 把网关说成一个"转发代理" —— 它集中了密钥、配额、限流、降级、日志、路由，是基础设施层。
❌ 说"路由用大模型来判断该用哪个模型" —— 自毁式设计，收益必被抵消。
❌ 编造路由带来的成本下降百分比。用结构性描述（简单请求分流、单位成本下降）。
❌ 认为路由只要准确率够高就行 —— 不看分桶，会把某一类请求的严重退化藏起来。
❌ 忽略误判代价不对称，把阈值往"省钱"方向调。
❌ 忘了路由也需要评测与闭环：误判 case 要能被记录并回灌训练/评测数据。
❌ 把"统一接口"说成"统一行为" —— 接口统一了，但模型的上下文长度、工具调用格式、能力边界仍然各不相同，上层仍要做能力探测与降级处理。
❌ 忽略缓存的误命中风险（语义缓存把不同问题判成同一个）。

自测#

1. 为什么路由用的模型必须小而快？如果路由用大模型会怎样？

答案

因为路由处在每个请求的关键路径上：它的延迟会加到所有请求的体感延迟上，它的成本要乘以总请求量，是被请求量放大的开销。用小模型做一次短分类前向（几十 token 输出），对比它省下的一次长上下文大模型生成，量级差很明显，所以净收益为正。如果为了决定用哪个模型而先调用大模型，路由开销与省下的成本同量级甚至更大，收益被自己吃掉，设计就失去了意义。这就是选 Qwen2.5-4B 这类小模型做意图识别的关键原因。

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

答案

因为两类误判的代价不对称：难请求被误判为简单（走小模型）会直接给出低质量或错误的回答，用户可感知、伤害信任，还可能触发重试与投诉；简单请求被误判为复杂（走大模型）只是多消耗算力和成本，用户体验没有任何损失。所以决策应偏向"升配"，用置信度阈值兜底 —— 低置信时不赌，直接走大模型；并配合低置信重试与误判回流。这是用不对称损失而非准确率来定阈值的思维。

3. 网关集中了哪些职责？没有网关会付出什么代价？

答案

职责：统一接口（多供应商/自建模型统一协议，换模型不改上层）、密钥与凭证管理（虚拟 key 按应用/客户签发）、配额与预算（成本可按应用/客户归集）、限流（RPM/TPM）、重试/超时/熔断/降级、路由策略、缓存（精确与语义）、日志与链路追踪、安全接入（PII 脱敏、内容审核）。没有网关则退化为 M×N：每个应用各写一套适配、各管密钥、各做限流重试，换模型要改所有应用，密钥散落、成本无法归集、日志分散无法定位。网关把 M×N 压成 M+N。

4. 面试官问「怎么评估你的路由策略」，你会给出哪些指标？

答案

① 分桶评测（按请求类型/难度分桶看质量与成本）—— 最重要，总体指标会掩盖局部退化；② 分流比例分布是否合理（全走大模型等于路由没起作用，极少走大模型要警惕把难请求判简单了）；③ 单位成本变化，并计算"省下的成本 − 路由自身开销"的净收益；④ 质量是否不降（离线评测 + 线上反馈：点赞点踩、追问率、转人工率、重试率）；⑤ 把"难判简单"与"简单判难"分开统计，因为一个是质量问题、一个是成本问题，混在一起算准确率会掩盖真正的风险。

5. 「统一接口」是不是意味着上层应用不用管模型差异了？

答案

不是。统一的是调用协议（请求/响应格式、认证、错误码），不是行为。模型之间仍有实际差异：上下文窗口长度、支持的参数（温度、工具调用、结构化输出格式）、工具调用的可靠性、能力边界、限流与价格。上层仍然需要做能力探测、按模型降级处理（比如某模型不支持某参数要自动裁剪）、以及对不同模型返回质量的差异化处理。网关降低了接入成本，但没有消除能力差异 —— 把这两件事说混是常见的认知漏洞。