AIBrix 專案目前已經開源，本文為AIBrix 技術解析。詳見：
vLLM 部落格：https://blog.vllm.ai/2025/02/21/aibrix-release.html
程式碼倉庫：https://github.com/vllm-project/aibrix
技術詳解部落格：https://aibrix.github.io/posts/2025-02-20-vllm-control-plane/
隨著 LLaMA、DeepSeek、Qwen 等開源大模型的快速崛起，企業在模型部署的靈活性、成本與自主可控性方面迎來了新的機遇。然而，僅靠對模型本身的最佳化尚不足以將這些模型部署成高效且可擴充套件的生產級 API。大模型推理往往引入諸多獨特的系統挑戰，如 GPU 彈性伸縮指標的非線性問題、長尾模型和精調模型流量過低的問題、多機推理時的角色編排以及 GPU 卡型的異構管理等，都對易用性和成本控制提出了更高要求。因此，我們需要從推理引擎到底層基礎設施進行全棧系統設計，才能真正讓大模型在生產環境中長期穩定且高效地執行。
AIBrix 作為首個基於 Kubernetes 的企業級推理系統專案，正好填補了業界在“系統層”上的空白。它透過最佳化資源排程、自適應擴縮容、快取感知路由以及異構計算管理等多項能力，為企業級大模型的大規模部署提供高效、低成本、可擴充套件的解決方案。AIBrix 與 vLLM 等推理引擎深度協同，持續最佳化推理效率，並融合多項前沿研究成果，推動大模型推理走向更加高效、可落地的生產化階段。
在規劃 AIBrix 專案的過程中，我們始終站在基礎架構的角度，思考如何在大規模場景下為推理引擎提供更好支援。結合字節跳動內部的業務實踐，我們發現，大模型往往會帶來一系列與傳統微服務截然不同的系統挑戰，包括：
-
模型權重的下載 / 載入：如何快速分發和載入體積龐大的模型檔案，降低冷啟動延遲。
-
GPU 彈性伸縮指標的非線性：大模型對 GPU 的利用率並非線性關係，傳統的指標收集與彈性策略常常滯後或不精準。
-
長尾模型或精調模型流量低：針對這些流量低但又需要及時響應的模型，如何做到有效的資源利用和成本控制。
-
多機推理的角色編排：在分散式推理場景下，如何更高效地在多個節點之間分配和排程任務。
-
GPU 卡型異構：不同型號、不同效能的 GPU 共同部署時，如何協同工作並最佳化利用率。
-
單服務跨 Region：多資料中心與跨區域部署的需求增大了同步管理模型與推理任務的難度，同時對容災與可用性提出了更高要求。
傳統微服務框架（如 KNative）或服務網格（如 Istio）在鑑權、流量管控、版本升級等通用能力上已經相當成熟，但對於大模型服務而言仍然顯得過於臃腫，且缺少針對性的最佳化。此外，市面上大多數專案往往將推理引擎視作一個“黑盒”，無法進行深度協同最佳化。
為應對上述挑戰，AIBrix 的核心理念在於透過“引擎層”與“系統層”的緊密協同，搭建一個輕量化、雲原生的方案。具體而言，我們將部分通用的引擎功能解除安裝到系統層面進行管理，並對模型推理常用能力進行封裝，向外提供統一的引擎介面層。這種模式能夠在大規模場景下同時兼顧效能、成本和易用性，幫助企業級大模型部署實現更高的彈性和可控性。
AIBrix 包含控制平面元件與資料平面元件，並完全基於 Kubernetes 進行開發，採用完整的雲原生設計來確保系統的可擴充套件性、可靠性以及資源效率。AIBrix 充分利用了 Kubernetes 的現有功能，包括自定義資源 (CRD)、控制器機制以及動態服務發現等，為大規模 LLM 推理服務提供了穩健的基礎設施。
控制平面元件主要負責管理模型元資料註冊、自動擴縮容、模型介面卡註冊，並執行各種策略。資料平面元件則提供可配置的請求派發、排程與推理服務能力，實現靈活且高效能的模型推理執行。下圖為 AIBrix 的系統架構：
AIBrix 專案已釋出了 v0.1.0 和 v0.2.0 兩個版本。在 v0.1.0 階段，我們主要針對 Serverless 場景進行了一系列最佳化，著重解決冷啟動、彈性伸縮和高密度部署的問題；而在 v0.2.0 階段，我們則聚焦於分散式與解耦化，透過多機推理、KV-Cache 管理以及異構計算管理等特性，讓大模型的規模化部署更加高效可控。
AIBrix v0.1.0 的主要思路是將大模型在生產環境中面臨的核心難題，與 Serverless 領域的幾項關鍵技術（冷啟動、快速伸縮與高密度部署）相結合。我們並不追求讓大模型像 FaaS 一樣徹底“無伺服器化”，因為這在現實中尚難達到理想效果，也並非企業級生產環境的最佳形態；更可行的路線是借鑑並改進 Serverless 的相關思路，對大模型的部署環節進行有針對性的最佳化。
在實際應用中，Autoscaling 最大的難點是：流量波峰和推理例項利用率之間通常存在顯著的時間滯後（常見在 2～5 分鐘），導致高併發場景下容易出現短時過載，從而拉昇長尾延遲。此外，傳統的 GPU 效能指標（如 DCGM 暴露的 DCGM_FI_DEV_GPU_UTIL 或 DCGM_FI_PROF_SM_ACTIVE）嚴重依賴引擎自身實現，也很難體現 GPU 空間利用率，導致擴縮容決策往往不夠精確。
為此，我們嘗試過將引擎 KV_CACHE 利用率 與佇列中待處理請求的輸入 / 輸出指標結合起來，做出更精細的擴縮容判斷。然而在實際業務中，保障 SLO（而非 GPU 利用率）通常是更高優先順序的目標，這使得傳統基於資源利用率的 Autoscaling 策略效果有限。為了應對這一挑戰，我們又探索了 基於 Profiling 並以 SLO 驅動的擴縮容方案，透過對歷史與即時流量分佈進行分析，動態確定擴縮容時機，減少過載並降低尾部延遲。
目前，AIBrix 在此方向上仍在持續迭代研究，包括嘗試更具前瞻性的 LLM 專用指標，以及 Proactive 主動式彈性策略，讓系統在應對突發流量時更加遊刃有餘。
在架構設計中，v0.1.0 主要引入了 Gateway API Plugin (Envoy) + Runtime 這兩個元件，以適配大模型通常面對的兩類路由方式：應用層路由（app router） 和 代理層路由（proxy router）。在大模型社群，如 vLLM 正不斷豐富自身 API（含 token、transcription、score 等），保持與引擎原生介面一致是一項不小的挑戰。為此，我們採用了高效能標準化的 envoy gateway 配合 extension server 來實現定製化，來進行高效能且可定製化的流量管理：
-
只在必要處做 request head/body 的修改，儘量避免重複實現類似 OpenAI 的 API；
-
同時支援對請求進行快取感知的排程，包括 kv cache least used、least of prompt、prefix-cache aware 等策略，以進一步縮短長尾 TTFT（Time to First Token） 等效能指標。
在冷啟動問題上，我們重點考察了不同機型在 網路頻寬、本地盤 I/O、RDMA 等方面的效能差異。雖然雲原生社群已有如 Fluid 等專案可在 “1 -> N” 場景下發揮快取加速作用，但在 “0 -> 1” 階段，磁碟 I/O 並不總能比網路更快，有時透過 遠端流式載入 直接將權重載入進 GPU memory 反而效率更高。
為此，AIBrix 在 v0.1.0 中實現了 GPU 流式載入 方案，支援在 Tensor 層面更細粒度地控制下載速度和順序，為開發者提供靈活的組合策略。需要注意的是，若機型配有本地 NVMe 磁碟，則本地載入可能仍優於遠端；而在分散式檔案系統場景下，單機自我讀取也能減輕對共享檔案系統的集中訪問壓力。AIBrix 將這些能力進一步封裝，開發者可基於自有機型和頻寬狀況，自行選擇最佳載入方式。
對於精調模型（如 LoRA），實現高密度部署是釋放其競爭力的關鍵。我們在 vLLM 專案中做了大量改動來支援 LoRA 的動態部署與度量，血緣關係追蹤、LoRA metrics 單獨計量等關鍵特徵，方便與 AIBrix 控制面深度整合。但這其中依然存在若干未解決的挑戰，我們正在逐步完善並計劃在後續版本中支援更多功能：
-
單容器混合部署：目前基本模型（Base Model）和精調模型（LoRA）常被打包在同一容器，雖然能減少部署節點，但也打破了容器隔離以及不可變性的原則，某些場景會因過載觸發部署失敗。
-
Adaptive LoRA batch、dynamic merge 等高階功能還在持續研發當中，旨在進一步提高同一 GPU 上執行多個模型或微調版本的效率。
-
定製化記憶體分配器（memory allocator）：在固定 GPU 資源中快速換入換出不同基礎模型，利用引擎原生的 CUDA 虛擬記憶體（visual memory）管理能力，使多模型部署具備更好的魯棒性與伸縮性。
AIBrix v0.2.0 的工作重心是分散式與解耦（Distributed and Disaggregated）系統，分散式部分主要涉及到多機推理的編排。我們在對 DeepSeek-R1 671B 模型、16 卡滿配場景下進行驗證後，已經實現了較為穩定的分散式推理方案。具體來說，AIBrix 採用 Ray 來編排分散式推理任務，原因包括：
-
vLLM 自帶分散式 runtime：預設支援 Ray 與多程序，為分散式推理奠定良好基礎。
-
KubeRay 場景經驗積累：AIBrix 專案的核心成員曾主導 KubeRay 的開源工作，對如何在 Kubernetes 與 Ray 之間實現高效整合有著豐富的實踐。目前，KubeRay 是行業通用的 Ray on Kubernetes 編排方案，被廣泛應用於包括字節跳動在內的多家企業生產環境。
-
雲原生的多角色編排：在一個 CRD 中靈活編排不同容器或角色（如 TP/PP 等）並非易事，而多機排程策略也可能因具體業務場景（例如 P&D、Splitwise 論文提出的 Router/CLS、Mixed Pool 或 vLLM xPyD 等）而改變。透過“混合編排（Hybrid Orchestration）”理念，讓 Ray 負責應用內部的角色管理，Kubernetes 則專注於升級、伸縮等通用工作，雙方分工明確且更具靈活性。
在實際實現中，我們將一個多容器推理例項視作一個 Ray 應用，用 RayCluster 來進行描述，再由 RayClusterFleet 負責升級與擴縮容等通用任務。除此之外，我們還在 vLLM 中加入了額外的彈性功能，允許叢集節點在資源不足時先行等待，觸發 Pod 排程與自動擴縮容後，再承接推理負載；這一改進在生產環境中顯著提升了容錯與魯棒性。
在 Prefix/Session Cache、P&D Disaggregation、跨機請求遷移等場景中，KV Cache 元件扮演至關重要的角色。如果僅放在推理引擎內部，諸如跨機分享 KV Cache 等操作就會非常複雜。
AIBrix 透過分散式 KV 快取來應對這些挑戰，不僅實現了跨引擎的 KV 複用，同時也在網路與記憶體效率方面進行了最佳化。我們的方案採用了一種可防掃描（scan-resistant）的淘汰策略，有選擇地保留熱點 KV 張量（hot KV tensors），從而最大程度地減少不必要的資料傳輸；此外，透過非同步方式維護元資料更新進而降低系統開銷，並在快取與引擎的協同部署（colocation）中利用共享記憶體進行更快速的資料傳輸。
在實際部署場景中，我們發現：
-
記憶體層次最佳化：在 prefix cache 等場景中， 如果低端 GPU 型號模型載入已經佔用大部分 HBM 視訊記憶體，留給 KV Cache 的空間十分有限；此時可藉助空閒的 CPU DRAM 做“二級”快取，能實現一定程度上的容量擴充套件。需要注意的是，從絕對效能角度，這種方案不可避免地會帶來從 CPU DRAM 到 GPU HBM 間資料交換的額外開銷，但在容量與效能間取得平衡對於某些業務仍然十分必要。
-
靈活的替換策略：AIBrix 正在基於 vLLM v1 的架構調整，向上遊社群貢獻更多 KV Cache 淘汰策略的實現，敬請期待後續更新。
在異構資源環境中，並非所有使用者都能在同一叢集內獲取一致的 GPU 規格，常常需要混合不同型號的 GPU 來支援同一業務。而異構卡的效能差異也會影響控制面的排程與資料面的路由。
AIBrix 針對這種需求，透過 Profiling + ILP （整數線性規劃） 的組合，找到了成本最優的機型分配和部署方案。對於異構路由策略層面的能力，目前相關功能和特性也正在開發中。
AI Accelerator 故障診斷與模擬工具是 AIBrix 的系統元件，基於火山引擎容器服務 (VKE) 的經驗開發，針對的是 GPU 故障和效能下降在大規模 AI 部署中構成重大挑戰 — 靜默錯誤、過熱、記憶體洩漏和間歇性等故障可導致模型效能下降、延遲增加，甚至系統崩潰；而在異構 AI accelerator 環境中，不同 GPU 型號在不同工作負載下表現不一致，故障診斷和自動化運維更加棘手。
-
故障檢測：目前針對不同廠商的卡型能夠完成自動化故障檢測， 幫助使用者在影響負載之前識別效能問題。
-
故障模擬：該工具可以模擬 GPU 的效能下降或硬體故障，方便開發者測試和構建高容錯能力的 AI 系統。一旦故障發生，系統能平滑恢復，降低對整體服務的影響。
-
硬體支援：目前已支援 NVIDIA GPU 等主流 AI 晶片，後續也將持續擴充套件相容更多型別的加速器。
火山引擎容器服務已實現了 AIBrix 的元件化接入，在一系列 GenAI 場景下的基準測試中，彈性伸縮效能與 token 吞吐量提升超 10%，LoRA 應用成本最高降低 4.7 倍，模型載入提速可超 50%。收益詳情如下：
在上述核心特性中，彈性伸縮是連線雲上應用與雲服務的橋樑。接下來，我們將著重聚焦 LLM 彈性伸縮，深入探究其在 GenAI 場景中發揮的作用以及與 VKE 結合所帶來的價值。
VKE 透過節點池統一管理例項資源，使用節點池建立 8 臺 A10 單卡例項，作為實驗環境。
節點池支援包年包月、按量付費、彈性預約、Spot 等多種例項交付方式，滿足不同場景下的成本與可用性需求
容器映象方面，透過預載入的方式在例項上提前拉取 deepseek-coder-7b 模型映象，加快 Pod 拉起速度。
VKE 集成了對網路請求流入流出、各類資源狀態與利用率、Kubernetes 資源物件以及應用自身執行指標的端到端觀測，並且支援應用的自定義指標透出，藉助這些能力，可以全面觀測 LLM 應用的執行狀態。對於彈性伸縮場景，觀測指標一方面用於工作負載伸縮，一方面用於觀察 AIBrix 的彈性伸縮效果。
AIBrix 集成了多種 Pod 伸縮方法，在本例中，使用 Kubernetes 原生的水平 Pod 自動擴縮器（HPA）與 AIBrix 實現的 Kubernetes Pod 自動擴縮器（KPA，可參考 KPA）進行對比。
LLM 應用負載，使用 vllm 執行 deepseek-coder-7b，彈性伸縮指標使用 vllm:gpu_cache_usage_perc，訪問請求從 ShareGPT 中隨機抽取，並以指定的併發數將這些請求分發給該服務。對於 HPA，AIBrix 會建立一個 Kubernetes 原生的 HPA 例項，以擴充套件指標的方式進行伸縮。對於 KPA，AIBrix 實現了其完整的流程，包括指標收集、對目標部署狀態的定期監控以及伸縮操作。
實驗資料如下所示。AIBrix 支援直接從 Pod 中拉取關鍵指標，因此伸縮響應速度獲得顯著提升，大模型應用首次伸縮響應耗時 12 秒, 相比 HPA 的 67 秒耗時加速 82%。AIBrix 的完整擴容週期為 120 秒，而 HPA 為 320 秒，加速 62.5%，並且震動頻次降低 33%。
AIBrix 的目標是將大模型推理的“系統側”能力與“引擎側”創新完美結合，提供從資源排程、網路流量控制到分散式推理的端到端解決方案。透過與 vLLM 開源社群的深度協作，我們希望不斷迭代並完善在雲原生環境下的大模型部署架構，讓企業能夠更加輕量、彈性地構建面向生產的 LLM 推理服務。
在 AIBrix 開發過程中，我們的很多創新想法都受到了學術研究的啟發，比如 Preble、Melange、QLM 和 MoonCake 等，在這裡我們真誠地感謝這些成果背後的研究人員。我們也非常感謝 vLLM 社群的支援，使 AIBrix 成為了 vLLM 的控制面，進一步增強了我們構建可擴充套件和高效 AI 基礎設施的使命感。
AIBrix 由字節跳動開源，現在正在開源社群的支援下成為一個完全開源的專案——目前專案已經吸引了來自密歇根大學、伊利諾伊大學厄巴納 – 香檳分校、華盛頓大學、Google、DaoCloud 等學術界和工業界的開源夥伴。未來，我們也希望 AIBrix 能透過開放、協作的方法塑造 AI-Infra 的未來，持續將頂尖學術研究和行業內的生產級實踐結合起來。也歡迎更多開發者和企業加入我們，為開放、可擴充套件的 AI 基礎設施的未來做出貢獻：https://github.com/vllm-project/aibrix