LLM 多模型统一网关实战:路由、降级与成本控制

更新日期：2026-10-05

2026 年的模型发布节奏,把「只接一家」的架构代价摆上了台面:9 月一个月里,Google 连发 Gemini 3.8 Flash 与 Gemini 4 Argon,Anthropic 更新了 Fable 5.1 与 Opus 5.5,更早还有 GPT-6 Astra;各家的 Flash 档(GLM-5.3-Flash、3.8 Flash、Haiku 系)与旗舰档的价格差在五倍以上,能力边界各不相同,可用性事故各自发生。当你的业务同时在用两三家模型时,真正的问题从「接哪个 SDK」变成:路由怎么定、一家挂了怎么降、预算怎么不被单次失控调用打穿、审计怎么对得上账。这四个问题有一个共同答案——在业务代码与模型供应商之间加一层统一网关。

本文按自建与托管两条路线讲:LiteLLM 代表的开源自建网关,OpenRouter、Vercel AI Gateway、Cloudflare AI Gateway 代表的托管网关,功能上怎么选;然后依次落地降级链与熔断、按任务的路由策略、预算与用量拆账,以及密钥与数据策略。写作背景是本站多模型接入的工程实践——评估维度参考 GLM-5.3-Flash 生产实测与接入指南,接入形态参考 Cloudflare AI Search 接入 GLM-5.3-Flash:检索与生成分离实战,模型侧的选型分析见同批的 Gemini 4 Argon 发布解读 与 Claude Fable 5.1 与 Mythos 5.1 发布解读。

适用范围:已接入或计划接入两家以上模型供应商的后端/平台团队,日均调用量从几千次到千万次均可参照,配置示例以 LiteLLM 代理与 Cloudflare AI Gateway 的公开文档为准。不适用场景:只接一家且调用量小、挂了可以人工兜底的——网关层的运维成本会超过收益,把超时重试写好即可;对数据出域零容忍且无私有化部署条件的——托管网关的数据策略先过法务再谈架构;期待网关解决提示注入的——那是应用层的安全问题,网关管的是路由、可用性与成本,不是内容安全。

先看结论

1. 网关层只有四个职责:统一协议与密钥、路由分流、故障降级、预算与审计。任何超出这四项的「网关功能」都要先问一句是否该放在这一层。
2. 自建(LiteLLM)与托管(OpenRouter/Vercel/Cloudflare)的第一分野是数据路径:托管网关意味着流量经第三方,数据策略(BYOK、零保留承诺)要在选型时逐条核;自建网关意味着你自己运维它,网关本身成了新的单点。
3. 降级不是「换个模型名」:上下文窗口差异(context_window_fallbacks)、内容策略差异(content_policy_fallbacks)、能力差异都要有对应的 fallback 分组,否则降级后的输出质量崩塌比 5xx 更伤业务。
4. 熔断参数要显式配置:allowed_fails 与 cooldown_time 决定「失败几次、歇多久再试」,默认值不匹配你的流量形态时,要么熔断太敏感要么形同虚设。
5. 预算控制必须 fail closed:LiteLLM 的 max_budget 依赖数据库,DB-less 部署下预算检查 fail open(放行)——这是文档明说的行为,用 DB-less 部署又指望预算兜底的组合是自欺。
6. 虚拟密钥按「服务 × 环境」发放,不是按人:每个下游服务一把 key、独立预算、独立用量账,失控时能单独吊销。
7. 路由策略按业务指标选:延迟敏感用 latency-based,成本敏感用 lowest cost/usage-based,容量敏感用 rate-limit aware;默认的 simple-shuffle 只适合无差别负载。
8. 降级演练是上线条件,不是上线后规划:把主模型指向一个必然失败的目标跑真实流量验证 fallback 链,这条没做,降级配置的真实行为就是未知的。

网关层的四个职责

先把边界画清楚,网关层做得好不好,取决于这四件事有没有各自的量化口径:

值得强调的是「统一协议」的隐性收益:2026 年这种发布节奏下,你的评测集与流量回放能力是跟着统一接口走的——新模型发布当天,把模型 ID 换掉跑一轮评测,接入成本从「周」变「小时」。这是网关层对抗行业快节奏的根本手段。

选型:自建 LiteLLM 还是托管网关

四条路线的公开事实对比(功能描述以各家官方文档为准):

选型判据按顺序过:数据合规——模型供应商的密钥与请求内容是否可以交给第四方,答案是否定的直接排除托管路线;运维预算——没有人管 LiteLLM 的高可用,就别把它放进关键路径;生态契合——业务在 Vercel 上,AI Gateway 的零加价与 budgets 是顺手的选择;全站已在 Cloudflare,AI Gateway 的边缘位置与可观测性集成顺理成章;多供应商深度——需要在路由策略上做精细控制(weighted、usage-based)的,LiteLLM 的策略面最宽。

混合路线也常见且合理:托管网关做主干(省运维),LiteLLM 只在数据敏感的内部服务前自建一层——两层的预算与审计口径要统一,否则对账时会出现「账对不上但都说是对的」的经典僵局。

降级设计:fallback 链与熔断

降级设计的核心认知:fallback 目标不是一个模型,是一组按「降级后仍然可用」筛选过的模型。主模型挂了切到一个上下文窗口只有一半的备用,长会话请求直接超限——这不是降级,是把 5xx 换成 400。LiteLLM 的文档把这件事拆成了三组配置,照抄结构即可:

# LiteLLM proxy 的 fallback 配置示例(config.yaml 片段,以官方文档为准)
cat > litellm-fallbacks.yaml <<'YAML'
model_list:
  - model_name: coding-primary
    litellm_params:
      model: anthropic/claude-opus-5-5
  - model_name: coding-fallback
    litellm_params:
      model: gemini/gemini-3.8-flash
  - model_name: coding-budget
    litellm_params:
      model: openai/gpt-6-mini   # 示例名,以你的实际接入为准

router_settings:
  fallbacks:
    - "coding-primary": ["coding-fallback", "coding-budget"]
  context_window_fallbacks:
    - "coding-primary": ["coding-budget"]   # 超长上下文直接走大窗口目标
  num_retries: 2
  allowed_fails: 3          # 连续失败 3 次触发熔断
  cooldown_time: 30         # 熔断 30 秒后恢复探测
YAML

三条工程纪律:第一,链上每一环都验证过真实可用——能力评测(质量、延迟、上下文)对 fallback 目标与主目标同等执行,很多团队只测主模型,fallback 名存实亡;第二,熔断参数按流量形态调,allowed_fails=3 对每秒千次请求是秒级切换,对每天百次请求可能一周都触发不了,低流量场景把探测做成主动健康检查更有效;第三,降级要可观测——Cloudflare AI Gateway 用 cf-aig-step 响应头标记命中了链条第几步,自建网关至少要在日志里记 fallback 事件,值班看板要能看到「当前有多少流量在降级状态」,否则降级会静默地吃掉质量一周没人发现。

托管侧的等价配置,以 Cloudflare AI Gateway 为例:Universal Endpoint 按错误或超时触发逐级 fallback,请求时在头部/端点里声明模型顺序,命中步骤见 cf-aig-step 头;OpenRouter 则在请求体的 provider routing 里声明 provider.order 与 allow_fallbacks,模型级 fallback 由其 Model Fallbacks 机制处理。语义都一样,配置字段以各家当日文档为准。

路由策略:按任务分流

路由的前提是请求带「任务语义」:编码、客服、摘要、批量分析,各自的 SLO 与成本容忍度不同。LiteLLM 文档的策略清单对应关系:

落地建议分两步走。第一步给请求打标:业务侧在调用时带上 task_type(哪怕先用粗粒度的 interactive/batch 两类),这一步不改架构,只改调用习惯,但它是后面一切精细路由的输入。第二步按标签配策略:interactive 走 latency-based 指向旗舰/Flash 档,batch 走 lowest cost 或直接 Batch API(五折),长上下文任务按 context_window_fallbacks 兜底。不要一开始就上 usage-based + Redis 的完整形态——那个复杂度是为「配额就是产能」的团队准备的,一般业务用 weighted 加预算就已经解决 80% 的问题。

成本控制:预算、虚拟密钥与拆账

预算体系的三个层级,从粗到细:组织级月度总预算(LiteLLM max_budget 配数据库,或 Vercel budgets 直接拒绝超支请求)、服务级虚拟密钥预算(每个下游服务一把 key、独立上限)、任务级单次请求护栏(最大 token 数、最大重试深度)。配置动作:

# LiteLLM:为虚拟密钥设月度预算(需接数据库;DB-less 部署预算检查会 fail open!)
# 生成一把 $200/月 的虚拟 key(命令形态以官方文档为准):
curl -s -X POST "http://localhost:4000/key/generate" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"max_budget": 200, "budget_duration": "30d", "key_alias": "svc-coding-assistant"}' \
  | jq '{key: .key, max_budget: .max_budget}'

再把那句文档里明说的风险翻译成人话:LiteLLM 在 DB-less 模式下预算检查 fail open——数据库不可用时请求照放。预算控制依赖持久化状态,这是架构约束不是 bug;用 DB-less 的人要么接受「预算尽力而为」,要么给数据库上高可用,不能两者都不做还指望预算兜底。

拆账是预算的另一半:请求日志要能按「服务 × 任务类型 × 模型」三个维度聚合出单位成本,并且定期与供应商账单对账(差异率应低于 1%,持续偏高说明有调用绕过网关或日志丢失)。绕过网关的调用是预算体系最大的洞——供应商密钥只在网关持有(虚拟密钥只发业务),是唯一可靠的堵法。

密钥与数据策略

托管网关的选型里,数据策略要逐条核的不是营销页而是文档:OpenRouter 的 provider routing 支持数据策略过滤(按「不训练」等政策筛选供应商)与 BYOK(自带供应商密钥,流量经网关但计费与策略走你自己的账号);Vercel AI Gateway 支持 BYOK 且对 provider token 价格零加价;Cloudflare AI Gateway 的日志保留与 SOC 类合规以平台文档为准。BYOK 的实质是「路径分离」:数据路径仍经第三方,但供应商关系与密钥在你手里——对多数合规评审,这比「完全托管」好谈,比自建省事,是很多团队的落点。

自建侧的密钥纪律只有三条:供应商密钥只存在于网关的密钥库(环境变量注入或 secret manager),业务代码与配置库零出现;虚拟密钥按服务发放、支持单独吊销;密钥轮换演练进运维日历(供应商侧泄露事件轮到你时,从发现到全量换完应该在分钟级)。

验证与演练

上线前的三个必做演练,每个都有明确的通过判据:

# 演练 1:降级链——把主模型指向一个必然失败的假模型,验证 fallback 与熔断
curl -s http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $VIRTUAL_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "coding-primary", "messages": [{"role": "user", "content": "ping"}]}' \
  | jq '{model: .model, content: .choices[0].message.content}'
# 通过判据:请求成功返回,网关日志显示 fallback 事件与实际生效模型

# 演练 2:预算拦截——把测试 key 预算调到 $0.001,确认请求被拒(fail closed)
# 通过判据:返回预算超限错误;同时验证 DB 停掉时的行为(预期 fail open,记录在案)

# 演练 3:熔断恢复——连续打失败目标,确认 allowed_fails 触发冷却,
# cooldown_time 后流量恢复探测,业务侧无持续报错

三个演练的结果写进值班手册:降级时的实际生效模型、预算拦截的错误形态、熔断的恢复时间。网关层的回滚很简单——业务调用的是网关地址,把 DNS/路由切回直连供应商(保留一段双跑期)即可;但双跑期的账单拆分要提前想好,否则回滚决策会被「成本说不清」拖住。

检查清单

• 统一协议:业务代码零供应商 SDK 依赖,新增模型不改业务代码。
• 供应商密钥只在网关持有;业务侧只有虚拟密钥;轮换演练通过。
• 降级链三组配置(fallbacks/上下文/内容策略)与熔断参数就位,fallback 目标全部通过能力评测。
• 演练 1–3 全部通过,结果写入值班手册。
• 预算三层齐备,预算系统的持久化依赖的高可用方案明确(DB-less fail open 已知并接受,或数据库已加固)。
• 用量观测按「服务 × 任务 × 模型」拆账,与供应商账单月度对账,差异率 < 1%。
• 托管路线(如适用):数据策略、BYOK、日志保留逐条过合规评审,评审结论存档。
• 网关自身的高可用方案明确(双实例、健康检查、业务侧超时与重试语义)。
• 回滚路径:切回直连的操作单与双跑期的账单拆分方案成文。

官方资料与继续阅读

外部官方链接(功能以各家当日文档为准):

• LiteLLM 可靠性与 fallback 文档:https://docs.litellm.ai/docs/proxy/reliability
• LiteLLM 路由策略:https://docs.litellm.ai/docs/routing
• LiteLLM 虚拟密钥与预算:https://docs.litellm.ai/docs/proxy/virtual_keys 、https://docs.litellm.ai/docs/proxy/users
• OpenRouter Provider Routing 与 Model Fallbacks:https://openrouter.ai/docs/features/provider-routing 、https://openrouter.ai/docs/guides/routing/model-fallbacks
• Cloudflare AI Gateway Fallbacks:https://developers.cloudflare.com/ai-gateway/configuration/fallbacks/
• Vercel AI Gateway:https://vercel.com/docs/ai-gateway
• 各厂商定价页:Anthropic https://docs.anthropic.com/en/docs/about-claude/pricing 、OpenAI https://platform.openai.com/docs/pricing 、Gemini https://ai.google.dev/gemini-api/docs/pricing 、Z.ai https://z.ai/pricing

站内相关文章:

• GLM-5.3-Flash 生产实测与接入指南:速度、成本和长上下文怎么评估——单模型评估框架,网关评测集的输入
• Cloudflare AI Search 接入 GLM-5.3-Flash:检索与生成分离实战——检索增强场景的接入形态
• Gemini 4 Argon 发布解读:与 GPT-6 Astra、Claude Opus 5.5 怎么选——模型侧的选型与迁移判据
• Claude Fable 5.1 与 Mythos 5.1 发布解读:Claude Code 该配哪个模型——Claude 线的配置与成本结构

事实与日期边界:本文功能描述截至 2026-10-05,均以上列各家官方文档为准;配置示例为文档语法的示意,字段名与取值随版本演进,采用前以官方文档当日版本核对;各厂商价格请以定价页实时数据为准,本文不复制具体价格数字到决策文档。