长上下文推理变慢的根因往往不是模型参数量而是每生成一个 token 都要把前面所有 token 的隐藏状态重新算一遍。Stanford 前缀滑动法把这个问题拆成两部分前缀复用和滑动窗口。前者让已经算过的 KV 缓存可以被后续请求继续使用后者让缓存不会随着对话长度无限膨胀。长推理场景中这套机制可以把端到端推理速度提升约 3 倍。下面先讲清楚前缀滑动法的原理再用一个标准库 Python 脚本实现最小闭环最后梳理落地到推理引擎时的关键参数、常见坑和生产建议。这篇内容面向正在做 LLM 推理服务性能优化、或者正在研究长上下文应用的同学。阅读前只需要了解自回归生成的基本流程不需要额外框架经验。如果当前项目还没有接入任何前缀缓存读完至少能回答三个问题缓存应该存什么、按什么粒度匹配、如何控制内存占用。整个实现不依赖深度学习框架用 Python 3.10 标准库就能跑通方便先验证思路再迁移到真实生产系统。1. 先理解长推理为什么慢KV Cache 与重复计算1.1 自回归生成与 KV Cache 的基本流程语言模型生成内容时通常按 token 逐个生成。每一步的输入是已经生成的全部 token 序列模型需要计算注意力层的 K 矩阵和 V 矩阵。早期实现里每一步都从零计算全部历史 token 的 K/V导致时间复杂度随序列长度近似二次增长。KV Cache 就是把这些历史 K/V 结果缓存下来每步只计算新 token 对应的 K/V再拼接到已有缓存中。这样时间复杂度从二次降到线性但代价是显存占用随序列长度线性增长。实际项目中KV Cache 通常由推理框架管理比如 vLLM 的 PagedAttention、TensorRT-LLM 的 KV Cache Manager、SGLang 的 RadixAttention 都在做类似的事情。它们要解决的核心问题一致避免重复计算已经出现过的历史内容。前缀滑动法可以看作这类思路里更强调“前缀复用”和“窗口淘汰”的组合方案。1.2 长推理场景中的重复计算问题普通聊天请求通常较短前缀缓存收益有限。长推理任务比如 Agent 工具调用、思维链展开、多轮文档改写经常把上一轮输出作为下一轮输入的一部分。此时输入序列不断变长而且前后两轮之间大量 token 是重叠的。如果推理框架不做前缀复用每一轮都会把重叠部分重新计算一遍。假设一轮输入 2000 token每轮新增 200 token连续 10 轮。无缓存时每一轮都要从开头计算总计算量约为 2000 加 2200 加 2400一直累加到 3800总和接近 29000 token 的 prefill 工作量。理想复用情况下只需要首次完整计算 2000 token后续每轮只计算新增的 200 token总量约 3800 token。这个差距接近 3 倍和前面提到的提速结论基本吻合。1.3 前缀滑动法要解决的核心矛盾KV Cache 能缓存但不能无限缓存。长推理的序列会持续变长如果每个请求都把完整 KV 保存下来显存和进程内存都会被快速耗尽。前缀滑动法的切入点是不要让每个请求保存完整历史而是只保留一个固定窗口内的前缀状态在新请求到达时按最长公共前缀匹配已有缓存记录缓存条目总数超过阈值后按访问时间或窗口边界淘汰。可以把这理解成“按可复用前缀保存缓存”和“给缓存加滑动边界”的组合。普通 KV Cache 的默认策略是随请求生命周期走请求结束缓存释放。前缀滑动法把缓存生命周期延长到跨请求复用但同时用窗口和条目上限约束内存避免因为复用过猛导致资源失控。2. Stanford 前缀滑动法的核心机制2.1 前缀复用的本质缓存 K/V 而不是缓存答案前缀滑动法不是缓存模型输出文本而是缓存计算过程中的 KV 状态。模型每一步生成都会依赖 Attention 层的 K/V 状态。只要输入前缀 token 完全一致并且模型权重、dtype、采样参数一致那么这段前缀计算出的 KV 状态理论上就是相同的。后续请求如果包含相同前缀就可以直接跳过这段前缀的 prefill 计算只从第一个不同位置开始计算。用例子说明。第一次请求输入 A B C D模型生成 E F完整序列是 A B C D E F。第二次请求输入 A B C D E如果缓存保存过完整序列 A B C D E F 的 KV那么第二次请求至少可以复用 A B C D E 这一段只需要计算新增部分。“能复用到哪一位”就是前缀命中长度。这里的关键不是“答案是否相同”而是“计算路径是否可复用”。只要 token 序列一致KV 状态天然一致这是前缀缓存成立的前提。2.2 滑动窗口限制缓存生命周期和内存上限长推理过程中输入序列会越来越长。如果每个前缀都保存内存增长速度远高于推理本身。滑动窗口在这里有两层含义第一每条缓存记录只保留最近若干 token 的 KV超过窗口的部分丢弃第二缓存池按 LRU 或访问频率淘汰旧条目保证总条目数有上限。设计上窗口大小 W 决定了单条缓存能覆盖多长的前缀最大条目数 N 决定了缓存池整体内存。W 太大缓存能覆盖更长序列但浪费内存W 太小长 prompt 无法完整命中。N 太大支持更多并发请求复用但淘汰和查找变慢N 太小刚存进去的缓存很快被挤掉。调参时需要同时观察命中率和内存占用不能只看其中一项。2.3 为什么能提速从重复 prefill 变为增量 decode没有前缀缓存时每次请求都要做 prefill也就是把整个输入从头到尾计算一遍才能生成第一个 token。长推理场景中很多请求的前半段完全相同这部分 prefill 被重复执行是最大的浪费。前缀滑动法让这些请求命中缓存后只需要从第一个未计算 token 开始 prefill后续 decode 保持不变。为什么能到 3 倍左右因为长推理请求里典型分布是前面大部分内容重叠后面小部分是新增内容。比如公共前缀占 80%新增内容占 20%。复用时计算量从 100% 降到 20%再扣除缓存查找和内存拷贝开销性能提升一般会在 2 到 4 倍之间。具体数值受前缀长度、模型大小、批大小、显存带宽影响不是固定值。标题里的 3 倍是典型场景的结果不是所有场景的保底收益。2.4 与普通 Prompt Cache 的差异对比维度普通 Prompt Cache前缀滑动法缓存粒度通常以完整 prompt 为 key以任意前缀为 key按最长匹配匹配方式只缓存完全相同的 prompt支持公共前缀部分命中内存控制每个 prompt 各存一份容易膨胀按窗口和条目上限淘汰适用场景请求 prompt 固定不变Agent、多轮推理、链式生成实现复杂度低中需要前缀匹配和淘汰速度提升只对完全重复请求有效对部分重复请求也有效普通 Prompt Cache 更适合请求完全相同的离线任务而前缀滑动法更适合交互式长推理。交互式请求往往只有部分前缀相同普通缓存命中率很低前缀滑动法能通过最长公共前缀匹配获得收益。理解这个差异有助于选型如果业务请求完全随机连前缀滑动法也帮不上太多忙如果业务请求共享一段文档或系统提示词前缀滑动法收益会非常明显。3. 实现一个最小可运行的前缀滑动缓存3.1 环境准备只用标准库方便快速验证下面实现不依赖深度学习框架只使用 Python 3.10 标准库。目的是把前缀缓存的数据结构和匹配