KV Cache 工程實務：LLM 推論的隱形引擎

當我們談論 LLM 的速度時，大多數人想到的是「每秒 token 數」。但真正的戰役並非發生在生成階段，而是在 KV Cache。如果你曾好奇為什麼長對話會讓 AI 變得遲鈍，或是為什麼「上下文視窗」如此昂貴，你面對的正是 KV Cache 的問題。

核心問題：冗餘計算

在 Transformer 模型中，每個新生成的 token 都需要關注所有先前的 token。如果沒有快取，模型每次產生新 token 時，都必須重新計算歷史中每一個 token 的 Key (K) 和 Value (V) 向量。對於一個 1000 個 token 的提示詞（prompt），生成第 1001 個 token 就需要進行 1000 次冗餘計算。這是最糟糕情況下的 O(n²) 複雜度。

什麼是 KV Cache？

KV Caching 本質上是一種針對注意力機制的「記憶化」（memoization）策略。一旦模型在預填充階段（處理提示詞時）計算出某個 token 的 K 和 V 向量，就會將它們儲存在 GPU 記憶體中。當生成下一個 token 時，它僅計算該單一新 token 的 K 和 V，並從快取中檢索其餘部分。

記憶體牆

這裡開始變得棘手。KV cache 的體積非常龐大。以 Llama-3-70B 模型為例，快取大小會隨著序列長度和批次大小線性增長。在高併發情況下，瓶頸不在於運算能力不足，而是 VRAM 耗盡。這道「記憶體牆」正是我們看到以下技術的原因：

• 多查詢注意力機制（MQA）： 讓所有查詢頭共享同一組 K 和 V 頭，將快取大小減少 8 倍以上。
• 分組查詢注意力機制（GQA）： Llama-3 採用的折衷方案，在品質與記憶體效率之間取得平衡。
• PagedAttention（vLLM）： 將 GPU 記憶體視為虛擬 RAM，允許 KV 區塊非連續儲存，以消除記憶體碎片。

實務建議

對於建構 RAG 系統或長上下文代理程式的開發者來說：請記住，你的「上下文視窗」不僅限制了模型能「看見」的內容，更直接佔用你的 GPU 記憶體。最佳化提示詞長度不只是為了成本考量，更是為了維持推論吞吐量。