正在打开工具详情…
正在打开工具详情…
百度飞桨的 OCR 与文档解析工具包，能把 PDF/图片转成 Markdown 或 JSON 给 LLM 用，100+ 语种。适合中文扫描件与表格公式多的场景；代价是模型与依赖不轻，轻量的只需 PP-OCRv6 tiny 档。
要给中文 PDF、扫描件、票据、表格做结构化入库的人：RAG 的知识解析层、批量档案数字化、需要坐标信息的版面还原。
只偶尔识别几张截图的人——不如直接用现成的在线 OCR 或浏览器端 SDK；也不适合没有 Python 环境又不想碰模型权重下载的轻量需求。
PaddleOCR 现在不只是「识别文字」，而是一套文档 AI：一条线是 PP-OCRv6 做通用文字识别（单模型覆盖中英日等 50 种语言，tiny / small / medium 三档分别 1.5M、7.7M、34.5M 参数，对应端侧、移动端和服务器），另一条线是文档解析——PaddleOCR-VL-1.6（0.9B）直接输出 Markdown / JSON，PP-StructureV3 则额外给出表格单元格、文字的坐标信息。后者适合要把版面位置一起交给下游的场景，前者适合只要内容的场景。
选它而不是通用多模态大模型的理由通常是中文与复杂版面：官方给的 OmniDocBench v1.6 准确率 96.3%，在文本、公式、表格三项领先，古文、生僻字、印章、图表也做了专门增强。它已经接进 Dify、RAGFlow、Cherry Studio，做 RAG 的知识入库层很省事。
代价有两个。一是别指望一条管线打天下：想要坐标就用 PP-StructureV3，想要高吞吐解析就上 HPD-Parsing（分层并行解码 + P-MTP，公开基准峰值 4752 tokens/s，支持 OpenAI 兼容 serving 与定制 vLLM 本地推理）。二是部署环境：官方支持 NVIDIA GPU、Intel CPU、昆仑芯 XPU 等多种后端，但具体后端与版本对应关系要查文档，Windows 上新版显卡（如 RTX 50 系）有单独的说明页。
上手步骤之外的具体做法：常见场景怎么配、命令怎么写、报错怎么处理。
按第一次选型会卡在哪讲：文字识别和文档解析是两条不同的管线、模型档位怎么选、要不要坐标、以及不想装环境时的浏览器方案。
这是最容易走错的一步。PaddleOCR 里「识别文字」和「解析文档」不是同一件事：
| 你要什么 | 用哪个 |
|---|---|
| 图片 / 自然场景里的文字 | PP-OCRv6（单模型覆盖中英日等 50 种语言） |
| 文档转 Markdown / JSON，只要内容 | PaddleOCR-VL-1.6（0.9B） |
| 文档转结构化，还要表格单元格与文字坐标 | PP-StructureV3 |
| 高吞吐批量解析 | HPD-Parsing（峰值 4752 tokens/s） |
README 特别点了一句：PP-StructureV3 相比 PaddleOCR-VL 系列多了细粒度坐标信息（表格单元格坐标、文字坐标）。要做版面还原或让下游定位到原文位置，就必须选它，光靠 VL 模型拿不到。
PP-OCRv6 分三档，不是越大越好：
tiny 1.5M —— 端侧small 7.7M —— 移动端medium 34.5M —— 服务器官方给的加速数据：CPU 端到端 5.2×（OpenVINO）、Apple M4 上 6.1×（tiny）、A100 上 0.13s。嵌入式和笔记本上硬上 medium 只会白等。
3.5.0 起有官方浏览器推理 SDK：
js// PaddleOCR.js —— 官方浏览器推理 SDK，支持直接跑 PP-OCRv5适合一次性识别、内部小工具、或者不想在机器上放模型权重的场景。真正批量处理还是回到 Python。
3.2.0 之后核心依赖与可选依赖已经分离：基础文字识别只需要最小核心依赖，文档解析、信息抽取的额外依赖按需安装。一次性装 all 会拉进来一堆用不到的包，升级时也更容易冲突。
它已经深度集成进 Dify、RAGFlow、Pathway、Cherry Studio。做 RAG 时通常不需要自己写解析脚本，直接在那些平台里选 PaddleOCR 作为解析后端即可；解析结果还能导出 DOCX（PaddleOCR-VL 系列、PP-StructureV3、PP-DocTranslation 都支持），方便人工校对。
官方列了 NVIDIA GPU、Intel CPU、昆仑芯 XPU 和多种 AI 加速器。Windows 上的新显卡（例如 RTX 50 系）有单独的安装说明页，别照着通用教程装。