paddleocr 2.8.1 paddlepaddle-gpu 2.6.1 占用大量显存并且只增不减，很快cuda oom

[purplesword]

🔎 Search before asking

• I have searched the PaddleOCR Docs and found no similar bug report.
• I have searched the PaddleOCR Issues and found no similar bug report.
• I have searched the PaddleOCR Discussions and found no similar bug report.

🐛 Bug (问题描述)

你好，我们原本是使用paddleocr==2.7.0.3 paddlepaddle-gpu==2.5.2.post117，一切都正常，最近我们升级到paddleocr 2.8.1 paddlepaddle-gpu 2.6.1 (cuda 11.8)，但是现在很快cuda OOM。看log是推理占用大量显存并且只增不减从不释放。（我们已经用了paddle.device.cuda.empty_cache() - 非常奇怪，相同的batchsize设置，以前基本上模型只需要占用2-3G的显存，现在很快就16-24G，甚至放到显存更大的机器直接上到40+G。

请问可能是什么有问题？除了退回原先版本之外还有别的释放显存方法吗？

🏃‍♂️ Environment (运行环境)

当前

OS: linux ubuntu 22.04  
paddleocr 2.8.1 
paddlepaddle-gpu 2.6.1 
cuda 11.8 
cudnn 8.9.6 
python 3.12 

之前运行正常时候

OS: linux ubuntu 20.04
paddleocr: 2.7.0.3
paddlepaddle-gpu 2.5.2.post117
cuda 11.7
cudnn 8.5.0
python 3.10

🌰 Minimal Reproducible Example (最小可复现问题的Demo)

目前很难提供，但是只有我们遇到了这样的问题吗？

[GreatV]

换paddle3.0 beta 1试试

[raoyutian]

CUDNN版本问题。有的CUDNN版本有内存泄漏漏洞。cuda 11.8 建议cudnn版本使用-8.9.7.29。
本人商业库封装库长达半年稳定运行。

[purplesword]

奇怪，似乎是2.8.1的问题，我退到paddleocr 2.7.3就没有这个显存泄漏的问题了

[Tpinion]

奇怪，似乎是2.8.1的问题，我退到paddleocr 2.7.3就没有这个显存泄漏的问题了

！！！感恩！！！好像是这样，我也尝试降级了下，这个问题好像确实解决了。

2.7.3在仅检测的方法实现上，有个语法BUG，我看2.8.1解决了，就升了个版本。因为自己正好上了不少新Feature，我还以为OOM是负载变大暴露出来的问题。（要不是看到你的评论，我都忘了还有这个变量）QAQ

[Tpinion]

补充下现象，方便排查：

1. 不是每次预测都会导致显存分配量增加（大概是每次收到比之前更大的图像时，会触发一次新的显存分配，这仅是我的观察）
2. 泄露发生在，新的显存分配后，此前分配的显存并没有释放。（empty_cache对此情况没有作用）

[lwinhong]

我这用2.8.1的，内存也是只增不减，一直崩溃

[myhloli]

目前测下来发现两个点：

1. 2.7.3的rec_batch_size参数不生效，改成多少实际上都是1，在本地测试样本上占用显存1.7G
2. 2.8.x~2.9.0的rec_batch_size 是生效的，默认配置是6，在同样的样本上测试，显存占用7G，rec_batch_size 改成1后，显存占用2.6G

比较直观的能感受出，在不调整rec_batch_size 的情况下，仅从2.7.3切换到2.8+的版本，显存占用涨了4倍以上，实际上修改rec_batch_size 为1后，显存占用上涨50%左右，虽然单batch的情况显存占用涨的不是特别多，但是对小显存设备十分不友好，还是希望能够查清楚原因

[chelseaztq]

我解决了，之前安装的是paddle 2.6.0-post 117 后面换成了最新的paddle 3.0.0 b2 cu118版本的（我的显卡驱动最高支持到12.1 paddle官方还有个cu123的 那个没试过）
然后之前的现象是 我解析一批pdf shape 各不相同 最大长边应该在2000左右 ，然后我的检测最长边设置的是min 736 ，但是理论上说2000左右的最长边 最大显存开销应该不大，但是很奇怪 ，在推理了好几个不同的pdf后 显存涨到了15个 g左右，
然后我换了paddle3.0.0 b2版本后 先保持min 736不变 然后讲一张4000×4000的图拿进去推理 经过det与rec 观测到显存来到4g左右 ，接下来我根据2.6.0版本paddle 的预测过程一样，推理了相同的几个pdf ，这个时候显存再也没有超过4个g左右了（因为他们的分辨率都比4000×4000低）。
最后我还做了个实验，当你的ocr是服务的时候（就像我一样 用fastapi 进行算法部署），最好设置最大长边resize 参数为max 具体值根据你显存决定，因为你不知道用户上传的图片分辨率有多大，设置个上限保证显存不会因为图片太大而oom，我测试下来 max设置为2048 在批量推理很多图与pdf后，显存始终在2320左右，再也不会增加或变化了，希望对你有帮助

还有你们说的 rec batch的问题 我似乎没遇到 paddle3.0.0 b2 cu118

[jesszgc]

这个貌似是paddle的问题，我试了的2.9.1，也是显存在不停的涨直到oom，paddle 升级到3.0.0，就没有了

[myhloli]

奇怪，似乎是2.8.1的问题，我退到paddleocr 2.7.3就没有这个显存泄漏的问题了

！！！感恩！！！好像是这样，我也尝试降级了下，这个问题好像确实解决了。

2.7.3在仅检测的方法实现上，有个语法BUG，我看2.8.1解决了，就升了个版本。因为自己正好上了不少新Feature，我还以为OOM是负载变大暴露出来的问题。（要不是看到你的评论，我都忘了还有这个变量）QAQ

老哥能说下2.7.3仅检测的语法bug是什么吗，我现在因为显存占用的原因只能用2.7.3版本，而且也需要用到仅检测的功能