llama.cpp 多线程陷阱：停止信号、上下文切换与 Prompt Cache 的三大致命 Bug

在 llama.cpp 项目近期的技术回顾中，作者披露了三个与多线程交互直接相关的关键缺陷，这些缺陷会导致模型在实际使用中出现不可预期的行为和性能退化。

1. 停止信号未被传递或执行 服务器在收到客户端的停止请求后，并未向正在运行的模型实例发送相应的中止指令。结果是，即便前端 UI 已显示“已停止”，模型仍继续在后台消耗算力并生成输出，导致资源浪费和潜在的安全风险。

2. 线程切换导致上下文混淆 llama.cpp 在不同工作线程（如 VS Code 的 Cline 线程、Roo 线程）之间切换时，未能正确隔离各自的执行上下文。模型在新线程启动后仍会沿用旧线程的内部状态（例如已处理到第 17k token），但随后使用新线程的上下文（第 40k token）继续推理，产生明显的上下文错位。

3. Prompt Cache 未彻底清理 切换线程时，先前的 Prompt Cache 并未被完整释放。随着累计的上下文量增长，模型的推理速度出现显著下降；即便切换到空闲线程，速度也难以恢复到基准水平。这表明缓存层仍残留旧数据，导致系统状态混乱。

解决建议

• 在服务器层面实现可靠的 stop‑signal 传播机制，确保模型实例能够即时响应中止指令。
• 为每个工作线程分配独立的执行上下文对象，切换时强制销毁旧上下文并重新初始化。
• 在线程切换前强制清空 Prompt Cache（如调用 llama_kv_cache_clear()），或在库内部加入自动清理逻辑。

实战提示：在调试多线程环境时，可通过在代码入口处打印线程 ID 与当前 token 位置，快速定位上下文错位的根源。

以上三点若得到修复，将显著提升 llama.cpp 在本地部署、插件化以及 RAG/Agent 场景下的可靠性与性能。