本文档提供了一种参考架构，用于使用 Google Kubernetes Engine (GKE) 创建多模型推理服务。在该架构中，GKE 托管的推理池位于 GKE 推理网关后面。此架构具有以下优势：
- 用于处理所有推理请求的统一界面。
- 将每个请求智能路由到能够以最高效方式处理该请求的模型和推理服务器。
- 集中式授权、安全和其他服务。
本文档面向负责统一部署在 GKE 中运行的推理服务器的网络架构师。如果您的所有推理服务器并非都托管在 GKE 中，请参阅在所有后端上为 AI 推理模型提供服务的网络。本文档不提供有关如何设计应用或部署单个生成式 AI 模型的指南。如需有关如何部署模型的指南，请参阅在企业中构建和部署生成式 AI 模型和机器学习模型。
此架构适用于应用网络架构适用于分布式应用的跨云网络 和其他设计。
架构
下图展示了一种架构，其中包含位于 GKE 托管的推理服务器前面的推理网关。该网关可为所有托管的模型提供整合的服务。
图中显示的架构包括以下组件：
- Private Service Connect 推理端点：适用于所有托管模型的统一端点。最终用户向端点 IP 地址发送推理请求。该图显示了单个使用方虚拟私有云 (VPC) 网络中的 Private Service Connect 端点。您可以在多个 VPC 网络或共享服务 VPC 网络中托管端点。
- 推理网关：推理网关增强了 GKE 网关，可优化 GKE 提供生成式 AI 应用和工作负载的方式。它会根据模型名称将流量路由到模型副本的推理池。网关使用前缀匹配来路由复制池内的流量。如果没有前缀匹配项，网关推理处理器会使用 GPU 或 TPU Prometheus 指标来选择池中负载最低的副本。
推理处理器还负责处理前缀缓存。在此架构中，面向客户的应用通过网关调用 OpenAI API 来访问模型。网关是基于区域级内部应用负载平衡器 (
gke-l7-rilb) 部署的，因此无法直接从互联网访问。- API 管理：API 管理器提供 API 身份验证、安全性、速率限制、配额跟踪和其他 API 管理服务。此架构使用 Apigee，但该架构支持其他选项。为了从负载均衡器调用 Apigee，该架构和 Terraform 部署使用Service Extensions 流量扩展来调用 Apigee Extension Processor。
- Model Armor：一种 AI 护栏系统，可在推理提示到达推理服务器之前对其执行安全检查。然后，它会对传出的回答执行安全检查。此架构使用 Model Armor 作为 AI 护栏，但它也支持其他选项，例如 NVIDIA Nemo Guardrails。此参考架构随附的 Terraform 部署包含基本的 Model Armor 配置。
- 推理池：推理池包含同一模型的多个副本。当网关收到提示时，它会使用
HTTPRoute查找功能，根据模型标识符选择推理池。池具有初始大小，但可以配置为自动扩缩。 - 模型副本集：模型副本是部署到一台或多台 GPU 或 TPU 的推理服务器副本。模型副本可以是单节点或多节点。副本集是由负载均衡器作为前端的统一模型副本组。如果副本集是多节点的，则 GPU 通过后端 RDMA VPC 网络相互连接。该网络提供与轨道对齐的 GPU 间无损低延迟网络。
请求流程
系统按如下方式路由推理请求：
- 最终用户向 Private Service Connect 端点发送 OpenAI API 请求。此请求包含以下内容：
- 提示。
- 模型名称，必须与某个托管推理服务器的模型名称一致。
- Private Service Connect 端点将请求转发到推理网关的区域性内部应用负载平衡器版本。
- 网关使用基于正文的路由从请求正文中提取模型名称，并将其注入到请求标头中。
- 网关将请求转发到 API 管理系统，以获取所需的 API 管理服务。
- 网关将提示发送到 Model Armor 以进行过滤。
- 如果提示包含无法隐去的敏感信息，系统会屏蔽该提示，并且 Model Armor 会返回一条表明发现违规行为的回答。
- 如果提示包含可进行遮盖的敏感信息，或者提示完全没有问题，Model Armor 会遮盖所有敏感信息，然后转发提示。
- 网关会查询
HTTPRoute，以获取与请求的模型匹配的推理池列表。网关会根据优先级从该列表中选择一个。 - 网关会查询前缀缓存和池中所有副本的当前负载，然后使用这些信息来选择副本。
- 副本处理请求并将其发送回网关。
- 网关将响应发送给 Model Armor 以供审批或拒绝。
- 网关将响应发送回 Private Service Connect 端点，然后发送给最终用户。
下图显示了一个示例部署的路由视图。
在此示例中，系统会根据用户选择的模型来处理提示：
- Llama：系统会在两个都托管 Llama 模型的副本集之间以 90/10 的比例对这些提示进行负载均衡。这两个副本集不必以相同的方式托管。例如，一个副本集可以托管在 Gemini Enterprise Agent Platform 中，另一个副本集可以托管在 GKE 中。
- LoRA-1-gemma 或 LoRA-2-gemma：系统会将所有提示发送到同一组副本，该组副本可以处理这两个模型。
在所有情况下，网关都会结合使用前缀匹配和最小负载来选择相关池中的副本。
使用的产品
此参考架构使用以下 Google Cloud产品：
- Google Kubernetes Engine (GKE)：一种 Kubernetes 服务，可用于使用 Google 的基础架构来大规模部署和操作容器化应用。
- GKE Inference Gateway：Google Kubernetes Engine 网关的扩展程序，可提供优化路由和负载均衡来处理生成式 AI 工作负载。它简化了 AI 推理工作负载的部署、管理和可观测性。
- 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 管理，该架构通过负载均衡器服务扩展程序进行部署。如果 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 地址检查，请向前端区域级内部应用负载平衡器添加 Google Cloud Armor。
可靠性
为了防止发生区域级故障，请使用Google Cloud 多区域部署原型将部署复制到第二个区域。
费用优化
如需获取 GKE 费用优化建议，请参阅在 GKE 上运行费用经过优化的 Kubernetes 应用的最佳实践。
运营效率
使用推理网关信息中心监控推理网关推理请求的性能。该信息中心会显示错误以及请求速率、延迟时间和饱和度等指标。利用信息中心内的发现结果，有助于优化部署。
性能优化
遵循 GKE 上的推理最佳实践概览中的建议。
部署
如需部署此架构的示例实现，请使用 GitHub 中提供的 AI 推理模型服务的网络代码示例。
后续步骤
- 如需了解如何向部署添加检索增强生成 (RAG)，请参阅支持 RAG 的生成式 AI 应用的专用连接。
- 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。
贡献者
作者：Victor Moreno | Cloud 网络产品经理
其他贡献者：
- Mark Schlagenhauf | 网络技术文档工程师
- James Duncan | 解决方案产品经理
- Ammett Williams | 开发者关系工程师