PaddleOCR本地部署（安装，使用，模型优化/加速）

之前在服务器上要训练ppocr模型&＃xff0c;所以需要额外安装PaddlePaddle&＃xff0c;但是自己训练后已经把模型变成了推理模型&＃xff0c;直接可以使用paddleocr package这一个包来进行运行&＃xff0c;所以在迁移到别的环境时候&＃xff0c;可以不再进行paddlepaddle的安装。

参考&＃xff1a;
和之前的文章&＃xff1a;

1.1 还是需要paddle

根据&＃xff1a;paddleocr package使用说明
一开始以为&＃xff1a;

pip install "paddleocr>&＃61;2.0.1"


但是果然&＃xff1a;

so就在本机安装一下paddle好了&＃xff0c;但是也仅需要paddle&＃xff0c;参考&＃xff1a;快速安装

# windows下 直接 python 不是python3
python3 -m pip install paddlepaddle&＃61;&＃61;2.0.0 -i https://mirror.baidu.com/pypi/simple


安装好再去运行&＃xff0c;遇到经典的shapely错误&＃xff0c;参考&＃xff1a;Win10 CPU环境&＃xff0c;OSError: [WinError 126] 找不到指定的模块
#212

windows下安装shapely&＃xff0c;需要从这里下载&＃xff0c;然后再

pip uninstall shapely
pip install Shapely-1.7.1-cp37-cp37m-win_amd64.whl
conda install shapely -c conda-forge


或者

更名为Shapely-1.7.0-cp39-cp39-win_amd64.rar&＃xff0c;然后解压缩&＃xff0c;从其子目录shapely\DLLs\中找到geos_c.dll&＃xff0c;并将geos_c.dll拷贝到conda的环境&＃xff08;我的命名是ocr&＃xff09;目录 C:\Users\myusername\Miniconda3\envs\ocr\Library\bin中。问题解决
同时把geos.dll和geos_c.dll拷贝至你anaconda环境中的library\bin中

最简单的方案&＃xff01;&＃xff01;&＃xff01;
或者&＃x1f356;&＃xff08;我直接选择了这个方案&＃xff0c;成功&＃xff01;&＃xff09;

删除anaconda中之前装的shaply&＃xff08;文件夹和程序都删掉&＃xff09;&＃xff0c;重新安装&＃xff0c;

参考&＃xff1a;anaconda3&＃43; paddleOCR安装使用

1.2 确认各种包和环境

本机上&＃xff0c;使用了anaconda默认环境&＃xff0c;各种版本如下&＃xff1a;

• python 3.7.6
• paddleocr 使用pip安装后看到的版本是&＃xff1a; paddleocr-2.0.6-py3

requirments文件中的内容&＃xff1a;

shapely
scikit-image &＃61;&＃61; 0.17.2
imgaug &＃61;&＃61; 0.4.0
pyclipper
lmdb
opencv-python &＃61;&＃61; 4.2.0.32
tqdm
numpys
visualdl
python-Levenshtein

1.3 可能不需要paddle&＃xff1f;

根据paddleocr的FAQ文档

Q3.4.23&＃xff1a;安装paddleocr后&＃xff0c;提示没有paddle
A&＃xff1a;这是因为paddlepaddle gpu版本和cpu版本的名称不一致&＃xff0c;现在已经在whl的文档里做了安装说明。

但是参考&＃xff1a;预测示例 (Python)
可知&＃xff0c;想使用paddle系列的模型&＃xff0c;是必须要使用paddle的inference的。

所以还是老老实实安装上paddle吧

改改路径就好了。

其中有一点需要注意&＃xff1a;

[[[[72.0, 149.0], [113.0, 151.0], [113.0, 166.0], [72.0, 163.0]], (&＃39;40&＃39;, 0.7172388)],
[[[62.0, 170.0], [237.0, 175.0], [233.0, 300.0], [58.0, 294.0]], (&＃39;1076&＃39;, 0.9666834)]]


可以看到输出文件的结构&＃xff0c;每一个文本识别结果&＃xff0c;都包括四个点的坐标&＃xff0c;一个二位数组&＃xff0c;以及一个最后识别结果的元组&＃xff08;识别的文字结果&＃xff0c;置信度&＃xff09;&＃xff0c;结构就是一个数组涵盖这两部分内容。
如果是多个文本识别结果&＃xff0c;会有再外层的一个数组。

2.1 配置摄像头&＃xff0c;读取&＃xff0c;识别&＃xff0c;显示

参考另一个文章&＃xff1a;python opencv调用摄像头识别并绘制结果

发现一个神奇的事情&＃xff0c;当你插着usb摄像头启动电脑时&＃xff0c;cap &＃61; cv2.VideoCapture(0)&＃xff0c;usb摄像头的序号就是0&＃xff1b;当启动电脑之后再插上usb摄像头&＃xff0c;usb摄像头的序号就是2&＃xff08;我的电脑是一个前置&＃43;一个后置摄像头&＃xff09;

关于摄像头参数的调节&＃xff0c;可以参考另一篇文章&＃xff1a;Opencv摄像头相关参数

2.3 检测模型的问题

由于使用了摄像头读取图像&＃xff0c;图片背景比较杂&＃xff0c;对检测有难度&＃xff0c;发现使用DB效果不是很好。&＃xff08;由于还没怎么研究过检测模型&＃xff0c;所以很难判断问题到底出在哪里&＃xff09;

2.3.1 换个模型

参考&＃xff1a;
paddleocr文档

可以看到&＃xff0c;其实EAST的准确率要比DB高&＃xff0c;虽然存在过检。

EAST高效&＃xff0c;准确&＃xff0c;但对弯曲文本检测较差。

在paddleocr.py文件中看到&＃xff1a;

parser.add_argument("--det_algorithm", type&＃61;str, default&＃61;&＃39;DB&＃39;)
# 调用时修改为EAST&＃xff0c;但是报错


然后看到代码中有&＃xff1a;

SUPPORT_DET_MODEL &＃61; [&＃39;DB&＃39;]
VERSION &＃61; 2.0
SUPPORT_REC_MODEL &＃61; [&＃39;CRNN&＃39;]
BASE_DIR &＃61; os.path.expanduser("~/.paddleocr/")


结论&＃xff1a;
发现下载的是预训练模型&＃xff0c;不是推理模型&＃xff0c;无法使用EAST算法。

2.3.2 限定检测位置

设置一个按键&＃xff0c;opencv摄像头有键盘响应&＃xff0c;可以有相应的操作&＃xff0c;参考&＃xff1a;cv2.VideoCapture.get、set详解可以获取相机参数。

另外&＃xff0c;参考&＃xff1a;opencv python全屏显示、置窗口大小和位置

cap&＃61;cv2.VideoCapture(1)cv2.VideoCapture.get(3) # CV_CAP_PROP_FRAME_WIDTH 在视频流的帧的宽度
cv2.VideoCapture.get(4) # CV_CAP_PROP_FRAME_HEIGHT 在视频流的帧的高度# 除了get&＃xff0c;还有set
capture.set(CV_CAP_PROP_FRAME_WIDTH, 1080); 宽度
capture.set(CV_CAP_PROP_FRAME_HEIGHT, 960); 高度frame[top:bottom,left:right]


参考&＃xff1a;python cv2图片剪裁

3.0 基本情况

检测时间比较久&＃xff0c;检测&＃43;识别的时间差不多是0.7~1.2s&＃xff0c;在cpu机器上&＃xff0c;其实比较尴尬。

先查看一下模型的size&＃xff0c;运行检测的时候会打印出模型的配置信息&＃xff0c;可以从这里看到

Namespace(cls_batch_num&＃61;6, cls_image_shape&＃61;&＃39;3, 48, 192&＃39;,
cls_model_dir&＃61;&＃39;C:\\Users\\huangshan/.paddleocr/2.1/cls&＃39;, cls_thresh&＃61;0.9, det&＃61;True,
det_algorithm&＃61;&＃39;DB&＃39;, det_db_box_thresh&＃61;0.3, det_db_thresh&＃61;0.2,
det_db_unclip_ratio&＃61;2.2, det_east_cover_thresh&＃61;0.1, det_east_nms_thresh&＃61;0.2,
det_east_score_thresh&＃61;0.8, det_limit_side_len&＃61;960, det_limit_type&＃61;&＃39;max&＃39;,
det_model_dir&＃61;&＃39;C:\\Users\\huangshan/.paddleocr/2.1/det/ch&＃39;, drop_score&＃61;0.5,
enable_mkldnn&＃61;False, gpu_mem&＃61;8000, image_dir&＃61;&＃39;&＃39;, ir_optim&＃61;True, label_list&＃61;[&＃39;0&＃39;,
&＃39;180&＃39;], lang&＃61;&＃39;ch&＃39;, max_text_length&＃61;25, rec&＃61;True, rec_algorithm&＃61;&＃39;CRNN&＃39;,
rec_batch_num&＃61;6, rec_char_dict_path&＃61;&＃39;C:/shaiic_work/ZhiNengKeJiOCR/digit.txt&＃39;,
rec_char_type&＃61;&＃39;ch&＃39;, rec_image_shape&＃61;&＃39;3, 32, 320&＃39;,
rec_model_dir&＃61;&＃39;C:/shaiic_work/ZhiNengKeJiOCR/rec_crnn_digit&＃39;, use_angle_cls&＃61;False,
use_dilation&＃61;False, use_gpu&＃61;False, use_pdserving&＃61;False, use_space_char&＃61;True,
use_tensorrt&＃61;False, use_zero_copy_run&＃61;False)


采用的检测模型是自带的&＃xff0c;位置在&＃xff1a;det_model_dir&＃61;&＃39;C:\\Users\\huangshan/.paddleocr/2.1/det/ch&＃39;&＃xff0c;检测模型只有3M

先确认一下这个默认模型的信息&＃xff0c;从代码中可以看到&＃xff1a;

&＃39;rec&＃39;: {&＃39;ch&＃39;: {&＃39;url&＃39;:&＃39;https://paddleocr.bj.bcebos.com/dygraph_v2.0/ch/ch_ppocr_mobile_v2.0_rec_infer.tar&＃39;,&＃39;dict_path&＃39;: &＃39;./ppocr/utils/ppocr_keys_v1.txt&＃39;},


ch_ppocr_mobile_v2.0_rec_infer.tar所以这个默认的模型目测已经是剪枝过的了。同时&＃xff0c;参考&＃xff1a;PP-OCR 2.0系列模型列表文档

识别模型是自己训练之后转为推理模型的&＃xff0c;有94MB&＃xff0c;确实对于比较简单的一块数字仪表识别很重。

X 自己模型的速度和全用默认的速度对比

上面已经给了几个自己模型的用时图&＃xff0c;下面给几个全用默认的时间图

可知&＃xff1a;
不使用mkldnn加速的情况下&＃xff0c;使用默认的检测&＃43;自己的识别速度基本在0.7~1.2s
不使用mkldnn加速的情况下&＃xff0c;使用默认的检测&＃43;默认的识别速度基本在0.7~0.9s
所以虽然识别时间本来就不到0.2s&＃xff0c;但是可以变得更快&＃xff0c;这样就只剩检测时间了基本上。
个人猜测&＃xff0c;是不是第一阶段检测模型是剪枝后的&＃xff0c;比如是8位精度&＃xff0c;第二阶段识别模型也是8位精度&＃xff0c;这样系统处理是一致的。
如果两个阶段数据精度不一样&＃xff0c;系统处理的时候不一致&＃xff0c;是不是也会造成数据差异。

3.1 端侧部署

参考文档&＃xff1a;端侧部署
这种会帮助有效减小模型size&＃xff0c;但是推理速度似乎没有强调会不会变快。

3.2 加速

直接去FAQ文档中搜索加速&＃xff0c;可以看到以下结果.

Q3.1.73: 如何使用TensorRT加速PaddleOCR预测&＃xff1f;
A&＃xff1a; 目前paddle的dygraph分支已经支持了python和C&＃43;&＃43; TensorRT预测的代码&＃xff0c;python端inference预测时把参数–use_tensorrt&＃61;True即可&＃xff0c; C&＃43;&＃43;TensorRT预测需要使用支持TRT的预测库并在编译时打开-DWITH_TENSORRT&＃61;ON。 如果想修改其他分支代码支持TensorRT预测&＃xff0c;可以参考PR。
注&＃xff1a;建议使用TensorRT大于等于6.1.0.5以上的版本。

另外&＃xff0c;搜索速度&＃xff0c;可以看到&＃xff1a;

Q3.4.40: 使用hub_serving部署&＃xff0c;延时较高&＃xff0c;可能的原因是什么呀&＃xff1f;
A: 首先&＃xff0c;测试的时候第一张图延时较高&＃xff0c;可以多测试几张然后观察后几张图的速度&＃xff1b;其次&＃xff0c;如果是在cpu端部署serving端模型&＃xff08;如backbone为ResNet34&＃xff09;&＃xff0c;耗时较慢&＃xff0c;建议在cpu端部署mobile&＃xff08;如backbone为MobileNetV3&＃xff09;模型。

这里建议在cpu端部署mobile模型

也可以只看预测部署部分&＃xff0c;还可以看到以下比较有用的信息&＃xff1a;

Q3.4.1&＃xff1a;如何pip安装opt模型转换工具&＃xff1f;
A&＃xff1a;由于OCR端侧部署需要某些算子的支持&＃xff0c;这些算子仅在Paddle-Lite 最新develop分支中&＃xff0c;所以需要自己编译opt模型转换工具。opt工具可以通过编译PaddleLite获得&＃xff0c;编译步骤参考lite部署文档 中2.1 模型优化部分。

&＃x1f371;Q3.4.2&＃xff1a;如何将PaddleOCR预测模型封装成SDK
A&＃xff1a;如果是Python的话&＃xff0c;可以使用tools/infer/predict_system.py中的TextSystem进行sdk封装&＃xff0c;如果是c&＃43;&＃43;的话&＃xff0c;可以使用deploy/cpp_infer/src下面的DBDetector和CRNNRecognizer完成封装

3.2.1 CPU下使用mkldnn加速

由于慢的地方主要是检测&＃xff0c;所以即便对剪枝进行优化也不是很有效&＃xff0c;所以这里先尝试使用mkldnn来进行加速。

Q3.1.77: 使用mkldnn加速预测时遇到 &＃39;Please compile with MKLDNN first to use MKLDNN’
A&＃xff1a; 报错提示当前环境没有mkldnn&＃xff0c;建议检查下当前CPU是否支持mlkdnn&＃xff08;MAC上是无法用mkldnn&＃xff09;&＃xff1b;另外的可能是使用的预测库不支持mkldnn&＃xff0c; 建议从这里下载支持mlkdnn的CPU预测库。

Q1.1.10&＃xff1a;PaddleOCR中&＃xff0c;对于模型预测加速&＃xff0c;CPU加速的途径有哪些&＃xff1f;基于TenorRT加速GPU对输入有什么要求&＃xff1f;
A&＃xff1a;&＃xff08;1&＃xff09;CPU可以使用mkldnn进行加速&＃xff1b;对于python inference的话&＃xff0c;可以把enable_mkldnn改为true&＃xff0c;参考代码&＃xff0c;对于cpp inference的话&＃xff0c;在配置文件里面配置use_mkldnn 1即可&＃xff0c;参考代码
&＃xff08;2&＃xff09;GPU需要注意变长输入问题等&＃xff0c;TRT6 之后才支持变长输入

直接在inference代码中将enable_mkldnn改为true&＃xff0c;确实变快了一些。





之前是0.7~1.2&＃xff0c;现在基本就是0.6-0.98&＃xff0c;反正没有超过1s的&＃xff0c;0.8的比较多。

3.2.2 修改参数

想起来还有一些参数可以考虑修改&＃xff0c;比如&＃xff1a;

parser.add_argument("--det_limit_side_len", type&＃61;float, default&＃61;960)


根据FAQ文档

Q3.3.2&＃xff1a;配置文件里面检测的阈值设置么?
A&＃xff1a;有的&＃xff0c;检测相关的参数主要有以下几个&＃xff1a;
det_limit_side_len&＃xff1a;预测时图像resize的长边尺寸
det_db_thresh: 用于二值化输出图的阈值
det_db_box_thresh:用于过滤文本框的阈值&＃xff0c;低于此阈值的文本框不要
det_db_unclip_ratio: 文本框扩张的系数&＃xff0c;关系到文本框的大小
这些参数的默认值见代码&＃xff0c;可以通过从命令行传递参数进行修改。

det_limit_side_len默认是960&＃xff0c;考虑改成32的倍数&＃xff0c;但是改小一些&＃xff0c;比如320。



det_limit_side_len改的再小一些&＃xff0c;256&＃xff0c;识别部分最大长度max_text_length&＃61;5&＃xff0c;rec_image_shape&＃61;(3,32,256)&＃xff0c;之前默认是(3,32,320)。
很奇怪&＃xff0c;一开始速度是0.6&＃xff0c;后来逐渐稳定再0.8~0.9之间。打开内存任务管理器发现&＃xff0c;这个东西内存占用可以达到98%&＃xff1f;&＃xff1f;&＃xff1f;&＃xff1f;
我本机是32G的内存&＃xff0c;无语。

另外&＃xff0c;关于常见PaddleOCR包里给出的参数说明&＃xff0c;参考&＃xff1a;paddleocr package使用说明最后有一个参数说明表&＃xff1a;

关于检测可控的参数有很多&＃xff0c;但是关于识别&＃xff0c;其实并没有很多可以进行调优的参数。

3.2.3 内存泄露

根据FAQ文档&＃xff0c;

Q3.4.43: 预测时显存爆炸、内存泄漏问题&＃xff1f;
A: 打开显存/内存优化开关enable_memory_optim可以解决该问题&＃xff0c;相关代码已合入&＃xff0c;查看详情。

可以看到这个代码的位置&＃xff1a;
https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.1/tools/infer/utility.py#L153

Q3.4.17&＃xff1a; 预测内存泄漏问题
A&＃xff1a;1. 使用hubserving出现内存泄漏&＃xff0c;该问题为已知问题&＃xff0c;预计在paddle2.0正式版中解决。相关讨论见issue
A&＃xff1a;2. C&＃43;&＃43; 预测出现内存泄漏&＃xff0c;该问题已经在paddle2.0rc版本中解决&＃xff0c;建议安装paddle2.0rc版本&＃xff0c;并更新PaddleOCR代码到最新。

2021.6.3查看那个issue看到&＃xff1a;

这个更新是26天前&＃xff0c;查看自己的环境&＃xff0c;似乎不是2.0rc&＃xff0c;换。

所以虽然找不到paddle2.0rc版本&＃xff0c;但是可以直接去下载2.1版本&＃xff0c;开始使用

python -m pip install paddlepaddle -i https://mirror.baidu.com/pypi/simple
# 直接用这个会显示已经安装了2.0&＃xff0c;所以需要
pip install --upgrade paddlepaddle -i https://mirror.baidu.com/pypi/simple
# 更新到最新&＃xff0c;就是2.1


改了之后&＃xff0c;内存依然占用量很高&＃xff0c;而且推理速度还变慢了。。。。都超过1s了&＃xff0c;但是效果好像好了一些&＃xff0c;连一些虚的都变好了。换成自带的识别模型之后&＃xff0c;也比之前时间长了&＃xff0c;无语。
但是更新到2.1之后&＃xff0c;打开mkldnn&＃xff0c;速度变快了&＃xff0c;基本控制在0.3-0.5s。。。但是内存占用是100%基本上。



加速之后&＃xff0c;超级快&＃xff0c;但是内存占用非常高。

最后的结论
内存泄漏是因为开启了mkldnn&＃xff0c;需要关闭。
同时cpu thread数量改为1&＃xff0c;不然还是会有很高的内存占用率&＃xff0c;同时改成1&＃xff0c;其实速度影响并不大。

3.2.4 内存泄漏的问题记录

发现paddle的issue中有很多说速度很慢的&＃xff1a;

• 使用CPU下进行加速处理&＃xff0c;但是识别的速度将近30S&＃xff0c;请问有什么方法提高嘛&＃xff1f; #2950
  这个用的是服务器端的模型&＃xff0c;看到了server
  
  还有关于PPOCRLabel也是自动标记过程中由快到慢&＃xff1a;

• 关于半自动标注工具PPOCRLabel运行速度由快逐渐变慢的问题 #1391
  

• 类似的也有&＃xff1a;PPOCRLabel自动标注跑着跑着就自己闪退了 #2724

• 有说版本变慢的&＃xff1a;2.x版本比1.x版本慢2倍 #2630
  

• 还有识别时内存一直涨 溢出 #303
  
  虽然这个issue关闭了&＃xff0c;但是下面还是有人再报错。。。
  

3.3 剪枝

在上面下载支持mlkdnn的CPU预测库的时候&＃xff0c;看到了一个很有用的说明文档&＃xff1a;https://paddle-inference.readthedocs.io/en/latest/index.html&＃xff0c;就是针对paddle系列的推理模型的。

模型量化&＃xff08;主要就是剪枝&＃xff09;——X86 CPU 上部署量化模型

大概介绍一下&＃xff0c;搬运

众所周知&＃xff0c;模型量化可以有效加快模型预测性能&＃xff0c;飞桨也提供了强大的模型量化功能。所以&＃xff0c;本文主要介绍在X86 CPU部署PaddleSlim产出的量化模型。
对于常见图像分类模型&＃xff0c;在Casecade Lake机器上&＃xff08;例如Intel® Xeon® Gold 6271、6248&＃xff0c;X2XX等&＃xff09;&＃xff0c;INT8模型进行推理的速度通常是FP32模型的3-3.7倍&＃xff1b;在SkyLake机器上&＃xff08;例如Intel® Xeon® Gold 6148、8180&＃xff0c;X1XX等&＃xff09;&＃xff0c;INT8模型进行推理的速度通常是FP32模型的1.5倍。
X86 CPU部署量化模型的步骤&＃xff1a;
产出量化模型&＃xff1a;使用PaddleSlim训练并产出量化模型
转换量化模型&＃xff1a;将量化模型转换成最终部署的量化模型
部署量化模型&＃xff1a;使用Paddle Inference预测库部署量化模型

一开始其实不太想用剪枝的&＃xff0c;因为慢的原因主要在于检测&＃xff0c;但是检测的模型已经是剪枝后的了&＃xff0c;在比较过全都使用默认的剪枝模型&＃xff08;检测&＃43;识别&＃xff09;&＃xff0c;和使用默认的检测&＃43;自己的识别模型之后&＃xff0c;发现其实还是有些效果的。

但是相比于剪枝的代价&＃xff0c;并不值得。

3.4 其他可能的途径

3.3 更换模型

https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.1/doc/doc_ch/models_list.md

3.4 多进程

FAQ-如何多进程运行paddleocr&＃xff1f;

Q3.4.33: 如何多进程运行paddleocr&＃xff1f;
A&＃xff1a;实例化多个paddleocr服务&＃xff0c;然后将服务注册到注册中心&＃xff0c;之后通过注册中心统一调度即可&＃xff0c;关于注册中心&＃xff0c;可以搜索eureka了解一下具体使用&＃xff0c;其他的注册中心也行。

Q3.4.44: 如何多进程预测
A: 近期PaddleOCR新增了多进程预测控制参数&＃xff0c;use_mp表示是否使用多进程&＃xff0c;total_process_num表示在使用多进程时的进程数。具体使用方式请参考文档。

parser.add_argument("--use_mp", type&＃61;str2bool, default&＃61;False)
# 只能命令行调用
# 使用方向分类器
python3 tools/infer/predict_system.py --image_dir&＃61;"./doc/imgs/00018069.jpg" --det_model_dir&＃61;"./inference/det_db/" --cls_model_dir&＃61;"./inference/cls/" --rec_model_dir&＃61;"./inference/rec_crnn/" --use_angle_cls&＃61;true# 不使用方向分类器
python3 tools/infer/predict_system.py --image_dir&＃61;"./doc/imgs/00018069.jpg" --det_model_dir&＃61;"./inference/det_db/" --rec_model_dir&＃61;"./inference/rec_crnn/" --use_angle_cls&＃61;false# 使用多进程
python3 tools/infer/predict_system.py --image_dir&＃61;"./doc/imgs/00018069.jpg" --det_model_dir&＃61;"./inference/det_db/" --rec_model_dir&＃61;"./inference/rec_crnn/" --use_angle_cls&＃61;false --use_mp&＃61;True --total_process_num&＃61;6


看了一下&＃xff0c;其实这个文件https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.1/paddleocr.py和另一个PaddleOCR/tools/infer/utility.py文件内容很像&＃xff0c;wheel包里的那个paddleocr.py其实就是这个utility.py文件的一部分内容的简化&＃xff0c;方便调用而已。

3.5 cpu占用问题

之前又说内存泄漏&＃xff0c;还有个问题就是CPU抢占&＃xff0c;默认会占到100%。
很多人也有这样的问题&＃xff0c;比如&＃xff1a;百度AI社区-ppocr部分

在FAQ文档中没有搜索到相关信息&＃xff0c;移动端arm cpu优化学习笔记第3弹–绑定cpu(cpu affinity)

查看自己电脑核数
win10系统如何查看cpu核数

所以我这个电脑是8核。

3.5.1 paddle绑定cpu问题

3.6推理部署文档里涉及了一点点&＃xff0c;主要是&＃xff1a;
Docs » Python API 文档 » Config 类 » 3. 使用 CPU 进行预测

后来想到PaddleOCR的代码中有&＃xff1a;

主要是这里的infer文件夹中的五个脚本文件&＃xff0c;关键就是搞清楚utility.py中config文件配置的项目都是怎么搞的。
由于人工找太累了而且还没找到&＃xff0c;所以直接在代码里调试来查看&＃xff1a;把调用ocr的附近打个断点&＃xff0c;然后看输出的变量&＃xff0c;里面就有ocr对象&＃xff08;PaddleOCR类&＃xff09;

然后就可以看到&＃xff0c;有一个文本检测和文本识别

展开&＃xff0c;可以看到大部分参数其实都是在文本检测那里配置的

文本检测配置了很多东西&＃xff0c;但是并没有cpu相关的配置。

其实utility.py文件中&＃xff0c;有一段代码&＃xff0c;找到自己本机安装paddleocr的地方&＃xff0c;C:\software\anaconda\Lib\site-packages\paddleocr\tools\infer&＃xff0c;133行左右

if args.use_gpu:config.enable_use_gpu(args.gpu_mem, 0)if args.use_tensorrt:config.enable_tensorrt_engine(precision_mode&＃61;inference.PrecisionType.Halfif args.use_fp16 else inference.PrecisionType.Float32,max_batch_size&＃61;args.max_batch_size)
else:config.disable_gpu()# cpu设置的关键&＃x1f9e1; config.set_cpu_math_library_num_threads(6)if args.enable_mkldnn:# cache 10 different shapes for mkldnn to avoid memory leak# mkldnn设置的关键&＃x1f9e1; config.set_mkldnn_cache_capacity(10)config.enable_mkldnn()# TODO LDOUBLEV: fix mkldnn bug when bach_size > 1#config.set_mkldnn_op({&＃39;conv2d&＃39;, &＃39;depthwise_conv2d&＃39;, &＃39;pool2d&＃39;, &＃39;batch_norm&＃39;})args.rec_batch_num &＃61; 1


根据文档Docs » Python API 文档 » Config 类 » 3. 使用 CPU 进行预测说明&＃xff0c;

在 CPU 可用核心数足够时&＃xff0c;可以通过设置 set_cpu_math_library_num_threads 将线程数调高一些&＃xff0c;默认线程数为 1

所以如果想要限制这个使用cpu的核数量&＃xff0c;可以设置代码中

config.set_cpu_math_library_num_threads(6)
# 把6改成4好了


另外&＃xff0c;由于启用了mkldnn&＃xff0c;还是根据上面那个文档&＃xff1a;

启用 MKLDNN 的前提为已经使用 CPU 进行预测&＃xff0c;否则启用 MKLDNN 无法生效
启用 MKLDNN BF16 要求 CPU 型号可以支持 AVX512&＃xff0c;否则无法启用 MKLDNN BF16

# 设置 MKLDNN 的 cache 容量大小
config.set_mkldnn_cache_capacity(1)


最后将cpu个数从6变成4&＃xff0c;mkldnn从10变成5&＃xff0c;需要重启电脑才生效&＃xff0c;使用reload函数重新加载库似乎没什么用&＃xff0c;关掉pycharm重新启动pycharm也没啥用。
但是检测速度又降低了。
而且重启电脑之后&＃xff0c;第一次是控制在了50%左右&＃xff0c;但是第二次再去进行的时候就不行了。

这是因为 python 把ppocr这个库缓存了&＃xff0c;需要把它从 sys.modules 里删了再导入即可。
参考另一个博文&＃xff1a;python3 reload

3.6 推理部署文档

paddle有很多关于推理部署的专门的文档&＃xff0c;其实可以看看。
推理部署

这附近文档还有个图&＃xff0c;感觉不错

另外&＃xff0c;从官网这里可以切到文档&＃xff1a;Python预测部署示例

还找到了一个使用Paddle inference进行口罩检测推理的&＃xff1a;
(二) 使用 Paddle Inference进行口罩检测