让5060Ti打工：OCR扫600页书的AI心得

前言：用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.sa ve(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,sa ve_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处理多页文档，别犹豫，直接上循环。