免责声明：本站与 Baidu 官方无关。
YuliusWiki
🌐 English Version发布日期:•最后更新:•yulius
百度 Unlimited-OCR-2 是什么？单次读完数百页的开源文档解析模型
快速答案
百度开源3B文档解析模型，单次读数百页，基准84.6/77.1分（自报，preliminary）。
百度 2026 年 10 月 27 日开源了 Unlimited-OCR-2，这是文心文档解析模型的第二代：3B 量级、MIT 许可，代码与权重同步上线 GitHub 与 Hugging Face（baidu/Unlimited-OCR-2）。它解决的是一个很具体的问题：合同、财报、整本书这种几十到几百页的文档，怎么一次读完而不把跨页的表格、脚注、前后引用拆散。第一代（2026 年 6 月）只能处理连续数十页，第二代换上 SR-SWA 稀疏注意力后，百度演示里 7 部《哈利·波特》、3600 多页一次解析完成。先说清楚两点：第一，本文所有基准分数都是百度自报（preliminary），目前没有第三方复现；第二，“任意页数”指的是机制上不再被页数卡住，不是总成本不变——图像编码与总时长仍然随页数增长。\n\n免责声明：本站与百度无关；本文为产品技术报道与分析，不构成采购、部署或投资建议。分数为百度自报口径，标注 preliminary；硬件与价格信息以官方页面为准，可能变化。
一、是什么：第二代长文档解析模型，2 天前刚开源
先把时间线写对，免得把新旧两代混在一起。第一代 Unlimited-OCR 发布于 2026 年 6 月 22 日，以 DeepSeek-OCR 的路线为基线，用参考滑动窗口注意力（R-SWA）把解析范围从单页拓展到连续数十页。第二代 Unlimited-OCR-2 于 2026 年 10 月 27 日发布，Hugging Face 模型页创建于 10 月 26 日，代码与权重同步开源，另有百度智能云与百度 AI 开放平台的托管入口。本文写于 10 月 29 日，词龄只有 2 天，不存在过时问题。\n\n模型卡上的硬参数：3B 量级（按权重计数约 3.3B），image-text-to-text 任务类型，MIT 许可，BF16 权重约 6.2GB，上下文窗口 131,072 个 token（输入与输出共享），每页约 273 个图像 token。推理入口有三条：Transformers 适合快速试验，SGLang 是官方推荐的上服务路线，社区另有 vLLM 支持；官方测试硬件是单张 NVIDIA A800 80GB。两点要诚实说明：平台上目前还没有量化版本，本地跑要先准备好约 6.2GB 权重的显存再加激活与缓存；CPU 也能跑，但长文档会明显变慢，别拿 CPU 去跑几百页。
二、SR-SWA 机制：每步只看固定 512 个参考 token
长文档解析难在哪里？普通注意力机制里，每个新 token 都要回看之前全部内容，KV 缓存和单步计算都随页数往上涨；页数一多，成本先扛不住。传统解法是逐页跑再拼接，但跨页的表格、段落、脚注和前后引用最容易在拼接处断掉。\n\nSR-SWA（Sparse Reference Sliding Window Attention，稀疏参考滑动窗口注意力）的做法是把回看范围封顶：每一步解码只看一个固定大小的工作参考集——128 个 token 的本地窗口，加上从 32 个 token 的块里按相关性挑出的 16 个块，一共 512 个远程参考 token。页门控先把每条查询的视觉参考从整篇文档收窄到相关页面，再取分数最高的 token 块补长程依赖。参考集大小固定了，每步解码的延迟与内存占用就不再跟着页数涨；再配合无限解码机制（Unlimited-Horizon Decoding），模型可以在有限的上下文窗口里处理任意长度的文档。这就是百度 slogan 里“有限窗口内真正无界解析”的实际含义：无界的是机制，不是窗口本身。
三、本站算账：3600 页是窗口的 7.5 倍，所以“无限”靠的不是窗口大
这组数字是本站按模型卡公开参数直接算的（已复算），不是转述。按每页 273 个图像 token 算：100 页是 27,300 个 token，300 页是 81,900 个，3600 页是 982,800 个。窗口一共 131,072 个 token，300 页的图像部分占掉 81,900，剩约 49,172 给输出——300 页这个量级，窗口本身还装得下。但 3600 页的 982,800 个 token 是窗口的约 7.5 倍，窗口无论如何装不下；演示能一遍过，靠的正是上一节的固定参考集机制，而不是把窗口做大。\n\n这组账顺带拆穿一个常见误读：每步成本近乎恒定，不等于总成本恒定。图像编码要一页一页做，总时长仍然随页数增长；内存里“每步新增的注意力开销”被压住了，不等于整机内存需求不涨。选型时按这个口径算账才不会踩坑：页数翻倍，总时长大致翻倍，但不会出现“越到后面每步越慢”的拖尾；如果你的文档是 30 页以内，普通方案完全够用，没必要为“无限”买单。
四、基准成绩：全部百度自报，标 preliminary，暂无第三方复现
两项基准，先说口径再说分数。MPDocBench 是多页文档解析基准（数十页规模），Unlimited-OCR-2 综合得分 84.6，百度自报口径下领先第二名 Qwen3.8-Max 的 78.3 约 6.3 分，Gemini-3.8-Flash 为 76.2。MarathonDocBench 是百度随这次发布新推的百页级基准（103–300 页），Unlimited-OCR-2 得 77.1，下一名 Kimi-K3 为 33.7，领先约 43 分；上一代 Unlimited-OCR 在这项上是 0 分——这个 0 分本身就是个信号：百页级长文档对上一代机制是基本不可用的量级。另有一家中文报道给出的 MarathonDocBench 未取整数字是 77.06，与 77.1 是同一分数的不同取整，本文统一用 77.1。\n\n速度口径同样来自百度自报：100 页设置下，SR-SWA 的单步解码比全注意力快 7 倍，比上一代 R-SWA 快 5.6 倍。必须标注清楚：以上全部是百度自己的测量，没有第三方复现；MarathonDocBench 还是百度自己新发的基准，存在“自家出题自家考”的口径问题。在独立评测出现之前，这些分数只能当作“方向正确、量级可观”的参考，不能当成实测结论写进采购论证。
五、选型建议：30–300 页是甜点，30 页以下没必要，千页级要算总时长
结论分三档。第一档，30 页以下的合同、报表、论文：普通 OCR 或通用视觉模型完全够用，跨页断裂问题不突出，不必为了“无限”换模型。第二档，30–300 页的研报、财报、招股书、手册：这是 Unlimited-OCR-2 的甜点——一次输入保留跨页上下文，单步成本不随页数拖尾，BF16 约 6.2GB 的权重在单卡上就能跑，MIT 许可商用友好，适合直接接入 RAG 与 Agent 的文档摄入环节。第三档，千页级的整本书、档案库：机制上能跑，演示里 3600 页就是证明，但要按总时长做预算（图像编码逐页发生），并且先在自己的文档类型上抽测跨页表格与脚注的实际表现——自报基准的文档分布不一定等于你的档案分布。\n\n落地路线建议：先用 Transformers 在几十页样本上验证格式与跨页表现，确认可用再切 SGLang 上服务；长文档批量处理前，先跑一遍 300 页量级的端到端耗时，别只看单步速度倍数。评测分（preliminary，基于公开资料，非本站实测）：机制可信度高（多家来源对 SR-SWA 的 512 参考集、128 本地窗口、16×32 远程块描述一致）；基准领先可信度中等（自报口径、无第三方复现，且 MarathonDocBench 为自家新基准）；本地可跑性可信度高（权重规模、推理入口、测试硬件多源一致）。
六、来源清单与免责声明
来源清单（核实日期 2026-10-29）：\n1）https://github.com/baidu/Unlimited-OCR —— 官方仓库：[2026/10/27] 发布 Unlimited OCR 2；\n2）https://huggingface.co/baidu/Unlimited-OCR-2 —— 官方模型页：MIT 许可、3B 量级、Transformers 与 SGLang 推理入口；\n3）https://letsdatascience.com/news/baidu-open-sources-unlimited-ocr-2-for-single-pass-long-docu-e22e3bc9 —— 发布日期、SR-SWA 机制、MPDocBench 84.6、MarathonDocBench 77.1、100 页单步 7 倍与 5.6 倍加速、哈利·波特 3600 页演示；\n4）https://aiweekly.co/alerts/baidu-open-sources-unlimited-ocr-2-for-100-page-documents —— 512 参考集、128 本地窗口、16×32 远程块、Kimi-K3 33.7、Qwen3.8-Max 长集 22.9；\n5）https://alphasignal.ai/news/baidu-open-sources-unlimited-ocr-2-to-parse-hundred-page-documents-at-once —— 6.7GB BF16 权重口径、131,072 窗口、A800 测试硬件、273 token/页；\n6）https://cpu3d.com/zh/ainews/novaya-model-unlimited-ocr-2-image-text-to-text/ —— HF 页 2026-10-26 创建、33 亿参数、仓库 6.2GB、暂无量化版；\n7）https://alfw.ai/article/baidu-unlimited-ocr-2-marathon-benchmark/ —— 对“无限”口径的提醒：每步成本平不等于总成本平，图像编码与总时长仍随页数增长。\n\n免责声明：本站与百度无关；本文为产品技术报道与分析，不构成采购、部署或投资建议。基准分数为百度自报口径，标注 preliminary，尚未经第三方复现；硬件与托管信息以官方页面为准，可能变化。
横向对比：Unlimited-OCR-2 vs 逐页拼接 vs 通用视觉大模型 vs 上一代
| 方案 | 单次处理页数 | 跨页上下文 | 每步成本随页数 | 许可与获取 |
|---|---|---|---|---|
| Unlimited-OCR-2（百度） | 数百页，演示 3600 多页 | 一次输入，跨页保留 | 近乎恒定（固定 512 参考 token） | MIT，GitHub 与 Hugging Face 开源 |
| 上一代 Unlimited-OCR | 连续数十页 | R-SWA 参考窗口内保留 | 随参考窗口增长 | MIT，开源 |
| 逐页 OCR 再拼接 | 不限（分批跑） | 拼接处易断：跨页表格、脚注、前后引用常丢 | 每页固定，但拼接成本另算 | 多为传统 OCR 工具链 |
| 通用视觉大模型整本输入 | 受上下文窗口限制 | 窗口内保留，超窗截断 | KV 缓存与单步成本随页数上涨 | 多为闭源 API 或大权重 |
MPDocBench 综合得分对比（百度自报，preliminary）
★ Unlimited-OCR-284.6
Qwen3.8-Max78.3
Gemini-3.8-Flash76.2
数据来源：来源：百度自报基准口径（2026-10-29 多源报道一致）；无第三方复现，仅作量级参考
常见问题解答 (FAQ)
Unlimited-OCR-2 真能读“无限”页吗？
机制上可以，总成本上不行。SR-SWA 把每步解码的参考集固定在 512 个 token，所以单步延迟与内存不再随页数上涨，演示里 3600 多页一次过关；但图像编码要逐页做，总时长仍然随页数增长，整机内存需求也不会完全不动。理解成“不再被页数卡住单步成本”，不要理解成“页数免费”。
本地跑 Unlimited-OCR-2 要什么硬件？
BF16 权重约 6.2GB，官方测试用单张 NVIDIA A800 80GB；消费级大显存卡按权重规模也能跑，但要给激活与缓存留余量。Transformers 适合快速试验，SGLang 是官方推荐的上服务路线，社区另有 vLLM 支持；平台上暂无量化版本，CPU 能跑但长文档会明显变慢。
84.6 和 77.1 这两个分数可信吗？
目前只能当参考。两项分数全部是百度自报，标注 preliminary，没有第三方复现；MarathonDocBench 还是百度随模型新发的基准，存在自家出题自家考的口径问题。等独立评测出现后再拿它们做采购论证，现在只适合判断方向与量级。
和第一代 Unlimited-OCR 有什么区别？
机制换代。第一代用 R-SWA 参考滑动窗口，只能处理连续数十页，在百页级 MarathonDocBench 上得 0 分；第二代换成 SR-SWA 稀疏参考，把参考集压进固定 512 个 token，页数上限从数十页推到演示里的 3600 多页，MPDocBench 也从上一代水平涨到 84.6。