KV Cache 为什么吃光了显存
KV Cache 为什么吃光了显存
一行公式看清显存去哪了
KV Cache 并不是什么新概念，它就是 transformer 在逐 token 解码时为每一层缓存下来的 Key 和 Value 矩阵。真正麻烦的是它随序列长度线性增长，上下文越长，缓存越大，而且它和模型权重争的是同一块显存。粗略估算每 token 的缓存量，公式是二乘以层数、再乘 KV 头数、乘头维度、乘元素字节数。以七十 B 级别的 GQA 模型为例，八十层、八个 KV 头、头维度一百二十八、用 BF16 存储，每 token 大约零点三二 MB。
这意味着十万 token 的上下文就要三十二 GB 左右，二十万上下文直接逼近六十四 GB。一块 H100 的八十 GB 显存，权重占掉一大半后，留给缓存的余量根本撑不住长会话。H200 提到一百四十一 GB、B200 到一百九十二 GB，可七十 B 模型光权重就接近一百四十 GB，缓存空间依旧紧巴巴，更别说再叠加批处理的多个请求。
为什么它特别难管
显存不像普通内存可以随意换出，GPU 计算又对延迟极其敏感。请求来了又走，缓存不断膨胀收缩，传统连续分配会留下百分之二十到四十的碎片，这部分空间既放不下新请求，又不能还给系统。很多人以为显存不够是模型太大，其实在长上下文场景下，真正压垮显存的是这些按 token 累积的缓存，而不是权重本身。
解码阶段本身是内存带宽受限的：每生成一个新 token，都要把整段 KV 读一遍来做注意力计算，显存带宽一旦被缓存占满，生成速度就掉。一旦缓存放不下，要么降低并发，要么截短上下文，两者都在牺牲吞吐或体验。也正因如此，把这部分数据搬去别处，比如内存、固态盘、甚至远端节点，才成了这两年推理系统里最热闹的方向。
当主机 DRAM 开始扛起这些热缓存数据，单条内存就不再是单纯的容量问题。一个在临界温度才暴露的位翻转，就足以让某段缓存悄悄出错，污染后续所有依赖它的生成结果，而且不会立刻报错。HeroTEST 提供模块级 DDR5 RDIMM 宽温测试与可信分级，包含余量测试与高温老化，用真实工况验证模块表现，欢迎联系我们了解测试方案。