KV Cache 進階：從靜態快取到動態壓縮

在上一篇中我們討論了 KV Cache 的基本原理。但隨著上下文視窗從 32k 擴展到 1M 甚至更多，簡單的快取已經無法滿足需求。現在的核心矛盾是：模型需要記住所有歷史，但 GPU 記憶體無法承載所有歷史。

動態壓縮的必要性

如果一個對話有 10 萬個 token，KV Cache 將佔用數十 GB 的顯存。這意味著單卡只能服務極少數使用者。為了解決這個問題，工業界開始探索「選擇性遺忘」和「動態壓縮」。

核心技術路徑

1. H2O (Heavy Hitter Oracle)：
   研究發現，Attention Map 中只有極少數 token（Heavy Hitters）對最終結果有決定性影響。H2O 透過即時追蹤每個 token 的累積注意力權重，剔除那些貢獻度低的 KV 對，從而在不顯著降低精度的情況下將快取規模壓縮 5x-10x。

2. StreamingLLM (Attention Sink)：
   這是一個驚人的發現：模型在處理長文本時，前幾個 token（即使它們是無意義的空格或標點）承載了巨大的注意力權重（Attention Sinks）。StreamingLLM 透過保留最初的幾個 token + 最近的滑動視窗 token，實現了在固定記憶體下無限長度的串流式推論，且不會崩潰。

3. Quantized KV Cache (INT8/FP8)：
   將 KV Cache 從 FP16 量化到 INT8 或 FP8。這直接將記憶體佔用減半，且由於 KV Cache 對精度相對不敏感，效能損失幾乎可以忽略不計。

對架構設計的啟示

對於建構 AI 應用的開發者來說，這意味著我們不能再把 LLM 當作一個簡單的「黑盒 API」。當你設計長對話系統時，應該考慮：
- 關鍵資訊錨定：透過 Prompt 引導模型將重要資訊放在開頭（利用 Attention Sink）。
- 分段總結：不要依賴模型的原生長上下文，而是在應用層實現遞迴總結 $\rightarrow$ 更新上下文 $\rightarrow$ 清空快取的循環。

總結

KV Cache 的演進路徑是從「全量儲存」$\rightarrow$「高效組織 (PagedAttention)」$\rightarrow$「選擇性保留」。未來的趨勢是讓模型像人類一樣，擁有一個快速更新的短時記憶和一個經過壓縮的長時記憶。