PP-OCRv6 模型：tiny、small 与 medium 对比

PP-OCRv6 是什么（以及“PaddleOCR v6”不是什么）#

PP-OCR 是 PaddleOCR 文本行 OCR 系统的名字：一个文本检测模型找出每一行文字并返回多边形框，一个文本识别模型读出裁剪下来的文本行。PP-OCRv6 是这对模型的第六代，于 2026 年 6 月 11 日随 paddleocr 包 3.7.0 版本一同发布，并成为默认模型。³

版本号很容易搞混。并不存在“PaddleOCR v6”这个包——最新的包版本是 PaddleOCR 3.7.0。“v6”指的是模型的代数。同一个包仍然可以加载 PP-OCRv5、v4 和 v3 模型，对于 PP-OCRv6 未覆盖的语言，它会自动这样做（见下文）。

百度将 PP-OCRv6 描述为一个系列、三个档位，分别面向边缘/物联网（tiny）、移动端/桌面端（small）和服务器（medium）。相比 PP-OCRv5，最主要的变化是语言覆盖：small 和 medium 识别模型一个模型即可识别 50 种语言——简体中文、繁体中文、英文、日文以及 46 种拉丁字母语言——因此法语或越南语不再需要单独的模型。¹ 如果你直接调用 PaddleOCR()，得到的就是 medium 档位：⁶

from paddleocr import PaddleOCR

ocr = PaddleOCR()   # lang=None, ocr_version=None -> PP-OCRv6_medium_det + PP-OCRv6_medium_rec

三个档位：参数量、大小与语言#

每个档位由两个模型组成：PP-OCRv6_<tier>_det 和 PP-OCRv6_<tier>_rec。参数量取自 Hugging Face 模型卡片；大小取自官方模块文档，按 MiB（1,048,576 字节）计算时与 Hugging Face 上的文件一致。⁴⁵

检测 + 识别的参数量四舍五入后，与百度公布的各档位总数（1.5M / 7.7M / 34.5M）一致。³ MB 一栏的合计是我们把官方公布的单模型大小相加得出的。

tiny 档位读不了日文——我们实测了有多糟#

官方文档只用半句话提到这一点（“tiny supports 49, excluding Japanese”），OCR 产线文档补充说 PP-OCRv6_tiny 不支持 japan。¹⁷ 中文版算法文档给出了原因：为避免约 4,000 个日文汉字和假名字符对 tiny 识别模型 1.1M 参数输出层的影响，没有纳入日文。² 我们统计了每个模型自带的字典：tiny 有 6,904 个条目，完全没有平假名和片假名；small 和 medium 各有 18,708 个条目，其中 180 个是假名。¹²

实际效果如何：在我们的日文店铺通知上，tiny 的字符错误率为 47.3%，而 small 和 medium 都是 0%。8 行中只有 1 行完全正确——就是那行只有汉字和数字的。PaddleOCR 不会发出任何警告，置信度也高到足以骗过阈值过滤：¹¹¹²

每个假名都被替换成 tiny 字典里长得像的字符：の 变成 ⑦，お 变成 书，し 变成 L。medium 和 small 八行全部识别正确。如果输入可能包含日文，请用 small 或 medium；出于同样的原因，我们的在线识别工具在浏览器中默认使用 small。

PP-OCRv6 的工作原理（通俗版）#

• 两项任务共用一个骨干网络。PPLCNetV4 采用 MetaFormer 范式（一个轻量的“token mixer”后接一个“channel mixer”），并使用结构重参数化：额外的分支在训练时提供帮助，推理时被合并成单个卷积。用于检测时，它在两个方向上缩小图像；用于识别时只缩小高度，于是一行文字就变成从左到右的序列。¹
• 检测看到更大的上下文。新的 RepLKFPN neck 使用 7×7 深度卷积替代 3×3，参数量比 PP-OCRv5 的 RSEFPN 少 31%（118K 对 172K）。¹
• 识别兼顾局部与全局。EncoderWithLightSVTR neck 用一个小卷积处理相邻字符，再用一到两层自注意力处理整行。CTC head 输出文本；NRTR head 只在训练时辅助，推理时被移除。¹
• tiny 是蒸馏出来的。tiny 识别模型完全没有 neck，通过模仿 medium 模型训练而成（知识蒸馏）。¹
• 50 种语言共用一个字典。字符集扩充了约 200 个带变音符号的字符，这正是一个模型能同时识别波兰语、越南语或冰岛语以及中文的原因。¹

官方精度：PP-OCRv6 对比 PP-OCRv5#

这些数字是百度自己在其内部多场景评测集上测得的——检测 16 个类别，识别 15 个类别。该测试集不公开，因此应视为厂商自报数据。¹

有两点值得注意。small（7.7M 参数）在两项平均值上都胜过大得多的 PP-OCRv5 server。tiny 的识别平均值（73.5%）与 PP-OCRv5 mobile（73.7%）持平，下载体积约为其三分之一——但从分类别表格可以看到，它在手写体上明显落后。

各类别检测 Hmean（%）#

检测提升最大的是旋转文本（93.8 对 v5 server 的 80.0）。在表格（97.1 对 96.8）和手写英文（84.1 对 84.0）上，PP-OCRv5 server 仍略胜 medium。¹

各类别识别精度（%）#

百度特别强调了 medium 相对 v5 server 在日文（+16.8 个百分点）、古籍（+12.0）和屏幕文字（+14.4）上的提升。² 注意表中有一个反常的单元格：tiny 在日文上得分 89.8%，接近 medium，尽管它读不了假名。文档没有说明这一格背后的测试集；对真实的日文文本，请以上文的实测结果为准。

同一组表格中还列出了视觉语言模型（Gemini-3.1-Pro、GPT-5.5、Qwen3-VL-235B），它们在百度评测集上的得分都低于 PP-OCRv6 medium；这就是“34.5M 参数模型超越 VLM”这一说法的依据。¹

模型大小与精度#

从 tiny 换到 small，多 24 MB，换来 7.8 个精度点；从 small 换到 medium，再多 103 MB，只换来 1.9 个点。和上一代相比：small 比 PP-OCRv5 mobile 高 7.6 个点，只大 9 MB；medium 比 PP-OCRv5 server 高 5.1 个点，体积反而更小；tiny 与 PP-OCRv5 mobile 持平，体积不到其三分之一。

官方速度表（含硬件）#

百度对完整产线计时——图片读取、前后处理和两个模型——测试集为 200 张通用和文档图片。数值为每张图片的秒数。文档写明了硬件，但没有说明线程数和批处理设置。¹

要逐行看，不要只看宣传数字。在 GPU 上，medium 在 A100 上只比 v5 server 快一点点（0.29 对 0.32 s），在 V100 上用 PaddlePaddle 时反而更慢（0.72 对 0.66 s）。百度引用的大幅加速——medium 用 OpenVINO 快 5.2 倍、tiny 在 Apple M4 上快 6.1 倍——都来自 PP-OCRv5 server 或 mobile 异常慢的 CPU 行。¹ 在 Apple Silicon 上，这张表里的每个模型都是 ONNX Runtime 比 PaddlePaddle 快。

模块文档还公布了四种推理引擎（PaddlePaddle 静态图和动态图、Transformers、ONNX Runtime）在 NVIDIA A100 和 Xeon Gold 6248 上的单模型耗时，但没有说明哪个数字来自哪台设备，所以我们不在这里转载。⁴

我们的 CPU 实测：精度、速度、内存、磁盘#

我们在一台 4 vCPU Intel Xeon @ 2.10 GHz、15 GB 内存、无 GPU 的机器上测试了全部五个当前模型，使用 PaddleOCR 3.7.0 和两种推理引擎：PaddlePaddle 3.2.0 与 ONNX Runtime。测试集为五份文档，共 124 个已知文本项——一张干净的小票、同一张小票斜着拍的照片、一张英文发票、一份中英文通知和一份日文通知。每个数字都是三次热启动运行的中位数；关闭了文档方向分类、弯曲矫正和文本行方向分类。完整方法和原始数据见我们的基准测试页面（英文）。¹¹

各列含义：CER 是字符错误率，在对两边的全角标点、破折号和空格做归一化后计算，再对各文档取平均。峰值内存是整个 Python 进程在跑完全部五份文档期间的常驻内存峰值。磁盘占用是 PaddlePaddle 引擎下载的检测 + 识别模型文件夹大小，按十进制 MB（10⁶ 字节）计算；ONNX 模型文件夹与之相差不到 1 MB。¹¹

我们的结论：

• medium 是我们测试过最准的模型——124 项中唯一的错误是把发票上的“600x600”识别成带乘号的“600×600”，这个错所有模型都犯了。它在精度（123 对 117）和速度（PaddlePaddle 下 4.51 对 5.25 s）上也都胜过 PP-OCRv5 server。
• 在 CPU 上 small 是最佳平衡点。用 ONNX Runtime 时比 medium 快约 3.3 倍，峰值内存少 36–42%，下载体积不到四分之一，只多错两项：两张小票上的“Order”都被识别成“0rder”。
• tiny 确实又小又快——每页 0.26 s——除日文外，它的错误率（0.46%）接近 PP-OCRv5 server（0.43%）。
• PP-OCRv5 server + ONNX Runtime 的异常。PP-OCRv5 server 在 ONNX Runtime 下每页耗时 35.7 s，而 PaddlePaddle 下为 5.2 s；两者输出的文字完全相同。百度自己的 Xeon 数据也是同一趋势，只是远没有这么极端（ONNX Runtime 6.36 s 对 PaddlePaddle 2.04 s）。后来我们用 lang="korean" 复查——它使用同一个 v5 server 检测模型加一个小的韩文识别模型——也出现了同样的规律（每张图 12.35 s 对 1.80 s），所以慢的看来是检测模型。如果你要在 CPU 上使用 v5 server 或某个 PP-OCRv5 语言，请用 PaddlePaddle 引擎。¹¹⁴
• 我们测得的 medium CPU 结果与百度的 Xeon 8350C 那一行不同：在那里，ONNX Runtime（3.31 s）比 PaddlePaddle（2.05 s）更慢。不同的 CPU、线程数和引擎版本会让这些数字差别很大——正式选型前请在自己的硬件上测一测。

我该用哪个档位？#

来源：平台相关的几行依据 PaddleOCR.js 源码以及 iOS、Android 部署文档；精度依据上文百度的表格；速度依据我们的实测。¹¹¹¹³ 可以用在线识别工具在你自己的图片上并排试一试 small 和 tiny。

如何在 Python 和命令行中选择档位#

这里最容易踩坑：lang 和 ocr_version 永远只能选到 medium 档位。对于任何 PP-OCRv6 语言，PaddleOCR 3.7 返回的都是 PP-OCRv6_medium_det + PP-OCRv6_medium_rec。要用 small 或 tiny，必须显式指定模型名：⁶

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    text_detection_model_name="PP-OCRv6_small_det",     # 或 PP-OCRv6_tiny_det
    text_recognition_model_name="PP-OCRv6_small_rec",   # 或 PP-OCRv6_tiny_rec
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
    engine="onnxruntime",   # 可选：我们测试中最快的 CPU 推理引擎
)
for res in ocr.predict("receipt.jpg"):
    print(res["rec_texts"])

paddleocr ocr -i receipt.jpg \
    --text_detection_model_name PP-OCRv6_small_det \
    --text_recognition_model_name PP-OCRv6_small_rec \
    --use_doc_orientation_classify False \
    --use_doc_unwarping False \
    --use_textline_orientation False \
    --engine onnxruntime

只要传入了模型名或模型目录，PaddleOCR 就会忽略 lang 和 ocr_version，并记录这条警告：⁶

`lang` and `ocr_version` will be ignored when model names or model directories are not `None`.

所以 PaddleOCR(lang="japan", text_recognition_model_name="PP-OCRv6_tiny_rec") 会毫无提示地用 tiny 去识别你的日文。其他选择方式：

• 旧版本模型：PaddleOCR(ocr_version="PP-OCRv5") 加载 PP-OCRv5_server_det + PP-OCRv5_server_rec。ocr_version="PP-OCRv4" 只适用于 lang="ch" 和 "en"，加载 v4 mobile 模型。其他版本字符串会抛出 ValueError。⁶
• 其他文字：PaddleOCR(lang="korean") 加载 PP-OCRv5_server_det + korean_PP-OCRv5_mobile_rec。我们的语言代码查询工具列出了每个代码对应的模型。
• 浏览器：PaddleOCR.js 把 ocrVersion: "PP-OCRv6" 映射到 small 档位；要用 tiny 同样需要显式指定模型名。见 PaddleOCR.js 指南（英文）。
• 在 PP-StructureV3 中：它默认仍用 PP-OCRv5 server 识别文字；在我们的发票上，换成 PP-OCRv6 模型后修正了三行识别错误。方法。

代码生成器（英文）可以替你生成这些代码片段，包括 HTTP 和 JavaScript 版本。

PP-OCRv6 之外的文字：PP-OCRv5 多语种模型#

PP-OCRv6 覆盖中文、日文和拉丁字母语言。PaddleOCR 3.7 中的其他语言都由 2025 年 6 月至 10 月间发布的小型 PP-OCRv5 识别模型负责，搭配 PP-OCRv5_server_det 检测模型。精度数据来自百度，各自使用自己的测试集，所以只能和“相比上一代”一栏对照着看。⁸

另外两个 PP-OCRv5 多语种模型 latin_ 和 en_PP-OCRv5_mobile_rec 现在基本已被 PP-OCRv6 取代；3.7 仍会为巴利语（pi）加载 Latin 模型，因为 PP-OCRv6 明确排除了它。⁶ 有一个代码 ka 只有 PP-OCRv3 模型。全部 112 个代码的路由见支持语言页面。

PP-OCRv5 与 PP-OCRv6 一览#

要不要升级？对于中文、英文、日文和拉丁字母文本，要。无论百度的数据还是我们的数据，medium 和 small 都比 v5 server 和 v5 mobile 更准。在我们的 CPU 上，medium 也比 v5 server 更快；small 比 v5 mobile 略慢（ONNX Runtime 下 0.90 对 0.73 s），但少错了四项。只有在需要 v6 未覆盖的文字，或必须精确复现旧输出时，才继续用 v5。¹¹¹

PP-OCR 版本历史#

1. 2020-05-14第一个轻量模型——“Open source 8.6M lightweight Chinese OCR model”。⁹
2. 2020-09PP-OCR——第一个正式命名的系统；论文 arXiv:2009.09941（2020 年 9 月 21 日）。⁹
3. 2021-09-07PP-OCRv2——随 PaddleOCR 2.3 发布；arXiv:2109.03144。⁹
4. 2022-05-09PP-OCRv3——随 PaddleOCR 2.5 发布；论文 arXiv:2206.03001 于 6 月发表。在 3.7 中，lang="ka" 仍然只能用它的识别模型。⁹
5. 2023-08-07PP-OCRv4——release/2.7，mobile 和 server 两个版本。官方列表中唯一没有论文的一代。⁹
6. 2025-05-20PP-OCRv5——随 PaddleOCR 3.0 发布。在 3.0.1（2025 年 6 月 5 日）中，默认模型从 mobile 改为 server。⁹
7. 2025-06 → 10PP-OCRv5 多语种——3.1.0 新增 37 种语言的识别模型，包括法语、西班牙语、俄语和韩语；3.2.0 新增英文、泰文和希腊文；3.3.0 新增西里尔文、阿拉伯文、天城文、泰卢固文和泰米尔文。³⁹
8. 2026-06-11PP-OCRv6——tiny、small、medium 三个档位，一个模型支持 50 种语言；PaddleOCR 3.7.0 的默认模型。论文 arXiv:2606.13108。³⁹

如果想看包的版本发布而非模型代数，请见 PaddleOCR 版本发布（英文）；要把旧的 2.x 代码迁移到 3.x API，请用迁移指南。

官方资料之间的矛盾#

我们在核对本页每个数字时发现了以下矛盾。需要取舍时，我们以源码或实际文件为准。

• “2.37× GPU 推理加速”。PP-OCRv6 文档开头一段称 medium 相比 PP-OCRv5 server 有此加速，但同一文档里的速度表显示 A100 上是 0.29 对 0.32 s（文档自己称之为“1.1× faster”），在 V100 上用 PaddlePaddle 和 TensorRT 时 medium 反而更慢。我们没有找到任何能支撑 2.37× 的表格。README 引用的是别的数字：CPU 上用 OpenVINO 快 5.2 倍，tiny 在 Apple M4 上快 6.1 倍。¹³
• 48 种还是 50 种语言？英文文档和识别模型卡片写的是 50。Hugging Face 上三个检测模型卡片写的是“Supports 48 languages”，中文文档一处写 48、另一处写 50。代码接受 52 个 PP-OCRv6 代码，其中两个是别名（french、german）——即 50 种语言。²⁵⁶
• 模型大小。PP-OCRv5_server_det 在模块文档中是 84.3 MB，在 model_list.md 中是 101 MB；它的文件加起来是 84.24 MiB。ch_RepSVTR_rec 在一份文档中是 22.1 MB，在另外两份中是 48.8 MB。韩文、Latin 和东斯拉夫 v5 识别模型都标为 14 MB，但它们的文件分别是 13.0、7.8 和 7.7 MiB。官方公布的“MB”实际上是 MiB；我们上文的磁盘占用是整个模型文件夹的十进制 MB，所以会高出几个百分点。⁴⁵¹⁰
• 同一个模型，不同的分数。PP-OCRv5_server_rec 是 86.38%、0.8401 还是 78.1%，取决于你看哪份文档——三个不同的评测集（见上文提示框）。⁴⁸
• PP-OCRv5 多语种是 106 种还是 109 种语言？v5 多语种文档写 106；2025 年 10 月发布之后的 README 写 109。³⁸
• 缺失的 PP-OCRv6 行。model_list.md 中 PP-OCRv6 的精度、延迟和大小都是“-”，标准 T4 延迟表中 PP-OCRv6 也列为“- / -”。⁴¹⁰

如果你发现了其他矛盾，或其中某项在上游已经修正，请发邮件至 hello@paddleocr.dev。

常见问题#