PegaFlow 外部 KV 缓存（適用於 vLLM）
啟動速度快 2.15 倍——這是 vLLM 與 Novita AI PegaFlow 聯合文章中的核心數字，但更重要的架構意義在於：生產環境的 LLM 服務需要 KV 缓存的擁有權脫離單一推理引擎程序。PegaFlow 將 KV 缓存轉變為獨立服務，讓 vLLM 部署能在重啟、本地實例及遠端節點之間保存、共享並擴展缓存。
本文從 Novita AI 的角度說明為何我們打造了 PegaFlow、公開的 vLLM 整合顯示了哪些成果、哪些論點已有原始碼支持，以及開發者如何立即查閱開放原始碼實現。
探索 PegaFlow GitHub 倉庫，或閱讀 vLLM x Novita AI 聯合文章以取得完整的技術說明。
PegaFlow 為 vLLM 服務解決了什麼問題？
PegaFlow 解決了高吞吐 LLM 推理中程序本地 KV 缓存脆弱易失的問題。當 KV 缓存只存在於一個 vLLM 引擎程序內時，有用的缓存狀態可能在重啟時消失、被困在單一實例內、或無法有效跨節點移動。
當工作負載重複使用長提示詞、將相似請求路由至多個副本、或將預填充與解碼工作分離時，這種脆弱性就會付出高昂代價。缓存可能已包含系統不該重新計算的結果，但服務拓樸卻往往無法重複利用這些內容。
PegaFlow 改變了這個邊界。它以 Rust 核心實現，作為外部 KV 缓存服務運作，並透過外部 KV 連接器機制（而非長期運行的分支）與 vLLM 連結。
PegaFlow 如何與 vLLM 整合？
PegaFlow 透過 kv_transfer_config、PegaKVConnector 及 kv_connector_module_path 與 vLLM 整合。根據已發佈的文章，連接器讓 PegaFlow 在執行時期接管關鍵的 KV 缓存操作，同時 vLLM 繼續負責排程、模型執行、批次處理及 OpenAI 相容的服務路徑。
公開倉庫目前在其框架整合表中將 vLLM 標記為「就緒」，並在快速入門中展示以下連接器設定：
vllm serve Qwen/Qwen3-0.6B \
--kv-transfer-config '{"kv_connector": "PegaKVConnector", "kv_role": "kv_both", "kv_connector_module_path": "pegaflow.connector"}'
實際的好處是更清晰的擁有權模型：vLLM 保留為服務引擎，而 PegaFlow 則擁有外部 KV 缓存儲存、傳輸、共享及相關缓存可觀測性。
Novita AI 架構增加了什麼？
Novita AI 的設計目標是讓 KV 缓存表現得像生產級服務基礎設施，而非暫時的进程記憶體。這意味著 PegaFlow 圍繞著獨立服務邊界、Rust 資料路徑、共享缓存池及多層儲存來設計。
| 架構選擇 | 對開發者的重要性 | 公開原始碼 |
|---|---|---|
| 獨立的 sidecar 服務 | KV 缓存可在推理引擎重啟後留存，並獨立於 vLLM 进程擴展。 | PegaFlow README |
| 無 GIL 的 Rust 核心 | 缓存热路径避免 Python 開銷，讓推理引擎執行序專注於服務工作。 | PegaFlow README |
| 鎖定主機記憶體、RDMA 遠端記憶體及 SSD 缓存 | 缓存可跨越更快的本地記憶體、遠端節點記憶體及更大容量的 SSD 儲存。 | vLLM 文章 |
| Prometheus 指標及 OTLP 匯出 | 運維人員可以觀察缓存行為，而非將 KV 重複利用視為隱藏的引擎細節。 | PegaFlow README |
最近驗證：2026-05-20。這些細節來自 vLLM 聯合文章及公開的 novitalabs/pegaflow README。
哪些效能結果已經公開？
公開的效能數據應視為來自 vLLM 聯合文章及倉庫基準測試的 PegaFlow 評估結果，而非適用於所有工作負載的通用保證。缓存命中率、提示詞重複使用、模型形狀、硬體、網路拓樸及請求路由都會影響實際部署。
| 情境 | 報告結果 | 來源 |
|---|---|---|
| 使用已擁有的 500 GiB 主機 KV 池啟動 vLLM | 啟動速度快 2.15 倍 | vLLM 聯合文章 |
| 八個 Qwen3-8B 實例共享同一主機缓存 | 吞吐量提高 56% | vLLM 聯合文章 |
| DeepSeek-V3.2 MLA 搭配 TP8 | 吞吐量提高 72% | vLLM 聯合文章 |
| 內部 RDMA 叢集遠端讀取 | 平均遠端讀取吞吐量 194 GB/s | vLLM 聯合文章 |
| H800 參考基準測試，Llama-3.1-8B，熱缓存與冷缓存比較 | TTFT 平均值從 572.5 ms 降至 61.5 ms；P99 TTFT 從 1113.7 ms 降至 77.0 ms | PegaFlow README |
最近驗證：2026-05-20。RDMA 數字在原始文章中描述為內部叢集結果，因此應視為已發佈的評估數據，而非通用吞吐量承諾。
何時最適合使用外部 KV 缓存？
當提示詞重複使用率高到使重新計算在延遲、吞吐量或 GPU 利用率上變得明顯時，外部 KV 缓存最有用。而在幾乎每個請求都獨特、缓存重複使用自然很低的工作負載中，則較不實用。
- 頻繁重啟：將缓存保留在引擎外部可降低重啟代價（若缓存狀態仍有保留價值）。
- 多實例服務：共享主機缓存可減少跨本地 vLLM 實例的重複預填充工作。
- 多節點部署：RDMA 支援的遠端缓存可讓有用的 KV 區塊跨越單機邊界。
- 預填充/解碼分離：外部缓存可為服務系統提供更清晰的階段交接點。
對 Novita AI 而言，這是更廣泛基礎設施原則的一部分：生產級 AI 系統需要服務引擎、記憶體層、路由層及可觀測性層在流量模式變得複雜時能夠獨立演進。
開發者現在如何檢查 PegaFlow？
開發者可以查看公開的 GitHub 倉庫，並安裝 README 中提到的已發佈套件。倉庫文件包含 CUDA 12 套件、CUDA 13 套件、vLLM 連接器範例、伺服器設定、P2P RDMA 設置、預填充/解碼路由、指標及專案目標。
uv pip install pegaflow-llm # CUDA 12
uv pip install pegaflow-llm-cu13 # CUDA 13
README 中最簡單的本地伺服器指令是：
pegaflow-server
對於生產環境評估，請從您自己的提示詞重複使用輪廓、目標模型、GPU 拓樸、記憶體容量及 RDMA 或 SSD 假設開始。PegaFlow 是為缓存重複使用而生的基礎設施；工作負載決定了有多少價值可以捕捉。
平台團隊在採用前應驗證哪些事項？
平台團隊應根據自己的服務拓樸驗證 PegaFlow，然後再將公開基準數字視為規劃依據。正確的測試不應只是冷缓存與熱缓存的比較，而應檢視實際驅動成本或延遲的流量模式中是否存在缓存重複使用。
- 在真實路由下測量提示詞重複使用率及預期的 KV 缓存命中率。
- 比較有無外部擁有 KV 缓存時的重啟行為。
- 先測試單節點多實例共享，再擴展至 RDMA。
- 驗證可觀測性：缓存命中、缺失、傳輸延遲、記憶體壓力及 SSD 行為。
- 確認所使用的部署中與 vLLM 連接器路徑的版本相容性。
這也是開放原始碼邊界重要性的原因。開發者可以檢查連接器、伺服器設定、指標及基準測試設置，而非依賴黑箱缓存服務。
常見問題
什麼是 PegaFlow？
PegaFlow 是 Novita AI 為 LLM 推理開發的開放原始碼 KV 缓存儲存引擎。它以獨立服務運作，並透過外部 KV 連接器路徑與 vLLM 連結。
PegaFlow 需要 vLLM 分支嗎？
不需要。已發佈的 vLLM 文章說明 PegaFlow 透過 kv_transfer_config 和 PegaKVConnector 連接，並透過 kv_connector_module_path 載入外部套件。
哪些效能結果已經公開？
vLLM 聯合文章報告了啟動速度快 2.15 倍、共享主機缓存設定中吞吐量提高 56%、DeepSeek-V3.2 MLA 設定中吞吐量提高 72%，以及內部 RDMA 叢集中平均遠端讀取吞吐量 194 GB/s。README 也報告了 H800 上熱缓存參考基準測試的 TTFT 改善。
開發者可以在哪裡嘗試 PegaFlow？
開發者可以查看公開的 novitalabs/pegaflow 倉庫，安裝 pegaflow-llm（CUDA 12）或 pegaflow-llm-cu13（CUDA 13），並遵循倉庫的快速入門指南。
結論
PegaFlow 是 Novita AI 為 vLLM 生產級 LLM 推理打造的外部 KV 缓存方案：獨立缓存服務、Rust 資料路徑、共享缓存池，以及避免 vLLM 分支的連接器邊界。關鍵結論很簡單：當 KV 缓存成為基礎設施而非程序本地狀態時，服務團隊就能在重啟、共享、擴展及可觀測性方面獲得更多控制權。查看 PegaFlow 倉庫，將公開結果與您自己的工作負載進行比較，並在需要圍繞該服務堆疊使用模型 API、代理執行或 GPU 工作流程時，運用 Novita AI 更廣泛的開發者基礎設施。
