教程
Google Cloud API Gateway 多模型路由实战：一个 OpenAI 兼容入口同时接 Gemini、Claude 和 OSS-GPT
企业 AI 应用越来越少只使用一个模型。客服可能用低成本模型处理普通问题，代码任务需要更强推理模型，离线批处理又可能使用开源模型。如果每个业务应用都直接连接不同厂商 API，模型地址、认证、重试、限流、切换和成本统计很快会散落在所有代码库里。Google Cloud API Gateway 已经提供 Model Routing Public Preview，可以暴露一个 OpenAI 兼容入口，通过 OpenAPI 3.x 中的 `x-google-api-management` 和 `x-google-model-router` 规则，把请求动态路由到 Gemini、Claude 或 OpenAI OSS-GPT 等 Google Cloud 托管模型。真正的价值不是“一个 API 调三个模型”，而是把业务代码和具体模型供应商解耦。
# Google Cloud API Gateway 多模型路由实战：一个 OpenAI 兼容入口同时接 Gemini、Claude 和 OSS-GPT
## 文章摘要
企业 AI 应用越来越少只使用一个模型。客服可能用低成本模型处理普通问题，代码任务需要更强推理模型，离线批处理又可能使用开源模型。如果每个业务应用都直接连接不同厂商 API，模型地址、认证、重试、限流、切换和成本统计很快会散落在所有代码库里。Google Cloud API Gateway 已经提供 Model Routing Public Preview，可以暴露一个 OpenAI 兼容入口，通过 OpenAPI 3.x 中的 `x-google-api-management` 和 `x-google-model-router` 规则，把请求动态路由到 Gemini、Claude 或 OpenAI OSS-GPT 等 Google Cloud 托管模型。真正的价值不是“一个 API 调三个模型”，而是把业务代码和具体模型供应商解耦。
---
一个 AI 项目刚开始时，很多人会这样写：
```python
if model == "gemini":
call_gemini()
elif model == "claude":
call_claude()
elif model == "openai":
call_openai()
```
做 Demo 没问题。等公司出现几十个 AI 服务以后，问题就会集中爆发：每个服务都有自己的 SDK、API Key、Retry、Token 统计、模型切换和错误处理。
最终，没有人能快速回答“这个模型如果明天退役，哪些业务会受影响”。
LLM Gateway 就是为解决这个问题出现的。
## 理想架构应该让业务只看到一个入口
```text
Application
↓
LLM Gateway
├── Auth
├── Routing
├── Rate Limit
├── Token Tracking
├── Policy
└── Observability
↓
Model Backends
├── Gemini
├── Claude
└── OSS Model
```
应用只调用一个稳定的企业地址，具体模型由平台层决定。
## Google Cloud API Gateway 现在能做什么？
Google Cloud API Gateway 的 Model Routing 当前处于 Public Preview。它允许开发者通过一个 OpenAI 兼容请求入口，把请求路由到 Google Cloud 上不同模型后端。
官方示例包括 Gemini、Claude 和 OpenAI OSS-GPT。
Gateway 负责接收 OpenAI 风格 Payload、根据路由选择后端、转换请求结构、添加 Agent Platform 所需认证，再调用实际模型。
## 最大价值是客户端和模型后端解耦
应用永远可以调用：
```text
https://ai.company.com/v1/chat
```
Gateway 后面今天是 Gemini，明天可以切 Claude，后续也可以换成 OSS 模型。
业务代码不应该因为模型升级而反复改 SDK 和 Endpoint。
## 客户端认证和后端认证应该分离
传统做法：
```text
Application
↓
Vendor API Key
↓
Model
```
很多业务系统都保存供应商密钥。
Gateway 后可以变成：
```text
Application
↓
Company API Key / OAuth
↓
Gateway
↓
Backend Credential
↓
Model
```
应用只认证到企业 Gateway，后端模型密钥可以统一轮换。
## 一个最小路由配置长什么样？
概念上可以这样理解：
```yaml
openapi: 3.0.4
x-google-api-management:
backends:
gemini-fast:
address: https://aiplatform.googleapis.com/...
deadline: 60
claude-strong:
address: https://aiplatform.googleapis.com/...
deadline: 60
ai:
models:
routing:
routers:
default-router:
defaultModel:
backend: gemini-fast
rules:
- model: claude-strong
backend: claude-strong
```
业务请求只需要传：
```json
{
"model": "claude-strong",
"messages": [
{"role": "user", "content": "分析这段代码"}
]
}
```
## 不要把真实 Model ID 暴露给所有业务
更成熟的做法不是让业务写：
```text
publishers/anthropic/models/claude-xxx
```
而是使用虚拟模型名：
```text
chat-fast
chat-balanced
reasoning-high
coding-high
batch-cheap
```
平台映射：
```text
chat-fast → Gemini
reasoning-high → Claude
batch-cheap → OSS Model
```
这就是 Virtual Model。
## Virtual Model 能显著降低模型升级成本
模型从 v1 升到 v2 时，只改 Gateway 映射。业务代码不用改。
某个后端故障时，也可以把 `reasoning-high` 切到备用模型。
业务应该选择“能力档位”，平台选择“具体模型”。
## 推荐的模型能力分层
例如：
```text
chat-fast
chat-balanced
reasoning-high
coding-high
vision
embedding
batch-cheap
```
不要让每个开发者直接面对 20～30 个具体模型。模型选择越分散，治理越困难。
## 路由可以按什么条件做？
最简单的是业务明确选择虚拟模型。
还可以按用户套餐：Free 走 fast，Enterprise 走 high。
也可以按任务类型：分类走小模型，复杂推理走强模型，离线批处理走低成本模型。
更复杂的动态路由，比如实时根据质量、预算和健康状态自动决策，可能需要在 API Gateway 之外再加一层 AI Gateway Service。
## 当前一个很重要的限制
Google 官方说明，同一个 Router 中引用的 Backend 需要共享同一个 Host，例如：
```text
aiplatform.googleapis.com
```
所以它不是一个“任意互联网厂商通用反向代理”。更准确地说，它适合 Google Cloud 托管模型生态内的统一入口。
Claude 之所以能被路由，是因为可以作为 Google Cloud 托管模型后端访问。
## OpenAI 兼容为什么有价值？
大量框架已经支持：
```text
base_url
api_key
```
如果内部 Gateway 提供 OpenAI 兼容接口，很多 RAG、Agent、SDK 和内部服务只需要改 `base_url`，不必重写完整 Provider Integration。
这会大幅降低迁移成本。
## 但“API 兼容”不代表“行为完全一样”
不同模型仍然会在这些方面存在差异：
- Tool Calling；
- Structured Output；
- Reasoning；
- Image Input；
- Streaming；
- Context；
- Safety；
- Token Accounting。
所以模型切换前必须跑 Evals。
## 建议增加内部 Capability Registry
例如：
```yaml
chat-fast:
supports:
- text
- streaming
- tools
reasoning-high:
supports:
- text
- tools
- structured_output
```
应用先判断需要什么能力，再选择虚拟模型。
## 限流最好做四层
```text
User
↓
Tenant
↓
Application
↓
Virtual Model
```
例如：
```text
用户 60 req/min
租户 500 req/min
应用 200 req/min
reasoning-high 50 req/min
```
这样一个 Agent 不会把整个公司的高端模型额度打满。
## 成本必须能追溯到业务
每次调用至少记录：
```text
tenant
user
application
virtual_model
actual_model
input_tokens
output_tokens
latency
cost
status
```
否则最终只会得到一张无法解释的 Cloud Bill。
## Budget Policy 也应该放在 Gateway 层
可以按部门分预算：
```text
marketing → $1,000 / month
engineering → $5,000 / month
research → $10,000 / month
```
到 80% 时告警，到 100% 时降级或要求审批。
真正成熟的模型路由不是只考虑“哪个模型最强”，而是同时考虑业务价值、SLA 和成本。
## 模型切换必须灰度
假设 `chat-balanced` 从 Model A 切 Model B，不要一次性 100%。
建议：
```text
1%
→ 10%
→ 25%
→ 50%
→ 100%
```
同时看：
- Task Success；
- Latency；
- Cost；
- Safety；
- User Feedback。
## Evals 至少覆盖哪些任务？
- FAQ；
- Code；
- RAG；
- Structured JSON；
- Long Context；
- Tool Calling；
- 中文；
- 边界请求；
- 安全问题。
不能只看厂商 Benchmark。
## Fallback 不能盲目
429、Timeout、临时 5xx 可以考虑备用模型。
Invalid Request、Schema Error、Permission Error 通常不是换模型能解决的。
如果所有错误都自动 Fallback，很容易出现“同一个错误连续调用三个模型，成本翻三倍”。
## Agent 写操作还必须有幂等
模型网关不能替代业务事务控制。
例如 Agent 调用 `create_order` 已经成功，但网络超时，Gateway 又切另一个模型重试，可能导致重复创建订单。
因此写工具必须使用：
```text
idempotency_key
```
Gateway 负责模型路由，业务层负责业务幂等。
## 推荐的企业架构
```text
Client
↓
API Gateway
├── Auth
├── Rate Limit
├── Virtual Model Routing
└── Token Tracking
↓
AI Gateway Service（可选）
├── Capability Check
├── Policy
├── Budget
├── Eval Flag
├── Retry
└── Trace
↓
Google-hosted Models
├── Gemini
├── Claude
└── OSS-GPT
```
小团队可以直接从 API Gateway 开始。复杂企业再增加 AI Gateway Service。
## 什么时候这条路线特别合适？
- 企业已经主要运行在 Google Cloud；
- 希望使用 Serverless Gateway；
- 不想维护开源网关集群；
- 需要的模型都能从 Google Cloud Host 获取；
- 希望和 Google IAM、Logging、Cloud 运维体系整合。
## 什么时候可能需要自建网关？
如果你需要直接跨多个互联网模型厂商、完全自定义缓存、复杂动态路由、特殊 Billing 或完全自托管，开源或自研 LLM Gateway 可能更合适。
## 一个稳妥的迁移路线
第一步，选一个非关键 AI 应用。
第二步，把它的 `base_url` 改到企业 Gateway。
第三步，换成虚拟模型名。
第四步，加 Token、Cost 和 Trace。
第五步，引入第二个模型后端。
第六步，加灰度和 Fallback。
最后再逐步统一更多 AI 服务入口。
## 总结
Google Cloud API Gateway Model Routing 真正解决的不是“怎么同时调用 Gemini、Claude 和 OSS-GPT”，而是怎么让业务代码不再被具体模型供应商绑死。
成熟企业 AI 架构应该逐渐从：
```text
App → Vendor API
```
转向：
```text
App → Company AI Endpoint → Routing → Model
```
这样企业才能统一管理认证、模型、限流、Token、成本、Fallback 和审计。
Google Cloud 当前 Public Preview 的实现提供了 OpenAI 兼容入口、OpenAPI 3.x 路由配置、多个 Google Cloud 托管模型后端以及客户端与后端认证分离。如果企业已经深度使用 Google Cloud，这是一条非常值得测试的 LLM Gateway 路线。
想继续了解模型路由、LLM Gateway、Agent 基础设施和企业 AI 工程，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续整理真正能够进入生产环境的 AI 架构实践。