10 月 26 日，百度在 Hugging Face 开源了 Unlimited OCR 2，一个 3.34B 参数的 OCR 模型，专门处理几百页的长文档。在 MarathonDocBench 上它拿到 77.1 分，第二名 Kimi-K3 只有 33.7 分。
稀疏注意力把长文档成本压平
全文注意力随序列长度平方增长，文档一长，每个新 token 都要扫更长的 KV cache。Unlimited OCR 2 用的是 SR-SWA 稀疏参考滑窗注意力，把文本与视觉的注意力压缩到固定的 512 个工作参考上，配置里是 128 token 局部窗口加 top-16 选块，每块 32 token，正好凑满 512。多页模式下每页固定消耗 273 个图像 token，100 页就是 27300 个输入 token，而每步解码的延迟和显存几乎不随页数增长。模型最大上下文 131072 token，BF16 权重约 6.7 GB，单卡 A800-80GB 就能跑起来。
分数很好看，短板也明显
百度在 MPDocBench 上拿 84.6 分，排在 Qwen3.8-Max 的 78.3 和 Qwen-3.8-Flash-Next 的 77.4 前面。换成 MarathonDocBench，领先幅度拉大到 77.1 对 33.7，后一位是 Gemini-3.8-Flash 的 28.6。真正的差别在长文档衰减，Qwen3.8-Max 从 78.3 掉到 22.9，Unlimited OCR 2 只掉 7.5 分，它的上一代 Unlimited-OCR 在 MarathonDocBench 上是 0.0 分。子项里标题层级识别最弱，TEDS 只有 48.2 分，表格 74.8 分，读序 85.3 分。官方也提醒，所有数字都出自自家排行榜图表，属于自报结果。模型采用 MIT 协议，配套的代码托管在 GitHub。
部署上有两条路。Transformers 直接加载，跑单页用动态切图的 gundam 模式，跑整份文档用 infer_multi，一次请求解析所有页面并保留跨页上下文，代价是需要开 trust_remote_code。SGLang 那边用的是百度定制 wheel 而非上游版本，官方示例按每个窗口 10 页调度，复用上一个窗口的 KV 尾部，窗口开小能压峰值显存但会削弱跨页合并。官方还提醒一个默认 bias 配置可能触发 462 MiB 的额外分配导致显存耗尽。
MIT 协议加上 3.34B 的体量，长文档 OCR 这一格的入门门槛又降了一层，文档提取相关的能力对比可以参照 Cloudflare Clairic 的文档提取实测。
延伸阅读
- 百度Unlimited OCR 2开源：3.34B模型百页文档77.06分，显存降26倍8 小时前
- 苹果 AI 中国落地：阿里百度双轨供货，12 月 iOS 27.3 上线2 周前
- 百度健康 MAU 超 5000 万，接入 15 万三甲真人大夫3 天前
- 苹果 AI 中国落地路线浮现：12 月 iOS 27.3 上线，首批阿里百度合作2 周前
继续读
同一批更新里这几篇值得一看：
- 百度健康 MAU 超 5000 万，接入 15 万三甲真人大夫2026-10-25
- 苹果 AI 中国落地路线浮现：12 月 iOS 27.3 上线，首批阿里百度合作2026-10-15
- 百度Unlimited OCR 2开源：3.34B模型百页文档77.06分，显存降26倍2026-10-27