本页面介绍了 Google Kubernetes Engine (GKE) 推理网关，这是 GKE 网关的一项增强功能，用于优化生成式 AI 应用的服务。本页面说明了关键概念、功能以及 GKE 推理网关的运作方式。
本页面适用于以下人员：
- 有兴趣使用 Kubernetes 容器编排功能处理 AI/机器学习工作负载的机器学习 (ML) 工程师、平台管理员和运维人员以及数据和 AI 专家。
- 与 Kubernetes 网络交互的云架构师和网络专家。
在阅读本页面之前，请确保您熟悉以下内容：
- GKE 上的 AI/机器学习编排。
- 生成式 AI 术语表。
- GKE 网络概念，包括 Service 和 GKE Gateway API。
- Google Cloud中的负载均衡，尤其是负载均衡器如何与 GKE 交互。
概览
GKE 推理网关是 GKE 网关的一种扩展程序，可提供优化路由和负载均衡来处理生成式人工智能 (AI) 工作负载。它简化了 AI 推理工作负载的部署、管理和可观测性。
特性和优势
GKE 推理网关提供以下关键功能，可高效地为 GKE 上的生成式 AI 应用部署生成式 AI 模型：
- 用于推理的优化负载均衡：分配请求以优化 AI 模型部署性能。它使用来自模型服务器的指标（例如
KVCache Utilization和queue length of pending requests），以便更高效地使用加速器（例如 GPU 和 TPU）来处理生成式 AI 工作负载。 - 动态 LoRA 微调模型部署：支持在通用加速器上部署动态 LoRA 微调模型。此功能通过在通用基本模型和加速器上对多个 LoRA 微调模型进行多路复用，减少了部署模型所需的 GPU 和 TPU 数量。
- 用于推理的优化自动扩缩：GKE Pod 横向自动扩缩器 (HPA) 使用模型服务器指标进行自动扩缩，这有助于确保高效使用计算资源并优化推理性能。
- 模型感知路由：根据 GKE 集群的
OpenAI API规范中定义的模型名称来路由推理请求。您可以定义网关路由政策（例如流量分配和请求镜像），以管理不同的模型版本并简化模型发布。例如，您可以将针对特定模型名称的请求路由到不同的InferencePool对象，每个对象部署不同版本的模型。 - 特定于模型的部署
Criticality：可让您指定 AI 模型的部署Criticality。优先处理对延迟时间敏感的请求，而非能够容忍延迟时间的批量推理作业。例如在资源受限时，您可以优先处理对延迟时间敏感的应用发出的请求，并舍弃对时间不太敏感的任务。 - 集成式 AI 安全：与 Google CloudModel Armor（这是在网关处对提示和回答应用 AI 安全检查的服务）集成。Model Armor 会提供请求、响应和处理的日志，以进行回顾性分析和优化。GKE 推理网关的开放式接口使第三方提供方和开发者可以将自定义服务集成到推理请求流程中。
- 推理可观测性：提供用于推理请求的可观测性指标，例如请求速率、延迟时间、错误和饱和度。监控推理服务的性能和行为。
了解主要概念
GKE 推理网关增强了使用 GatewayClass 对象的现有 GKE 网关。GKE 推理网关引入了以下新的 Gateway API 自定义资源定义 (CRD)，这些 CRD 与 OSS Kubernetes Gateway API 推理扩展程序保持一致：
InferencePool对象：表示一组共享相同计算配置、加速器类型、基本语言模型和模型服务器的 Pod（容器）。这样可以对 AI 模型部署资源进行逻辑分组和管理。单个InferencePool对象可以跨多个 Pod（位于不同的 GKE 节点上），并提供可伸缩性和高可用性。InferenceModel对象：根据OpenAI API规范，通过InferencePool指定部署模型的名称。InferenceModel对象还指定了模型的部署属性，例如 AI 模型的Criticality。GKE 推理网关会优先处理分类为Critical的工作负载。这使您可以在 GKE 集群上多路复用对延迟时间要求严格和能够容忍延迟时间的 AI 工作负载。您还可以配置InferenceModel对象以部署 LoRA 微调模型。TargetModel对象：指定目标模型名称和部署模型的InferencePool对象。这使您可以定义网关路由政策（例如流量分配和请求镜像），并简化模型版本发布。
下图展示了 GKE 集群中的 GKE 推理网关及其与 AI 安全、可观测性和模型部署的集成。
下图展示了资源模型，该模型侧重于说明两个新的专注于推理的角色及其管理的资源。
GKE 推理网关的运作方式
GKE 推理网关使用 Gateway API 扩展程序和特定于模型的路由逻辑来处理客户端对 AI 模型的请求。以下步骤介绍了请求流程。
请求流程的运作方式
GKE 推理网关将客户端请求从初始请求路由到模型实例。本部分介绍了 GKE 推理网关如何处理请求。此请求流程适用于所有客户端。
- 客户端将请求（采用 OpenAI API 规范中描述的格式）发送到在 GKE 中运行的模型。
- GKE 推理网关使用以下推理扩展程序处理请求：
- 基于正文的路由扩展程序：从客户端请求正文中提取模型标识符，并将其发送到 GKE 推理网关。GKE 推理网关随后会根据 Gateway API
HTTPRoute对象中定义的规则，使用此标识符来路由请求。请求正文路由与基于网址路径的路由类似。不同之处在于请求正文路由使用请求正文中的数据。 - 安全扩展程序：使用 Model Armor 或受支持的第三方解决方案来强制执行特定于模型的安全政策，包括内容过滤、威胁检测、清理和日志记录。安全扩展程序会将这些政策应用于请求和响应处理路径。这使安全扩展程序可以清理和记录请求和响应。
- 端点选择器扩展程序：在
InferencePool中监控来自模型服务器的关键指标。它会跟踪每个模型服务器上的键值对缓存 (KV-cache) 利用率、待处理请求的队列长度和活跃的 LoRA 适配器。然后，它会根据这些指标将请求路由到最佳模型副本，以便针对 AI 推理最大限度地减少延迟时间并最大限度地提高吞吐量。
- 基于正文的路由扩展程序：从客户端请求正文中提取模型标识符，并将其发送到 GKE 推理网关。GKE 推理网关随后会根据 Gateway API
- GKE 推理网关会将请求路由到端点选择器扩展程序返回的模型副本。
下图展示了通过 GKE 推理网关从客户端到模型实例的请求流程。
流量分配的运作方式
GKE 推理网关会将推理请求动态分配给 InferencePool 对象中的模型服务器。这有助于优化资源利用率，并在不同的负载条件下保持性能。GKE 推理网关使用以下两种机制来管理流量分配：
端点选择：动态选择最合适的模型服务器来处理推理请求。它会监控服务器负载和可用性，然后做出路由决策。
排队和卸除：管理请求流程并防止流量过载。GKE 推理网关会将传入的请求存储在队列中，根据定义的标准确定请求优先级，并在系统过载时舍弃请求。
GKE 推理网关支持以下 Criticality 级别：
Critical：这些工作负载会优先进行处理。即使在资源受限的情况下，系统也会确保处理这些请求。Standard：这些工作负载会在资源可用时进行处理。如果资源有限，这些请求会被舍弃。Sheddable：这些工作负载会伺机进行处理。如果资源不足，这些请求会被舍弃，以保护Critical工作负载。
当系统面临资源压力时，系统会立即舍弃 Standard 和 Sheddable 请求，并返回 429 错误代码，以保护 Critical 工作负载。
流式推理
对于需要持续更新或近乎实时的更新的应用（例如聊天机器人和实时翻译），GKE 推理网关支持流式推理。流式推理以增量块或分段的形式提供回答，而不是以单个完整输出的形式提供。如果在流式回答期间发生错误，则流会终止，并且客户端会收到错误消息。GKE 推理网关不会重试流式回答。
探索应用示例
本部分提供了一些示例，展示了如何使用 GKE 推理网关来应对各种生成式 AI 应用场景。
示例 1：在 GKE 集群上部署多个生成式 AI 模型
一家公司希望部署多个大型语言模型 (LLM) 来处理不同的工作负载。例如，他们可能希望部署 Gemma3 模型以用于聊天机器人界面，并部署 Deepseek 模型以用于推荐应用。该公司需要确保为这些 LLM 实现最佳部署性能。
借助 GKE 推理网关，您可以采用 InferencePool 在 GKE 集群中部署这些 LLM，并使用所选的加速器配置。您随后可以根据模型名称（例如 chatbot 和 recommender）以及 Criticality 属性来路由请求。
下图展示了 GKE 推理网关如何根据模型名称和 Criticality 将请求路由到不同的模型。
示例 2：在共享加速器上部署 LoRA 适配器
一家公司希望部署 LLM 来进行文档分析，并专注于多种语言（例如英语和西班牙语）的受众群体。他们针对每种语言对模型进行了微调，但需要高效地使用 GPU 和 TPU 容量。您可以使用 GKE 推理网关在通用基本模型（例如 llm-base）和加速器上为每种语言部署动态 LoRA 微调适配器（例如 english-bot 和 spanish-bot）。这样，您便可以通过在通用加速器上密集封装多个模型来减少所需的加速器数量。
下图展示了 GKE 推理网关如何在共享加速器上部署多个 LoRA 适配器。
