今年6月，PaddleOCR连着来了两次大更新：PP-OCR 系列第六代通用文字识别模型 PP-OCRv6 正式开源。知乎而就在5月底，面向复杂文档解析的 PaddleOCR-VL-1.6 也已经正式发布。微信评论区的风向也跟着变了：以前高赞是"太强了，收藏"，现在高赞是"我该用哪个"“v5能不能一键升级”“照着教程装怎么一堆报错”。
这很正常，因为这个项目早就不只是"一个模型"，而是一个覆盖文字识别、文档解析、结构化三个方向的模型家族。这篇文章不堆参数表，只解决两个问题：你该用哪一个，以及该走哪条路线跑起来。
一、PaddleOCR 不是一个模型，是一个家族
先看 PP-OCRv6。它是 PP-OCR 系列的第六代文本检测识别模型，首次推出 Tiny、Small、Medium 三档模型，参数规模分别为 1.5M、7.7M、34.5M，覆盖浏览器端、嵌入式设备到服务器的全算力平台。知乎在官方内部多场景评估集上，Medium 版本检测 Hmean 达 86.2%、识别准确率 83.2%，相比前代服务端模型检测精度提升 4.6%、识别精度提升 5.1%，CPU 推理速度是前代的 5.2 倍。值得买社区
单模型支持的语言数量从上代的 4 种扩展到 50 种，电路板、数码管、CAD 图纸、喷码点阵字符等工业场景也是这次新增的。知乎换句话说，v6 解决的是"把图里的字找出来、认出来"这件事，是纯文字识别的主力。
再看 PaddleOCR-VL-1.6。它在 5 月 28 日正式上线，在 OmniDocBench v1.6 上达到了 96.3% 的精度，同时新增了印章识别与文本检测识别能力。微信它和 v6 的定位差别很大：v6 管"文字行"，VL 管"整页文档"，表格、公式、图表、印章、阅读顺序都要结构化地解析出来。官方口径里，两者是互补关系，不是替代关系。
还有负责版面、表格、公式结构化的 PP-StructureV3，它可以从文档图片和 PDF 中抽取结构化信息，识别文本块、标题、段落、图片、表格、公式、图表等元素，并直接转换为 Markdown 或 JSON。知乎很多人说的"想把 PDF 喂给大模型"，背后干活的就是它或者 VL。
二、五个问题，快速定你用哪一个
不用背参数表，回答五个问题就够了：
只识别图片、截图里的文字？→ PP-OCRv6。日常用 Small 档就够，精度要求高上 Medium。
要保留表格、公式、标题层级，直接出 Markdown？→ PP-StructureV3 或 PaddleOCR-VL。
处理印章、古籍、生僻字这类特殊场景？→ PaddleOCR-VL。古籍、生僻字、印章等特殊场景识别，也是 1.6 版本重点增强的方向之一。微信
要搭 RAG 知识库、PDF 转数据库？→ 建议组合用：先用 v6 或 VL 把文档解析掉，再做检索问答，别指望一个模型全包。
识别电路板丝印、数码管、喷码点阵这类工业字符？→ v6。v6 新增了对电路板（PCB）丝印、数码管字符、CAD 图纸文字、喷码点阵字符等工业场景的专项支持。值得买社区
这里必须给跑分泼一盆冷水。社区有第三方 lite 横评对比过 PaddleOCR-VL、MinerU、HunyuanOCR、MonkeyOCR 四个方案，PaddleOCR-VL 不是每项第一，但总体最稳定。不过作者自己说得很清楚：本文里用到的排序分 rank_score 不是官方单一指标，而是本地为了方便排序做的聚合分。知乎官方 in-house 评估集同样只代表自家测试集的表现。跑分只能用来初筛，真好不好用，得拿你自己手里的两三份真实文档跑一遍。手写笔记、扫描件、工业件都可以先试，正常的识别输出长这样：检测框加逐行识别出的文字，看得清清楚楚再谈部署。
三、选完模型，挑一条路线跑起来
模型定了，下一步是选使用方式。官方推荐的路线分工很清楚：网页版用来看效果，API 用来快速集成，本地服务化用来长期生产，复杂文档交给 PP-StructureV3 或 PaddleOCR-VL。
路线一：网页体验。直接进 AI Studio 官方体验页，零安装零配置，先确认你的文档能不能被识别。这一步能排除掉大部分"不适合"的场景。
路线二：成品工具。日常批量使用，直接用 Umi-OCR 这类基于 PP-OCR 引擎的成品工具。Umi-OCR 虽为客户端软件，但底层集成 PaddleOCR 与 RapidOCR 双引擎。值得买社区引擎之间还能切换，老机器跑不动一个就换另一个。
路线三：pip 集成。paddleocr 包更新到 3.7.0 以后，默认 PP-OCR 模型已经切换到 v6 版本，推理还广泛兼容 onnxruntime、transformers 两种后端，可以通过 engine 参数指定。知乎这条路适合真正要把代码写进自己流程的开发者。
路线四：服务化部署。用 PaddleX Serving 把推理封装成服务，通过 HTTP 调用，适合企业批量处理和多系统调用。
四、避坑清单：最容易翻车的几个地方
这几条都是社区反复踩过的坑，遇到报错先按顺序对照：
GPU 版本安装：选择 cu118 还是 cu126 取决于你的显卡驱动版本，而不是主机安装的 CUDA Toolkit 版本。驱动版本 ≥550.54.14 可选 cu126，否则建议选 cu118。哔哩哔哩
模型路径：路径里不要带中文。新版本的模型路径参数同样不兼容中文，遇到莫名其妙的模型加载报错先查这一条。
别照抄旧教程：use_angle_cls、use_gpu 这类旧 API 参数，在 3.x 版本已经不再接受，设备和参数控制都统一了。抄教程之前先确认教程对应的版本。
昇腾等 aarch64 环境：paddleocr 3.7.0 用默认 engine=‘paddle_static’ 调用 ocr.predict() 时，PaddlePaddle 原生推理引擎会在 C++ 的 std::filesystem 析构函数中段错误。微信这时把推理引擎换成 onnxruntime 就能正常跑。
Pascal 架构老显卡：GTX 1070 Ti 这类老卡用户注意，onnxruntime-gpu 1.26.0 依赖的 cuDNN 9.x 不再支持 Pascal 架构旧显卡。值得买社区锁定旧版 onnxruntime-gpu，或者换 CPU、OpenVINO 路线。
关预处理提速：如果你的图片非常规整，可以关掉 use_doc_orientation_classify、use_doc_unwarping、use_textline_orientation，以提高推理速度。知乎
第三方一键包谨慎用：最近推广"一键部署 PaddleOCR WebUI"的文章，不少是同一个 GitHub 项目的分发稿。用之前先看仓库活跃度、issue 和开源协议，别把合同、票据这类敏感材料直接喂给来路不明的本地工具。
五、一张决策表，和三个值得继续盯的信号
最后把全部内容压成一张表：
你的需求 | 首选 | 建议路线 |
|---|---|---|
图片、截图批量识字 | PP-OCRv6 Small/Medium | 成品工具或 pip |
PDF 转 Markdown、保留表格公式 | PP-StructureV3 / VL-1.6 | pip 或服务化 |
印章、古籍、生僻字等复杂版面 | PaddleOCR-VL-1.6 | 先网页版试，再服务化 |
PCB 丝印、数码管、点阵等工业字符 | PP-OCRv6 | pip，先拿自己的样品验证 |
只想看看效果 | 网页体验版 | AI Studio 在线，零安装 |
还有三个信号值得继续盯。第一，v6 的 50 种语言支持来自官方内部评估集数据，小语种的实际精度还得等社区实测。发布头一周，GitHub 上已经出现了催更多小语种、C++ 推理崩溃、升级后方向分类精度回退这几类 issue，社区的总结挺准确：数据亮眼、值得一试，但生产环境上车前先趟一遍自己的坑。微信第二，RapidOCR、Umi-OCR 这类社区工具链对 v6 的集成进度不一，依赖特定工具的，升级前先看适配进度。第三，VL 系列迭代很快，1.5 到 1.6 只隔了几个月，没有印章、古籍这类硬需求的话，不必急着一步到位上最重的方案。
OCR 选型这件事真不复杂，复杂的是信息差。还在犹豫的话，按这个顺序来：先用网页版看效果，再用成品工具日常跑，真要集成再碰 pip。你打算拿 PaddleOCR 做什么场景？评论区说说，我帮你看看你的路线会踩哪些坑。
