关于由 llm-d 提供支持的 GKE Inference Gateway

本页面介绍了 Google Kubernetes Engine (GKE) 推理网关的关键概念和功能，这是 GKE 网关的一项扩展功能，用于优化生成式 AI 应用的服务。

本页面假定您了解以下内容：

• GKE 上的 AI/机器学习编排
• 生成式 AI 术语
• GKE 网络概念，包括 Service 和 GKE Gateway API
• Google Cloud中的负载均衡，尤其是负载均衡器如何与 GKE 交互

本页面适用于以下人员：

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

概览

GKE Inference Gateway 是 GKE 网关 的扩展，可为生成式人工智能 (AI) 工作负载提供优化的路由和负载均衡。它简化了 AI 推理工作负载的部署、管理和可观测性。

如需为 AI/机器学习工作负载选择最佳负载均衡策略，请参阅为 GKE 上的 AI 推理选择负载均衡策略。

特性和优势

GKE Inference Gateway 提供以下关键功能，可高效地为 GKE 上的生成式 AI 应用部署生成式 AI 模型：

• 支持的指标：
  • KV cache hits：键值对 (KV) 缓存中成功查找的次数。
  • GPU 或 TPU 利用率：GPU 或 TPU 处于活跃处理状态的时间所占的百分比。
  • 请求队列长度：等待处理的请求数。
• 用于推理的优化负载均衡：分配请求以优化 AI 模型部署性能。它使用来自模型服务器的指标（例如 KV cache hits 和 queue length of pending requests），以便更高效地使用加速器（例如 GPU 和 TPU）来处理生成式 AI 工作负载。这会启用前缀缓存感知路由，这是一项关键功能，可通过分析请求正文来识别具有共享上下文的请求，并将其发送到同一模型副本，从而最大限度地提高缓存命中率。这种方法可大幅减少冗余计算并缩短首次令牌生成时间，因此非常适合对话式 AI、检索增强生成 (RAG) 和其他基于模板的生成式 AI 工作负载。
• 动态 LoRA 微调模型部署：支持在通用加速器上部署动态 LoRA 微调模型。此功能通过在通用基本模型和加速器上对多个 LoRA 微调模型进行多路复用，减少了部署模型所需的 GPU 和 TPU 数量。
• 用于推理的优化自动扩缩：GKE Pod 横向自动扩缩器 (HPA) 使用模型服务器指标进行自动扩缩，这有助于确保高效使用计算资源并优化推理性能。
• 模型感知路由：根据 GKE 集群的 OpenAI API 规范中定义的模型名称来路由推理请求。您可以定义网关路由政策（例如流量分配和请求镜像），以管理不同的模型版本并简化模型发布。例如，您可以将针对特定模型名称的请求路由到不同的 InferencePool 对象，每个对象部署不同版本的模型。如需详细了解如何配置此功能，请参阅配置基于身体的路由。
• 集成式 AI 安全和内容过滤：GKE Inference Gateway 与 Google Cloud Model Armor 集成，以便在网关处对提示和回答应用 AI 安全检查和内容过滤。您还可以使用 NVIDIA NeMo Guardrails。 Model Armor 会提供请求、响应和处理的日志，以进行回顾性分析和优化。 GKE 推理网关的开放式接口使第三方提供方和开发者可以将自定义服务集成到推理请求流程中。
• 特定于模型的部署 Priority：可让您指定 AI 模型的部署 Priority。优先处理对延迟时间敏感的请求，而非能够容忍延迟时间的批量推理作业。例如在资源受限时，您可以优先处理对延迟时间敏感的应用发出的请求，并舍弃对时间不太敏感的任务。
• 基于预测延迟时间的路由：使用在实时流量上持续训练的 XGBoost 模型路由推理请求，从而优化每个请求的首 token 延迟 (TTFT) 和每个输出 token 的时间 (TPOT) 目标。在高方差工作负载下，比静态启发式方法更准确。请参阅“将基于预测延迟时间的路由与 GKE Inference Gateway 搭配使用”。
• 推理可观测性：提供用于推理请求的可观测性指标，例如请求速率、延迟时间、错误和饱和度。通过 Cloud Monitoring 和 Cloud Logging 监控推理服务的性能和行为，并利用专门的预建信息中心获取详细的分析洞见。如需了解详情，请参阅查看 GKE Inference Gateway 信息中心。
• 通过 Apigee 实现高级 API 管理：与 Apigee 集成，以增强推理网关的功能，例如 API 安全性、速率限制和配额。如需了解详细说明，请参阅配置 Apigee 以进行身份验证和 API 管理。
• 可扩展性：基于可扩展的开源 Kubernetes Gateway API 推理扩展程序构建，支持由 llm-d 提供支持的用户管理的 llm-d 端点选择器 (EPP) 算法。由 llm-d 提供支持的 llm-d 端点选择器 (EPP) 算法为该扩展程序提供核心路由智能。
• 多端口支持：支持公开多个端口的模型服务器，这对于高级服务场景（例如数据并行注意力机制）至关重要。
• 网络端点组 (NEG) 限制：每个Google Cloud 后端服务的 NEG 数量上限为 50 个。使用多端口 InferencePool 时，每个可用区中的每个端口都会创建一个专用 NEG。例如，在典型的区域级集群（三个可用区）中，具有 8 个端口的 InferencePool 会生成 24 个 NEG。因此，多集群网关最多只能从两个集群（2 个集群 × 24 个 NEG = 48 个 NEG）汇总此类 InferencePool，然后达到 50 个 NEG 的限制。

了解主要概念

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

• InferencePool 对象：表示一组共享相同计算配置、加速器类型、基本语言模型和模型服务器的 Pod（容器）。这样可以对 AI 模型部署资源进行逻辑分组和管理。单个 InferencePool 对象可以跨多个 Pod（位于不同的 GKE 节点上），并提供可伸缩性和高可用性。您可以在 InferencePool 资源中指定最多 8 个 targetPorts，以支持需要多个端口的模型服务器。
• InferenceObjective 对象：根据 OpenAI API 规范，通过 InferencePool 指定部署模型的名称。InferenceObjective 对象还指定了模型的部署属性，例如 AI 模型的 Priority。GKE Inference Gateway 会优先处理优先级值较高的工作负载。这使您可以在 GKE 集群上多路复用对延迟时间要求严格和能够容忍延迟时间的 AI 工作负载。您还可以配置 InferenceObjective 对象以部署 LoRA 微调模型。

下图展示了 GKE 集群中的 GKE Inference Gateway 及其与 AI 安全、可观测性和模型部署的集成。

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

llm-d 路由器

llm-d 路由器是推理网关用于做出每个请求端点决策的智能请求路由组件。它由两个子组件组成：

网关模式

GKE Inference Gateway 是以网关模式运行的 llm-d Router。在网关模式下，代理是一个正式的 Kubernetes 网关，其配置和管理与 EPP 服务分开。网关通过 ext-proc 调用 EPP 来做出路由决策，然后将请求直接转发到所选模型服务器 Pod。

将网关（数据平面）与 EPP（路由智能）分离可实现以下功能：

• 共享基础架构：单个 GKE 网关可同时为多个 InferencePool 以及标准 Kubernetes 服务提供服务。
• 高级流量管理：HTTPRoute 政策支持加权分配、逐步发布和请求镜像。
• 独立伸缩：EPP 服务独立于网关进行伸缩。
• 云原生集成：可与 GKE 的托管网关控制器、Cloud Load Balancing 和现有的可观测性工具搭配使用。

GKE Inference Gateway 的运作方式

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

请求流程的运作方式

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

1. 客户端将请求（采用 OpenAI API 规范中描述的格式）发送到在 GKE 中运行的模型。

2. GKE Inference Gateway 使用以下推理扩展程序处理请求：

   1. 基于正文的路由扩展程序：从客户端请求正文中提取模型标识符，并将其发送到 GKE Inference Gateway。GKE Inference Gateway 随后会根据 Gateway API HTTPRoute 对象中定义的规则，使用此标识符来路由请求。请求正文路由与基于网址路径的路由类似。不同之处在于请求正文路由使用请求正文中的数据。
   2. 安全扩展程序：使用 Model Armor、NVIDIA NeMo Guardrails 或受支持的第三方解决方案来强制执行特定于模型的安全政策，包括内容过滤、威胁检测、清理和日志记录。安全扩展程序会将这些政策应用于请求和响应处理路径。
   3. llm-d 端点选择器 (EPP)：监控 InferencePool 中模型服务器的关键指标，并将请求路由到最佳模型副本。如需了解详情，请参阅 llm-d 路由器。

3. GKE Inference Gateway 会将请求路由到端点选择器扩展程序返回的模型副本。

下图展示了通过 GKE Inference Gateway 从客户端到模型实例的请求流程。

流量分配的运作方式

GKE Inference Gateway 会将推理请求动态分配给 InferencePool 对象中的模型服务器。这有助于优化资源利用率，并在不同的负载条件下保持性能。GKE 推理网关使用以下两种机制来管理流量分配：

• 端点选择：动态选择最合适的模型服务器来处理推理请求。它会监控服务器负载和可用性，然后通过计算每个服务器的 score（结合了多种优化启发法）做出最佳路由决策：

  • 前缀缓存感知路由：GKE Inference Gateway 会跟踪每个模型服务器上可用的前缀缓存索引，并为具有较长前缀缓存匹配的服务器提供更高的分数。
  • 负载感知型路由：GKE Inference Gateway 会监控服务器负载（KV 缓存利用率和待处理队列深度），并为负载较低的服务器提供更高的分数。
  • LoRA 感知路由：启用动态 LoRA 服务后，GKE Inference Gateway 会监控每个服务器上的���跃 LoRA 适配器，并为具有所需 LoRA 适配器处于活跃状态或有额外空间可动态加载所需 LoRA 适配器的服务器提供更高的分数。选择总得分最高的服务器。

• 排队和卸除：管理请求流程并防止流量过载。GKE Inference Gateway 会将传入的请求存储在队列中，并根据定义的优先级确定请求优先级。

GKE Inference Gateway 使用数值 Priority 系统（也称为 Criticality）来管理请求流并防止过载。此 Priority 是一个可选的整数字段，由用户为每个 InferenceObjective 定义。值越高，表示请求越重要。当系统面临压力时，Priority小于 0 的请求会被视为优先级较低，并首先被舍弃，同时返回 429 错误，以保护更关键的工作负载。Priority 的默认值为 0。只有当请求的 Priority 明确设置为小于 0 的值时，请求才会因优先级而被舍弃。借助此系统，您可以优先处理对延迟时间敏感的在线推理流量，而非对时间不太敏感的批量作业。

对于需要持续更新或近乎实时的更新的应用（例如聊天机器人和实时翻译），GKE 推理网关支持流式推理。流式推理以增量块或分段的形式提供回答，而不是以单个完整输出的形式提供。如果在流式响应期间发生错误，则流会终止，并且客户端会收到错误消息。GKE Inference Gateway 不会重试流式回答。

探索应用示例

本部分提供了一些示例，展示了如何使用 GKE Inference Gateway 来应对各种生成式 AI 应用场景。

示例 1：在 GKE 集群上部署多个生成式 AI 模型

一家公司希望部署多个大型语言模型 (LLM) 来处理不同的工作负载。例如，他们可能希望部署 Gemma3 模型以用于聊天机器人界面，并部署 DeepSeek 模型以用于推荐应用。该公司需要确保为这些 LLM 实现最佳部署性能。

借助 GKE Inference Gateway，您可以采用 InferencePool 在 GKE 集群中部署这些大语言模型，并使用所选的加速器配置。您随后可以根据模型名称（例如 chatbot 和 recommender）以及 Priority 属性来路由请求。

下图展示了 GKE 推理网关如何根据模型名称和 Priority 将请求路由到不同的模型。

此图展示了 GKE Inference Gateway 如何处理对 example.com/completions 上生成式 AI 服务的请求。请求首先到达 Infra 命名空间中的 Gateway。此 Gateway 会将请求转发到 GenAI Inference 命名空间中的 HTTPRoute，该命名空间已配置为处理聊天机器人模型和情感分析模型的请求。对于聊天机器人模型，HTTPRoute 会拆分流量：90% 的流量会定向到运行当前模型版本（由 {pool: gemma} 选择）的 InferencePool，而 10% 的流量会定向到具有较新���本 ({pool: gemma-new}) 的池，通常用于 Canary 版测试。这两个池都与一个 InferenceObjective 相关联，该对象会为聊天机器人模型的请求分配 10 的 Priority，确保这些请求被视为高优先级。

示例 2：在共享加速器上部署 LoRA 适配器

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

下图展示了 GKE Inference Gateway 如何在共享加速器上提供多个 LoRA 适配器。

后续步骤

• 部署 GKE Inference Gateway
• 自定义 GKE Inference Gateway 配置
• 使用 GKE Inference Gateway 部署 LLM
• 使用基于预测延迟时间的路由与 GKE Inference Gateway 搭配使用（预览版）