个人电脑玩AI-08让5060 Ti给你打工——我拿 Unlimited-OCR扫了 600 页书然后悟了

前言：我拿 VLM 扫了 600 页书，然后悟了

先说结论——Unlimited-OCR 是我目前用过单页效果最强的文档解析工具，没有之一。 但如果你听信某些教程，去试它所谓的“多页批处理”接口，那大概率会在第 3 页就看着显存飙红、程序崩掉。正确且唯一有效的姿势，就是写个 for 循环，一页一页地喂，让它每页都“失忆”一次。 我就是用这种“笨方法”，在 5060 Ti 16G 上成功啃完了 600 多页排版爆炸的技术书，输出 Markdown 质量吊打 PaddleOCR 十条街。

下面把我的血泪经验全摊开，包括为什么必须逐页循环、怎么把 600 页跑稳、以及合并脚本怎么写，顺便吐槽一下那些“伪多页”的坑。

第一铁律：OCR 就是 OCR，别让它干编辑的活

这条是我用爆显存换来的教训，必须写在最前面：

PaddleOCR 这么干过，崩了；Unlimited-OCR 我也试过，加了 “请修正错别字”，单页推理从 5 秒变 30 秒，显存从 10G 飙到 15.8G，第三页直接 OOM。所以我的 prompt 永远焊死成官方原版：

prompt='document parsing.' # 多一个单词都不要！

错别字、逻辑问题，那是人眼和 LLM 的事，别在 OCR 这一步瞎操心。

为什么我抛弃 PaddleOCR，死磕 Unlimited-OCR？

PaddleOCR 快是快，但面对多栏、表格、公式，它吐出来的就是一坨“线性文字”——左栏读到一半跳右栏，表格变成空格分隔的灾难，公式全成乱码。我花在“修复结构”上的时间，比跑 OCR 本身还多。

而 Unlimited-OCR 是端到端的 VLM，直接输出带 Markdown 结构的文本：

• 标题自动分层（#、##、###）
• 表格转成标准 Markdown 表格
• 公式转成 LaTeX 风格（$...$）
• 多栏自动分左右，不串行

单页效果简直是艺术品。但问题来了——怎么把艺术品安全地拼成 600 页的“连环画”？

大坑：官方“多页模式”是个纸老虎

我在网上看到有人吹 Unlimited-OCR 可以直接传 PDF 路径，内部自动处理多页。于是我也试了试，结果：

• 显存爆炸：一次性加载所有页面，16G 根本 hold 不住，跑到第 10 页就 OOM。
• 输出混乱：即使侥幸跑完，输出的 Markdown 把所有页面揉在一起，标题序号错乱、表格断页、公式跨页分裂，根本没法用。
• 速度感人：内部 batch 推理没做优化，比单页循环还慢。

后来翻源码才明白，官方那个“多页”其实就是把 PDF 转成图片列表，然后 for 循环调用同一个模型——但它没有做任何显存管理和输出聚合，效果还不如我们自己写循环。所以我的结论是：

我的“笨方法”：逐页循环，稳如老狗

既然官方靠不住，那就自己动手。我的完整流水线如下：

1. PDF 转图片（用 PyMuPDF 或 pdf2image）

import fitz# PyMuPDFpdf = fitz.open("book.pdf")for page_num in range(len(pdf)):page = pdf[page_num]pix = page.get_pixmap(dpi=200)pix.save(f"page_{page_num+1:03d}.png")

2. 逐页调用 Unlimited-OCR（千万别开任何“批处理”参数）

for page_num in range(1, total_pages+1):img_path = f"page_{page_num:03d}.png"model.infer(tokenizer,prompt='document parsing.', # 焊死！image_file=img_path,output_path=f"./output/page_{page_num:03d}",base_size=1024,image_size=640,crop_mode=False,# 书本排版整齐，关掉更省显存max_length=32768,no_repeat_ngram_size=35,ngram_window=128,save_results=True,)# 每页跑完清一下缓存，防止碎片堆积torch.cuda.empty_cache()

关键点：

• 每页独立输出一个 .md 文件，文件名带页码。
• crop_mode 我关掉了，因为书本排版规整，切块反而容易出边界幻觉，而且费显存。
• 每页推理完手动清缓存，保证显存曲线平稳。

3. 合并脚本（灵魂所在）

光输出一堆碎片文件没用，必须合并成一本完整的 Markdown。我的合并脚本做了这几件事：

• 按页码顺序读取所有 .md 文件。
• 重新编号标题：因为每页的 # 都从 1 开始，所以要全局统计，把 # 1. 变成 # 1.，第二页的 # 1. 自动变成 # 2.，子标题同理。
• 拼接跨页表格：如果上一页末尾是 |--- 且下一页开头是 |---，说明表格被切断，合并成一个大表格。
• 处理图片引用：把每页内的图片路径统一改成相对路径（比如 ![img](./page_001_01.png)）。

整套脚本跑完，600 页直接变成一个 5MB 的 book.md，导入 Obsidian 后大纲清晰，搜索公式、跳转章节丝般顺滑。

为什么逐页循环反而比“批处理”更好？

1. 显存可控：每页处理完释放，不会累积。
2. 输出干净：每页独立，合并脚本可以精准控制标题编号和跨页元素。
3. 容错性强：万一某页崩了，只需要重跑那一页，不用全部重来。
4. 可以并行：如果你有多张卡，可以分页并行跑，但我一张 5060 Ti 串行也够用。

给后来者的终极忠告

• 千万别用官方任何“多页”或“批量”参数，那都是坑。老老实实 for 循环。
• Prompt 打死不加戏，就 document parsing，别想着让 OCR 做总结。
• 合并脚本值得投资，写一次，以后所有书都能复用。
• 5060 Ti 16G 在这个场景下非常够用，别被那些说“必须 A100”的吓到。

最后，为“单页循环”正名

有人说“逐页循环太 low，不够智能”，但我想说——在 GPU 资源有限的情况下，稳定、可控、高质量，比花里胡哨的“原生多页”重要一万倍。 我用这套流水线处理了 600 页，成果是一份可以直接出版级的 Markdown 文档，而某些“高级批处理”可能连 50 页都跑不下来。

所以，如果你也想用 Unlimited-OCR 处理多页文档，别犹豫，直接上循环。代码我都给你备好了，拿去抄就行。

本章代码（含 PDF 转图、逐页 OCR、合并脚本）已上传至 Gitee