Unlimited OCR(百度无限制 OCR)2026 完整指南：单次前向传播解析数十页文档的开源模型

Unlimited OCR(百度无限制 OCR)2026 完整指南：单次前向传播解析数十页文档的开源模型

核心要点 (TL;DR)

如果你需要在一个推理请求里把整本书、多页合同或上百页的 PDF 全部转写出来,Unlimited OCR 是 2026 年最值得关注的开源方案:

• Unlimited OCR 是百度于 2026 年 6 月 22 日开源的端到端 OCR 模型。它在解码器中使用了全新的 Reference Sliding Window Attention(R-SWA) 注意力机制,使 KV 缓存在生成长序列时保持恒定大小。
• 在 OmniDocBench v1.5 上,Unlimited OCR 取得 93.23% 的总分,比基线 DeepSeek OCR 高出 +6.22 分;在 v1.6 上达到 93.92%,是开源模型中的 SOTA。
• 模型在 Hugging Face(baidu/Unlimited-OCR)和 GitHub(github.com/baidu/Unlimited-OCR)以 MIT 协议 开源,首个 24 小时就收获 1,800+ GitHub star,并自带 SGLang 高吞吐推理 wheel。
• 提供两种推理模式:gundam(640 像素,启用裁剪,吞吐优先)和 base(1024 像素,不裁剪,适合多页 PDF 全保真)。
• 在 6,000 个生成 token 时,Unlimited OCR 比 DeepSeek OCR 快 35%,而且文档越长,差距越大——这是 2026 年你能在本地自托管的最强长文档 OCR 方案。

✅ 最佳实践: 几页以上的 PDF 一律使用 base 模式 + image_size=1024;只有高并发单图任务才用 gundam 模式。

---

目录

1. 什么是 Unlimited OCR?
2. 为什么"长文档"OCR 在 2026 年才真正落地?
3. Unlimited OCR 的核心:R-SWA + DeepEncoder
4. 规格参数对比表
5. OmniDocBench 基准全面对比
6. 长文档能力:从 2 页到 40+ 页
7. 吞吐和效率:全面领先 DeepSeek OCR
8. 本地运行 Unlimited OCR 完整步骤
9. 生产部署:SGLang + OpenAI 兼容 API
10. 与 Mistral OCR 4 / MinerU / DeepSeek OCR 的对比
11. 常见问题 FAQ
12. 结论与下一步行动

---

什么是 Unlimited OCR?

Unlimited OCR(完整项目名 Unlimited OCR Works — Welcome the Era of One-shot Long-horizon Parsing)是百度在 2026 年 6 月 22 日 开源的端到端多模态 OCR 模型,同日在 arXiv 发布了技术报告 2606.23050。这个项目的核心卖点只有一句话:用一次 forward pass 就能把整篇几十页的文档一次性转写出来,不再分页、不再缝合。

和 PaddleOCR、MonkeyOCR、Dolphin 这类"先检测再识别"的流水线 OCR 不同,Unlimited OCR 是一个真正的端到端视觉语言模型:

• 视觉编码器: 直接复用 DeepSeek OCR 的 DeepEncoder——SAM-ViT + CLIP-ViT 串行结构,带 16× token 压缩,一张 1024×1024 的页面只产生 256 个视觉 token。
• 语言解码器: MoE 架构的 LLM,总共 30 亿参数,推理时只激活 5 亿参数,每一层标准注意力都被替换成了 Reference Sliding Window Attention (R-SWA)。

支撑 Unlimited OCR 这个名字的关键数字是:它把会随生成长度爆炸增长的 KV 缓存,上界锁死在 L_m + n 这个常量(L_m 是 prefix+视觉 token 的长度,n=128 是解码滑动窗口)。也就是说:即使你让它转写 40 页的书,它的解码端缓存也永远只有 128 个 token 的窗口——这是 Unlimited OCR 真正能"无限长"输出的架构基础。

属性	取值
模型名	Unlimited OCR(aka. Unlimited OCR Works / UOW)
发布方	百度(Baidu Inc.)
发布日期	2026 年 6 月 22 日
开源协议	MIT(可商用)
Hugging Face	baidu/Unlimited-OCR
GitHub	github.com/baidu/Unlimited-OCR
ModelScope	已上架
架构	DeepEncoder(SAM-ViT + CLIP-ViT,16× 压缩)+ 带 R-SWA 的 MoE LLM
总参数	3B
激活参数	500M
上下文窗口	32K tokens(训练和推理一致)
推理模式	gundam(640,启用裁剪)、base(1024,不裁剪)
24h GitHub star	1,800+

---

为什么"长文档"OCR 在 2026 年才真正落地?

任何现代文档 AI 流水线——企业 PDF 上的 RAG、合规审查里的 Agent、学术搜索、金融抽取——最后都会撞上同一堵墙:没办法把 200 页的文档整本塞给一个只能看一页的模型。

在 Unlimited OCR 出现之前,业界标准做法是:

1. 把 PDF 拆成一页一页。
2. 每页单独 OCR。
3. 把结果拼接起来,祈祷跨页的表格没断、页脚的脚注引用没丢、章节标题没串到下一章。

错误就是这么"叠"出来的。这只是工程 hack,不是智能。Unlimited OCR 用一次 forward pass 把整篇文档当作单个序列——就像一个人坐下来抄一本书那样。

2026 年这件事终于能做,得益于三个同时发生的变化:

1. 视觉压缩已经做到极致。 DeepEncoder 的 16× 压缩率意味着 40 页文档只需要 ~10K 视觉 token,在 32K 上下文里给输出留出了充裕的空间。
2. KV 缓存的"经济学"终于跟上了。 R-SWA 把解码端的缓存限制为常量窗口,意味着 Unlimited OCR 的 TPS 从第 1 页到第 40+ 页基本不变。
3. 开源权重在价格上击败闭源 API。 Unlimited OCR 是 MIT 协议、单卡 A800/H100 就能跑,不用交 GPT-4o 或 Gemini 的"按页收费"税。

专业提示: 文档 AI 里最难的已经不是"这一页读得对不对",而是"能不能把 200 页当成一份文档来读"。Unlimited OCR 是第一个真正解决了第二个问题的开源模型。

---

Unlimited OCR 的核心:R-SWA + DeepEncoder

DeepEncoder:让 KV 缓存保持小的视觉压缩

Unlimited OCR 直接复用 DeepEncoder,这是 DeepSeek OCR 提出的两阶段 ViT 串行结构:

• 第一阶段(SAM-ViT): 只用 window attention,以原始分辨率处理图片 token。
• 第二阶段(CLIP-ViT): 用 global attention,只处理已经压缩过的 token。

中间夹了一层 16× 压缩,所以 1024×1024 的 PDF 页面只产生 256 个 token。关键是:这些视觉 token 在编码完成后保持不变,整个解码过程都不参与状态更新——这是 R-SWA 能成立的前提。

R-SWA(Reference Sliding Window Attention):核心创新

标准 Multi-Head Attention 的 KV 缓存随生成 token 线性增长,生成长度到 100K 时无论内存还是延迟都会爆炸。

R-SWA 用两段式注意力窗口替代它:

1. 参考段(大小 L_m)——所有视觉 token + prompt。每个解码 token 每一步都能看到全部。这是固定的,不会增长。
2. 解码滑动窗口(大小 n=128)——只看最近 128 个已生成的 token。这个窗口按因果方向滑动。

形式上,对 token t,它的注意力集合是:

(t) =  ∪ _n(t)
 = {1, …, L_m}                  ← 参考段(视觉 + prompt)
_n(t) = {j | max(L_m+1, L_m+t-n) ≤ j ≤ L_m+t-1}   ← 因果滑动窗口

KV 缓存变成 C_R-SWA(T) = L_m + min(n, T) ≤ L_m + n——一个常量上界,而不是标准 MHA 的 L_m + T(无限增长)。

这不仅是内存 trick,也是对人类抄写工作记忆的建模:你抄一本书的时候不会回头读所有已写过的内容,只扫一眼原稿页和刚写的几个字。R-SWA 就是这个行为的架构对照。

训练细节

• 起点: DeepSeek OCR 的开源 checkpoint。
• 数据: ~200 万文档 OCR 样本(单页 : 多页 = 9 : 1),全部 pack 到 32K token。多页样本由 2–50 个单页用 <page> 分隔符拼接。
• 硬件: 8×16 A800。
• 训练: 4,000 步,global batch 256,AdamW + cosine,学习率 1e-4。
• 关键 trick: 训练时冻结 DeepEncoder,只把 LLM 解码器的所有注意力层换成 R-SWA 并训练。DeepEP(EP=4)提供 expert parallelism。

⚠️ 注意: "unlimited" 还是有上限的——目前是 32K 上下文。如果你 prefill 100 页以上的文档,会先撞 prefix 预算。论文已经把 128K 训练列为下一步工作。

---

规格参数对比表

规格	Unlimited OCR(百度)	DeepSeek OCR(基线)	MinerU 2.5	Mistral OCR 4
发布方	百度	DeepSeek AI	OpenDataLab	Mistral AI
发布日期	2026-06-22	2025	2026	2026-06-23
协议	MIT(开源)	开源权重	Apache 2.0	闭源(企业可自托管)
架构	DeepEncoder + 带 R-SWA 的 MoE LLM	DeepEncoder + 标准 MHA 的 MoE LLM	流水线 + VLM	托管 API
总 / 激活参数	3B / 500M	3B / 500M	~0.9B–12B	n/a
视觉压缩	16×	16×	不定	n/a
最大输出	32K(常量 KV)	随长度线性增长	每页	每文档 API
多页一次完成	✅ 已测 40+ 页	❌ 必须分页	有限	✅ 通过 API
PDF 原生工作流	✅ 仓库自带 PyMuPDF helper	❌ 手动	✅	✅ 原生
bbox / block 类型	❌	❌	✅	✅
推理引擎	Transformers、SGLang	Transformers、vLLM	流水线	API only
OmniDocBench v1.5 总分	93.23%	87.01%	85.56%	n/a
OmniDocBench v1.6 总分	93.92%	90.25%	n/a	n/a

---

OmniDocBench 基准全面对比

OmniDocBench v1.5(端到端模型)

模型	规模	Overall ↑	Text Edit ↓	Formula CDM ↑	Table TEDS ↑	Table TEDS-S ↑	Read-Order Edit ↓
Unlimited OCR	3B-A0.5B	93.23	0.038	92.61	90.93	94.07	0.045
DeepSeek-OCR 2	3B-A0.5B	89.17	0.049	86.85	85.60	90.06	0.060
Qwen3-VL	235B	89.15	0.069	88.14	86.21	90.55	0.068
OCRVerse	4B	88.56	0.058	86.91	84.55	88.45	0.071
dots.ocr	3B	88.41	0.048	83.22	86.78	90.62	0.053
Gemini-2.5 Pro	—	88.03	0.075	85.82	85.71	90.29	0.097
Qwen2.5-VL	72B	87.02	0.094	88.27	82.15	86.22	0.102
DeepSeek-OCR(基线)	3B-A0.5B	87.01	0.073	83.37	84.97	88.80	0.086
InternVL3.5	241B	82.67	0.142	87.23	75.00	81.28	0.125

解读: Unlimited OCR 的 93.23% 比它继承的 DeepSeek OCR 基线高 +6.22 分,而且超过了 v1.5 上所有公开的端到端模型——包括 Gemini-2.5 Pro 和 Qwen3-VL-235B。

OmniDocBench v1.6

模型	规模	Overall ↑
Unlimited OCR	3B-A0.5B	93.92
Qianfan-OCR	4B	93.90
Logics-Parsing-v2	4B	93.33
FireRed-OCR	2B	93.26
dots.ocr	3B	90.77
DeepSeek-OCR 2	3B-A0.5B	90.25
HunyuanOCR	1B	89.95

Unlimited OCR 在 v1.6 上拿下单页总分第一,而且是表中参数量最小的几个模型之一——这说明 R-SWA 确实在做架构层面的事,而不只是靠容量堆。

子类别研究(OmniDocBench v1.5)

论文同时按文档类型统计了 edit distance。Unlimited OCR 在 PPT、学术论文、书籍、彩版教材、试卷、杂志、报纸、笔记、研究报告 9 个类别全部打平或超过 DeepSeek OCR 和 DeepSeek OCR 2。对于报纸、彩版教材、杂志这些版式复杂的类别,提升幅度最大——说明 R-SWA 的"有界注意力"对版式密集的页面是加分项,不是限制。

---

长文档能力:从 2 页到 40+ 页

这是 Unlimited OCR 这个名字真正能立住的实验。作者构建了一个内部基准,挑了小说、论文、长文档,按页数分桶:2、5、10、15、20、40+ 页,每桶至少 10 本。

页数	Distinct-20 ↑	Distinct-35 ↑	Edit Distance ↓
2	99.76%	99.87%	0.0362
5	99.78%	99.98%	0.0452
10	97.49%	99.83%	0.0526
15	99.92%	99.99%	0.0787
20	98.73%	99.89%	0.0572
40+	96.08%	96.90%	0.1069

即使在 40+ 页 这个桶,Unlimited OCR 仍然保持了 96.90% 的 Distinct-35(几乎不会重复生成同样的 n-gram)和低于 0.11 的 edit distance。作者对失败案例做了归因:绝大多数剩余错误来自 PDF 里的小字、而不是 R-SWA 本身在长文档里"迷路"——这是工程可以修复的问题,不是架构缺陷。

✅ 最佳实践: 如果 PDF 里包含小号脚注、密集表格等极小正文,先把它升采样到 200–300 DPI 再喂给 Unlimited OCR。base 编码器在 1024×1024 + R-SWA 仍然是长文档效果最好的组合。

---

吞吐和效率:全面领先 DeepSeek OCR

在 prefill=10、其他条件全部相同的设置下,作者对比了 Unlimited OCR 和 DeepSeek OCR 的 TPS:

生成 token 数	DeepSeek OCR TPS	Unlimited OCR TPS	加速比
256	7,229	7,229	~1.0×
512	7,468	7,714	1.03×
1,024	7,422	7,840	1.06×
2,048	7,166	7,881	1.10×
3,072	6,790	7,881	1.16×
4,096	6,430	7,905	1.23×
6,144	5,822	7,847	1.35×

4K token 时 Unlimited OCR 已经快 23%,6K 时差距扩大到 35%。原因是:R-SWA 让每一步的成本保持常量,DeepSeek OCR 的 TPS 持续下降,因为每一步都要重新计算不断增长的完整历史的注意力。

在 OmniDocBench v1.5 推理(256 并发,512-batch TPS)上,Unlimited OCR 是 5,580 TPS vs DeepSeek OCR 4,951 TPS——即使在短文档上也快了 12.7%。长文档上差距还会继续叠加。

---

本地运行 Unlimited OCR 完整步骤

步骤 1 — 安装依赖

pip install torch==2.10.0 torchvision==0.25.0 transformers==4.57.1
pip install Pillow matplotlib einops addict easydict pymupdf psutil

步骤 2 — 单图推理(gundam 模式)

import torch
from transformers import AutoModel, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained(
    "baidu/Unlimited-OCR", trust_remote_code=True
)
model = AutoModel.from_pretrained(
    "baidu/Unlimited-OCR",
    trust_remote_code=True,
    use_safetensors=True,
    torch_dtype=torch.bfloat16,
).eval().cuda()

model.infer(
    tokenizer,
    prompt="<image>document parsing.",
    image_file="your_image.jpg",
    output_path="./output",
    base_size=1024,        # 编码后的页面尺寸
    crop_mode=True,        # gundam 配置
    max_length=32768,
    no_repeat_ngram_size=35,
    ngram_window=128,
    save_results=True,
)

步骤 3 — 多页 PDF(base 模式)

import torch, fitz, tempfile, os
from transformers import AutoModel, AutoTokenizer

def pdf_to_images(pdf_path, dpi=300):
    doc = fitz.open(pdf_path)
    tmp_dir = tempfile.mkdtemp(prefix="pdf_ocr_")
    mat = fitz.Matrix(dpi / 72, dpi / 72)
    paths = []
    for i, page in enumerate(doc):
        out = os.path.join(tmp_dir, f"page_{i+1:04d}.png")
        page.get_pixmap(matrix=mat).save(out)
        paths.append(out)
    doc.close()
    return paths

tokenizer = AutoTokenizer.from_pretrained(
    "baidu/Unlimited-OCR", trust_remote_code=True
)
model = AutoModel.from_pretrained(
    "baidu/Unlimited-OCR", trust_remote_code=True,
    torch_dtype=torch.bfloat16
).eval().cuda()

model.infer_multi(
    tokenizer,
    prompt="<image>Multi page parsing.",
    image_files=pdf_to_images("your_doc.pdf", dpi=300),
    output_path="./output",
    image_size=1024,       # base 模式
    max_length=32768,
    no_repeat_ngram_size=35,
    ngram_window=1024,
    save_results=True,
)

专业提示: no_repeat_ngram_size=35 和 ngram_window 是从 DeepSeek OCR 继承下来的"抑制重复"参数,用来防止模型在表头、页码、密集脚注上原地循环。多页文档务必把 ngram_window 调到 1024,让抑制窗口比任何"合法重复"更宽。

---

生产部署:SGLang + OpenAI 兼容 API

仓库自带一个 SGLang wheel,可以一行命令起 OpenAI 兼容的 API server。

python -m sglang.launch_server \
  --model baidu/Unlimited-OCR \
  --served-model-name Unlimited-OCR \
  --attention-backend fa3 \
  --context-length 32768 \
  --enable-custom-logit-processor \
  --host 0.0.0.0 \
  --port 10000

然后用标准 multimodal message 格式调用:

import openai
client = openai.OpenAI(base_url="http://localhost:10000/v1", api_key="EMPTY")

resp = client.chat.completions.create(
    model="Unlimited-OCR",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "<image>document parsing."},
            {"type": "image_url", "image_url": {"url": "file://page1.png"}},
            {"type": "image_url", "image_url": {"url": "file://page2.png"}},
            # ... 可以一直加到几十页
        ],
    }],
    stream=True,
    extra_body={
        "images_config": {"image_mode": "base"},
        "custom_params": {"ngram_size": 35, "window_size": 1024},
    },
)

用 infer.py 跑批量任务

# 图片目录
python infer.py \
  --image_dir ./examples/images \
  --output_dir ./outputs \
  --concurrency 8 \
  --image_mode gundam

# PDF
python infer.py \
  --pdf ./examples/document.pdf \
  --output_dir ./outputs \
  --concurrency 8 \
  --image_mode base

--concurrency 控制同时处理的页数,用来批量导入几千份 PDF 特别合适。

---

与 Mistral OCR 4 / MinerU / DeepSeek OCR 的对比

模型	一次处理多页	开源权重	PDF 原生	上下文	bbox	最适合
Unlimited OCR	✅ infer_multi	✅ MIT	✅ 自带 PyMuPDF	32K(常量 KV)	❌	长文档、密集版式
Mistral OCR 4	按文档 API	企业可自托管	✅	API	✅	托管 Document AI、typed blocks
DeepSeek-OCR	单图	✅	❌	较短	❌	快速单图抽取
DeepSeek-OCR 2	有限	✅	❌	较长	❌	更高单页保真度
MinerU 3.4	通过流水线	✅	✅	hybrid	✅	完整多后端生产栈
GPT-4o Vision	逐页 API	❌	通过预处理	API 限制	部分	你已经在用 OpenAI

Unlimited OCR 的甜蜜区: 你需要一次吞下整份 PDF、想自托管开源权重、可以接受暂时没有 bounding-box 输出(把 Unlimited OCR 当 Markdown 抽取器,再在外面加一层版式逻辑)。

---

常见问题 FAQ

Q: Unlimited OCR 是什么?

Unlimited OCR 是百度 2026 年 6 月 22 日开源的端到端 OCR 模型。它在解码器引入 Reference Sliding Window Attention(R-SWA),把生成长序列时的 KV 缓存锁定为常量。结果是:在标准 32K 上下文窗口下,它能一次 forward pass 转写几十页文档,完全不需要分页、不需要结果拼接。

Q: Unlimited OCR 和 DeepSeek OCR 有什么区别?

两者共用同一个 DeepEncoder 视觉前端,但 Unlimited OCR 把解码器里每一层 Multi-Head Attention 都替换成了 R-SWA。DeepSeek OCR 的 KV 缓存随输出长度线性增长;Unlimited OCR 的 KV 缓存被一个常量窗口锁住。在 OmniDocBench v1.5 上,Unlimited OCR 拿到 93.23%,DeepSeek OCR 是 87.01%——绝对提升 +6.22 分。

Q: Unlimited OCR 真的是开源的吗?

是。权重在 Hugging Face(baidu/Unlimited-OCR)和 ModelScope 都是 MIT 协议;完整推理代码在 github.com/baidu/Unlimited-OCR。MIT 允许商用、修改、再分发。

Q: Unlimited OCR 一次能处理多少页?

论文里长文档评测跑到了 40+ 页 单次调用,Distinct-20 96.08%、Distinct-35 96.90%——意味着模型几乎不会重复输出已生成的 n-gram。超过这个量级会撞 32K 上下文预算;作者已经把 128K 训练列为下一步。

Q: 怎么在本地跑 Unlimited OCR?

装 PyTorch 2.10.0 + Transformers 4.57.1,然后 AutoModel.from_pretrained("baidu/Unlimited-OCR", trust_remote_code=True, torch_dtype=torch.bfloat16).cuda()。单图用 model.infer(..., crop_mode=True)(gundam);PDF 用 model.infer_multi(..., image_size=1024)(base),配合仓库自带的 PyMuPDF helper 把页面渲染成 300 DPI PNG。

Q: 可以把 Unlimited OCR 部署成 API server 吗?

可以。仓库自带 SGLang wheel:python -m sglang.launch_server --model baidu/Unlimited-OCR --attention-backend fa3 --context-length 32768 --enable-custom-logit-processor,然后通过 http://localhost:10000/v1/chat/completions 这个 OpenAI 兼容端点调用,支持流式和多模态消息。

Q: gundam 和 base 两种模式怎么选?

gundam 是高吞吐单图配置:640 分辨率 + 启用裁剪,单图 tokens/s 最高。base 是全保真多页配置:1024 分辨率 + 不裁剪,适合 PDF 和密集版式。infer.py 通过 --image_mode 切换。

Q: Unlimited OCR 能替代 Mistral OCR 4 或 MinerU 3.4 吗?

看你的需求。Unlimited OCR 赢在一次处理多页和开源自托管;Mistral OCR 4 赢在托管 API、bounding box、typed block classification;MinerU 3.4 赢在完整生产流水线(hybrid backends、VLM routing、多 GPU)。实际项目里很多团队会让 Mistral 负责"带版式的抽取",让 Unlimited OCR 负责"原始长文档转写",各取所长。

Q: 上下文只有 32K,为什么叫 "unlimited"?

这里的 "unlimited" 指的是不限输出长度,而不是不限输入。因为 R-SWA 把解码端 KV 缓存锁在 L_m + n,理论上 Unlimited OCR 可以一直输出到撞上上下文窗口为止。剩下的瓶颈是 prefix 预算——但 DeepEncoder 的 16× 压缩让 32K 上下文能轻松装下 30+ 页的视觉信息。作者的路线图里明确写了:下一步上 128K 上下文,再之后搞"prefill pool",模拟人类翻书的动作。

---

结论与下一步行动

Unlimited OCR 是 2026 年第一个真正改变文档 AI 格局的开源权重模型。它不是最小、不是短上下文最快、也不是单图最便宜——但它是唯一一个让你指着一份 40 页 PDF 就能放着不管的模型。

三步行动计划

1. 今天: pip install transformers==4.57.1 pymupdf,在你自己的 20+ 页 PDF 上跑一次 model.infer_multi(...),和现有"逐页 OCR + 拼接"的流水线对比 edit distance 和"拼接错位"。
2. 这周: 把仓库自带的 SGLang server 接入你现有的文档摄取端点。PDF 一律走 images_config.image_mode=base;缩略图、预览用 gundam。
3. 下月: 在你最关键的三类文档工作流里,把 Unlimited OCR 和 Mistral OCR 4 做 A/B。需要 bbox/typed blocks 的走 Mistral;只要原始长文档转写的走 Unlimited OCR。

一句话结论

✅ 2026 年赢的文档 AI 栈,是能把整篇文档当作一个序列、而不是"缝合出来的页序列"的栈。Unlimited OCR 是第一个把这个能力做到实用的开源模型——OmniDocBench 93%+、长输出比 DeepSeek OCR 快 35%、MIT 协议、单卡 A800/H100 就能跑。 如果你在做 RAG、合规审查 Agent、学术搜索或金融抽取,这就是新的基线。

---

参考与延伸阅读

• 百度 — Hugging Face 上的 Unlimited-OCR
• 百度 — GitHub 上的 Unlimited-OCR
• 百度 — arXiv 论文 2606.23050 — Unlimited OCR Works: Welcome the Era of One-shot Long-horizon Parsing
• vLLM Project — Unlimited-OCR 部署 recipe
• DeepSeek OCR 基线 — Wei et al., 2025
• OmniDocBench v1.5 / v1.6 — Ouyang et al., 2025

最后更新:2026-07-23.