GKE 推理网关简介

本页介绍了 Google Kubernetes Engine (GKE) 推理网关，它是 GKE 网关的增强功能，可优化生成式 AI 应用的服务。其中介绍了关键概念、功能以及 GKE 推理网关的运作方式。

本页面适用于以下角色：

  • 机器学习 (ML) 工程师、平台管理员和运维人员，以及对使用 Kubernetes 容器编排功能处理 AI/机器学习工作负载感兴趣的数据和 AI 专家。
  • 与 Kubernetes 网络交互的云架构师和网络专家。

在阅读本页面之前，请确保您熟悉以下内容：

概览

GKE 推理网关是 GKE 网关的扩展，可为生成式 AI (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 Cloud Model Armor 集成，该服务会对网关中的提示和回答应用 AI 安全检查。模型装甲提供请求、响应和处理日志，以便进行回溯分析和优化。借助 GKE 推理网关的开放式接口，第三方提供商和开发者可以将自定义服务集成到推理请求流程中。
  • 推理可观测性：为推理请求提供可观测性指标，例如请求速率、延迟时间、错误和饱和度。监控推理服务的性能和行为。

了解主要概念

GKE 推理网关增强了使用 GatewayClass 对象的现有 GKE Gateway。GKE 推理网关引入了以下新的 Gateway API 自定义资源定义 (CRD)，与适用于推理的 OSS Kubernetes Gateway API 扩展保持一致：

  • InferencePool 对象：表示一组共享相同计算配置、加速器类型、基础语言模型和模型服务器的 Pod（容器）。这样可以逻辑地对 AI 模型服务资源进行分组和管理。单个 InferencePool 对象可以跨不同 GKE 节点的多个 Pod 进行扩展，并提供可伸缩性和高可用性。
  • InferenceModel 对象：根据 OpenAI API 规范，从 InferencePool 指定投放模型的名称。InferenceModel 对象还会指定模型的服务属性，例如 AI 模型的 Criticality。GKE 推理网关会优先处理被归类为 Critical 的工作负载。这样，您就可以在 GKE 集群上对低延迟至关重要和对延迟容忍的 AI 工作负载进行多路复用。您还可以配置 InferenceModel 对象以提供经过 LoRA 微调的模型。
  • TargetModel 对象：指定目标模型名称和用于提供模型的 InferencePool 对象。这样，您就可以定义网关路由政策（例如流量拆分和请求镜像），并简化模型版本的发布。

下图展示了 GKE 推理网关及其与 GKE 集群中的 AI 安全性、可观测性和模型服务的集成。

GKE 推理网关 `InferencePool` 和 `InferenceModel` 对象之间的关系
图： GKE 推理网关资源模型

下图展示了资源模型，该模型侧重于两个新的侧重于推理的角色及其管理的资源。

侧重于推理的角色及其资源的资源模型
图： GKE 推理网关资源模型

GKE 推理网关的工作原理

GKE 推理网关使用 Gateway API 扩展和特定于模型的路由逻辑来处理对 AI 模型的客户端请求。以下步骤介绍了请求流程。

请求流程的运作方式

GKE 推理网关会将客户端请求从初始请求路由到模型实例。本部分介绍了 GKE 推理网关如何处理请求。此请求流程适用于所有客户端。

  1. 客户端向在 GKE 中运行的模型发送请求，请求的格式如 OpenAI API 规范中所述。
  2. GKE 推理网关使用以下推理扩展程序处理请求：
    1. 基于正文的路由扩展：从客户端请求正文中提取模型标识符，并将其发送到 GKE 推理网关。然后，GKE 推理网关会使用此标识符根据 Gateway API HTTPRoute 对象中定义的规则路由请求。请求正文路由与基于网址路径的路由类似。区别在于，请求正文路由使用请求正文中的数据。
    2. 安全扩展：使用 Model Armor 或受支持的第三方解决方案来强制执行特定于模型的安全政策，包括内容过滤、威胁检测、净化和日志记录。安全扩展程序会将这些政策应用于请求和响应处理路径。这样，安全扩展程序就可以对请求和响应进行清理和记录。
    3. 端点选择器扩展程序：监控 InferencePool 中模型服务器的主要指标。它会跟踪每个模型服务器上的键值对缓存 (KV-cache) 利用率、待处理请求的队列长度和活跃 LoRA 适配器。然后，它会根据这些指标将请求路由到最佳模型副本，以尽可能缩短 AI 推理延迟时间并最大限度提高吞吐量。
  3. GKE 推理网关会将请求路由到端点选择器扩展程序返回的模型副本。

下图展示了从客户端到模型实例通过 GKE 推理网关的请求流。

请求从客户端通过 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 推理网关，您可以在 GKE 集群上部署这些 LLM，并在 InferencePool 中使用您选择的加速器配置。然后，您可以根据模型名称（例如 chatbot 和 recommender）和 Criticality 属性来路由请求。

下图展示了 GKE Inference Gateway 如何根据模型名称和 Criticality 将请求路由到不同的模型。

根据模型名称和重要性将请求路由到不同的模型
图： 使用 GKE 推理网关在 GKE 集群上部署多个生成式 AI 模型

示例 2：在共享加速器上提供 LoRA 适配器

一家公司希望使用 LLM 进行文档分析，并专注于多语言（例如英语和西班牙语）受众群体。他们针对每种语言都进行了精细调整，但需要高效利用 GPU 和 TPU 容量。您可以使用 GKE 推理网关，在一个通用基准模型（例如 llm-base）和加速器上为每种语言（例如 english-bot 和 spanish-bot）部署动态 LoRA 微调适配器。这样，您就可以通过在一个通用加速器上密集打包多个模型来减少所需的加速器数量。

下图说明了 GKE 推理网关如何在共享加速器上为多个 LoRA 适配器提供服务。

在共享加速器上提供多个 LoRA 适配器
图： 在共享加速器上提供 LoRA 适配器

后续步骤