百度 Unlimited OCR 2 拆解：SR-SWA 如何让百页文档的 KV 缓存不再涨

百度文心团队 10 月 27 日开源了 Unlimited OCR 2，一个 3B 的 MoE 文档解析模型。宣传语是"任意页数"，比这句更值得看的是它的做法：解码时每一步只看固定数量的视觉 token，所以 100 页和 300 页的单步开销差不多，KV 缓存峰值也不再跟着页数往上涨。

端到端视觉语言模型以前一次只能处理几页到几十页，现在把整本书当成一个序列来解析，算力和显存也撑得住。下文依据技术报告、模型卡和 config，讲它的做法、哪些数字要打折看、适合哪些场景。

它是什么

项目	内容
发布方	百度文心（ERNIE）团队
发布日期	2026-10-27（GitHub / Hugging Face 同步开源）
许可证	MIT
规模	模型卡标 3B；技术报告正文写"3B 总参、每 token 激活 500M"，架构图里标的是 A570M，两处口径不一致
结构	DeepEncoder 视觉编码器（沿用 DeepSeek-OCR）+ MoE 解码器，config 里是 12 层、64 个路由专家加 2 个共享专家、每 token 选 6 个
核心改动	解码器全部注意力层换成 SR-SWA（Sparse Reference Sliding Window Attention）
上一代	Unlimited OCR，2026-06-22 开源，用 R-SWA，输入上限约 40 页
获取方式	GitHub `baidu/Unlimited-OCR`、Hugging Face `baidu/Unlimited-OCR-2`；据百度通稿，同时上线百度智能云和百度 AI 开放平台
价格	开源权重免费；云端 API 的计费未在一手来源中查到
参数量之外未公开的	训练数据的具体构成比例、MarathonDocBench 数据集是否公开

先说问题：长文档 OCR 卡在哪

现在主流的端到端文档解析（报告里叫 OCR 2.0），是把页面图片编码成视觉 token，再让语言模型一个字一个字地把内容"抄"出来。一页 OCR 的输出动辄上千 token，问题出在两处：

文本历史越抄越长。普通注意力下，每生成一个 token 都要回看前面所有输出，KV 缓存线性增长。
视觉上下文越堆越多。多页一起喂进去，每一步都要对所有页的视觉 token 做注意力。

上一代 Unlimited OCR 用 R-SWA 解决了第一个问题：文本历史只保留一个固定长度的滑动窗口，抄过去的内容不再回看。第二个问题它没解决，每一步仍然对全部页面的视觉 token 做稠密注意力。几十页还撑得住，到上百页，视觉 token 成了主要开销，所以上一代的输入上限停在 40 页左右。

报告里打了个比方：人抄一本书时，眼睛基本只盯着当前这页，偶尔回头翻一下前面的表格或者被截断的段落，不会每写一个字都把整本书重看一遍。SR-SWA 做的就是这件事。

SR-SWA 怎么工作

每个解码步，模型能"看到"的内容由两部分组成：

text 复制代码

当前 query 可见的 token =
    本地窗口（最近 128 个 token，固定）
  + 远端视觉块（从相关页面里挑出的 top-16 块 × 每块 32 token = 512 个）

文档 10 页还是 300 页，这个集合的大小不变

上面的数字来自 Hugging Face 上 config.json 里的 sliding_window_size: 128、sparse_block_size: 32、sparse_topk_blocks: 16，和 README 里"固定大小的工作参考集，例如 512 tokens"的说法对得上。

远端视觉块是分两层挑出来的。

第一层：Page Gate，先缩到相关页

Page Gate 根据当前在抄哪一页，把候选范围从整份文档缩到指定的几页，其他页的视觉块直接不进候选。

另一个容易忽略的设计是位置编码怎么防止爆掉 。几百页的文档，视觉 token 加文本 token 的总位置号会非常大，RoPE 外推容易出问题。SR-SWA 把每个 token 的位置拆成两段：页级坐标只在 0 和 1 之间交替（config 里 sparse_rope_page_mod: 2），页内坐标单调递增。模型只需要分清"这一页"和"相邻那一页"，永远不会碰到"第 287 页"这种训练时没见过的位置。整体长度能一直往外推，靠的就是这一点。

第二层：Token Sieve，按固定预算挑块

在 Page Gate 给出的候选里，Token Sieve 把每个 32 token 的块压成一个摘要 key，和当前 query 算相关性，过一遍 α-entmax（一种会把小概率直接压成 0 的 softmax 变体），再取 top-k。

被选中的块，路由分数会作为偏置直接加进注意力 logits。报告强调这样做的好处是：解析任务的损失可以直接把梯度传给路由模块，不需要另外用稠密注意力蒸馏一个 KL 损失来教路由器"该看哪"。很多稀疏注意力方案需要这样的辅助监督或者预热，SR-SWA 可以端到端训练。

为什么不用线性注意力

线性注意力和 Mamba 这类方案也能做到每步恒定开销，报告解释了没选的原因：它们把历史压成一个紧凑状态，文档解析却要"精确地看清某一页某个格子里的字"。细粒度的视觉证据一旦压进状态，就很难原样取回来。稀疏注意力保留了"直接访问原始 KV 块"的能力，只是限制每步能访问多少块。

这个取舍的代价放在后面「局限」里说。

光有 SR-SWA 还不够：Unlimited-Horizon Decoding

SR-SWA 限制的是每步算多少，KV 缓存存多少是另一回事：所有页的视觉 KV 如果一次性 prefill 进显存，页数一多照样放不下。

所以推理时还配了一个分块流程：

text 复制代码

页面:  P1 P2 P3 P4 | P4 P5 P6 P7 | P7 P8 P9 ...
       ---块 1---    ---块 2---    ---块 3---
               重叠 1 页      重叠 1 页

处理块 2 时：复用 P4 的视觉 KV + 块 1 末尾一段文本 KV
           块 1 其余页的视觉 KV 释放掉

相邻块共享一页边界，进入下一块时直接复用边界页的视觉 KV 和上一段输出的尾部，其余缓存释放。显存里永远只有一个块的大小。SGLang 部署时块大小由环境变量控制，模型卡示例是每块 10 页。

官方称的效果（MarathonDocBench 百页文档）：

指标	标准解码	Unlimited-Horizon 解码
峰值 KV 缓存（单序列）	47.00 GB	1.77 GB
端到端吞吐（16 并发）	360 TPS	1315 TPS

注意 1.77 GB 只是 KV 缓存，不含模型权重。模型卡也提醒了代价：块越小显存越省，但跨块的内容会丢上下文，影响跨页段落和表格的合并。

跑分：官方数据和要打折的地方

以下全部是技术报告里的官方自测数据。

基准	Unlimited OCR 2	报告中的第二名	说明
MPDocBench（最多 30 页）	84.59	Qwen3.8-Max 78.30	第三方已有基准
MarathonDocBench（100--300 页）	77.06	Kimi-K3 33.74	百度这次自建的基准
OmniDocBench v1.6（单页）	94.02	---	上一代 93.92；同表其他专用模型最高 96.91
单步解码速度（百页）	比 Full Attention 快 7.0 倍、比 R-SWA 快 5.6 倍	---	Gundam 模式，batch 3，每页生成 1024 token

几个要留意的点：

最大的领先出现在自建基准上。MarathonDocBench 由百度提出，100 份文档、20.5 万个标注元素，标注先用"一个强的逐页解析器"初始化，再人工和 VLM 修订。用自家流程初始化的标注评自家模型，有偏向的可能，数据集目前也没看到公开下载。
通用大模型的比法不完全对等。Gemini、Qwen、Kimi 这些通用模型被要求一次性端到端吃下上百页，这本来就不是它们的常规用法。实际工程里大家会逐页或分段调用，再拼接结果。报告没给"通用模型 + 分段流程"的对照。
单页不是最强。OmniDocBench 上 94.02 只比上一代高 0.1，同表里有好几个 0.8B--4B 的专用 OCR 模型分数更高。它的长处在长度，单页精度不是卖点。
报告里的对比对象有点旧。闭源模型列的是 Gemini 3.1 Pro Preview 和 Gemini 3.8 Flash，没有更新的 Pro 级模型。

第三方信息方面，量子位文章给出的实测是用它跑 884 页英文版《指环王》，约 42 分 56 秒，平均每页约 2.9 秒，抽查第 600、750 页与原文一致。这是媒体的单次测试，硬件配置文中没写清。官方演示还有一口气读完 3600 多页的《哈利·波特》全七部。

和其他方案比

方案	代表	长文档怎么处理	优点	短板
逐页流水线	MinerU、PaddleOCR-VL	一页一页解析再拼	成熟，显存小，好并行	跨页段落、跨页表格要靠后处理规则合并
通用 VLM 全量输入	Gemini、Qwen 等	整份塞进上下文	能顺便做理解、问答	页数一多精度掉得厉害（MarathonDocBench 大多跌到 30 分以下），成本高
稠密注意力 OCR 模型	DeepSeek-OCR 2	主要面向单页 / 少量页	单页精度高	长序列 KV 线性增长
R-SWA	Unlimited OCR（6 月）	文本历史窗口化，视觉仍全量	KV 恒定，几十页可行	视觉 token 随页数膨胀，约 40 页封顶
SR-SWA + 分块解码	Unlimited OCR 2	视觉也只看固定预算的块	单步开销和显存与页数无关	缺全局信息，标题层级等文档级结构偏弱

最接近的竞品其实是逐页流水线。Unlimited OCR 2 的训练伪标签恰好来自 MinerU2.5-Pro 和 PaddleOCR-VL-1.6，可以理解为：用逐页工具的单页能力做老师，再让模型自己学会跨页衔接。

适合用在哪

长篇 PDF 入库：教材、技术手册、财报、标书、论文合集这种几百页、跨页表格多的文档，给 RAG 做数据清洗。跨页表格合并是它比逐页方案强的地方，报告里 T-Table（跨页表格）指标在 MarathonDocBench 上是 71.11，报告里的通用模型都没超过 27 分。
显存有限的批量任务：1.77 GB 的 KV 峰值加约 3B 的权重，单卡跑长文档的门槛低了很多。
当成 Agent 的"读档"工具：主模型负责理解和问答，Unlimited OCR 2 负责把几百页扫描件转成结构化 Markdown，两者分工。

部署方面，模型卡给的 Transformers 用法如下（本文未实测，测试环境是 Python 3.10、torch 2.13.0、transformers 4.52.1、A800-80GB）：

python 复制代码

import torch
from transformers import AutoModel, AutoTokenizer

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

# 多页：每页一个全局视图
text, n = model.infer_multi(tokenizer, image_files=pages,
                            output_path="output/multi", save_results=True)

服务化部署官方推荐 SGLang，但需要装仓库里提供的定制 wheel ，并按模型卡设置几个参数：--mem-fraction-static 0.7（0.75 在 32 并发以上余量不够）、--max-prefill-tokens 2048，以及环境变量 SGLANG_OPT_UOCR_SAM_REL_POS_BIAS_MB=64 防止一次性大块分配导致 OOM。

局限和坑

文档级结构偏弱。报告自己承认，稀疏注意力不保留全局信息，标题层级这类整篇结构理解受限。MarathonDocBench 上 HeadingTEDS 只有 48.20，是各项里最低的。报告说下一步可能引入线性注意力补全局信息。
训练数据多样性有限，这也是报告原话。伪标签来自其他解析器，上限受老师模型影响。
必须 trust_remote_code=True，生产环境要先审一下仓库里的自定义代码。
SGLang 要用定制 wheel，和你现有的 SGLang 版本可能冲突，最好单独建环境。
Hugging Face 上暂时没有托管推理服务，想直接调 API 只能看百度云，计费方式我没查到一手说明。
分块越小越省显存，跨块衔接越差，块大小要按文档特点调。

我的判断

Unlimited OCR 2 值得看的地方，是它把"长上下文"这个通用难题，在一个边界清楚的任务里用很朴素的办法拆开了：抄书的人本来就只看当前页，那就让模型只看当前页附近，再留一个固定大小的回看名额。页级 0/1 交替的位置编码、路由偏置直接进注意力 logits 免掉蒸馏损失，这两个细节都很实用。它没有追求"什么都记住"，而是规定了"每步最多看多少"，换来的是和页数无关的开销。这个思路可以搬到语音转写、长视频字幕这类"输入很长、输出和输入局部对齐"的任务上，上一代论文就提过 R-SWA 适用于 ASR 和翻译。

数字要分开看。KV 缓存和单步延迟的改善是架构决定的，可信度高；MarathonDocBench 上 77 比 33 的差距，一半来自通用模型被用在了不擅长的方式上，基准又是自建的，等第三方用公开数据复现之后再下结论比较稳。

如果你手上有大量长 PDF 要转结构化文本，又被逐页方案的跨页表格断裂困扰，它值得拿一批自己的文档试一下，重点看跨页表格和标题层级两项。只处理单页票据、截图的场景，换它意义不大。

参考资料

Unlimited OCR 2 技术报告（PDF，仓库内）：github.com/baidu/Unlim...
GitHub 仓库 baidu/Unlimited-OCR：github.com/baidu/Unlim...
Hugging Face 模型卡与 config.json：huggingface.co/baidu/Unlim...
上一代论文 Unlimited OCR Works（arXiv 2606.23050）：arxiv.org/abs/2606.23...
量子位报道与实测（2026-10-27）：www.qbitai.com/2026/10/505...
雷峰网报道（百度通稿，含平台上线信息）：www.leiphone.com/category/in...
新浪科技报道（2026-10-27）：finance.sina.com.cn/tech/2026-1...