ToolBox
做后端那几年，凡是要「从图片里抠文字」的需求，我基本第一个想到的就是 PaddleOCR。理由很俗：中文场景它稳，装上就能跑，还不要钱。最近因为要处理一批扫描版合同，我又回去翻了翻它的近况，结果有点被吓到——这东西已经不是我印象里那个「检测+识别」的小工具了，它现在更像一套文档智能全家桶。
它现在到底长什么样
最新主线已经到 3.7.0（2026.06.11 那波），而且更新节奏快得离谱：光 2026 年 6 月到 7 月，就连续上了 PP-OCRv6、HPD-Parsing，7 月 22 日又推了 HPD-Parsing 的高吞吐解析。我把它现在的能力分成三块看，比较好理解：
第一块，场景 OCR（也就是最经典的「图里找字」）。 这一支现在是 PP-OCRv6：单个统一模型支持 50 种语言，相比 v5 检测涨了 4.6%、识别涨了 5.1%，CPU 推理还快了 5.2 倍。更妙的是它给了三档体量——tiny 才 1.5M、small 7.7M、medium 34.5M——分别往边缘设备、手机、服务器上贴，基本覆盖你能想到的所有部署场景。我之前在树莓派上跑旧版 PP-OCR 还觉得卡，现在 tiny 档应该能很轻松。
第二块，文档解析（这个才是真惊喜）。 由 PP-StructureV3 撑着：把复杂的 PDF 和图片直接转成 Markdown 或 JSON，文本、公式、表格都给你拆出来，还带细粒度坐标——具体到每个表格单元格、每段文字的位置。它的同门兄弟 PaddleOCR-VL 系列走的是 VLM 路线，最新的 PaddleOCR-VL-1.6（0.9B） 在 OmniDocBench v1.6 上拿到 96.3% 准确率，支持 100+ 语言。换句话说，以前要自己拼「检测→识别→版面→表格」四五个模型才能干的事，现在一条管线给你端了。
第三块，编排和部署。 这一块往往被忽略，但实际用起来最关键：它能在 Paddle 静态图、动态图、甚至 HuggingFace Transformers 之间无缝切换；后端覆盖 Paddle Inference、ONNX Runtime、TensorRT、CUDA 12，硬件从 NVIDIA GPU 到 Intel CPU、昆仑芯 XPU 都认；还有基于 vLLM 的定制 runtime（HPD-Parsing 在公开榜上峰值吞吐能到 4752 tokens/s）。部署形态也齐全：本地 C++、高稳定服务化（HTTP 接口）、浏览器端（PaddleOCR.js）、移动端。
我实际最在意的两点
中文和「复杂版面」是真强项。 我那批扫描合同里有大量表格跨页、手写批注、盖章遮挡。旧版 PaddleOCR 遇到盖章经常把红章当文字识别进去，新版的 PP-StructureV3 带版面分析后，表格结构和印章区域明显分得开，转出 Markdown 之后我只要补几处格式就行，不用从头校对。这点对「处理真实脏数据」的人价值很大。
它把「能下载」这件事做得很顺。 模型在 HuggingFace、ModelScope、AI Studio 三个源都能拉，文档站 paddleocr.ai 也齐。对一个怕麻烦的人来说，不用满世界找权重就是福报。
两点我也得跟你摊开说
不是无脑吹。踩之前先交底：
它不是轻量级玩具，依赖不轻。 PaddlePaddle 那一套环境（尤其要上 GPU、要 TensorRT）装起来还是有点劝退，新手第一次配 inference 环境大概率要跟版本对撞搏斗一阵。如果只是想「识别一张截图里的两行字」，上 PP-OCRv6 的 tiny 档、走 ONNX 是最简路径，别一上来就全套拉满。
VLM 路线和结构化路线是两套心智。 PaddleOCR-VL 给你的是「端到端一股脑转出来」的爽感，但细粒度坐标、表格单元格级信息还是 PP-StructureV3 更稳。你要做「精准回贴到原版式」就得选后者；要「快速出个可读版」就选前者。别指望一个模型把两种活都干到极致。
值不值得现在上车
如果你手头有中文文档、扫描件、票据、表格这类活，尤其是要批量处理、还要自己部署——PaddleOCR 现在基本是开源里最省心的默认选项之一。Apache 2.0 协议，商用不慌；100+ 语言覆盖，出海项目也能用；模型档位从 1.5M 到 VLM 都有，边缘到云端通吃。
我那批合同最后就是 PP-StructureV3 转 Markdown、再用脚本过一遍校对搞定的，比雇人抄省了不止一个量级。八年过去了，它从「一个 OCR 库」长成了「文档智能基础设施」——这话我现在说出来，不觉得夸张。