百度开放 Unlimited OCR 2：单请求解析上百页文档，SR-SWA 与定制推理栈值得先验证什么
据 MarkTechPost 2026 年 10 月 26 日报道，百度发布 3.34B 参数的 Unlimited OCR 2，权重以 MIT 许可发布，用 SR-SWA 把注意力压到固定参考集以支持单请求数百页解析，自报 MarathonDocBench 77.1 分。
发生了什么
据 MarkTechPost 2026 年 10 月 26 日报道，百度发布 Unlimited OCR 2，一款面向超长文档的 OCR 视觉语言模型，权重按 MIT 许可在 Hugging Face 发布，代码托管在 GitHub，接替 2026 年 6 月的 Unlimited-OCR。报道称其规模为 3.34B 参数，激活参数量未披露，最大位置长度 131,072 token；BF16 权重约 6.7 GB，百度在单块 NVIDIA A800-80GB 上测试。结构沿用 DeepSeek-OCR 风格：SAM ViT-B 加 CLIP-L 编码器接入 12 层混合专家解码器，每 token 路由到 64 个专家中的 6 个，另加 2 个共享专家。核心变化是 SR-SWA（稀疏参考滑动窗口注意力），把文本-视觉注意力压缩到固定工作参考集上；报道引述模型卡示例规模为 512 token，配置将 128 token 局部窗口与在 32 token 块上做 top-16 选择结合。报道称这让每步解码延迟和内存占用随文档增长近乎恒定，但图像编码和总运行时间仍随页数上升；多页模式下每页消耗 273 个图像 token。基准方面，报道称百度在公开的 MPDocBench-Parse（433 份文档、3,246 页）与 MarathonDocBench（数百页）上测试，并称未找到 MarathonDocBench 的公开发布版本；按百度排行榜图表，Unlimited OCR 2 在 MPDocBench 得 84.6、MarathonDocBench 得 77.1，对照模型在后者最高为 33.7，前代 Unlimited-OCR 在 MarathonDocBench 上为 0.0。全部数字为百度自报，报道称仅以一张图表图片呈现。子项中最低的是标题层级（TEDS），MarathonDocBench 上为 48.2；表格项从 MPDocBench 的 87.8 降到 74.8。运行方式上，模型卡列出 Transformers 用于快速测试（infer 处理单页，infer_multi 在一次请求中解析全部页），服务端使用百度定制 wheel 的 SGLang 而非报道所称的上游 SGLang；加载需要 trust_remote_code=True，会执行仓库中的 Python 代码。报道还提到百度示例每窗口调度 10 页并复用上一窗口的 KV 尾部，窗口越小峰值内存越低但跨页合并越弱，以及默认 bias 设置可能触发 462 MiB 分配并导致内存不足的警告。报道未交代 GitHub 仓库代码采用何种许可证。
对开发者的影响
对开发者的含义可分几层，多数仍需自行验证。第一层是显存与页数上限的估算方式变了：按报道描述，SR-SWA 让单步解码成本不随页数线性增长，因此在固定显存预算下，限制单请求页数的主要因素更可能转移到图像编码开销、KV 尾部占用与窗口调度，而不再是注意力的二次增长；这对书籍、申报文件、年报这类高页数、低交互的离线批处理有实质意义。但报道同时明确，总运行时间仍随页数上升，所以对要求逐页快速返回的在线场景收益有限。第二层是推理栈的锁定风险：服务路径是百度定制 wheel 的 SGLang，报道用“而非上游 SGLang”来描述这一差别，说明它是一个需要单独维护的厂商分支；若团队现有镜像、版本冻结与回滚流程围绕通用推理框架搭建，接入意味着多一条需跟进的依赖线。模型卡还列出 Transformers 路径，可作为功能验证的入口，但它不是生产服务方案。第三层是许可与安全的区分：权重按 MIT 许可发布，这是许可证层面的宽松授权，不能与“仅开放权重”混为一谈；不过报道只说明权重许可，未交代 GitHub 仓库代码的许可证，代码复用不宜直接按 MIT 处理。另外，MIT 覆盖的是授权范围，不等于对 trust_remote_code=True 所加载代码的安全背书，后者会把仓库里的 Python 代码执行进进程，在有审计要求的环境里通常需要先做代码审查与隔离运行。第四层是评估口径：报道显示 MPDocBench 上各家单项差距很小，举例文字项 94.8 对 94.3、公式项 89.4 对 89.2，差距主要集中在数百页的 MarathonDocBench；因此选型判断应基于自身文档的页数分布，而非总分排序。标题层级 48.2 与长文档表格 74.8 这两项短板直接关系章节树与表格入库的下游质量，需要在自有样本上单独测量。
接入与评估建议
以下为条件化建议，不是报道事实。决策一：是否用 SR-SWA 换取长文档吞吐。触发条件是单次任务经常达到上百页；若文档普遍在十页以内，报道中 MPDocBench 的单项差距很小，切换理由不足。可执行的判断是把自有语料按页数分两档（二十页以内与一百页以上），在同显存机器上用 infer_multi 分别跑，记录单请求峰值显存、总耗时与每页耗时曲线；若百页档每页耗时随页数明显上升，说明瓶颈已经转到图像编码，此时应调整窗口页数，而不是继续加大单请求页数。决策二：推理栈先走 Transformers 还是定制 SGLang。前提是团队现有推理服务栈与厂商 wheel 是否兼容；若镜像与回滚流程无法接纳定制的 SGLang，就先用 Transformers 做功能与精度验证，并把单卡单位时间可解析页数能否填满批处理窗口作为门槛；若能接纳定制 wheel，按报道提到的风险点压测：以示例的 10 页为起点逐步缩小窗口观察峰值内存，并检查默认 bias 触发的 462 MiB 分配是否造成内存不足，把“无内存不足失败”作为通过硬条件。决策三：结构化输出的验收标准要单独设。报道显示标题层级在长文档上仅 48.2、表格项降到 74.8；若下游依赖章节树或表格入库，应先准备带标题层级与表格标注的自有样本，按页数分档测这两项，再决定是否叠加人工复核或后处理规则。决策四：把 trust_remote_code=True 纳入上线前置检查，在隔离环境中先跑通并审查仓库代码，同时向百度确认仓库代码的许可条款，再决定是否进入生产。以上判断都应以自有标注集的误差为准，而不要以厂商总分为准。
限制与待确认事项
报道中的性能数字几乎全部来自百度自报，且报道称仅以一张排行榜图表图片呈现，没有可独立复现的评测细节；MarathonDocBench 被描述为数百页基准，但报道明确说未找到其公开发布版本，因此 77.1 以及对其他模型的对比都无法在外部复核。激活参数量未披露，无法据此推算实际推理算力或吞吐。报道只说明 BF16 下单卡运行、权重约 6.7 GB，未提及量化版本，能否在更小显存设备上部署无法从现有信息判断。截至本次目录核查时间，Unlimited OCR 2 这一版本未出现在 KimiSeek 的模型目录中；报道提到的 Transformers 与定制 SGLang 是指模型仓库与厂商材料的自行部署路径，不表示该模型已在 KimiSeek 上线，报道也未提及任何厂商托管服务或计费方式。若之后出现托管服务，其可用性与价格应以其官方文档与定价页面为准，价格可能变化。报道中关于 trust_remote_code=True、默认 bias 可能引发内存不足、以及定制 SGLang 的提示均来自厂商材料，未经第三方验证；GitHub 仓库代码的许可证也未见说明。报道引用的对照模型名称和基准版本较新，本文只转述其自报数据，不代表做过独立测试。