vLLM x Novita AI: PegaFlow 用於生產級外部 KV Cache
TL;DR
透過與 Novita AI 合作，PegaFlow 作為一個以獨立 Rust 進程實現的外部 KV cache 服務與 vLLM 整合，將 KV cache 的生命週期移出 vLLM worker 進程，實現跨本地實例與遠端節點的快取池化，並將固定主機記憶體 (pinned host memory)、可透過 RDMA 存取的遠端記憶體與 SSD 結合為三層快取層級結構。
為什麼 KV cache 需要進程邊界
KV cache 是生產環境 LLM 推論服務中最昂貴的運行時資產之一，通常每個主機會佔用數百 GiB，且分配與預熱需要時間，其生命週期往往長於創建它的請求模式。 在傳統的進程內 (in-process) 設計中，KV cache 與推論引擎進程緊密耦合，這在引擎崩潰、滾動升級或模型切換時會造成困擾，因為主機的 KV 池會隨著引擎重啟而消失。 PegaFlow 透過將 KV cache 運行環境移至每台機器上的獨立守護進程 (daemon) 來解決此問題，由該進程擁有主機 KV 池、SSD 快取、拓撲元數據、RDMA 資源、索引狀態與背景任務，而 vLLM workers 則透過 CUDA IPC 與 gRPC 進行連接。 這種設計允許一個快取伺服器在同一主機上為多個引擎與多個模型提供服務，在共享相同記憶體池、SSD 容量與跨節點網路頻寬的同時，提供命名空間隔離，從而實現更清晰的故障域 (failure domains)。
透過外部快取所有權實現更快的啟動
為了隔離主機 KV 池所有權對啟動路徑的影響，我們使用 dummy weights 與 eager mode，在一個運行 Qwen3-8B (TP8) 的 8 x RTX 5090 設置上進行了測試。 使用嵌入式 KV cache 設計時，vLLM 達到 ready 狀態需要 71.4 秒。 使用 PegaFlow 後，在獨立伺服器就緒後，vLLM 僅需 33.2 秒即可達到 ready 狀態，啟動速度提升了 2.15 倍，這歸功於將長效的主機快取分配與推論進程的生命週期解耦。
Rust 數據路徑與尾端延遲 (tail-latency) 穩定性
將 KV cache 移至外部進程的主要動機是生命週期管理、共享與 CPU 資源隔離。 使用 Rust 實現該進程可以避免 Python 解釋器開銷、GIL 爭用與 stop-the-world 垃圾回收，這點至關重要，因為生產級快取服務需要執行背景任務，如統計收集、索引上傳、預取、健康檢查、指標報告、逐出 (eviction) 與 SSD 快取管理。 在 PegaFlow 中，這些任務在同一個獨立的 Rust 服務中運行，不會與 vLLM 共享解釋器運行時，這讓系統有更多空間執行控制平面 (control-plane) 與維護工作，而不會干擾數據平面 (data-plane) 路徑。
跨實例與節點的快取池化
在生產部署中，相同的邏輯 KV 內容通常會被多次複製，因為進程、模型或節點的邊界使得快取彼此不可見。 PegaFlow 將這些孤立的快取碎片轉化為共享快取池。 在單一主機上，所有本地實例都連接到同一個 PegaFlow 伺服器並共享一個 CPU KV 池。 在跨主機方面，PegaFlow MetaServer 維護一個近似的全域索引，允許節點在連接建立後，透過單邊 RDMA READ 在遠端端無需 CPU 參與的情況下獲取遠端 KV 區塊。
單節點多實例共享
我們在同一主機上評估了八個使用相同 500 GiB 快取預算的 Qwen3-8B 實例。
| 設置 | 快取佈局 | 吞吐量 | 平均 TTFT | 請求命中率 |
|---|---|---|---|---|
| PegaFlow | 500 GiB 共享池 | 11.97 req/s | 5.26 s | 52.35% |
| In-process | 8 x 62.5 GiB 隔離池 | 7.68 req/s | 8.22 s | 11.77% |
| 吞吐量提升了 56%，平均 TTFT 下降了 36%，請求命中率增加了 4.4 倍。 |
MLA 邏輯 KV 去重
我們還評估了在 500 GiB 快取預算下使用 TP8 的 DeepSeek-V3.2 MLA。
| 設置 | 快取佈局 | 吞吐量 | 平均 TTFT | 請求命中率 |
|---|---|---|---|---|
| PegaFlow | 邏輯 KV 僅儲存一次 | 1.81 req/s | 35.66 s | 97.23% |
| In-process | 每 TP rank 儲存 KV | 1.05 req/s | 60.88 s | 65.18% |
| 吞吐量提升了 72%，平均 TTFT 下降了 41%，請求命中率接近該 trace 的實際上限。 |
跨節點 RDMA 共享
在一個每個節點配備 8 x 400 Gbps RDMA NIC 的內部生產推論集群中，我們對數千次最近的線上遠端讀取進行了採樣。 對於至少 1 GiB 的大型前綴拉取，PegaFlow 在生產流量下維持了 194 GB/s 的平均有效吞吐量，P99 為 250 GB/s，峰值為 261.6 GB/s。 在此傳輸速率下，大約 100 ms 即可從遠端節點拉取一個 24 GiB 的 KV cache 段，取代了原本會消耗數秒 GPU 時間的 prefill 計算。
三層快取層級
池化讓快取容量更具效益，但主機記憶體仍是有限的。 PegaFlow 透過三層快取層級來解決此問題：熱點本地區塊保留在固定 DRAM 中，遠端命中可透過 RDMA 獲取，而較冷的重複使用區塊可以溢出到本地 SSD。
| 層級 | 介質 | 存取路徑 | 典型角色 |
|---|---|---|---|
| L1 | 本地固定 DRAM | 本地記憶體 | 快速本地 KV 重用 |
| L2 | 遠端 DRAM | RDMA READ | 跨節點快取共享 |
| L3 | 本地 SSD | io_uring | 大容量溢出 |
SSD 快取是基於 io_uring 使用 Rust 實現的。在內部測試中，單個 SSD 提供了約 6.9 GB/s 的峰值讀取吞吐量，而 PegaFlow 保持每顆磁碟約 6.5-6.6 GB/s 的線上穩態吞吐量。 |
|||
| 透過多個磁碟的 RAID0，總吞吐量呈線性擴展。 | |||
| 對於掃描密集型工作負載或快取預算較小的主機，PegaFlow 可以啟用 TinyLFU 准入策略，僅在區塊很可能被重複使用時才准入，保護快取免受一次性流量的影響。 | |||
| 預設情況下禁用 TinyLFU，因為最佳准入策略取決於工作負載的形狀。 |
測量與理論命中率天花板的距離
僅憑線上命中率可能會產生誤導。 PegaFlow 使用 HyperLogLog 在線上估算理論命中率上限：
r* = (N - U) / N
這裡，N 是窗口內的總區塊請求數，U 是首次出現的唯一區塊數。
HyperLogLog 讓這種估算成本極低：一個 24 小時的窗口僅使用不到 1 MiB 的記憶體，誤差約為 0.8%。
PegaFlow 匯出滾動的 HLL 窗口，預設值為 15 分鐘、1 小時與 24 小時。
透過將測得的命中率與理論上限放在同一個儀表板上，運維人員可以區分三種情況：
- 快取已接近工作負載天花板，因此增加容量可能幫助不大。
- 測得的命中率遠低於天花板，這表明還有提升容量、准入、預取或跨節點發現的空間。
- 理論天花板本身很低，這表明工作負載的重複使用率有限，瓶頸並非主要來自快取實現。
透過外部連接器與 vLLM 整合
外部 KV cache 系統通常需要對調度器 (scheduler)、區塊管理器 (block manager) 或注意力內核 (attention kernels) 進行侵入性修改。
PegaFlow 則是透過 vLLM 的外部 KV 連接器機制進行整合。
連接器透過 kv_transfer_config 配置，並可以透過 kv_connector_module_path 動態載入外部套件。
這讓 PegaFlow 可以在運行時接管關鍵的 KV cache 操作，而無需修改 vLLM 源碼或維護一個長期的分支 (fork)。
從 vLLM 的角度來看，PegaFlow 並非推論引擎的替代品；它是透過 KV 傳輸介面連接的外部快取後端，而 vLLM 繼續處理調度、模型執行、批處理與 OpenAI 相容的服務路徑。
這種邊界對兩個專案都有利：PegaFlow 可以獨立迭代其 Rust 數據平面、SSD 快取、RDMA 路徑、索引與連接器邏輯，而 vLLM 在為外部快取系統提供穩定連接器合約的同時，可以繼續改進核心推論引擎。
快速入門
為您的 CUDA 版本安裝套件：
uv pip install pegaflow-llm # CUDA 12
uv pip install pegaflow-llm-cu13 # CUDA 13
啟動一個帶有固定主機記憶體與 SSD 快取的單節點 PegaFlow 伺服器：
pegaflow-server \
--pool-size 30gb \
--ssd-cache-path <ssd-cache-file-path> \
--ssd-cache-capacity 512gb
對於線上部署，我們建議添加 --use-hugepages。大頁 (huge pages) 應預先保留。
對於多節點部署，請先啟動 MetaServer，然後在每個節點上啟動帶有 RDMA 配置的 PegaFlow 伺服器。
當啟用 P2P 時，每個 PegaFlow 伺服器的 --addr 必須是可路由的 IP 地址，而不是 0.0.0.0 或 127.0.0.1，因為其他節點會使用它進行 gRPC 握手與區塊查詢。
pegaflow-metaserver --addr 0.0.0.0:50056
pegaflow-server \
--addr this-node:50055 \
--pool-size 30gb \
--ssd-cache-path <ssd-cache-file-path> \
--nics mlx5_0 mlx5_1 \
--metaserver-addr http://metaserver-host:50056
無需修改 vLLM 源碼即可連接 vLLM。本文中的範例使用 vllm>=0.20.0：
vllm serve <model> \
--kv-transfer-config '{
"kv_connector": "PegaKVConnector",
"kv_role": "kv_both",
"kv_connector_module_path": "pegaflow.connector"
}'
環境變數 PEGAFLOW_HOST 與 PEGAFLOW_PORT 會將連接器指向 PegaFlow 服務。預設值為 http://127.0.0.1 與 50055。
公開參考基準測試
PegaFlow 倉庫還包含一個在 H800 上使用 Llama-3.1-8B 的公開 KV cache 基準測試，使用 8 個提示詞、10K-token prefill、1-token decode 與 4.0 req/s。 在該設置下，熱快取路徑將平均 TTFT 從 572.5 ms 降低到 61.5 ms，P99 TTFT 從 1113.7 ms 降至 77.0 ms。
嘗試 PegaFlow
PegaFlow 已在 GitHub 上發布：novitalabs/pegaflow。該倉庫包含安裝說明、伺服器配置、P2P RDMA 設置、指標文件與 vLLM 連接器範例。
致謝
我們要感謝 Novita AI 團隊開發並將 PegaFlow 投入生產，並感謝 vLLM 維護者與廣大的 vLLM 社群，正是因為你們的討論、審核與連接器基礎設施，才讓這次整合成為可能。
Sources
相關
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch