长文档解析怎么选?这个开源模型把300页的显存从47GB压到了1.77GB

💡 福利：关注本公众号并私信发送【智能体学习】，即可获得智能体系统性学习资料，先到先得！

做文档解析的人，对下面这个场景不会陌生：手上有一份三百页的扫描版 PDF——招股书、设备说明书、九十年代的老教材——想把它变成干净的 Markdown，喂进知识库或者 Agent 管道。通行做法是拆成三百张图，一页一页跑，再把结果拼起来。

跑是能跑，麻烦全在接缝处：跨页表格被切成两半，第 137 页末尾的半句话接不上第 138 页的开头，页码、页眉、页脚到处乱飞。更致命的是，模型每翻一页就把上一页忘得干干净净——它读的永远是“当前这一页”，而不是“这本书”。

2026 年 10 月 27 日，百度发布并开源了 Unlimited OCR 2。它想做的事情很直接：别一页一页读了，整本一次读完。 官方实测中，它一次性解析了《哈利·波特》全系列 7 部、累计超过 3,600 页。

但比“能读 3,600 页”更值得拆的，是它为了做到这件事，改掉了 Transformer 解码器里一个几乎被默认接受的设计假设：注意力必须覆盖全部历史。

GitHub 地址：https://github.com/baidu/Unlimited-OCRStars / Forks：约 30.8K Stars / 3.3K Forks（2026 年 11 月快照，不同数据源抓取时间不同会存在波动，以 GitHub 实时口径为准）

📌 本文建议先收藏

这是一篇“问题拆解 + 机制分析 + 冷静评估”型文章。如果你在做 RAG 数据管道、超长文档处理，或者在关注“长序列推理成本怎么被结构性压下来”这条路线，这篇文章帮你搞清楚 Unlimited OCR 2 到底改了什么、SR-SWA 怎么把显存压成常数、以及它“不能做”的事情是什么。

📌 读完你将获得

✅ 超长文档解析的三笔账——KV Cache、注意力计算、视觉冗余，为什么一起往上涨

✅ SR-SWA 的核心思路——不是把窗口拉长，而是把参考集压成固定大小

✅ 关键数据怎么读——47GB → 1.77GB，单步 7×，以及这些数字的边界

✅ 一个被忽略的工程现实——512 tokens 是解码步的账，10 页窗口是端到端的妥协

✅ 冷静评估——自建基准、单页精度取舍、官方口径与独立复现之间的距离

一、先理解它要解决的不是“识别精度”，是“长度把成本撑爆了”

Unlimited OCR 2 的定位是超长文档的一次性端到端解析。它不是去和单页 OCR 模型比某个字符的识别率，而是去回答一个单页模型结构上回答不了的问题：当文档从 10 页变成 300 页，解码成本能不能不跟着线性甚至平方级地涨？

按官方口径，几乎不能涨。三百页文档的峰值 KV Cache 从 47.00 GB 压到 1.77 GB，降幅约 96%；16 路并发下端到端吞吐从 360 tokens/s 提到 1,315 tokens/s，约 3.65 倍。

但“KV Cache 压成常数”到底是什么意思，需要放在长文档的三笔账里才能看清楚。

二、长文档的三笔账：为什么“读长”这件事天然贵

把一本三百页的书喂给模型，有三笔账同时往上涨。

第一笔：KV Cache 越存越多。 大模型生成每个 token 时，都要回头看前面所有 token 的 key 和 value。这些值必须缓存。写到第 10 万个字时，缓存里躺着 10 万份 key/value。

第二笔：注意力越算越慢。 每生成一个 token，都要拿它和前面所有 token 做相似度计算。序列翻倍，计算量翻四倍——这是标准 Full Attention 的二次方老毛病。

第三笔：视觉冗余越来越重。 这一笔最容易被忽略。当模型在抄第 250 页时，第 3 页的那些像素对它毫无用处，但标准全注意力仍然要求它把第 3 页的每个视觉 token 都算一遍。arXiv 论文里把这个问题写得很直白：随着文档长度到几百页，视觉上下文急剧膨胀，每一步解码的计算成本都被显著推高。

这三笔账叠在一起，就是为什么“把上下文窗口堆大”解决不了超长文档——窗口可以堆，但堆出来的每一步解码成本，是页数的函数。

三、SR-SWA：把“看整本书”换成“看当前页，只在需要时回看”

Unlimited OCR 2 的核心机制叫 稀疏参考滑动窗口注意力（SR-SWA）。官方的类比是人抄书：你抄当前这一页时，注意力就放在这一页上；只有当需要核对前文、或者查找跨页信息时，才会回看相关的那几段，而不是把整本书从头翻一遍。

“抄当前页”这个类比真正值得注意的地方，不是它“像人”，而是它把“每一步解码要看多少东西”从“页数的函数”变成了“一个常数的函数”。 人抄书之所以能持续很久，不是因为记忆力好，是因为工作台的大小不随书变厚而变大。SR-SWA 把工作台钉死在了固定容量上——这才是成本曲线被压平的原因。

工程上，SR-SWA 做了一件很明确的事：把文本和视觉之间的注意力交互，从超长序列压缩到一个固定容量的工作参考集——Hugging Face 模型卡里给出的典型值是 512 tokens。论文里的表述是“bounding active reference tokens to a fixed capacity”，从而在任意长度的文档上维持恒定的计算成本。

关键不在于“窗口多大”，而在于“窗口是不是固定的”。 一旦工作参考的容量有上界，每一步解码的延迟和显存占用就不随文档长度增长——二次方注意力带来的显存瓶颈，被换成了一个常数级的工作集。

但需要提前说清楚：这个 512 是解码步的账。端到端部署时按页切分的窗口，是另一个层面的问题——这一点在第四节和第五节会展开。

再配合 Unlimited-Horizon Decoding，模型可以在一个有限的上下文窗口里，处理远超窗口长度的文档：分块推进，但块与块之间通过工作参考保持连续性。

四、数据：增益是真实的，但边界比数字更重要

官方公布的核心数据：

MarathonDocBench 上第二名 Kimi-K3 为 33.7 分，差距很大。子项上，文本 94.8 / 89.6、公式 89.4 / 87.9、阅读顺序 92.3 / 85.3、表格 87.8 / 74.8，而标题层级（TEDS）只有 60.1 / 48.2，是明显的短板。

但读这组数字时，有四件事需要放在前面：

第一，跑分口径是“百度自测 + 百度自建基准”。 MPDocBench 和 MarathonDocBench 的成绩均来自百度官方公布；MarathonDocBench 是随模型一起发布的自建评测集，论文中明确写的是“our newly proposed benchmark”。截至写作时，第三方独立复现尚未发布。这不代表数字不可信，但意味着它目前支持的是“在百度设定的测试条件下领先”。

第二，在通用单页基准上，它落后专用 OCR 模型。 OmniDocBench 上 Unlimited OCR 2 约 94 分（v1.6 口径约 93.9），低于 OXR 的 97.18 等专用模型。这是一个明确的取舍，不是缺陷：SR-SWA 为了长度牺牲了一部分单页的密集精度。百度自己的 PaddleOCR-VL 走的是单页精细识别路线，拿一张发票去和 Unlimited OCR 2 比单页准确率，是选错了工具。

第三，1.77 GB 是“峰值 KV Cache”，不是“整卡占用”。 实际部署还要给图像编码、权重和 batch 预留显存。模型规模约 3.34B 参数，权重本身约 6.6G（bf16）。

第四，官方部署示例里长文档并不是“一口气塞进去”的。 如第三节所述，512 tokens 是解码步的账；到了端到端部署，账本会变成另一个样子——按 ic.work 对部署脚本的拆解，实际处理是按 10 页一个窗口切开，复用前一个窗口的 KV 尾部来保持衔接，测试环境用的是 80GB 显存的 A800。512 tokens 稳住的是解码步的账；端到端的总显存和跨窗口的连续性，仍然是另一笔账。

五、冷静评估：它证明了什么，没证明什么

它真正证明的事情

“超长文档解析”的瓶颈可以被结构性绕开，而不是靠堆硬件硬扛。 把注意力交互压到固定容量的工作参考，让每一步的解码成本与页数脱钩——这个设计选择在工程上是有说服力的。47GB 到 1.77GB 不是优化出来的一个百分点，是把成本曲线从“随页数涨”改成了“近乎平的”。

而且它解决的不只是“读得完”，还有“读得连”。官方文档明确列出了跨页表格识别并合并、跨页段落按语义重新接续，输出带边界框、块类型和结构层级的结构化文档。这些能力指向的是 Agent 和 RAG 真正需要的东西：一份完整、连续、可以直接消费的文档，而不是三百份互不相识的碎片。

需要警惕的地方

第一，评测独立性是最大的未知数。 主推基准 MarathonDocBench 是自建的，第三方复测尚未发布。“大幅领先”这类结论，在独立验证出现之前，应该读作“在团队设定的条件下领先”。

第二，它不擅长单页密集精度，而且标题层级是明确的弱项。 如果你的场景是“一页发票、一页证件、一页表单”，OXR、PaddleOCR-VL 这类专用模型在单页基准上更强。Unlimited OCR 2 的性价比，只在“长”这个维度上成立——文档越短，它的架构优势越不明显。标题层级 TEDS 在长文档上只有 48.2，意味着它输出的结构树在“谁是谁的上级”这件事上，还远没有到可以直接信任的程度。

第三，固定参考集意味着“看什么”被选择过，而 10 页窗口是一个工程妥协。 SR-SWA 的注意力只落在页面门控筛出的相关页和固定容量的参考集上。如果关键信息恰好不在“被选中的参考”里，模型可能看不到它——这是“近乎恒定成本”的代价。更现实的是，ic.work 指出，把 10 页窗口进一步调小虽能压低峰值显存，但会直接损伤跨窗口边界的段落衔接与跨页大表格合并精度。“无限页数”在模型层面成立，在端到端服务层面仍然有窗口大小的二选一。

第四，它是“OCR 3.0 叙事”的一部分，但叙事不等于终局。 官方把这条路线定义为从 OCR 1.0（流水线）到 2.0（端到端单页）再到 3.0（无限视域）的演进。这个框架是清晰的，但**“无限页数”解决的是长度问题，不是“所有文档理解问题”**。把“能一次读完 3,600 页”读成“文档解析已经解决了”，是一种过度延伸。

把上面的边界收拢成一句选型判断：它擅长的是“长而连续”，不是“短而密集”。

六、写在最后

Unlimited OCR 2 的真正贡献，不是“读了 3,600 页”这个演示，而是把长文档解析的成本账，从“页数的函数”改成了“近乎常数”。

SR-SWA 的思路不复杂——抄当前页，只在需要时回看——但它动的是一个被默认接受的设计假设：注意力必须覆盖全部历史。一旦这个假设被松开，KV Cache 和单步延迟就不再是超长文档的硬约束。3.34B 参数、47GB → 1.77GB、单步 7×、16 路并发 1,315 TPS，这几个数字放在一起，说明“长度”这件事在文档解析里正在从天花板变成地板。

但它能做的事情有清晰的边界：它擅长的是“长而连续”，不是“短而密集”。单页基准上的落后、标题层级的 48.2、自建评测的未经验证、10 页窗口的端到端妥协——这些不是要否定的理由，而是选型时必须算进去的账。

如果你身边有人在处理几百页的招股书、合同卷宗或历史档案，把这篇转给他——不是推荐一个模型，而是帮他看到一个“页数不再是成本”的选项已经出现了，以及这个选项的代价在哪里。

💡 OCR 的下一代竞争，可能不再是谁认字更准，而是谁能在不把成本撑爆的前提下，把“整份文档”当成一个整体来读。Unlimited OCR 2 用一套固定容量的参考集，把“页数”从成本函数里几乎拿掉了——但它拿掉的是长度，不是判断力。（如果这两句让你停下来想了想，长按划线，帮这篇文章拿到更多曝光）

🔥 留言区聊两句

47GB→1.77GB 这个数字很漂亮，但我更关心“固定参考集”的代价——如果关键信息恰好不在被选中的参考页里，跨页接缝的准确率会不会掉？另外，官方部署是按 10 页一个窗口切开的，这算不算“无限页数”在工程上的一种打折？有没有人拿自己领域的长文档跑过 SR-SWA 的实际召回？

• A. 还在拆页 + 后处理，跨页表格和段落接缝是主要痛点
• B. 已经在用 Unlimited OCR 系列或其他长文档方案
• C. 长文档占比不高，单页精度更重要
• D. 还在选型，先看看

🔗 参考资料：

• GitHub：https://github.com/baidu/Unlimited-OCR（MIT 协议；约 30.8K Stars / 3.3K Forks，2026 年 11 月快照，不同数据源抓取时间不同会存在波动）
• Hugging Face：https://huggingface.co/baidu/Unlimited-OCR-2（约 3.34B 参数）
• Unlimited OCR Works 2, arXiv:2610.39308, Shu Wei et al., 2026-10-29
• 百度 AI 开放平台《开放公测：文心 Unlimited OCR 2 开源发布》，2026-10-27
• 新华网《文心 Unlimited OCR 2 开源发布，超长文档解析迎来“页数自由”》，2026-10-27
• 53AI《百度开源“不会累”的OCR：300页一次读完，显存仅需1.77 GB》，2026-10-28
• 掘金《把 200 页财报塞进一次请求：Unlimited-OCR 2 部署、显存账和三个坑》，2026-10-28
• ic.work《百度开源 Unlimited OCR 2：512 Tokens 稳住百页解码显存与 10 页窗口妥协》，2026-10-27
• Pandaily《Baidu Open-Sources Unlimited OCR 2, Parsing Documents of Any Length in One Pass》，2026-10-28
• MarkTechPost《Baidu Open-Sources Unlimited OCR 2 for Hundred-Page Document Parsing》，2026-10-27
• WaveSpeed 模型评测记录（OmniDocBench v1.6 口径 93.92），2026-10

如果这篇帮你理清了 Unlimited OCR 2 的 SR-SWA 到底改了什么、以及它那条“长度优先”路线的边界——欢迎转发给你正在处理超长文档的同事。