RapidOCR 推理优化指南三步把 OCR 端到端延迟压进 20 毫秒【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCRRapidOCR 推理优化拉开的差距长这样i7-10700K 上识别同一张中英文混排文档PyTorch 引擎一帧 68.5msOpenVINO 一帧 18.7ms——OCR 模型没换变的只有引擎和参数。下文按诊断、配置、验收的顺序讲清瓶颈花在哪一步、该动哪些参数、不同硬件选什么引擎以及最后怎么拿数据验收。瓶颈定位OCR 延迟到底花在哪一步一次 RapidOCR 调用按顺序跑三个小模型检测DB 网络给出文字框位置方向分类判断要不要旋转识别SVTR基于 Transformer 的场景文字识别网络输出字符前后处理resize、NMS、解码夹在两头。动手优化前先用 10 分钟定位检测耗时随输入分辨率近似线性增长。图像超过max_side_len默认 2000被缩放时时间主要花在 det。识别耗时随文字行数和行宽增长。一帧文字行多整页文档、表格、列表大头在 rec。开关都在 python/rapidocr/config.yamluse_det、use_cls、use_rec可单独关闭任一环节min_side_len/max_side_len控制检测输入上下限。纯横向文档关掉 cls 就省掉一次推理。⚡ 提速三板斧引擎、图、线程图优化是白捡的速度。ONNX Runtime 会话默认开启全部图优化做算子融合与常量折叠减少中间张量的内存访问。这一项在 python/rapidocr/inference_engine/onnxruntime/main.py 里写死为ORT_ENABLE_ALL默认生效自定义会话时别把它关回去即可。引擎选型决定上限。仓库内置六套推理引擎实现在 python/rapidocr/inference_engine/onnxruntime、openvino、pytorch、paddle、tensorrt、mnn。跨平台通吃选 ONNX RuntimeCUDA、DML、CANN、CoreML 执行提供器都可配Intel 硬件有 OpenVINO 的图特化与原生 INT8NVIDIA GPU 上 TensorRT 编译引擎后单帧延迟最低移动端用 MNN。线程数决定单帧吞吐的下限。原理不复杂算子内并行把一个卷积拆到多核执行收益在物理核数附近见顶再多只是调度开销。更直接地说验收小节的实测曲线里 8 线程 21.3ms、16 线程 20.8ms——翻倍线程只换来 0.5ms。落到配置上就是intra_op_num_threads: 8 inter_op_num_threads: 1 enable_cpu_mem_arena: trueintra取不超过物理核数的值inter算子间并行保持 1避免两层并行互相抢占。 按硬件选引擎一张决策表硬件场景推荐引擎为什么Intel CPU / 核显OpenVINO针对 Intel 微架构图特化原生 INT8实测 18.7ms 全场最低AMD CPU、ARM 服务器ONNX Runtime执行提供器覆盖最全移植成本最低NVIDIA GPU / 边缘 AI 芯片TensorRT仓库内置 engine_builder 离线编译引擎GPU 上单帧延迟最低Android / iOS 移动端MNN骁龙 888 跑 1080p 截图实测 30ms 以内见 android/README.md实验、微调、结构改造PyTorch改网络方便但生产延迟最高68.5ms不适合在线服务表里数字来自同一批实测环境在验收小节。判断顺序很简单先问是不是 Intel再问有没有独立 GPU最后问是不是移动端。️ 五个能立刻上手的参数intra_op_num_threads/inter_op_num_threadsONNX Runtime算子内、算子间线程数。高解析度图像、文字行多、单帧计算量大时值得调单核环境跳过。inference_num_threads/performance_hintOpenVINO线程数与性能模式LATENCY优化单帧延迟THROUGHPUT优化吞吐后者建议同时设置PERFORMANCE_HINT_NUM_REQUESTS。透传逻辑在 python/rapidocr/inference_engine/openvino/device_config.pyinference_num_threads: 8 performance_hint: LATENCYmax_side_len全局预处理检测输入上限。生产图像普遍在 1000px 宽以下时可以直接下调更直接地说宽度砍半识别侧计算量大约省一半。enable_cpu_mem_arena预分配内存池省掉每帧 malloc/free 的开销常驻推理服务开启即可。INT8 量化默认 FP32量化后模型文件缩到约 1/4速度提升约 2–3 倍。适用边界① profile 确认计算是瓶颈通常指 rec 占大头② 硬件有 INT8 加速路径Intel CPU OpenVINO、TensorRT。代价是精度下降可接受必须用自己业务的回归数据验证数字、生僻字体尤需逐条核对。用数据验收实测对比怎么看测试环境Intel i7-10700K、16GB 内存、Ubuntu 20.04数据集为仓库自带测试集 python/tests/test_files/覆盖中英文混排、多语言、复杂背景等场景。以其中一条识别输入为例引擎对比平均推理时间 / 峰值内存推理引擎平均推理时间毫秒峰值内存MBPyTorch68.5452ONNX Runtime21.3286OpenVINO18.7254同一硬件下 OpenVINO 比 PyTorch 快约 73%内存低约 44%。这组数据的含义引擎切换是量级差距18.7 vs 68.5参数调优是百分比差距——所以顺序上先定引擎再拧线程和输入尺寸。线程数影响i7-10700K单帧时间线程数毫秒185.2432.6821.31620.8读数建议只比较同一硬件、同一数据集下的结果看均值与峰值内存别拿单次最好成绩改完参数跑完整测试集而不是只测一张图。三个容易踩的坑线程越多越快。16 线程20.8ms相对 8 线程21.3ms的收益接近于零混跑业务时线程争抢还会更慢。反直觉之处在于inter_op_num_threads开大了反而亏多数场景 1 就够。先量化再谈提速。det 模型本来就小计算未必是瓶颈INT8 的增益可能不如把线程数调对来得大2–3 倍提速是计算密集场景的平均口径。动手前先 profile 确认时间分布量化后必须跑精度回归。用同一把分辨率杠杆调 det 和 rec。两者对分辨率的诉求相反检测输入越大召回越好识别成本却随行宽线性上涨。正确顺序是先下调max_side_len压成本再验证检测召回是否受损必要时对小字区域单独放大而不是把整张图统一拉大。引擎、图、线程三板斧加上数据验收就是 RapidOCR 推理优化的完整闭环。参数全集参考 python/rapidocr/config.yaml。【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RapidOCR 推理优化指南：三步把 OCR 端到端延迟压进 20 毫秒
RapidOCR 推理优化指南三步把 OCR 端到端延迟压进 20 毫秒【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCRRapidOCR 推理优化拉开的差距长这样i7-10700K 上识别同一张中英文混排文档PyTorch 引擎一帧 68.5msOpenVINO 一帧 18.7ms——OCR 模型没换变的只有引擎和参数。下文按诊断、配置、验收的顺序讲清瓶颈花在哪一步、该动哪些参数、不同硬件选什么引擎以及最后怎么拿数据验收。瓶颈定位OCR 延迟到底花在哪一步一次 RapidOCR 调用按顺序跑三个小模型检测DB 网络给出文字框位置方向分类判断要不要旋转识别SVTR基于 Transformer 的场景文字识别网络输出字符前后处理resize、NMS、解码夹在两头。动手优化前先用 10 分钟定位检测耗时随输入分辨率近似线性增长。图像超过max_side_len默认 2000被缩放时时间主要花在 det。识别耗时随文字行数和行宽增长。一帧文字行多整页文档、表格、列表大头在 rec。开关都在 python/rapidocr/config.yamluse_det、use_cls、use_rec可单独关闭任一环节min_side_len/max_side_len控制检测输入上下限。纯横向文档关掉 cls 就省掉一次推理。⚡ 提速三板斧引擎、图、线程图优化是白捡的速度。ONNX Runtime 会话默认开启全部图优化做算子融合与常量折叠减少中间张量的内存访问。这一项在 python/rapidocr/inference_engine/onnxruntime/main.py 里写死为ORT_ENABLE_ALL默认生效自定义会话时别把它关回去即可。引擎选型决定上限。仓库内置六套推理引擎实现在 python/rapidocr/inference_engine/onnxruntime、openvino、pytorch、paddle、tensorrt、mnn。跨平台通吃选 ONNX RuntimeCUDA、DML、CANN、CoreML 执行提供器都可配Intel 硬件有 OpenVINO 的图特化与原生 INT8NVIDIA GPU 上 TensorRT 编译引擎后单帧延迟最低移动端用 MNN。线程数决定单帧吞吐的下限。原理不复杂算子内并行把一个卷积拆到多核执行收益在物理核数附近见顶再多只是调度开销。更直接地说验收小节的实测曲线里 8 线程 21.3ms、16 线程 20.8ms——翻倍线程只换来 0.5ms。落到配置上就是intra_op_num_threads: 8 inter_op_num_threads: 1 enable_cpu_mem_arena: trueintra取不超过物理核数的值inter算子间并行保持 1避免两层并行互相抢占。 按硬件选引擎一张决策表硬件场景推荐引擎为什么Intel CPU / 核显OpenVINO针对 Intel 微架构图特化原生 INT8实测 18.7ms 全场最低AMD CPU、ARM 服务器ONNX Runtime执行提供器覆盖最全移植成本最低NVIDIA GPU / 边缘 AI 芯片TensorRT仓库内置 engine_builder 离线编译引擎GPU 上单帧延迟最低Android / iOS 移动端MNN骁龙 888 跑 1080p 截图实测 30ms 以内见 android/README.md实验、微调、结构改造PyTorch改网络方便但生产延迟最高68.5ms不适合在线服务表里数字来自同一批实测环境在验收小节。判断顺序很简单先问是不是 Intel再问有没有独立 GPU最后问是不是移动端。️ 五个能立刻上手的参数intra_op_num_threads/inter_op_num_threadsONNX Runtime算子内、算子间线程数。高解析度图像、文字行多、单帧计算量大时值得调单核环境跳过。inference_num_threads/performance_hintOpenVINO线程数与性能模式LATENCY优化单帧延迟THROUGHPUT优化吞吐后者建议同时设置PERFORMANCE_HINT_NUM_REQUESTS。透传逻辑在 python/rapidocr/inference_engine/openvino/device_config.pyinference_num_threads: 8 performance_hint: LATENCYmax_side_len全局预处理检测输入上限。生产图像普遍在 1000px 宽以下时可以直接下调更直接地说宽度砍半识别侧计算量大约省一半。enable_cpu_mem_arena预分配内存池省掉每帧 malloc/free 的开销常驻推理服务开启即可。INT8 量化默认 FP32量化后模型文件缩到约 1/4速度提升约 2–3 倍。适用边界① profile 确认计算是瓶颈通常指 rec 占大头② 硬件有 INT8 加速路径Intel CPU OpenVINO、TensorRT。代价是精度下降可接受必须用自己业务的回归数据验证数字、生僻字体尤需逐条核对。用数据验收实测对比怎么看测试环境Intel i7-10700K、16GB 内存、Ubuntu 20.04数据集为仓库自带测试集 python/tests/test_files/覆盖中英文混排、多语言、复杂背景等场景。以其中一条识别输入为例引擎对比平均推理时间 / 峰值内存推理引擎平均推理时间毫秒峰值内存MBPyTorch68.5452ONNX Runtime21.3286OpenVINO18.7254同一硬件下 OpenVINO 比 PyTorch 快约 73%内存低约 44%。这组数据的含义引擎切换是量级差距18.7 vs 68.5参数调优是百分比差距——所以顺序上先定引擎再拧线程和输入尺寸。线程数影响i7-10700K单帧时间线程数毫秒185.2432.6821.31620.8读数建议只比较同一硬件、同一数据集下的结果看均值与峰值内存别拿单次最好成绩改完参数跑完整测试集而不是只测一张图。三个容易踩的坑线程越多越快。16 线程20.8ms相对 8 线程21.3ms的收益接近于零混跑业务时线程争抢还会更慢。反直觉之处在于inter_op_num_threads开大了反而亏多数场景 1 就够。先量化再谈提速。det 模型本来就小计算未必是瓶颈INT8 的增益可能不如把线程数调对来得大2–3 倍提速是计算密集场景的平均口径。动手前先 profile 确认时间分布量化后必须跑精度回归。用同一把分辨率杠杆调 det 和 rec。两者对分辨率的诉求相反检测输入越大召回越好识别成本却随行宽线性上涨。正确顺序是先下调max_side_len压成本再验证检测召回是否受损必要时对小字区域单独放大而不是把整张图统一拉大。引擎、图、线程三板斧加上数据验收就是 RapidOCR 推理优化的完整闭环。参数全集参考 python/rapidocr/config.yaml。【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考