2026-06-07 — 次瀏覽

vLLM 0.22 新增多層 KV Cache 卸載：GPU 到 CPU 再到磁碟，為長上下文本地服務而設

vLLM 0.22.0（2026 年 5 月 29 日）推出多層 KV cache 卸載框架，可將已快取的區塊由 CPU DRAM 進一步級聯下放到磁碟，並提供 Python 檔案系統層與 Mooncake 磁碟後端；6 月 5 日的修補版加入了少數模型與 AMD-CPU 修正。對於服務 128K-token 上下文的單機本地設備而言，把 KV 溢出到 NVMe 而非重新計算 prefill，正是同一張卡只能服務一位使用者、還是約八位使

推出了什麼

vLLM 0.22.0 於 2026 年 5 月 29 日標記發布，落地了原生的多層 KV cache 卸載框架（PR #40020）。在此之前，vLLM 可以把 key/value 快取從 GPU 記憶體溢出到 CPU DRAM 再取回，但那就是極限了：一旦主機 RAM 填滿，區塊會被驅逐，prefill 必須重新計算。新框架把 CPU DRAM 視為單一的主層，並讓一個或多個次層位於其後——本地檔案系統、物件儲存、key-value 儲存，或遠端節點。本次發布加入了 Python 檔案系統次層（PR #41735）與 Mooncake 磁碟卸載（PR #42689）作為首批具體後端，並一併支援 DeepSeek V4（PR #43142）。

2026 年 6 月 5 日的修補版 0.22.1 是較小的後續：它加入了 JetBrains 的 Mellum v2 程式碼 MoE，在 AMD Zen CPU 上將 int8 與 GPTQ 線性運算路由經過 zentorch kernels，並修正了一個 DeepSeek-V4 CUTLASS 初始化中斷的問題。對於任何在單機上跑長上下文的人來說，重點功能都在 0.22.0。

分層如何運作

此設計（RFC #38260）引入了一個在排程器程序內執行的 TieringManager，以及每個後端都要實作的 SecondaryTierManager 介面。協調規則是「永遠級聯」：當某個區塊在 CPU DRAM 中被確認後，管理器會非同步地把它下推到每個已註冊的次層，使用對 CPU 張量的 zero-copy 檢視，使排程器永不因 I/O 而阻塞。當某個請求需要一個已從 DRAM 中老化淘汰的區塊時，管理器會把它從次層往上提升，而不是觸發一次全新的 prefill。區塊以標準的 CPU 佈局（TP rank 1 形式）儲存，這正是讓在某個 tensor-parallel 度下寫入的快取，能在另一個度下被重複使用的原因。

經濟帳很簡單。GPU HBM 以接近 3.35 TB/s 的速度搬移資料；一顆 PCIe 4.0 NVMe 硬碟約落在 7 GB/s，並具有亞毫秒延遲。在你拿它與替代方案相比之前，這個落差看似殘酷，而替代方案並不是「從 HBM 讀取」，而是「重新計算整個 prefill」。一旦提示變長，從磁碟載入預先計算好的區塊就能輕鬆勝過重新計算。

為何這對本地設備很重要

2026 年的現實是 128K——乃至 1M-token 的視窗已是尋常的工作負載，而吃掉這張卡的正是 KV cache。以下是一個粗略的單機概況，取自在一張 H100 級別卡上以 128K 上下文服務 70B 模型的獨立基準測試：

設定	在 128K 下的約略並行使用者數
僅 GPU HBM	~1
FP8 KV + CPU swap + 磁碟卸載	~8-10

同一來源指出，當 prefill 以磁碟上的快取命中方式提供、而非重新計算時，一個 128K 系統提示的首字延遲（time-to-first-token）會從約 11 秒降到約 1.5 秒。（那些數字來自某主機代管廠商於 2026 年 4 月的文章，並非 vLLM 自家的數據，因此請將該倍數視為方向性參考。）對於自架的營運者而言，實際的解鎖在於：固定的系統提示或一份長的被檢索文件，不再需要在每次請求時付出代價——它住在 SSD 上，並在需要時被提升回來。

同一次發布也收緊了一開始就讓 GPU 上佔用更小的量化路徑：batch-invariant Cutlass FP8 宣稱端到端 +28.9%（PR #40408），而一個 padded NVFP4 量化 kernel 增加了 +2.4 到 5.7%（PR #42774）。更小的 KV 區塊，加上有地方安置溢出，正是這個能讓單張卡撐得更開的組合。

實務者提醒

如果你用的是單 GPU 機器，而你的瓶頸在於上下文長度而非純粹的 token 吞吐量，這裡的槓桿是一顆快速的本地 NVMe 加上檔案系統或 Mooncake 層，而非第二張 GPU。請用一個貼近現實的共享前綴（一個系統提示或一份固定的 RAG 文件）做基準測試，讓快取命中的路徑真的會觸發；一個冷的、全部都唯一的工作負載，只會讓你看到 I/O 成本，而看不到任何重新計算的節省。在啟用磁碟層之前，先釘住一個合理的 CPU DRAM 預算——主層仍是每個區塊都會經過的暫存區。

較少被考量的角度：多層卸載悄悄地改變了「本地」部署的威脅與可靠性面向。KV 區塊現在會持久化到磁碟，這意味著你的提示與被檢索上下文的內容會在一次請求的生命週期之後仍住在 SSD 上——這是一個當快取隨 GPU 記憶體一同蒸發時並不存在的隱私與保存考量。而由於區塊以標準的 TP-rank-1 佈局儲存，今天建立的快取可以在你更改 tensor-parallel 度或重啟伺服器之後被重複使用，這把 KV 儲存變成你必須去推敲的持久性狀態（驅逐策略、磁碟壓力、過時的條目），而非短暫的暫存。近期值得玩味的問題是：一個持久、可跨重啟的 KV cache，是否會像向量索引早已成為的那樣，在單人設備上成為一項受管理的資產。