一个 Coding Agent 跑到第 20 轮眼前只多了一条工具结果发给模型的输入却可能已经塞满系统提示词、工具定义、代码文件和前 19 轮历史。模型每次都要先把这些内容读一遍首字越来越慢。你以为 GPU 在继续思考其实相当一部分时间花在重复做 prefill。Provider 的 Prompt Cache 已经能省掉稳定前缀。可一旦自己部署模型流量跨多个推理进程、工作集装不进显存或者 RAG 文档不断换顺序进程内 Prefix Cache 就开始撞墙。LMCache 想做的是把 KV Cache 从推理进程里拆出来变成一层能共享、能分级、能观察的基础设施。API 用户先把 Prompt Cache 用对自托管团队只有在“长输入、高复用、高并发、显存吃紧”同时出现时才值得为独立 KV Cache 服务付出运维成本。Agent 的账单常常先花在 prefill模型收到一段输入先经过 prefill每个 token 在每一层注意力里生成 Key 和 Value。它们会被留在显存里后续每生成一个 token直接读取此前的 K/V不必把旧 token 全部重新算一遍。这份中间结果就是 KV Cache。同一个系统提示词、同一组工具定义、同一段对话前缀它们对应的 K/V 也可以复用。命中缓存后服务跳过那段重复 prefill只处理新追加的输入再进入 decode。所以要先分清两笔账KV Cache 省的是重复输入的计算和首字等待时间新输入与输出 token 仍然要处理。把“缓存输入便宜 90%”写成“总成本下降 90%”上线后一定会失望。命中也不是免费。KV 留在 HBM读取很快但容量小下沉到 CPU、SSD 或远端后容量变大搬运和等待也跟着增加。最终比较的是两段时间把旧 KV 取回来还是把原输入重新 prefill哪个更快。短上下文、低并发、小工作集经常是后者。缓存系统越复杂不代表延迟越低。Prompt Cache 很划算但它认前缀以 Anthropic 当前公开价格为例5 分钟缓存写入是普通输入价的 1.25 倍命中读取是 0.1 倍。一次命中就足以覆盖那 0.25 倍的额外写入成本。条件也很明确可复用部分必须保持一致并按tools → system → messages组成稳定前缀。前方改了一处后面的缓存也会受影响。这给 Agent 应用留下了几条很具体的优化• 系统提示词和工具定义放前面别在每轮动态改写• 工具列表保持稳定顺序不要随手遍历一个无序集合• 大段固定资料放在用户问题之前• 会话需要压缩时避免频繁改动已经缓存的前段• 同一任务连续调用别拖过缓存 TTL 才发下一轮。如果你调用托管 API先把这些做到位。没有必要一看见“缓存”两个字就先搭一套新的分布式服务。这里有个容易写错的细节对话在尾部继续增长不会自动毁掉前面的缓存。只要前缀保持一致旧 K/V 仍能接上新一轮。麻烦来自前缀内容或顺序变化以及多个独立片段重新组合。比如 RAG 先取出文档 A、B、C下一轮因为召回分数变化顺序变成 C、A、B。三份材料都读过拼起来却不再匹配旧前缀。又比如不同请求需要组合各自缓存过的文档直接拼接各段 K/V 会漏掉文档之间的注意力关系。对只在显存里维护缓存的推理服务还有一层限制多个数据并行进程各管一份缓存。相同上下文被路由到另一个进程或者热数据被显存淘汰复用机会就没了。LMCache 把缓存做成独立服务LMCache 的做法像给推理集群加一层专门的缓存系统。推理引擎继续负责调度和生成KV 可以分层留在 GPU、CPU 内存、本地 SSD 或远端存储。LMCache 的 MP 模式以独立服务运行多个推理进程注册到同一个缓存池于是跨进程也能找回相同上下文。一次请求进来推理进程先按 token 块查询缓存。命中就把 KV 拉回可用位置只对缺失部分做 prefill未命中则照常计算并异步把结果写入后面的存储层。缓存服务超时也应退回正常 prefill不能让“加速层”变成整条推理链路的单点故障。这套设计解决了两个现实问题• 缓存不再和某个推理进程同生共死重启或跨实例调度时仍有机会复用• 显存放不下的工作集可以下沉到更大的存储层再异步预取回来。代价也一并进来了缓存键必须在不同进程间保持一致淘汰策略要看工作集CPU 内存、PCIe、网卡和 SSD 都可能成为新瓶颈命中率高但取回太慢指标看上去漂亮用户依然在等。LMCache 团队在 2026 年 5 月公开了一组 MI300X 测试。8 用户、32K 上下文的低负载下工作集能放进 HBM原生 Prefix Cache 完成 52 个请求LMCache 只完成 25 个。多一层搬运此时成了负担。压力拉到 32 用户、100K 上下文后显存开始顶不住LMCache 的平均 TTFT 才从 HBM Prefix Cache 的 102.17 秒降到 34.59 秒并完成 28 个请求对方只有 12 个。数字属于 2 张 MI300X、MiniMax-M2.5 和指定软件版本不能抄成“部署就提速 3 倍”。它提供的工程判断更有用工作集还在显存里时搬缓存可能比重算更慢工作集溢出后分层缓存才开始还债。文档换顺序CacheBlend 怎么补独立存储解决“缓存放哪儿”还没有解决“不同文档的 KV 能不能直接拼”。CacheBlend 处理的是后一个问题。它先复用各文档已有的 KV再挑出受上下文影响较大的少量 token 重算用这部分计算补回跨文档注意力。EuroSys 2025 论文在 3 个开源模型和 3 组数据集上测试相比完整重算与 Prefix Cache 基线TTFT 改善 2.2–3.3 倍吞吐提高 2.8–5 倍。作者的经验是重算少于 15% 的 token 往往能接近完整重算质量。“往往”两个字不能删。模型、文档相关性、任务类型变了重算比例和质量也会变。对答案可验证的检索任务可以先做离线评测涉及合规、医疗、财务等高风险回答别拿论文均值替代自己的质量门槛。上线前先抄这张检查单我不会先问“要不要上 LMCache”而会先拉出一周请求数据看六项每轮输入里有多少 token 与前一轮重复Prefix Cache 的命中率和命中 token 数p50、p95、p99 TTFT而不只看平均值从缓存读取一段 KV 花多久从头 prefill 又花多久工作集是否频繁被 HBM 淘汰CPU、SSD、网络是否还有余量缓存服务超时或命中异常时能否降级为正常 prefill。API 用户如果连第 2 项都没拿到先检查稳定前缀、TTL、工具顺序和缓存断点。自托管团队如果发现长上下文重复率高、跨进程调度频繁、p95 TTFT 被 prefill 拉长再做一次真实流量回放。固定模型、硬件、并发与请求集只切换三组配置无缓存、引擎自带 Prefix Cache、LMCache 分层缓存。每组至少记录命中 token、缓存读取时间、prefill 时间、TTFT 分位数和完成请求数。别拿一条重复提示词的 warm hit替代真实 Agent 工作集。缓存不是越大越好也不是层数越多越先进。它只在“取回旧计算”比“重新计算”更便宜时成立。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 
长河君 · 2026/9/2 18:18:24 · 阅读 1.2k Agent 上下文越跑越贵，先把 KV Cache 从推理进程里拆出来
一个 Coding Agent 跑到第 20 轮眼前只多了一条工具结果发给模型的输入却可能已经塞满系统提示词、工具定义、代码文件和前 19 轮历史。模型每次都要先把这些内容读一遍首字越来越慢。你以为 GPU 在继续思考其实相当一部分时间花在重复做 prefill。Provider 的 Prompt Cache 已经能省掉稳定前缀。可一旦自己部署模型流量跨多个推理进程、工作集装不进显存或者 RAG 文档不断换顺序进程内 Prefix Cache 就开始撞墙。LMCache 想做的是把 KV Cache 从推理进程里拆出来变成一层能共享、能分级、能观察的基础设施。API 用户先把 Prompt Cache 用对自托管团队只有在“长输入、高复用、高并发、显存吃紧”同时出现时才值得为独立 KV Cache 服务付出运维成本。Agent 的账单常常先花在 prefill模型收到一段输入先经过 prefill每个 token 在每一层注意力里生成 Key 和 Value。它们会被留在显存里后续每生成一个 token直接读取此前的 K/V不必把旧 token 全部重新算一遍。这份中间结果就是 KV Cache。同一个系统提示词、同一组工具定义、同一段对话前缀它们对应的 K/V 也可以复用。命中缓存后服务跳过那段重复 prefill只处理新追加的输入再进入 decode。所以要先分清两笔账KV Cache 省的是重复输入的计算和首字等待时间新输入与输出 token 仍然要处理。把“缓存输入便宜 90%”写成“总成本下降 90%”上线后一定会失望。命中也不是免费。KV 留在 HBM读取很快但容量小下沉到 CPU、SSD 或远端后容量变大搬运和等待也跟着增加。最终比较的是两段时间把旧 KV 取回来还是把原输入重新 prefill哪个更快。短上下文、低并发、小工作集经常是后者。缓存系统越复杂不代表延迟越低。Prompt Cache 很划算但它认前缀以 Anthropic 当前公开价格为例5 分钟缓存写入是普通输入价的 1.25 倍命中读取是 0.1 倍。一次命中就足以覆盖那 0.25 倍的额外写入成本。条件也很明确可复用部分必须保持一致并按tools → system → messages组成稳定前缀。前方改了一处后面的缓存也会受影响。这给 Agent 应用留下了几条很具体的优化• 系统提示词和工具定义放前面别在每轮动态改写• 工具列表保持稳定顺序不要随手遍历一个无序集合• 大段固定资料放在用户问题之前• 会话需要压缩时避免频繁改动已经缓存的前段• 同一任务连续调用别拖过缓存 TTL 才发下一轮。如果你调用托管 API先把这些做到位。没有必要一看见“缓存”两个字就先搭一套新的分布式服务。这里有个容易写错的细节对话在尾部继续增长不会自动毁掉前面的缓存。只要前缀保持一致旧 K/V 仍能接上新一轮。麻烦来自前缀内容或顺序变化以及多个独立片段重新组合。比如 RAG 先取出文档 A、B、C下一轮因为召回分数变化顺序变成 C、A、B。三份材料都读过拼起来却不再匹配旧前缀。又比如不同请求需要组合各自缓存过的文档直接拼接各段 K/V 会漏掉文档之间的注意力关系。对只在显存里维护缓存的推理服务还有一层限制多个数据并行进程各管一份缓存。相同上下文被路由到另一个进程或者热数据被显存淘汰复用机会就没了。LMCache 把缓存做成独立服务LMCache 的做法像给推理集群加一层专门的缓存系统。推理引擎继续负责调度和生成KV 可以分层留在 GPU、CPU 内存、本地 SSD 或远端存储。LMCache 的 MP 模式以独立服务运行多个推理进程注册到同一个缓存池于是跨进程也能找回相同上下文。一次请求进来推理进程先按 token 块查询缓存。命中就把 KV 拉回可用位置只对缺失部分做 prefill未命中则照常计算并异步把结果写入后面的存储层。缓存服务超时也应退回正常 prefill不能让“加速层”变成整条推理链路的单点故障。这套设计解决了两个现实问题• 缓存不再和某个推理进程同生共死重启或跨实例调度时仍有机会复用• 显存放不下的工作集可以下沉到更大的存储层再异步预取回来。代价也一并进来了缓存键必须在不同进程间保持一致淘汰策略要看工作集CPU 内存、PCIe、网卡和 SSD 都可能成为新瓶颈命中率高但取回太慢指标看上去漂亮用户依然在等。LMCache 团队在 2026 年 5 月公开了一组 MI300X 测试。8 用户、32K 上下文的低负载下工作集能放进 HBM原生 Prefix Cache 完成 52 个请求LMCache 只完成 25 个。多一层搬运此时成了负担。压力拉到 32 用户、100K 上下文后显存开始顶不住LMCache 的平均 TTFT 才从 HBM Prefix Cache 的 102.17 秒降到 34.59 秒并完成 28 个请求对方只有 12 个。数字属于 2 张 MI300X、MiniMax-M2.5 和指定软件版本不能抄成“部署就提速 3 倍”。它提供的工程判断更有用工作集还在显存里时搬缓存可能比重算更慢工作集溢出后分层缓存才开始还债。文档换顺序CacheBlend 怎么补独立存储解决“缓存放哪儿”还没有解决“不同文档的 KV 能不能直接拼”。CacheBlend 处理的是后一个问题。它先复用各文档已有的 KV再挑出受上下文影响较大的少量 token 重算用这部分计算补回跨文档注意力。EuroSys 2025 论文在 3 个开源模型和 3 组数据集上测试相比完整重算与 Prefix Cache 基线TTFT 改善 2.2–3.3 倍吞吐提高 2.8–5 倍。作者的经验是重算少于 15% 的 token 往往能接近完整重算质量。“往往”两个字不能删。模型、文档相关性、任务类型变了重算比例和质量也会变。对答案可验证的检索任务可以先做离线评测涉及合规、医疗、财务等高风险回答别拿论文均值替代自己的质量门槛。上线前先抄这张检查单我不会先问“要不要上 LMCache”而会先拉出一周请求数据看六项每轮输入里有多少 token 与前一轮重复Prefix Cache 的命中率和命中 token 数p50、p95、p99 TTFT而不只看平均值从缓存读取一段 KV 花多久从头 prefill 又花多久工作集是否频繁被 HBM 淘汰CPU、SSD、网络是否还有余量缓存服务超时或命中异常时能否降级为正常 prefill。API 用户如果连第 2 项都没拿到先检查稳定前缀、TTL、工具顺序和缓存断点。自托管团队如果发现长上下文重复率高、跨进程调度频繁、p95 TTFT 被 prefill 拉长再做一次真实流量回放。固定模型、硬件、并发与请求集只切换三组配置无缓存、引擎自带 Prefix Cache、LMCache 分层缓存。每组至少记录命中 token、缓存读取时间、prefill 时间、TTFT 分位数和完成请求数。别拿一条重复提示词的 warm hit替代真实 Agent 工作集。缓存不是越大越好也不是层数越多越先进。它只在“取回旧计算”比“重新计算”更便宜时成立。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】