企业和个人开发者经常同时运行多个 AI 推理模型。Google Cloud 这篇博客介绍了两套参考架构：一套面向 GKE 后端，一套面向所有其它后端，目标是让模型调用方式更简单，同时提供集中式治理。

两套设计都以一个稳定、安全、可靠的入口作为推理调用的前端和控制区。Cloud Load Balancer 和 Inference Gateway 都提供入口能力，可以终止 TLS、集成 API 管理组件、通过 Service Extensions 扩展功能，并能配合 Model Armor 增强安全性。共同服务包括：Private Service Connect 推理端点把入口锚定在消费 VPC 内部，流量命中私有内部 IP，推理调用始终留在私有网络；Apigee API Management（可选）通过 Apigee Extension Processor 做客户端身份验证、限流和配额执行；Model Armor 作为内联 AI 安全检查点，对提示词和输出做 prompt injection 与敏感数据泄漏筛查。

GKE-only 设计在共同服务之外，额外使用三个组件。GKE Inference Gateway 部署为内部 Application Load Balancer（gke-l7-rilb），作为专用入口引擎，解析请求 payload、评估 HTTPRoute 规则，把查询引导到对应模型服务目标。推理池是同一模型的副本逻辑分组，初始大小可配置，并支持动态自动扩缩。模型副本集则是跨单节点或多节点 GPU/TPU 节点池部署的推理服务器实例，代表一组同质副本。

GKE 流量流程如下：客户端在消费 VPC 内发出 OpenAI 兼容 API 调用到本地 Private Service Connect 端点，经区域内部 Application Load Balancer 路由到 GKE Inference Gateway。Gateway 读取请求体中的目标模型参数，写入 HTTP 头。如果使用了 Apigee，则先校验客户端凭据和配额；Model Armor 再对提示词做策略违规和数据泄漏检查。之后 Gateway 评估 HTTPRoute 映射识别目标推理池，匹配共享前缀缓存上下文，并根据实时 Prometheus 数据路由到负载最低的 GPU 或 TPU 副本。副本运行推理后，输出 token 经 Model Armor 验证，再通过私有连接流式返回。

面向 GKE、Cloud Run、Agent Platform、本地数据中心或外部云等混合后端，则使用另一套组件。区域内部 Application Load Balancer 作为中心 L7 路由代理，负责路由逻辑、SSL 终止和 Service Extensions 调用。Inference Payload Processor（Service Extensions）实现与 GKE Inference Gateway 类似的基于 body 的路由：在 ALB 上通过一个轻量 Cloud Run callout 检查 OpenAI API 请求的 JSON body，提取目标模型 ID，写入 X-Gateway-Model-Name 头来驱动 URL map 路由。Network Endpoint Group（NEG） 则根据注入的模型头，把流量灵活分发到异构后端。

全后端流量流程：客户端通过私有 IP 空间访问 Private Service Connect 端点，区域内部 Application Load Balancer 接收到请求后，先把 payload 发给 Cloud Run body-based router callout，解析 JSON 并注入 X-Gateway-Model-Name 头。随后请求经过 Apigee 的身份和配额校验，再到 Model Armor 清洗敏感数据、拦截恶意提示词。负载均衡器的 URL map 检查模型头，将请求转发到匹配的后端 NEG（Agent Platform、GKE、Cloud Run、Hybrid 或 Internet）。目标后端执行模型推理，Model Armor 检查生成内容，结果沿入口路径私有返回。

这篇博客是两份完整架构文档的概览：GKE 版对应《Networking for AI inference model serving on GKE》，混合后端版对应《Networking for AI inference model serving on all backends》，端到端细节需要阅读原文文档。