PDF 一页一页喂 OCR 早过时了：百度开源 Unlimited-OCR，3.3B 参数一次吃下几十页

一份 40 页的 PDF 摆在你面前。常规操作是切成 40 张图，一张一张塞给模型，跑完再把 40 段文字拼回来。中间那个跨页表格，表头在第一页，数据落在第二页，拼完一看，全错位了。这活儿不少人干过，骂完还得接着干。

说白了，这事怪不到你手上，问题在工具的设计。业内把 LLM 当 OCR 的解码器，图的是语言先验：模型认识合同这两个字，就不会把它认成别的。结果呢，输出越长，KV cache 越大，显存往上飙，token 一个一个往外蹦，越到后面越慢。

这里有个挺荒唐的对比。人抄几十页，抄到第 50 页不会比第 1 页慢，手累了也就慢一点点。模型会，而且是稳定地、可预测地越来越慢。百度这次开源的 Unlimited-OCR 就是冲着这个别扭来的。截至 10 月下旬，GitHub 上 28,422 星，MIT 协议，Python 写的，6 月 18 日建库，10 月 23 日还在推新代码，Trending 日榜上挂着 trendshift 徽章。

先说结论：慢的根源在解码器，跟硬盘没关系

PDF 解析慢，很多人的第一反应是文件大、硬盘慢、网络卡。都不是。瓶颈卡在解码这一步。

现在的 OCR 模型大多是编码器加解码器的结构。编码器把整张图压成特征，解码器再一个字一个字往外吐。每吐一个 token，都要回头把前面所有已经吐出来的 token 看一遍。这份回看的记录就是 KV cache。文本越长，记录越厚，显存占用跟着涨，每一步的计算量也跟着涨。

凭什么你抄到第 50 页还是那个速度，模型却越写越吃力？论文摘要把这个代价说得很直白：业界普遍认为拿 LLM 当解码器可以借语言先验提分，代价就是输出越长 KV cache 越大、显存上涨、生成越来越慢。提分是真的，越来越慢也是真的。麻烦在于这个代价一直被当成必需品。

而且这笔账会一路传导到工程侧。显存不够，就只能一页一页切；一页一页切，上下文就碎；上下文碎了，后面的检索、问答、归档全得替它擦屁股。绕了一大圈，成本一点没少，只是从模型那头挪到了人这头。

百度下了狠手：R-SWA 把 KV cache 锁死

百度在论文里提的机制叫 R-SWA，全称 Reference Sliding Window Attention，参考滑窗注意力。做法很干脆：解码器里所有的 attention 层，全换掉，一个不留。

换完之后，每个新 token 只在一个固定大小的窗口里看，再配一份参考信息，不用再跟全量前文做注意力。窗口大小是常数，那么整个解码过程中 KV cache 的大小也就是常数。写得再长，占用不涨，速度不掉。

这就像抄书时把要用的那几页摊在桌上，写完一个字只挪一下视线，不必把整本草稿从头翻一遍。人这么干了几千年，模型直到现在才把这一招学过去。

论文还说 R-SWA 是个通用的解析注意力机制，ASR、翻译这类长输出任务一样能套。这句话的分量，其实比模型本身的跑分更值得记一笔。

还要看清一点：这是把解码器的骨架换了，不是在外面加个补丁。补丁调参，骨架改命，两件事的量级差得远。

真正的爽点：几十页文档当一次任务

光有恒定 KV cache 还不够，得吃得下才行。Unlimited-OCR 配的是 DeepSeek-OCR 的编码器，压缩率高。官方 README 给的说法是，在标准的 32K max length 下面，一次前向传播就能转写几十页文档。

注意是一次前向传播，不是循环。传统管线是喂一页、出结果、清空状态、再喂下一页，跨页的上下文天然断掉。Unlimited-OCR 把多页当成一个任务，页与页之间的关系还留在模型手里。表头和数据分家的那种表格，终于有机会被整体读懂。

多页推理的调用方式，README 里写得很清楚：

model.infer_multi(tokenizer, prompt='<image>Multi page parsing.', image_files=pdf_to_images('your_doc.pdf', dpi=300), output_path='your/output/dir', image_size=1024, max_length=32768, no_repeat_ngram_size=35, ngram_window=1024, save_results=True)

PDF 先转成图，用 PyMuPDF，dpi 给到 300。这里有个约束要记住：多页和 PDF 只能用 base 模式，也就是 image_size 1024、不切块那一套。单张图想提精度可以换成 gundam 模式，base_size 1024、image_size 640、crop_mode 打开，代价是切块会带来更多 token。

上手成本：一张卡加几条命令

部署给了两条路。想省心走 vLLM，镜像都备好了：vllm/vllm-openai:unlimited-ocr 是 CUDA 13.0 版，Hopper 卡用 unlimited-ocr-cu129 那个。

想自己搭就走 SGLang。用 uv 建一个 3.12 的虚拟环境，装本地 wheel、kernels、pymupdf，然后起服务：

python -m sglang.launch_server --model baidu/Unlimited-OCR --served-model-name Unlimited-OCR --context-length 32768 --port 10000

服务起来后走 OpenAI 兼容的 /v1/chat/completions 接口。长文档这里有个坑必须填：请求里要带 custom_logit_processor，也就是 DeepseekOCRNoRepeatNGramLogitProcessor，ngram_size 35、window_size 1024，专门防模型在长文里复读。

批量的活更省事，一条命令扫一份文件或一个目录，–image_dir 是另一条入口：

python infer.py --pdf ./examples/document.pdf --output_dir ./outputs --concurrency 8 --image_mode gundam

环境这块老实交底：要 NVIDIA GPU，Python 3.12.3 配 CUDA 12.9 是测试通过的组合。最低显存门槛 README 没写，这块只能自己试，或者以官方 README 为准。手边没卡又想先跑通流程，云端方案能顶一阵，比如LlamaParse 把文档喂给 RAG这种，丢给 API 就拿回结构化结果，代价是数据出家门。

别急着欢呼：Unlimited 这名字有水分

名字叫 Unlimited，听着像能一直喂。清醒一点：max_length 32768 是硬上限，不是无限页。能塞多少页取决于每页压成多少 token，几十页是官方口径下的量级，不是承诺。

输出也得处理一下。结果里带版面标记，形如 <|det|>类型 [坐标]<|/det|>，要当纯文本用，得先按 README 里的 remove_det 正则清洗一遍，否则那些坐标会混进你的语料。

评测数字更别横着比。omniDocBench 这类基准在跑之前要做后处理，各家的清洗规则不一样，分数摆一起比容易失真。

话说回来，名字有水分，技术是真的。百度动的是 attention 层的骨架，跟营销词没关系，论文里的说法摆在那里，能不能复现自己跑一遍就知道。

该不该换：三个场景说清楚

换不换，看你的活儿长什么样。

• 要跨页结构：合同、财报、论文这类表头和数据分家的文档，一次前向传播的价值最大，上下文不会在页与页之间裂开。
• 要批量离线：手里几千份 PDF 等着转成可检索文本，并发 8 配上恒定的 KV cache，显存和耗时都好估算。
• 只要单张图：拍张发票、截个屏，专用小模型更便宜也更快，没必要为一张图扛起 3.34B。

想横向看看别人的路子，也有两条对照。大模型顺手把 OCR 一起干了，比如GPT-5.6 Sol 把 OCR 和检测计数干成一个模型，好处是一个模型通吃，坏处是长文档的成本不透明。商业文档解析是另一条线，Upstage 的文档 AI走的是打包好的服务，省事，但按量付钱。

收个尾：现在就能动手的那一步

回到开头那个场景。40 页 PDF 切成 40 张图，拼回去表头丢了。这个流程今天就可以换掉。

一个人一天能校对的页数是有天花板的，切页拼回来的错位，最后都要人眼去补。这笔账很少有人认真算过，但它每个月都在发生。

Unlimited-OCR 真正的改动在成本结构上，不在识别精度里多抠那一个点。KV cache 恒定，意味着你喂多长，代价都落在一个可预期的框里。对做文档流水线的人来说，这比跑分涨两个点实用得多。

版本节奏也够密：6 月 22 日发 1.0，6 月 23 日论文上 arXiv 并上架 ModelScope，6 月 24 日 HF Spaces 挂出在线 demo，6 月 28 日支持 vLLM 推理，7 月 3 日上百度云，7 月 21 日接上 ms-swift 训练。ModelScope 官方模型卡上，3.34B 参数、权重单文件 6.67GB 的 BF16，下载量 35.4 万，多语言。

想先看效果，HF Spaces 那个 demo 不用部署。想接进自己的管线，上面那条 SGLang 命令抄下来就能起。别一页一页切了，真没必要。

关注圈圈，持续带你玩转 AI 工具。