国产小视频国产精品,欧美一级一毛片,久久一本色道综合

傳統(tǒng)的負(fù)載均衡算法可能不適合 AI/LLM 模型后端。與典型的無狀態(tài) Web API 不同，基于 GPU 的 LLM 有不同的運行方式，需要更細(xì)致的方法，這能節(jié)省很多成本。如果我們能夠利用模型和 GPU 的實時指標(biāo)來做出更智能的路由和負(fù)載均衡決策呢？例如，如果后端 LLM 已經(jīng)加載了特定的微調(diào)（LoRA）適配器，那么對這些模型的請求應(yīng)該路由到這些端點，而不是那些缺少適配器的端點，從而避免按需加載帶來的不必要 GPU 開銷。同樣，如果后端已經(jīng)被排隊的請求壓垮，發(fā)送更多請求只會降低性能。如果所有后端 LLM 都處于高負(fù)載狀態(tài)，我們是否可以實施負(fù)載削減（在適當(dāng)情況下）以保障系統(tǒng)穩(wěn)定性？

這正是?Gateway API 推理擴展項目的目標(biāo)。它引入了兩個新的 Kubernetes 自定義資源定義（CRD）：InferenceModel 和 InferencePool，以及一個可以擴展 L7 路由的“端點選擇器”概念。這個端點選擇器利用底層 LLM 的指標(biāo)，為 L7 路由基礎(chǔ)設(shè)施做出更智能的路由和負(fù)載均衡決策。例如，kgateway 和 Istio 等項目可以將其集成到自己的實現(xiàn)中。

推理擴展擴展了 Gateway API 推理擴展引入了兩個新的自定義資源定義（CRD）：InferenceModel 和 InferencePool。通過使用這兩個新資源以及端點選擇器，L7 路由基礎(chǔ)設(shè)施變成了一個“推理網(wǎng)關(guān)”，使你能夠以“模型即服務(wù)”的思維自托管 GenAI/LLM。

InferenceModel CRD

InferenceModel CRD 旨在為 AI 工程師提供服務(wù)，允許他們定義邏輯模型推理端點。它將用戶面向的模型名稱映射到后端模型，并為流量分配提供靈活性。例如，假設(shè)你想將名為 llama2 的模型暴露給客戶端，但后端模型可能名為 vllm-llama2-7b-2024-11-20 或 vllm-llama2-7b-2024-12-10。使用 InferenceModel，你可以實現(xiàn)這一點并在這些模型之間分配流量。也許你想引入一個新的模型，如 vllm-llama2-7b-2025-03-24。

apiVersion:?inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: inferencemodel-llama2
spec:
  modelName: llama2
  criticality: Critical
  poolRef:
    name: vllm-llama2-7b-pool
  targetModels:
    - name: vllm-llama2-7b-2024-11-20
      weight: 75
    - name: vllm-llama2-7b-2025-03-24
      weight: 25

此外，它允許工作負(fù)載所有者指定請求的重要性，確保實時服務(wù)優(yōu)先于盡力而為的批處理作業(yè)。下面我們將根據(jù) LLM 指標(biāo)看到這一點的具體表現(xiàn)。

InferencePool CRD

另一方面，InferencePool CRD 面向管理模型服務(wù)基礎(chǔ)設(shè)施的平臺運營者。它表示一組模型服務(wù)實例，并作為 AI 工作負(fù)載的專用后端服務(wù)。換句話說，你可以通過 InferencePool 將請求直接路由到一組推理端點。該池通過指定使用哪個端點選擇器來管理感知推理的端點選擇，基于實時指標(biāo)（如請求隊列深度和 GPU 內(nèi)存可用性）做出智能路由決策。

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

要設(shè)置路由，使得對推理網(wǎng)關(guān)的請求發(fā)送到后端 LLM，我們首先需要創(chuàng)建一個將流量路由到 InferencePool 的 HTTPRoute。

apiVersion:?gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-route
spec:
  parentRefs:
    - name: inference-gateway
  rules:
    - backendRefs:
        - group: inference.networking.x-k8s.io
          kind: InferencePool
          name: vllm-llama2-7b
      matches:
        - path:
            type: PathPrefix
            value: /

現(xiàn)在，當(dāng)請求到達推理網(wǎng)關(guān)時，它將根據(jù) HTTPRoute 中的內(nèi)容進行匹配，然后將請求發(fā)送到 InferencePool。在這里事情變得有趣。使用 Envoy 支持的 L7 路由器（如 kgateway 或 Istio），通常路由策略和負(fù)載均衡將選擇請求發(fā)送到的端點。但在 InferencePool 中，請求首先會進入一個專用的擴展“端點選擇擴展選擇器”（ESE）。這個 ESE 將根據(jù) LLM 的指標(biāo)選擇合適的后端 LLM 端點。讓我們更深入地了解它的工作原理。

端點選擇的工作原理

當(dāng)請求到達端點選擇擴展（ESE）時，它會從請求體中提取 modelName。目前，ESE 期望請求體遵循 OpenAI API 格式。一旦識別出 modelName，ESE 將其與可用 InferenceModel 對象的 modelName 字段進行比較，以確定相應(yīng)的后端模型名稱或 LoRA 適配器。例如，如果 ESE 檢測到請求的模型名稱為 llama2，它將找到匹配的 InferenceModel，并將請求路由到相應(yīng)的端點，如 vllm-llama2-7b-2024-11-20 或 vllm-llama2-7b-2025-03-24。

選擇特定模型的端點的邏輯在 ESE 中定義為一系列“過濾器”。這些過濾器評估以下標(biāo)準(zhǔn)，以決定最終的端點：

請求的重要性（Critical 或 Sheddable）
LLM 的隊列等待大小
LoRA 適配器的可用性/親和性
LLM 的 KV 緩存使用情況

過濾流程以“這是一個重要請求嗎？”開始。如果請求是 Critical 請求，它將檢查是否有 LLM 端點的等待隊列小于 50。如果找到這些端點，它將檢查這些端點是否加載了模型所需的 LoRA 適配器。如果找到一個通過這些過濾器的端點，它就是返回的端點。如果沒有找到加載了正確 LoRA 適配器的端點，它會找到下一個最佳選項，即可以加載請求的 LoRA 適配器的端點。

如果過濾器看到一個 Sheddable 請求，它將尋找 KV 緩存利用率低于 80% 且等待隊列少于 5 的 LLM。如果找不到滿足該條件的 LLM 端點，則丟棄該 Sheddable 請求。

讓我們看幾個場景：

示例 1：帶 LoRA 適配器的重要請求

給定以下 Pod：

Pod A: Queue=10, KV Cache=30%,?已加載 LoRA-X
Pod B: Queue=5, KV Cache=70%,?未加載 LoRA-X
Pod C: Queue=60, KV Cache=20%,?已加載 LoRA-X

對于一個需要 LoRA-X 的重要請求：

重要請求檢查：通過（請求為重要）
低隊列過濾：Pod A 和 B 通過（隊列 < 50）
LoRA 親和性檢查：僅 Pod A 通過（有 LoRA-X）
最小隊列過濾：Pod A 通過（只有一個 Pod）
最小 KV 緩存過濾：Pod A 通過（只有一個 Pod）
最終選擇：Pod A

示例 2：非重要請求

給定以下 Pod：

Pod A: Queue=6, KV Cache=85%
Pod B: Queue=4, KV Cache=75%
Pod C: Queue=7, KV Cache=60%

對于一個非重要請求：

重要請求檢查：失敗（請求不是重要）
有容量過濾：僅 Pod B 通過（隊列 ≤ 5 且 KV 緩存 ≤ 80%）
最小隊列 + LoRA + KV 緩存過濾鏈：Pod B 繼續(xù)（只有一個 Pod）
最終選擇：Pod B

示例 3：到處都是高隊列的重要請求

給定以下 Pod：

Pod A: Queue=70, KV Cache=40%,?已加載 LoRA-Y
Pod B: Queue=80, KV Cache=60%,?已加載 LoRA-Y
Pod C: Queue=65, KV Cache=70%,?未加載 LoRA-Y

對于一個需要 LoRA-Y 的重要請求：

重要請求檢查：通過（請求為重要）
低隊列過濾：失敗（所有隊列 > 50）
最小隊列過濾：Pod A 和 C 通過（在隊列范圍的第一段）
低成本 LoRA 過濾：僅 Pod A 通過（有 LoRA-Y）
最小 KV 緩存過濾：Pod A 通過（只有一個 Pod）
最終選擇：Pod A

總結(jié)

Gateway API 推理擴展項目引入了一些強大的模型選擇和負(fù)載均衡功能，旨在提高在 Kubernetes 上運行時 GPU 和 LLM 的利用率。GPU 供應(yīng)緊張且價格昂貴。推理擴展項目可以顯著改善請求處理，為組織節(jié)省大量資金。項目網(wǎng)站上有一些初步數(shù)字，下一篇博客文章中我將提供更多負(fù)載測試數(shù)據(jù)。

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