Misc. bug: Consistent OOM crashes when using -np 3

问题场景

用户在 Linux 上运行 llama.cpp 的 llama-server，加载 Qwen3.8-27B-GGUF:Q8_K_XL 模型，使用 -np 3 开启 3 个并发槽位、每槽 context 262k，并启用了 MTP 草稿投机（--spec-type draft-mtp）、layer 分层 offload 及张量拆分。发起 2 个长上下文并发请求后，几分钟内系统 RAM 快速上涨，最终服务因 OOM 被杀。用户表示此前长期从 master 构建使用同一套配置都正常，只是最近一次构建后才开始出现。

报错原文

Misc. bug: Consistent OOM crashes when using -np 3

原因分析

根据维护者在 Issue 中的说明，#28302 的改动使 server 生成的 checkpoint 数量比以前更多，因此 --cache-ram 指定的主机缓存会被更快地填满。用户设置了 --cache-ram 131072（约 128GB）并配合 --ctx-checkpoints 128，在长时间、多并发、长上下文的使用下，host 内存被 checkpoint 缓存逐步占满，最终触发 OOM。这属于配置与新增行为不匹配，而非未知的内存泄漏。

环境排查

• 确认 llama.cpp 版本/构建号（本例为 0.4.0-dev, build 10930, commit 56381e407）。
• 确认是否包含 #28302 之后的改动。
• 确认 -np 并发槽位数与每槽 context 大小。
• 确认 --ctx-checkpoints 与 --cache-ram 的取值（本例为 128 与 131072）。
• 确认实际可用主机内存是否与 --cache-ram 设定量级匹配（本例 192GB DDR4）。
• 确认 Linux 下的 OOM killer 或系统内存监控是否记录了进程被杀的时间点与峰值。

解决步骤

1. 停止当前 llama-server 进程。
2. 编辑启动脚本，删除以下两行参数：

     --ctx-checkpoints 128 \
     --cache-ram 131072 \
   

3. 其余参数（-np 3、-c、-ts、-fa on 等）保持不变，重新启动服务。
4. 用与之前相同的 2 个长上下文并发请求复测，观察系统 RAM 是否仍持续增长。
5. 若必须保留缓存参数，可将 --cache-ram 调低到一个明显小于物理内存、并预留模型与 KV cache 开销的值（可优先尝试，具体数值需自行按环境实测）。

验证方法

移除 --ctx-checkpoints 与 --cache-ram 后，重放原先触发崩溃的 2 并发长上下文请求，持续运行数分钟以上，确认系统 RAM 不再快速上涨、llama-server 不再被 OOM 终止，即可认为问题解决。

参考来源

ggml-org/llama.cpp #28813

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。