几百份文档一起跑，崩在哪

单份跑得很好，一上批量就出问题：GPU 空转、内存一路涨到炸、进程无声消失、整批任务报废。这不是你不会用，是多数解析项目本来就没按「批量」设计。这个专题把开源项目里开发者自己报的问题摊开，再给一套能跑通的分批 + 队列 + 校验搭法。

相关搜索：批量 文档 解析 · 批量 OCR · 扫描件 批量 识别 · PDF 批量 转 markdown · 文档 批处理 队列 · MinerU 批量

用户到底在抱怨什么

底层就是逐页 for 循环，批量只是排更长的队

有人翻源码后确认：解析项目把每一页当独立单元，按顺序一页页处理，没有并行。想加并行也不容易——模型加载和参数传递层层耦合，作者自己说很难拆。所以「批量处理」在多数项目里不是加速，是把同一段耗时重复几百遍。

仅使用 Layout + OCR 按顺序处理每页，速度还是非常不理想的……这几乎没办法拆分成并行结构 —— MinerU issue #570：分页并行以及模块化处理（2024-09）

花了钱上 GPU，利用率只有 3%

有人在 L4 上跑 Docling 处理长 PDF：显存只用了 1.4G，GPU 利用率卡在 3%，调多少线程都没用。原因是解析链路的瓶颈不在矩阵运算，而在图像预处理、版面后处理这些 CPU 环节——买更快的卡，解决不了排队问题。

it only uses 1.4GB of VRAM and is stuck at 3% GPU utilization regardless of the num_threads I use —— Docling issue #1304：Docling is unusable on long PDFs with CUDA（2025-04）

中文 OCR 那一步偷偷跑在 CPU 上

一位用户查了半天才发现，最耗时的 OCR 检测阶段根本没走 GPU：部署在 GPU 上，但这个环节仍然在 CPU 上跑，于是几百份扫描件的耗时被这一小段拖死。批量任务里，一个环节没走对设备，整体吞吐就是它说了算。

gpu下部署ocr-det ch 这个处理特别耗时，并且看显存占用，发现执行这个操作时，没有走GPU —— MinerU issue #3285：ocr-det batch 推理与 torch 版本兼容问题（2025-08）

想多卡并行，得自己写一个服务

项目本身没带批量服务，社区里有人自己基于 LitServe 写了一个多 GPU 并行的解析服务，当作方案提交上来。也就是说：想要「一次丢进去几百份、自动排队并行」这件事，在开源方案里通常是你自己写的那一层。

批量处理的话大家只需要简单的多线程调用客户端的 do_parse 函数就可以了，服务端会自动在多个 GPU 上并行处理 —— MinerU issue #667：一个服务化的可多 GPU 并行处理的方案（2024-09）

内存不是跳一下，是一路涨到炸

把解析包成 FastAPI 服务、跑在 docker 里之后，有人发现内存占用随文档数量持续增长，直到 OOM——注意是内存（RAM），不是显存。批量场景下这几乎是必然：模型、图像缓存、中间结果都在进程里堆着，不在每份文档后释放就一定会炸。

RSS grows unbounded across documents until OOM —— MinerU issue #5313（2026-07）

进程静默消失，整批任务全废

最难受的一种失败：长文档跑到一半，主进程直接没了，没有 traceback、也没有 Killed 日志，客户端只看到连接被拒。同一份文档、同一套配置，只是页数不同结果就不同。批量任务的容错必须按「随时会死」来设计：单份隔离、断点续跑、缺页即报错。

主进程直接消失，没有任何 traceback、没有 Killed 输出。任务全部报废，客户端只能看到连接失败 —— MinerU issue #5488：长文档解析崩溃（2026-09）

能解决这些痛点的开源项目

• MinerU（本地离线）— 中文扫描件与复杂版式的解析主力。要点不是它多快，而是它输出结构化结果、能本地跑；批量时按「每批 N 份起一个进程」用，别在一个进程里循环几百份。 痛点标签：中文文档、检索/识别准、本地离线、不限条数、批量稳定。注意：长文档存在整进程崩溃的已知问题，必须外部守护 + 分批，别拿它跑无人值守的大批量。
• Docling（本地离线）— IBM 出的文档解析，表格和阅读顺序做得细，Docker 部署干净，适合把 PDF/Word/PPT 统一成结构化输出。 痛点标签：本地离线、检索/识别准、中文文档。注意：长 PDF 上 GPU 利用率极低（实测 3%），批量要靠多进程而不是多线程。
• PaddleOCR / PP-StructureV3（本地离线）— 中文 OCR 与版面还原的底座。批量的正确姿势是自己写一个「读目录 → 逐页识别 → 落 JSONL」的小脚本，而不是指望某个 App 的批量按钮。 痛点标签：中文文档、检索/识别准、本地离线、批量稳定、不限条数。注意：检测/识别/版面是三个模型，参数多；中文表格要单独开结构化管线。
• LitServe（自托管）— 把解析函数包成一个能吃并发请求的服务，自动在多个 GPU 上排队执行——社区里给 MinerU 做多卡批量，用的就是它。 痛点标签：批量稳定、部署简单、团队共享。注意：只负责调度，不解决模型本身的内存增长；worker 仍要定期重启。
• Dify（自托管）— 把「入库 → 解析 → 抽取字段 → 输出表格」固定成工作流，失败可重跑单条。批量的编排和重试在这里做，别塞进一个脚本里。 痛点标签：部署简单、团队共享、批量稳定。注意：工作流引擎不是队列系统，几千份的吞吐要自己接消息队列。

常见问题

几百份一起跑，怎么才不崩？

三条：① 分批，每批 20~50 份，批与批之间重启 worker 进程（内存增长靠重启清）；② 单份隔离，一份失败不影响整批；③ 每份输出带页码校验，缺页就判失败，绝不静默继续。跑批的可靠性靠这三条，不靠模型更强。

GPU 一直空转，是不是白买了？

解析类任务的瓶颈常在 CPU：图像预处理、版面后处理、PDF 渲染。解法是多进程 + 每进程绑一张卡，而不是换更贵的卡。先测「每页耗时里 GPU 占多少」，再决定要不要加硬件。

要不要直接用云 API？

看你上传的是什么。公开论文、产品手册，云 API 省事；合同、病历、财务凭证，数据出网这条就过不了。另外云 API 按页计费 + 排队，量大时自建通常更便宜，前提是你有人维护队列。

一天能跑多少份？

没有通用答案，而且别信厂商的 QPS 数字。用你自己的 50 份样本实测：记录每份页数、是否扫描件、耗时和峰值内存，再按你的机器线性推算。扫描件和文本型 PDF 差好几倍，混在一起算就是自欺。

解析完了，怎么确认没漏页、没错序？

每页输出必须带 page_index，最后比对「原 PDF 页数 = 输出页数」；表格另存结构化结果，别只留文字。漏页是最常见的静默错误——它不会报错，只会在三个月后让你在知识库里搜不到那一条。

最后更新 2026-11-06。内容基于公开讨论与项目公开文档整理，不构成采购建议；价格与配额随时可能变，下单前请自行核对。