Google Cloud API Gateway model routing 的规格优先路线和共享主机限制

Google Cloud API Gateway model routing 在 8 月 4 日进入 Public Preview。它给团队提供了一种 serverless 做法，可以暴露一个 OpenAI-compatible endpoint，再把请求转到 Vertex AI 后面的 Gemini、Claude 或 OpenAI OSS-GPT 模型。这里最该看的细节不只是 Google 加了一个 router。router 放在 OpenAPI 3.x 规格里，挂在 Google 的 x-google-api-management 扩展下面，模型选择由配置表达，不靠 gateway 代码。

对已经把模型调用收进 Vertex AI 的平台团队来说，这是一条很干净的迁移路。对同时使用 Vertex、DashScope、Anthropic direct API 或其他 provider host 的团队来说，Public Preview 里有一条硬边界，最好在方案评审时就讲清楚。

Google Cloud API Gateway model routing 把路由写进 OpenAPI

这次预览允许 operator 在 OpenAPI 文档里直接定义 model router。一个 router 有 defaultModel 和 rules[] 数组，每个 model 指向一个命名 backend。Google 给出的例子里，claude-opus-4-7 这样的虚拟模型名，会映射到 Vertex AI backend path，比如 aiplatform.googleapis.com 下面的 Anthropic publisher endpoint。

这会改变应用团队和平台团队的分工。过去，client 往往为每个模型硬编码一条完整的 Vertex AI 路径，比如 https://aiplatform.googleapis.com/v1/projects/...。迁移以后，团队可以暴露一个稳定 endpoint，比如 /v1/chat/gemini-claude，让 client 继续发送熟悉的 OpenAI-style body，里面带 "model": "claude-opus-4-7"，backend path 的映射则留在 API spec 里。

Google 也把 client auth 留在 Gateway 边界。client 认证的是 API Gateway，不是各个 model provider。rate limiting 和 token tracking 也在这个托管层处理。团队如果想少维护一层 proxy 进程，少管扩容、补丁和观测，这个方案会很有吸引力。

Google Cloud API Gateway model routing 有共享主机边界

operator 最该记住的是这个限制。Google 说明，单个 router 引用的所有 backends 必须共享同一个 host，例如 aiplatform.googleapis.com。路由只是选择这个共享 Agent Platform host 上的不同 model 和 path。它不会跨不同 host 做路由。

实际后果很直接。你不能在一个 Google API Gateway router 里同时放 Vertex-hosted Gemini backend、Anthropic direct API 和 DashScope。如果团队确实需要这种 provider 组合，就要拆成多个 gateways，或者在 Google API Gateway 前面放一个 code-level proxy，由那一层先做跨 host 决策。

这个问题在配置里有一个很具体的位置，code review 时可以直接查 x-google-api-management.ai.models.routing.routers.<name>.defaultModel.backend。如果这个 backend 所属 router 里的其他 models 不共享同一个 host，这个设计就已经超出了当前预览的形状。

规格优先路由和代码级 proxy 路由

Google 这次的做法，是 spec-first AI gateway design 的一个很明确例子。routing policy 和 HTTP contract 放在一起。平台团队可以像审 API 配置一样审它，继续使用 API Gateway 的控制面，也不必再运行一个开源 proxy 层。

这和 LiteLLM 或自建 TheRouter-style gateway 这类 code-level router 的取舍不一样。code-level routing 可以跨 provider host 做决策，可以同时组合 Vertex 和 direct APIs，也可以加入自定义 fallback 逻辑，并处理不同 provider 的响应差异。代价是团队要自己负责服务、部署、rate-limit 行为和故障模式。

Azure API Management 的 Unified Model API 更接近 Google 这种 spec-first 路线，但它的 cross-provider 叙事更宽。Google 这次预览更有立场。只要你的后端世界已经在 Vertex AI 里，就能拿到 managed、serverless 的 router。

这个立场本身有用。它减少了运维面。它也让架构的可迁移性变弱。该怎么选，取决于你的路由问题主要是 Vertex 内部的模型选择，还是跨云和跨厂商的 provider 选择。

TheRouter operator 现在该调整什么

如果你的团队已经通过 Vertex AI 转发模型调用，这次预览值得放到非关键 route 后面试一下。先从一个低风险 chat endpoint 开始，映射两个 Vertex-hosted models，然后观察 token tracking、latency 和 error reporting 跟现有 gateway 有什么差别。宽入口的 TheRouter documentation 可以当作检查清单，用来重新确认 provider identity、model names 和 client compatibility，再动生产流量。

如果你的架构横跨多个 provider hosts，就把 Google 的共享主机限制当成设计输入，不要当成脚注。cross-provider policy 要留在能看得到每个 provider 的 router layer。API Gateway 可以做 Vertex-hosted traffic 的 managed edge，也可以是更大 routing system 里的一个 hop。

最接近的迁移模式很简单。

• 把 client 从硬编码 Vertex model URLs 迁到一个稳定 Gateway path。
• 在 client payload 里保持 virtual model names 稳定。
• 把 Vertex backend paths 放进 OpenAPI spec，不要放在应用代码里。
• 在 Google 扩展 host model 以前，把跨 host 路由留在这次预览之外。

最后一点最能说明这条新闻的分量。Google Cloud API Gateway model routing 是一个有用的 managed primitive，但它不能承担通用 multi-provider router 的全部职责。它适合把 Vertex AI 内部的模型选择收敛到一个稳定入口，也适合让 API 团队用熟悉的 OpenAPI review 流程管理模型映射。它不适合替代一个跨 provider hosts 的 router。对最近跟进过 Google 更大范围 Vertex AI Agent Platform migration 的团队来说，它延续的是同一个方向。把更多 agent 和 model traffic 放进 Google managed infrastructure，然后再认真决定哪些 open routing 仍然应该留在外面。这个判断会影响故障演练、账单归因和 provider 退出策略。否则应用层会把统一入口看得过宽，平台层到故障演练时才发现，跨 host fallback 没有被这个 managed router 覆盖，线上切换时会留下空档。