CachyLLama：llama.cpp 分支加入持久化 KV 缓存，缓解本地智能体长会话卡顿

近期在 Reddit r/LocalLLaMA 社区，有用户分享了一个 llama.cpp 的分支项目 CachyLLama。该分支聚焦于本地推理中一个常见的痛点：在较慢的硬件上运行本地模型时，每次请求都要重新处理完整的系统提示、工具定义和历史对话，长会话中的「重复提示词处理」开销往往远大于真正的文本生成耗时。

核心思路：让 KV 缓存可持久化

CachyLLama 的关键改进是引入 SSD 持久化的 KV 缓存检查点（checkpoint），并在此基础上构建了一套多级缓存体系。当新请求的开头部分与此前已经处理过的上下文匹配时，推理引擎可以直接恢复对应的 KV 状态，只对发生变化的后缀部分进行重新计算，从而跳过大量重复的前缀处理工作。这些检查点还可以跨服务重启保留，意味着长时间运行的 agent 会话不必每次都从冷启动开始重建上下文。

需要强调的是，该项目并不声称能加速模型本身的 token 生成速度，它优化的是「避免重复劳动」这一维度。

项目方公布的基准数据

CachyLLama 仓库中给出基于 7840U + 780M 配置的测试结果，涵盖冷启动（cold）与热缓存（warm）两种场景下的提示词处理耗时：

• ~1,243 token 提示词：冷启动 9.3 秒，热缓存 0.41 秒
• ~5,409 token 提示词：冷启动 43.3 秒，热缓存 0.57 秒
• ~15,700 token 提示词：冷启动 143.1 秒，热缓存 0.99 秒

可以看到，在三个不同长度的提示词下，热缓存相较冷启动均能带来数量级级别的提速，且提示词越长、相对收益越大。

实际体验与适用场景

发帖者使用的是较老的双路 MI50 硬件，他表示在长 agent 会话中，重复请求的响应速度有了明显改善。不过他也明确说明这只是个人使用感受，并未进行受控基准测试，结论应视为运维经验而非严谨的科研结果。

此外，CachyLLama 还针对 Qwen 3.5/3.6、Gemma 4、GLM-4.7 等混合架构（hybrid architecture）做了专门处理，因为这类模型除了常规 attention 的 KV 缓存外，还涉及更复杂的循环状态（recurrent state）恢复问题。

小结

对于在本地或自建硬件上运行长上下文 agent 工作流、又受困于每次请求都要「从头读提示词」的用户来说，CachyLLama 提供了一种务实的工程优化路径。项目地址为 GitHub 上的 fewtarius/CachyLLama，感兴趣者可直接查看源码与更新日志。