CachyLLama:一个带有持久化KV缓存的llama.cpp分支,让长时间本地代理会话不再那么痛苦
摘要
CachyLLama是llama.cpp的一个分支,它增加了基于SSD的持久化KV缓存和多层缓存,显著减少了在较慢硬件上长时间本地代理会话的提示重新处理时间。
我与这个项目无关,但我最近一直在使用它,我很惊讶它在这里没有引起更多关注:https://github.com/fewtarius/CachyLLama
CachyLLama是llama.cpp的一个分支,专注于在较慢硬件上非常重要的问题:重复的提示处理。它不仅有一个新的基于SSD的缓存,而且还有一些其他的缓存改进,比如多层KV缓存。我的本地模型一旦开始运行,生成速度是可以接受的。痛苦的部分是使用一个代理编程框架,它在每个请求中都会将大型系统提示、工具定义以及大部分对话内容发送回服务器。长时间的会话在重新处理熟悉的上下文上花费的时间远远多于生成答案的时间。
CachyLLama增加了基于SSD的持久化KV检查点和系统提示缓存。当请求的开头与之前处理过的上下文匹配时,它可以恢复该状态,只评估变化的部分,而不是从头开始。检查点也可以在服务器重启后保留。在我较旧的双MI50设置上,这使得长时间代理会话中的重复请求响应速度大幅提升。
我还没有进行受控基准测试,所以请将此视为一份操作报告而非科学结果,但实际差异非常明显。
该项目自带的7840U/780M基准测试报告:
~1,243 token的提示:冷启动9.3秒,热启动0.41秒
~5,409 token的提示:冷启动43.3秒,热启动0.57秒
~15,700 token的提示:冷启动143.1秒,热启动0.99秒
重要的区别在于,它并不声称让生成速度更快。它避免了重复已经完成的提示评估工作。它还包含对混合架构的处理,例如Qwen 3.5/3.6、Gemma 4和GLM-4.7,在这些架构中恢复循环状态比恢复传统的仅注意力KV缓存更复杂。
这里还有其他人尝试过吗?它对我非常有帮助,但我还没有在任何其他地方看到过它的介绍。
相似文章
Llama-Server 正在丢弃您完美的KV缓存,以及如何修复
本文详细介绍了一个关键bug:在llama-server中,由于缺少检查点元数据,恢复的KV缓存会立即被丢弃。文章提供了一个117行的修复方法,使用sidecar文件跨重启持久化检查点,实现了约720倍的预填充加速。
llama.cpp 有一个加速 KV 缓存解码的巧妙技巧
llama.cpp 的 webUI 中有一个设置,它会将生成的 token 重新发送到 KV 缓存,从而显著减少提示处理延迟,提高长生成或工具调用的响应速度,且没有明显的权衡。
使用llama-server自托管?修复每次轮次中提示缓存重载的问题
一份故障排除指南展示了将OpenClaw的contextInjection设置从 'always' 更改为 'continuation-skip' 后,如何解决使用 llama-server 时每次对话都会重载提示缓存的问题,从而在长时间会话中实现100倍的加速。
如何防止 llama.cpp 将数据卸载到交换空间?
用户寻求关于如何防止 llama.cpp 在 RAM 完全耗尽前将 KV 缓存卸载到交换空间的建议,并分享了他们在配备 96GB RAM 的 M2 Max 和大型 Qwen 模型上的配置。
也许将KV缓存卸载到RAM并不差
一位用户分享了在llama.cpp中将KV缓存卸载到RAM的经验,在释放显存以便运行更大模型和上下文窗口的同时,实现了相近的速度,表明这种权衡通常是值得的。