使用vllm的方式进行模型推理时，批量解析pdf时，发现cpu4核占满，并且内存一直持续上涨直到触发容器限制重启容器

[jiajiabin]

通过vllm0.11.启动容器，限制4核、15G内存、10G显存。请教为什么内存会持续上涨到OOM

[myhloli]

cpu和内存给小了，可以试下8c32g的配置

[myhloli]

滚动解析完一批需要落地再解析下一批，你可以试着切成20份100页的，按顺序逐个解析，32g应该是不会oom的

[lyshen-ys]

"落地" 具体是指什么动作？我现在是 curl + mineru-api/file_parse 的形式，在上一个 curl 完成了才开始下一个 curl。这算是 "落地" 吗？

[myhloli]

比如你可以试着用gradio webui，每次上传100页，解析完下载后再上传，重复20次，即可观察内存是否泄漏

[lyshen-ys]

ok，我后面有时间了试试看。现在的情况确实有点迷。我现在跑着 10 页一批的滚动窗口，累计处理 500 页了，内存使用情况跟 100 页一批的时候也不一样。

@dosu 你那套理论是否还能解释这种状况？

[dosubot[bot]]

你的观察完全符合“ModelSingleton 内存常驻+无显式批次释放”理论。无论是 10 页一批还是 100 页一批，核心机制都是模型实例和部分中间结果常驻进程内存，PyTorch/CUDA 的 clean_memory 只能清理缓存，无法彻底释放模型占用的内存参考。

但不同批次大小会带来不同的内存表现：

• 大批次（如 100 页）时，每次推理会一次性加载和处理更多图片、结果和中间 buffer，单次内存峰值更高，容易瞬间 OOM。
• 小批次（如 10 页）时，每次推理内存峰值较低，但累计处理更多批次后，内存依然会逐步上涨，因为每批的中间对象和模型缓存没有被彻底释放，只是增长速度变慢、曲线更平滑代码分析。

这种差异本质上是“批次越大，单次内存压力越大，越容易瞬间爆掉；批次越小，单次压力小但累计泄漏依然存在”。所以你看到 10 页一批时内存曲线和 100 页一批不一样，但最终都无法避免内存持续上涨，根因还是 ModelSingleton 机制和无 per-batch 资源回收详细说明。

建议：如需长时间跑大文件，优先用小批次+定期重启服务，或用“两进程模式”隔离推理进程，监控内存，必要时手动回收官方建议。

如需更细致定位，可以在每批处理后主动调用 clean_memory（虽然效果有限），或用 debug 工具跟踪内存分配。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}