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

Last reviewed 2026-05-20 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 后面的 Google Kubernetes Engine (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 集群中的推理后端提供模型感知负载均衡。推理网关会在适用时使用前缀匹配。如果没有前缀匹配,推理网关会根据 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 Extension 进行部署。如果 Apigee 无法满足您的需求,您可以使用 Service Extensions 部署其他 API 管理服务。

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

连接到其他网络

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

设计考虑事项

为工作负载构建架构时,请考虑 Google Cloud Well-Architected Framework 中的最佳实践和建议。

安全性、隐私权和合规性

  • 如需向部署添加分布式拒绝服务攻击 (DDoS 攻击) 防护、Web 应用防火墙 (WAF) 功能和 IP 地址检查,请将 Cloud Armor 添加到前端区域级内部应用负载均衡器。
  • 如需向所有后端添加通用身份验证层,请实现 Identity-Aware Proxy (IAP) 以验证身份并强制执行授权政策。
  • 将流量从 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 用户操作日志记录,但要求每个最终用户都预配 Google CloudIAM 权限(例如 roles/aiplatform.user)。

可靠性

为了防范区域级故障,请使用Google Cloud 多区域部署原型将部署复制到第二个区域。

运营效率

  • 如需监控流量,以便快速识别和解决问题,请为区域级内部应用负载均衡器使用 Cloud Logging 日志。
  • 为了便于发现贵组织支持的模型,请实现一个可供查询以返回可用模型的列表。例如,您可以在服务器上创建一个列表,用于响应列出模型 API 调用。

性能优化

部署

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

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

后续步骤

贡献者

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

其他贡献者: