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。显存是稀缺资源，要用在刀刃上。