91精品久久久久久久久久,a中文字幕1区,亚洲精品动漫免费二区

Image credit: NVIDIA Developer Blog[3]

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

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

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

引入 Gateway API 推理擴(kuò)展

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

InferenceModel CRD

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

InferencePool CRD

InferencePool CRD[5]則面向管理模型服務(wù)基礎(chǔ)設(shè)施的平臺(tái)運(yùn)營(yíng)者。它表示一組模型服務(wù)實(shí)例，并充當(dāng) AI 工作負(fù)載的專(zhuān)用后端服務(wù)。該池管理推理感知的端點(diǎn)選擇，基于實(shí)時(shí)指標(biāo)（如請(qǐng)求隊(duì)列深度和 GPU 內(nèi)存可用性）做出智能路由決策。

kgateway 的推理路由工作原理

當(dāng)請(qǐng)求到達(dá) kgateway 時(shí)，將遵循典型的 Gateway API HTTPRoute 策略，以確定哪個(gè)后端處理請(qǐng)求。此時(shí)的后端是一個(gè) 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

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

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

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

在 kgateway 部署推理擴(kuò)展

你可以使用以下 helm 配置部署啟用了推理擴(kuò)展的 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

你還需要將推理擴(kuò)展 CRDs 部署到集群中：

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

要使用 kgateway 配置 Gateway API 推理擴(kuò)展，可以指定一個(gè) 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

在這個(gè) InferenceModel 中，我們指定了一個(gè)面向客戶(hù)的模型名稱(chēng) tweet-summary，然后將其分配到多個(gè)后端 LLM LoRA 適配器 tweet-summary-0 和 tweet-summary-1。這種機(jī)制可以用于引入新的微調(diào)適配器，或者運(yùn)行藍(lán)綠或金絲雀發(fā)布的模型更改。還可以設(shè)置重要性級(jí)別，這將影響在后端 LLM 負(fù)載下請(qǐng)求的處理方式：重要請(qǐng)求將嘗試負(fù)載均衡，而可丟棄請(qǐng)求則可能被丟棄。

我們還需要指定一個(gè) InferencePool，作為我們的 Gateway API 后端以進(jìn)行路由：

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

該資源類(lèi)似于 Kubernetes 服務(wù)，指定了后端 LLM（即 InferenceModel 端點(diǎn)）的選擇器和目標(biāo)端口。InferencePool 資源在 extensionRef 字段中指定了一個(gè)端點(diǎn)選擇器（EPP）。在 kgateway 中，你指定的名稱(chēng)為<pool-name>-endpoint-picker。因此，如果你的 InferencePool 名為 my-pool，則可以使用 extensionRef: my-pool-endpoint-picker。該端點(diǎn)選擇器組件會(huì)自動(dòng)啟動(dòng)，負(fù)責(zé)基于模型的負(fù)載均衡。

總結(jié)

Kubernetes 上的 AI 工作負(fù)載需要的不僅僅是基本的 HTTP 路由——LLM 需要智能流量管理，以確保最佳性能。Gateway API 推理擴(kuò)展引入了模型感知、GPU 高效的負(fù)載均衡，顯著改善了資源利用率和響應(yīng)時(shí)間。通過(guò)利用這一擴(kuò)展，組織能夠在 Kubernetes 環(huán)境中實(shí)現(xiàn)更智能的 AI 流量路由，確保 GPU 基礎(chǔ)設(shè)施得到最有效的使用。

借助 kgateway 對(duì) Gateway API 推理擴(kuò)展的支持，開(kāi)發(fā)人員和平臺(tái)運(yùn)營(yíng)者都可以利用這些功能來(lái)優(yōu)化 AI 工作負(fù)載。

原文轉(zhuǎn)載自：https://mp.weixin.qq.com/s/rNgcxF2WHqTO86v8YD4-eg