大模型KV Cache前缀缓存优化

可视化演示

动态演示大模型KV Cache前缀缓的核心机制，通过开始/执行/监控/完成四种模式展示关键概念与交互流程。

重复计算困境

面馆开业初期，店长立下规矩：“每位顾客来了先熬汤。”不管顾客点牛肉面还是排骨面，高汤配方一模一样，但每单都要从洗锅、放水、下料重新开始。后厨忙得脚不沾地，顾客却等得拍桌子。店长月底算账：一天 1000 单，每单熬汤两小时，其中九成工序是在重复做同一件事，煤气费全烧在“重来一次”上。

大模型服务就是这样。一个典型的 Chat 应用，每个请求都带着相同的系统提示词（“你是一个乐于助人的助手……”），偶尔还有 Few-shot 示例。这些前缀 token 在每次请求里一字不差。模型在预填充阶段要逐个 token 计算注意力，把每个 token 的 K 向量和 V 向量算出来并存入 KV Cache——这个动作对每个请求完整重复，哪怕那 500 个前缀 token 昨天已经被算了十万次。

KV Cache 是 Transformer 自回归解码的产物：预测下一个 token 时，模型要“回看”前面全部 token，把 K/V 缓存下来避免重复计算。问题是缓存“按请求隔离”：请求 A 算好的底料，请求 B 一点用不上。以 7B 模型为例，32 层 × 32 头 × 128 维再乘上几千 token 的序列长度，一个请求的 KV Cache 就能吃掉几百 MB 显存；一千个请求各自重复算出同样的前缀 KV，浪费就这样悄悄变成了昂贵的账单。

店长猛然醒悟：熬汤的钱付了一千次，其中九百次都是重复劳动。与其让每口锅都从零开始，不如把这锅“高汤”变成厨房的公共资产——这正是前缀缓存的第一步思考。

前缀缓存原理

店长推出新方案：厨房窗口挂一块“今日高汤已备好”的牌子。顾客点单时，先看高汤锅——有现成的汤直接舀；只有浇头（用户个性化部分）需要现场做。高汤的配方、熬法、火候对每个顾客都一样，所以它成了所有订单共用的“底座”。

Prefix Cache 的思路完全一致：把请求分解成“共享前缀”和“专属后缀”。共享前缀通常由系统提示词、Few-shot 示例、任务说明组成，在同一应用的所有请求里几乎不变；专属后缀则是每个用户真实输入的内容。前缀缓存把共享前缀 token 的 K/V 值算好、存在显存公共区；新请求进来先做一次“对牌”，匹配上了就直接把缓存装进计算流，跳过预填充阶段那几百甚至上千 token 的注意力计算。

在实现层面，前缀缓存通常不是“逐 token 匹配”，而是把前缀切成固定大小的块（block），以块为单位做哈希索引。块内 token 完整算出 KV 后，连同该块的内容哈希一起存入缓存表。命中时，调度器把对应块指针接进新请求的 KV 页表——这正是 vLLM 里 PagedAttention 与 prefix caching 结合的底层思路；未命中的块才从预填充开始算。这整个机制，和操作系统里“页缓存命中”的逻辑几乎同构。

高汤锅越大（共享前缀越长），直接舀汤的顾客占比越高（命中率越高），后厨就越轻松。前缀缓存把“每单重熬”变成了“一锅共用”，原理朴素，收益却直击要害。

命中判定逻辑

为了快速判断高汤是不是同一锅，店长给每锅汤挂了一块“配方编号牌”。新订单来了不用尝味道，对一下编号就知道是不是自家那锅高汤。但编号怎么打才能又快又不出错？这就是厨房的算法问题。

前缀缓存同样需要“对牌”机制。最朴素的做法是逐 token 比对：新请求的前 1000 个 token 和缓存里的 1000 个 token 逐个比较。但每次请求都做一次 O(L) 级别的比对，本身就是不小的开销。工程上通用的方案是“块级哈希”：把前缀切成固定块，每块用内容哈希（如 xxhash / SHA 摘要）作为编号，查找时逐块对哈希，命中连续若干块就复用对应 KV。

判定逻辑的核心是“前缀对齐”——只有当两个序列从开头起有连续完全相同的 token 才算有效命中。中间断掉一块，后面即使文字相同也不能复用，因为注意力上下文已经改变，KV 必须重算。vLLM 的做法是：每个块在存储时记录“整条前缀中间所有块的哈希链”，查询请求从前往后逐块匹配，遇到第一个哈希不一致的块就停止；此前的块全部复用，此后的块走正常预填充。这就是“部分命中”。

就像服务员按编号牌连看七张，前六张都对上、第七张对不上——那前六锅汤直接用，第七锅重新熬。编号牌（哈希）让“对牌”从分钟级变成毫秒级，这就是部分命中的工程智慧。

系统集成实现

面馆要落地“公共高汤锅”，得改造整个流程：设一个高汤区、一个煮面区，服务员下单先查高汤区有没有货，没有才通知后厨开火。店长还要规定高汤锅最多放几口，放不下时优先倒掉“最近没人点”的汤。

在真实推理框架（如 vLLM）中，这套流程对应三个模块：块管理器（Block Manager）、缓存控制器（Cache Controller）和调度器（Scheduler）。块管理器负责按固定 token 数切分前缀，并为每块分配显存页；缓存控制器维护哈希表，记录每块的内容哈希、引用计数和最近访问时间；调度器在每批请求进来时先查缓存表，把命中块直接插进新请求的 KV 页表。

一个关键细节是“引用计数”——同一块 KV 可能被多个进行中的请求同时引用（例如同一个系统提示词同时服务 10 个用户），块不能随意释放。最近最少使用（LRU）策略在这里天然适用：记录每块最后一次被命中的时间，显存紧张时优先驱逐最久没被用过的块。另外，模型权重更新、提示词模板改版都会让缓存“失效”，所以缓存控制器还要支持按版本号整体失效。

面馆的“高汤区”从此独立于“煮面区”，成为公共设施：服务员查单、后厨补汤、旺季排队全按这套流程走。系统集成做扎实了，整套服务才能稳定高效地运转。

收益量化分析

改造一个月后，店长拉出报表：顾客从下单到第一口面入口的时间（首口延迟）从 15 分钟降到 6 分钟；同一时段能接待的顾客数（吞吐量）翻了一倍。钱省在哪？省在“没重复熬汤”。

LLM 推理的核心指标是 TTFT（Time To First Token，首 token 延迟）和吞吐量。预填充阶段占据 TTFT 的大头，而预填充计算量与 prompt 长度成正比。Prefix Cache 命中后，预填充只剩“专属后缀”那一段，计算量从 L_prompt 降到 L_prompt − L_hit——节省比例恰好等于命中率。

考虑一个典型场景：系统提示词 512 token，用户输入 128 token。不做缓存时预填充要算 640 个 token；命中后只需算 128 个，预填充计算量降为原来的五分之一。如果 100 个用户共享同一个前缀，GPU 原本要为 100 × 512 = 51,200 个 token 做重复计算，现在只需算 1 次加 100 × 128 次。在长上下文场景（如 8K 系统提示词 + 对话历史）里，加速比可以轻松突破 10 倍，吞吐量也随之上升，因为 GPU 的空转时间被大幅压缩。

报表上的数字不会骗人：没重复熬汤，后厨的煤气费（算力）降了，顾客翻台率（吞吐）升了。这一锅“公共高汤”直接改写了面馆的盈亏线。

适用场景特征

高汤策略也不是对谁都有效——如果顾客天南海北、点单完全随机，每锅汤配方都不一样，熬一大锅高汤反而占地方。店长总结：高汤只适合“点单模式固定”的客群。

同理，Prefix Cache 的收益完全取决于“前缀复用率”。三个最典型的高复用场景：第一，多轮对话——每轮请求的前缀是“系统提示词 + 全部历史消息”，轮次越多公共前缀越长，缓存命中率越高；第二，模板化推理——医疗报告、法律文书、代码审查等场景，请求结构是“固定模板 + 少量字段”，模板部分天然共享；第三，批量评测与批量生成——同一 prompt 并发发给 N 个用户（如 A/B 测试、排行榜评测），共享前缀被高并发访问，命中率极高。

这里要特别强调：“长系统提示词 + 短用户输入”是最佳组合——共享前缀越长，专属后缀越短，命中率越接近 1。反过来，如果每条请求开头都是完全不同的内容（如无系统提示词的自由问答），前缀根本不存在，缓存自然帮不上忙。另外，缓存条目数会随前缀种类线性增长，前缀种类越少且访问越集中，缓存的“性价比”越高。

面馆后来还发现一个意外之喜：经常来的老顾客（多轮对话）续汤越来越快——因为他们喝的还是那锅底汤，只是换了浇头。场景对上了，缓存的威力才能完全释放。

工程权衡考量

高汤锅也有烦恼：冰箱只有那么大，放十口高汤锅，就放不下新鲜食材了；而且高汤放久了会变味，必须定时倒掉重熬。公共高汤不是免费的。

Prefix Cache 的代价同样直接。第一，显存占用——每段被缓存的前缀 KV 都要常驻 GPU 显存，这会挤占给生成阶段预留的 KV 空间；第二，管理开销——哈希表、引用计数、LRU 结构都要消耗 CPU 与内存资源；第三，失效风险——提示词模板改一个词，或模型权重升级，所有相关缓存全部失效，命中率瞬间归零。

因此工程上要在“缓存多少”和“命中多少”之间找平衡。常见做法包括：设置缓存显存上限，超出后按 LRU 驱逐；区分“热前缀”与“冷前缀”，只缓存访问频率高于阈值的前缀；前缀被驱逐后，对应 KV 页回收到公共池继续给生成阶段使用。对于动态前缀（如 RAG 检索中每请求不同的文档前缀），缓存收益不稳定，需要单独评估是否值得缓存。在分布式推理中，多卡共享缓存池还要保证淘汰与更新的原子性。

聪明的店长最后定下规矩：高汤锅最多留三口，只留点单率最高的三种；三天没人点的汤直接倒掉，腾地方给新鲜食材。缓存不是越多越好，而是越“热”越好。

AI 应用场景

Python 演示

"""模拟 LLM 推理中 Prefix Cache 复用共享前缀 KV 的过程."""import hashlib  class PrefixCache:    """前缀缓存: 存共享前缀 KV 块, 支持按内容哈希查找与命中统计."""     def __init__(self):        self._store = {}        self._hit_count = 0        self._total_count = 0     def lookup(self, prefix_tokens):        """按前缀 token 序列取缓存 KV, 命中返回 KV 块, 未命中返回 None."""        self._total_count += 1        key = self._hash(prefix_tokens)        kv = self._store.get(key)        if kv is not None:            self._hit_count += 1        return kv     def store(self, prefix_tokens, kv_blocks):        """首次计算的共享前缀 KV 写入缓存表."""        self._store[self._hash(prefix_tokens)] = kv_blocks     def _hash(self, tokens):        return hashlib.sha256(' '.join(map(str, tokens)).encode()).hexdigest()     @property    def hit_rate(self):        if self._total_count == 0:            return 0.0        return self._hit_count / float(self._total_count)  def compute_kv(tokens, cache, shared_prefix):    """模拟一次请求: 前缀命中则复用缓存 KV, 否则全量计算并写入缓存."""    if tokens[:len(shared_prefix)] == shared_prefix:        hit = cache.lookup(shared_prefix)        if hit is not None:            suffix = tokens[len(shared_prefix):]            merged = dict(hit)            merged.update({t: 'kv_new' for t in suffix})            return merged, True    kv = {t: 'kv_new' for t in tokens}    prefix_kv = {t: 'kv_cached' for t in shared_prefix}    cache.store(shared_prefix, prefix_kv)    return kv, False  def main():    cache = PrefixCache()    shared_prefix = [1, 2, 3, 4]    requests = [        [1, 2, 3, 4, 100, 101],        [1, 2, 3, 4, 200, 201],        [5, 6, 7, 8, 300, 301],        [1, 2, 3, 4, 400, 401],    ]    for idx, req in enumerate(requests, 1):        _, hit = compute_kv(req, cache, shared_prefix)        print('请求%d: %s, 命中率=%.2f%%' % (idx, '前缀命中' if hit else '重新计算', cache.hit_rate * 100))  if __name__ == '__main__':    main()

1. key = self._hash(prefix_tokens)把前缀 token 序列压缩成哈希“配方牌”，作为缓存查找的钥匙，避免逐 token 比对。
2. kv = self._store.get(key)在公共显存表里查这张“配方牌”，命中就直接取出 KV 块。
3. if tokens[:len(shared_prefix)] == shared_prefix:请求级入口先判断“前端是否带了相同的公共前缀”，相当于确认顾客点的汤底是不是同一锅。
4. hit = cache.lookup(shared_prefix)只拿共享前缀去查缓存，用户输入的专属部分不参与匹配。
5. cache.store(shared_prefix, prefix_kv)首次计算后把共享前缀的 KV 存入公共缓存，供后续请求复用。
6. merged = dict(hit)命中时把缓存的 KV 块复制出来，与新增 token 的 KV 合并成完整缓存，模拟部分命中流程。
7. for idx, req in enumerate(requests, 1):依次处理四条模拟请求，观察第二次、第四次请求命中，第三次因前缀不同而“重新熬汤”。

常见误区

面试题