百度 Unlimited-OCR-2 支持单次读取多页 PDF，跨页表格可还原为一张

Unlimited-OCR-2 一次请求可读取多个 PDF 页面，因此跨页表格会作为一张表返回。下面看看它与逐页 OCR 相比表现如何。

对长篇 PDF 报告做 OCR 时，跨越两页的表格可能会被拆成两张独立的表，而不是一张。原因在于多数 OCR 模型一次只读一页，无法判断某一页上的表格是否延续到了下一页。

Unlimited-OCR-2 通过一次请求读取多页解决了这个问题，跨页表格会作为一张表返回。

它在长文档基准测试中得分不错，但基准测试未必总能反映真实文档的情况。于是我用一份长篇 PDF 报告做了实测，看看它在实践中表现如何。

💻 获取代码：所有示例的脚本都在 GitHub 上。

Unlimited-OCR-2 是百度开源的一款文档解析模型。它基于 DeepSeek-OCR 构建，规模与 DeepSeek-OCR-2 相同。两者的主要区别在于读取文档的方式。

DeepSeek-OCR-2 每次请求读取一页，而 Unlimited-OCR-2 一次请求读取多页：

让模型跨越分页符看到上下文，最直接的做法是让它在生成时查看每一页。但这样一来，模型每写一个词之前都要重读所有页面，对长文档来说会非常慢。

由于无论文档多长，它完整读取的波段数量都保持很少，所以随着页数增加，每个词的生成速度只会稍微变慢。在百度的测试中，100 页的文档里，每个词的生成速度比“读取每一页”的方案快 7 倍。

为了验证实际效果，我在几张跨多页的表格上分别运行了 DeepSeek-OCR-2 和 Unlimited-OCR-2。两个模型都基于 DeepSeek-OCR 构建、规模相同，因此输出的差异主要来自它们是否跨分页符读取。

Unlimited-OCR-2 可以通过百度的 Transformers 代码在 NVIDIA GPU 上运行，也可以通过 mlx-vlm 中的 MLX 转换在 Apple Silicon Mac 上运行。本文使用 Mac 方案，但两种方式输出的格式相同。

pip install mlx-vlm==0.7.11

在 NVIDIA GPU 上，请按照模型卡中的 Transformers 配置操作。

第一个测试最简单：给模型一张跨页表格所在的两页，看它能否识别为同一张表。

测试使用美联储的《2024 年度报告》，这是一份 214 页的报告，其中许多表格跨越分页符。表 5.3 从第 71 页开始，延续到第 72 页，表头重复出现。

像 DeepSeek-OCR-2 这样的逐页模型会分别解析每一页，因此这两页会返回两张表。第一张在第 71 页底部结束：

第二张以页面标题和表头作为普通行开头：

要使用这张表，你必须先删掉第二张表中多余的标题和表头行，然后自己把两张表拼接起来。

现在试试 Unlimited-OCR-2。在一次调用中把两张页面图像传给 mlx_vlm.generate，提示词为 Multi page parsing.：

mlx_vlm.generate --model mlx-community/Unlimited-OCR-2-8bit
--image p071.png p072.png
--prompt "Multi page parsing." --max-tokens 8000

这会为每张图像打印一个 <PAGE> 区块，每个区块包含一组块。模型用 append_table 标签表示第 72 页的表格是第 71 页表格的延续。

<PAGE> <- page 71 <BLOCK>table[144, 460, 855, 817]<FORK><table>... <PAGE> <- page 72 <BLOCK>append_table[145, 137, 855, 535]<FORK><table>... <- continues the table above

原始输出不易阅读，所以我使用百度的 Markdown 转换器。它利用 append_table 标签把两半合并成一张表。以下是分页符附近的行：

两半合并成一张表，中间没有重复的表头。

我们把测试加难一些，让模型处理一张跨越四页的表格（表 G.10）。

DeepSeek-OCR-2 返回四张独立的表，每页一张。

Unlimited-OCR-2 为全部四页返回一张表，只在 1986 和 1987 之间残留了一行重复的表头：

结果并不完美，但删掉一行远比清理并拼接四张独立的表省事。

分页符也会把段落切成两半。我们看看模型能否把它们重新接起来。

这个测试我换了一份报告。美联储《2025 年 6 月货币政策报告》中的这段文字在第 54 页停在 "highly accommodative"，并在第 55 页继续：

DeepSeek-OCR-2 让句子保持分裂，中间还插入了第 55 页的框标题：

...called for highly accommodative <- end of page 54 Box 4—continued <- box title repeated on page 55 monetary policy in response to the pandemic-driven recession... <- start of page 55

Unlimited-OCR-2 返回了一个段落，但丢失了分页处的空格：

...called for highly accommodativemonetary policy in response to the pandemic-driven recession... ^ space lost at the page break

我还测试了另外两处段落中断，Unlimited-OCR-2 都让句子保持分裂，和 DeepSeek-OCR-2 一样。所以段落合并似乎不如表格合并可靠。

到目前为止，我只给模型提供了某一处分页符附近的几页。实际使用中，你会发送报告的整个章节，让模型自己找出中断处。

下面测试模型在更长请求中找中断处的效果，每次请求分别发送年度报告中 10 页和 30 页的片段：

mlx_vlm.generate --model mlx-community/Unlimited-OCR-2-8bit
--image pages/p185.png pages/p186.png ... pages/p214.png
--prompt "Multi page parsing." --max-tokens 150000

每请求页数 | 识别出的表格中断 2 到 4 | 7/7 10 | 11/12 30 | 20/22

即使在 30 页的请求中，Unlimited-OCR-2 也识别出了大多数中断。

在搭载 M5 Pro 芯片的 MacBook Pro 上，30 页的请求耗时 3 到 5.5 分钟，内存峰值约 17 GB，因此无需 GPU 服务器，在笔记本上就能解析长篇报告。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）