KV Cache Offloading怎麼做？GPU、CPU、SSD、Prefetch與Admission Control

先畫出資料生命週期：Offload不是把GPU記憶體變大

KV Cache Offloading的核心，是在GPU HBM快要成為瓶頸時，把暫時不需要的KV block移到較大的Host Memory、NVMe或遠端儲存，之後在請求再次需要前載回GPU。它增加的是可保留資料的容量與重用機會，不是讓CPU或SSD擁有和GPU相同的讀取延遲。每個block都要有清楚的owner、token範圍、模型版本、precision、location和reference count；只要其中一項不一致，載回的資料就可能無法被安全重用。

實作時應把一個請求拆成四個事件：建立KV、移出GPU、在較慢層保留、重新載回。每個事件要記錄 block id、bytes、開始與結束時間、queue wait、來源層與目的層、checksum 或版本指紋。只看「cache hit」會把真正的成本藏起來；一個命中 SSD 的 request 可能省下 Prefill，卻增加了足以超過重算的 I/O 等待。正確的比較是 restore path 和 recompute path 的完成時間，而不是單一命中率。

TensorRT-LLM 的 primary／secondary pool 與優先淘汰

TensorRT-LLM KV Cache System 官方文件把GPU視為primary memory，較慢的 offload memory 視為secondary memory；KV block在請求之間可依共同prefix重用。當primary需要空間時，系統會依 retention priority 與 LRU 邏輯選擇可淘汰資料，並把被移出的狀態保留在secondary pool。這種設計的重點不是無限保留，而是讓高價值、預期會再使用的block在較慢層繼續存在。

優先級必須和業務語意對齊。正在Decode的active block、短時間內即將恢復的preempted request、共用且重建成本高的system prefix，通常比很少重用的長文件更值得保留；但租戶、權限、模型版本和文件版本要先通過隔離檢查，不能因為命中率高就跨邊界共用。優先級還要有上限與老化機制，否則高優先租戶可能長期占滿secondary pool，讓其他合法請求飢餓。

Offload、Prefix Reuse與Recompute要用同一個成本模型比較

對每個候選block，可以估算三條路徑：留在GPU的占用成本、從較慢層載回的成本，以及放棄後重新Prefill的成本。簡化模型可寫成 restore = queue + storage_read + transfer + synchronization，而 recompute = prefill_queue + prefill_compute。若GPU正好空閒、prefix很短或SSD queue很長，recompute可能比restore更快；若prefix很長且未來重用機率高，offload才有機會帶來淨收益。

模型不可只用平均值。應該分別計算P50、P95和P99，並加入取消請求、突發併發、GPU memory pressure、Host NUMA、PCIe／NVLink contention與遠端網路重傳。服務真正要最佳化的是Goodput和SLO，而不是把更多bytes搬來搬去。若offload讓平均TTFT下降、但P99因少數大block載回而暴增，就應縮小Admission範圍、限制單次prefetch bytes或直接選擇recompute。

Prefetch的窗口、預測與錯誤成本

Prefetch只有在資料真正被使用前完成，才可能隱藏搬移延遲。窗口太小，GPU會在Decode時等待；窗口太大，預取資料會先占用GPU和Host資源，甚至驅逐更急迫的block。Scheduler可依下一個layer、請求剩餘token、估計I/O bandwidth和開始時間動態調整窗口，而不是把固定的「預取N個request」當成所有工作負載的答案。

錯誤預取也有成本。若預測了不會被讀取的長prefix，會造成無效I/O、快取污染與額外功耗；若預測過晚，則在critical path上暴露完整載入時間。觀測上要把prefetch issued、prefetch completed、prefetch used、prefetch wasted和deadline miss分開。只有看到used／issued比例、restore P95與GPU idle同步改善，才表示prefetch真的隱藏了搬移成本。

• 先用冷cache、熱cache、部分命中與完全miss建立基線。
• 再固定一個prefetch窗口，觀察queue和GPU idle。
• 調整窗口時一次只變更一個主要參數。
• 對取消或改版請求立即停止無效prefetch。
• 把預取浪費率和P99列入停止條件。

KV Cache Connector：資料格式、檔案與非同步邊界

TensorRT-LLM KV Cache Connector 官方文件提供把KV block載入、保存與管理交給外部連接器的介面。官方示例包含以檔案系統保存block，再依metadata將特定檔案載回GPU block；它適合作為理解API和狀態流轉的參考，不等於高吞吐Production storage。文件也指出同步的檔案I/O、每個block一個檔案和只處理完整block的簡化實作，都需要在真正部署前改造或重新驗證。

Connector的metadata至少要包含邏輯block identity、GPU destination、token range、precision、checksum、save/load狀態與過期時間。save完成前不能把GPU block標成可回收；load未完成前不能讓Attention讀取destination。若程序在兩個事件之間崩潰，重啟流程要能掃描半成品、驗證checksum、刪除孤兒檔案並重建location map。不能因為檔名存在，就把它當成完整且屬於目前租戶的KV。

非同步I/O應與compute stream、copy stream和event同步。同步的torch save／load或大批量blocking filesystem呼叫可能讓GPU整段停住，造成看似「offload開啟」但服務P99惡化。每一層都要有backpressure：Host queue滿時暫停新的swap-out，Disk queue滿時降低Admission，Remote connector失聯時切回recompute或拒絕長上下文，而不是無限累積等待。

Host、NVMe與Remote三層的取捨

層級不應只依容量排序。若Host memory已因其他服務接近上限，NVMe反而可能是較穩定的secondary；若遠端共享需要跨租戶，安全隔離和刪除證據可能比容量收益更重要。每個tier都應有獨立quota與明確的eviction policy，並可在壓力超過門檻時降級。

目前 API 欄位與版本鎖定

TensorRT-LLM 最新 API reference列出 host_cache_size、disk_cache_size、disk_cache_path、disk_prefetch_num_reqs、enable_block_reuse與KV dtype等欄位；部分欄位只在特定 PyTorch backend 或 KV cache manager v2 生效。設定檔中的欄位存在，不表示目前執行路徑一定使用它；部署時要把 backend、版本、實際啟用狀態和runtime events一起驗證。

kv_cache_config = {
  "free_gpu_memory_fraction": 0.70,
  "host_cache_size": HOST_BYTES,
  "disk_cache_size": DISK_BYTES,
  "disk_cache_path": "/fast-nvme/kv",
  "disk_prefetch_num_reqs": 2,
  "enable_block_reuse": true
}

這段只是欄位關係示意，不是通用Production值。真正的manifest要保存 package version、backend、GPU、driver、model、tokenizer、block size、cache namespace和rollback config；升級後先用小流量與固定prompt重跑，不要只依賴舊版benchmark結果。

安全、隔離與失效：KV 不能脫離資料治理

KV cache可能包含使用者輸入、文件內容與工具上下文。即使儲存的是中間表示，命中狀態、大小、載入時間和錯誤也可能洩漏某份資料是否曾被使用。cache key應包含tenant、model、tokenizer、prompt template、policy、document version與access group；權限撤回、文件刪除、模型升級和policy變更時，必須能主動invalidate，而不是等待LRU自然淘汰。

Host與NVMe層應考慮加密、檔案權限、disk cleanup、備份政策和租戶間的容量隔離。Remote connector則要驗證來源與目的地的身份、request範圍、expiry和錯誤回覆；不能因為兩個request的prefix文字相同，就跳過tenant或權限檢查。安全失敗時應選擇miss、recompute或拒絕，而不是放寬cache identity。

故障演練與回滾條件

正式導入前要故意製造 Host memory 壓力、NVMe queue 滿、connector timeout、partial write、GPU reset、程序重啟、權限撤回與模型版本切換。每種故障都要有預期行為：停止新prefetch、保護active decode、清理不完整block、回到recompute、保留可追溯事件，或拒絕無法達成SLO的請求。最重要的是，fallback不能把舊租戶的KV帶到新版本。

可以把下列條件寫入 deployment gate：restore P95高於recompute基線、thrashing rate超過門檻、prefetch wasted比例過高、GPU idle上升、cache checksum mismatch、跨租戶命中、刪除後仍可讀取，或connector錯誤率連續上升。觸發任一高風險條件，就切回baseline或GPU-only cache，保留事故時間窗、request class與event log，再修正一個變因後重新測試。

從事件流找出真正的瓶頸

建議為每次KV狀態變更建立單調遞增的event sequence，包含request開始、block建立、prefix命中、swap-out開始、寫入完成、swap-in開始、載入完成、attention讀取、eviction、invalidate和錯誤。事件不要只寫「cache miss」；要能回答miss發生在GPU pool、Host pool、Disk index、權限檢查還是版本不一致。把event和request、tenant、model version及trace id關聯後，才有辦法將P99尖峰對回某一段I/O或排程。

容量監控也要分層：GPU free blocks、Host pinned bytes、NVMe free space、disk queue、remote connection、pending prefetch、in-flight transfer和orphan blocks都要有獨立告警。若只看GPU顯存，可能在Host queue已塞滿時仍接受大量請求；若只看SSD剩餘空間，則可能忽略單一租戶的quota或大量小檔案造成的metadata瓶頸。告警要包含可執行的降級動作，例如停止新prefetch、降低長上下文上限、回到recompute或切換GPU-only模式。

壓力測試最後要回到讀者能驗證的結果：同一組固定請求，在GPU-only、Host offload、Disk offload與recompute四條路徑下，分別比較restore bytes、TTFT、TPOT、P95、Goodput、GPU idle、錯誤率和品質。若沒有完整硬體環境，應把結果標成架構推論或API驗證，不把文件中的設定範例寫成現場效能結論。

官方資料與圖片來源

本文依據 TensorRT-LLM KV Cache System、TensorRT-LLM KV Cache Connector、TensorRT-LLM latest API reference、KV Cache Transfer 官方文件與 NVIDIA/TensorRT-LLM 官方 repository整理。官方示例與API欄位會隨版本及backend更新，本文把它們用作架構判讀與驗收清單，不把範例參數宣稱為所有硬體或工作負載的保證。圖片使用 pinned commit 71f025e9b2db99638f0f4c0e46079ba79cf0ce43 的官方 KV transfer 圖，來源頁與圖片URL均保留，不主張超出原始專案授權範圍。

__SPECULATIVE_KV_SWAPPING_26479_SOURCE_IMAGE_RECONCILE_20260816__