Lin Manhui

> 考虑比较可能和框架的内存分配策略有关，建议可以试试这个issue里提到的`empty_cache`方案：[#16011](https://github.com/PaddlePaddle/PaddleOCR/issues/16011) @fhkankan 可以先试试这个

> > > 一样的问题，GPU还可以调用cuda.empty_cache()，NPU设备没法清缓存，运行一段时间必定OOM > > > > > > 请问定期调用`gc.collect`有帮助吗 > > 没有用 这样的话大概率和框架的内存/缓存分配策略有关了，建议也可以到paddle框架的repo提一个issue，那边会有更专业的开发者提供可能的解决方式。

> > > 考虑比较可能和框架的内存分配策略有关，建议可以试试这个issue里提到的`empty_cache`方案：[#16011](https://github.com/PaddlePaddle/PaddleOCR/issues/16011) > > > > > > [@fhkankan](https://github.com/fhkankan) 可以先试试这个 > > 不是显存，是内存在累加不释放 不好意思我之前看错了。请问方便用[tracemalloc标准库](https://docs.python.org/3/library/tracemalloc.html)看看是什么对象占据了大量内存吗？

> 手动屏蔽如下代码，则内存不会增加 > > result = pipeline.predict(file_base64) 这一句代码里面包含了很多复杂的步骤，我们可能需要看看具体是哪个步骤出现了内存泄漏或者其他情况

> > > > 考虑比较可能和框架的内存分配策略有关，建议可以试试这个issue里提到的`empty_cache`方案：[#16011](https://github.com/PaddlePaddle/PaddleOCR/issues/16011) > > > > > > > > > [@fhkankan](https://github.com/fhkankan) 可以先试试这个 > > > > > > 不是显存，是内存在累加不释放 > > 不好意思我之前看错了。请问方便用[tracemalloc标准库](https://docs.python.org/3/library/tracemalloc.html)看看是什么对象占据了大量内存吗？ 通过这个方式，可以不用猜测，直接定位到是哪些对象占据了内存

这样修改之后，继续通过tracemalloc定位，哪些对象占据内存较大呢？

请问你启动VLM推理服务了吗？

可以参考文档中的说明

> [@Bobholamovic](https://github.com/Bobholamovic) 你好，上面的客户端请求脚本能之间在windows开发环境使用吗？（相关依赖paddleocr、paddlepaddle已装） 在Windows上建议使用WSL或者Docker，我们也在高优适配Windows原生推理中。

> 使用docker compose 部署，容器已经启动，但是通过访问[http://127.0.0.1:8080/layout-parsing接口后，后台api服务报错如下：](http://127.0.0.1:8080/layout-parsing%E6%8E%A5%E5%8F%A3%E5%90%8E%EF%BC%8C%E5%90%8E%E5%8F%B0api%E6%9C%8D%E5%8A%A1%E6%8A%A5%E9%94%99%E5%A6%82%E4%B8%8B%EF%BC%9A) ERROR: Exception in ASGI application 2025-11-01 16:00:29 Traceback (most recent call last): 2025-11-01 16:00:29 File "/usr/local/lib/python3.10/site-packages/uvicorn/protocols/http/h11_impl.py", line 403, in run_asgi 2025-11-01 16:00:29 result = await app(...