， 注建议使用TensorRT大于等于6.1.0.5以上的版本， use_tensorrt False， max_batch_size args . max_batch_size ) else : config . disable_gpu ( ) # cpu设置的关键 config . set_cpu_math_library_num_threads ( 6 ) if args . enable_mkldnn : # cache 10 different shapes for mkldnn to avoid memory leak # mkldnn设置的关键 config . set_mkldnn_cache_capacity ( 10 ) config . enable_mkldnn ( ) # TODO LDOUBLEV: fix mkldnn bug when bach_size 1 #config.set_mkldnn_op({conv2d， 这是因为 python 把ppocr这个库缓存了需要把它从 sys.modules 里删了再导入即可， det_limit_side_len 960 ， rec True。
det_east_score_thresh 0.8 ，32， type float ， rec_batch_num 6 。
det_algorithm DB ， ( 1076 ， det_limit_side_len改的再小一些256识别部分最大长度max_text_length5rec_image_shape(3。
320 ， det_db_box_thresh 0.3 ， ir_optim True， 其实utility.py文件中有一段代码找到自己本机安装paddleocr的地方C:\software\anaconda\Lib\site-packages\paddleocr\tools\infer133行左右 if args . use_gpu : config . enable_use_gpu ( args . gpu_mem ， 所以还是老老实实安装上paddle吧 2. 使用 改改路径就好了， rec_char_dict_path C:/shaiic_work/ZhiNengKeJiOCR/digit.txt ， 3.5 cpu占用问题 之前又说内存泄漏还有个问题就是CPU抢占默认会占到100%。
det_db_thresh 0.2 ， det_east_cover_thresh 0.1 ， Q3.4.44: 如何多进程预测 A: 近期PaddleOCR新增了use_mp表示是否使用多进程total_process_num表示在使用多进程时的进程数。
3.2.4 内存泄漏的问题记录 发现paddle的issue中有很多说速度很慢的 3.3 剪枝 在上面下载支持mlkdnn的CPU预测库的时候看到了一个很有用的说明文档https://paddle-inference.readthedocs.io/en/latest/index.html就是针对paddle系列的推理模型的， 同时参考文档 识别模型是自己训练之后转为推理模型的有94MB确实对于比较简单的一块数字仪表识别很重， 170.0 ] ， cls_thresh 0.9 ， 如果是多个文本识别结果会有再外层的一个数组， [ [ [ 62.0 ，具体使用方式请参考， 0.7172388 ) ] ， 所以虽然找不到paddle2.0rc版本但是可以直接去下载2.1版本 python -m pip install paddlepaddle -i https://mirror.baidu.com/pypi/simple # 直接用这个会显示已经安装了2.0所以需要 pip install --upgrade paddlepaddle -i https://mirror.baidu.com/pypi/simple # 更新到最新就是2.1 改了之后内存依然占用量很高而且推理速度还变慢了，， 在paddleocr.py文件中看到 parser . add_argument ( --det_algorithm ， left : right ] 参考python cv2图片剪裁 3. 性能改进 3.0 基本情况 检测时间比较久检测识别的时间差不多是0.7~1.2s在cpu机器上其实比较尴尬。
163.0 ] ] 。
2021.6.3查看那个issue看到 这个更新是26天前查看自己的环境似乎不是2.0rc换， dict_path : ./ppocr/utils/ppocr_keys_v1.txt } ，所以本文主要介绍在X86 CPU部署PaddleSlim产出的量化模型，但是内存占用是100%基本上， 另外搜索速度可以看到 Q3.4.40: 使用hub_serving部署延时较高可能的原因是什么呀 A: 首先测试的时候第一张图延时较高可以多测试几张然后观察后几张图的速度其次如果是在cpu端部署serving端模型如backbone为ResNet34耗时较慢建议在cpu端部署mobile如backbone为MobileNetV3模型， 文章目录 1. 安装 1.1 还是需要paddle 根据paddleocr package使用说明 一开始以为 pip install paddleocr2.0.1 但是果然 so就在本机安装一下paddle好了但是也仅需要paddle参考快速安装 # windows下 直接 python 不是python3 python3 -m pip install paddlepaddle 2.0 .0 -i https://mirror.baidu.com/pypi/simple 安装好再去运行遇到经典的shapely错误参考Win10 CPU环境OSError: [WinError 126] 找不到指定的模块 #212 windows下安装shapely需要从下载然后再 pip uninstall shapelypip install Shapely-1.7.1-cp37-cp37m-win_amd64.whlconda install shapely -c conda-forge 或者 更名为Shapely-1.7.0-cp39-cp39-win_amd64.rar然后解压缩从其子目录shapely\DLLs\中找到geos_c.dll并将geos_c.dll拷贝到conda的环境我的命名是ocr目录 C:\Users\myusername\Miniconda3\envs\ocr\Library\bin中， parser . add_argument ( --use_mp ， ( 40 ，相关讨论见issue A2. C 预测出现内存泄漏该问题已经在paddle2.0rc版本中解决建议安装paddle2.0rc版本并更新PaddleOCR代码到最新， 48， 同时cpu thread数量改为1不然还是会有很高的内存占用率同时改成1其实速度影响并不大，由于还没怎么研究过检测模型所以很难判断问题到底出在哪里 2.3.1 换个模型 参考 paddleocr文档 可以看到其实EAST的准确率要比DB高虽然存在过检。
但是相比于剪枝的代价并不值得， 3.2 加速 直接去FAQ文档中搜索加速可以看到以下结果. Q3.1.73: 如何使用TensorRT加速PaddleOCR预测 A 目前paddle的dygraph分支已经支持了python和C TensorRT预测的代码python端inference预测时把参数–use_tensorrtTrue即可 CTensorRT预测需要使用支持TRT的预测库并在编译时打开-DWITH_TENSORRTON， default False ) # 只能命令行调用 # 使用方向分类器 python3 tools / infer / predict_system . py - - image_dir ./doc/imgs/00018069.jpg - - det_model_dir ./inference/det_db/ - - cls_model_dir ./inference/cls/ - - rec_model_dir ./inference/rec_crnn/ - - use_angle_cls true # 不使用方向分类器 python3 tools / infer / predict_system . py - - image_dir ./doc/imgs/00018069.jpg - - det_model_dir ./inference/det_db/ - - rec_model_dir ./inference/rec_crnn/ - - use_angle_cls false # 使用多进程 python3 tools / infer / predict_system . py - - image_dir ./doc/imgs/00018069.jpg - - det_model_dir ./inference/det_db/ - - rec_model_dir ./inference/rec_crnn/ - - use_angle_cls false - - use_mp True - - total_process_num 6 看了一下其实这个文件https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.1/paddleocr.py 和另一个文件内容很像 wheel包里的那个paddleocr.py其实就是这个utility.py文件的一部分内容的简化方便调用而已， 可以看到这个代码的位置 Q3.4.17 预测内存泄漏问题 A1. 使用hubserving出现内存泄漏该问题为已知问题预计在paddle2.0正式版中解决， depthwise_conv2d， Q3.1.77: 使用mkldnn加速预测时遇到 ‘Please compile with MKLDNN first to use MKLDNN’ A 报错提示当前环境没有mkldnn建议检查下当前CPU是否支持mlkdnnMAC上是无法用mkldnn另外的可能是使用的预测库不支持mkldnn 建议从下载支持mlkdnn的CPU预测库， 最后的结论 内存泄漏是因为开启了mkldnn需要关闭， det_east_nms_thresh 0.2 ， 个人猜测是不是第一阶段检测模型是剪枝后的比如是8位精度第二阶段识别模型也是8位精度这样系统处理是一致的， type str2bool ， 先查看一下模型的size运行检测的时候会打印出模型的配置信息可以从这里看到 Namespace ( cls_batch_num 6 ， det_model_dir C:\\Users\\huangshan/.paddleocr/2.1/det/ch ， 151.0 ] ，320)， EAST高效准确但对弯曲文本检测较差。
det_limit_type max ， use_pdserving False。
use_angle_cls False， 之前是0.7~1.2现在基本就是0.6-0.98反正没有超过1s的0.8的比较多， X86 CPU部署量化模型的步骤 产出量化模型使用PaddleSlim训练并产出量化模型 转换量化模型将量化模型转换成最终部署的量化模型 部署量化模型使用Paddle Inference预测库部署量化模型 一开始其实不太想用剪枝的因为慢的原因主要在于检测但是检测的模型已经是剪枝后的了在比较过全都使用默认的剪枝模型检测识别和使用默认的检测自己的识别模型之后发现其实还是有些效果的， [ 58.0 ， 这里建议在cpu端部署mobile模型 也可以只看还可以看到以下比较有用的信息 Q3.4.1如何pip安装opt模型转换工具 A由于OCR端侧部署需要某些算子的支持这些算子仅在Paddle-Lite 最新develop分支中所以需要自己编译opt模型转换工具。
[ 72.0 ， Q1.1.10PaddleOCR中对于模型预测加速CPU加速的途径有哪些基于TenorRT加速GPU对输入有什么要求 A1CPU可以使用mkldnn进行加速对于python inference的话可以把enable_mkldnn改为true参考代码对于cpp inference的话在配置文件里面配置use_mkldnn 1即可参考代码 2GPU需要注意变长输入问题等TRT6 之后才支持变长输入 直接在inference代码中将enable_mkldnn改为true确实变快了一些，都超过1s了但是效果好像好了一些连一些虚的都变好了， rec_algorithm CRNN ，打开内存任务管理器发现这个东西内存占用可以达到98% 我本机是32G的内存无语， rec_model_dir C:/shaiic_work/ZhiNengKeJiOCR/rec_crnn_digit 。
max_text_length 25 ， 模型量化主要就是剪枝——X86 CPU 上部署量化模型 大概介绍一下搬运 众所周知模型量化可以有效加快模型预测性能飞桨也提供了强大的模型量化功能， 对于常见图像分类模型在Casecade Lake机器上例如Intel® Xeon® Gold 6271、6248X2XX等INT8模型进行推理的速度通常是FP32模型的3-3.7倍在SkyLake机器上例如Intel® Xeon® Gold 6148、8180X1XX等INT8模型进行推理的速度通常是FP32模型的1.5倍， default 960 ) 根据FAQ文档 Q3.3.2配置文件里面检测的阈值设置么? A有的检测相关的参数主要有以下几个 det_limit_side_len预测时图像resize的长边尺寸 det_db_thresh: 用于二值化输出图的阈值 det_db_box_thresh:用于过滤文本框的阈值低于此阈值的文本框不要 det_db_unclip_ratio: 文本框扩张的系数关系到文本框的大小 这些参数的默认值见代码可以通过从命令行传递参数进行修改， gpu_mem 8000 。
但是更新到2.1之后打开mkldnn速度变快了基本控制在0.3-0.5s，， 很奇怪一开始速度是0.6后来逐渐稳定再0.8~0.9之间， batch_norm}) args . rec_batch_num 1 根据文档Docs » Python API 文档 » Config 类 » 3. 使用 CPU 进行预测说明 在 CPU 可用核心数足够时可以通过设置 set_cpu_math_library_num_threads 将线程数调高一些默认线程数为 1 所以如果想要限制这个使用cpu的核数量可以设置代码中 config . set_cpu_math_library_num_threads ( 6 ) # 把6改成4好了 另外由于启用了mkldnn还是根据上面那个文档 启用 MKLDNN 的前提为已经使用 CPU 进行预测否则启用 MKLDNN 无法生效 启用 MKLDNN BF16 要求 CPU 型号可以支持 AVX512否则无法启用 MKLDNN BF16 # 设置 MKLDNN 的 cache 容量大小 config . set_mkldnn_cache_capacity ( 1 ) 最后将cpu个数从6变成4mkldnn从10变成5需要 重启电脑 才生效使用reload函数重新加载库似乎没什么用关掉pycharm重新启动pycharm也没啥用， 166.0 ] ， [ 237.0 ， 192 ，问题解决 同时把geos.dll和geos_c.dll拷贝至你anaconda环境中的library\bin中 最简单的方案 删除anaconda中之前装的shaply文件夹和程序都删掉重新安装 参考anaconda3 paddleOCR安装使用 1.2 确认各种包和环境 本机上使用了anaconda默认环境各种版本如下 python 3.7.6 paddleocr 使用pip安装后看到的版本是 paddleocr-2.0.6-py3 requirments文件中的内容 shapely scikit-image 0.17.2 imgaug 0.4.0 pyclipper lmdb opencv-python 4.2.0.32 tqdm numpys visualdl python-Levenshtein 1.3 可能不需要paddle 根据 Q3.4.23安装paddleocr后提示没有paddle A这是因为paddlepaddle gpu版本和cpu版本的名称不一致现在已经在whl的文档里做了安装说明， rec_image_shape 3， 2.3.2 限定检测位置 设置一个按键opencv摄像头有键盘响应可以有相应的操作参考cv2.VideoCapture.get、set详解可以获取相机参数， 0 ) if args . use_tensorrt : config . enable_tensorrt_engine ( precision_mode inference . PrecisionType . Half if args . use_fp16 else inference . PrecisionType . Float32 ，。
很多人也有这样的问题比如百度AI社区-ppocr部分 在FAQ文档中没有搜索到相关信息移动端arm cpu优化学习笔记第3弹–绑定cpu(cpu affinity) 查看自己电脑核数 win10系统如何查看cpu核数 所以我这个电脑是8核， default DB ) # 调用时修改为EAST但是报错 然后看到代码中有 SUPPORT_DET_MODEL [ DB ] VERSION 2.0 SUPPORT_REC_MODEL [ CRNN ] BASE_DIR os . path . expanduser ( ~/.paddleocr/ ) 结论 发现下载的是预训练模型不是推理模型无法使用EAST算法， 3.4 其他可能的途径 3.3 更换模型 https://github.com/PaddlePaddle/PaddleOCR/blob/release/2.1/doc/doc_ch/models_list.md 3.4 多进程 Q3.4.33: 如何多进程运行paddleocr A实例化多个paddleocr服务然后将服务注册到注册中心之后通过注册中心统一调度即可关于注册中心可以搜索eureka了解一下具体使用其他的注册中心也行， 3.5.1 paddle绑定cpu问题 3.6推理部署文档里涉及了一点点主要是 Docs » Python API 文档 » Config 类 » 3. 使用 CPU 进行预测 后来想到PaddleOCR的代码中有 主要是这里的infer文件夹中的五个脚本文件关键就是搞清楚utility.py中config文件配置的项目都是怎么搞的， 另外关于常见PaddleOCR包里给出的参数说明参考paddleocr package使用说明最后有一个参数说明表 关于检测可控的参数有很多但是关于识别其实并没有很多可以进行调优的参数，opt工具可以通过编译PaddleLite获得编译步骤参考lite部署文档 中2.1 模型优化部分， 由于人工找太累了而且还没找到所以直接在代码里调试来查看把调用ocr的附近打个断点然后看输出的变量里面就有ocr对象PaddleOCR类 然后就可以看到有一个文本检测和文本识别 展开可以看到大部分参数其实都是在文本检测那里配置的 文本检测配置了很多东西但是并没有cpu相关的配置。
use_gpu False，， ch_ppocr_mobile_v2.0_rec_infer.tar所以这个默认的模型目测已经是剪枝过的了， [ 233.0 ， 如果两个阶段数据精度不一样系统处理的时候不一致是不是也会造成数据差异， 0.9666834 ) ] ] 可以看到输出文件的结构每一个文本识别结果都包括四个点的坐标一个二位数组以及一个最后识别结果的元组识别的文字结果置信度结构就是一个数组涵盖这两部分内容， 1080 ) ; 宽度capture . set ( CV_CAP_PROP_FRAME_HEIGHT ，换成自带的识别模型之后也比之前时间长了无语， 294.0 ] ] ，32， enable_mkldnn False， 如果想修改其他分支代码支持TensorRT预测可以参考PR， image_dir 。
rec_char_type ch 。
参考另一个博文python3 reload 3.6 推理部署文档 paddle有很多关于推理部署的专门的文档其实可以看看， label_list [ 0 ， 3.2.3 内存泄露 根据FAQ文档 Q3.4.43: 预测时显存爆炸、内存泄漏问题 A: 打开显存/内存优化开关enable_memory_optim可以解决该问题相关代码已合入。
149.0 ] ， 175.0 ] ， use_space_char True， use_zero_copy_run False ) 采用的检测模型是自带的位置在det_model_dirC:\\Users\\yourname/.paddleocr/2.1/det/ch检测模型只有3M 先确认一下这个默认模型的信息从代码中可以看到 rec : { ch : { url : https://paddleocr.bj.bcebos.com/dygraph_v2.0/ch/ch_ppocr_mobile_v2.0_rec_infer.tar ， [ 113.0 ，， 32， use_dilation False， 3.2.2 修改参数 想起来还有一些参数可以考虑修改比如 parser . add_argument ( --det_limit_side_len ， 180 ] 。
[ 113.0 。
X 自己模型的速度和全用默认的速度对比 上面已经给了几个自己模型的用时图下面给几个全用默认的时间图 可知 不使用mkldnn加速的情况下使用默认的检测自己的识别速度基本在0.7~1.2s 不使用mkldnn加速的情况下使用默认的检测默认的识别速度基本在0.7~0.9s 所以虽然识别时间本来就不到0.2s但是可以变得更快这样就只剩检测时间了， pool2d， type str ， 其中有一点需要注意 [ [ [ [ 72.0 ， 但是检测速度又降低了。
det_limit_side_len默认是960考虑改成32的倍数但是改小一些比如320， lang ch ， 300.0 ] ， det True， 2.1 配置摄像头读取识别显示 参考另一个文章python opencv调用摄像头识别并绘制结果 发现一个神奇的事情当你插着usb摄像头启动电脑时cap cv2.VideoCapture(0)usb摄像头的序号就是0当启动电脑之后再插上usb摄像头usb摄像头的序号就是2我的电脑是一个前置一个后置摄像头 关于摄像头参数的调节可以参考另一篇文章Opencv摄像头相关参数 2.3 检测模型的问题 由于使用了摄像头读取图像图片背景比较杂对检测有难度发现使用DB效果不是很好， drop_score 0.5 ， 960 ) ; 高度frame [ top : bottom ，256)之前默认是(3， 而且重启电脑之后第一次是控制在了50%左右但是第二次再去进行的时候就不行了， cls_image_shape 3， 另外参考opencv python全屏显示、置窗口大小和位置 cap cv2 . VideoCapture ( 1 ) cv2 . VideoCapture . get ( 3 ) # CV_CAP_PROP_FRAME_WIDTH 在视频流的帧的宽度 cv2 . VideoCapture . get ( 4 ) # CV_CAP_PROP_FRAME_HEIGHT 在视频流的帧的高度 # 除了get还有set capture . set ( CV_CAP_PROP_FRAME_WIDTH ， Q3.4.2如何将PaddleOCR预测模型封装成SDK A如果是Python的话可以使用tools/infer/predict_system.py中的TextSystem进行sdk封装如果是c的话可以使用deploy/cpp_infer/src下面的DBDetector和CRNNRecognizer完成封装 3.2.1 CPU下使用mkldnn加速 由于慢的地方主要是检测所以即便对剪枝进行优化也不是很有效所以这里先尝试使用mkldnn来进行加速， 加速之后超级快但是内存占用非常高， 3.1 端侧部署 参考文档端侧部署 这种会帮助有效减小模型size但是推理速度似乎没有强调会不会变快。
cls_model_dir C:\\Users\\huangshan/.paddleocr/2.1/cls ， 但是参考预测示例 (Python) 可知想使用paddle系列的模型是必须要使用paddle的inference的， det_db_unclip_ratio 2.2 ， 推理部署 这附近文档还有个图感觉不错 另外从官网这里可以切到文档 还找到了一个使用Paddle inference进行口罩检测推理的 (二) 使用 Paddle Inference进行口罩检测 。