PaddleOCR PP-OCRv6 快速上手指南三档模型 50 种语言一张图搞定 OCR 选型【免费下载链接】PaddleOCRTurn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100 languages.项目地址: https://gitcode.com/GitHub_Trending/pa/PaddleOCR手里堆着一堆扫描件、单据、商品图和路牌照片想喂给 LLM 做结构化分析第一步往往卡在图里的字到底在哪、写的是什么。PaddleOCR 就是干这活的一个轻量级 OCR 工具包把图片和 PDF 转成带坐标的结构化文本支持 100 种语言。它的新一代通用识别方案 PP-OCRv6 基于全新的 PPLCNetV4 骨干用 tiny / small / medium 三档模型覆盖从手机端侧到服务端的全场景一个模型就能同时读中英文、日文和 46 种拉丁语系。下面不讲论文腔直接按你该选哪个 → 怎么跑起来 → 为什么这样设计 → 快不快的顺序带你走完。先选型三档模型分别适合谁结论放前面精度优先选 medium实时性优先选 small端侧极限延迟选 tiny。三者共用同一套 PPLCNetV4 骨干和检测/识别架构区别只在网络宽度和语言覆盖面所以你切换档位时训练和推理管线基本不用动。档位参数规模典型场景语言覆盖tiny约 1.1M端侧 / IoT、嵌入式49 种不含日文small中间档移动端 / 桌面端实时50 种medium34.5M服务端、大规模数据管线50 种简中/繁中/英/日 46 拉丁语系为什么 tiny 砍掉日文因为日文要额外引入约 4000 个汉字/假名字符对只有 1.1M 参数的模型来说光输出层就会膨胀得不成比例。tiny 档还直接用 medium 模型做知识蒸馏训练所以小归小精度没有崩。三档的配置分别放在 configs/det/PP-OCRv6/ 和 configs/rec/PP-OCRv6/想换档只改model_size字段即可复用整条训练管线。最小可运行示例几行代码看到效果装好paddleocr后下面这段就是最完整的端到端 OCR默认直接跑 medium 档from paddleocr import PaddleOCR ocr PaddleOCR( use_doc_orientation_classifyFalse, # 关掉文档方向分类 use_doc_unwarpingFalse, # 关掉文档矫正 use_textline_orientationFalse, # 关掉文本行方向分类 ) result ocr.predict(general_ocr_002.png) for res in result: res.print() # 打印识别结果 res.save_to_img(output) # 存带框图 res.save_to_json(output) # 存结构化 JSON三个开关关掉就是在图很正、文字横排时跳过预处理直接走检测→识别主链路能省掉几个模块的开销。如果你处理的是倾斜的扫描件或手机拍的文档就把它们保持默认开启。命令行等价写法paddleocr ocr -i general_ocr_002.png \ --use_doc_orientation_classify False \ --use_doc_unwarping False \ --use_textline_orientation False原理拆解一张图进来经历了什么别把骨干、检测、识别当成三个孤立模块把它看成一条输入 → 处理 → 输出的流水线理解就快了。第一步骨干提特征PPLCNetV4。输入是一张图骨干网络负责把它变成带语义的特征图。PP-OCRv6 的检测和识别共用这一个骨干靠任务自适应下采样分成两种模式检测模式走标准 stride-2 空间下采样产出 stride 4/8/16/32 的多尺度特征图喂给特征金字塔做聚合。识别模式在 Stage 3/4 用非对称 stride (2,1)只压高度、保留宽度再沿高度轴做平均池化得到 1-D 序列特征专门给 CTC/NRTR 解码用。这正是源码里 rec_lcnetv4.py 中NET_CONFIG_DET与NET_CONFIG_REC两组配置的差别——识别配置里能看到[3, 48, 96, (2, 1), False]这种非对称步长检测配置则全是对称的 stride-2。同一套骨干喂两个任务是这套架构省参数的根。骨干内部的 Block 长什么样遵循 MetaFormer 范式每个 Block 拆成两块3×3 深度卷积做空间混合Token Mixer再加一层可选 SE 通道注意力 扩展比为 2 的通道混合Channel Mixer激活用 GELU。关键 trick 是RepDWConv 三分支结构重参数化3×3 1×1 identity 三条支路配合BN 零初始化训练时用多分支增强表达力推理时合并成单个卷积零额外开销。medium 档通道演进是128 → 256 → 512 → 896small 是48 → 96 → 192 → 384tiny 是32 → 48 → 64 → 160。第二步检测出文本框RepLKFPN 深度监督。检测仍是 DBNet 框架但颈部换成了 RepLKFPN用 7×7 深度膨胀卷积 可重参数化块替换掉上一代的 3×3 普通卷积。感受野从 3×3 拉到 7×7参数量反而降 31%118K vs 172K。实现见 db_fpn.py 里的RepLKFPN/DilatedReparamBlock它带rep()方法在部署前把多分支合并成大核卷积推理零成本。另外在 P2/P3/P4 三层加了辅助预测头做深度监督训练时给更强梯度推理时不额外跑所以不加推理开销——对应的aux_weight_p2/p3/p4权重在 PP-OCRv6_medium_det.yml 里直接可见。损失用 DiceLoss Focal Loss 组合DiceFocalLoss对小目标和密集文本更友好。第三步识别文本内容LightSVTR 颈部 双解码头。颈部EncoderWithLightSVTR干三件事1×7 深度卷积建局部上下文、1–2 层 Transformer 做全局自注意力、用加法跳跃连接替代上一代的拼接concat进一步压参数。注册在 rnn.py 的lightsvtr分支。识别头是MultiHead同时挂了 CTCHead 和 NRTRHeadCTCHead负责真正的推理训练和推理都在用NRTRHead只在训练时当辅助监督推理时直接移除。这个组合写死在 PP-OCRv6_medium_rec.yml 里MultiLoss同时算CTCLoss和NRTRLoss标签由MultiLabelEncode生成label_ctc/label_gtc两套监督。tiny 档则干脆没有颈部直接 reshape FC靠蒸馏补齐精度。性能实测精度与速度到底如何先看精度。下面这张表是内部多场景综合基准的检测 Hmean16 类场景和识别加权准确率15 类场景汇总数字会随数据集和版本演进但量级能帮你判断档位差距模型检测 Hmean (AVG)识别准确率 (W-Avg)PP-OCRv6_medium86.283.2PP-OCRv6_small84.181.3PP-OCRv6_tiny80.673.5PP-OCRv5_server81.678.1PP-OCRv5_mobile75.273.7解读medium 相比 PP-OCRv5_server识别 5.1 个百分点、检测 4.6 个百分点在日文、古籍、屏幕显示、工业字符这类长尾场景提升最猛同时还能压住 VLM 常见的文字幻觉问题。连 1.1M 的 tiny 都超过了多数大型 VLM 在识别上的表现。再看端到端推理速度200 张图含读图 前后处理 推理硬件 / 后端v6_mediumv6_smallv6_tinyv5_serverv5_mobileA100 · PaddlePaddle0.29s0.25s0.13s0.32s0.25sV100 · ONNX Runtime0.67s0.53s0.29s0.77s0.46sXeon 8350C · OpenVINO1.40s0.59s0.20s7.30s0.78sApple M4 · ONNX Runtime5.55s1.29s0.35s7.20s1.10s解读medium 在所有平台都不慢于v5_serverCPU 上 OpenVINO 甚至快 5 倍以上small 和 v5_mobile 速度持平但精度更高tiny 则是跨平台最快的一档。GPU 优先用 PaddlePaddle 原生 TensorRTCPU 场景用 OpenVINO / ONNX Runtime 后端拿最优延迟。能力覆盖语言、场景、硬件一次看全语言medium / small 支持 50 种语言——简中、繁中、英、日 法德意西葡等 46 种拉丁语系tiny 是 49 种去日文。多语言靠字典扩展约 200 个带变音符号字符实现对应两份字典ppocrv6_dict.txt约 1.87 万行medium/small 用ppocrv6_tiny_dict.txt约 6900 行tiny 用。场景除了常规印刷/手写对数码显示屏、点阵字符、轮胎印字等传统通用 VLM 搞不定的工业场景也有针对性优化。硬件 / 系统Windows / Linux / Mac 全兼容NVIDIA GPU、Intel CPU、昆仑芯、昇腾等都能跑推理和部署。部署与进阶从跑通到生产高性能推理HPI加enable_hpiTrue自动切 ONNX Runtime 加速CPU 上收益明显Transformers 引擎装transformers5.8.0后识别模块可用enginetransformers走 HF 引擎适合已有 HF 生态的团队服务化部署支持高稳定在线服务详见 serving 文档二次开发换自己的数据集训练 / 扩展字典 / 微调入口在 文本检测教程 和 文本识别教程训练配置全开放在 configs/det/PP-OCRv6/、configs/rec/PP-OCRv6/。一句话选型建议追求生产级稳定与极致精度选medium移动端/桌面端实时选small端侧或对延迟极度敏感选tiny记住它不读日文。PP-OCRv6 这条统一骨干、分档部署、单模型多语言的路线让你用一套代码就能在三个算力档位间自由切换——从手机到数据中心都不用重写管线。【免费下载链接】PaddleOCRTurn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100 languages.项目地址: https://gitcode.com/GitHub_Trending/pa/PaddleOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PaddleOCR PP-OCRv6 快速上手指南：三档模型 + 50 种语言，一张图搞定 OCR 选型
PaddleOCR PP-OCRv6 快速上手指南三档模型 50 种语言一张图搞定 OCR 选型【免费下载链接】PaddleOCRTurn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100 languages.项目地址: https://gitcode.com/GitHub_Trending/pa/PaddleOCR手里堆着一堆扫描件、单据、商品图和路牌照片想喂给 LLM 做结构化分析第一步往往卡在图里的字到底在哪、写的是什么。PaddleOCR 就是干这活的一个轻量级 OCR 工具包把图片和 PDF 转成带坐标的结构化文本支持 100 种语言。它的新一代通用识别方案 PP-OCRv6 基于全新的 PPLCNetV4 骨干用 tiny / small / medium 三档模型覆盖从手机端侧到服务端的全场景一个模型就能同时读中英文、日文和 46 种拉丁语系。下面不讲论文腔直接按你该选哪个 → 怎么跑起来 → 为什么这样设计 → 快不快的顺序带你走完。先选型三档模型分别适合谁结论放前面精度优先选 medium实时性优先选 small端侧极限延迟选 tiny。三者共用同一套 PPLCNetV4 骨干和检测/识别架构区别只在网络宽度和语言覆盖面所以你切换档位时训练和推理管线基本不用动。档位参数规模典型场景语言覆盖tiny约 1.1M端侧 / IoT、嵌入式49 种不含日文small中间档移动端 / 桌面端实时50 种medium34.5M服务端、大规模数据管线50 种简中/繁中/英/日 46 拉丁语系为什么 tiny 砍掉日文因为日文要额外引入约 4000 个汉字/假名字符对只有 1.1M 参数的模型来说光输出层就会膨胀得不成比例。tiny 档还直接用 medium 模型做知识蒸馏训练所以小归小精度没有崩。三档的配置分别放在 configs/det/PP-OCRv6/ 和 configs/rec/PP-OCRv6/想换档只改model_size字段即可复用整条训练管线。最小可运行示例几行代码看到效果装好paddleocr后下面这段就是最完整的端到端 OCR默认直接跑 medium 档from paddleocr import PaddleOCR ocr PaddleOCR( use_doc_orientation_classifyFalse, # 关掉文档方向分类 use_doc_unwarpingFalse, # 关掉文档矫正 use_textline_orientationFalse, # 关掉文本行方向分类 ) result ocr.predict(general_ocr_002.png) for res in result: res.print() # 打印识别结果 res.save_to_img(output) # 存带框图 res.save_to_json(output) # 存结构化 JSON三个开关关掉就是在图很正、文字横排时跳过预处理直接走检测→识别主链路能省掉几个模块的开销。如果你处理的是倾斜的扫描件或手机拍的文档就把它们保持默认开启。命令行等价写法paddleocr ocr -i general_ocr_002.png \ --use_doc_orientation_classify False \ --use_doc_unwarping False \ --use_textline_orientation False原理拆解一张图进来经历了什么别把骨干、检测、识别当成三个孤立模块把它看成一条输入 → 处理 → 输出的流水线理解就快了。第一步骨干提特征PPLCNetV4。输入是一张图骨干网络负责把它变成带语义的特征图。PP-OCRv6 的检测和识别共用这一个骨干靠任务自适应下采样分成两种模式检测模式走标准 stride-2 空间下采样产出 stride 4/8/16/32 的多尺度特征图喂给特征金字塔做聚合。识别模式在 Stage 3/4 用非对称 stride (2,1)只压高度、保留宽度再沿高度轴做平均池化得到 1-D 序列特征专门给 CTC/NRTR 解码用。这正是源码里 rec_lcnetv4.py 中NET_CONFIG_DET与NET_CONFIG_REC两组配置的差别——识别配置里能看到[3, 48, 96, (2, 1), False]这种非对称步长检测配置则全是对称的 stride-2。同一套骨干喂两个任务是这套架构省参数的根。骨干内部的 Block 长什么样遵循 MetaFormer 范式每个 Block 拆成两块3×3 深度卷积做空间混合Token Mixer再加一层可选 SE 通道注意力 扩展比为 2 的通道混合Channel Mixer激活用 GELU。关键 trick 是RepDWConv 三分支结构重参数化3×3 1×1 identity 三条支路配合BN 零初始化训练时用多分支增强表达力推理时合并成单个卷积零额外开销。medium 档通道演进是128 → 256 → 512 → 896small 是48 → 96 → 192 → 384tiny 是32 → 48 → 64 → 160。第二步检测出文本框RepLKFPN 深度监督。检测仍是 DBNet 框架但颈部换成了 RepLKFPN用 7×7 深度膨胀卷积 可重参数化块替换掉上一代的 3×3 普通卷积。感受野从 3×3 拉到 7×7参数量反而降 31%118K vs 172K。实现见 db_fpn.py 里的RepLKFPN/DilatedReparamBlock它带rep()方法在部署前把多分支合并成大核卷积推理零成本。另外在 P2/P3/P4 三层加了辅助预测头做深度监督训练时给更强梯度推理时不额外跑所以不加推理开销——对应的aux_weight_p2/p3/p4权重在 PP-OCRv6_medium_det.yml 里直接可见。损失用 DiceLoss Focal Loss 组合DiceFocalLoss对小目标和密集文本更友好。第三步识别文本内容LightSVTR 颈部 双解码头。颈部EncoderWithLightSVTR干三件事1×7 深度卷积建局部上下文、1–2 层 Transformer 做全局自注意力、用加法跳跃连接替代上一代的拼接concat进一步压参数。注册在 rnn.py 的lightsvtr分支。识别头是MultiHead同时挂了 CTCHead 和 NRTRHeadCTCHead负责真正的推理训练和推理都在用NRTRHead只在训练时当辅助监督推理时直接移除。这个组合写死在 PP-OCRv6_medium_rec.yml 里MultiLoss同时算CTCLoss和NRTRLoss标签由MultiLabelEncode生成label_ctc/label_gtc两套监督。tiny 档则干脆没有颈部直接 reshape FC靠蒸馏补齐精度。性能实测精度与速度到底如何先看精度。下面这张表是内部多场景综合基准的检测 Hmean16 类场景和识别加权准确率15 类场景汇总数字会随数据集和版本演进但量级能帮你判断档位差距模型检测 Hmean (AVG)识别准确率 (W-Avg)PP-OCRv6_medium86.283.2PP-OCRv6_small84.181.3PP-OCRv6_tiny80.673.5PP-OCRv5_server81.678.1PP-OCRv5_mobile75.273.7解读medium 相比 PP-OCRv5_server识别 5.1 个百分点、检测 4.6 个百分点在日文、古籍、屏幕显示、工业字符这类长尾场景提升最猛同时还能压住 VLM 常见的文字幻觉问题。连 1.1M 的 tiny 都超过了多数大型 VLM 在识别上的表现。再看端到端推理速度200 张图含读图 前后处理 推理硬件 / 后端v6_mediumv6_smallv6_tinyv5_serverv5_mobileA100 · PaddlePaddle0.29s0.25s0.13s0.32s0.25sV100 · ONNX Runtime0.67s0.53s0.29s0.77s0.46sXeon 8350C · OpenVINO1.40s0.59s0.20s7.30s0.78sApple M4 · ONNX Runtime5.55s1.29s0.35s7.20s1.10s解读medium 在所有平台都不慢于v5_serverCPU 上 OpenVINO 甚至快 5 倍以上small 和 v5_mobile 速度持平但精度更高tiny 则是跨平台最快的一档。GPU 优先用 PaddlePaddle 原生 TensorRTCPU 场景用 OpenVINO / ONNX Runtime 后端拿最优延迟。能力覆盖语言、场景、硬件一次看全语言medium / small 支持 50 种语言——简中、繁中、英、日 法德意西葡等 46 种拉丁语系tiny 是 49 种去日文。多语言靠字典扩展约 200 个带变音符号字符实现对应两份字典ppocrv6_dict.txt约 1.87 万行medium/small 用ppocrv6_tiny_dict.txt约 6900 行tiny 用。场景除了常规印刷/手写对数码显示屏、点阵字符、轮胎印字等传统通用 VLM 搞不定的工业场景也有针对性优化。硬件 / 系统Windows / Linux / Mac 全兼容NVIDIA GPU、Intel CPU、昆仑芯、昇腾等都能跑推理和部署。部署与进阶从跑通到生产高性能推理HPI加enable_hpiTrue自动切 ONNX Runtime 加速CPU 上收益明显Transformers 引擎装transformers5.8.0后识别模块可用enginetransformers走 HF 引擎适合已有 HF 生态的团队服务化部署支持高稳定在线服务详见 serving 文档二次开发换自己的数据集训练 / 扩展字典 / 微调入口在 文本检测教程 和 文本识别教程训练配置全开放在 configs/det/PP-OCRv6/、configs/rec/PP-OCRv6/。一句话选型建议追求生产级稳定与极致精度选medium移动端/桌面端实时选small端侧或对延迟极度敏感选tiny记住它不读日文。PP-OCRv6 这条统一骨干、分档部署、单模型多语言的路线让你用一套代码就能在三个算力档位间自由切换——从手机到数据中心都不用重写管线。【免费下载链接】PaddleOCRTurn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100 languages.项目地址: https://gitcode.com/GitHub_Trending/pa/PaddleOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考