kvcached：把 KV cache 從靜態預留改成按需映射
Virtualized Elastic KV Cache for Dynamic GPU Sharing and Beyond
秒懂
- 它是什麼？
- kvcached 用 OS 虛擬記憶體的概念，把 KV cache 的虛擬位址與實體 GPU 記憶體解耦，讓多個 LLM 在同一張 GPU 上彈性共用記憶體。本文說明它的機制、啟動方式、整合限制，以及什麼情況下該改用別的方案。
- 適合誰用？
- kvcached 適合已經在用 vLLM 或 SGLang、而且手上 GPU 數量不足以替每個模型做靜態切分的團隊，尤其是需要同時跑多個模型或做線上線下共用的場景。如果你的服務只有一個模型、KV cache 佔用穩定、或你無法接受把引擎版本綁在文件列出的測試範圍內，那導入它只會多一層除錯負擔。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
kvcached 要解的是靜態切分留下的閒置記憶體
現在的推理引擎在啟動時通常就替 KV cache 預留一大塊 GPU 記憶體。這個預留量是依照最大併發數與最大序列長度估出來的，服務跑起來之後，這塊空間即使當下沒有請求佔用，別的模型也用不到。當一張 GPU 上要放兩個以上的模型，做法往往是把記憶體切成幾份，各自分配固定的上限。切分的比例一旦決定就很難改，流量偏移時，閒置的那一份救不了吃緊的那一份。
kvcached 的定位是 KV cache library，目標讀者是已經在用 SGLang 或 vLLM、但記憶體利用率被靜態配置壓住的部署者。README 描述的作法是把 GPU 虛擬位址與實體記憶體配置拆開：引擎一開始只保留虛擬記憶體，等到 cache 真的被使用時才映射實體 GPU 記憶體。這讓配置變成隨負載驅動，而不是啟動時就定死。文件列出的使用場景包括多模型共用一張 GPU、serverless 的隨需啟停，以及在有限硬體上組 compound AI system。
虛擬位址與實體頁面之間的映射是整個設計的核心
README 對機制的說明集中在一個句子：decoupling GPU virtual addressing from physical memory allocation for KV caches。拆開來看，流程是引擎先向 kvcached 要一段虛擬位址空間，此時不佔用實體 GPU 記憶體；請求進來、KV cache 真的被寫入時，才由 runtime 把對應的實體頁面接上去。請求結束、區塊被回收後，實體記憶體可以還回去。
這個抽象讓「邏輯上我擁有這麼大的 KV 空間」與「實體上我真的佔了這麼多記憶體」變成兩件事。多個模型各自保留自己的虛擬空間，實際佔用的實體頁面則隨當下負載浮動。README 稱之為 elastic and demand-driven allocation。要注意的是，虛擬空間的保留本身仍有上限，而且映射與回收都在請求路徑上，所以這不是零成本的抽象，只是把成本從啟動時的一次性預留，移到執行期的映射管理。
倉庫另外附了兩篇 arXiv 論文連結，一篇標題是 GPU OS vision，一篇是 Multi LLM Serving。前者說明這個虛擬記憶體想法在整體系統層的延伸，後者對應多模型共用。想理解設計取捨的人應該直接讀這兩篇，README 本身對映射粒度、頁面大小、回收策略都沒有交代。
安裝與 CLI 記憶體上限的實際操作面
README 標示支援 Python 3.9 到 3.13，主要語言是 Python，授權為 Apache-2.0。整合對象是 SGLang 與 vLLM，README 的表格給出的版本下限是 SGLang ≥ v0.4.9、vLLM ≥ v0.8.4，並註明測試到 SGLang v0.5.15 與 vLLM v0.24.0。這兩個數字是判斷能不能用的第一道門檻，因為整合是直接改動引擎的 KV cache 配置路徑，不是外部掛載。
文件提到的操作介面是一個 CLI，功能是 enforce memory limits。README 的 Key Features 段落寫的是 Memory control CLI: enforce memory limits with kvcached CLI，但沒有在正文給出完整指令與參數。實際的旗標名稱、記憶體上限的單位、以及上限是針對單一模型還是整張 GPU，都需要到 examples 目錄或 DeepWiki 文件確認。
另一個有具體路徑的設定是 prefix caching。README 說明 vLLM 端支援 automatic prefix caching（APC），SGLang 端對應 RadixCache，並且有一個可配置的記憶體上限，細節指向 examples/09_prefix_caching。這個目錄是文件裡少數給出明確位置的設定範例，要調 prefix cache 的記憶體邊界就從那裡開始。
引擎與模型支援是一張有明確邊界的表
README 的支援表格列了兩種引擎、五種注意力型態：MHA、GQA、MLA、sliding window、hybrid。範例模型包含 DeepSeek-V3、Qwen3-8B、GPT-OSS-20B、Qwen3.5-9B、Gemma-4-E2B-it、Gemma-4-12B-it。表格下方直接指向 issue #425，說那裡有各引擎、各模型的逐項結果與 KV layout 說明。
這個安排本身透露了一件事：支援與否不是二分法，而是取決於模型的 KV layout 跟引擎版本組合。MLA 模型（DeepSeek-V3、DeepSeek-V2）與 GPT-OSS 這類 hybrid attention 模型是在 2026-03 才加入 vLLM 支援，SGLang 端的 GPT-OSS 支援則更新到 v0.5.9。也就是說，如果你的模型比較新或注意力結構特殊，能不能跑要看你落在哪個版本。
對照組是 pipeline parallelism，2026-03 加入。這些更新節奏說明專案還在快速補支援面，代價是版本相容矩陣會持續變動。升級引擎版本之前先去 issue #425 對一次，比讀 release note 更直接。
prefix caching 與 sleep mode 是兩個不同層次的省記憶體手段
prefix caching 解的是重複計算：多個請求共用同一段前綴時，KV 可以重用，不必重算。kvcached 在 vLLM 端支援 automatic prefix caching，在 SGLang 端支援 RadixCache。這裡有個容易混淆的地方：prefix caching 本身會讓 KV cache 的佔用變大，因為被重用的區塊必須留在記憶體裡。kvcached 的作法是給它一個可配置的記憶體上限，讓 prefix cache 的成長受控，而不是無限制吃掉彈性配置出來的空間。README 把細節放在 examples/09_prefix_caching。
sleep mode 是另一個層次。README 描述 frontend router and sleep mode 這個功能：router 負責把請求導向目標模型，模型閒置時進入 sleep。這對應的是 serverless 場景，模型不需要一直佔著記憶體待命。要注意 router 是 kvcached 自己提供的一層，不是 vLLM 或 SGLang 內建的東西，導入時等於多了一個要維運的元件。
這兩個功能解決的問題不同：prefix caching 降低重複的 prefill 計算，sleep mode 降低閒置模型的記憶體佔用。把它們當成同一件事會誤判導入範圍。
什麼情況下 kvcached 是錯的工具
第一種情況是單一模型、流量穩定的服務。如果只有一個模型在跑，KV cache 的峰值本來就由這個模型的併發決定，靜態預留雖然浪費一點，但換來的是沒有映射開銷、沒有額外元件、沒有版本相容問題。kvcached 的價值來自多個消費者之間的彈性調度，單一消費者時這個價值不存在。
第二種情況是引擎版本落後或超前太多。表格寫的是 SGLang ≥ v0.4.9、vLLM ≥ v0.8.4，並標示測試上限。如果你的生產環境卡在更舊的版本，或已經跳到超過測試範圍的新版，整合路徑可能已經改變。這類專案改的是引擎內部配置邏輯，不是穩定的公開介面，升級時的破壞性變更風險比一般函式庫高。
第三種情況是無法接受請求路徑上多一層映射管理。README 沒有給出映射與回收的延遲數據，也沒有說明頁面粒度與碎片處理方式。如果你的服務對尾延遲極度敏感，而你又無法先在自己的硬體上量測這層開銷，那就不該直接上生產。
第四種情況是團隊沒有能力讀 issue #425 這類逐模型結果。支援矩陣會隨版本變動，README 明確把細節外連到 issue，等於要求使用者在升級前自己核對。這是專案現階段的文件策略，不是缺陷，但它把一部分驗證責任交給了使用者。
與靜態 MPS 切分及引擎內建記憶體池的差異
最常見的替代做法是 NVIDIA MPS 加上靜態記憶體切分，或直接用引擎自己的記憶體池參數把上限調小。這兩種做法的共同點是配置在啟動時決定，執行期不變。MPS 讓多個 process 共用一張 GPU，但每個 process 的記憶體上限是固定的，閒置的那一份不會讓給別人。引擎內建的 gpu_memory_utilization 這類參數也是同樣性質：調低可以避免吃滿，但省下來的空間不會自動被另一個模型用掉。
kvcached 的差別在於配置是執行期決定的。虛擬位址先保留，實體頁面按需映射，所以模型 A 閒置時釋出的實體記憶體可以讓模型 B 用。這是機制上的不同，不是參數調校的差別。
代價是導入面變大。MPS 是驅動層設定，引擎內建參數是改一個 flag，kvcached 則需要引擎端整合、可能還需要 frontend router 這一層。如果你的問題只是「某個模型偶爾吃太多記憶體」，先把引擎的記憶體上限調緊可能就夠了，不需要引入虛擬記憶體這一層。
另一個方向是排程層的做法，例如把不同模型排到不同時間窗執行。這不需要改引擎，但無法處理同時到來的混合流量。kvcached 的 online-offline coserve 場景（見 topics 列表）針對的正是這種同時性。
維護成本、授權與導入前該確認的事
授權是 Apache-2.0，寬鬆授權，允許商用與修改，附帶專利授權條款。這裡不構成法律意見，實際條文與你組織的合規要求仍需自行確認。
維護成本主要來自版本綁定。README 顯示的更新節奏是 2026-01、2026-03、2026-04 各有一次功能更新，v0.1.5 在 2026-04-07 發布。專案沒有 archived，最後推送時間是 2026-08-23，仍在活動。但活躍也意味著支援矩陣會變：MLA 與 GPT-OSS 的 vLLM 支援、pipeline parallelism、prefix caching 都是近幾個月才補上的。每次升級 vLLM 或 SGLang，都應該先確認 kvcached 是否跟上。
外部採用方面，README 提到 Red Hat 的 Sardeenz 專案建立在 kvcached 之上，提供搭配 Kubernetes 與 OpenShift 的動態多模型服務。這是文件裡唯一提到的第三方整合案例，可以作為評估參考，但它同時意味著你的部署環境如果跟 Kubernetes 差異很大，能直接複用的經驗有限。
導入前該確認的具體項目：你的引擎版本是否落在表格區間內；你的模型注意力型態是否在 MHA、GQA、MLA、sliding window、hybrid 這五類之中；examples/09_prefix_caching 的設定是否符合你需要的 prefix 重用行為；以及 kvcached CLI 的記憶體上限語法（README 未給出，需查 examples 或 DeepWiki）。這四項裡有任何一項對不上，就先不要動生產環境。
編輯結論
kvcached 適合已經在用 vLLM 或 SGLang、而且手上 GPU 數量不足以替每個模型做靜態切分的團隊，尤其是需要同時跑多個模型或做線上線下共用的場景。如果你的服務只有一個模型、KV cache 佔用穩定、或你無法接受把引擎版本綁在文件列出的測試範圍內，那導入它只會多一層除錯負擔。動手前先確認三件事：你的引擎版本是否落在 README 表格標示的區間（SGLang ≥ v0.4.9、vLLM ≥ v0.8.4），你的模型注意力型態是否在支援清單內，以及 issue #425 上對應的 KV layout 結果是否涵蓋你的模型。
社群筆記