Unlimited-OCR 实测评估：一次解析整本 PDF 的代价与边界

它解决的是长文档解析的痛点

传统 OCR 工具按页切分图片，逐页识别后再拼接，遇到扫描版书籍或多栏论文时，页与页之间的段落断裂、表格跨页错位是常态。Unlimited-OCR 的定位是 one-shot long-horizon parsing，也就是把整份文档作为一次输入，直接输出结构化文本。仓库的标语是 Welcome the Era of One-shot Long-horizon Parsing，这个目标很明确：省掉分页、合并、后处理这些繁琐步骤。它面向的是文档密集型工作流，比如法律卷宗、学术论文、技术手册的数字化，以及 AI 工作流里的上下文预处理。

模型怎么做到一次解析：从代码看到的机制

仓库没有给出模型架构图，但从推理代码和配置能推断出关键设计。模型基于 DeepSeek-OCR 演进，README 里明确说 aim to push Deepseek-OCR one step further。它接受 <image> 标记和 document parsing 提示词，输出带 <|det|> 标记的文本，标记里包含类型和坐标，比如 <|det|>text [bbox]<|/det|>。这个输出格式意味着模型在识别文字的同时做版面分析，把段落、表格、图片位置都编码进文本流。推理时有两个配置模式：gundam 模式用 640x640 的 image_size 并启用 crop_mode，适合高分辨率文档；base 模式用 1024x1024 且关闭裁剪，适合普通图片。crop_mode 的存在暗示模型内部有滑动窗口或分块机制，但仓库没有公开细节。

三种部署路径，消耗完全不同

README 提供了 transformers、vLLM、SGLang 三种推理方式。transformers 路径最直接，用 AutoModel 加载 baidu/Unlimited-OCR，但依赖版本被钉死：torch 2.10.0、transformers 4.57.1、CUDA 12.9。vLLM 路径提供现成 Docker 镜像，默认 CUDA 13.0，Hopper GPU 用 cu129 版本，这是为 H100 这类显卡准备的。SGLang 路径最复杂，需要手动安装本地 wheel 包，还要指定 kernels==0.11.7，启动参数里有 --attention-backend fa3、--context-length 32768、--enable-custom-logit-processor。这些参数说明模型依赖 FlashAttention 3 和自定义 logit 处理器，普通显卡可能跑不动。infer.py 脚本封装了 SGLang 服务器，支持对图片目录或 PDF 批量推理，用 --concurrency 控制并发。

PDF 转图片这步，仓库没帮你做

虽然主打长文档解析，但仓库没有内置 PDF 解析模块。SGLang 示例代码里，你需要自己用 PyMuPDF（fitz）把 PDF 转成 PNG 图片，dpi 设为 300。infer.py 接受 --pdf 参数，但内部大概率也是调 PyMuPDF 转换。这意味着 PDF 的扫描质量直接影响 OCR 结果，低 dpi 或模糊页面会丢失信息。此外，输出文本带 <|det|> 标记，需要后处理才能得到干净文本。README 里提供了 remove_det 函数，用正则剥离标记并按块分组，但这段代码只处理了 image 类别，表格和文本的边界情况需要你自己扩展。

显存和算力是硬门槛

模型用 bfloat16 加载，context-length 设为 32768，这基本宣告了消费级显卡出局。SGLang 启动参数里 --mem-fraction-static 0.8 意味着静态分配 80% 显存，一张 24GB 的 RTX 4090 可能勉强跑 8K 上下文，但长文档的 32K 上下文需要至少 40GB 显存。仓库没有给出最低显存要求，这是个明显的信息缺口。如果你只有单张 A100 或 H100，可以尝试，但多卡并行没有文档支持。vLLM 的 Docker 镜像只提供 CUDA 13.0 和 12.9 两个版本，意味着老 GPU（如 V100）无法使用。

和 DeepSeek-OCR 的差异：不是简单升级

README 明确感谢了 DeepSeek-OCR、DeepSeek-OCR-2 和 PaddleOCR，但 Unlimited-OCR 不是它们的替代品。DeepSeek-OCR 本身就是多模态模型，Unlimited-OCR 的核心变化在于长上下文处理，这从 32768 的 context-length 和 SGLang 的流式接口可以看出。DeepSeek-OCR 更轻量，适合单页或短文档，而 Unlimited-OCR 牺牲了轻量性换取长文档的一次性解析。如果你只需要识别一张发票或一段截图，DeepSeek-OCR 或 PaddleOCR 更快更省资源。Unlimited-OCR 的价值只有在处理整本 PDF 时才体现出来。

维护和许可证：MIT 但文档不全

项目采用 MIT 许可证，可以自由商用和修改，这点对集成方友好。但仓库没有发布任何 release 版本，也没有版本号，这意味着 API 可能随时变化。README 的 Release 记录显示项目在 2026 年 6 月发布，7 月就支持了 ms-swift 训练和 vLLM 推理，更新节奏快，但稳定性存疑。依赖版本被锁死，升级 transformers 或 torch 可能导致推理失败。训练支持需要额外安装 ms-swift，但仓库没有给出训练配置示例，文档只覆盖推理。如果你需要长期维护，建议锁定 Docker 镜像或固定依赖版本。

编辑结论

Unlimited-OCR 适合需要把整本 PDF 或长图一次转成结构化文本的工程师，尤其是文档解析、RAG 预处理场景。它依赖高端 NVIDIA GPU，且推理配置复杂，至少需要 32GB 显存，否则只能走 SGLang 的流式接口。不适合轻量级 OCR 需求，也不适合 CPU 或低显存环境。采用前先确认你的 GPU 支持 CUDA 12.9 或 13.0，并验证 transformers 版本 4.57.1 与 torch 2.10.0 的兼容性。仓库未提供官方基准测试数据，不要轻信社区宣传，建议在自己的 PDF 样本上跑通 infer.py 的 --image_mode gundam 参数，再评估输出质量。

官方来源

1. Official README
2. Project repository