KV Cache 優化：為什麼你的本地 AI 越跑越慢？

KV Cache 是什麼？為什麼它這麼佔顯存？

凌晨 1:46，監控面板上的顯存曲線像坐過山車。

Franky 在群裡丟了一句：「Qwen3.5 剛啟動時響應飛快，跑了半小時怎麼卡成 PPT？」

我盯著 Grafana 看了十分鐘，終於找到罪魁禍首——KV Cache 爆了。

說人話：KV Cache 就是大模型的「短期記憶」。

每次你跟模型對話，它都要記住前面說過的話。不然你問「剛才提到的那個技能怎麼安裝？」，模型一臉懵逼：「哪個技能？我剛才說了啥？」

Transformer 架構裡，每個 token 生成時都要計算 Query、Key、Value 三個矩陣。前面的 token 算過的 Key 和 Value，沒必要重複算——存起來複用就行。這就是 KV Cache。

但問題在於：KV Cache 會隨著對話長度線性增長。

顯存佔用 = 基礎模型權重 + KV Cache + 激活值
KV Cache 大小 ≈ 2 × 層數 × 頭數 × 頭維度 × 序列長度 × batch size × 精度字節數

拿 Qwen3.5-35B 舉例：層數 48，注意力頭數 40，頭維度 128，精度 FP16（2 字節）。跑個 32K 上下文，KV Cache 輕鬆吃掉 20GB 顯存。

我們踩過的三個坑

坑 1：無限制上下文 = 顯存爆炸

凌晨 3 點，小浣熊的 PMD 生成任務突然失敗。日誌顯示：CUDA out of memory。它把整個 PRD 歷史對話都塞進去了——128K tokens。KV Cache 直接撐爆 80GB A100。

解決方案：硬編碼上限，max_context_length: 16384。

坑 2：Batch 推理時的顯存陷阱

早間 9 點，三個 Agent 同時請求推理。每個都佔 20GB KV Cache，60GB 沒了。再加上模型權重 70GB，140GB 顯存直接告急。

坑 3：多輪對話不釋放緩存

監控腳本每 5 分鐘輪詢一次 Agent 狀態。一個月下來，累積了 8000+ 輪對話的緩存。

實戰優化方案

方案 1：分頁注意力（Paged Attention）

vLLM 的殺手鐧。把 KV Cache 切成固定大小的塊，像操作系統管理內存頁一樣管理。同樣 48GB 顯存，Paged Attention 能同時服務 8 個併發會話，傳統方式只能跑 3 個。

方案 2：KV Cache 量化

FP16 的 KV Cache 佔 2 字節/token。量化到 INT8，直接減半。精度損失幾乎感知不到，BLEU 分數差異小於 0.5%。

方案 3：滑動窗口注意力

對於代碼生成任務，最近 2K tokens 最重要。window_size: 4096，KV Cache 大小固定，不會隨對話增長。

SFD 編者註

今天凌晨的顯存告警，讓我們重新審視了「無限上下文」的代價。技術上能做到 128K，不代表應該用 128K。合適的上下文長度，比單純追求數字更重要。

現在我們的生產環境策略：代碼任務 8K，文檔寫作 16K，數據分析 32K，日常對話 4K。顯存是稀缺資源，要用在刀刃上。