最近文档解析圈特别热闹，PaddleOCR-VL-1.6刚刷完榜，GLM-OCR、DeepSeek-OCR 2也下场了。但比模型大战更值得聊的，是知乎一个老问题最近又被顶了上来：「有一说一，真有人用paddlepaddle（飞桨）吗？」这个问题浏览量已经362万，高赞回答特别典型——先夸：“paddleOCR-vl-1.6 0.9B在OCR界确实牛，4090机器可以直接安装，复杂页面需要将近30秒，但质量杠杠的”；最后一句却是：“部署paddle是一个痛苦的过程”。知乎
评论区没人吵效果，全在聊部署。有人说网页版"不用登录不用安装还免费"，也有人吐槽"网页版公式错误率高，上传下载很麻烦"；有人说换MinerU更省心，立刻有人补刀：“mineru的pipeline模式使用的模型，大部分是paddle的，你可以看下源码”。知乎
这就是现在想用飞桨能力的人最真实的纠结：效果心动，安装心虚。这篇把目前能找到的接入路径全部拉出来对了一遍，帮你判断该走哪条路。
先说清楚：苦的是框架，不是模型
"部署痛苦"这个名声有历史原因：paddlepaddle-gpu要和CUDA、cuDNN版本严格对齐，Windows下动辄DLL报错，Python版本稍新稍旧就装不上，Mac M1上跑老版PaddleOCR有实测一张图要5秒。知乎这些都是真实踩坑记录，不是黑。
但2026年情况变了。PaddleOCR官方这两年的更新主线，其实就是一直在开"不装框架也能用"的侧门：4月PaddleOCR 3.5上了浏览器端PaddleOCR.js和网页版。知乎7月的3.7把推理层做成多引擎，社区还有RapidOCR这种直接把模型转成ONNX的方案。换句话说：你想要的是PaddleOCR的效果，不一定非要背下PaddlePaddle框架这块大石头。
七条路，各有各的命
按"省事程度"从高到低排：
第一条，网页版在线体验。入口在百度AI Studio，零安装，传张图或PDF就能看识别效果。知乎社区有人拿它识别了几十页资料，直呼准确度非常高，比很多大模型都好。知乎适合第一次验证效果。坑也说清楚：要上传下载、拿到的是md文件，有用户反馈公式场景错误率偏高，敏感文件别传。一句话：试效果可以，做生产不行。
第二条，云API。发请求拿结果，接入成本最低，适合先跑通业务闭环。知乎代价是按量付费、数据出域。如果你的场景是"先证明这事能成"，API是最快路径，别一上来就本地部署。
第三条，pip本地安装。paddleocr 3.x会带上完整的paddle 3.x框架体系（当前常见组合是paddleocr 3.7.0 + paddlex 3.7.2，社区实测Python 3.12环境较顺）。知乎适合要二次开发、要本地隐私、要批量跑的人。坑集中在版本对齐：CUDA版本、Python版本、paddleocr和paddlex的配套版本，装之前对一遍官方安装表能省很多事。
第四条，Docker。高赞回答给的经验很具体：4090机器直接装，5090这种新卡环境用docker。知乎新硬件、驱动新、不想污染本机环境的，直接镜像起步，能绕开大部分依赖地狱。
第五条，浏览器端PaddleOCR.js。npm包@paddleocr/paddleocr-js，能在浏览器里跑PP-OCR流水线，适合前端小工具、浏览器插件这类轻量场景。知乎注意它跑的是传统PP-OCR管线，不是PaddleOCR-VL，复杂文档解析不要指望它。
第六条，RapidOCR（ONNX路线）。这是"完全不装paddle"的社区方案：把PaddleOCR的模型转成ONNX，用ONNX Runtime跑，Python、Java、C#、C++都能接。对无GPU机器和Mac特别友好——那位Mac M1一张图5秒的朋友，换RapidOCR后"速度直接起飞"。知乎但注意两点：它目前主要覆盖PP-OCR级别的能力，PaddleOCR-VL这类VLM模型不在这条路上；而且社区已经实测发现，RapidOCR的默认参数、默认模型和官方paddleocr并不完全一致（PP-OCRv5之后尤其明显），换引擎一定要拿自己的样本重新测，别默认效果等价。知乎
第七条，第三方引擎，典型是MinerU。这条最有意思：很多人觉得MinerU是paddle的竞品，但翻源码会发现它pipeline模式用的模型大部分来自paddle——它在模型之上做了业务层的端到端纠偏、规则过滤和结果增强。知乎所以"部署更方便"的本质，是别人替你把paddle的工程活干了。如果你的目标是干净的Markdown、不想碰任何底层，这类引擎值得优先试；但相应的，出了问题排障链路也更长。
两个"速度"别搞混
很多对比贴吵起来，是因为没区分两个概念。一个是部署速度——从零到跑起来要多久；另一个是推理速度——处理一页文档要多久。这两个排序几乎完全相反：
论"最快看到结果"：网页版 > API > 浏览器端 > 本地Python > 本地服务化。知乎
论"长期批量吞吐"：GPU服务化/高性能推理 > 本地GPU > 云API > 本地CPU > 浏览器端。
所以正确的姿势是分阶段：先用网页版或API把业务闭环跑起来，等成本、速度、隐私真成了瓶颈，再往本地迁。一上来就和CUDA搏斗三小时，是最常见的劝退姿势。
另外提醒一句：官方文档里给的模型耗时，一般只含模型推理，不含前后处理、文件上传和网络传输。知乎真实速度必须拿你自己的文档实测，这句话值得截图。
对号入座
只想看效果、零技术基础：网页版，十分钟出结论。
没有GPU，或者是Mac：RapidOCR（ONNX），CPU也能跑，记得自测效果。
笔记本4060、8G显存：可以本地跑，评论区有人实测"我的笔记本4060， 8G显存都可以跑PaddleOCRVL…有一说一，效果真心不错"。知乎老卡（泰坦1080级别）跑量化版也有人成功。
4090/5090工作站：直接装或用docker，上PaddleOCR-VL-1.6完整版。
Java/C#后端、企业集成：RapidOCR或自建API，别为了OCR把整个技术栈换成Python。
数据不能出域：本地部署或内网服务化（PaddleX Serving，稳定要求高的上Triton那套）。知乎
国产系统（麒麟等）：社区有paddleocr 3.7.0的完整安装实战，先抄作业再动手。知乎
最后说两句
“模型很强、框架很重"这对矛盾，飞桨自己显然也知道——这一年的更新基本都在把入口从"装框架"换成"用模型、调服务”。对用户的实际建议就一句：现在是用到最强效果、同时入门成本最低的窗口期，但请按需选入口，别默认自己必须从pip install paddlepaddle开始。
接下来值得盯三个信号：PaddleOCR-VL-1.6是否跟进云端API（有的话本地部署的压力会再降一档）、加速解码的HPD-Parsing什么时候进开源主线（决定批量处理的性价比）、以及RapidOCR对新版模型的适配速度（决定ONNX路线能不能继续当"免装平替"）。这三个有任何一个落地，这篇的选择结论就该更新——到时候再聊。
