跨Worker共享KV Cache怎麼做？Connector、Remote Store、Routing與資料隔離

跨Worker共享KV Cache，是讓一個推論Worker產生的KV狀態，被另一個Worker讀取或重用。它和單一Engine內的Prefix Cache不同：資料可能跨程序、GPU、節點，甚至進入CPU、SSD或Object Store，因此需要明確的Connector、Layout、版本與安全契約。

• Producer寫入KV，Consumer在相容條件下讀取。
• Model、Tokenizer、RoPE、LoRA、Dtype與Block Layout必須一致。
• KV-aware Router需同時考慮Cache Locality與Worker Load。
• LMCache可提供CPU、Filesystem、GDS與Object Store等Backend。
• Mooncake適合大型Tensor與跨節點RDMA傳輸。
• Tenant、權限、Salt、Retention與Timing Side Channel都需治理。

文章實體化：跨Worker共享KV Cache怎麼做？Connector、Remote Store、Routing與資料隔離

本文以「跨Worker共享KV Cache怎麼做？Connector、Remote Store、Routing與資料隔離」為主線，補回人物、作品／事件、時間、地點、做法與可驗證結果，讓抽象論述重新連到真實情境。

• 對象與場景：指出誰在什麼時間、地點與條件下做了什麼。
• 證據與細節：補上名稱、數據、流程、作品、產品或事件節點，並說明它們如何支撐主張。
• 判讀邊界：分開已確認事實、當事人說法與本文的分析，不用形容詞取代證據。

涉及人物近況、價格、規則、活動或市場資料時，發布前應以第一手公告與可追溯來源核對。

四種共享範圍

KV Connector負責什麼

Connector是Serving Engine與外部傳輸或儲存系統之間的介面。Engine告訴它哪些Layer、Block與Token範圍需要寫出或載入，Connector則負責資料位置、傳輸、完成通知與錯誤處理。

engine allocates blocks
→ connector writes or exports
→ metadata publishes availability
→ router selects consumer
→ connector transfers blocks
→ consumer marks ready
→ decode continues

Producer、Consumer與Both

相容性契約

model_revision
tokenizer_hash
chat_template_version
attention_backend
kv_dtype
block_size
layer_layout
rope_config
lora_id
multimodal_hash
tenant_namespace

只比較Prompt Hash不足以證明KV可重用。相同文字在不同Tokenizer、RoPE、模型版本或LoRA下產生的KV不同，錯誤重用可能生成流暢但不正確的輸出。

LMCache與Mooncake的差異

LMCache把可重用KV放到Serving Engine外部，可使用CPU、POSIX、GDS、Shared Filesystem或Object Store。Mooncake Store則以大型Immutable Object與RDMA資料路徑為核心，適合跨節點共享大KV與Tensor。

KV-aware Routing

共享Cache只有在請求被送到能快速取得該KV的Worker時才有價值。Router需要同時考慮缺少多少Token、Remote Read時間、Decode負載、拓撲與Deadline。過載Worker即使擁有完整Cache，也可能比重新Prefill更慢。

失效、保留與安全

• 模型、Tokenizer或文件版本更新時失效。
• 權限撤銷時立即Invalidate。
• 高敏感Tenant使用短TTL與獨立Namespace。
• Tenant ID與Trust Group應進入Cache Key。
• 使用Salt防止Prefix探測。
• Remote Store需加密、認證與Network Policy。
• 刪除要求必須涵蓋所有Replica與Tier。

KV不是可讀文字，但源自使用者資料並會影響模型輸出，應依同等資料分類與Retention政策治理。

Failure模式與安全回退

• Metadata存在，但Object已被Evict。
• 只載入部分Layer或Blocks。
• Model Revision不一致。
• Sidecar重啟遺失Local Index。
• Remote Write成功，Router未收到Event。
• Client取消後留下Orphan KV。

Consumer必須在完整驗證後才將KV標為Ready；失敗時應安全回退到Recompute，不應使用部分資料繼續Decode。

官方資料

• Dynamo LMCache Integration
• Mooncake Store與Transfer Engine
• Dynamo KV-aware Routing

跨Worker共享KV的核心是一份可驗證的相容性契約。Connector負責移動，Remote Store負責保存，Router負責選擇位置；任何一層忽略版本、權限或資料完整性，效能優化都可能變成輸出錯誤。

若想把跨 Worker 共用 KV Cache 的資料契約延伸到 vLLM 的記憶體管理與排程，可接著參考 Woosuk Kwon如何用PagedAttention重做LLM服務？vLLM的KV Cache、排程與生產治理。

這張圖是 vLLM 專案識別標誌，僅用來標示本文所談的 vLLM 生態脈絡，不把標誌誤當成 KV Cache 架構或效能示意圖。

延伸閱讀：共享快取的難題，不只是搬得快，而是知道誰能讀

跨 Worker 共享 KV Cache 時，Connector、Remote Store 與 Routing 會一起決定快取是否真的帶來收益。若路由讓請求頻繁跨節點、資料搬移成本高於重新計算，或快取命中卻沒有版本與租戶隔離，系統就可能在延遲、成本與安全之間同時失分。

設計時應明確定義 key、生命週期、失效條件、加密與清除方式，並為遠端 store 中斷、版本不相容與資料污染準備 fallback。測試也要涵蓋多租戶、熱點前綴、故障重試與滾動更新。快取最佳化的完成標誌，不是命中率最高，而是服務在失效時仍可預期。

增量：跨 Worker 共享 KV Cache，先把資料隔離寫進架構

共享 KV Cache 的目標是減少重複 Prefill 與跨 worker 的計算，但 cache 不是單純的「遠端記憶體」。Connector、Remote Store、Routing、失效策略與租戶隔離必須一起設計，否則命中率提高的同時，也可能帶來錯誤上下文、資料洩漏或難以重現的結果。

• Key：把模型版本、tokenizer、system prompt、租戶與權限範圍納入 cache key。
• Routing：優先送往能命中的 worker，但要有過期、故障與跨區域延遲的 fallback。
• 隔離：明確定義誰能讀、多久保留、如何加密、如何刪除與如何稽核。

評估時同時量測命中率、TTFT、傳輸成本、錯誤上下文率與隔離測試；共享快取若沒有清楚的資料生命週期，就不適合直接放進多租戶生產環境。