什麼是 KV Cache？為什麼它會影響 LLM 推理速度
當使用者與大型語言模型對話時，模型通常會一個 Token 接著一個 Token 地生成回應。每當產生新的 Token，Transformer 都需要重新進行 Attention 的運算。如果模型每次都必須從頭計算先前所有的 Token，那麼隨著上下文越來越長，已經完成的運算將被反覆執行，推論效率自然會顯著下降。
KV Cache（Key-Value Cache，鍵值快取）正是為了減少這類重複運算而設計的快取機制。 它會將 Attention 中先前 Token 已經計算完成的 Key 和 Value 儲存下來，讓模型在生成下一個 Token 時能直接重用，而不必重新計算整個歷史序列。
因此，KV Cache 已成為現代 LLM 推論中的關鍵技術之一。它能顯著提升自回歸文本生成的效率，但也會佔用大量記憶體或 GPU 顯存。上下文越長、並發請求越多，所需儲存的 KV Cache 也通常越大，這使它成為影響 LLM 延遲、吞吐量與推論基礎設施設計的重要因素。
什麼是 KV Cache？
KV Cache 是 Transformer 推論過程中用於快取 Attention Key 和 Value 的機制。其主要目的是儲存先前 Token 已經完成的 Attention 部分運算結果，讓模型在生成後續 Token 時能直接重用這些結果。
在 Transformer 的 Attention 機制中，每個 Token 的隱藏表示會被用來產生三組向量：
- Query（Q）：當前 Token 想要查找的資訊
- Key（K）：已有 Token 提供的可比對資訊
- Value（V）：比對後實際用來完成輸出的資訊
當 LLM 生成下一個 Token 時，新的 Query 會與先前 Token 的 Keys 進行 Attention 運算，並根據計算結果取出相符的 Values。
關鍵的問題在於：先前 Token 的 Key 和 Value 其實於生成過程中早已計算完成，而且不會因為新 Token 出現就必須從頭再算一遍。
KV Cache 正是把這些 K 與 V 快取下來。當新 Token 出現時，模型只需要運算新 Token 對應的 Q、K 和 V，並將新的 K、V 加入快取，就能運用過去儲存的 KV 持續進行 Attention。
為什麼沒有 KV Cache 時 LLM 會產生大量重複運算？
想理解 KV Cache 的價值，可以觀察一個簡化的文本生成過程。
假設 Prompt 是：
AI models can
模型首先處理這三個 Token，並預測出：
generate
此時上下文成為：
AI models can generate
模型接下來需要預測第五個 Token。如果沒有 KV Cache，它可能得重新處理前面的「AI models can generate」，再次計算歷史 Token 在各層 Attention 的 Key 和 Value。
假設下一步產生「text」，上下文又繼續變長：
AI models can generate text
如果持續從頭處理，已多次計算過的歷史 Token 又會重複進行 K/V 投影運算。
隨著輸出長度成長，這種重複作業只會越來越多。
KV Cache 改變了這個流程。第一次處理「AI models can」時，模型便已經將這些 Token 的 Key 和 Value 儲存下來。生成「generate」後，只需計算此新 Token 的相關表示並加入快取；產生「text」時，也只需將新的 K 和 V 追加快取即可。
因此，KV Cache 的核心不在於讓模型「少看歷史上下文」，而是：
讓模型完整參考歷史上下文，同時避免重複計算歷史 Token 已經得到的 Key 和 Value。
KV Cache 是如何運作的？
KV Cache 與 Transformer 的 Self-Attention 密不可分。
在自回歸的 Decoder 中，每個新 Token 都需要根據現有上下文預測下一個 Token。假設模型已處理四個 Token：
T1 → T2 → T3 → T4
Attention 已生成這些 Token 的 Key 和 Value。KV Cache 會儲存：
K1, V1K2, V2K3, V3K4, V4
當新的 T5 進入模型時，就不必再重新計算 T1 到 T4 的 K 和 V。模型只需計算：
Q5, K5, V5
再讓 Q5 與快取中的 K1–K4 及新的 K5 執行 Attention 運算，並透過對應的 Value 得到新的 Attention 輸出。
接下來：
K5, V5
也會被加入 KV Cache，為 T6 的生成預作準備。
全流程可再簡化成：
歷史 Token → 快取 K/V
新 Token → 新 Q/K/V → 與快取 K/V 執行 Attention → 產生下一 Token → 新 K/V 加入快取
這樣的過程會發生在含有 KV Cache 的 Transformer Attention Layer，因此對於堆疊多層結構的大型語言模型而言，KV Cache 本身有時也會佔用相當可觀的記憶體空間。
Prefill 與 Decode 階段有什麼不同？
LLM 推論通常可分為兩個非常重要的階段：Prefill（預填充）和 Decode（解碼生成）。弄清這兩個階段，就能更理解 KV Cache 的作用。
假設用戶提交了一個包含 2,000 個 Token 的 Prompt。
在 Prefill 階段，模型需要處理這 2,000 個輸入 Token，計算它們彼此之間的 Attention，順便建立後續生成所需的 KV Cache。由於 Prompt 內容已齊全，這階段常可善用 GPU 的平行運算能力一次批次處理。
Prefill 完成後，模型才會開始產生回答，進入 Decode 階段。
Decode 階段屬於自回歸流程：每生成一個 Token，再接著產生下一個 Token。此時 KV Cache 的效益開始發揮，因為歷史 Token 的 K/V 已快取，新 Token 可直接運用這些內容進行 Attention，不需重算所有歷史計算。
因此，用戶感受到的 LLM 延遲也可切分為下表兩個常見指標：
| 指標 | 意義 | 主要受哪些因素影響 |
|---|---|---|
| TTFT | Time to First Token，首 Token 延遲 | Prompt 長度、Prefill 運算等 |
| TPOT | Time per Output Token，每個輸出 Token 所需時間 | Decode、KV Cache、硬體效能等 |
若 Prompt 特別長，用戶可能等更久才會看到第一個 Token；進入 Decode 後，KV Cache 的管理效率則會直接影響後續 Token 生成的速度與系統吞吐量。
為什麼 KV Cache 能提升 LLM 推論速度？
KV Cache 的主要效益即在於避免重複執行歷史 Token 的 K/V 投影運算。
對自回歸 LLM 而言，歷史上下文會隨新 Token 不斷累加。如果沒有快取機制，每個步驟都要重算全部的歷史表示，會產生大量重複動作。
KV Cache 把已算過的 Key 及 Value 留下來，讓每次解碼（Decode Step）只需專注處理新 Token，並重用過去的 Attention 狀態。
這對長文本生成尤為關鍵。當只輸出幾個 Token 時，快取優勢不太明顯；但當模型需連續產生數百、數千 Token，歷史上下文愈拉愈長，避免重複運算的效益也就越大。
不過，KV Cache 並不代表 Attention「與上下文長度無關」。新 Token 的 Query 仍需與愈來愈多的歷史 Key 執行 Attention，並取出對應 Value。因此，上下文增加依舊會拉高計算與記憶體取用負載。
KV Cache 最優化的是避免重複計算，但無法消除長上下文本身的成本。
為什麼 KV Cache 會佔用大量 GPU 顯存？
KV Cache 最大的代價是記憶體佔用。
模型必須把所有已處理過的 Token 的 Key 和 Value 保留下來，而且這些快取資料會存在多個 Transformer Layer。KV Cache 的大小會受多種因素影響，包括模型層數、KV Head 數、Head 維度、數據精度、上下文長度、並發請求數等等。
最直觀的關係如下：
上下文越長 → 需快取的 Token 越多 → KV Cache 越大。
如果單一用戶只有數百個 Token 上下文，KV Cache 需求還小；但如果擴展到幾萬甚至更長，快取規模就會激增。
並發情境會放大此問題。推論伺服器常得同時處理多位用戶，每個生成請求都需要維護自己的 KV Cache。若同時有大量長上下文請求，顯存很快就會被快取塞滿。
因此，在 LLM 服務（Serving）部署裡，GPU 顯存不僅要存放模型權重，還必須預留 KV Cache、中間運算結果與 Batch 等空間。這也就是為什麼「模型可裝進 GPU」不代表「這張 GPU 就能高吞吐量服務大量用戶」。
上下文長度為何會影響 KV Cache？
Context Window（上下文視窗）和 KV Cache 之間息息相關，因為模型需快取目前有效上下文中各 Token 的 K/V 狀態。
假使模型已處理 1,000 個 Token，KV Cache 就需保留這些 Token 的相關狀態；當上下文漲到 10,000 個 Token，維護的數據量也會顯著增加。
這帶來兩個影響。
首先是顯存壓力加大。Context Window 越長，單一請求可能佔用更多快取空間，因此相同硬體可同時服務的請求數會下降。
其次則是記憶體存取與 Attention 運算增多。當要生成新 Token 時，需存取的 K/V 序列會拉長，因此即使歷史 K/V 無須重算，過長上下文還是可能拖慢 Decode 效率。
所以，模型標榜支援 128K 甚至更長 Context Window，並不意味著用超長上下文就沒有成本。最大上下文能力與實際推論效率是兩碼子事。
MHA、MQA 和 GQA 為什麼會影響 KV Cache 大小？
為壓低 KV Cache 成本，現代 Transformer 發展出不同 Attention 設計，常見方案有 MHA、MQA 與 GQA。
傳統的 Multi-Head Attention（MHA）會為不同 Attention Head 保留獨立的 Key 和 Value，因此 KV Cache 需求大。
Multi-Query Attention（MQA）則讓多個 Query Head 共用一組 Key 和 Value，大幅減少必須快取的 K/V 數量。Grouped-Query Attention（GQA）則介於兩者之間，讓一組 Query Head 共用 K/V，兼顧模型性能與快取效率。
| Attention 類型 | K/V 結構 | KV Cache 特徵 |
|---|---|---|
| MHA | 每個 Query Head 通常有對應 K/V Head | 快取較大 |
| GQA | 多個 Query Head 共用一組 K/V Head | 快取明顯降低 |
| MQA | 所有 Query Head 共用極少 K/V Head | 快取進一步縮減 |
這也是為什麼分析現代 LLM 推論效率時，不能只看模型參數量。即便兩個模型規模接近，如果採用不同的 Attention 架構，KV Cache 對顯存的需求可能差很多。
KV Cache 與 Batch Size、吞吐量有什麼關連？
對 AI 服務供應商來說，KV Cache 不只會影響單一用戶的生成速度，更直接關係到整個推論系統可同時服務多少個請求。
GPU 顯存有限。模型權重佔去一部分空間後，剩下的顯存必須給 KV Cache 和其餘執行資料。如果單一請求所需的 KV Cache 越大，那麼同一張 GPU 能接納的同時請求數也會減少。
這會直接牽動 Batch Size（批次規模）。較大的 Batch 有助提升 GPU 使用率與總吞吐量，但前提是顯存得能同時裝下這些請求的 KV Cache。
因此，LLM Serving 必須多方權衡：
長上下文、並發用戶數、Batch Size、延遲、吞吐量與顯存運用
這也就是為什麼現代推論框架會特別優化 KV Cache 管理，例如減少記憶體碎片、動態分配快取空間、重用共用前綴，以及以較低精度存儲 KV 等。
KV Cache 與 Prompt Caching 是同一回事嗎？
並非如此。二者都有「快取」之名，但快取的物件和層級不同。
KV Cache 主要是模型推論過程中的內部快取，用來儲存 Attention 已運算出的 Key 和 Value，藉此加速單次生成過程的後續 Token 計算。
Prompt Caching 則通常是針對多個請求中共用的 Prompt 或前綴，重複利用其運算結果。例如，大量請求都含有相同的 System Prompt，推論平臺可複用這部份前綴對應的快取，而不用每個請求都從頭做一遍 Prefill。
簡單比較如下：
| 對比 | KV Cache | Prompt Caching |
|---|---|---|
| 快取物件 | Attention 的 Key / Value | 重複 Prompt / 前綴的運算結果 |
| 主要用途 | 加速當前序列的 Decode 流程 | 降低共用 Prompt 的 Prefill 成本 |
| 使用場景 | 幾乎所有自回歸生成 | 存在重複前綴的請求 |
| 影響 | Token 生成速度與顯存配置 | TTFT、運算量以及服務成本 |
Prompt Caching 的底層有可能運用或共用 KV 狀態，但就用戶和系統設計來看，兩者解決的問題並不盡相同。
KV Cache 與 LLM 推論優化有什麼關係？
KV Cache 是 LLM Inference Optimization（推論優化）中極為基礎的一環，但現代推論系統不只依賴單一技術。
除了 KV Cache 之外，推論系統還會採用像 Continuous Batching、Paged Attention、KV Cache Quantization、Prefix Caching 和 Speculative Decoding 等多種方法，提升吞吐或降低延遲。
這些技術目標各有側重。例如 Paged Attention 重點優化 KV Cache 的記憶體管理，KV Cache Quantization 則降低快取精度來減少顯存消耗，而 Speculative Decoding 嘗試降低產生多個 Token 所需的序列推論成本。
因此，如今 LLM 推論優化的核心問題不只是「模型計算多快」，更包含如何管理顯存、調度請求，並讓有限 GPU 資源同時服務更多 Token 與用戶。
KV Cache 正是這些問題的交匯核心，因此是理解 AI 推論基礎設施必備的觀念之一。
總結
KV Cache（Key-Value Cache，鍵值快取）是 Transformer 大型語言模型推論中不可或缺的快取機制。它把歷史 Token 已於 Attention 運算所得的 Key 與 Value 快取起來，讓 Decoder 產生新 Token 時能直接重用，不必一再計算整個上下文的 K/V。
這使得 KV Cache 成為提升自回歸 LLM 推論效率的重要技術。不過，快取本身並非零成本：上下文愈長、模型層數愈多、KV Head 愈多、並發請求愈高，佔用的內存自然也會增加。
因此，KV Cache 正好連結了 LLM 推論的兩大核心：速度與顯存。它減少重複運算、提升解碼效率，同時也可能成為長上下文與高並發服務時最主要的顯存消耗來源。
理解 KV Cache，也能進一步闡明為什麼現代 AI 推論系統會發展 GQA、MQA、Paged Attention、Prefix Caching 與 KV Cache Quantization 等技術。這些優化本質上都在解決同一個難題：如何讓大型語言模型在有限計算與內存條件下，更高效地生成 Token。
FAQ
KV Cache 會改變 LLM 生成的回應嗎？
一般情況下不會。KV Cache 主要重用已計算的 Attention Key 和 Value，屬於效率優化機制，並不會動搖模型本身的參數。
關閉 KV Cache 後 LLM 還能生成文本嗎？
可以，但自回歸生成通常會導致更多重複運算，特別在長文本生成時效率顯著下降。
KV Cache 會一直增長嗎？
同一生成請求中，隨上下文 Token 增加，KV Cache 理論上會逐步膨脹，直到達到上下文上限、請求終止，或系統採用相關快取管理策略為止。
為什麼長上下文模型更該重視 KV Cache？
因為更長上下文意味著必須快取更多 Token 的 Key 和 Value，產生新 Token 時又得訪問更長的快取序列，因此顯存占用與存取壓力皆大增。
KV Cache 於模型訓練時也必須啟用嗎？
KV Cache 的主要貢獻在自回歸推論階段。訓練時通常能平行處理整個序列，其算圖模式不同於逐 Token 解碼，通常不會像推論時一樣依賴 KV Cache。
