Unlimited OCR 2 解读：性能、本地部署与同类模型对比

百度在 2026 年 10 月 27 日发布了开源的 Unlimited OCR 2：一个采用 MIT 许可证、总参数量 3.34B 的视觉语言模型，专门用来解析超长文档——上百页的书籍、财报、研报，一次请求全部读完。它最核心的变化是名为 SR-SWA 的新注意力机制，让每个解码步骤的开销几乎不随页数增长。在百度自己公布的基准上，它在团队报告的两个多页文档解析测试中都排名第一，其中在新推出的百页级基准上，第二名模型的成绩还不到它的一半。部署方面，模型卡文档给出的路径很清晰：快速测试用 Transformers，正式服务用定制版 SGLang wheel，首批测试在一张 80GB 的 NVIDIA A800 上完成。

这篇文章会把模型本身、SR-SWA 的工作原理、基准成绩能证明什么和不能证明什么、文档写明的部署要求，以及它与其他开源 OCR 模型的对比一次讲清楚。先说明一个前提：下文所有性能数字都是百度自报的——本文没有独立基准测试，凡是只能从图表里读出的数字，我们会明确标注。

核心要点

• Unlimited OCR 2 是百度第二代长文档 OCR 模型：总参数 3.34B（MoE 架构），MIT 许可证，2026 年 10 月 27 日上线 Hugging Face、ModelScope 和百度智能云。
• SR-SWA（Sparse Reference Sliding Window Attention，稀疏参考滑窗注意力）把超长文档的注意力压缩到一个约 512 token 的固定工作参考集，让每步解码的延迟和显存几乎不随页数变化。
• 自报成绩：MPDocBench 84.6 分、MarathonDocBench 77.1 分——在百页级基准上，第二名 Kimi-K3 只有 33.7 分。标题层级（heading hierarchy）是它的短板，MarathonDocBench 上仅 48.2 分。
• 本地部署文档写明跑在单张 CUDA GPU 上（测试机为 A800-80GB，BF16 权重约 6.7 GB）：快速测试用 Transformers（需 trust_remote_code=True），规模化服务用定制 SGLang wheel。
• 横向对比：DeepSeek-OCR-2（3.39B，Apache 2.0）和 PaddleOCR-VL-1.6（0.96B，Apache 2.0）都是可信的备选，但两者都没有出现在百度这两个基准上，所以对比只能落在设计思路和生态上，而不是实测分数。

Unlimited OCR 2 是什么？

Unlimited OCR 2 是百度 ERNIE 团队出品的文档解析视觉语言模型：输入按页序排列的页面图片，输出结构化文本——段落、表格、公式、标题和阅读顺序。它的前身是 2026 年 6 月发布的 Unlimited-OCR，当时的定位是"把 DeepSeek-OCR 再往前推一步"；这层渊源延续到了 v2：架构保留了 DeepSeek-OCR 式的布局，模型卡也明确致谢了 DeepSeek-OCR、DeepSeek-OCR-2 和 PaddleOCR。

v2 于 2026 年 10 月 27 日发布，同日上线的还有 MarathonDocBench——团队专为百页级解析新造的基准。技术报告 Unlimited OCR Works 2 于 10 月 29 日挂上 arXiv。团队把这次发布称为"开创 OCR 3.0 时代"——这是他们的宣传语，不是独立评价。

根据 MarkTechPost 对配置文件的分析，模型由 SAM ViT-B 加 CLIP-L 的图像编码器，接一个 12 层混合专家解码器组成：每个 token 路由到 64 个专家中的 6 个，外加 2 个共享专家——DeepSeek-OCR 论文把这套解码器称为 DeepSeek3B-MoE-A570M。多页模式下每页编码为 273 个图像 token。权重和代码在 Hugging Face 上，ModelScope 和百度智能云有镜像，HF Spaces 上有社区 demo，页面上已列出十二个社区量化版本，可跑 llama.cpp、Ollama 和 LM Studio。

图片来源：Hugging Face 上的 baidu/Unlimited-OCR-2 模型卡（huggingface.co），访问于 2026 年 11 月 2 日。

SR-SWA 怎么拆掉长文档的算力墙？

SR-SWA 解决的是注意力开销的平方级增长问题。全注意力的计算量随序列长度平方增长，而且解码时每个新 token 都要扫描更长的 KV cache。Unlimited OCR 2 每页编码 273 个图像 token，一份 100 页的文档在模型输出第一个字之前就有约 27,300 个输入 token——而且每多写一个字，扫描就更慢。

SR-SWA 全称 Sparse Reference Sliding Window Attention（稀疏参考滑窗注意力）。它不让每个 token 都看完整的超长序列，而是把文本-视觉注意力交互压缩成一组固定大小的"工作参考"——文档示例里是 512 个 token。配置上是 128 token 的局部窗口（模型正在转写的当前位置）加上从 32-token 块中选出的 top-16（保留的全局上下文）。论文把这比喻成人抄书：只盯着正在抄的内容，外加一段有界的"前面读过什么"的记忆，而不是每写一笔都从头重读。

模型卡声称的结果是：每步解码的延迟和显存占用几乎不随文档长度变化。在百页级规模上，论文报告相对全注意力 7.0 倍的每步加速，相对 v1 使用的 R-SWA 是 5.6 倍。这就是"unlimited-horizon parsing"能在 131,072 token 的有限上下文窗口里成立的原因：页数上的视界是无界的，但单步计算是有界的。

两句话把话说全。第一，"每步开销几乎恒定"不等于"总耗时恒定"——图像编码和整体处理时间仍随页数上升。第二，"unlimited"运作在上下文窗口和推理栈的页窗口调度之内；这是关于扩展行为的工程结论，不是"百页文档瞬间转完"的承诺。

本文创作的过程示意图，仅表达机制概念，非实测行为。左：每个 token 关注所有页面；右：128 token 局部窗口加约 512 token 固定参考集。

实际性能到底怎么样？

简短回答：按百度自己的测量，它在团队报告的两个多页基准上都是第一——而且优势恰恰出现在别的模型崩掉的地方：百页级文档。短板也很明确：标题层级。本节所有数字来自百度的榜单和论文；MarkTechPost 指出部分数字只能以图表图片的形式看到，目前也没有任何第三方复现过。

在采用数十页文档的 MPDocBench 上，Unlimited OCR 2 拿到 84.6 分，领先 Qwen3.8-Max 的 78.3 和 Qwen-3.8-Flash-Next 的 77.4。在百页级的 MarathonDocBench 上它拿到 77.1 分，第二名 Kimi-K3 是 33.7，Gemini-3.8-Flash 是 28.6。

分数跌幅是更有信息量的对比。从数十页换到数百页文档，Unlimited OCR 2 只掉了 7.5 分；Qwen3.8-Max 从 78.3 跌到 22.9，跌了 55 分；没有 SR-SWA 的前代 Unlimited-OCR 在 MarathonDocBench 上得分是 0.0——v1 的机制在百页文档上根本撑不住。这组反差是这次发布最有说服力的信号，但它也恰恰是厂商选择公布的对比。

分项成绩（MPDocBench / MarathonDocBench），来自百度榜单、经 MarkTechPost 转述：

文本和公式提取在两个规模上都表现出色；表格在百页级上保持得不错（74.8）；标题层级是短板——MarathonDocBench 上的 48.2 是全场最低分项，所以强依赖多级标题结构的文档需要额外校验。另外要注意：MPDocBench 上的单项领先幅度很小（Qwen3.8-Max 文本 94.3、公式 89.2，与 v2 基本持平），"SOTA"的说法真正站得住的地方是长文档成绩。

图片来源：arXiv 论文《Unlimited OCR Works 2》摘要页（arxiv.org/abs/2610.39308），访问于 2026 年 11 月 2 日。

本地部署：文档实际要求什么？

本节内容全部基于文档——来自模型卡和 GitHub README，不是我们自己的实测。模型卡给出两条受支持路径：快速测试用 Transformers，正式服务用 SGLang，测试硬件为 NVIDIA A800-80GB。

用 Transformers 快速测试

Transformers 路径面向单机实验。文档要求固定版本：Python 3.10、torch 2.13.0、transformers 4.52.1、huggingface-hub 0.36.0、tokenizers 0.21.4。加载模型需要 trust_remote_code=True——值得停一下：这个开关会执行模型仓库里自带的 Python 代码。对一个大厂的 MIT 许可模型来说这是常见取舍，但它实质上是你在做一次供应链信任决策。

文档给了两种推理模式。infer() 用动态切片处理单页（称为"gundam 模式"），适合高分辨率页面。infer_multi() 把一份文档的所有页面放进一次请求——prompt 自动构造为逐页重复的 <PAGE><image> 加上"Multi page parsing."——让模型能用跨页上下文，这正是一个长文档模型的意义所在。输出按输入顺序保留每页一个 <PAGE> 标记。

用定制 SGLang wheel 做服务

正式服务场景下模型卡推荐 SGLang——但不是上游官方包。你要安装百度定制的 wheel（sglang-0.5.20.dev13+g75b9b06b02），外加用于 PDF 转图片的 PyMuPDF。这是实打实的运维考量：你被绑在一个快速迭代推理框架的厂商 fork 上，升级跟随百度的发布节奏，而不是 SGLang 的。

文档配置里浓缩了几条用显存换来的教训：

• 页窗口：超长文档按 10 页一个窗口调度（gundam 或 base 模式），并复用上一个窗口的 KV 尾部。更小的窗口能压低显存峰值，但会伤害跨页合并——跨窗口边界的段落会丢失上下文。
• --mem-fraction-static 0.7：文档给出的稳定值。0.75 在 32 路以上并发时余量不足。
• --max-prefill-tokens：驱动一个约 [tokens, context/32] 的临时张量，显存随它线性增长——从 4096 降到 2048 就能把这块峰值砍半。--cuda-graph-bs-prefill 最大的桶必须等于这个值，否则超大批次会静默回退到 eager 执行。
• CUDA graph 并发：默认的 full_prefill_max_req 是 8，16/32 路并发会回退到 eager 模式；文档配置把它提到 64。
• SAM bias 的 OOM 陷阱：SAM 注意力 bias 的默认分块上限（512）会产生一次约 462 MiB 的单笔分配，可能直接 OOM。文档写明 SGLANG_OPT_UOCR_SAM_REL_POS_BIAS_MB=64 效果等价且峰值低得多。PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True 还能进一步减少碎片化失败。

服务 API 的契约

服务跑起来之后，走 OpenAI 兼容的 /v1/chat/completions 接口，页面图片以 base64 编码传入。文档给的模式是：temperature 0；一个防重复的 n-gram logit processor（n-gram 大小 35，多页窗口 1024、单页 128）；max_tokens 设为每页 token 数 × 页数（示例用每页 8,000，单页输出上限 20,000）；PDF 先按 300 dpi 转成图片再提交。

更轻的路径和获取渠道

不是每个人都需要完整的服务栈。Hugging Face 页面已经列出十二个社区量化版本，可跑 llama.cpp、Ollama 和 LM Studio，还支持 Docker Model Runner 一行命令启动。模型在 ModelScope 和百度智能云有镜像，ms-swift 社区在 10 月 28 日加上了微调支持。一个诚实的空白：除了 A800-80GB 测试环境和约 6.7 GB 的 BF16 权重体积，文档没有给出最低显存要求——请为激活值、页批次和框架本身的开销留出预算，并在自己的硬件上实测。

和其他开源 OCR 模型比怎么样？

下面是诚实的对比表，由 MarkTechPost 交叉核对各模型 Hugging Face 页面，加上百度的榜单整理而成：

读基准两行要小心：DeepSeek-OCR-2 和 PaddleOCR-VL-1.6 完全没有出现在百度这两个基准上，所以"第一名"的含义是"在百度选择上榜的九个模型里第一"——别忘了，这是自报成绩。这张表能支持的结论是：v2 是这一组里唯一一个为百页解析设计了专门机制、并给出对应基准的模型，而且它在文档规模变化时的分数跌幅（7.5 分）很小，而竞品是崩盘式的。

怎么选：如果你的任务是一次性解析长文档——书籍存档、上百页的财报、给 RAG 管线用的多页研报——Unlimited OCR 2 是这批模型里唯一为此设计并被基准验证过的。如果是在普通硬件上做轻量单页批量提取，0.96B 的 PaddleOCR-VL-1.6 配合宽松许可证和成熟工具链是合理选择。如果你已经深度使用 DeepSeek 生态，DeepSeek-OCR-2 能让你留在原地。而如果你特别需要 Apache 2.0 许可证下的长文档解析，这一条就足以排除 MIT 许可的两个百度模型。

部署前要掂量的局限

把上文任何数字当成采购决策之前，先看这些关键 caveat：

• **所有成绩都是自报的。**在我们的信源里，Unlimited OCR 2 没有任何独立基准。最强的成绩恰恰出现在 MarathonDocBench——一个由模型同一团队推出、与模型同日（2026 年 10 月 27 日）发布的基准。
• **部分数字只有图表。**榜单上的若干数字只能以图表图片而非论文表格的形式查看，精确核验更难。
• **标题层级是短板。**MarathonDocBench 上 48.2 的最低分项意味着结构复杂的文档可能需要后处理。
• **运维上有附加条件。**服务路径绑死定制 SGLang wheel，Transformers 路径也会经 trust_remote_code=True 执行仓库代码。两者都是信任决策，不只是便利设置。
• **内部细节未公开。**v2 的激活参数量没有公布，A800-80GB 测试配置之外的最低显存也没有文档。

结论

如果你的问题恰好是"把很长的文档一次解析完、保留结构"，那 Unlimited OCR 2 是当前最可信的开源选项——自报数字显示，优势最大的地方恰恰在这里。SR-SWA 是对平方级算力之墙一个实打实的架构解法，而 v1 在同一基准上的 0.0 分让这次代际跨越变得具体。

但证据基础完全来自厂商。如果你在评估它，最有价值的下一步是在自己的文档上做一次小规模对照测试：挑一份标题层级复杂的报告、一份表格密集的财报、一份能代表你工作负载的百页 PDF，和现有解析器同台对比，用你的硬件、你的页长。模型的官方文档给了你一个下午跑完这场测试所需的一切；基准数字给你的是待验证的假设，不是可以照单全收的结论。