PP-OCRv6 实战PPLCNetV4 统一骨干如何用三档轻量模型打穿 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从一张轮胎照片说起先讲两个真实到不能再真实的场景。第一产线质检。一条轮胎侧壁上的钢印字符背景是高对比橡胶、字符间距不一、还带弧度。你把它丢给一个百亿参数的视觉语言模型它要么直接编出一串看起来合理的型号——而那个型号根本不存在于照片里要么返回一大段自然语言描述你最后还是得再写一套规则去提取字段。第二跨境电商后台。一天几万张商品图中英德法西文混排还有越南语、土耳其语这类带变音符号的文字。传统做法是给每种语言单独维护一个识别模型维护成本随语言数线性上涨。这两个场景背后其实是同一个诉求要一个足够轻、能上端侧和 GPU 两边的模型还要在一个权重里把几十种语言一起吃掉并且在没有文字的地方老老实实说没有。PP-OCRv6 就是奔着这件事来的——它是 PP-OCR 的新一代通用文字识别方案用一个叫 PPLCNetV4 的统一骨干网络派生出 tiny、small、medium 三档模型。三档模型一张表看懂能力边界PP-OCRv6 不是一个模型而是一个共享同一套架构、只改宽度参数的模型族。选型之前先把它的边界钉死在一张表里档位参数量级目标场景语言数识别颈部tiny约 1.1M端侧 / IoT49不含日文无reshape FCsmall中间档移动端 / 桌面端50EncoderWithLightSVTRmedium34.5M服务端50EncoderWithLightSVTR这张表回答的是我的场景该用哪一档。三句话建立整体认知medium 档以34.5M 参数在内部多场景基准上拿到86.2% 检测 Hmean、83.2% 识别加权准确率small 与 medium 同架构、只缩小宽度适合移动端实时tiny 砍掉识别颈部直接上全连接专为端侧极限压缩。至于语言medium/small 单权重覆盖简中、繁中、英文、日文加 46 种拉丁语系共 50 种tiny 因为输出层放不下日文那约 4000 个汉字/假名字符而少一种。技术内核为什么是一个骨干吃两个任务设计哲学宽度参数化而不是一套套架构传统做法里检测一个网、识别一个网端侧一档、服务端又一档架构是叉出来的。PP-OCRv6 反过来同一套 PPLCNetV4 骨干靠一组宽度配置同时服务检测与识别。这套配置的入口在 rec_lcnetv4.py 里的NET_CONFIG_DET与NET_CONFIG_REC两张字典——检测模式 medium 档通道从 stem 输出的 128 一路演进到128 → 256 → 512 → 896small 档是48 → 96 → 192 → 384tiny 档是32 → 48 → 64 → 160。说白了三档不是三个模型而是同一结构在宽度轴上的三个取值。这个决策带来的直接好处是训练管线、后处理、部署链路全部复用新增语言或新档位不需要动架构代码。LCNetV4Block把空间和通道两件事拆开单个 Block 遵循 MetaFormer 范式把一次前向拆成空间混合Token Mixer和通道混合Channel Mixer两步。设输入特征为 x两步计算是x̂ SE(DW(x)) xy W2·σ(W1·x̂) x̂直觉上第一步的 3×3 深度卷积DW让每个像素去看自己的 8 个邻居第二步的两层全连接W1、W2扩展比为 2σ 是 GELU让每个位置在通道维度上做加权融合两个加号是残差连接保证梯度能顺畅回流。相比上一代 LCNetV3 的单个 1×1 点卷积换通道V4 用先扩 2 倍→激活→压回 残差的方式让通道交互更充分代价是多一点计算——而这一点计算在重参数化之后几乎被抹掉见下。重参数化草稿纸上推导交卷时合并成一步这是理解 PP-OCRv6 为什么训练复杂、推理便宜的钥匙。它的空间卷积用三分支结构 RepDWConv3×3、1×1 和一个恒等分支并存。训练时这三个分支各自学习表达能力更强部署前调用rep()把它们按权重合并成单个卷积BN 也一并折叠进去。类比一下草稿纸上用三步推导保证算得对交卷时把三步合并成一步直接写答案——推理时看不出训练时那份冗余零额外开销。压缩层的 BN 还做了零初始化让网络起步时每个 Block 近似恒等映射训练更稳。设计维度LCNetV3LCNetV4架构范式MobileNet 风格DW→SE→PWMetaFormerTokenMixer ChannelMixer通道交互单个 1×1 点卷积扩 2×→激活→压回 残差空间卷积普通 DWRepDWConv 三分支可重参数化BN 初始化标准压缩层零初始化一骨干两任务的关键任务自适应下采样同一个骨干检测要多尺度特征图识别要一维序列。PP-OCRv6 的解法是改下采样方向而不是改网络。检测模式用标准 stride-2 对称下采样产出 stride 4/8/16/32 的多尺度图交给 FPN识别模式则在后段 Stage 用非对称步长(2,1)——只把高度压掉、宽度保留再沿高度轴平均池化得到一维序列喂给 CTC/NRTR 解码。NET_CONFIG_REC里的[3, 48, 96, (2, 1), False]就是这条非对称下采样路径。这里有个坑值得点破别小看只压高度这一步它保住了文字在水平方向上的像素分辨率而这恰恰是识别精度最敏感的方向。检测侧RepLKFPN 的大核是怎么省下来的检测模块在 PP-OCRv5 的 DBNet 框架上做了三处升级核心是把特征金字塔颈部换成了 RepLKFPN。大核轻量 FPN。上一代 RSEFPN 用 3×3 普通卷积做输入层PP-OCRv6 换成DilatedReparamBlock——一个膨胀深度卷积加重参数化。它配合训练期多膨胀率如 3、5 模式把感受野从 3×3 撑到 7×7参数反而少了约 31%118K 对 172K。db_fpn.py 里的RepLKFPN把这个逻辑拆成深度大核重参数卷积 1×1 点卷积 SE 注意力三段并保留rep()方法在部署前把多分支合并成单卷积。这里的大感受野解决的是长文本行和小目标检测——字符越分散越需要看得远。辅助深度监督。在 P2、P3、P4 三个层级各挂一个预测头只在训练时参与、提供更强梯度推理时完全移除。这在 PP-OCRv6_medium_det.yml 里直接可见Loss: name: DBLoss main_loss_type: DiceFocalLoss # Dice Focal 组合利好小目标与密集文本 focal_alpha: 0.25 # Focal 类别平衡 focal_gamma: 2.5 # Focal 难易样本调节 aux_weight_p2: 0.4 # P2/P3/P4 辅助头加权 aux_weight_p3: 0.3 aux_weight_p4: 0.2DiceFocal 损失。把 DiceLoss 和 Focal Loss 揉在一起DiceFocalLoss对密集文本的逐像素监督更稳。这套检测配置的完整参数——Adam 优化器、Cosine 学习率、640×640 训练尺寸、500 epoch、EMA 衰减 0.9996——都能在该 YAML 里逐字段核对。识别侧多头解码与训练用两个头、推理只留一个识别模块的颈部是 rnn.py 里注册的EncoderWithLightSVTR配置里叫lightsvtr。它做两件事用 1×7 深度卷积建局部上下文再用 1–2 层 Transformer 建全局注意力。关键点在连接方式——它用加法跳跃连接替代了 PP-OCRv5 的拼接。把两路特征相加而不是首尾相接参数量直接降下来PP-OCRv6_medium_rec.yml 中dims: 192、depth: 2、mlp_ratio: 4.0、local_kernel: 7就是这组参数的落地。解码端是两头设计。MultiHead同时挂了CTCHead和NRTRHeadCTC 负责高效并行推理NRTR 只在训练时做辅助监督推理时被整个移除。多语言则靠字典扩展约 200 个带变音符号的字符实现——medium/small 用 1.87 万行的ppocrv6_dict.txttiny 用 6904 行的精简字典配置里max_text_length: 25限长、use_space_char: true保留空格。tiny 档则干脆没有颈部直接 reshape 加全连接并用 medium 做知识蒸馏训练use_guide: true把小模型学大模型这件事写进了配置。从跑通一张图到生产级配置第一步最小可运行示例。装好依赖后默认就是 medium 档端到端 OCRfrom 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)这三个开关的含义值得说清它们分别控制文档方向分类、文档矫正、文本行方向分类。对已经摆正的纯文字图关掉能省掉整段预处理处理倾斜扫描件或拍照文档时再打开。第二步走命令行。不写 Python 时用 CLI 同样能跑paddleocr ocr -i general_ocr_002.png \ --use_doc_orientation_classify False \ --use_doc_unwarping False \ --use_textline_orientation False第三步生产级加速。要压延迟就启用高性能推理插件HPI底层自动切到 ONNX Runtimeocr PaddleOCR( use_doc_orientation_classifyFalse, use_doc_unwarpingFalse, use_textline_orientationFalse, enable_hpiTrue, # 自动走 ONNX Runtime 后端 ) result ocr.predict(general_ocr_002.png)如果识别模块想接 Hugging Face Transformers 生态需transformers5.8.0也可以用TextRecognition(model_namePP-OCRv6_medium_rec, enginetransformers)单独拉起识别头。性能画像数字背后是什么含义在 200 张图通用 文档场景上测端到端 OCR包含读图、前后处理和推理全流程。选几个代表点看硬件后端v6_mediumv5_serverA100PaddlePaddle0.29s0.32sV100ONNX Runtime0.67s0.77sXeon 8350COpenVINO1.40s7.30sApple M4PaddlePaddle8.82s10s这张表回答换到 v6 我的吞吐会怎样。三个结论medium 在主流后端上都不慢于上一代 server 档CPU 上差距尤其大Xeon OpenVINO 快约 5.2 倍small 和 mobile 档速度持平但精度更高tiny 是全平台最快的一档Apple M4 上约 0.96s 一张。换句话说精度提升没有以速度为代价反而在 CPU 侧拉开了代差。精度对比86.2% Hmean、83.2% 识别准确率、对比 PP-OCRv5_server 提升 4.6%/5.1%均为官方内部多场景基准数据具体数值随数据集与版本演进而变化。生产落地从单机到服务化按从简单到复杂排个序。最轻的一步是 Python API / CLI前面已经覆盖其次是高性能推理插件用 ONNX Runtime 后端进一步压延迟再往上走服务化部署拿高稳定性的在线服务形态。硬件侧兼容 Windows/Linux/Mac推理支持 NVIDIA GPU、Intel CPU、昆仑芯、昇腾等。要做二次开发仓库把训练配置configs/det/PP-OCRv6/、configs/rec/PP-OCRv6/和字典文件全部开放改model_size就能复用同一套管线换档扩字典或微调只需替换character_dict_path指向的新字典。决策速查按场景对号入座省去纠结服务端、要精度和稳定直接上 medium配 TensorRTGPU或 OpenVINO/ONNX RuntimeCPU。移动端/桌面端实时选 small架构与 medium 相同只缩宽度精度损失可控。端侧/IoT、对延迟极度敏感选 tiny注意它不含日文若业务强依赖日文要回退到 small。多语言混排文档medium/small 单权重即可不必为每种语言单独维护模型。工业长尾场景数码屏、点阵、轮胎印字、旋转文本优先 medium这类场景正是它与通用 VLM 拉开差距的地方。要接 LLM 生态识别模块走 Transformers 引擎要最低延迟叠加 HPI 插件。一句话收口PP-OCRv6 的取舍是统一骨干、分档部署、单模型多语言——用一套 PPLCNetV4 把检测与识别、端侧与服务端都装进同一个宽度参数化框架里再靠重参数化和多头解码把训练期的复杂度留在推理期之外。选哪一档只看你愿意为精度付多少延迟。【免费下载链接】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），仅供参考 PP-OCRv6 实战：PPLCNetV4 统一骨干如何用三档轻量模型打穿 50 语言 OCR
PP-OCRv6 实战PPLCNetV4 统一骨干如何用三档轻量模型打穿 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从一张轮胎照片说起先讲两个真实到不能再真实的场景。第一产线质检。一条轮胎侧壁上的钢印字符背景是高对比橡胶、字符间距不一、还带弧度。你把它丢给一个百亿参数的视觉语言模型它要么直接编出一串看起来合理的型号——而那个型号根本不存在于照片里要么返回一大段自然语言描述你最后还是得再写一套规则去提取字段。第二跨境电商后台。一天几万张商品图中英德法西文混排还有越南语、土耳其语这类带变音符号的文字。传统做法是给每种语言单独维护一个识别模型维护成本随语言数线性上涨。这两个场景背后其实是同一个诉求要一个足够轻、能上端侧和 GPU 两边的模型还要在一个权重里把几十种语言一起吃掉并且在没有文字的地方老老实实说没有。PP-OCRv6 就是奔着这件事来的——它是 PP-OCR 的新一代通用文字识别方案用一个叫 PPLCNetV4 的统一骨干网络派生出 tiny、small、medium 三档模型。三档模型一张表看懂能力边界PP-OCRv6 不是一个模型而是一个共享同一套架构、只改宽度参数的模型族。选型之前先把它的边界钉死在一张表里档位参数量级目标场景语言数识别颈部tiny约 1.1M端侧 / IoT49不含日文无reshape FCsmall中间档移动端 / 桌面端50EncoderWithLightSVTRmedium34.5M服务端50EncoderWithLightSVTR这张表回答的是我的场景该用哪一档。三句话建立整体认知medium 档以34.5M 参数在内部多场景基准上拿到86.2% 检测 Hmean、83.2% 识别加权准确率small 与 medium 同架构、只缩小宽度适合移动端实时tiny 砍掉识别颈部直接上全连接专为端侧极限压缩。至于语言medium/small 单权重覆盖简中、繁中、英文、日文加 46 种拉丁语系共 50 种tiny 因为输出层放不下日文那约 4000 个汉字/假名字符而少一种。技术内核为什么是一个骨干吃两个任务设计哲学宽度参数化而不是一套套架构传统做法里检测一个网、识别一个网端侧一档、服务端又一档架构是叉出来的。PP-OCRv6 反过来同一套 PPLCNetV4 骨干靠一组宽度配置同时服务检测与识别。这套配置的入口在 rec_lcnetv4.py 里的NET_CONFIG_DET与NET_CONFIG_REC两张字典——检测模式 medium 档通道从 stem 输出的 128 一路演进到128 → 256 → 512 → 896small 档是48 → 96 → 192 → 384tiny 档是32 → 48 → 64 → 160。说白了三档不是三个模型而是同一结构在宽度轴上的三个取值。这个决策带来的直接好处是训练管线、后处理、部署链路全部复用新增语言或新档位不需要动架构代码。LCNetV4Block把空间和通道两件事拆开单个 Block 遵循 MetaFormer 范式把一次前向拆成空间混合Token Mixer和通道混合Channel Mixer两步。设输入特征为 x两步计算是x̂ SE(DW(x)) xy W2·σ(W1·x̂) x̂直觉上第一步的 3×3 深度卷积DW让每个像素去看自己的 8 个邻居第二步的两层全连接W1、W2扩展比为 2σ 是 GELU让每个位置在通道维度上做加权融合两个加号是残差连接保证梯度能顺畅回流。相比上一代 LCNetV3 的单个 1×1 点卷积换通道V4 用先扩 2 倍→激活→压回 残差的方式让通道交互更充分代价是多一点计算——而这一点计算在重参数化之后几乎被抹掉见下。重参数化草稿纸上推导交卷时合并成一步这是理解 PP-OCRv6 为什么训练复杂、推理便宜的钥匙。它的空间卷积用三分支结构 RepDWConv3×3、1×1 和一个恒等分支并存。训练时这三个分支各自学习表达能力更强部署前调用rep()把它们按权重合并成单个卷积BN 也一并折叠进去。类比一下草稿纸上用三步推导保证算得对交卷时把三步合并成一步直接写答案——推理时看不出训练时那份冗余零额外开销。压缩层的 BN 还做了零初始化让网络起步时每个 Block 近似恒等映射训练更稳。设计维度LCNetV3LCNetV4架构范式MobileNet 风格DW→SE→PWMetaFormerTokenMixer ChannelMixer通道交互单个 1×1 点卷积扩 2×→激活→压回 残差空间卷积普通 DWRepDWConv 三分支可重参数化BN 初始化标准压缩层零初始化一骨干两任务的关键任务自适应下采样同一个骨干检测要多尺度特征图识别要一维序列。PP-OCRv6 的解法是改下采样方向而不是改网络。检测模式用标准 stride-2 对称下采样产出 stride 4/8/16/32 的多尺度图交给 FPN识别模式则在后段 Stage 用非对称步长(2,1)——只把高度压掉、宽度保留再沿高度轴平均池化得到一维序列喂给 CTC/NRTR 解码。NET_CONFIG_REC里的[3, 48, 96, (2, 1), False]就是这条非对称下采样路径。这里有个坑值得点破别小看只压高度这一步它保住了文字在水平方向上的像素分辨率而这恰恰是识别精度最敏感的方向。检测侧RepLKFPN 的大核是怎么省下来的检测模块在 PP-OCRv5 的 DBNet 框架上做了三处升级核心是把特征金字塔颈部换成了 RepLKFPN。大核轻量 FPN。上一代 RSEFPN 用 3×3 普通卷积做输入层PP-OCRv6 换成DilatedReparamBlock——一个膨胀深度卷积加重参数化。它配合训练期多膨胀率如 3、5 模式把感受野从 3×3 撑到 7×7参数反而少了约 31%118K 对 172K。db_fpn.py 里的RepLKFPN把这个逻辑拆成深度大核重参数卷积 1×1 点卷积 SE 注意力三段并保留rep()方法在部署前把多分支合并成单卷积。这里的大感受野解决的是长文本行和小目标检测——字符越分散越需要看得远。辅助深度监督。在 P2、P3、P4 三个层级各挂一个预测头只在训练时参与、提供更强梯度推理时完全移除。这在 PP-OCRv6_medium_det.yml 里直接可见Loss: name: DBLoss main_loss_type: DiceFocalLoss # Dice Focal 组合利好小目标与密集文本 focal_alpha: 0.25 # Focal 类别平衡 focal_gamma: 2.5 # Focal 难易样本调节 aux_weight_p2: 0.4 # P2/P3/P4 辅助头加权 aux_weight_p3: 0.3 aux_weight_p4: 0.2DiceFocal 损失。把 DiceLoss 和 Focal Loss 揉在一起DiceFocalLoss对密集文本的逐像素监督更稳。这套检测配置的完整参数——Adam 优化器、Cosine 学习率、640×640 训练尺寸、500 epoch、EMA 衰减 0.9996——都能在该 YAML 里逐字段核对。识别侧多头解码与训练用两个头、推理只留一个识别模块的颈部是 rnn.py 里注册的EncoderWithLightSVTR配置里叫lightsvtr。它做两件事用 1×7 深度卷积建局部上下文再用 1–2 层 Transformer 建全局注意力。关键点在连接方式——它用加法跳跃连接替代了 PP-OCRv5 的拼接。把两路特征相加而不是首尾相接参数量直接降下来PP-OCRv6_medium_rec.yml 中dims: 192、depth: 2、mlp_ratio: 4.0、local_kernel: 7就是这组参数的落地。解码端是两头设计。MultiHead同时挂了CTCHead和NRTRHeadCTC 负责高效并行推理NRTR 只在训练时做辅助监督推理时被整个移除。多语言则靠字典扩展约 200 个带变音符号的字符实现——medium/small 用 1.87 万行的ppocrv6_dict.txttiny 用 6904 行的精简字典配置里max_text_length: 25限长、use_space_char: true保留空格。tiny 档则干脆没有颈部直接 reshape 加全连接并用 medium 做知识蒸馏训练use_guide: true把小模型学大模型这件事写进了配置。从跑通一张图到生产级配置第一步最小可运行示例。装好依赖后默认就是 medium 档端到端 OCRfrom 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)这三个开关的含义值得说清它们分别控制文档方向分类、文档矫正、文本行方向分类。对已经摆正的纯文字图关掉能省掉整段预处理处理倾斜扫描件或拍照文档时再打开。第二步走命令行。不写 Python 时用 CLI 同样能跑paddleocr ocr -i general_ocr_002.png \ --use_doc_orientation_classify False \ --use_doc_unwarping False \ --use_textline_orientation False第三步生产级加速。要压延迟就启用高性能推理插件HPI底层自动切到 ONNX Runtimeocr PaddleOCR( use_doc_orientation_classifyFalse, use_doc_unwarpingFalse, use_textline_orientationFalse, enable_hpiTrue, # 自动走 ONNX Runtime 后端 ) result ocr.predict(general_ocr_002.png)如果识别模块想接 Hugging Face Transformers 生态需transformers5.8.0也可以用TextRecognition(model_namePP-OCRv6_medium_rec, enginetransformers)单独拉起识别头。性能画像数字背后是什么含义在 200 张图通用 文档场景上测端到端 OCR包含读图、前后处理和推理全流程。选几个代表点看硬件后端v6_mediumv5_serverA100PaddlePaddle0.29s0.32sV100ONNX Runtime0.67s0.77sXeon 8350COpenVINO1.40s7.30sApple M4PaddlePaddle8.82s10s这张表回答换到 v6 我的吞吐会怎样。三个结论medium 在主流后端上都不慢于上一代 server 档CPU 上差距尤其大Xeon OpenVINO 快约 5.2 倍small 和 mobile 档速度持平但精度更高tiny 是全平台最快的一档Apple M4 上约 0.96s 一张。换句话说精度提升没有以速度为代价反而在 CPU 侧拉开了代差。精度对比86.2% Hmean、83.2% 识别准确率、对比 PP-OCRv5_server 提升 4.6%/5.1%均为官方内部多场景基准数据具体数值随数据集与版本演进而变化。生产落地从单机到服务化按从简单到复杂排个序。最轻的一步是 Python API / CLI前面已经覆盖其次是高性能推理插件用 ONNX Runtime 后端进一步压延迟再往上走服务化部署拿高稳定性的在线服务形态。硬件侧兼容 Windows/Linux/Mac推理支持 NVIDIA GPU、Intel CPU、昆仑芯、昇腾等。要做二次开发仓库把训练配置configs/det/PP-OCRv6/、configs/rec/PP-OCRv6/和字典文件全部开放改model_size就能复用同一套管线换档扩字典或微调只需替换character_dict_path指向的新字典。决策速查按场景对号入座省去纠结服务端、要精度和稳定直接上 medium配 TensorRTGPU或 OpenVINO/ONNX RuntimeCPU。移动端/桌面端实时选 small架构与 medium 相同只缩宽度精度损失可控。端侧/IoT、对延迟极度敏感选 tiny注意它不含日文若业务强依赖日文要回退到 small。多语言混排文档medium/small 单权重即可不必为每种语言单独维护模型。工业长尾场景数码屏、点阵、轮胎印字、旋转文本优先 medium这类场景正是它与通用 VLM 拉开差距的地方。要接 LLM 生态识别模块走 Transformers 引擎要最低延迟叠加 HPI 插件。一句话收口PP-OCRv6 的取舍是统一骨干、分档部署、单模型多语言——用一套 PPLCNetV4 把检测与识别、端侧与服务端都装进同一个宽度参数化框架里再靠重参数化和多头解码把训练期的复杂度留在推理期之外。选哪一档只看你愿意为精度付多少延迟。【免费下载链接】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），仅供参考