智能体面试准备（六十四）：智能体多模型路由与 LLM 网关工程——路由、降级、成本路由与一致性-迪斯科星球

智能体面试准备（六十四）：智能体多模型路由与 LLM 网关工程——路由、降级、成本路由与一致性

引言

前面（五十四）讲了大模型推理成本与吞吐调优，（五十七）讲了多模态评测。但当一个智能体系统要同时服务很多种任务——简单分类、长文档摘要、代码生成、多模态看图、复杂推理——把所有请求都丢给同一个旗舰模型，既不经济也不可能（旗舰模型吞吐有限、还贵）。真实生产是一座"模型花园"：小模型便宜快、大模型贵但强、专用模型（embedding、rerank、视觉）各管一摊。

把这些模型统一挡在一层"LLM 网关"后面，按请求特征路由，是工程上的标准答案。本文讲路由策略、降级容错、成本路由、多模型一致性，含架构与代码。结尾给速答。

一、为什么需要 LLM 网关

无网关(反模式) 有网关 Agent --直接调--> GPT-4 Agent --调--> 网关 --路由--> 小/中/大模型 Agent --直接调--> 自建7B |--降级/重试/限流 Agent --直接调--> 视觉模型 |--成本/质量统计 每个调用点硬编码模型, 难治理 统一治理: 路由/观测/配额/安全

网关把"用哪个模型"从业务代码里解耦出来。好处：① 换模型不碰业务；② 统一限流/配额/审计（呼应六十/六十一）；③ 成本可路由（便宜任务别用贵模型）；④ 故障可降级（旗舰挂了切备用）。

二、网关分层架构

LLM 网关架构 +------------------------------+ 请求 -> [接入层] ->| 鉴权/限流/租户配额 | | | | | [路由层] 按特征选 model | | - 任务类型 | | - 长度/复杂度启发式 | | - 用户档位(SLA) | | - 实时成本/负载 | | | | | [执行层] model 池 | | 小模型 / 中模型 / 大模型 / 视觉| | 每个带 降级候选 + 重试 | | | | | [观测层] 成本/质量/延迟/命中 | +------------------------------+

关键设计：路由层是纯函数（输入特征 → 输出 model 列表，含主选+降级序），执行层负责按序尝试；两者解耦便于 A/B 不同路由策略。

三、路由策略：从规则到学习

3.1 规则路由（起步必做）

路由规则(示例) 任务类型=分类/抽取 -> 小模型(7B), 快且够 任务类型=摘要 -> 中模型(14B) 任务类型=复杂推理/代码 -> 大模型 输入长度>8k -> 支持长上下文模型 含图像 -> 视觉模型 用户=SLA高优 -> 直接大模型

规则路由可解释、好调试，覆盖 80% 场景。缺点：靠人写规则，难以精细。

3.2 学习路由（Router / 级联）

更进阶：训一个小 router，输入（任务描述+长度+历史难度），输出模型选择或"先小后大"的级联决策。代表思路：用"小模型能答对就用小模型，答不上再升级"的级联（cascade），用校验器判断小模型输出是否可信。

级联路由 query -> 小模型 -> 校验器(答案置信?) --高--> 返回(省成本) --低--> 中模型 -> 校验 -> 低 -> 大模型

3.3 成本路由

把"预算"作为路由维度：给每次调用一个 cost budget，按"预期成本 + 质量达标"选最便宜够用的模型。呼应（五十四）三本账。

四、代码：最小 LLM 网关

import time, random MODELS = { "small": {"endpoint": "http://7b:8000", "cost": 1, "ok": True}, "mid": {"endpoint": "http://14b:8000", "cost": 3, "ok": True}, "large": {"endpoint": "http://72b:8000", "cost": 10,"ok": True}, } def route(req): # 规则路由: 返回 [主选, 降级1, 降级2] if req.get("has_image"): return ["vision", "large"] if req["task"] in ("classify", "extract"): return ["small", "mid", "large"] if req["task"] in ("reason", "code"): return ["large", "mid"] if req["len"] and req["len"] > 8000: return ["longctx", "large"] return ["mid", "small", "large"] def call_model(name, req): m = MODELS.get(name) if not m or not m["ok"]: raise RuntimeError(f"model {name} unavailable") # 真实: POST m["endpoint"], 这里占位 return f"[{name}] ans" def gateway(req, budget=None): plan = route(req) last_err = None for name in plan: if budget is not None and MODELS[name]["cost"] > budget: continue try: t0 = time.time() ans = call_model(name, req) log(req, name, time.time()-t0) # 观测 return ans except Exception as e: last_err = e continue # 降级到下一个 raise last_err or RuntimeError("all models failed")

降级顺序很重要：主选失败后按"代价递增、能力递减"的顺序试，保证最终能出结果；同时记录"降级触发率"做看板（降级率突增=主模型不健康）。

五、降级与容错

故障场景 网关应对 旗舰模型 503 降级到次选; 次选也挂->排队/限流返回 429 某模型延迟飙高 超时(如 8s)切下一个; 标记模型 unhealthy 临时摘流 配额耗尽(云API) 切到自建模型; 或返回降级答案+提示 单模型结果质量差 级联: 校验不过升级模型

要点：① 每个模型有 timeout + 不健康计数，连续失败临时摘流（circuit breaker）；② 降级要可观测，不能"悄悄用差模型"还以为是旗舰；③ 对外 SLA 高的请求可以"双发取快"（ hedging），用一点成本换尾延迟。

六、多模型一致性

路由到不同模型，最头疼的是"同一问题不同模型答案风格/结论不一致"，尤其当一次会话里前半用大模型、降级用小模型。治理：

输出契约化：关键字段用 schema/JSON 约束，模型只填槽位，风格差异被结构吸收。
系统提示统一：所有模型共享同一份 instruction 骨架，仅能力不同。
关键决策锁模型：涉及最终对外结论的步骤锁死大模型，不降级；只有内部中间步骤允许降级。
一致性评测：定期用 Golden Set 跑各模型，监控答案一致性分布（呼应五十六回归门禁）。

七、成本与质量观测

网关必看指标 成本: 每请求成本 / 路由分布(多少走了小模型) / 预算命中率 质量: 级联升级率 / 小模型置信通过率 / 端到端任务成功率 稳定: 降级触发率 / 模型不健康次数 / P99 延迟

路由策略优化本质是"在质量达标前提下把成本压最低"，是持续调参过程。常见目标：在不掉任务成功率的前提下，把小模型承载比例从 30% 提到 60%。

八、与（六十一）可观测、（五十四）成本的衔接

网关是成本与观测的天然采集点：每一次路由选择、每一次降级、每一分钱都在这层发生。把网关指标接进（六十一）的可观测面板、把成本路由接进（五十四）的三本账，整套"省钱且稳"的闭环就通了。

面试速答

问：为什么要 LLM 网关？
答：解耦"用哪个模型"，统一路由/降级/限流/配额/审计/成本统计；换模型不碰业务，故障可降级。

问：级联路由（cascade）是什么？
答：先用小模型，校验器判可信就返回，不可信升级中/大模型。在质量达标前提下降成本。

问：多模型一致性怎么保证？
答：输出契约化(schema)、统一 system 提示、关键结论锁大模型不降级、Golden Set 一致性评测。

高频追问清单

规则路由和学习路由分别适用什么阶段？
级联路由的校验器怎么设计才不会"小模型自信地错"？
降级顺序怎么排？为什么按代价递增？
circuit breaker 在模型网关怎么实现？
成本路由的 budget 怎么定？和 SLA 怎么权衡？
hedging（双发取快）什么时候用、代价多大？
多模型答案不一致，生产怎么兜底？
网关怎么做租户级配额与限流？
路由策略怎么 A/B 评估效果？
视觉模型怎么并入同一网关路由？

企业官网建设流程全解析