在所有后端上部署 AI 推理模型的网络方案

Last reviewed 2026-11-12 UTC

本文档提供了一个参考架构，用于为本地或任何提供商（包括第三方和 Google Cloud）托管的多个 AI 模型创建统一的前端。如果您的所有推理服务器都托管在 Google Kubernetes Engine (GKE) 中，请参阅在 GKE 上提供 AI 推理模型的网络。

此架构旨在让开发者能够选择模型，而无需为每个模型指定单独的 IP 地址。而是向前端端点发送包含模型名称的 OpenAI API 请求。架构中的系统会将请求路由到托管指定模型的后端。该架构中的前端负载均衡器提供以下集中式管理功能：

  • 无论您如何托管模型，所有模型调用都使用单个前端端点。
  • API 管理功能。
  • AI 保护措施的检查点。
  • Service Extensions 插入点，用于未来扩展。

本文档适用于希望将新的或现有的生成式 AI 模型置于单个推理端点后面的网络管理员和生成式 AI 应用管理员。本文档未提供有关如何设计应用或部署单个生成式 AI 模型的指导。如需了解如何部署模型，请参阅在企业中构建和部署生成式 AI 和机器学习模型。此架构可与应用网络架构（例如适用于分布式应用的跨云网络）以及其他设计搭配使用。

架构

下图展示了一个架构，其中消费者网络中的端点指向区域级内部应用负载均衡器前端。此负载均衡器使用指定模型的名称，将请求路由到托管在本地或由任何提供商托管的模型副本集。前端负载均衡器为所有托管模型提供整合服务。

简要介绍 AI 推理的网络。

图中显示的架构包括以下组件：

  • Private Service Connect 推理端点：适用于所有托管模型的统一端点。最终用户向端点 IP 地址发送推理请求。该图显示了单个使用方 Virtual Private Cloud (VPC) 网络中的 Private Service Connect 端点。您可以在多个 VPC 网络或共享服务 VPC 网络中托管端点。
  • 区域级内部应用负载均衡器：在此架构中，前端负载均衡器是区域级内部应用负载均衡器。前端负载均衡器会根据请求中指定的模型名称，将流量路由到副本池。在此架构中，客户应用会向负载均衡器发出 OpenAI API 调用。如果后端推理服务器与 OpenAI API 兼容，则一切都会透明地运行。如果推理服务器与 OpenAI API 不兼容，则您必须使用服务扩展实现 API 转换器。此参考架构不包含 API 转换器的实现。
  • Service Extensions 标注：您可以使用标注向应用负载均衡器添加额外的处理。此设计中的架构使用以下标注：
    • 推理载荷处理器（之前称为基于正文的路由器）：推理载荷处理器部署在 Cloud Run 中。它会从 OpenAI API 请求的正文中读取模型名称，并将其写入标头中的 X-Gateway-Model-Name 字段。负载均衡器网址映射使用该字段将请求转发到相应的后端服务。此参考架构提供的 Terraform 部署包含推理载荷处理器配置。
    • Apigee：一种 API 管理器，可提供 API 身份验证、安全性、速率限制、配额跟踪和其他 API 管理服务。此架构使用 Apigee，但该架构支持其他选项。为了从负载均衡器调用 Apigee，该架构和 Terraform 部署使用服务扩展程序流量扩展程序来调用 Apigee Extension Processor。
    • Model Armor：一种 AI 保护措施系统，可在推理提示到达推理服务器之前对其执行安全检查。然后，它会对输出的回答执行安全检查。 此架构使用 Model Armor 作为 AI 护栏，但也支持其他选项，例如 NVIDIA NeMo Guardrails。此参考架构提供的 Terraform 部署包含基本的 Model Armor 配置。
  • 后端服务：负载均衡器会根据请求中的模型名称，将请求路由到后端服务。后端服务包含网络端点组 (NEG)。
  • 模型副本集：模型副本是部署到一个或多个 GPU 或 TPU 的推理服务器的副本。模型副本可以是单节点或多节点。副本集是一组统一的模型副本，由负载均衡器作为前端。在该架构中，模型副本包含在 GKE Inference Gateway 后面的 GKE 集群中、Gemini Enterprise Agent Platform 中、Cloud Run 中、本地或其他云数据中心内，以及互联网上的端点后面。

模型副本集配置

在此架构中，前端负载均衡器会根据模型名称将流量定向到特定后端服务。指定模型的推理服务器可以托管在下表中所述的其中一种配置中。

副本集类型 说明 副本负载均衡
Agent Platform 模型副本在 Agent Platform 中运行。您将 Agent Platform 端点发布为 Private Service Connect 网络端点组 (NEG)。前端负载均衡器使用 Private Service Connect NEG 作为每个不同模型的后端，每个模型都结构化为后端服务。 Agent Platform 会在内部进行扩缩和负载均衡。 Agent Platform 执行基于指标的加权负载均衡和基于前缀缓存的路由，从而优化资源利用率并加快推理速度。如需了解详情，请参阅将模型部署到端点。
GKE 推理服务器作为 Pod 在 GKE 副本集 VPC 网络中的 GKE 集群中运行。GKE 中的多个模型副本共同构成推理网关背后的单个后端。推理网关会发布一个 Private Service Connect 端点，前端负载均衡器会使用 Private Service Connect NEG 访问该端点。 推理网关为 GKE 集群中的推理后端提供模型感知负载均衡。推理网关会在适用时使用前缀缓存感知路由。否则，推理网关会根据请求队列长度、键值对 (KV) 缓存利用率以及 GPU 或 TPU 利用率来分配请求。此配置支持 Pod 横向自动扩缩。
Cloud Run 推理服务器在 Cloud Run 中运行。 Cloud Run 会发布一个端点，前端负载均衡器会使用无服务器 NEG 访问该端点。 Cloud Run 会根据流量自动扩缩副本数量。仅限于单节点副本。
混合 推理服务器在本地或其他云端运行。您在路由 VPC 网络中配置区域级内部代理网络负载均衡器。此负载均衡器会发布一个 Private Service Connect 端点，前端负载均衡器会使用 Private Service Connect NEG 访问该端点。路由 VPC 网络中的内部负载均衡器又具有一个混合 NEG 后端，该后端指向本地推理服务器前面的本地或其他云负载均衡器的 IP 地址。 外部负载均衡器的负载均衡机制由外部设施的管理员配置。
互联网 可从公共互联网 IP 地址访问的推理服务器。 前端负载均衡器具有一个互联网 NEG 后端，该后端指向托管在互联网上的模型的 IP 地址。 由代管式服务提供商负责伸缩。

请求流程

系统会按如下方式路由推理请求：

  1. 最终用户向 Private Service Connect 端点发送 OpenAI API 请求。此请求包含以下内容：
    • 提示。
    • 模型名称，必须与其中一个托管推理服务器的模型名称匹配。
  2. Private Service Connect 端点会将请求转发到前端内部应用负载均衡器。
  3. 负载均衡器会将请求转发到 Service Extensions。
  4. Service Extensions 推理载荷处理器代码会从请求正文中读取模型名称，并将其写入 X-Gateway-Model-Name 标头。
  5. 负载均衡器使用 Service Extensions 流量扩展标注，将请求发送到 API 管理系统，以获取所需的任何 API 管理服务。
  6. 负载均衡器使用 Service Extensions 流量扩展程序标注将提示发送到 Model Armor 进行筛查。
    • 如果提示包含无法隐去的敏感信息，系统会屏蔽该提示，并且 Model Armor 会返回一条回答，指明发现了违规行为。
    • 如果提示包含可隐去敏感信息，或者提示没有任何问题，Model Armor 会隐去所有敏感信息并转发提示。
  7. 如果 Model Armor 允许该请求，负载均衡器会查阅网址映射，并根据模型名称自定义标头将请求转发到后端服务。如有必要，网址映射会重写请求的网址和路径，以匹配后端所需的内容。
  8. 后端服务会将请求转发到其关联的副本集负载均衡器。
  9. 特定推理服务的负载均衡器会将请求分配给其副本之一。
  10. 副本处理请求并发送回响应。
  11. 前端区域级内部应用负载均衡器会将响应发送到 Model Armor 进行筛查。
  12. 应用负载均衡器将响应发送回 Private Service Connect 端点，然后发送给最终用户。

下图显示了示例部署的路由视图：

提示流向示例副本集。

在此示例中，系统会根据用户选择的模型来处理提示：

  • Gemma：所有提示都会路由到托管 Gemma 模型的副本集。
  • Llama：系统会在两个都托管 Llama 模型的副本集之间平均分配这些提示。这两个副本集不必以相同的方式托管。例如，一个副本集可以托管在 Agent Platform 中，另一个副本集可以托管在 GKE 中。
  • LoRA-1-gemma 或 LoRA-2-gemma：系统会将所有提示发送到同一个副本集，该副本集可以处理这两个模型。

使用的产品

本文档中的参考架构使用以下 Google Cloud 产品：

  • Cloud Load Balancing：一组高性能、可扩缩的全球和区域级负载均衡器。
  • Virtual Private Cloud (VPC)：为您的 Google Cloud 工作负载提供全球可扩缩的网络功能的虚拟系统。VPC 包括 VPC 网络对等互连、Private Service Connect、专用服务访问通道和共享 VPC。
  • Private Service Connect：一项功能，可让使用方从其 VPC 网络内部以私密方式访问托管式服务。
  • Cloud Run：一个无服务器计算平台，可让您直接在 Google 可伸缩的基础设施之上运行容器。
  • Apigee：一种 API 管理工具，可让您精细控制 API 的访问和使用方式。它提供安全性、速率限制、配额强制执行和分析功能。
  • Model Armor：一项服务，可保护您的生成式 AI 和智能体 AI 资源免受提示词注入、敏感数据泄露和有害内容的侵害。

设计替代方案

本部分介绍了此架构的一些基本假设的替代方案。

AI 保护措施

我们建议您使用 Model Armor 作为 AI 护栏。为了集中管理，我们建议您直接从负载均衡器调用它，如本架构中所示。您还可以通过以下替代方式实现 Model Armor：

  • 使用 API 管理政策调用 Model Armor。
  • 仅在副本上部署 Model Armor。

如果您在模型端点以外的位置实施 AI 护栏，则可以在前端负载均衡器上关闭 Model Armor（如果您不需要它）。如果您不想使用 Model Armor，可以使用流量扩展程序部署其他护栏产品，例如 NVIDIA NeMo Guardrails。

API 管理

本文档中的架构使用 Apigee 进行 API 管理，该管理使用 Service Extensions 进行部署。如果 Apigee 无法满足您的需求，您可以使用 Service Extensions 部署其他 API 管理服务。

如果使用 Service Extensions 部署 API 管理无法满足您的需求，您可能需要部署面向客户端的网络和面向 API 的网络。在此场景中，API 管理服务充当两个网络之间的桥梁。如需了解如何为 Apigee 部署此功能，请参阅 Apigee 网络选项。

连接到其他网络

本文档中的架构使用单个使用方 VPC 网络。不过，您可以在跨云网络部署中使用服务访问通道 VPC 网络，与许多其他网络共享 Private Service Connect 端点。

设计考虑事项

本部分介绍了符合 Google Cloud Well-Architected Framework 的设计因素、最佳实践和建议。您在使用此参考架构开发满足特定安全性、可靠性、费用优化、运营效率和性能要求的拓扑时，请考虑这些信息。

安全性、隐私权和合规性

基准架构将推理流量隔离在 Private Service Connect 端点后，使用 Apigee 强制执行 API 政策，并使用 Model Armor 筛查提示。如需进一步强化多后端推理拓扑并满足隐私权和合规性要求，请考虑以下建议：

  • 边缘和应用层保护：如需添加分布式拒绝服务攻击 (DDoS 攻击) 防护、Web 应用防火墙 (WAF) 规则和 IP 地址检查，请将 Google Cloud Armor 安全政策附加到前端区域级内部应用负载均衡器。
  • 零信任访问权限和边界控制：
  • 后端身份和身份验证：将流量从 Web 应用路由到 Agent Platform 模型时，您必须选择一个身份模型进行身份验证：
    • 服务账号身份（推荐用于常规 Web 应用）：应用通过 IAP 对最终用户进行身份验证。然后，它会使用 Workload Identity（例如 Cloud Run、GKE 或第三方身份）调用 Agent Platform。此实现方式对最终用户隐藏了 Identity and Access Management (IAM)，但需要应用级日志记录来跟踪每个提示是由哪个用户生成的。
    • 最终用户身份传递（建议用于严格的可审核性）：应用会捕获最终用户的 Google OAuth 访问令牌，并将其直接传递给 Agent Platform（在 Authorization: Bearer 标头中）。此实现提供了内置的 Cloud Audit Logs 用户操作日志记录。不过，必须为每个最终用户预配 IAM 权限（例如 roles/aiplatform.user）。
  • 量身定制的提示和回答模板：如需检测和隐去提示和回答中的自定义敏感数据类型，请在 Model Armor 中配置高级 Sensitive Data Protection 模板。由于 Model Armor 负载均衡器标注会忽略流式 OpenAI API 响应，因此在流式传输 token 时，请在应用或后端中强制执行响应筛选。
  • 代理身份和治理：
    • 如果自主 AI 智能体或 Model Context Protocol (MCP) 工具发送或接收推理流量，请使用 Agent Gateway 治理这些交互。
    • 如需为代理分配加密 SPIFFE 身份和绑定凭据，请使用 Agent Identity。

可靠性

基准架构在区域级、混合和外部模型副本集前面部署区域级内部应用负载均衡器和 Service Extensions 标注。为了在流量高峰、出价邀约冷启动和区域或混合连接性服务中断期间提高可用性，请考虑以下建议：

费用优化

在多后端推理费用中，通常占比最大的是 token 消耗、加速器容量和跨区域数据传输。如需控制 token 使用量、减少冗余模型调用并优化计算和网络支出，请考虑以下建议：

  • Token 配额和限制：如需控制每个使用方或应用的基于 token 的推理支出，请在 Apigee API 代理中强制执行 LLMTokenQuota 和 PromptTokenLimit 政策。
  • 语义和上下文缓存：
  • 区域级共置：为避免产生跨区域数据传输费用，请将前端区域级内部应用负载均衡器、Apigee 运行时、Model Armor 模板和 Google Cloud 副本集共置在同一区域。
  • 加速器利用率：如需提高加速器利用率，请在 GKE 上使用动态工作负载调度器，或在 Agent Platform 上使用模型共存。

运营效率

运营多后端推理平台需要了解负载均衡器路由、Service Extensions 标注、后端模型指标和混合网络路径。为了简化推理后端的第 2 天监控、问题排查和模型发现，请考虑以下建议：

性能优化

推理延迟时间和吞吐量取决于每个后端如何加载模型权重、扩缩实例以及跨副本调度请求。为了减少冷启动延迟、缩短首 token 延迟 (TTFT) 并提高服务吞吐量，请考虑以下建议：

部署

如需部署此架构的示例实现，请使用 GitHub 中提供的用于 AI 推理模型部署的网络代码示例。

如需了解如何部署 AI 模型，请参阅以下资源：

后续步骤

贡献者

作者：Victor Moreno | Cloud 网络产品经理

其他贡献者：