百度扔出一个 3B OCR：月下载 117 万，把 DeepSeek-OCR 再推一步

2026年10月14日

过去半年，我心里 OCR 一直是个不太起眼的活儿——把图片里的字抠出来，谁都能做。直到这次看到百度在 Hugging Face 发的 Unlimited-OCR，我才意识到自己低估了这一块：官方口径叫「Welcome the Era of One-shot Long-horizon Parsing」，翻译一下就是「一次推理，把一整个长文档解析干净」。这已经不是「抠字」了，是「读文件」。

模型本身体量不大，3B 参数，BF16，单看不大起眼。但 Hugging Face 页面显示它上个月有 1,175,446 次下载——117 万，一个刚发布的 OCR 模型能到这个量级，说明这东西戳中了疼点。而且它的定位很直白，就是「push Deepseek-OCR one step further」，在 DeepSeek 打下的底子上再往前拱一段。致敬列表里还挂着 DeepSeek-OCR、DeepSeek-OCR-2 和 PaddleOCR，血统清晰。

让我觉得值得写第二遍的，是它的使用方式。官方给单张图配了两套配置，一个叫 gundam，一个叫 base：gundam 走 base_size=1024, image_size=640, crop_mode=True，适合单页精细解析；base 走 image_size=1024，不带裁剪。而多页和 PDF 只走 base。这意思是，单页要精度就开裁剪，长文档则整页喂进去，一次全塞是不行的。PDF 得先自己转成图——官方给的脚本是 PyMuPDF 按 300 DPI 把每页渲染成 PNG，再交给 infer_multi。这种「先转图再解析」的流程，本身就是长文档解析里最常见的坑：格式、表头、脚注会被 DPI 和分页方式直接影响。

我更关心的是它的生态位。它不只是一堆权重丢出来，推理栈直接接了三套：Transformers、vLLM、SGLang，训练侧还接上了 ms-swift，云上摆进了百度智能云和 ModelScope。Release 记录从 6 月 22 号放出，到 6 月 24 号就有 AK 做了 Hugging Face Spaces 的在线 demo，6 月 28 号 vLLM 支持跟进。这种发布节奏，说明不是放个模型出来就完事，人家是把「部署」当成发布的一部分在做。vLLM 甚至给了不同 GPU 平台的 Docker 镜像，CUDA 13 一套、Hopper 的 CUDA 12.9 一套。对要上生产的团队来说，这是实打实省事的地方。

页面上的数字也值得拆着看。Model tree 里显示已经有 2 个适配器、16 个微调分支、37 个量化版本，还有 79 个 Space 在用。这些数字放在一起，可以粗略判断社区的活跃程度不是虚标。

不过得泼一盆冷水。ParseBench 的评估结果就很有意思：unlimitedocr 这条 pipeline 整体 46.17，Text Content（内容提取）86.81，但 Text Formatting（版式还原）只有 0.97。也就是说，它把文字「读出来」的能力很强，但把版面结构原样重建的能力还很弱。0.97 这个数几乎可以理解为：它擅长把文字内容提取出来，表格排版和栏位原样搬回来基本别指望。所以如果需求是「转成 Markdown 直接能用的结构化文档」，期望别全押在它身上。

对团队来说真正的取舍在部署成本。3B 的规模意味着单卡能跑，SGLang 那套启动参数里 --mem-fraction-static 0.8、--context-length 32768，看起来是给长上下文推理做了不少针对性调优。想「一次解析整个 PDF」的，这套东西比拿通用 VLM 去硬啃要划算得多——通用多模态模型在长文档上既慢又容易截断，而它是专门往这个方向调的。

我个人的保留意见集中在一点：这个模型目前最讨喜的地方在「省事」，离「惊艳」还远。它站在 DeepSeek-OCR 的肩膀上，把 OCR 从「识别」推到了「解析」，但 Text Formatting 那个 0.97 提醒我们，版式还原这道坎还没跨过去。哪天它能把表格栏位和复杂版式也稳稳重建，那才是真正的「长程解析」时代。现在这版，先拿来做文档内容提取，是顺手且经济的。