更智能的Kubernetes AI推理路由：Gateway API推理扩展

更智能的 Kubernetes AI 推理路由

Image credit: NVIDIA Developer Blog[3]

虽然大部分重点都放在后端优化上，以最大限度地提高 GPU 效率，但有效利用不仅仅涉及硬件分配；它还取决于推理请求如何在模型服务实例之间路由和负载平衡。简单的负载平衡策略通常无法有效处理 AI 工作负载，导致 GPU 使用率不理想并增加延迟。

AI 推理流量路由的挑战与传统的网络流量不同，AI 推理请求具有独特特性，使常规负载均衡技术效果不佳。推理请求的处理时间通常较长，有时需要几秒钟甚至几分钟，而不是毫秒，并且涉及的负载显著更大。单个请求可能会占用整个 GPU，这使得调度决策比标准 API 工作负载更具影响力。有时，这些请求需要在其他请求处理时排队。

另一个关键考虑是，AI 模型通常维护内存缓存，例如用于提示令牌的 KV 存储，以帮助提高性能。一些模型还加载微调的适配器，如 LoRA，根据特定用户或组织需求定制响应。路由决策需考虑这些“有状态”的细微差别——请求不仅应均匀分配，还应指向最适合处理它们的实例，这取决于其当前状态、可用内存和请求队列深度。

引入 Gateway API 推理扩展

为了应对这些挑战，Kubernetes Gateway API 推理扩展通过两个新的自定义资源定义（CRDs）引入了推理感知路由：InferenceModel 和 InferencePool。

InferenceModel CRD

InferenceModel CRD[4]旨在帮助 AI 工程师定义逻辑模型端点。它将用户面向的模型名称映射到后端模型，并提供在微调适配器之间进行流量拆分的灵活性。此外，它允许工作负载拥有者指定请求的重要性，确保实时服务优先于尽力而为的批处理作业。

InferencePool CRD

InferencePool CRD[5]则面向管理模型服务基础设施的平台运营者。它表示一组模型服务实例，并充当 AI 工作负载的专用后端服务。该池管理推理感知的端点选择，基于实时指标（如请求队列深度和 GPU 内存可用性）做出智能路由决策。

kgateway 的推理路由工作原理

当请求到达 kgateway 时，将遵循典型的 Gateway API HTTPRoute 策略，以确定哪个后端处理请求。此时的后端是一个 InferencePool：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-route
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: inference-gateway
    sectionName: llm-gw
  rules:
  - backendRefs:
    - group: inference.networking.x-k8s.io
      kind: InferencePool
      name: my-pool
      port: 8000
      weight: 1
    matches:
    - path:
        type: PathPrefix
        value: /
    timeouts:
      backendRequest: 24h
      request: 24h

与将请求转发到 Envoy上游集群[6]（典型 API 服务的做法）不同，Gateway 调用一个推理感知的端点选择扩展[7]。该扩展通过监控Prometheus 指标[8]来评估模型服务实例的实时状态，考虑因素包括 LLM 队列深度、可用 GPU 内存，以及所需适配器是否已预加载。基于这些实时指标，它选择最优的模型服务器 Pod 来处理请求，确保更好的资源利用率和更低的延迟。

一旦做出路由决策，请求将转发到选定的 Pod，响应将流回客户端。这种方法确保了对 AI/LLM 模型的请求能够有效分配到可用的 GPU 上，防止特定实例过载，同时最大化整体系统性能。

通过将推理感知逻辑引入路由层，Kubernetes 能够在延迟和 GPU 利用率上实现超越传统负载均衡或调度技术的优化。

在 kgateway 部署推理扩展

你可以使用以下 helm 配置部署启用了推理扩展的 kgateway：

helm upgrade -i --namespace kgateway-system --version v2.0.0-main kgateway oci://cr.kgateway.dev/kgateway-dev/charts/kgateway  --set inferenceExtension.enabled=true

你还需要将推理扩展 CRDs 部署到集群中：

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/${INF_EXT_VERSION}/manifests.yaml

要使用 kgateway 配置 Gateway API 推理扩展，可以指定一个 InferenceModel，如下所示：

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: inferencemodel-sample
spec:
  criticality: Critical
  modelName: tweet-summary
  poolRef:
    group: inference.networking.x-k8s.io
    kind: InferencePool
    name: my-pool
  targetModels:
  - name: tweet-summary-0
    weight: 50
  - name: tweet-summary-1
    weight: 50

在这个 InferenceModel 中，我们指定了一个面向客户的模型名称 tweet-summary，然后将其分配到多个后端 LLM LoRA 适配器 tweet-summary-0 和 tweet-summary-1。这种机制可以用于引入新的微调适配器，或者运行蓝绿或金丝雀发布的模型更改。还可以设置重要性级别，这将影响在后端 LLM 负载下请求的处理方式：重要请求将尝试负载均衡，而可丢弃请求则可能被丢弃。

我们还需要指定一个 InferencePool，作为我们的 Gateway API 后端以进行路由：

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferencePool
metadata:
  name: my-pool
spec:
  targetPortNumber: 8000
  selector:
    app: vllm-
  extensionRef:
    name: my-pool-endpoint-picker

该资源类似于 Kubernetes 服务，指定了后端 LLM（即 InferenceModel 端点）的选择器和目标端口。InferencePool 资源在 extensionRef 字段中指定了一个端点选择器（EPP）。在 kgateway 中，你指定的名称为<pool-name>-endpoint-picker。因此，如果你的 InferencePool 名为 my-pool，则可以使用 extensionRef: my-pool-endpoint-picker。该端点选择器组件会自动启动，负责基于模型的负载均衡。

总结

Kubernetes 上的 AI 工作负载需要的不仅仅是基本的 HTTP 路由——LLM 需要智能流量管理，以确保最佳性能。Gateway API 推理扩展引入了模型感知、GPU 高效的负载均衡，显著改善了资源利用率和响应时间。通过利用这一扩展，组织能够在 Kubernetes 环境中实现更智能的 AI 流量路由，确保 GPU 基础设施得到最有效的使用。

借助 kgateway 对 Gateway API 推理扩展的支持，开发人员和平台运营者都可以利用这些功能来优化 AI 工作负载。

原文转载自：https://mp.weixin.qq.com/s/rNgcxF2WHqTO86v8YD4-eg