百度发 Unlimited OCR 2：3.3B 把长文档注意力压到 512 token，几百页不再崩
百度在 Hugging Face 放出 Unlimited-OCR-2，MIT 许可，权重 3.34B（BF16，仓库占用约 7.1GB），代码同仓挂在 GitHub 的 baidu/Unlimited-OCR。模型本体是 12 层、隐层 1280 的 MoE：每层 64 个路由专家取 6 个、另加 2 个共享专家，滑窗 128，最大位置编码 131072，视觉端沿用 deeplip_b_l。部署有两条路：Transformers 原生推理，或用官方定制的 SGLang wheel 起服务——后者支持按页窗口调度（默认每窗口 10 页）并复用上一窗口的 KV 尾部，把超长文档切成可管理的段。
它要解决的是长文档 OCR 的结构性瓶颈。上一代 Unlimited-OCR 在数十页的 MPDocBench 上还能打，到了数百页的 MarathonDocBench 综合分直接是 0——不是分数低，是跑不完。Unlimited-OCR-2 的做法叫 SR-SWA（Sparse Reference Sliding Window Attention）：把文本与视觉之间的注意力交互，从随页数线性增长的整段序列，压缩到一组固定大小的工作参考（模型卡举例 512 token）。计算复杂度因此被钉住，官方称每步解码的延迟与显存占用基本不随文档长度变化，二次注意力增长与显存瓶颈一并消掉。
数字来自模型卡里的排行榜图（本机两次独立读数一致）：综合分 MPDocBench 84.6、MarathonDocBench 77.1；同图里 Qwen3.8-Max 是 78.3 / 22.9，Qwen3.8-Flash-Next 是 77.4 / 27.8，Gemini-3.8-Flash 是 76.2 / 28.6。也就是说，数十页档它是小幅领先，数百页档是另一个量级。这些是百度自测口径，本轮没有找到第三方复现；分项里表格 TEDS 与公式 CDM 在数百页档掉得比文本多（89.5→71.1、89.4→67.8），说明「跑得完」与「每一栏都同等准」还不是一回事。
原文链接：百度 HF 模型卡 / GitHub