一、它是什么
处理长文档——整本书、长篇报告、学术论文、扫描档案——时，传统 OCR 的思路通常是：把 PDF 拆成一页一页，逐页识别，再人工或用规则把结果拼起来。表格跨页、公式断行、页眉页脚干扰、阅读顺序错乱，这些接缝问题只能硬工程处理。
百度 Unlimited-OCR 想做的是端到端一次性转录：把几十页文档作为一整张「大图」输入，模型一次性输出结构化 Markdown，包含文本、公式、表格和阅读顺序。
一句话定位：基于 DeepSeek OCR 改进的端到端长文档 OCR 模型，通过 R-SWA 机制把解码器 KV Cache 锁在固定窗口，实现 40+ 页长文档单条前向推理。
二、传统 OCR 的瓶颈
现代 OCR 大多基于 Transformer 解码器。解码器在生成每个 token 时，都要「回看」之前生成的所有 token，因此 KV Cache 会随输出长度线性增长：
| 问题 | 表现 |
|---|---|
| 显存线性增长 | 页数越多，KV Cache 越大，容易 OOM |
| 速度越跑越慢 | 每生成一个新 token 都要看完全部历史 |
| 分页割裂 | 跨页表格、段落被切成碎片，需要后处理拼接 |
| 长程遗忘 | Page-by-Page 方案前后页上下文不连贯 |
学术界和工业界常见的 workaround 是「for-loop 工程」：逐页处理，再写一堆规则合并。这不是真正的长文档理解，而是把模型的短板包了一层壳。
三、核心技术：R-SWA + DeepEncoder + MoE
1. Reference Sliding Window Attention（R-SWA）
这是 Unlimited-OCR 最核心的创新。它借鉴人类抄书的方式：眼睛始终盯着原文，手里只需要记住刚写的几个字。
- 参考侧：完整保留原始文档的视觉 token 和 prompt token，解码器每步都能「看到」整页/整份文档
- 输出侧：只保留最近约 128 个生成 token 作为「工作记忆」
- 结果：KV Cache 变成固定容量队列，输出 1 万 token 和 10 万 token 的显存占用基本一样
这样设计的好处是：模型既能保持对原始文档的完整感知，又不会因为输出变长而线性堆内存。40 页和 2 页的推理成本曲线接近常数。
2. DeepEncoder 视觉压缩
来自 DeepSeek OCR 的视觉编码器，能把一页 1024×1024 的图像压缩到 256 个视觉 token。这种压缩率让多页 PDF 在 32K 上下文里放得下：
| 组件 | 作用 | 数据 |
|---|---|---|
| SAM-ViT | 第一阶段，全分辨率窗口注意力 | 处理原始图像 |
| 16× 压缩层 | 将 token 数压缩 | 1024×1024 → 256 token |
| CLIP-ViT | 第二阶段，全局注意力 | 处理压缩后的特征 |
视觉 token 只编码一次，在后续解码中保持静态，不随输出重新计算，这是 R-SWA 能省内存的关键前提。
3. MoE 解码器
模型采用 Mixture-of-Experts（MoE）架构：
总参数 3B，每次推理激活参数约 500M（570M）。基于 DeepSeek OCR 检查点继续训练 4000 步，训练数据约 200 万文档样本，使用 8×16 张 A800 GPU。
MoE 的优势在于：总容量大，但前向激活少，推理速度和显存占用更可控。
四、性能与测试数据
在端到端 OCR 权威基准 OmniDocBench 上，Unlimited-OCR 刷新了 SOTA：
| 基准 | 综合得分 | 备注 |
|---|---|---|
| OmniDocBench v1.5 | 93.23% | 开源时首次发布成绩 |
| OmniDocBench v1.6 | 93.92% | 后续刷新端到端模型第一 |
长文档测试数据：
- 一次性输入 20 页文档，编辑距离 0.057
- 一次性输入 40+ 页文档，编辑距离低于 0.11，Distinct-35 指标约 97%
- 输出 6000 token 时，推理速度比 DeepSeek OCR 快约 35%
- 长程解析能力：输出侧 KV Cache 保持恒定，不随页数衰减
社区热度：
- 2026 年 6 月 22 日开源
- 5 天 GitHub Star 破万
- HuggingFace 全球模型趋势榜、多模态趋势榜均排名第一
五、部署与使用
项目提供 GitHub 和 HuggingFace 两个入口：
| 资源 | 地址 |
|---|---|
| GitHub | github.com/baidu/Unlimited-OCR |
| HuggingFace | huggingface.co/baidu/Unlimited-OCR |
| 技术报告 | HuggingFace 仓库内 PDF |
| License | MIT（开源权重，可商用） |
推荐部署：SGLang / vLLM
官方示例基于 SGLang 启动服务。单张 A800 / H100 即可跑起来。
批量推理
仓库提供 infer.py，支持并发处理图片目录或 PDF：
六、最小试玩
如果你想在本地或服务器上快速体验，下面是一条最小路线：
1. 准备一台带 NVIDIA GPU 的环境（建议至少单卡 A800/H100 或同显存规模），安装 CUDA 和 Python 3.11+。
2. 克隆仓库并安装依赖：
3. 下载模型权重（从 HuggingFace 拉取 baidu/Unlimited-OCR）。
4. 启动 SGLang 服务或直接用 infer.py 跑一张 5-10 页的 PDF。
5. 对比输出 Markdown 与原文，重点观察跨页表格、公式、阅读顺序是否正确。
6. 逐步加长文档页数，从 10 页到 20 页再到 40 页，感受生成速度和显存占用是否稳定。
7. 如果只想快速测试，HuggingFace 上可能有在线 demo，可直接上传图片体验。
注意：访问 HuggingFace 和 GitHub 在中国大陆可能需要代理，模型下载请根据网络情况选择镜像或本地下载。
七、适合谁 & 注意点
适合：
- 需要批量数字化书籍、论文、报告、档案的团队
- 做 RAG 文档预处理，需要保持长文档语义连贯的开发者
- 厌倦逐页 OCR + 拼接后处理的工程师
- 希望用开源、可商用模型替代付费 OCR API 的中小企业
注意点：
- 页数上限：官方公开测试为 40+ 页一次性转录，不是「无限页」。未来计划扩展到 128K 上下文，但现在仍以 40 页左右为实际参考。
- 硬件门槛：端到端模型需要 GPU，A800/H100 级别的显存更适合长文档。消费级显卡可能只能跑短页。
- 数据准确性：模型在公式、表格、复杂版面上的表现优于传统方案，但仍需人工抽查关键数据。
- 网络环境：模型权重托管在 HuggingFace，国内访问需考虑网络方案。
- 生态依赖：基于 DeepSeek OCR，若团队已在 DeepSeek OCR 生态中，迁移成本较低；否则需要先熟悉 SGLang/vLLM 部署。
- 商用范围：MIT 协议允许商用，但需保留版权声明，并注意百度开源模型自身的使用条款更新。
数据勘误：坤哥给的信息里提到「单图扫描 100 页」和「14.2K 星标」。根据公开资料，目前官方明确测试的是 40+ 页长文档；GitHub Star 是「5 天破万」，当前可能达到 14K+，但「14.2K」这个数字需要以仓库实时显示为准。建议不要对外承诺「100 页」或「14.2K」作为项目官方保证。
返回技艺录