三种模型路由怎么选？
Google Cloud Model Routing、LiteLLM 和 OpenRouter 怎么选？本文从模型范围、路由控制、fallback、数据边界、成本与运维责任逐项对比。
Google Model Routing vs LiteLLM vs OpenRouter
模型网关第一版通常很简单：一个虚拟模型名、两个 backend、一条 fallback。半年后，配置里塞满团队预算、重试、区域限制、prompt cache、三套 API 协议和一个没人完全相信的 dashboard。
Google Cloud 2026 年 8 月推出 Model Routing Public Preview，看起来就是“别自己养网关了”。API Gateway 接收 OpenAI-compatible 请求，边转换协议边把流量送到 Vertex AI Model Garden。它和 LiteLLM、OpenRouter 的功能确实重叠，但三者最根本的区别不是算法，而是谁承担责任。
先说结论
- 模型流量本来就在 GCP，规则路由够用，Google Cloud API Gateway 最省心。
- LiteLLM 控制力和 provider 覆盖最强，但升级、状态、扩容和路由回归都归你值班。
- OpenRouter 接模型最快，也能利用全平台性能数据做托管路由，但会多一层商业数据与结算关系。
- OpenAI-compatible 不代表 provider 私有能力经过转码和 fallback 后毫发无损。
- 先选治理边界，再选路由算法。
Google 这次到底发布了什么
Google Cloud API Gateway Model Routing 在 2026 年 8 月进入 Public Preview。它提供 serverless ingress，接收 OpenAI-compatible prompt，然后路由到 Vertex AI Model Garden 中的 Gemini、Anthropic Claude、OpenAI OSS-GPT 等模型。
Google 把 API Gateway 定位为轻量托管 LLM 入口，负责规则路由、rate limit 和 token tracking。来源：Google Developers Blog。
有两个限制很容易被标题掩盖。
第一，它不是把请求转发到任意厂商公开 API 的 marketplace，官方目标是 Vertex AI Model Garden 里可用的模型。第二，发布说明讲的是 OpenAPI 配置里的规则，不是一个能自动判断问题难度、永远选对模型的“智能大脑”。
范围窄反而是它的价值。IAM、audit log、quota、网络边界和账单继续留在企业熟悉的 Google Cloud 体系里。
三种产品，三种责任分配
| 问题 | Google API Gateway | LiteLLM | OpenRouter |
|---|---|---|---|
| 谁运维网关 | Google Cloud | 你的团队或 LiteLLM 服务 | OpenRouter |
| 模型范围 | Vertex AI Model Garden | 大量 provider 直连 | 大型 marketplace catalog |
| 凭证 | Google IAM | 自己的 provider key | OpenRouter credit 或 BYOK |
| 路由方式 | OpenAPI 规则 | 多种算法与 hook | 托管 provider/model 选择 |
| 数据面 | Google Cloud | 自有基础设施 | OpenRouter 加最终 provider |
| 自定义代码 | 有限策略 | 深度 Python/plugin 控制 | Request policy 字段 |
| 最适合 | GCP 治理型负载 | 需要控制的平台团队 | 追求接入速度和模型范围 |
Google 的取舍是把运维交出去，同时接受 Vertex 边界。LiteLLM 把策略和数据面握在手里，也把生产服务背到自己身上。OpenRouter 则连 provider 接入与一部分路由判断一起托管。
Google Cloud 的优势就是“无聊”
API Gateway 原本就负责普通 API 的认证、rate limit、部署和流量策略。模型路由沿用这套控制面，不需要另起一个开源 proxy 技术栈。
应用
-> Google Cloud API Gateway（OpenAI-compatible）
-> 路由规则 + 请求转码
-> Vertex AI Model Garden deployment安全团队已经会用 Google IAM、VPC Service Controls、Cloud Logging 和组织策略时，这条路很顺。平台团队发布一个 endpoint，模型 owner 调整 backend mapping，应用不用改代码。
一旦需要的 provider 不在 Google-hosted 范围里，或者路由要依赖实时质量信号，边界就出现了。它可以继续叠加 Agent Gateway 和 Apigee，但每加一层就多一份策略面和成本。Public Preview 也意味着限制、字段和可用性在 GA 前仍可能变化。
Release Notes 明确写了 OpenAI-compatible 输入、in-flight transcoding 与 Vertex AI Model Garden 路由。来源：Google Cloud Release Notes。
LiteLLM：控制力是有值班成本的
LiteLLM 通过统一 proxy 和 SDK 接大量 provider。Router 支持 simple shuffle、least-busy、usage、latency、cost 等策略，也有 cooldown、retry、context-window fallback、virtual key、team policy 和 custom hook。
这些灵活性正是选择它的原因，也是配置必须像代码一样 review 的原因。
生产升级前至少回归这些场景：
- 主 route 的 streaming tool call；
- 部分 stream 已返回后的 failover；
- 跨 turn 保存 provider 私有 reasoning block；
- context fallback 是否丢 system instruction；
- key、team、global 三层预算与 rate limit；
- provider error mapping 会不会放大 retry。
协议归一化有硬边界。不支持的 request 字段有时能丢掉，response 里的有状态数据却不能随便翻译。比如 Anthropic 签名 thinking block，下一 turn 切到完全不同的 provider，并不等于一次无状态文本 fallback。
LiteLLM 的控制粒度最深，包含 key 和 team 级路由配置。来源：LiteLLM Router Settings。
更完整的自托管取舍可以继续看 LiteLLM vs OpenRouter。
OpenRouter：买的是 marketplace 路由
OpenRouter 把统一 API、合并账单、同模型多 provider 和自动 fallback 放在一起。请求可以限制 provider 顺序、data collection、ZDR、quantization、最高价格、latency 和 throughput。
它最难复制的优势是数据。OpenRouter 能看到多个 provider 的共享可用性与近期性能，再绕开降级容量。单家公司从自己的少量请求里，很难得到同等质量的信号。
代价是多一个中间方。数据处理同时受 OpenRouter policy 和最终 provider 影响。BYOK 会改变计费与排序，并不会把 OpenRouter 从请求路径中删除。响应里必须记录实际 model 和 provider，因为 fallback 可能同时改变延迟、价格、能力和数据区域。
默认 fallback 也要认真看。官方文档说 rate limit、downtime、moderation refusal，甚至 context length validation 都可能触发换模型。它提高了 availability，但 moderation fallback 是产品安全决策，不只是基础设施容灾。
Fallback 并不总是安全
网关架构图喜欢画一条从 Model A 到 Model B 的漂亮箭头，实际 conversation 是带状态的。
| 失败场景 | 安全默认值 | 原因 |
|---|---|---|
| 响应前连接失败 | 重试同能力 deployment | 客户端没收到输出 |
| 响应前 429 | 同模型换区域/provider | 能力保持稳定 |
| Stream 一半断开 | 不要静默重放 | 可能重复输出或 tool call |
| Context 超限 | 显式 compact 或拒绝 | 小窗口可能丢指令 |
| Content policy 拒绝 | 默认返回拒绝 | 换模型会改变安全语义 |
| Tool 已执行 | 根据 idempotency 恢复 | 直接重试会修改两次 |
这张表应该直接变成 gateway test。Agent 流量不能只写 retries: 3，tool call 会产生副作用。模型调用前分配 idempotency key，持久化工具状态，并区分“完全没返回字节”和“动作后 stream 中断”。
成本不能只看 token 单价
Google API Gateway 要算 gateway request、日志、网络和 Vertex 模型费。LiteLLM 要加 compute、Redis/数据库、observability、工程升级与 incident ownership。OpenRouter 则要看充值或 BYOK fee、实际 provider 价格和企业功能。
表格里最便宜的 router，可能因为破坏 prompt cache locality 变成最贵的那个。OpenRouter 有 sticky routing，自托管 LiteLLM 能实现 affinity，Google 规则也能把 workload 固定到已知 deployment。Cache read 节省和 fallback 频率要放在同一张图里看。
一套能直接用的选择规则
选 Google Cloud API Gateway，如果：
- 工作负载和治理已经在 GCP；
- 需要的模型都能从 Vertex AI 获取；
- 托管规则、IAM、quota 和日志比自定义算法重要。
选 LiteLLM，如果：
- Provider portability 和自托管数据流是硬要求；
- 平台团队确实有能力运维和测试网关；
- 路由依赖 custom policy、hook 或内部成本信号。
选 OpenRouter，如果：
- 优先级是大范围模型接入和快速实验；
- 托管 provider health 与 fallback 有价值；
- 安全评审能接受额外中间方和计费模式。
Agent 还要运行隔离代码或访问外部 API 时，可以把 SandBase 放在模型路由层的后面或旁边。模型选择和工具授权要分开：路由到便宜模型，绝不能顺手给它更大的执行权限。
我的判断
Google Model Routing 不是全场景 LiteLLM 替代品，而是一个更窄、更托管的 Google-hosted 模型入口。OpenRouter 赢在立即可用的 catalog 和共享路由数据，LiteLLM 赢在控制力。
GCP 中心型企业，我默认选 Google；小团队验证 model-market fit，先用 OpenRouter；只有组织里真有平台 owner，我才会建议上 LiteLLM。“能把 container 跑起来”和“拥有这个网关”是两回事。
FAQ
Google Cloud Model Routing 已经 GA 了吗？
没有。Google 在 2026 年 8 月宣布它进入 Public Preview。
Google API Gateway 能路由任意外部模型 API 吗？
发布文档聚焦 Vertex AI Model Garden 中支持的基础模型，不是任意公开 provider endpoint。
LiteLLM 自托管就是免费吗？
软件可以开源自托管，但生产 compute、状态、observability、升级和 on-call 都要成本。
OpenRouter 一定使用我请求的模型吗？
如果没有配置 model fallback，会使用指定模型；provider routing 仍可能在提供该模型的多个上游之间选择。
Agent 模型请求失败后应该自动重试吗？
只有系统确认没有副作用或部分输出被提交时才适合。涉及 tool call 时，先有 idempotency 和执行状态，再谈自动 retry。
