KV 缓存的显存账是怎么算的？一文拆账

AI 模型回答长文时为什么越答越慢、显存越吃越紧？很多时候账要算在 KV 缓存头上。它是推理时留下的一份「草稿」，专门用来避免重复计算，对话越长这份草稿越厚，显存自然越吃越紧。

先弄懂缓存里存了什么

模型每生成一个新字，都要回看前面所有内容。如果每生成一个字都把前文全部重算一遍，长对话的代价会大得无法接受。于是推理时把每个字的两种中间结果——K 和 V——记下来，下一个字直接查表复用。这就是 KV 缓存：一份随对话增长而增长的中间记录。

类比抄写员抄长卷宗：每写一笔都要回看前文，聪明的做法是把看过的要点先摘录在便签上，写新内容时翻便签就行。便签越积越多，桌面越来越挤——这正是缓存吃显存的画面。

显存账逐项拆开算

这份账由三个乘数决定：每个字记多少、记多少层、前文有多长。层数和每字的记录宽度由模型结构定死，用户能左右的主要是第三项——上下文长度。把三个乘数乘起来再乘以并发请求数，就是缓存的总占地。直觉上记住一点：缓存和「长度乘并发」成正比，长文本服务里这个数字很容易反超权重。

四个乘数里模型结构定死两个，能动的只有长度和并发。

拿一个直觉例子感受量级：同样是几条并发请求，普通问答的短上下文，缓存占地很小；换成几万字长文档的连续问答，缓存可能膨胀几十倍。这也是长上下文服务贵的原因，Kimi 这类以长文本见长的产品，背后要为这份账做大量优化，通义千问的长文档能力同样建立在这套账本的管理上。

上下文长度为什么金贵

「能接多长的上下文」常被当作卖点，本质是显存能不能装下对应长度的缓存。长度翻倍，缓存大致翻倍；并发也抢同一块显存，所以长上下文服务的并发数往往上不去——并非不愿意接更多用户，是缓存先把地方占满了。理解这一点，就明白「长文本」和「高并发」在同一台机器上是此消彼长的关系。

省显存的三条路

第一条是压缩存储：把记录用更低位宽存放，原理与量化一致，详见量化部署；第二条是精简记录：丢弃或合并价值不高的旧内容，用少量精度换大量空间；第三条是把一份大模型拆到多卡分摊，机制见模型切分。整体显存里权重、激活、缓存三块的分工，参考显存占用；整机方案怎么把这些账打包，看一体机；批量请求下缓存怎么管理，与批处理的调度直接相关。

观察缓存还有个实用视角：会话之间的复用。同一个用户连续追问时，前文的缓存记录可以直接接着用，不需要重算，这就是多轮对话响应快的原因；换一个新会话，记录作废重起。因此把高频场景设计成「同会话内完成」，比让用户反复开新对话更省显存也更快。服务端做会话亲和——让同一用户的请求落到同一处——正是为这份复用创造条件。

KV 缓存速查表

• 它是什么：避免重复计算的中间记录，随对话变长而变厚
• 占地算法：每字记录乘层数乘上下文长度乘并发
• 主要变量：上下文长度，翻倍即占地翻倍
• 省法三条：压位宽、精简记录、多卡分摊

带走一句：长文本的钱大多花在缓存上，压长度、降并发、做压缩，三选一都能立竿见影。

关于 KV 缓存再多问三句

• 清空对话能释放缓存吗？：能，会话结束缓存即失效，这也是高并发服务要限制单会话长度的原因之一。
• 缓存会影响回答质量吗？：存取本身不损失质量，做精简压缩时会有轻微折损，属于用精度换空间的权衡。
• 为什么长对话越聊越慢？：缓存越攒越厚，每一步要翻的记录变多，时间开销随之上升。