长文档别再逐页 OCR，我看成一条解析流水线

我最近看了百度开源的 Unlimited-OCR，第一反应不是“又出了一个 OCR 模型”，而是：长文档这件事，终于可以不再按截图一张张处理了。

很多材料处理的麻烦，不在识别那一刻。

真正耗人的，是 PDF 要拆页，长图要分段，结果要合并，失败要重跑，业务同事还会反复问：这批文件到底跑到哪一步了？一份材料还能手工兜底，几十页、几百页材料同时进来，靠人盯流程就很容易漏。

Unlimited-OCR 给我的启发，是把 OCR 从“识别能力”往前推了一步，变成一套文档解析流水线。

仓库里能看到几个很具体的入口：单图支持 gundam / base 两种配置；多页走 infer_multi；PDF 先用 PyMuPDF 按 300 DPI 转成页面图；SGLang 版本则把模型挂成 OpenAI-compatible streaming API。批量脚本 infer.py 还把图片目录、PDF 页面、并发数、重试、超时、结果落盘都放进了同一个流程里。

这不是一个“我点一下就识别”的小功能。

它更像一个可以被接入后台的材料入口：同一类文件进来，先转成标准页面，再进入模型，再按请求并发解析，最后落成可继续处理的结果。

论文里更底层的点，是 R-SWA。它试图解决长序列输出时 KV cache 不断增长、生成越来越慢的问题。摘要里写到，在 32K 最大长度下，模型可以单次前向转录数十页文档。这个说法我没有在本机复跑大模型，只把它当作论文和仓库公开材料里的能力边界来理解。

我更在意的是它留下的工程形状。

一个文档解析系统，最怕的是只有模型，没有秩序。输入格式不统一，服务入口不稳定，失败之后不知道重试哪一步，输出结果也不知道该落在哪里。Unlimited-OCR 的仓库虽然不大，但 README、论文、SGLang 服务示例和 infer.py 放在一起，已经把“从文件到结果”的路径画出来了。

这条路径对内部系统很重要。

因为老板和业务同事真正关心的，不是我们用了哪个注意力机制，也不是脚本里写了几个参数。他们关心的是：以后类似材料来了，能不能少找人、少解释、少返工；出了问题，能不能知道卡在哪一层；换一个人接手，能不能按同一套流程复跑。

对业务来说，这件事的价值不只是“识别率更高”。

它减少的是材料交接里的打断，降低的是人工拆页、拼结果、漏跑重跑的风险，留下的是一套可以复跑、可以迁移、可以被别人接手的流程。

所以我看 Unlimited-OCR，最重要的不是 OCR 三个字。

是长文档终于有机会从“人工处理一堆图”，变成“系统接管一条流水线”。