如何在重新启动 llama.cpp 后处理长上下文会话?

Reddit r/LocalLLaMA 新闻

摘要

用户提出在 llama.cpp 中为长上下文会话实现自动缓存机制,以避免重启后的重复预填充,提升在较慢硬件上的可用性。

我在一个128GB的Strix Halo上运行本地模型,并且在测试构建、后端和模型参数时经常重启 llama.cpp。令人烦恼的是长时间运行的代理会话。Hermes/OpenCode 会话很容易达到 50k-100k 的上下文,每次重启后都必须重新预取相同的上下文,这可能需要几分钟时间。我知道 llama-server 已经有了 slot save/restore API,但个人认为,每个代理或客户端都应该需要为此进行自定义集成。理想情况下,推理服务器应该自动处理这个。类似于:使用对话 -> 缓存 KV/预填充状态到磁盘 -> 重启 llama.cpp/重启 -> 相同对话返回 -> 自动恢复最长的有效缓存前缀。旧缓存可以通过大小/LRU 策略简单驱逐。DS4 似乎实现了类似的功能:https://github.com/antirez/ds4 我理解为 llama.cpp 支持的每种架构通用地实现这一点可能很困难。但先为几个流行的模型/架构支持它是否有意义,例如 Qwen3.8 27B?对于像 Strix Halo 这样预填充较慢的硬件,避免重复的 50k-100k 预填充会在日常使用中产生非常明显的差异。有没有人尝试过在服务器端透明地实现这个,而不是要求客户端自己管理保存/恢复?英语不是我的母语,所以我先用英语打出来,然后翻译的。
查看原文

相似文章

llama.cpp 有一个加速 KV 缓存解码的巧妙技巧

Reddit r/LocalLLaMA

llama.cpp 的 webUI 中有一个设置,它会将生成的 token 重新发送到 KV 缓存,从而显著减少提示处理延迟,提高长生成或工具调用的响应速度,且没有明显的权衡。

如何防止长对话耗尽整个上下文窗口?

Reddit r/openclaw

一位用户分享了一个自定义的插件SDK钩子,该钩子逐渐压缩较早的轮次,同时保留最近的轮次不压缩,以防止在长时间OpenClaw会话中上下文窗口耗尽,将重新发送的上下文减少了80%。