RapidOCR 实战拆解3 行代码跑通 OCR6 个推理引擎按硬件切换【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR凌晨两点一个做票据自动归档的接口开始告警批量识别 500 张单据平均要 800ms其中一张带旋转文字和半透明底色的图直接超时。你把 PaddleOCR 原版部署翻出来看了一遍发现瓶颈不只在模型本身更在换个硬件就要换一套部署代码。这类问题就是 RapidOCR 想解决的事它把 PaddleOCR 的模型转成 ONNX 等可移植格式再用统一接口包在 ONNX Runtime、OpenVINO、TensorRT、MNN、PaddlePaddle、PyTorch 六个推理引擎之上换硬件时只改配置不改业务代码。核心能力一览一条engine(img)调用完成检测、方向分类、识别三级流水线六推理引擎统一抽象配置切换即可换后端模型按语言 规模自动下载缓存默认支持中英文提供 Python 包与 CLI另有 C/Java/C#/Android/iOS 等语言组件独立仓库5 步从零跑通安装到出识别结果本节回答最短路径是什么哪几步可以复制粘贴。pip install rapidocr onnxruntimefrom rapidocr import RapidOCR engine RapidOCR() result engine(python/tests/test_files/ch_en_num.jpg) print(result.txts) # 识别文本 result.vis(vis_result.jpg) # 可视化框图来源README.md接着还有三步常用操作rapidocr check检查环境是否装对rapidocr download_models预下载模型rapidocr -img 图片.jpg --lang_type en -vis直接命令行跑一张图。✅ 到这里就算跑通了。第一次调用时模型会自动下载到python/rapidocr/models目录之后走本地缓存。三个最值得读的模块引擎抽象、懒加载、坐标回映射本节回答这套工程结构里哪部分设计真正决定了它换硬件不改代码的能力。引擎抽象层一份调用六个后端设计意图让TextDetector、TextRecognizer等业务代码完全不感知后端是 ONNX 还是 TensorRT。实现思路get_engine(engine_type)按枚举分发到具体会话类六个引擎都继承同一个抽象基类InferSession统一暴露__call__输入 numpy、输出 numpy、get_character_list读字典表等接口。ONNX Runtime 引擎里还有个细节ProviderConfig.get_ep_list()会探测当前机器可用的 ExecutionProvider按 CUDA → DirectML → CANN → CoreML → CPU 的顺序组装 provider 列表CPU 永远兜底。来源python/rapidocr/inference_engine/base.py实际影响把Det/Rec的engine_type从onnxruntime改成openvino业务代码零改动在 NVIDIA GPU 上开use_cuda: true时如果环境没装 CUDA 版 onnxruntime探测逻辑会明确报出 provider 不匹配而不是静默跑在 CPU 上让你误判性能。三级流水线 惰性模型加载设计意图OCR 的 det/cls/rec 三级并非每次都都要用模型加载又是重开销必须按需付费。实现思路RapidOCR.__init__只读配置不加载任何模型。真正推理时_load_det_model/_load_cls_model/_load_rec_model各自带threading.Lock做双重检查第一次用到才建会话。use_det/use_cls/use_rec三个开关可以直接跳过整级。来源python/rapidocr/main.py实际影响如果你手里已经是裁好的文本条engine(img, use_detFalse, use_clsFalse)只加载识别模型启动时间和内存都省一大截多 worker 服务里并发请求不会重复建 N 份推理会话。预处理与坐标回映射竖长图为什么也能检出设计意图检测模型对极窄长条图单行文字裁条很不友好输入缩放后检测框还必须能精确对回原图坐标。实现思路resize_image_within_bounds把长边压到max_side_len默认 2000内、短边抬到min_side_len默认 30以上并记录缩放比apply_vertical_padding在宽高比超过width_height_ratio默认 8时对上下加 padding把窄条撑成模型舒服的宽高比所有几何操作都写进op_record最后map_boxes_to_original按记录的顺序逐一反向还原坐标并裁剪到原图边界。来源python/rapidocr/utils/process_img.py实际影响直接丢一张 65x11 的单行文字截图进去也不会漏检且返回的框天然对齐原图像素——这层映射做错了可视化框和识别文本就会错位这是二次开发时最容易碰坏的地方。性能调优实战线程数、批大小、输入尺寸怎么配本节回答拿到一台新机器按什么顺序调参数每项配置改在哪个键上。先看 配置模板 里最关键的几个键都在EngineConfig下配置键作用默认值EngineConfig.onnxruntime.intra_op_num_threads单算子内部线程数-1引擎自决EngineConfig.onnxruntime.inter_op_num_threads算子间并行线程数-1EngineConfig.onnxruntime.enable_cpu_mem_arenaCPU 内存竞技场减少动态分配falseEngineConfig.openvino.inference_num_threadsOpenVINO 推理线程数-1EngineConfig.openvino.performance_hintLATENCY/THROUGHPUT调度提示nullEngineConfig.openvino.num_streams并行推理流数-1Det.limit_side_len检测输入长边上限直接影响 det 耗时736Rec.rec_batch_num识别批大小多文本条时生效6Global.max_side_len全局预处理长边上限2000⚡️ 下面这张表是典型 x86 CPU 上线程数 → 单图端到端耗时的示例数据趋势参考请以你本机实测为准intra_op 线程数ONNX Runtime 端到端ms示例数据现象说明195单核跑完det 阶段占比最大442多数 8 核机器的甜点位838继续加线程收益变小1639上下文切换开销开始显现调优顺序建议先拿result.elapse_listdet/cls/rec 三段耗时定位大头别盲调det 占大头降Det.limit_side_len检测输入从 736 降到 960 以下的档位延迟和精度可以一起换rec 占大头图里文字条多保持rec_batch_num默认 6减少无效文本条比改 batch 更管用服务器批量场景OpenVINO 设performance_hint: THROUGHPUTnum_streams: 2低延迟单请求场景设LATENCY并显式限定inference_num_threads落地避坑清单现象、原因、解法本节回答部署后最常见的几个坑怎么快速定位。1. 现象第一次调用卡住几十秒甚至超时原因运行时在后台下载模型det/cls/rec 三个包。 解法部署前执行rapidocr download_models离线机器则手动把模型放进Global.model_root_dir指定目录。模型清单见 python/rapidocr/default_models.yaml。2. 现象配了use_cuda: true报错或日志显示实际跑在 CPU原因装的是 CPU 版 onnxruntime 轮子CUDA ExecutionProvider 不存在。 解法装 GPU 版 onnxruntime或把use_cuda改回false用session.get_providers()验证实际生效的 provider 列表。3. 现象小字、低对比度文字整条丢失原因默认Global.text_score: 0.5过滤识别置信度Det.box_thresh: 0.5过滤检测框。 解法按顺序放宽text_score0.3 起步、box_thresh0.3、再调大unclip_ratio1.6 → 2.0每次只动一个参数看召回变化。4. 现象窄长条图、竖排图检测框漏检或框不准原因手动关掉了use_vertical_padding窄图直接喂给了检测模型。 解法保持use_vertical_padding: true默认开必要时调width_height_ratio和min_height竖排场景测试图可参考python/tests/test_files/text_vertical_words.png。5. 现象识别日文/韩文等语言结果乱码或字符缺失原因Rec.lang_type默认ch字典表跟随模型加载语言不对会取错字符集。 解法构造时传params{Rec.lang_type: japan}或命令行--lang_type japan注意新语言模型会触发一次下载。6. 现象多 worker 服务内存持续上涨原因默认enable_cpu_mem_arena: false时每次推理都走动态分配或线程数未限制导致每 worker 占满核心。 解法长驻服务可开启enable_cpu_mem_arena: true并设arena_extend_strategy: kSameAsRequested同时显式给intra_op_num_threads一个小于物理核数的固定值。选型建议按硬件和场景挑引擎本节回答同一份代码不同硬件上应该选哪个engine_type。场景推荐引擎说明通用 x86 CPU 服务器onnxruntime默认配置兼容性最好Intel CPU 且想榨性能openvino用performance_hint区分延迟/吞吐NVIDIA GPU 批量识别tensorrt默认开 FP16支持 engine 缓存NVIDIA GPU 通用onnxruntimeuse_cuda: true省掉 TRT 引擎构建步骤嵌入式 / 移动端mnn资源占用最低配置项最少要微调后接入自有数据paddle用 PaddleOCR 训练/微调再导出部署调试、研究网络结构torch内置 SVTR 等识别 backbone 参考实现后续演进方向上主线是继续扩充多语言模型矩阵、配合 PaddleOCR 微调后回流到统一部署链路以及 C/Java/.NET/移动端各语言组件的独立仓库化维护。收尾RapidOCR 的价值不在多快而在一份代码、六套后端、配置级切换——把 OCR 部署的硬件适配成本从代码层降到了配置层。源码仓库clone 用https://gitcode.com/GitHub_Trending/ra/RapidOCR完整配置模板python/rapidocr/config.yaml默认模型清单python/rapidocr/default_models.yaml引擎抽象层python/rapidocr/inference_engine/base.pyDocker 多引擎环境docker/README.md测试用例图片集python/tests/test_files/【免费下载链接】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 实战拆解：3 行代码跑通 OCR，6 个推理引擎按硬件切换
RapidOCR 实战拆解3 行代码跑通 OCR6 个推理引擎按硬件切换【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR凌晨两点一个做票据自动归档的接口开始告警批量识别 500 张单据平均要 800ms其中一张带旋转文字和半透明底色的图直接超时。你把 PaddleOCR 原版部署翻出来看了一遍发现瓶颈不只在模型本身更在换个硬件就要换一套部署代码。这类问题就是 RapidOCR 想解决的事它把 PaddleOCR 的模型转成 ONNX 等可移植格式再用统一接口包在 ONNX Runtime、OpenVINO、TensorRT、MNN、PaddlePaddle、PyTorch 六个推理引擎之上换硬件时只改配置不改业务代码。核心能力一览一条engine(img)调用完成检测、方向分类、识别三级流水线六推理引擎统一抽象配置切换即可换后端模型按语言 规模自动下载缓存默认支持中英文提供 Python 包与 CLI另有 C/Java/C#/Android/iOS 等语言组件独立仓库5 步从零跑通安装到出识别结果本节回答最短路径是什么哪几步可以复制粘贴。pip install rapidocr onnxruntimefrom rapidocr import RapidOCR engine RapidOCR() result engine(python/tests/test_files/ch_en_num.jpg) print(result.txts) # 识别文本 result.vis(vis_result.jpg) # 可视化框图来源README.md接着还有三步常用操作rapidocr check检查环境是否装对rapidocr download_models预下载模型rapidocr -img 图片.jpg --lang_type en -vis直接命令行跑一张图。✅ 到这里就算跑通了。第一次调用时模型会自动下载到python/rapidocr/models目录之后走本地缓存。三个最值得读的模块引擎抽象、懒加载、坐标回映射本节回答这套工程结构里哪部分设计真正决定了它换硬件不改代码的能力。引擎抽象层一份调用六个后端设计意图让TextDetector、TextRecognizer等业务代码完全不感知后端是 ONNX 还是 TensorRT。实现思路get_engine(engine_type)按枚举分发到具体会话类六个引擎都继承同一个抽象基类InferSession统一暴露__call__输入 numpy、输出 numpy、get_character_list读字典表等接口。ONNX Runtime 引擎里还有个细节ProviderConfig.get_ep_list()会探测当前机器可用的 ExecutionProvider按 CUDA → DirectML → CANN → CoreML → CPU 的顺序组装 provider 列表CPU 永远兜底。来源python/rapidocr/inference_engine/base.py实际影响把Det/Rec的engine_type从onnxruntime改成openvino业务代码零改动在 NVIDIA GPU 上开use_cuda: true时如果环境没装 CUDA 版 onnxruntime探测逻辑会明确报出 provider 不匹配而不是静默跑在 CPU 上让你误判性能。三级流水线 惰性模型加载设计意图OCR 的 det/cls/rec 三级并非每次都都要用模型加载又是重开销必须按需付费。实现思路RapidOCR.__init__只读配置不加载任何模型。真正推理时_load_det_model/_load_cls_model/_load_rec_model各自带threading.Lock做双重检查第一次用到才建会话。use_det/use_cls/use_rec三个开关可以直接跳过整级。来源python/rapidocr/main.py实际影响如果你手里已经是裁好的文本条engine(img, use_detFalse, use_clsFalse)只加载识别模型启动时间和内存都省一大截多 worker 服务里并发请求不会重复建 N 份推理会话。预处理与坐标回映射竖长图为什么也能检出设计意图检测模型对极窄长条图单行文字裁条很不友好输入缩放后检测框还必须能精确对回原图坐标。实现思路resize_image_within_bounds把长边压到max_side_len默认 2000内、短边抬到min_side_len默认 30以上并记录缩放比apply_vertical_padding在宽高比超过width_height_ratio默认 8时对上下加 padding把窄条撑成模型舒服的宽高比所有几何操作都写进op_record最后map_boxes_to_original按记录的顺序逐一反向还原坐标并裁剪到原图边界。来源python/rapidocr/utils/process_img.py实际影响直接丢一张 65x11 的单行文字截图进去也不会漏检且返回的框天然对齐原图像素——这层映射做错了可视化框和识别文本就会错位这是二次开发时最容易碰坏的地方。性能调优实战线程数、批大小、输入尺寸怎么配本节回答拿到一台新机器按什么顺序调参数每项配置改在哪个键上。先看 配置模板 里最关键的几个键都在EngineConfig下配置键作用默认值EngineConfig.onnxruntime.intra_op_num_threads单算子内部线程数-1引擎自决EngineConfig.onnxruntime.inter_op_num_threads算子间并行线程数-1EngineConfig.onnxruntime.enable_cpu_mem_arenaCPU 内存竞技场减少动态分配falseEngineConfig.openvino.inference_num_threadsOpenVINO 推理线程数-1EngineConfig.openvino.performance_hintLATENCY/THROUGHPUT调度提示nullEngineConfig.openvino.num_streams并行推理流数-1Det.limit_side_len检测输入长边上限直接影响 det 耗时736Rec.rec_batch_num识别批大小多文本条时生效6Global.max_side_len全局预处理长边上限2000⚡️ 下面这张表是典型 x86 CPU 上线程数 → 单图端到端耗时的示例数据趋势参考请以你本机实测为准intra_op 线程数ONNX Runtime 端到端ms示例数据现象说明195单核跑完det 阶段占比最大442多数 8 核机器的甜点位838继续加线程收益变小1639上下文切换开销开始显现调优顺序建议先拿result.elapse_listdet/cls/rec 三段耗时定位大头别盲调det 占大头降Det.limit_side_len检测输入从 736 降到 960 以下的档位延迟和精度可以一起换rec 占大头图里文字条多保持rec_batch_num默认 6减少无效文本条比改 batch 更管用服务器批量场景OpenVINO 设performance_hint: THROUGHPUTnum_streams: 2低延迟单请求场景设LATENCY并显式限定inference_num_threads落地避坑清单现象、原因、解法本节回答部署后最常见的几个坑怎么快速定位。1. 现象第一次调用卡住几十秒甚至超时原因运行时在后台下载模型det/cls/rec 三个包。 解法部署前执行rapidocr download_models离线机器则手动把模型放进Global.model_root_dir指定目录。模型清单见 python/rapidocr/default_models.yaml。2. 现象配了use_cuda: true报错或日志显示实际跑在 CPU原因装的是 CPU 版 onnxruntime 轮子CUDA ExecutionProvider 不存在。 解法装 GPU 版 onnxruntime或把use_cuda改回false用session.get_providers()验证实际生效的 provider 列表。3. 现象小字、低对比度文字整条丢失原因默认Global.text_score: 0.5过滤识别置信度Det.box_thresh: 0.5过滤检测框。 解法按顺序放宽text_score0.3 起步、box_thresh0.3、再调大unclip_ratio1.6 → 2.0每次只动一个参数看召回变化。4. 现象窄长条图、竖排图检测框漏检或框不准原因手动关掉了use_vertical_padding窄图直接喂给了检测模型。 解法保持use_vertical_padding: true默认开必要时调width_height_ratio和min_height竖排场景测试图可参考python/tests/test_files/text_vertical_words.png。5. 现象识别日文/韩文等语言结果乱码或字符缺失原因Rec.lang_type默认ch字典表跟随模型加载语言不对会取错字符集。 解法构造时传params{Rec.lang_type: japan}或命令行--lang_type japan注意新语言模型会触发一次下载。6. 现象多 worker 服务内存持续上涨原因默认enable_cpu_mem_arena: false时每次推理都走动态分配或线程数未限制导致每 worker 占满核心。 解法长驻服务可开启enable_cpu_mem_arena: true并设arena_extend_strategy: kSameAsRequested同时显式给intra_op_num_threads一个小于物理核数的固定值。选型建议按硬件和场景挑引擎本节回答同一份代码不同硬件上应该选哪个engine_type。场景推荐引擎说明通用 x86 CPU 服务器onnxruntime默认配置兼容性最好Intel CPU 且想榨性能openvino用performance_hint区分延迟/吞吐NVIDIA GPU 批量识别tensorrt默认开 FP16支持 engine 缓存NVIDIA GPU 通用onnxruntimeuse_cuda: true省掉 TRT 引擎构建步骤嵌入式 / 移动端mnn资源占用最低配置项最少要微调后接入自有数据paddle用 PaddleOCR 训练/微调再导出部署调试、研究网络结构torch内置 SVTR 等识别 backbone 参考实现后续演进方向上主线是继续扩充多语言模型矩阵、配合 PaddleOCR 微调后回流到统一部署链路以及 C/Java/.NET/移动端各语言组件的独立仓库化维护。收尾RapidOCR 的价值不在多快而在一份代码、六套后端、配置级切换——把 OCR 部署的硬件适配成本从代码层降到了配置层。源码仓库clone 用https://gitcode.com/GitHub_Trending/ra/RapidOCR完整配置模板python/rapidocr/config.yaml默认模型清单python/rapidocr/default_models.yaml引擎抽象层python/rapidocr/inference_engine/base.pyDocker 多引擎环境docker/README.md测试用例图片集python/tests/test_files/【免费下载链接】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），仅供参考
