KV Cache 是什麼？AI 工程師如何努力解決記憶體瓶頸，提升推理效率

更新於 2025/08/23發佈於 2025/08/23閱讀時間約 11 分鐘

當我們與任何大型語言模型 (LLM) 互動時，流暢、即時的文字生成速度背後其實隱藏著一道巨大的技術挑戰。模型的每一次回覆，都是一場與時間和硬體限制的賽跑。而這場賽跑的決勝關鍵，就藏在所有 AI 工程師都必須面對的核心技術：「KV Cache」。

KV Cache 不只是快取。它是 LLM 推理（Inference）效率的心臟，也是限制模型處理長篇文章、對話的根本瓶頸。當模型需要處理的上下文越長，KV Cache 佔用的 GPU 記憶體就越多，最終會成為壓垮系統效能的稻草。理解 KV Cache 的運作原理與優化策略，就等於掌握了衡量一個 LLM 服務能否做到「又快、又長、又便宜」的關鍵指標。

什麼是 KV Cache？LLM 推理的「短期記憶」

要理解 KV Cache，必須先說明一下 LLM 的基本技術：自注意力機制 (Self-Attention)。

從注意力機制說起：Q、K、V 的角色

想像一下，模型在寫作時，就像一位作家，需要不斷回顧前面寫過的段落，才能確保文意通順、邏輯一致。這個「回顧」的動作，在模型中就是透過「自注意力機制」來完成。

對於每一個即將生成的新字 (token)，模型會把它看作一個「查詢」(Query, Q)，然後去檢視前面所有已經存在的字。每個舊字都帶有兩個屬性：一個是供查詢配對的「鑰匙」(Key, K)，另一個是它實際代表的「內容值」(Value, V)。

簡化流程如下：

提出查詢 (Q)：當模型要生成第 100 個字時，它會產生一個代表「我現在是誰？我需要什麼資訊？」的 Q 向量。
匹配鑰匙 (K)：模型會拿這個 Q 向量，去跟前面 1 到 99 個字的所有 K 向量做計算，找出哪些舊字跟現在的「查詢」最相關。
提取內容 (V)：根據上一步的相關性分數，模型會按比例提取前面所有字的 V 向量，加權平均後得到一個包含完整上下文資訊的向量，用來決定第 100 個字應該是什麼。

如果沒有 KV Cache，會發生什麼？

LLM 的文字生成過程是「自回歸 (auto-regressive)」的，也就是一個字接著一個字產生。問題來了：當模型要生成第 101 個字時，它需要參考前面 1 到 100 個字。如果按照原始的注意力機制，它必須重新計算第 1 到 100 個字的所有 K 和 V 向量。

這會導致大量的重複計算。在生成第 100 個字時，第 1 到 99 個字的 K、V 向量就已經算過一次了。現在為了第 101 個字，又要再全部重算一遍，造成了巨大的效能浪費。如果生成一千個字，這種浪費會放大到令人難以接受的程度。

KV Cache 的核心思想：避免重複計算

為了解決這個問題，KV Cache 的概念非常直接：算過一次的 K 和 V 向量，就把它們存起來，下次直接用，不要重算。

KV Cache 就是一個專門的記憶體空間，用來存放所有已生成 token 的 Key 和 Value 向量。運作方式變成：

預填 (Prefill)：當你輸入一段提示詞 (Prompt) 時，模型會一次性算完這段話裡所有 token 的 K、V 向量，並全部存入 KV Cache。
解碼 (Decode)：接著，每生成一個新 token，模型只需要

為這個新 token 計算它自己的 Q、K、V 向量。
拿新 token 的 Q，去跟 KV Cache 中所有已存在的 K 向量做匹配。
根據匹配結果，提取 KV Cache 中所有已存在的 V 向量來生成結果
最後，把這個新 token 自己的 K、V 向量也附加到 KV Cache 的末端，供下一次生成使用。

透過這種方式，模型從「每次都重頭複習全文」，變成「只讀一次舊筆記，然後寫下新筆記」。這就是 KV Cache 的價值，也是讓 LLM 能夠快速回應的關鍵。

KV Cache 的挑戰：記憶體瓶頸

效能關鍵：從平方級到線性級的轉變

在演算法複雜度上，標準注意力機制的計算量與序列長度平方成正比，這代表上下文長度變成兩倍，計算量會變成四倍。

有了 KV Cache，在解碼階段，每次都只需要處理當前這一個新 token，其計算量與序列長度大致呈線性關係。這個從平方級到線性級的轉變，是 LLM 能否實用化的分水嶺。沒有 KV Cache，現在所體驗到的流暢對話將難以實現。

記憶體挑戰：長上下文的隱形成本

可是天下沒有白吃的午餐，KV Cache 用記憶體空間換取了計算時間，這個「短期記憶」的大小，會隨著上下文長度線性增長。

一個 token 的 K、V 向量需要佔用多少空間？這取決於模型的層數、注意力頭數和維度。一個看似簡單的設定，在長序列下依然會累積成驚人的數字。例如，在一個常見的 Llama 7B 模型設定下，處理 4096 個 token 的上下文，KV Cache 就需要佔用約 2GB 的 GPU VRAM。這帶來兩個的問題：

記憶體容量瓶頸：GPU 的 VRAM 非常昂貴且有限。當 KV Cache 佔滿 VRAM 時，模型就無法再處理更長的上下文，這也是為什麼許多服務都有輸入長度限制的原因。
記憶體頻寬瓶頸：在解碼的每一步，GPU 都需要從 VRAM 中讀取完整的 KV Cache，並寫入新的 K、V 向量。當 Cache 變得非常大時，資料傳輸的時間甚至會超過實際計算的時間，這就是所謂的「記憶體頻寬瓶頸 (Memory-bound)」。

因此，整個 AI 工程界的焦點，逐漸從單純追求更快的計算速度 (FLOPs)，轉向如何更聰明地管理和優化 KV Cache。

如何優化 KV Cache？三大策略解析

為了解決 KV Cache 帶來的挑戰，業界發展出了三大策略：從源頭減量、將數據壓縮，以及更智慧地調度。

策略一：直接減量 (GQA/MQA 與滑動窗口)

最直接的方法，就是讓需要存的東西變少，例如：

分組查詢注意力 (Grouped-Query Attention, GQA)：在標準的多頭注意力 (MHA) 中，每個 Query 頭都有一對專屬的 K、V 頭。GQA 則讓多個 Query 頭「共享」同一組 K、V 頭。這麼做，需要快取的 K、V 數量就等比例下降。
多查詢注意力 (Multi-Query Attention, MQA)：讓所有的 Query 頭共享唯一的一組 K、V 頭。這能最大程度地減少 KV Cache 的大小，但可能稍微影響模型品質。
滑動窗口注意力 (Sliding Window Attention, SWA)：與其儲存從頭到尾所有的歷史紀錄，SWA 只保留最近的 N 個 token 的 KV 快取。例如，只記住最近 4096 個字的內容，更早的就直接丟棄。這讓模型能用固定的記憶體處理無限長的文本。

策略二：壓縮儲存 (INT8/INT4 量化)

如果不能減少數量，那就把每個東西變得更小。傳統上，KV Cache 中的數字是以 16 位元浮點數 (FP16) 儲存的。KV Cache 量化技術，則是將這些數字用更低的位元數來表示，例如 8 位元整數 (INT8) 或 4 位元整數 (INT4)，當然這麼做，也可能影響模型品質。

FP16 → INT8：記憶體用量直接減半。
FP16 → INT4：記憶體用量變為原來的四分之一。

策略三：智慧調度 (PagedAttention 與 Offloading)

除了減少和壓縮，更聰明的管理方式也能帶來巨大效益，例如：

分頁注意力 (PagedAttention)：由上次文章主題所介紹的 vLLM 專案提出，是目前最高效的 KV Cache 管理機制之一。傳統方法會為每個請求預留一塊連續的大記憶體，造成大量碎片和浪費。PagedAttention 借鏡作業系統的虛擬記憶體分頁技術，將 KV Cache 切分成許多固定大小的「區塊 (Block)」，並動態分配。這將記憶體利用率提升到極致 (浪費率低於 4%)，大幅提升系統吞吐量。
KV Offloading：當 VRAM 實在不夠用時，可以將比較不常用的、較舊的 KV Cache 內容「卸載」到速度較慢但容量更大的 CPU 記憶體，甚至是 NVMe 硬碟上。需要時再預先讀取回來。這是一種用延遲換取超長上下文能力的策略。

實務上，這些技術往往會被組合使用，從而實現效能最大化。

TN科技筆記的觀點

在 context engineering 越來越重要且受到關注的同時，LLM 每次處理使用者問題所能容納的上下文容量也成為關鍵競爭力。隨著各家 AI 大廠持續投入資源，嘗試訓練並推出能支援數十萬甚至百萬 token 的模型，如何在不影響模型精準度與回答能力的前提下，突破上下文長度所帶來的計算與記憶體瓶頸，將會是未來兵家必爭之地。

從技術面來看，KV Cache 的演進正是這場競賽的主題，雖然快取避免了大量重複計算，使得效能從平方級降到線性級，但代價是記憶體空間與頻寬的持續消耗。這也是為什麼上述減少需要快取的數量、捨棄過舊上下文、量化技術以及智慧資源調度會成為產業的焦點。這些方法的本質，都是在「保有上下文資訊」與「節省記憶體資源」之間找到平衡。

然而，所有優化策略都有其潛在代價：共享 KV 頭會減少注意力的多樣性，極低精度量化可能犧牲模型品質，而 Offloading 則會以延遲換取更長的上下文能力。這些取捨表示未來的解決方案是必須依照應用場景，甚至在推理過程中動態調整策略。

接下來可以想像，硬體與軟體的同時演進將成為決定性優勢。硬體層面，需要更快的記憶體頻寬與更大容量的 GPU/專用晶片來承載超長上下文；軟體層面，則需要更精緻的推理框架與排程機制來最大化資源利用率。誰能在「長上下文」與「高效能」之間找到最佳平衡，就更可能在下一波 LLM 商業化浪潮中掌握領先。