
作者 | 褚杏娟 、Tina
vLLM 的故事始于加州大學伯克利分校 Sky Computing Lab 里一群充滿熱情的學生與研究員。2023 年,他們開源了核心的 PagedAttention 技術,vLLM 在短短一年多內 GitHub Star 數突破 4 萬,并迅速增長至如今的 6.5 萬,如今已成為全球科技公司首選的推理引擎。
在這一成功背后,Neural Magic 扮演了關鍵角色。這家由 MIT 研究員創立的企業,在巨頭林立的 AI 優化領域中,以獨特的“免費平臺 + 開源工具”策略脫穎而出。通過深入貢獻 vLLM,Neural Magic 不僅構建了成熟的企業級推理堆棧,還持續推動模型優化研究,維護著可直接與 vLLM 集成的預優化模型庫。
正是其在 vLLM 開源社區的深厚積累與工程實力,吸引了紅帽的注意。2024 年 11 月,紅帽正式收購 Neural Magic,并將包括 vLLM 核心維護者 Michael Goin 在內的核心團隊納入旗下。Michael 在優化推理性能、最大化 CPU/GPU 效能方面擁有超過十年的經驗。在 vLLM 社區,他專注于內核調優、模型壓縮及系統優化等工作。
紅帽成為重要參與者之后,AI 大模型領域發生了非常多變化。期間,vLLM 如何應對各種變化和挑戰?紅帽又如何幫助 vLLM 保持競爭優勢?我們采訪了紅帽首席工程師、vLLM 核心貢獻者 Michael Goin 和紅帽亞太 CTO 辦公室首席架構師兼大中華區 CTO 張家駒,他們詳細介紹了 vLLM 的發展近況以及這期間的一些思考。
![]()
紅帽首席工程師、vLLM 核心貢獻者 Michael Goin
從 Llama 轉向 DeepSeek
Michael 團隊作為 vLLM 項目的“內核團隊”,始終專注于集成與開發高性能推理內核,支撐著整個項目在快速迭代中保持領先。
隨著各類模型競相發布,vLLM 的開發節奏也持續加快。尤其是 DeepSeek R1 的發布,推動團隊從聚焦 Llama 系列模型效率優化,轉向全力投入 DeepSeek 模型相關特性的優化中。
為迅速響應 DeepSeek 的新特性,整個 0.7.2 版本的開發周期都很緊湊,此外還高效支持了 Qwen 2.5 VL 并引入了 Transformers backend,使用戶能夠直接運行任意 Hugging Face 模型。隨后的 0.7.3 版本則成為一次規模更大的更新,短時間內有眾多貢獻者參與,開發過程高效且緊張。
該版不僅為 DeepSeek 啟用了多 Token 預測(MTP)、MLA 注意力等優化,還擴展了對 AMD 硬件的支持與調優。此外,專家并行在 DeepSeek 之前并不常見,團隊也因此推動了 vLLM 從支持張量并行、流水線并行到支持專家并行的演進。Michael 還將 DeepSeek 開源的一系列高性能工具,如 DeepGEMM、DeepEP、專家并行負載均衡等,系統化地融入 vLLM 生態。
![]()
面向推理場景,團隊不斷擴充高性能內核庫,涵蓋定制版 Triton、CUTLASS、CUDA 內核、HIP 內核等,還包括各種量化支持、眾多定制內核實現等。
DeepSeek 的復雜性反而為團隊帶來了優化與泛化的契機。Michael 指出,團隊將原本主要用于 DeepSeek 私有環境的技術,轉化為可持續、通用化的實現,使其能服務更多基于 MoE 架構的模型。他強調,vLLM 的某些演進正是受 DeepSeek 所推動,并非因為 DeepSeek 模型本身運行更快,而是其開源的一系列先進技術為整個生態帶來了提升。
這個過程中,DeepSeek 揭示了大模型高效部署的可行路徑,而 vLLM 團隊則將這些經驗復現并通用化,構建出更強大的推理框架。“我們與 DeepSeek 合作,將優秀算法與底層框架的實現相結合,構建出更高效的推理框架,真正實現了強強聯合。”Michael 總結道。
除了主導 DeepSeek V3 的整合,Michael 還帶領團隊完成了 GPT-OSS、Qwen、Kimi 等多個模型的適配與優化。
一個框架如何支持各家硬件
vLLM 團隊的另一個核心使命,是構建開放、高效的硬件推理生態。他們不僅廣泛支持各類主流芯片,更深度參與到新硬件的架構設計與性能優化中,推動整個社區向多硬件兼容的方向演進。
過去幾個月,Michael 一直在與 NVIDIA 共同推進 Blackwell 芯片的支持工作,優化 B200 相關性能。團隊成員還與 AMD 團隊保持緊密協作,確保 AMD 在 vLLM 中的性能表現。Michael 還與 Google TPU 團隊緊密合作一年多,完成了多次版本發布。最近,Michael 還作為最高決策者,參與設計了整體沐曦的支持架構。
以與沐曦的合作為例,可以看到紅帽團隊的參與程度之深:在項目非常早期階段,Michael 便與沐曦團隊共同討論支持框架的設計方向。他主導高層架構,而團隊中的社區貢獻者則深入細節,甚至專程赴上海進行面對面技術對接。雙方還專門在 Slack 上創建了頻道,組建起一個跨公司的“線上聯合工作組”,確保支持工作持續高效推進。
整個流程體現了團隊對生態建設的嚴謹投入:他們先為硬件伙伴指明實現方向;待沐曦完成相應工作后,再共同進行代碼審查與迭代優化。例如,協助沐曦將最初的支持方案,通過插件機制重構得更為優雅和可維護。在 GitHub 上,大量的修訂建議(RC)經過團隊的仔細審核。現在,Michael 手中持有一份很長的待審核列表。
這種深度協作,最終讓雙方共贏。正如張家駒所言:“對沐曦而言,他們找到了讓社區支持其硬件的優雅方式,這意味著未來的維護工作量將比以往更少。對社區而言,我們也推動了一個支持不同硬件的生態系統的發展。”
PyTorch 之重
在異構計算時代,vLLM 之所以能廣泛支持從 NVIDIA、AMD 到 Google TPU 乃至國內眾多芯片,其核心戰略在于:深度擁抱 PyTorch,將其作為連接上層框架與底層硬件的“最大公約數”。
從技術棧來看,硬件之上是 PyTorch,PyTorch 之上才是 vLLM。這意味著,只要硬件廠商提供了對 PyTorch 的良好支持,那么適配 vLLM 的工作就已完成大半。vLLM 中的模型定義幾乎完全基于 PyTorch 編寫,僅對注意力機制等少數關鍵模塊保留了可替換的定制化空間。
PyTorch 自身已提供 SDPA 注意力實現,而 vLLM 在此基礎上還支持十余種其他硬件 backend 的注意力實現,比如 NVIDIA 的 FlashAttention 與 FlashInfer、AMD 的 ROCm Attention 與 Triton Attention、Google TPU 的 Pathways Attention,以及昇騰 NPU 的 Attention 等。
正是通過這種統一的 PyTorch 抽象層,vLLM 得以集成各家硬件的加速實現。只要硬件供應商提供適用于 PyTorch 的集成或分發版本,絕大部分(約 90%)工作就已自然完成。而剩余約 10% 主要涉及對 PyTorch 中效率較低的部分進行定制優化,例如融合 MoE、矩陣乘法量化以及特定的注意力實現。
Michael 解釋稱,vLLM 之所以深度依賴 PyTorch,是因為幾乎所有硬件供應商都有充分理由基于 PyTorch 進行開發:它不僅用于訓練,也用于推理,并且與絕大多數開源軟件深度集成。
他進一步表示,PyTorch 的主要競爭者是 Google 的 JAX,但 JAX 的開源程度相對較低,比如其 XLA 編譯器 backend 并未開放,實際生態普及度遠不及 PyTorch。正因為 PyTorch 被視為從機器學習到硬件層的最佳抽象框架,vLLM 才緊密依托其基礎架構,并圍繞高效大語言模型推理進行功能擴展,這也部分解釋了 vLLM 選擇加入 PyTorch 基金會的原因。
張家駒也指出,PyTorch 的應用如此廣泛,以至于任何硬件廠商均主動適配 PyTorch 生態。像國內各類芯片廠商也正是通過 PyTorch 這一路徑進行集成與適配的。
簡言之,vLLM 不直接面對紛繁復雜的硬件技術棧,而是依托 PyTorch 這一成熟、開放的中間層,與硬件廠商及社區協同共建。這既降低了多硬件支持的復雜度,也讓整個生態能在統一的基礎上持續演進與優化。
NVIDIA 所謂護城河還很堅固?
那我們自然需要面對一個更深層的問題:如果說 CUDA 是 GPU 加速的“引擎”,PyTorch 就是調用它的“框架”,那么新興硬件廠商究竟該如何追趕,才能達到與 NVIDIA CUDA 同等的高效與易用水平?
在 Michael 看來,這是一個充滿挑戰的命題。核心難點在于,即便最終能在 PyTorch 層實現功能兼容,其效率往往難以匹敵 NVIDIA 經過十數年深度打磨的 CUDA 生態。“CUDA 對其他硬件而言并非一種可直接遷移的語言,”他指出,這本質上是硬件抽象與軟件生態的長期累積差距。
不過,路徑依然存在。
Michael 指出,在硬件抽象層,采用類似 Triton 這樣的領域特定語言是一種解決方案:只需用 Triton 編寫一次算法,便可在多種硬件平臺上運行。但該模式也存在局限:即使軟件最終能夠支持所有硬件 backend,內核開發人員仍需投入大量手動調試與內核開發工作,針對具體硬件進行深度調優才能實現高效率。
而張家駒分析稱,實現與 CUDA 同等能力,有多種技術路徑。例如沐曦選擇完全兼容 CUDA API 的路線,此外也可借助領域特定語言通過不同的 backend 編譯實現跨硬件運行,如 Triton 就是一種編寫 GPU 算子的新興語言。但這本質上仍是一種需要大量人工優化與適配的模式。
但轉折點也正在出現。Michael 敏銳地指出,新型注意力算法正在不斷涌現,對于這些嶄新技術,其他硬件供應商有可能實現超越。
“它們非常新穎,供應商或許能提供比 CUDA 更快速、更原生的支持。例如 Kimi 提出的 KDA 算法,便率先通過 Triton 獲得支持。在新算法領域,其他廠商有時反而能更敏捷地響應。”Michael 說道。
隨著模型供應商不斷探索比標準 Transformer 更高效的新架構,硬件廠商也獲得了更大的靈活性與快速響應空間。就像 Michael 的那個比喻:這就像體育競賽,一切又回到了同一條起跑線。
多模態支持
在軟件與硬件生態持續融合的背景下,vLLM 并未止步于優化單一模態的推理。當多模態 AI 浪潮席卷而來時,團隊將 vLLM 從一個純文本推理引擎,全面升級為一個支持全模態生成與理解的統一服務平臺。可以說,多模態模型架構如今改變了 vLLM 的架構。
“無論是文生圖、文檔理解,還是其他生成任務,其底層均依賴于大模型推理,因此都可以通過 vLLM 進行處理。”Michael 指出。
為此,團隊對 vLLM v1 版本進行了徹底重構,其中一項關鍵創新是多模態前綴緩存(multimodal prefix caching)。傳統上,vLLM 通過 Page Attention 復用文本 token 的鍵值緩存;如今,這一機制已擴展至圖像、音頻等任意模態輸入。現在團隊維護的是多模態緩存,重復請求的處理效率因此大幅提升。
為進一步支撐大規模推理部署,團隊實現了編碼器解耦技術,將視覺、音頻編碼器與語言模型 backbone 解耦。這既符合多模態模型的結構特點,也為超大規模推理場景提供了極致的彈性與資源利用率。
今年 12 月,這項演進迎來了一個里程碑:vLLM-Omni 作為其首個“全模態”推理框架正式發布,它將文本、圖像、音頻、視頻的統一生成從概念變為可落地的生產級代碼。Omni 并非在原有框架上簡單封裝,而是引入了一套完全解耦的流水線架構,讓不同階段按需分配資源,并通過統一調度銜接。一個 omni-modality 推理請求大致會經過模態編碼器、LLM 核心與模態生成器三類組件,通過管線調度在不同 GPU/ 節點間協同工作。
![]()
這一進化極大拓展了 vLLM 的應用邊界。如今,vLLM 作為一個推理引擎與服務器,其支持的范圍十分廣泛:它不僅能運行文本生成模型,還支持多模態理解與生成、嵌入模型(用于 RAG 與向量數據庫)、智能體編程(驅動 Claude Code 等工具),甚至在企業級層面,可應用于文檔理解、OCR、推薦系統、客服、編程輔助乃至缺陷檢測等判別式任務。此外,在強化學習等訓練流程中,最終部署的推理模型、思維模型或工具調用模型,同樣可以構建在或內置于 vLLM 之上。
“vLLM 的核心角色,是一個高效的推理引擎與服務器,”Michael 總結道,“這類似于 Web 服務器托管各種網頁應用(如 HTML 或 JavaScript 頁面)的邏輯。vLLM 需要承載各種各樣的模型與應用,并致力于在各種使用場景下,無論是應對一千名還是十萬名用戶的訪問,都能提供優異的性能。”
從統一硬件抽象層到定義全模態推理架構,vLLM 正穩步推進其愿景:成為 AI 時代最通用、最高效的推理基礎架構。
如何保持競爭優勢
隨著 vLLM 在過去兩年半中逐漸發展成熟,一個趨勢越來越明顯:無論是去年還是今年,許多公司都開始將更多修改回饋至上游。
“這是因為 vLLM 本身已經有了大量的改進,這些改進對他們私下開發的版本來說也是有增益性的,所以他們希望能更頻繁地與上游同步。他們開始愿意把自己定制的改動 upstream 到項目中,并且更傾向于直接使用 upstream vLLM,而不是開發一個非常不同的私有版本。我們已經在多個案例中看到了這種情況的發生。”Michael 解釋道。
這一良性循環的核心驅動力,在于“速度”。
“我們的上游版本有一個獨特優勢:就是和眾多領先的模型實驗室和公司合作,快速收集他們的反饋,有 bug 就去修,修完之后也會放回社區,讓更多人看到。”張家駒補充道。vLLM 的合作名單涵蓋了從 DeepSeek、Qwen、字節、騰訊,到 LinkedIn、亞馬遜、Mistral、Azure 和 Snowflake 等。
“了解他們可能如何使用 vLLM,以及未來模型架構可能對 vLLM 提出哪些改進需求,通過開發這些功能,來確保 vLLM 始終保持競爭力,緊跟行業發展。”張家駒說道。
用戶越多,反饋就越快,迭代也越迅猛。當社區版本的迭代速度遠超私有分支時,即使后者曾開發某些獨有功能,也會很快發現社區版本的功能更多,可能有些功能與其類似。為了保留自己的少量修改而放棄社區的更多功能,顯然得不償失。張家駒指出。
據張家駒觀察,去年很多人可能還用自己的版本做一些小開發,但今年在發現社區版本比他們“跑”得快很多后,大家都更傾向于使用社區版本。這種“速度優勢”正推動 vLLM 加速成為大模型推理領域的事實標準。
one more thing:回應開發者問題
作為一個每月下載量超 20 萬次的熱門推理框架,vLLM 的廣泛采用也使其必須直面生產環境中的真實挑戰。近期,不少開發者集中反饋了啟動速度偏慢的問題。
對此,Michael 回應道,團隊大約從幾個月前已經開始明確著手解決。團隊不僅在 GitHub 上建立了專項跟蹤與“啟動體驗優化”項目,還在 Slack 開設了專門頻道,以持續收集并響應用戶的實際痛點。
Michael 解釋,導致啟動時間較長的因素有幾個,其一是 CUDA graph capture time:為了獲得最佳性能,開發者希望能捕獲盡可能多的 CUDA graph,但每多捕獲一個 graph,啟動時間也會增加,因此這需要做好權衡。另一個因素是 torch.compile,它本身也會需要一定的時間。開發團隊已推動 torch.compile 團隊重視啟動時間問題,也取得了一些顯著改進。
另外,vLLM 團隊還打造了一些工具和指南,指導用戶如何處理冷啟動與熱啟動的差異,即模型是否首次運行與部署。團隊設置了緩存目錄,用于存儲 torch.compile 的輸出結果、Triton 的輸出結果以及其他編譯或初始化的內容。若開發者正在部署單個模型,并計劃擴展至多個副本,團隊建議在部署中復制該緩存目錄以實現熱啟動,這比冷啟動快得多。
結束語
在 vLLM 這一由社區驅動的項目中,紅帽以其深厚的開源基因扮演著重要的角色。正如張家駒所說:“紅帽全球約有兩萬名員工,其中可能有一兩千名工程師完全在社區中做貢獻。他們貢獻的工作并不針對紅帽的商業方面,做的事情非常中立。”
Michael 進一步指出,vLLM 的治理結構本身高度分散,共有 15 到 20 個不同組織的成員擔任提交者或維護者。紅帽正是在這樣的多元生態中,以其工程實力與對開源原則的堅持發揮影響力。
紅帽如此投入 vLLM,源于一個戰略判斷:推理是 AI 應用成本的核心環節。例如,若 DeepSeek 以其公開的成本效率托管模型,企業也必然期望在本地部署中達到同等水平。實現這種性能,需要 vLLM 集成最前沿的模型優化,而紅帽正致力于此。
最具代表性的貢獻是紅帽主導推動了 vLLM v1 版本的架構重構。這次升級不僅為未來系統設計奠定了基礎,更實質性地推動了社區標準化進程。例如,與 PyTorch torch.compile 團隊長達一年半的合作,優化了上游框架以更好支持 vLLM 的高階場景。“這些工作讓支持新硬件、新模型變得更容易,”張家駒解釋道,“紅帽力圖把這個標準化的層做得越來越厚、越來越穩定。”
面向更加多變的未來,紅帽和 vLLM 如何守住“推理服務標準”的地位,我們拭目以待。
AI 重塑組織的浪潮已至,Agentic 企業時代正式開啟!當 AI 不再是單純的輔助工具,而是深度融入業務核心、驅動組織形態與運作邏輯全面革新的核心力量。
把握行業變革關鍵節點,12 月 19 日 - 20 日,AICon 全球人工智能開發與應用大會(北京站) 即將重磅啟幕!本屆大會精準錨定行業前沿,聚焦大模型訓練與推理、AI Agent、研發新范式與組織革新,邀您共同深入探討:如何構建起可信賴、可規模化、可商業化的 Agentic 操作系統,讓 AI 真正成為企業降本增效、突破增長天花板的核心引擎。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.