KV Cache 是什麼？AI Agent 的長期記憶，正在吃掉更多 SSD 與 DRAM

為什麼 AI 需要快取前文？

Transformer 在推理時要參考先前 token 的注意力資訊。如果每生成一個新 token 都重新計算全部歷史，序列愈長，浪費的運算愈大。KV Cache 把已計算的 Key 與 Value 保存下來，讓下一步直接重用。

這個機制用容量換速度。單一短對話不明顯，但當上下文變長、使用者增加、Agent 需要記住工具結果與中間步驟，KV Cache 會隨序列與併發規模擴張。快取命中率、保存時間與可否跨服務共享，開始直接影響每個 token 的成本。

因此 AI Agent 的『記憶』不只是軟體功能，也是一張硬體帳單。模型愈會長時間工作，就愈需要設計快取生命週期與儲存階層。

從 G1 到 G4：愈往下，容量愈大、延遲愈高

報告整理的階層由 GPU HBM（G1）、系統 DRAM（G2）、本地 SSD（G3）到共享物件／檔案儲存（G4）。HBM 是納秒級、最適合活躍快取，但容量昂貴；DRAM 與 SSD 提供更大空間，延遲與能源成本也逐層增加；共享儲存適合低頻與持久資料。

問題出在 G3 與 G4 之間：本地 SSD 容量有限，共享儲存延遲太高。NVIDIA 以 BlueField-4 DPU 建立專用上下文記憶層 G3.5，讓 4 顆 DPU 管理 150TB 記憶池並直連 GPU。報告指出，這種設計可讓每顆 GPU 額外取得 16TB 上下文空間。

最具體的需求變化是，單機櫃 NAND 配置可能由 830TB 上升到接近 2PB。AI 推理對 NAND 的價值，正從資料保存延伸到上下文記憶基礎設施。

這個題材要怎麼驗證？

首先看平台是否正式量產，以及機櫃配置是否從參考設計變成客戶採購。其次看企業級 SSD 的容量、介面、主控與韌體規格，能否承受高頻讀取、可預測延遲與資料共享。

第三要看軟體是否把快取分層做好。若模型壓縮、快取量化、稀疏注意力或更有效的上下文管理大幅降低容量，需求成長可能低於硬體線性外推。KV Cache 是重要增量，但估算必須跟模型架構與推理軟體一起更新。

• 容量：上下文長度、併發 token 與保存時間。
• 效率：快取命中率、量化、壓縮與淘汰策略。
• 硬體：HBM、DRAM、SSD 與共享儲存的成本曲線。
• 落地：平台量產、客戶採用與企業級認證。

KV Cache 的容量，不是用模型參數一個數字就能算完

快取需求至少受到模型層數、注意力頭、Key／Value 維度、資料精度、序列長度與同時服務的使用者數影響。MoE 可以降低每次運算啟用的參數，GQA、量化與壓縮也能減少快取；但更長上下文、更多 Agent 和更高併發又會把節省的容量吃回去。因此任何 PB 級估算都必須附上情境。

軟體營運方式同樣重要。一次性問答可以在完成後釋放快取，長時間工作的 Agent 卻可能保留工具輸出、文件片段與多輪狀態。服務商還要決定不同使用者能否共享前綴快取、哪些內容需要持久保存，以及快取未命中時重新計算是否比搬移資料便宜。

資安與隱私也會影響架構。KV Cache 可能含有使用者上下文與企業資料，不能只追求最大共享率；租戶隔離、加密、刪除與保存期限會增加管理成本。這代表上下文記憶層不是單純購買更多 SSD，還需要 DPU、軟體調度與治理機制。

從產業角度看，最可靠的需求訊號不是『Agent 很熱門』，而是推理平台公開的每 token 成本、上下文長度、快取命中率、企業級 SSD 配置與實際採購量。當軟體效率提升仍追不上推理使用量成長，DRAM 與 NAND 的增量才會持續轉成可見訂單。

對企業導入而言，還要區分短期工作記憶與真正的長期知識。KV Cache 儲存模型推理中可重用的注意力資訊，向量資料庫與文件系統則保存可檢索知識；兩者都會使用儲存資源，但讀寫模式、保存時間與軟體堆疊不同。把所有『AI 記憶』都算成同一種 SSD 需求，會重複估算。

最後，容量估算應以尖峰併發而非平均流量設計，否則熱門事件一來就會把 HBM 與 DRAM 擠滿；但為尖峰永久配置昂貴記憶體又會降低利用率。業者會在延遲目標、快取淘汰、跨節點共享與重新計算之間取捨。這些營運策略決定新增需求落在 HBM、DRAM 還是 SSD，也決定硬體採購是否真的隨 token 用量等比例成長。