人人妻,天天操,夜夜爽,欧美大黑bbbbbbbbb,欧美另类69xxxxx极品

Image credit: NVIDIA Developer Blog[3]

雖然大部分重點都放在后端優(yōu)化上，以最大限度地提高 GPU 效率，但有效利用不僅僅涉及硬件分配；它還取決于推理請求如何在模型服務實例之間路由和負載平衡。簡單的負載平衡策略通常無法有效處理 AI 工作負載，導致 GPU 使用率不理想并增加延遲。

AI 推理流量路由的挑戰(zhàn)與傳統(tǒng)的網絡流量不同，AI 推理請求具有獨特特性，使常規(guī)負載均衡技術效果不佳。推理請求的處理時間通常較長，有時需要幾秒鐘甚至幾分鐘，而不是毫秒，并且涉及的負載顯著更大。單個請求可能會占用整個 GPU，這使得調度決策比標準 API 工作負載更具影響力。有時，這些請求需要在其他請求處理時排隊。

另一個關鍵考慮是，AI 模型通常維護內存緩存，例如用于提示令牌的 KV 存儲，以幫助提高性能。一些模型還加載微調的適配器，如 LoRA，根據特定用戶或組織需求定制響應。路由決策需考慮這些“有狀態(tài)”的細微差別——請求不僅應均勻分配，還應指向最適合處理它們的實例，這取決于其當前狀態(tài)、可用內存和請求隊列深度。

引入 Gateway API 推理擴展

為了應對這些挑戰(zhàn)，Kubernetes Gateway API 推理擴展通過兩個新的自定義資源定義（CRDs）引入了推理感知路由：InferenceModel 和 InferencePool。

InferenceModel CRD

InferenceModel CRD[4]旨在幫助 AI 工程師定義邏輯模型端點。它將用戶面向的模型名稱映射到后端模型，并提供在微調適配器之間進行流量拆分的靈活性。此外，它允許工作負載擁有者指定請求的重要性，確保實時服務優(yōu)先于盡力而為的批處理作業(yè)。

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

與將請求轉發(fā)到 Envoy上游集群[6]（典型 API 服務的做法）不同，Gateway 調用一個推理感知的端點選擇擴展[7]。該擴展通過監(jiān)控Prometheus 指標[8]來評估模型服務實例的實時狀態(tài)，考慮因素包括 LLM 隊列深度、可用 GPU 內存，以及所需適配器是否已預加載。基于這些實時指標，它選擇最優(yōu)的模型服務器 Pod 來處理請求，確保更好的資源利用率和更低的延遲。

一旦做出路由決策，請求將轉發(fā)到選定的 Pod，響應將流回客戶端。這種方法確保了對 AI/LLM 模型的請求能夠有效分配到可用的 GPU 上，防止特定實例過載，同時最大化整體系統(tǒng)性能。

通過將推理感知邏輯引入路由層，Kubernetes 能夠在延遲和 GPU 利用率上實現超越傳統(tǒng)負載均衡或調度技術的優(yōu)化。

在 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。這種機制可以用于引入新的微調適配器，或者運行藍綠或金絲雀發(fā)布的模型更改。還可以設置重要性級別，這將影響在后端 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 環(huán)境中實現更智能的 AI 流量路由，確保 GPU 基礎設施得到最有效的使用。

借助 kgateway 對 Gateway API 推理擴展的支持，開發(fā)人員和平臺運營者都可以利用這些功能來優(yōu)化 AI 工作負載。

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