几百页扫描件还要拆开识别吗？百度新开源的Unlimited OCR 2能省哪一步

要是你平时只需要把一两张发票或者截图转成文字，现在手头顺手的工具就够用了，没必要特意折腾一趟新模型。但要是你在做文档整理工具，天天面对几百页的扫描版 PDF、旧档案或者长篇报告，要把它们变成能搜索、能整理的文字资料，常见的一种处理方法是：把文档拆成单页图片，分别送入模型识别，最后再写一套规则把识别出来的碎片拼回去。

拼回去听着简单，一旦遇到一句话跨了两页、或者一张表格从上一页延续到下一页，单页识别因为看不见前面的内容，拼出来的东西往往得靠人工再去缝补。

10月27日，百度在 Hugging Face 上开源了 Unlimited OCR 2（仓库名 `baidu/Unlimited-OCR-2`），3B 参数量，采用 MIT 许可。它替做工具的人省下的，就是拆开单页再硬拼这一步。

边读边留住前情，多页放进一次请求里

按照官方说明，这次的模型用了一套叫 SR-SWA 的新机制，把超长序列里的文字和图像交互压进一个固定大小的工作参照里。用日常看书来打比方，就像人一边往后读，一边在手头留住一小份有用的前情提要；哪怕文档越变越长，每往下读一步花的时间和占用的内存也能保持接近稳定。

落到实际调用上，官方给出的 PDF 处理示例是先把每一页转成图片，再通过多页接口（`infer_multi`）把按顺序排好的图片放在一次请求里直接交给模型。这样模型在认后一页的时候能用上跨页的上下文；吐出来的结果里，每一页会对应一个 `<PAGE>` 标记，顺序和塞进去的图片一致，省去了自己在外面写拼接逻辑的麻烦。官方在模型卡里也放了一段整本文档识别的回放供参考。

省显存和保上下文，得按手头的文档算笔账

看到长文档识别，很多人第一反应是摸摸自己的显卡。Linux.do 社区里有位用户聊起自己以前在 6GB 显存笔记本上部署第一代 Unlimited OCR 的经历：处理小图很快，但遇到大图超出处理窗口后，显存需求就明显往上走；所以看到二代发出来，这位用户也在问 6GB 显存能不能跑起来。

官方在文档里标出的验证环境是 Python 3.10 配一张 80GB 显存的 NVIDIA A800，这只是他们跑通测试的机器配置，没说是最低硬件门槛。不过真要往自己的机器上搬，模型卡里写明的一条取舍比宣传口号更值得留意：把页窗口调小可以降低峰值内存，但会损害跨页合并的效果，因为一旦内容跨越了窗口边界，模型就丢掉了前面的上下文。

这笔账就得按你手里的文档来算了。为了省显存把窗口缩得很小，结果跨页的表格、章节和延续到下一页的半句话全没接上，省下来的机器成本最后全变成人工校对的工时，那还不如最初老老实实拆单页。

接入看正文说明，别直接抄网页顶部的通用命令

我们顺手点开了官方挂在 Hugging Face 上的在线演示空间，页面还停在 Starting 状态，没法直接在网页上传文档试手。普通用户等平时用惯的文档软件接入，会更省事。

已经在做多页处理、自己会跑模型的开发者，现在就能去 官方模型卡 拿权重和看接入说明。这里有个很容易踩的小坑：以前我写后端接开源组件时，最喜欢直接复制代码托管页面顶部自动生成的两行启动命令，省事，但往往跑不通。这次也一样，Hugging Face 页面上方有个自动生成的“Use this model”按钮，点开给的是通用启动命令；但往下翻看官方写的正文就会发现，要是用 SGLang 做服务部署，得安装他们定制的 wheel 包，还要配专用的模板和参数。无论你是想用 Transformers 快速测一下，还是用定制 SGLang 部署服务，都直接从模型卡正文里的 Inference 章节看起。

手里正好有长扫描件整理需求的人，不妨先抽一份跨页情况复杂的真实文档跑一遍，重点盯三件事：吐出来的 `<PAGE>` 页序对不对、跨页的句子和表格接没接上、在自己的显存限制下窗口要调到多大才够用，试完这三样再决定要不要换掉手头原来的拆页方案。