當 ChatGPT 或 Claude 這類服務在幾秒內回應一個提問時，背後其實是一整套高度工程化的推理基礎設施在運作。Momento 共同創辦人暨執行長 Khawaja Shams 在 InfoQ 舉辦的 QCon AI 大會上發表了一場題為「Serving LLMs at Scale: The Hidden KV Cache Advantage」的演講。他出身於分散式系統領域，曾參與 NASA 火星探測車相機系統、在 AWS 領導 DynamoDB 與 AWS Elemental，現在則專注於高效能資料基礎設施，也是開源專案 Valkey 的貢獻者。他以分散式系統工程師的視角切入 LLM 推理，指出一個常被忽略的事實：GPU 是當今最稀缺的資源之一，而提升 GPU 利用率，直接決定了推理服務的可用性、效能與成本。
背景
要理解這場演講的核心，得先從推理的兩個階段說起。當使用者送出一段提示詞，系統其實會分兩步處理。第一步是 prefill 階段，把輸入的提示詞轉換成模型能理解的內部表示，這個階段高度依賴計算能力，可以大量平行處理。第二步是 decode 階段，模型逐一生成回答的 token，這個階段必須反覆參考之前的所有內容，因此重度依賴記憶體頻寬。使用者最在意的指標「time to first token」，也就是從送出請求到第一個字出現的時間，必須等 prefill 完全結束才會開始，就像人必須聽完問題才能回答一樣。
Prefill 過程中產生的中間資料會存進 KV cache，也就是「鍵值快取」。這個名字容易誤導人：它並不是像 HashMap 那樣一個鍵對應一個值，而是每個 token 的表示都取決於它前面出現過的所有 token，是一種需要完整前綴才能重用的向量化狀態。這正是 KV cache 難以管理的根本原因。
核心內容
Shams 用實際實驗具體化了 KV cache 的龐大體積。他用一個僅 40 億參數的中小型模型，在 AWS 的 G6 GPU 執行個體上測試。經過計算，這個模型每個 token 會產生約 72 KB 的 KV cache 資料：模型有 36 層、每層 8 個 KV heads、每個 token 映射到 128 維的嵌入向量。一個 20,000 token 的提示詞就會產生約 1.6 GB 的快取資料。而像是 Claude Code 這類代理式工作流程，每個對話來回動輒超過 10 萬個 token。GPU 的記憶體卻非常有限，普通 GPU 只有 24 GB，最先進的 Blackwell GPU 也只有 192 GB，要為每位使用者保存好幾 GB 的狀態，成本很快就失控。
更麻煩的是，KV cache 幾乎無法在不同對話之間共用。因為每個 token 的值都依賴其上下文，同一個詞在不同語境下的意義完全不同，無法像傳統快取那樣直接重用。這也解釋了為什麼每個使用者的快取基本上都是個人化的。一個實際案例是：有團隊成員發現 Llama.cpp 推理引擎會在提示詞前插入時間戳，這個看似無害的動作會讓整個前綴失效，GPU 必須重新執行全部 prefill 計算。
技術與脈絡解讀
不過，提示詞的不同部分確實有可共用的空間。系統提示詞在所有使用者之間完全相同，可以跨使用者共享；同一個使用者在幾分鐘到幾小時內的先前對話輪次，也大概率還留在快取中。Shams 觀察到 Claude Code 的快取命中率之所以很高，是因為它每次不是發送全新提示詞，而是在上一輪之後持續附加內容，讓前綴始終保持一致。
實驗結果清楚顯示了「快取懸崖」的存在。當模擬的代理式編碼工作流程跑到 12 個並發對話時，p50 的首 token 延遲只有一秒，p99 也只有 2.6 秒，表現相當好，因為 KV cache 恰好還裝得下，數學上大約可以容納 13 個這樣的對話。但一增加到 14 個並發，記憶體開始放不下，快取在輪次之間被驅逐、必須重新計算，p99 頓時從 2.6 秒暴增到 38.9 秒。這就像 2000 年代電腦開始使用 swap 空間時整個系統卡死一樣，少數幸運的對話還能命中快取，被擠出去的則表現極差，形成嚴重的長尾延遲。
解法之一是分層儲存。GPU 記憶體最快但最貴；主機上的 DRAM 雖然速度較慢，卻便宜得多，而且重算的成本往往更高；再往下是 NVMe 固態硬碟，容量可達數十 TB，但寫入次數有壽命限制，不斷覆寫大型 KV 資料會很快耗盡 SSD 壽命；最後一層是直接重新計算。實驗顯示，僅加上 32 GB 的本地 DRAM，就能把並發懸崖從 14 個對話推到 28 個，其中 16 GB 是關鍵的轉折點，p99 從 38 秒降到約 3.5 秒。
在遠端快取方面，Shams 透過他參與的開源專案 Valkey（Redis 的分支，由 Amazon、Google 等公司共同支援）指出，這個場景真正重要的是飽和網路卡頻寬，而不是低延遲，因為你是在下載好幾 GB 的上下文。把大物件切成許多幾 MB 的小塊平行下載、以及避免不必要的記憶體拷貝，是最有效的優化。他特別警告一個常見陷阱：有人用 Rust 重寫客戶端想加快速度，結果 4 MB 的物件下載完成後，還要從 Rust 層複製到 Python 層、再到 CUDA 空間、最後到 GPU，層層拷貝反而拖慢整體速度。盡量減少拷貝，才是經典電腦科學功底在推理堆疊上最有價值的地方。
影響與限制
這些發現對服務營運者有直接的實務意義。首先，不能再用並發數量作為准入控制的依據。多租戶環境下，流量會因為工作流程不同而劇烈變化：簡短的單輪問答可能只有幾千 token，代理式編碼工作流程卻動輒數萬 token，一次 Claude Code 的改版就可能完全改變流量樣貌。正確做法是依模型計算每個 token 的快取成本，評估特定 token 規模下的懸崖位置，在決定是否讓新請求進入某張 GPU 時，先判斷它會不會觸發驅逐。
路由策略也很關鍵。把對話固定回送到同一張 GPU 的 sticky session 能提高快取命中率，但這類工作流程極不穩定——使用者可能馬上回來、可能去吃午飯、也可能再也不回來，容易造成特定 GPU 過熱的「銀行擠兌」效應。業界因此發展出 KV 感知路由，例如 Mooncake 的主動式 KV 遷移，以及 NVIDIA Dynamo 的權重式排程。Shams 的實驗顯示，兩張 GPU 若不考慮會話親和性，輸出只有 128 tokens per second，效率僅 58%；啟用會話感知後達到 201，接近理想的兩倍。
更激進的做法是將 prefill 與 decode 拆分到不同節點，也就是所謂的 disaggregated 架構。Shams 用一個簡單練習說明原理：交替唸「1 到 12」或「A 到 L」都很快，但要唸「A1、B2、C3」就會卡住——同時要求一個節點做兩件事，本質上就是這種問題。拆分之後，節點可以專注單一角色、靈活排程、甚至使用專為 decode 優化的特殊硬體，也避免一個漫長的 prefill 拖慢所有 decode。Shams 觀察到，約六個月前這些做法還爭論不休，如今業界已大致收斂到「遠端快取感知放置、prefill 與 decode 拆分、KV 狀態可遷移」這條路線上。
對一般使用者而言，這場演講同樣有實用啟示：每個 token 都是需要有人承載的狀態，客戶端快取命中通常能換到約九成的價格折扣，因此提示詞應盡量精簡、避免無謂的冗詞，把次要任務交給子代理或獨立視窗執行，避免稀釋前綴快取的上下文。隨著推理堆疊逐漸像資料庫一樣普及化，理解 KV cache 這個隱藏的運作機制，未來幾年會變得越來越重要。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。