PP-OCRv6 深度解析PPLCNetV4 统一骨干、三档模型族与 50 语言完整实战指南【免费下载链接】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/PaddleOCRPP-OCRv6 是 PaddleOCR 推出的最新一代通用 OCR 模型族同一套 PPLCNetV4 骨干架构派生出 tiny、small、medium 三档模型参数覆盖 1.5M 到 34.5M单一模型原生识别简中、繁中、英文、日文及 46 种拉丁语系共 50 种语言。官方内部多场景基准上medium 档检测 Hmean 达 86.2%、识别加权准确率 83.2%相比上一代 PP-OCRv5_server 分别提升 4.6 和 5.1 个百分点GPU 推理速度提升 2.37 倍。三档模型三种用法PP-OCRv6 怎么选档位参数量目标场景语言支持tiny约 1.1M识别子模型端侧 / IoT49 种不含日文small中间档介于 tiny 与 medium 之间移动端 / 桌面端50 种medium34.5M服务端50 种简中、繁中、英文、日文 46 种拉丁语系官方文档给出的整族参数区间是 1.5M 至 34.5M三档共用同一骨干与同一套检测/识别管线。换个档位往往只需把配置里的model_size改成tiny或small。选型逻辑很直接服务端大批量文档管线、离线数据处理、精度优先选 medium手机 App 和桌面端实时识别、精度与延迟要平衡选 small嵌入式设备或对延迟极度敏感选 tiny。值得一提的是 tiny 档放弃了日文。日文需要约 4000 个汉字和假名字符这些字符会直接落在输出层权重上。对 1.1M 参数的模型来说这个输出矩阵的膨胀不可接受所以 tiny 用 49 语言换一个小巧的输出层。⚡ 硬指标先行精度与速度数据检测 Hmean16 类场景平均 86.2%测试条件官方内部多场景基准16 类场景指标为 Hmean(%)。模型AVG手写CN印刷CN繁体古籍日文模糊扭曲拼音艺术字表格旋转工业PP-OCRv6_medium86.283.795.186.380.284.394.188.674.069.096.893.873.3PP-OCRv6_small84.180.594.285.772.682.392.687.669.665.395.693.767.6PP-OCRv6_tiny80.679.493.183.763.076.689.386.159.060.194.791.062.0PP-OCRv5_server81.680.394.581.567.677.290.187.667.167.397.180.064.3PP-OCRv5_mobile75.274.490.582.358.172.787.482.757.552.592.864.752.8Gemini-3.1-Pro46.853.447.339.045.838.250.044.640.665.226.922.152.5GPT-5.545.642.450.235.026.742.049.137.736.352.071.010.036.2Qwen3-VL-235B38.356.541.719.313.127.038.528.533.068.319.62.148.4medium 相比 PP-OCRv5_server 的提升集中在长尾场景日文 84.3 对 77.2古籍 80.2 对 67.6旋转 93.8 对 80.0工业字符 73.3 对 64.3。v5_server 只在表格场景97.1 对 96.8略占优。再看 VLM 一列表现最好的 Gemini-3.1-Pro 平均 46.8只有 medium 的一半不到。识别准确率15 类场景加权平均 83.2%测试条件同上官方内部多场景基准15 类场景指标为识别准确率(%)。模型W-Avg手写CN印刷CN繁体古籍日文易混淆特殊字符通用拼音艺术字工业屏幕卡片PP-OCRv6_medium83.262.191.578.672.490.564.961.787.578.171.277.482.588.1PP-OCRv6_small81.357.690.577.071.188.264.160.285.775.968.476.479.786.9PP-OCRv6_tiny73.540.186.765.068.489.852.357.178.065.454.762.171.280.5PP-OCRv5_server78.158.090.174.760.473.759.456.886.574.464.070.268.187.6PP-OCRv5_mobile73.741.786.072.057.875.855.754.880.772.554.059.357.681.7Qwen3-VL-235B74.949.782.376.433.666.256.149.082.576.569.674.773.878.7Gemini-3.1-Pro71.446.480.069.518.067.254.450.374.675.963.169.173.275.9GPT-5.564.219.275.757.563.758.649.148.367.750.453.062.467.771.1提升幅度最大的是日文16.8%、屏幕显示14.4%和古籍12.0%。v5_server 仅在卡片场景87.6 对 88.1 相差不大卡片为 v5 略优的个别项上保持微弱优势。官方文档同时指出仅 1.1M 参数的 tiny 档也超越了 4/5 的 VLM 模型。端到端推理速度6 种硬件与后端组合测试条件200 张图像通用场景 文档场景包含读图、前后处理、模型推理全流程单位 s/image。硬件推理后端v6_mediumv6_smallv6_tinyv5_serverv5_mobilev4_mobileNVIDIA A100PaddlePaddle0.290.250.130.320.250.14NVIDIA A100TensorRT--0.320.16--0.330.16NVIDIA V100PaddlePaddle0.720.490.210.660.500.25NVIDIA V100ONNX Runtime0.670.530.290.770.460.27NVIDIA V100TensorRT0.770.600.230.730.590.27Intel Xeon 8350CPaddlePaddle2.050.790.322.040.800.62Intel Xeon 8350COpenVINO1.400.590.207.300.780.60Intel Xeon 8350CONNX Runtime3.310.610.226.360.610.49Apple M4PaddlePaddle8.823.070.96105.825.65Apple M4ONNX Runtime5.551.290.357.201.101.02三个要点。第一medium 在所有平台上匹配或优于 v5_serverA100 上 0.29s 对 0.32sV100 ONNX Runtime 快 1.15 倍Intel Xeon OpenVINO 后端快 5.2 倍1.40s 对 7.30s。第二small 速度大体持平 v5_mobile 但精度更高Apple M4 PaddlePaddle 后端快 1.9 倍3.07s 对 5.82s。第三tiny 是全平台最快的模型M4 上快 6.1 倍0.96s 对 5.82sXeon OpenVINO 快 3.9 倍A100 上单图 0.13s。架构拆解一个骨干两套任务PPLCNetV4MetaFormer 块 结构重参数化骨干源码在 rec_lcnetv4.py。每个 LCNetV4Block 遵循 MetaFormer 范式一种把空间混合和通道混合解耦的设计先做空间混合再做通道混合各自带残差$$\hat{\mathbf{x}} \text{SE}(\text{DW}(\mathbf{x})) \mathbf{x}, \qquad \mathbf{y} W_2,\sigma(W_1,\hat{\mathbf{x}}) \hat{\mathbf{x}}$$其中 $\text{DW}(\cdot)$ 是 3×3 深度卷积负责让不同像素之间交换信息Token MixerSE 是可选的通道注意力模块$W_1 \in \mathbb{R}^{2C \times C}$、$W_2 \in \mathbb{R}^{C \times 2C}$ 构成扩展比为 2 的通道变换Channel Mixer$\sigma$ 是 GELU 激活。骨架里还有两味轻量子弹。其一是结构重参数化训练时多分支、推理时合并为单卷积的技巧空间混合用的 RepDWConv 在训练期是 3×3 1×1 identity 三个并行分支部署前调用rep()合并成一个卷积推理零额外开销。其二是 Compress 层 BN 零初始化让每个 Block 训练初期近似恒等映射深层网络收敛更稳。通道宽度按档位分三档检测配置NET_CONFIG_DET中为medium 是 128 → 256 → 512 → 896small 是 48 → 96 → 192 → 384tiny 是 32 → 48 → 64 → 160。识别配置NET_CONFIG_REC中 medium 为 128 → 256 → 512 → 768。配置里每个 Block 形如[3, 512, 512, 1, True]末位布尔值表示是否启用 SE。和上一代 LCNetV3 的对比设计维度LCNetV3LCNetV4架构范式MobileNet-styleDW→SE→PWMetaFormerTokenMixer ChannelMixer通道交互单个 1×1 PW ConvExpand(2×)→Act→Compress 残差空间混合普通 DW ConvRepDWConv3×3 1×1 identity 三分支BN 初始化标准Compress 层 BN 零初始化任务自适应下采样同一骨干两种压缩方式检测要的是多尺度空间特征识别要的是保住文字行的横向上下文。PPLCNetV4 用下采样策略把两件事分开检测模式标准 stride-2 空间下采样产出 stride 4/8/16/32 四组特征图交给特征金字塔聚合识别模式Stage 3/4 改用非对称 stride (2,1)只把高度减半、宽度原样保留最后沿高度轴平均池化得到一维序列特征供 CTC/NRTR 解码。这一设计直接写在源码的识别配置里形如[3, 96, 96, (2, 1), False]。对照检测配置里全是标量 stride 2差异一目了然。说白了识别时你只想让特征图变窄不想让文字行变短。RepLKFPN 如何把参数量砍掉 31%检测侧沿用 DBNet基于二值化概率图做文字区域分割的框架颈部升级为 db_fpn.py 中的RepLKFPN。它把 PP-OCRv5 RSEFPN 里的 3×3 普通卷积替换为DilatedReparamBlock7×7 深度卷积 膨胀分支加 1×1 点卷积再加 SE 的组合。结果是参数量 172K 降到 118K-31%感受野一个神经元能看到的输入区域从 3×3 扩到 7×7。大感受野对小字和密集文本很关键3×3 卷积看到的邻域太小小目标文字的特征容易被稀释。训练期DilatedReparamBlock用多个膨胀模式并行源码注释给出 3、5 的组合示例推理期合并为单个大核深度卷积零额外成本。深度监督是配套的训练侧增益。训练时在 P2、P3、P4 三个尺度各挂一个预测头给浅层特征更直接的梯度RepLKFPN.forward训练态返回fuse加aux_p2/p3/p4三份特征推理态只返回融合结果不加任何推理开销。损失用 DiceFocalLossDice Loss 与 Focal Loss 的组合前者缓解类别不平衡后者聚焦难样本配置见 PP-OCRv6_medium_det.ymlLoss: name: DBLoss main_loss_type: DiceFocalLoss alpha: 5 beta: 10 focal_alpha: 0.25 focal_gamma: 2.5 aux_weight_p4: 0.2 # 深度监督权重P2 最高逐层递减 aux_weight_p3: 0.3 aux_weight_p2: 0.4这段配置定义了主损失中 Focal 部分的超参和三个辅助头的加权方式越浅的层级权重越高因为它离输入最近、最需要监督。检测侧其余关键配置算法DBBackbonePPLCNetV4det: truemodel_size: mediumNeckRepLKPANout_channels 256开启 intracl 通道重标定HeadDBHeadk50。优化器 Adamβ10.9, β20.999 Cosine 学习率初始 0.001warmup 2 epoch L2 正则 1e-5后处理DBPostProcessthresh 0.2、box_thresh 0.45、max_candidates 3000、unclip_ratio 1.4训练 500 epoch图像 640×640EMA 衰减 0.9996。tiny/small 档配置就在同目录 configs/det/PP-OCRv6/改model_size即可复用同一管线。识别侧LightSVTR 颈部 CTC/NRTR 双头识别颈部是EncoderWithLightSVTR注册在 rnn.py。它做三层事1×7 深度卷积建局部上下文local_kernel: 71-2 层 Transformer 做全局自注意力depth: 2跳跃连接用逐元素加法。PP-OCRv5 的 SVTR 用拼接加法方案直接省掉拼接带来的参数膨胀。解码用多头结构MultiHeadrec_multi_head.py配置见 PP-OCRv6_medium_rec.ymlHead: name: MultiHead head_list: - CTCHead: # 主解码器训练和推理都用 Neck: name: lightsvtr dims: 192 depth: 2 mlp_ratio: 4.0 local_kernel: 7 use_guide: false Head: fc_decay: 0.00001 - NRTRHead: # 辅助解码器仅训练时监督推理时移除 nrtr_dim: 512 max_text_length: 25CTCHead 是主力CTCConnectionist Temporal Classification一种对齐变长序列的解码方式解码天然支持并行推理。NRTRHead 只在训练期提供辅助监督信号MultiLoss里同时配CTCLoss和NRTRLoss推理时整个头被裁掉。标签由MultiLabelEncode一次生成label_ctc与label_gtc两套监督。训练侧还有两个工程细节。多尺度采样MultiScaleSampler在[[320, 32], [320, 48], [320, 64]]三种宽度/高度组合间动态切换批大小 64让模型适应不同宽高比的文字行。文本级增强RecConAug概率 0.5融合 2 张外部图把不同样本的文本拼到一起强化对长文本和密集排版的鲁棒性。优化器 Adam Cosine学习率 0.0005warmup 5 epoch L2 3e-5后处理CTCLabelDecode指标RecMetricacc。tiny 档识别是无颈部设计CTCHead 的 Neck 直接是reshapemid_channels: 80并开启use_guide: true用 medium 模型做知识蒸馏训练。配置在 PP-OCRv6_tiny_rec.yml。1.1M 参数的模型自己学不出足够好的表征借老师模型的输出分布来学是端侧小模型的标准打法。50 语言一个模型字典扩展与 tiny 的工程权衡medium/small 档的 50 种语言 4 种核心语言简体中文、繁体中文、英文、日文 46 种拉丁语系完整清单见官方文档 PP-OCRv6.md。拉丁语系覆盖法、德、西、葡、荷、波、捷克、瑞典、土耳其、越南、印尼、马来、乌兹别克、塞尔维亚拉丁、加泰罗尼亚、巴斯克、罗曼什、克丘亚等长尾程度远超一般 OCR 产品。单模型多语言的实现手段是字典扩展在基础字典上加入约 200 个带变音符号字符diacritical如 é、ñ、š、đ 这类带声调或重音标记的字母让一个输出层同时覆盖 50 种语言。仓库里对应两份字典ppocrv6_dict.txtmedium/small 档50 语言ppocrv6_tiny_dict.txttiny 档49 语言剔除日文。识别配置用character_dict_path: ppocr/utils/dict/ppocrv6_dict.txt加use_space_char: true指定字典max_text_length: 25限制最大文本长度。tiny 档不做日文的原因前面提过约 4000 个汉字/假名字符会显著撑大 1.1M 参数模型的输出层工程上不划算。 五分钟跑通从 Python API 到 CLIPython API默认 medium 端到端 OCRfrom paddleocr import PaddleOCR # 默认使用 PP-OCRv6_medium 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)三个开关关掉的是文档方向分类、文档矫正、文本行方向分类这三个预处理模块。纯文字图关掉它们就直接走检测 → 识别主链路省掉三次额外推理扫描件倾斜严重就保留开启。CLI一条命令跑同一条管线paddleocr ocr -i general_ocr_002.png \ --use_doc_orientation_classify False \ --use_doc_unwarping False \ --use_textline_orientation False参数和 Python API 一一对应脚本化批处理时用这个入口最省事。Transformers 引擎复用 Hugging Face 推理栈from paddleocr import TextRecognition model TextRecognition( model_namePP-OCRv6_medium_rec, enginetransformers, # 需安装 transformers5.8.0 ) output model.predict(inputgeneral_ocr_rec_001.png, batch_size1) for res in output: res.print()这里只跑识别模块走 Hugging Face Transformers 的推理栈。适合已有 transformers 生态、想在统一框架里管理模型资产的场景。HPI 高性能推理一个开关切到 ONNX Runtimefrom paddleocr import PaddleOCR ocr PaddleOCR( use_doc_orientation_classifyFalse, use_doc_unwarpingFalse, use_textline_orientationFalse, enable_hpiTrue, # 高性能推理插件底层自动用 ONNX Runtime ) result ocr.predict(general_ocr_002.png)enable_hpiTrue启用高性能推理插件后模型自动转换为 ONNX 格式并用 ONNX Runtime 执行。插件需额外安装安装与配置见高性能推理指南CLI 对应--enable_hpi True。生产部署与二次开发部署面覆盖全链路。系统层兼容 Windows、Linux、Mac硬件层支持 NVIDIA GPU、Intel CPU、昆仑芯、昇腾等。GPU 上可配合 TensorRT 进一步压缩延迟CPU 场景组合 OpenVINO 或 ONNX Runtime 后端具体数字见前文速度表压测方法见基准测试文档。需要长期对外提供能力时走服务化部署方案。二次开发入口是标准的配置 训练脚本组合训练入口 tools/train.py检测与识别配置分别在 configs/det/PP-OCRv6/ 和 configs/rec/PP-OCRv6/。自定义数据集、字典扩展、模型微调的完整流程见文本检测模块使用教程和文本识别模块使用教程。因为三档共用架构在 medium 配置上微调后把权重迁移思路复用到 small/tiny 档是自然的路径。选型决策卡场景映射档位与推理后端使用场景推荐档位推荐推理后端服务端大批量文档管线、数据标注mediumA100/V100PaddlePaddle 或 TensorRTCPU 服务器、成本优先mediumIntel XeonOpenVINO1.40s 对原生 2.05s移动端 / 桌面端实时识别smallONNX Runtime 或 OpenVINO端侧 / IoT、延迟极度敏感tinyCPU OpenVINOXeon 上 0.20s/图业务涉及日文文本medium 或 smalltiny 不支持日文不在此场景考虑精度优先就上 medium配合 GPU 原生推理或 TensorRT 拿满性能。延迟优先就往下走档位small 在多数平台与上代 mobile 版速度持平但精度更高tiny 则是全平台最快且精度仍压制多数 VLM。三档同架构、同管线一个合理的做法是先用 medium 跑通业务基线再按实测延迟需求降到 small 或 tiny配置层面只改model_size一项。【免费下载链接】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），仅供参考