长上下文推理为什么慢又贵从一次请求的旅程拆解 LMCache 的 KV 缓存加速原理【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache你有没有算过一笔账用户发来一篇一万字的文档提问模型要先生成第一个字GPU 得把整个文档逐 token 算一遍这个过程叫 prefill。文档越长TTFT第一个字多久能吐出来越久成本越高更亏的是如果下一句提问还带着同一篇文档前面全部要重新算一遍。LMCache 解决的就是这个问题它把算好的 KV 缓存按块存起来下次同样的前缀再来时直接复用省掉大部分重复计算。实测里长文档场景下启用它之后 TTFT 能降 68% 左右推理因此又快又省。这篇文章不逐行读代码而是跟着一份真实请求看它是怎么被存下来、又被命中复用的。 一份读书笔记为什么 KV 缓存值得被留下来先打个比方。模型读一篇长文档回答问题相当于边读边记笔记读到第 1000 字时它记下了前 1000 字的所有要点这些要点就是 KV 缓存读到第 2000 字时前面 1000 字的笔记还能继续用只需要记新增部分。问题在于笔记是一次性的——请求结束、GPU 显存被清空笔记就扔了。下一个问题哪怕问的还是同一篇文档模型也得从头再读一遍、再记一遍。所以缓存 KV 的价值只有一个字省。只要新请求的前缀和某次旧请求相同——系统提示词相同、引用的文档相同、聊过的上文相同——相同部分的笔记就能直接搬来用GPU 只负责算最后不一样的那一截。而且这些笔记是按内容来识别的哪怕两份请求只有开头几十字重叠重叠部分也能对上。LMCache 干的活就是把这份笔记按块存起来、按内容找回来它是推理引擎和各类存储之间的一层 KV 缓存加速层。 一次请求的完整旅程从 prompt 进来到 KV 命中我们来看一个请求进来后发生了什么。先查分块、算指纹、连续命中vLLM 把 token 序列交给 LMCache 的LMCacheEngine核心入口在 lmcache/v1/cache_engine.py。引擎先把序列切成固定大小的块再给每块算一个内容指纹哈希值。随后按顺序去存储层内存、本地文件或远端服务由配置决定问第一块的指纹在不在在要回来第二块在不在在继续……直到某个指纹查不到搜索到此为止返回此前连续命中的所有块。命中的 KV 数据经 GPU 连接器搬回推理引擎的缓存区引擎只需要 prefill 剩下的部分。retrieve最后还给调度器一个布尔掩码逐 token 标清哪些已经拿回来了谁该补算一目了然。再存算完的笔记不白扔第一个字吐出来后新产生的 KV 不会浪费。store先为每块分配托管内存、从 GPU 拷出数据然后异步写入存储层不堵在推理主流程上。每一次查和存统计监控都会记录 token 数、命中长度和耗时——命中率、延迟这些指标就是这么攒出来的后面调参全靠它。 三个关键设计决策为什么是链式哈希、固定分块和连续内存块指纹为什么要接龙式地算给一份文档分三块第一块指纹只由自己内容决定第二块由第一块指纹 第二块内容共同决定第三块再往前滚——像滚雪球一样每一块都背着前面所有块的信息。好处很直接中间任何一个 token 变了从那一块开始后面所有指纹全变绝不会出现内容其实不同、指纹却相同的误命中复用到错误 KV 数据的风险被从根上堵死。prefix_hash NONE_HASH for token_chunk in token_chunks: prefix_hash self._hash_tokens(token_chunk, prefix_hash) yield prefix_hash为什么坚持固定大小的块块大小固定后每块占多大内存、一次存多少都可以提前算准分配器不会遇到意料之外的形状。更重要的是前缀对齐两份请求只要开头 N 个 token 相同它们的前 N 块指纹一定一致从头开始、连续命中这套检索逻辑才成立。块大小默认 256 个 token可以在配置里调切块本身很朴素按固定长度从头切到尾最后一块不满也照样存。实现在 lmcache/v1/token_database.py 的ChunkedTokenDatabase。为什么要把 KV 拼成连续内存块GPU 里的 KV 张量往往散在不同层、不同显存页里形状零碎。如果原样去传输和落盘就是一堆小 I/OPCIe 和磁盘带宽都跑不满。LMCache 统一用连续的托管内存对象来装每块 KV拷进来一次成型之后无论是走 PCIe 上卡、写文件还是发远端都是整块连续传输效率最高。存储层按整块读写也省掉了大量碎片化的小请求。 哪些场景命中率最高公开测试数据的延迟收益命中率取决于前缀重叠的多少。前缀越稳定、上下文越长、请求之间重复越多收益越大。下面汇总了项目公开材料里的几组数据场景KV 命中 / 复用率延迟收益长文档 RAGLLaMA-7B10k token 上下文—TTFT 降低 68%端到端延迟降低 73%长文档问答重复上下文段落复用率 85% 以上省去重复段落的 prefill 计算多轮对话命中率稳定在 70% 以上历史上文直接复用只算新增发言同前缀批量推理—吞吐提升 3-5 倍一句话总结前缀稳定 上下文长 请求间重叠多三个条件占得越多LMCache 越划算。 快速启用 LMCache 的 3 个步骤第一步拿到代码和依赖git clone https://gitcode.com/GitHub_Trending/lm/LMCache按仓库说明安装。第二步安装 vLLM 时带上 LMCache 集成以 vLLM 缓存优化为例SGLang 等引擎同理。第三步启动时指定一个配置 yaml写清楚用哪块内存、存到哪个后端本地文件或远端服务都行。仓库里的 examples/basic_check/ 和 examples/kv_cache_reuse/ 各有一份可直接改的示例配置照着填就能跑起来。 还能往哪走几个值得关注的方向。块大小目前是固定值按内容语义动态调整块粒度命中会更细对高频前缀做预取在请求正式到达前就把 KV 从远端拉进内存把等待藏在计算时间里存储和传输路上叠加量化或无损压缩跨实例共享时省下的带宽和存储费用会更可观。回到开头那个问题长上下文慢是因为重复算贵也是重复算。LMCache 的答案就是让算过的 KV 缓存按指纹存下来、按需命中——理解这一点你就理解了它凭什么快。【免费下载链接】LMCacheLMCache: Supercharge Your LLM with the Fastest KV Cache Layer项目地址: https://gitcode.com/GitHub_Trending/lm/LMCache创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考