在 Golang 中實現 JWT 令牌認證
傳統的負載均衡算法可能不適合 AI/LLM 模型后端。與典型的無狀態 Web API 不同，基于 GPU 的 LLM 有不同的運行方式，需要更細致的方法，這能節省很多成本。如果我們能夠利用模型和 GPU 的實時指標來做出更智能的路由和負載均衡決策呢？例如，如果后端 LLM 已經加載了特定的微調（LoRA）適配器，那么對這些模型的請求應該路由到這些端點，而不是那些缺少適配器的端點，從而避免按需加載帶來的不必要 GPU 開銷。同樣，如果后端已經被排隊的請求壓垮，發送更多請求只會降低性能。如果所有后端 LLM 都處于高負載狀態，我們是否可以實施負載削減（在適當情況下）以保障系統穩定性？
這正是?Gateway API 推理擴展項目的目標。它引入了兩個新的 Kubernetes 自定義資源定義（CRD）：InferenceModel 和 InferencePool，以及一個可以擴展 L7 路由的“端點選擇器”概念。這個端點選擇器利用底層 LLM 的指標，為 L7 路由基礎設施做出更智能的路由和負載均衡決策。例如，kgateway 和 Istio 等項目可以將其集成到自己的實現中。
推理擴展擴展了 Gateway API 推理擴展引入了兩個新的自定義資源定義（CRD）：InferenceModel 和 InferencePool。通過使用這兩個新資源以及端點選擇器，L7 路由基礎設施變成了一個“推理網關”，使你能夠以“模型即服務”的思維自托管 GenAI/LLM。
InferenceModel CRD 旨在為 AI 工程師提供服務，允許他們定義邏輯模型推理端點。它將用戶面向的模型名稱映射到后端模型，并為流量分配提供靈活性。例如，假設你想將名為 llama2 的模型暴露給客戶端，但后端模型可能名為 vllm-llama2-7b-2024-11-20 或 vllm-llama2-7b-2024-12-10。使用 InferenceModel，你可以實現這一點并在這些模型之間分配流量。也許你想引入一個新的模型，如 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此外，它允許工作負載所有者指定請求的重要性，確保實時服務優先于盡力而為的批處理作業。下面我們將根據 LLM 指標看到這一點的具體表現。
另一方面，InferencePool CRD 面向管理模型服務基礎設施的平臺運營者。它表示一組模型服務實例，并作為 AI 工作負載的專用后端服務。換句話說，你可以通過 InferencePool 將請求直接路由到一組推理端點。該池通過指定使用哪個端點選擇器來管理感知推理的端點選擇，基于實時指標（如請求隊列深度和 GPU 內存可用性）做出智能路由決策。
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要設置路由，使得對推理網關的請求發送到后端 LLM，我們首先需要創建一個將流量路由到 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: /現在，當請求到達推理網關時，它將根據 HTTPRoute 中的內容進行匹配，然后將請求發送到 InferencePool。在這里事情變得有趣。使用 Envoy 支持的 L7 路由器（如 kgateway 或 Istio），通常路由策略和負載均衡將選擇請求發送到的端點。但在 InferencePool 中，請求首先會進入一個專用的擴展“端點選擇擴展選擇器”（ESE）。這個 ESE 將根據 LLM 的指標選擇合適的后端 LLM 端點。讓我們更深入地了解它的工作原理。
當請求到達端點選擇擴展（ESE）時，它會從請求體中提取 modelName。目前，ESE 期望請求體遵循 OpenAI API 格式。一旦識別出 modelName，ESE 將其與可用 InferenceModel 對象的 modelName 字段進行比較，以確定相應的后端模型名稱或 LoRA 適配器。例如，如果 ESE 檢測到請求的模型名稱為 llama2，它將找到匹配的 InferenceModel，并將請求路由到相應的端點，如 vllm-llama2-7b-2024-11-20 或 vllm-llama2-7b-2025-03-24。
選擇特定模型的端點的邏輯在 ESE 中定義為一系列“過濾器”。這些過濾器評估以下標準，以決定最終的端點：
過濾流程以“這是一個重要請求嗎？”開始。如果請求是 Critical 請求，它將檢查是否有 LLM 端點的等待隊列小于 50。如果找到這些端點，它將檢查這些端點是否加載了模型所需的 LoRA 適配器。如果找到一個通過這些過濾器的端點，它就是返回的端點。如果沒有找到加載了正確 LoRA 適配器的端點，它會找到下一個最佳選項，即可以加載請求的 LoRA 適配器的端點。
如果過濾器看到一個 Sheddable 請求，它將尋找 KV 緩存利用率低于 80% 且等待隊列少于 5 的 LLM。如果找不到滿足該條件的 LLM 端點，則丟棄該 Sheddable 請求。
讓我們看幾個場景：
給定以下 Pod：
對于一個需要 LoRA-X 的重要請求：
給定以下 Pod：
對于一個非重要請求：
給定以下 Pod：
對于一個需要 LoRA-Y 的重要請求：
Gateway API 推理擴展項目引入了一些強大的模型選擇和負載均衡功能，旨在提高在 Kubernetes 上運行時 GPU 和 LLM 的利用率。GPU 供應緊張且價格昂貴。推理擴展項目可以顯著改善請求處理，為組織節省大量資金。項目網站上有一些初步數字，下一篇博客文章中我將提供更多負載測試數據。
原文轉載自：https://mp.weixin.qq.com/s/5LY0vkQYYPndTmHRfj2v5w
