把《哈利·波特》全七部一次性丢给一个开源模型：累计超过 3600 页，跨页表格不断表、跨页段落不丢字，一个半小时左右跑完全书。这不是概念演示，而是百度在 2026 年 10 月 27 日正式发布并开源的文心 Unlimited OCR 2 给出的官方实测演示。代码与权重同步开放，仓库在 github.com/baidu/Unlimited-OCR，权重同步上架 Hugging Face 的 baidu/Unlimited-OCR-2 与魔搭社区的 PaddlePaddle/Unlimited-OCR-2，仓库地址：github.com/baidu/Unlimited-OCR。
先交代本篇分工：站内已有六款开源 OCR 的选型横评（见六款开源 OCR 模型横评）、0.9B 小钢炮 GLM-OCR 的单体深评（见GLM-OCR 开源资源）和 DeepSeek-OCR 压缩路线的部署实操（见DeepSeek-OCR 本地部署 SOP），它们解决的是单页与几十页的问题；本篇管的是另一个维度——超长文档、任意页数，一次读完一整本书。
一、仓库与许可证：MIT，商用没有门槛
先说最实际的：许可证。仓库 LICENSE 逐字核验为标准 MIT License，版权行为 Copyright (c) 2026 Baidu，没有附加商用限制条款。翻译成大白话：可以商用、可以修改、可以再分发、可以本地离线部署，唯一义务是保留版权与许可声明。在一票「仅限研究」的开源模型里，这是相当干净的一种姿态，也是它与很多同行拉开差距的隐性卖点——当然，MIT 自带的免责条款仍然有效，别夸大成「无任何限制」。
时间线也值得一看：仓库 2026 年 6 月 18 日创建，6 月 22 日第一代发布，10 月 27 日第二代在同一仓库发布，并同步上架魔搭与百度智能云。热度方面，官方公告口径为 2.85 万星（10 月 27 日），10 月 30 日实测 29,757——三天自然增长，仍在上升期。11 月 12 日的百度世界 2026 大会还将进一步展示这个系列的技术亮点与应用潜力。
二、跑分：双榜第一与一个刺眼的反差
按官方公告口径，Unlimited OCR 2 在 MPDocBench 拿下 84.6，在百页级的 MarathonDocBench 拿下 77.1，双双端到端第一，且大幅领先 Qwen 3.8-Max、Gemini-3.8-Flash、GLM-5.3-Flash、DeepSeek-4.1-Flash 等参评模型。技术报告的精确值分别为 84.59 与 77.06，公告口径是四舍五入，两者同源，不构成矛盾。
反差在第二名。据技术报告所列参评模型，MarathonDocBench 上第二名 Kimi-K3 只有 33.74，与 77.1 差出四十多分——长文档解析这一项，专用架构和通用大模型之间的差距不是鸿沟，是断崖。
但这组分数必须带一个限定：MarathonDocBench 是百度自建基准，100 份文档、每份 103 到 300 页、20.5 万个标注元素，标注流程自家起步，发布时基准未公开下载；报告未给「分段调用再拼接」的对照组，截至发稿全部成绩均为百度自报、无独立第三方复现。「双榜第一」成立的前提是「在这份自家基准上」，买不买账，建议等第三方复测再下结论。
演示侧的口径可以并列着看：官方实测一次解析《哈利·波特》全七部累计超过 3600 页；第三方精确口径为 3623 页、总耗时约 1 小时 30 分、平均每页约 1.5 秒。另有《四大名著》合订本 5026 页、《三体》1200 余页的官方演示。
三、SR-SWA：像人一样「抄书」
超长文档难在哪？难在注意力。传统 Full Attention 每生成一个字都要回看前面所有视觉 token，文档越长，每一步越贵。人类显然不是这么读书的——抄书的人只盯着当前页，需要核对前文或查跨页信息时才回头翻一下。
SR-SWA（Sparse Reference Sliding Window Attention，稀疏参考滑动窗口注意力）抄的就是这个作业：把文本与视觉的注意力交互压缩到一个固定大小的工作参考集（约 512 个 token），让单步解码的延迟与显存占用几乎不随文档长度变化。具体分两步：Page Gate（页面门控）先把每个查询的视觉参考范围从整份文档缩小到相关页面，并建模跨页位置关系；再用 Token Buckets 取得分最高的视觉 token 桶，捕捉长距离依赖。第三方技术拆解补充了细节：候选页内每 32 个 token 压成摘要 key 算相关性，取 top-k 块进参考集，路由打分直接参与端到端训练，无需额外蒸馏一个路由器。
解码侧配合无限解码机制（Unlimited-Horizon Decoding）：文档按页窗口分块推进，相邻窗口保留一页「交接页」并复用其 KV 缓存，用来衔接跨页段落与续表；历史窗口的缓存随即从显存释放。于是任意时刻，显存里始终只有一个窗口的大小——这就是「任意页数」的底气。
和一代 R-SWA 的分界在这里：一代只把文本历史压进滑动窗口、没处理视觉 token 随页数增长的问题，输入上限约 40 页；二代同时限住了「每步看多少视觉 token」，才敢把上限推到「无限」。位置编码的处理同样取巧：页级 RoPE 坐标只在 0 和 1 之间交替，页内坐标照常递增，位置量有界，长度因此可以无限外推——用两行约定换无限长度，是整套设计里最省的一段。顺带一句技术划界：站内写过的 DeepSeek-OCR 走的是视觉压缩降 token 的路线，本篇主角是稀疏参考控注意力范围，两条路线不同，此处不展开。
四、三大产品能力：版面、跨页表格、跨页段落
第一，原生版面要素切分。标题、段落、表格、公式、图片自动切分识别，交付边界框、块类型与结构层级，输出顺序与阅读顺序一一对应——下游做 RAG 或结构化入库时，不用再自己排一遍版。
第二，跨页表格识别合并。财报里那种跨页续排的合并报表，模型自动识别延续关系并合并为完整一张表。技术报告分项 T-Table 得分 71.11，而报告所列通用模型无一超过 27，这一项的领先幅度比总分更夸张。
第三，跨页段落无缝接续。靠无界视域解码范式保障连续性，把被页码切断的段落在语义层面重新接续，官方口径为不丢字、不乱序、不重复。对整本书级别的解析来说，这一点比单页精度更要命。
五、效率：一笔显存与速度的账
官方口径下，百页文档场景 SR-SWA 的单步解码速度达到 Full Attention 的 7 倍、上一代 R-SWA 的 5.6 倍。据技术报告，百页级单序列测试的峰值 KV 缓存从 47GB 降到 1.77GB，减少约 96.2%；16 路并发下端到端吞吐从 360 TPS 提到 1315 TPS，约 3.65 倍。注意两点：一是 1.77GB 仅指 KV 缓存，不含模型权重，别换算成「4GB 显存就能跑」；二是这些效率数字均为官方自报，暂无第三方复现。
「无限」也要打引号。官方自己承认，图像编码与总运行时间仍随页数增长——恒定的是单步解码开销，不是总耗时。第三方拆解给出的曲线对比是：Full Attention 下文档从 2 页加到 100 页，单步解码延迟从约 3 毫秒涨到约 27 毫秒，而 SR-SWA 的单步耗时几乎是一条水平线。3600 页跑一个半小时，就是这个边界的直观数字。
抗干扰表现也有自测数据可看（官方自测口径，无第三方复现）：在 240 页、17.3 万字的小说里埋入 32 处人名与页码篡改陷阱，模型全部按纸面原文一字不差输出；300 页、3000 条财务台账中混入 176 条负数冲销，全部识别正确，合计金额分毫不差。这类「对抗样本」演示比榜单更能说明长文档场景的实际成色，但口径同前，听听方向即可。
六、社区热度：第一代攒下的家底
这个系列不是无名之辈。第一代 2026 年 6 月 22 日发布，次日登顶 GitHub Daily Trending 总榜、Python 榜与 HuggingFace 全球模型总趋势榜、多模态模型趋势榜，四榜第一；开源 5 天 GitHub 星破万。据中国科学报口径，第一代 HF 累计下载量已突破 1000 万次，还获得过图灵奖得主 Yann LeCun 的转发推荐。二代踩着这个起点出场，三天涨到近 3 万星，生态底子是现成的。
七、部署：两条路线与几个坑
推理路径两条。一是 Transformers 原生推理，适合快速测试：Python 3.10、torch 2.13.0、transformers 4.52.1，加载模型必须 trust_remote_code=True（自定义建模代码在仓库内；生产环境建议先审计这批代码再上线）。多页走 infer_multi 一次请求吃整份文档，单页默认动态切片 gundam 模式。
二是服务化，官方推荐定制版 SGLang（OpenAI 兼容 API，页窗调度每块 10 页、相邻块共享边界页 KV）。注意别和第一代搞混：vLLM 支持是一代 6 月 28 日的记录，二代 README 只列 Transformers 与 SGLang。部署须装仓库自带的定制 SGLang wheel，版本以 README 最新为准，建议单独建环境避免冲突。生态侧的另一条线是训练：ms-swift 已于 10 月 28 日支持二代训练，想在其上微调垂直文档场景的团队可以留意；HF Spaces 上有现成 demo，百度智能云也提供托管，不想折腾环境的可以直接用云端版。
几个显存相关的坑，README Notes 原文口径：mem-fraction-static 建议 0.7，0.75 在 32 路以上并发时余量不足；SAM 注意力偏置默认分块 512，允许单次约 462MiB 的大块分配，容易 OOM，把分块设小（环境变量 SGLANG_OPT_UOCR_SAM_REL_POS_BIAS_MB=64）等价且峰值更低；页窗越小越省显存，但跨页合并质量会下降——块大小是按文档特点调的旋钮。另外页窗调度有个环境变量 SGLANG_UOCR_EANABLE_DOC_LIMIT，其中 EANABLE 是 README 原文拼写（不是笔误），照抄即可。
资源底线方面：参数量只有第三方报道口径——总参数约 3B、每次推理实际激活约 500M，官方未公布，多被解读为 MoE 结构，引用必须带口径。官方公布的测试环境是 NVIDIA A800-80GB，最低显存要求未公布；第三方有「12GB 消费级显卡可跑」的推算（1.77GB KV 缓存加约 3B 权重），未经官方确认，听听就好。仓库与公开检索均未发现官方 AWQ/GPTQ/int4 量化版本，「无官方量化版」目前成立。
八、短板与边界：官方自己承认的部分
先给诚实加分项：技术报告自认 MarathonDocBench 的 HeadingTEDS（标题层级）只有 48.20，是全部指标里最低的分项——稀疏注意力不保留全局信息，文档级结构理解受限，下一步方向是引入线性注意力。如果你的下游任务强依赖文档标题层级树，当前这一版要留个心眼。
单页精度也并非最强：OmniDocBench v1.6 得 94.02，只比一代高 0.1，同表还有 0.8B 到 4B 的专用 OCR 小模型更高（TeleOCR 96.91、OvisOCR2 96.47）。卖点在长度，不在单页精度——单页选型请回头看站内那篇六款横评。
再叠加前面说过的限定：MarathonDocBench 是自建基准无独立复现，效率数字均为自报。收拢成一句选型判断：手里有整本书、整卷财报、整套台账要一次性结构化，且能接受 A800 级起步或自行压测显存，Unlimited OCR 2 目前在开源阵营里几乎没有对手；如果只是单页票据、几页合同，它反而是杀鸡用牛刀。
常见问题
Q1: Unlimited OCR 2 在哪里下载？GitHub 和 Hugging Face 地址是什么？ 代码与权重已同步开源至 GitHub（仓库地址见文首），权重同步上架 Hugging Face 的 baidu/Unlimited-OCR-2 与魔搭社区的 PaddlePaddle/Unlimited-OCR-2，也可直接使用百度智能云与百度AI开放平台的托管服务。
Q2: Unlimited OCR 2 商用要付费吗？开源许可证是什么？ 仓库 LICENSE 为标准 MIT License（Copyright (c) 2026 Baidu），可商用、可修改、可再分发、可本地离线部署，唯一义务是保留版权与许可声明；MIT 自带的免责条款照常生效。
Q3: 跑 Unlimited OCR 2 需要多少显存？ 官方仅公布测试环境为 NVIDIA A800-80GB，最低显存要求未公布；第三方有 12GB 消费级显卡可跑的推算口径，未经官方确认。另外峰值 KV 缓存 1.77GB 不含模型权重，别直接按它换算显卡。
Q4: Unlimited OCR 2 和 PaddleOCR 等传统开源 OCR 有什么区别？ 传统管线按单页切分识别，Unlimited OCR 2 用 SR-SWA 稀疏注意力把上限推到任意页数，主打跨页表格合并与跨页段落接续；单页精度上它的 OmniDocBench v1.6 得分 94.02 反而低于部分专用小模型，选型先看你的文档长度。
Q5: Unlimited OCR 2 一次最多能解析多少页？ 官方定位为任意页数，实测演示过《哈利·波特》全七部累计超 3600 页、《四大名著》合订本 5026 页；但官方承认总耗时仍随页数增长，3600 页约一个半小时，不是无限快。