关键发现
- 代码库显著影响缓存效率。 客户端输入中，有1.6%至11.1%无法命中缓存。在92%的命中率下，每百个token中有8个需重新计算；而在97%命中率下仅为3个。这意味着前者的预填充（prefill）工作量约为后者的2.7倍。
- 缓存未命中导致能耗倍增。 对于缓存命中率极低（低于10%）的请求，其能耗约为完全缓存请求的两倍。在GLM-5.3模型上，这一比例接近2.5倍。
- 长会话中的未命中代价高昂。 当上下文超过128k tokens时，若对话重读超过一半的提示词，其产生的预填充工作量相当于该深度下约600次正常对话的总和。
- 问题主要源于代码实现。 实验室测试显示，每次缓存中断均因代码库修改了已发送内容，迫使系统从差异点重新读取。
Neuralwatt通过直观监控代理代码库（agent harness）对模型调用的影响，分析了云端一个月的流量数据。结果显示，代码库在决定GPU工作量方面占据出人意料的比重。业界通常聚焦于模型架构或硬件对比，但客户端的实现细节同样至关重要。
大部分流量来自输入远大于输出的代理应用。典型编码代理轮次发送超10万tokens的历史记录，仅返回数百tokens结果。若前文保持不变，服务器可利用键值（KV）缓存仅处理新增部分，这是提升效率的关键。然而，缓存依赖精确的前缀匹配，任何对已发送内容的修改都会导致缓存中断，引发从差异点开始的重算。
同一模型，不同的缓存率
2026年9月8日至10月7日期间，数百个客户端（包括OpenCode、Oh My Pi、Pi等开源代理及SDK）接入服务。仅OpenCode就占据了约四分之一的客户群。数据显示，尽管各客户端整体缓存率较高，但微小差异影响巨大：缓存率92%的客户端带来的预填充工作量是97%客户端的2.7倍。
命中率受工作负载影响，会话越长，新增文本占比越小，命中率越高。衡量代码库优劣的另一指标是缓存中断频率：deepseek-harness约每100次对话中断1次，而OpenCode和Pi约为3次。OpenCode 2.x版本通过修复1.x版本的缓存中断问题，将未命中率从3.0%降至2.2%，但在生产环境中这一优势尚未完全显现。
未命中的能耗与延迟成本
基于实测能耗数据，2026年10月1日至7日的一周内，针对相似规模（约50k tokens）的请求进行比较，几乎未命中的请求能耗约为缓存请求的两倍，GLM-5.3上接近2.5倍。无效的预填充不仅浪费能源，还争夺GPU资源，降低其他用户的响应速度。
在2026年10月6日至13日对长会话的追踪中，大多数缓存中断仅涉及末尾少量token。但当上下文超过128k tokens时，每1,000次对话中约有3次会重读超过一半的提示词。这些少数情况占据了该深度下75%的重读token量，单次重读平均涉及约230k tokens，而正常对话仅新增约370个token。此类重读导致首token等待时间显著增加，且在长会话后期发生时，累积的能耗和延迟成本极为可观。
缓存中断的根源
实验室对OpenCode、Pi、omp和Kilo Code等主流开源代理的测试显示，88%的请求为纯追加，其余12%的缓存中断均源于代码库对已发送内容的修改。
无用户操作下的中断：
- OpenCode计划模式提醒： 1.x版本在每条用户消息后附加并随后移除提醒，导致每轮重读前一轮全部内容。2.x版本将提醒保留在自身消息中，避免了此问题。
- omp文件修剪： 二次读取文件时，omp用标记替换历史记录中的早期副本，导致提示词中部被修改，迫使重读大量token。禁用相关压缩配置可保持缓存完整。
用户行为引发的中断：
- 切换推理强度： 强度参数位于提示词开头，切换导致全部重读。
- MCP服务器连接/断开： OpenCode 1.x和Kilo Code按字母顺序插入工具，改动发生在提示词前部；OpenCode 2.x改为追加说明，实现纯追加。
- 日期变化： OpenCode 1.x和Kilo Code在系统提示词中包含当日日期，跨越午夜即触发全量重读。
- 压缩策略： Pi重写开头摘要导致大部分重读；OpenCode 2.x复用前缀，重读成本较低。
生产环境元数据分析证实，更改工具列表或强度级别使缓存中断概率增加20倍以上，平均重读前一个提示词的40%。尽管此类操作仅占0.5%的轮次，却贡献了19%的重读token量。其余重读主要由代码库内部逻辑（如提醒、修剪、日期）或缓存驱逐引起。
deepseek-harness的最佳实践
deepseek-harness在测试中实现了所有后续请求的纯追加，即便在重启后亦然。其核心策略包括：
- 基于只追加日志重建请求： 确保重试和恢复时的提示字节级一致。
- 固定且精简的系统提示词： 不包含日期、Git状态等易变信息。
- 状态变更后置： 将审批策略或技能变化以快照形式追加至历史记录末尾，不修改前文。
- 工具列表排序一致： 通过文本指令而非增删工具来执行模式切换。
- 延迟压缩： 摘要调用复用现有前缀，最大化缓存命中。
- 评估缓存影响： 每个功能包均附带“KV缓存影响”说明。
优化建议
针对开发者：
- 保持每轮提示词开头一致，在末尾追加新消息和工具结果。
- 系统提示词中避免包含日期、Git状态等动态内容。
- 保持工具列表稳定有序，新工具追加至末尾。
- 推迟压缩，并确保摘要复用对话前缀。
- 发送稳定的会话ID，以便路由至持有缓存的服务器。
针对用户：
- 会话初期确定推理强度，避免中途切换。
- 使用omp时，考虑禁用
compaction.supersedeReads。 - 在会话变长前完成强度、MCP服务器和技能等设置。
Neuralwatt的应对措施
Neuralwatt通过将会话路由回持有其缓存的服务器，已在最繁忙模型上实现88–96%的token保留在主服务器。共享KV缓存池允许迁移时会话加载前缀而非重算。测试显示，更智能的前缀感知路由器仅能提升0.1%至0.2%的命中率，表明剩余浪费主要源于提示词构建方式。
下一步，Neuralwatt计划向上游开源代码库提交修复方案和推荐默认值，并研究在提示词开头发生微小编辑后复用缓存的技术，以解决客户端侧的效率问题。
缓存中断虽不报错，但导致显著的能源浪费和延迟。通过测量和优化，无论是个人开发者还是数据中心，均可大幅降低AI运行的隐性成本。