5 個 llama.cpp 的 KV cache 重點
5 個重點帶你看懂 llama.cpp 的 KV cache 壓縮、記憶體節省與效能取捨，判斷該追新方法還是先用現有格式。
這篇整理 5 個 llama.cpp 的 KV cache 重點，幫你判斷記憶體省多少、速度會怎麼變，以及現在該不該改用新格式。
如果你正在調 long context 推論，這 5 點可以直接幫你決定三件事：要不要追 TurboQuant、現有 q4_0 或 q8_0 值不值得先上、以及該怎麼量測才不會看錯結果。對做模型部署的人來說，KV cache 不只是技術細節，而是會直接影響能不能把上下文塞進顯存。
| 項目 | KV 緩衝區 | 相對 f16 節省 | 110K 生成速度 |
|---|---|---|---|
| f16 | 768 MiB | 基準 | 38.0 tok/s |
| q8_0 | 408 MiB | 47% | 未提供 |
| q4_0 | 216 MiB | 72% | 24.0 tok/s |
| TurboQuant | 低於 3 bits／值 | 目標更高 | 近零精度損失 |
1. TurboQuant 可能把 KV cache 壓得更小
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Google Research 的 TurboQuant 主打的是把 KV cache 壓縮到 3 bits 以下，還盡量維持接近零的準確率損失。這件事重要，是因為長上下文推論最常卡住的地方，往往不是算力，而是記憶體。
如果這個結果能穩定落地，llama.cpp 這類推論框架就可能在同樣顯存下保留更多上下文，對多輪對話、文件摘要、程式碼助理都很有幫助。
- 目標：每個 KV 值低於 3 bits
- 主張：精度損失接近零
- 意義：降低長上下文的記憶體壓力
2. 現有量化格式已經能省下很多記憶體
就算不等新方法，llama.cpp 討論串裡的修正數據也已經很有參考價值。在 DGX Spark GB10 測試中，f16 的 KV 緩衝區是 768 MiB，q8_0 變成 408 MiB，q4_0 則降到 216 MiB。
這代表 KV cache 量化不是理論上的小優化，而是能直接改變工作負載能否跑得動。對顯存有限的機器來說，q4_0 和 q8_0 的差別，常常就是長上下文能不能進服務。
- f16：768 MiB
- q8_0：408 MiB，約省 47%
- q4_0：216 MiB，約省 72%
3. 生成速度和提示詞速度不一定一起變
一個很關鍵的修正是：在 110K context 下，提示詞處理速度其實沒有因為 cache 類型而改變。這提醒我們，prefill 和 decode 是兩個不同階段，不能把它們混成同一個指標來看。
真正拉開差距的是生成階段。修正後的測試顯示，q4_0 在 110K context 的生成速度比 f16 慢 36.8%。社群的解讀是，每 token 的反量化成本成了瓶頸，這也正是 TurboQuant 想處理的地方。
110K context 生成速度（修正後）
f16 = 38.0 tok/s
q4_0 = 24.0 tok/s
差異 = -36.8%4. 社群已經開始做不同實作分支
這件事不是只有論文熱度。討論裡已經出現 TheTom 的 llama-cpp-turboquant 分支，也有人提到 NVIDIA 的 KTVC、MLX 開發者關注，以及 CUDA、HIP/ROCm 和 prefill 優化等不同路線。
這表示 KV cache 不是單一答案，而是一串實作選擇。對想看生產可用性的人來說，重點已經從「有沒有方法」變成「哪條路線先成熟、哪個 block size 比較穩、哪個分支比較少 bug」。
- Google Research 先提出 TurboQuant
- llama.cpp 討論串開始驗證實作可行性
- 社群分支已在測 CUDA、ROCm、prefill 優化
5. 量測方法會直接影響你怎麼解讀結果
討論串裡有一個很實用的教訓：一開始有人以為提示詞吞吐量大幅崩掉，後來才修正為量測方式有誤。真正的問題不是速度指標本身，而是用了 RSS 這種不夠準的記憶體來源。
如果你自己要測 TurboQuant、q4_0 或其他 cache 格式，務必要把 GPU 記憶體、prefill、decode 分開看，還要確認失敗請求沒有被算進吞吐量。否則很容易把量化效果看反。
- 記憶體請同時看 nvidia-smi 與內部 KV 緩衝區
- prefill 和 decode 要分開量
- 吞吐量要排除失敗請求
怎麼挑
如果你現在最在意的是長上下文能不能塞進顯存，先看 q4_0 和 q8_0 這種現成格式最實際，因為它們已經有明確的省記憶體效果。若你是在做前瞻評估，TurboQuant 值得追蹤，因為它有機會把 KV cache 再往下壓一階。
如果你的工作是維護推論服務或寫 benchmark，最重要的不是只看單一速度數字，而是先定義你要解決的是記憶體、提示詞速度，還是生成速度。KV cache 的選擇，最後都要回到你的瓶頸在哪裡。