3600 页文档一次读完，显存从 47GB 压到 1.77GB：百度开源 Unlimited OCR 2，MIT 协议、单卡能跑

做长文档处理的人都撞过同一堵墙：一页一页识别都不会错，拼起来就散了。跨页的表格被页码拦腰截断，接了两页的段落要从中间对一遍，标题层级直接丢光。这不是模型认字不准，是切块的时候上下文就断了。

百度 10 月 27 日开源的 Unlimited OCR 2，冲的就是这件事。

它做了什么

代码在 GitHub 的 baidu/Unlimited-OCR，权重在 HuggingFace 的 baidu/Unlimited-OCR-2，MIT 协议，可商用。模型卡标 3B 参数量，约 500M 激活。
核心是 SR-SWA（稀疏参考滑动窗口注意力）：先把每个查询要看的视觉范围从整份文档缩到相关的几页，再在里面挑得分最高的视觉 token，文本与视觉的注意力交互被压到一组固定大小的工作参考里（官方举例 512 个 token）。计算复杂度因此有界。
配上「无限视界解码」：文档按块顺序处理，块与块交界的那页复用 KV 缓存，处理完的窗口直接释放。
官方实测：单序列峰值 KV 缓存 47.00GB → 1.77GB，降 96.2%；16 并发吞吐 360 TPS → 1315 TPS；单步解码比全注意力快 7 倍，比上一代 R-SWA 快 5.6 倍。

两个基准，都要看清是谁的榜

MPDocBench（几十页级）：84.6 分，第二是 Qwen3.8-Max 的 78.3。
MarathonDocBench（百页级）：77.1 分，第二是 Kimi-K3 的 33.7，上一代 Unlimited OCR 是 0.0。这个榜是跟模型一起发出来的，出的也是百度。
差别集中在百页以上：几十页这档各家都在 60 到 78 分，上了百页，多数通用模型掉到二三十分。原因不复杂——视觉 token 超了上下文窗口，只能切块拼，跨页结构一拼就丢。

对你意味着什么

假设你手上有个活：一批 300 页的合同或年报，要抽条款、抽表格、抽金额。

老办法是按页调通用模型，每页一次请求，回来自己写规则拼。300 次请求、300 次拼错的机会，跨页表格基本靠人补。
新办法是 infer_multi 一次传 300 张图，模型自己带跨页上下文，输出按页顺序带标记。输出预算官方给的是每页 8000 token（可调到 20000）乘页数，300 页就是 240 万 token 的输出上限。按每百万输出 10 美元的中档价粗算，一次大约 24 美元。
自己部署：BF16 权重约 6.7GB，加 1.77GB 的单序列 KV，不到 9GB。一张 12GB 的消费级显卡装得下，剩下的留给并发。

这就是它的位置：不是”更聪明的模型”，是把一件按页计费、按页出错的事，改成按份计费、一次出错。

泼冷水

两个榜都是官方自测，MarathonDocBench 还是百度自己发布的。评测脚本开源、可以复现，但”专用选手对通用选手”的对比，本身就不太公平——那几家通用模型不是为百页 OCR 调过的。
官方 README 的测试环境是 NVIDIA A800-80GB，没有消费级显卡的实测数据。“12GB 卡装得下”是按参数量和显存占用算出来的，不是跑出来的。
显存有界不等于不用调参。SGLang 部署里 SGLANG_UOCR_DOC_GUNDAM_PAGE_WINDOW=10 是页窗口，窗口越小峰值显存越低，但跨窗口的表格和段落会丢上下文——这正是你要的跨页合并。官方自己也写了这个 trade-off。
每页输出仍有 20000 token 上限。扫描件质量差、公式密、表格碎的文档，体验会很不一样。
生产可用版本还在公测（百度智能云 / AI 开放平台），开源权重面向的是探索。

怎么开始

别一上来就换掉现有管道。先挑 5 份你最脏的真实文档（带跨页表格、带跨页段落的那种），用 infer_multi 跑一遍，跟现在的结果逐块比。
比对时只看两件事：跨页表格有没有被合并成一张，标题层级有没有恢复。文字识别率这一项大家都够用，不构成差异。
要部署服务就用官方推荐的 SGLang 定制 wheel，mem-fraction-static 设 0.7（0.75 在 32 并发以上会不够），页窗口先给 10，再看你的文档类型往上调。
算成本的时候把显卡租金和”人工补跨页”的时间一起算。省下的如果只是几美元 API 费，而你还得自己运维一套推理服务，那不划算；值钱的是那部分原本要人补的结构。