← 返回概念解读

Concept Fable

KV Cache

Key-Value Cache · Serving optimization

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

说书人的两本暗册

港口问事亭原本靠一套熟办法运转。老书记熟悉每柜文书的位置,按旧节奏翻找时很少出岔子;商人也愿意等他慢慢核对。

后来事情变大了。商人反复追问同一批货的去向,催促声从清晨排到傍晚。新人以为这是数量问题,只要多派人、多加钟点就行;老人却看见许多细节已经越过旧办法能承受的边界。

掌事人试了第一个办法:每次都翻整柜文书。开头几天确实看见起色,队伍短了些,外人也觉得这门手艺终于跟上了新场面。

可麻烦很快换了样子。有人为了赶进度省掉检查,有人把不合适的活硬塞进旧流程,最熟练的人反而被琐事拖住。出错处不总在明面上,常等到交付之后才露出来。 旧账本还能说明来路,却说不清下一步该怎么改。

掌事人又加了规矩,要求每个人多签字、多回报、多补一层保护。纸面看起来周全,现场却更慢;师傅们忙着证明自己没错,真正的裂缝仍在原处扩大。旁观者只看到结果忽好忽坏,现场的人越来越难判断该先救速度、质量,还是责任。 每个人都觉得自己多做了一点,整件事却没有因此更稳。

一位沉默的老匠人把几次失败摊在桌上。他没有责怪谁,只让大家看同一个细节:新限制从来没有进入日常练习,只在交付前突然冒出来。他把几次返工按发生顺序排开,众人才发现,失误总在同一个拐角被放大。

于是作坊改成了新规:把货名和对应去向写成手边卡片,问过的先查卡片。刚开始人人不适应,手脚都像被拴住;但几轮下来,粗糙的捷径被挡住,真正稳妥的动作慢慢留下来。

再遇到同样的压力时,交付没有变得花哨,却明显更可靠。老书记终于明白:前面查过的对应关系若留得住,后面问答就省下大量翻找。若等到最后才补救,代价往往已经埋进前面的每个选择里;这条新路没有消灭成本,却让成本提前现身,方便在还能改动的时候被处理。

揭示

这个故事讲的是:KV Cache

大模型生成文本时,每个旧 token 都会产生可供注意力机制使用的 Key 和 Value。把这些 Key/Value 缓存起来,后续生成新 token 时就不用重新计算全部历史。

KV Cache 能显著加快自回归生成,尤其是长对话和流式输出。但它会占用显存或内存,长度越长、并发越高、模型层数和头数越多,缓存成本越高。

隐喻映射

  • 两本暗册:历史 token 的 Key 和 Value 缓存
  • 新问题查暗册:新 token 对历史上下文做注意力查询
  • 不用重读整本书:避免重复计算历史 token
  • 暗册占满桌子:KV Cache 占用显存
  • 每桌一套暗册:并发请求各自需要缓存

Soloharness 判断

KV Cache 是长上下文成本的底层原因之一。产品设计里看似只是“多放点历史”,背后可能直接变成显存、延迟和并发能力的账。

attentiondecodePagedAttention

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。