文心 Unlimited OCR 2 深度研究 · 从长视野到无限视野

00摘要：十条可证伪的判断

每一章都在展开其中某一条。若某条被后续证据推翻，对应章节会跟着塌。

它解决的是第二重瓶颈，不是第一重。 第一代用 R-SWA 只压住了「越抄越长的文本历史」，视觉上下文仍随页数线性膨胀，所以官方承认上限卡在约 40 页。SR-SWA 才动的是视觉侧。

核心机制是给每个解码步一个固定容量的「工作参考集」。 本地窗口 128 token（4 块 × 32）+ 远端 top-16 块 × 32 = 512 token，合计 640，与文档 10 页还是 300 页无关。这个数可以从 config.json 字段直接对上。

「无限」必须两个机制叠加，不能单独归因。 SR-SWA 管的是单步算力（百页场景 7.0×/5.6× 加速），Unlimited-Horizon Decoding 管的是显存（峰值 KV 47GB → 1.77GB）。报告里的 Table 4 只对比了后者，把两者混为一谈会误读。

页级 0/1 交替位置编码，比稀疏注意力本身更值得抄。 它把「第 287 页」这个训练时没见过的坐标从表示空间里消掉，让外推在结构上成立，而不是靠调 RoPE 参数硬撑。

路由是端到端训的，不需要 KL 蒸馏。 路由概率被转成 mean-centered log-prior 直接加进 attention logits，梯度自然回传到路由器。use_kl_loss: false 与报告第 3.3.2 节的说法互相印证。

代价是文档级全局结构。 稀疏注意力不保留全文信息，作者自陈标题层级理解受限，未来可能引入线性注意力补全局。MarathonDocBench 上 HeadingTEDS 只有 48.20，是各项里最低的一项。

单页精度不是卖点。 OmniDocBench v1.6 得 94.02，只比一代高 0.1，且被 0.8B 的 OvisOCR2（96.47）和 1.2B 的 TeleOCR（96.91）超过。买它是买长度。

百页级 77.06 分要打折看。 基准是百度自建、标注由「强逐页解析器初始化」；对比的通用大模型被要求一次性端到端吃下 100–300 页，本就不是它们的常规用法，且没有「通用模型 + 分段流水线」这一条基线。

它的正确定位是智能体的「读档层」，不是理解层。 输出带 bbox、块类型、层级、阅读顺序的结构化文档，跨页表格合并（T-TableTEDS 71.11，通用模型不超过 26.3）才是它压过逐页方案的真实差异点。

工程可用性有隐性成本。 必须 trust_remote_code=True、要用仓库自带定制 SGLang wheel（0.5.20.dev10）、page-window 与 block 大小要和文档类型匹配，块越小越省显存但跨块衔接越差。

一句话结论

这是一次问题定义层面的进步：它把「长上下文」这个通用难题，塞进「输入很长、输出与输入局部对齐」这个边界清楚的任务里，用「每步最多看 640 个 token」换取与页数无关的开销。数字里，架构决定的效率提升可信度高；基准上的领先幅度，要等第三方用公开数据复现之后再下定论。

01定位：它自称开启「OCR 3.0」，这个说法站得住吗

百度把这条线切成三段：1.0 是多阶段流水线，2.0 是端到端视觉语言模型，3.0 是无限视野。分段本身是营销动作，但分段的判据是实的——因为判据决定了你该不该换方案。

三代的分野不在精度，在成本结构

把三代放在一起看，会发现差异不在「识别得准不准」，而在成本随文档长度怎么变。1.0 的成本随页数线性增长（页数 × 单页流水线开销），但每页独立，误差会累积；2.0 把整页压成视觉 token 交给语言模型解码，误差不再累积，可代价是解码器的 KV 缓存随输出长度线性膨胀；3.0 要解决的就是这个膨胀。

图 1 · 三代文档解析范式的关键差异。注意 2.0 与 3.0 之间只隔了四个月，而 1.0 到 2.0 隔了三年——加速点在「把扫描件当序列抄」这个统一框架确立之后。

判别式：什么才算 3.0

把官方叙事翻译成可检验的条件，一个系统要配得上「无限视野」，得同时满足三条。缺任何一条，都只是「更长的 2.0」：

① 单次前向

整份文档一次请求送入，不做「逐页解析 + 结果拼接」。跨页结构由模型自己判断，而不是靠后处理规则合并。

② 成本与页数解耦

单步延迟与显存占用不随页数增长。注意要两个维度都看：只压住其中一个，页数一过百就漏。

③ 跨页结构连贯

跨页的段落与表格由模型在语义层接续，输出顺序与阅读顺序一致，不丢字、不乱序、不重复。

按这三条对照，Unlimited OCR 2 是目前唯一公开可下载权重且三条都宣称满足的模型；通用大模型（Gemini、Qwen、Kimi）满足①但严重违反②，逐页流水线（MinerU、PaddleOCR-VL）满足②③里的一半，靠规则缝合跨页结构。这个对照关系后面第 07 章会用分数验证。

版本事实核对

表 1 · 两代 Unlimited OCR 的公开事实（据 README、模型卡、官方通稿与报告正文）
维度	Unlimited OCR（一代）	Unlimited OCR 2
发布时间	2026-06-22	2026-10-27
核心机制	R-SWA（文本参考滑动窗口）	SR-SWA（稀疏参考滑动窗口）+ 无限视野解码
文档长度上限	约 40 页（报告 Table 2 脚注自述）	宣称任意页数；基准覆盖 103–300 页
基座	DeepSeek-OCR：DeepEncoder（SAM-ViT-B + CLIP-L/14，1024² 输入）+ MoE 解码器
规模	3B 总参 / 约 500M 激活	同左（报告图 3 图注另标 A570M，口径不一，见 03 章）
训练方式	基于 DeepSeek-OCR 继续训练	从一代 checkpoint 初始化，后训练 1 个 epoch
许可	MIT（权重与代码均开放）
获取渠道	GitHub / Hugging Face / ModelScope / 百度云	同左 + 百度 AI 开放平台（公测）
社区数据	一代：开源 5 天 GitHub Star 破万，四榜第一；截至 10 月 HF 累计下载超 1000 万次、GitHub 约 2.85 万 Star，获 Yann LeCun 转发

一个容易忽略的信号：一代四个月就拿到 1000 万次下载与 2.85 万 Star，说明「长文档一次性解析」是真实需求，不是论文指标驱动的伪需求。二代的真正对手不是通用大模型，而是团队自己上一代已经占领的存量场景。

02问题解剖：长文档解析卡在两个地方，而一代只修好了一个

理解 SR-SWA 的前提，是先接受一个不太直观的事实——OCR 的成本大头不是「看」，是「回忆」。

形式化：一个解码步到底要看多少东西

报告把多页解析写成一个序列转录任务：给定有序文档 D = (P1 … PN)，在第 t 步，模型操作的输入是

X_t = Concat( V₁, …, V_N, y_<t )
V 是各页视觉 token，y 是已经生成的文本

两个求和项都会膨胀，但膨胀方式不同：

文本历史 y<t 随输出变长。一页 OCR 的输出动辄上千 token，抄 100 页就是十万级 token 的历史。稠密注意力下每生成一个字都要回看全部历史，KV 缓存线性增长。
视觉上下文 V1:N 随页数变长。多页一起喂进去，每一步都要对所有页的视觉 token 做注意力。页数翻倍，单步注意力开销就翻倍。

图 2 · 两重瓶颈与两代机制的作用点。一代修左、二代修右——这是理解两个版本关系的唯一关键。图中「128」来自 config.json 的 sliding_window_size。

为什么不用线性注意力或 Mamba

这是报告里最诚实的一段论证。线性注意力、状态空间模型（Mamba）也能做到每步恒定开销，但它们把历史压成一个紧凑状态。而文档解析的要求恰恰相反：要能精确看清某一页某个格子里的字。

细粒度的视觉证据一旦被压进状态向量，就很难原样取回——这不是精度调优能解决的问题，是表示能力的问题。所以 SR-SWA 选择了另一条路：保留对原始 KV 块的直接访问能力，只限制每步能访问多少块。稀疏化发生在「访问范围」，不发生在「表示压缩」。

这个取舍决定了它的边界

「只限制访问范围、不压缩表示」意味着模型永远能看清被选中的那一块，但也意味着没被选中的块等于不存在。于是所有依赖全局统计的结构判断（标题层级、全文目录、第 3 页的脚注与第 80 页的呼应）都会变弱。第 09 章会看到这个代价在指标上的具体形状。

稀疏注意力的两条路线，以及它站在哪一边

报告的相关工作部分把已有方案分成两类，这个分类很实用：

路线	代表	怎么选块	代价
硬选择	CSA（DeepSeek-V4）、MSA（MiniMax）	离散 top-k 路由，不可微	通常需要辅助监督或 warmup 才能训稳
可微路由	DashAttention、HiLS	路由分数可微或前向积分，直接进注意力	实现复杂度高，需要专门的 kernel 支持
SR-SWA	本文	α-entmax 产生稀疏分布 → top-k 块 → 概率转 log-prior 作注意力偏置	依赖 Triton 实现（`dash_use_triton: true`）

有个细节能佐证它确实建立在 DashAttention 之上：config.json 里这套机制的字段名全部以 dash_ 开头（dash_router、dash_topk_blocks、dash_stage0、dash_prior_floor、dash_scale_per_layer），training_stage 的值就是 dash。也就是说，SR-SWA 是把 DashAttention 的路由思路搬到「页 × 块」这个二维结构上，并针对 OCR 的页级局部性做了门控。

03架构：一个 3B 的 MoE，把视觉压到每页 273 个 token

它不是从零训的多模态模型，而是站在 DeepSeek-OCR 肩上做的一次「注意力层手术」。理解这一点，才能理解为什么四个月就能迭代一代。

三段式结构

整个模型可以拆成三段：视觉编码器（DeepEncoder，SAM-ViT-B 与 CLIP-L/14 双塔）→ 线性投影（2048 → 1280）→ MoE 解码器（12 层，全部注意力层替换为 SR-SWA）。这是一条单向管线，没有交叉注意力，也没有额外的版面检测分支——版面理解是解码器「顺手」学出来的，不是单独模块输出的。

表 2 · 从 `config.json` 读出的硬事实（非官方叙述，可直接复核）
模块	字段	值	含义
视觉编码	`vision_config.model_name`	deeplip_b_l	SAM-ViT-B + CLIP-L/14 组合
	`vision_config.image_size`	1024	单页输入分辨率
	`per_page_image_tokens`	273	每页编码后的视觉 token 数
	图 3 压缩标注	16×	报告架构图中标注的压缩倍率
解码器	`num_hidden_layers`	12	全部为 SR-SWA 层（`sparse_attention_freq` 全 1）
	`hidden_size`	1280	隐藏维；10 个注意力头 × 128
	`n_routed_experts / n_shared_experts`	64 / 2	路由专家 + 共享专家
	`num_experts_per_tok`	6	每 token 选 6 个路由专家
	`moe_intermediate_size`	896	专家中间维（很窄）
上下文	`max_position_embeddings`	131072	位置编码上限 128K
上下文	`rope_scaling`	yarn ×4	原始 32K → 扩展 128K
词表	`vocab_size`	129280	沿用 DeepSeek 系词表

参数量：三个口径，差在哪

同一份材料里出现了三个数：模型卡与报告正文写「3B 总参、每 token 激活 500M」，报告图 3 的架构图标「3B-MOE-A570M」，config.json 则不含参数总量字段。这不是笔误，而是「激活参数」到底算不算 embedding 查表的口径差异。

用 config.json 的字段可以自己算一遍（粗算，非官方）：

单个专家 FFN = 3 × 1280 × 896 ≈ 3.44M
66 个专家 × 12 层 × 3.44M ≈ 2.72B　← 总参的绝对主体
Attention（q/k/v/o）× 12 层 ≈ 78.6M
Embedding（129280 × 1280）≈ 165M
合计 ≈ 2.96B　→ 与「3B」吻合

每 token 激活 = (6 路由 + 2 共享) × 3.44M × 12 ≈ 330M + Attention 78.6M ≈ 409M
加首层 dense FFN（6848 中间维）≈ 26M　→ 约 435M
若把 Embedding 查表也算进激活：435M + 165M ≈ 600M　→ 接近图注的 A570M

结论：A500M ≈ 不含 embedding 的计算侧激活，A570M ≈ 含 embedding 的端到端激活。两者不矛盾，但官方在同一份报告里混用，说明这一版材料赶得比较急。对你我的实际影响是零，但它是一个有用的材料质量信号——第 09 章会再遇到几处类似情况。

每页 273 个 token 意味着什么

这个数字是整份报告里最容易被低估的。per_page_image_tokens: 273 意味着 1024×1024 的一页纸，被压成了不到三百个 token 的信息量。对比通用 VLM 处理一页文档动辄上千 token，这是一个数量级的压缩。

压缩带来两个后果，方向相反：

好的：视觉侧基数小。100 页 = 27,300 个视觉 token，300 页 = 81,900，都还在 128K 位置编码范围内。这是「单次前向吃整本书」在结构上可行的前提。
坏的：信息密度有限。273 个 token 要承载文字、表格、公式、图片位置，必然丢掉细节。这也解释了为什么它在单页基准上打不过专门做单页的 0.8B 小模型——压缩率是为长度服务的，不是为极限精度服务的。

一个反直觉的推论

按每页 273 视觉 token、每页约 1024 输出 token 估算，300 页文档的输出序列就超过 30 万 token，远超 131K 的位置上限。所以「无限页」在数学上从来不是靠位置编码实现的，而是靠解码阶段的分块与 KV 释放。位置编码只负责让「页」这个维度不爆——这两件事常被混为一谈，下一章分开讲。

04SR-SWA：把每步的视野钉成 640 个 token

这一章是全文技术密度最高的部分。机制本身不复杂，复杂的是它怎么在「稀疏」与「可训练」之间同时成立。

一个解码步能看见什么

SR-SWA 把每个 query 可见的 token 分成两段，两段都是固定大小：

R(q) = L(q) ∪ ⋃_{b ∈ S(q)} B_b

L(q) = 本地窗口，最近 128 个 token（sparse_local_block: 4 × sparse_block_size: 32）
S(q) = 远端被选中的块，top-16 块（sparse_topk_blocks: 16）× 每块 32 token = 512
合计 640 —— 与文档长度无关

图 3 · 上条为 SR-SWA 单步可见 token 的精确构成（128 + 512，比例 1:4）；下条为 100 页文档的完整视觉上下文（按每页 273 token 推算，非官方实测）。两条不同尺度：下条在锯齿处已被画布截断，真实长度是上条的约 43 倍，切勿按条长直接比长短。

第一层：Page Gate，先把范围从「整本书」缩到「相关页」

Page Gate 做的是页级门控：对属于第 g(q) 页的 query，只保留与该页相交的块。

C_page(q) = { b | B_b ∩ V_g(q) ≠ ∅ }
块边界与页边界不对齐，所以允许跨页块；这是它能处理跨页表格的前提

真正精巧的是位置编码怎么防止爆炸。几百页文档，视觉 + 文本的总位置号极大，RoPE 外推必然失准。SR-SWA 把每个 token 的位置拆成两段：

p_i,j = [ p_i^page , p_i,j^intra ]

p^page ∈ {0, 1}　页级坐标按 0–1 交替（config: sparse_rope_page_mod = 2）
p^intra 单调递增　页内坐标（config: sparse_rope_mode = page2d）

效果是：模型只需要分清「这一页」和「相邻那一页」，永远不会遇到「第 287 页」这种训练时没见过的绝对坐标。长度外推因此变成结构性的，而不是靠调 RoPE 的 base 或 factor 硬撑。这个设计比稀疏路由本身更容易被搬到别的长序列任务上。

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

在 Page Gate 给出的候选集里，Token Sieve 用三步完成选择：

块摘要。每个 32-token 块用一个 128 维的摘要 key 表示（sparse_index_dim: 128，sparse_num_index_heads: 1），与当前 query 算相关性得分。
α-entmax 稀疏化。普通 softmax 会给所有候选非零概率，α-entmax 会把小概率直接压成 0，天然产生稀疏分布。
取 top-k，概率转偏置。选中块的得分被转成去均值的对数先验，作为偏置直接加进注意力 logits。

α_j(q) = Softmax( q^⊤k_j / √d + 𝟙[b(j) ∈ S(q)] · β_b(j)(q) )
β_b(q) = log π_b(q) − mean_b′∈S(q) log π_b′(q)
去均值是为了只保留「块之间的相对偏好」，不引入整体尺度漂移

这一步是全篇最关键的工程决策：因为路由偏置直接参与注意力 logits，解析任务的损失可以把梯度一路传回路由器，不需要另外用稠密注意力蒸馏一个 KL 损失来「教」路由器该看哪。config.json 里 use_kl_loss: false，与报告第 3.3.2 节的表述完全一致。

参数对照：每个旋钮都在这张表里

表 3 · SR-SWA 的可调参数与默认值（取自 `config.json` 的 `sparse_attention_config`）
字段	默认	作用	调大的后果
`sparse_block_size`	32	块粒度	路由更省算力，但定位精度下降
`sparse_local_block`	4	本地窗口（4×32=128）	近处上下文更完整，开销线性上升
`sparse_topk_blocks`	16	远端块预算（16×32=512）	跨页检索更强，单步开销上升
`dash_topk_blocks`	12	路由阶段候选块数	与上一行是两套预算，需实测确认生效关系
`sparse_rope_page_mod`	2	页级坐标交替周期	页坐标不再只分「本页/邻页」，外推变难
`dash_router`	entmax_topk_perlayer	逐层独立的 entmax 路由	固定值，改动需重训
`dash_prior_floor`	0.0001	先验概率下限，防数值塌陷	路由更保守，长尾块更难被选中
`use_kl_loss`	false	是否启用蒸馏辅助损失	打开需重新准备教师信号
`dash_use_triton`	true	使用 Triton 实现的路由 kernel	关掉会显著变慢

一处需要实测确认的地方：sparse_topk_blocks: 16 与 dash_topk_blocks: 12 并存，字面上是两套块预算。合理推测是「路由阶段先粗选 12 块、主注意力阶段用 16 块」，也可能是训练与推理走不同分支。官方材料未说明这一关系，属可复核的灰色地带——真要调参，建议先跑一次 profiler 看实际生效值。

05无限视野解码：真正把显存按住的是这一半

SR-SWA 限制的是「每步算多少」，KV 缓存「存多少」是另一回事。两者常被混为一谈，这也是官方宣传里最容易被误读的地方。

问题：算得再省，也得先把所有页塞进显存

如果一次性 prefill 整份文档，所有页的视觉 KV 都要常驻显存。按报告 Figure 4 的说法，显存随页数线性增长，最终必然溢出。SR-SWA 对此无能为力——它管的是解码时「看哪些」，不管「存哪些」。

解法：重叠切块 + 边界页复用

报告的 Algorithm 1 很短，但每一步都对应一个工程决策：

1. 把 N 页切成 K 个带 1 页重叠的块　← 重叠是跨块连续性的唯一来源
2. 第一块 prefill，只有第一块携带指令 q　← 指令不重复注入，避免语义漂移
3. 解码第一块
4. 循环 k = 2..K：
　　新缓存 ← 边界页视觉 KV ⊕ 用旧缓存编码的新块 ⊕ 上一块的文本 KV 尾部
　　解码第 k 块，释放其余缓存

图 4 · 分块解码的时序。块大小由部署时环境变量控制（SGLANG_UOCR_DOC_BASE_PAGE_WINDOW / ..._GUNDAM_PAGE_WINDOW，模型卡示例为 10 页）。图中页序为示意。

效果与归因：别把两份功劳记在一个人头上

表 4 · 无限视野解码的可行性验证（报告 Table 4，MarathonDocBench 百页场景，官方实测）
方案	峰值 KV 显存（B=1）	端到端吞吐（B=16）
标准解码（全部页常驻）	47.00 GB	360 TPS
无限视野解码（分块 + 边界页复用）	1.77 GB	1,315 TPS
变化	↓ 96.2%	↑ 3.65×

这里有一个必须点明的归因陷阱：Table 4 对比的是「标准解码 vs 分块解码」，与 SR-SWA 无关。也就是说 47GB → 1.77GB 这 96% 的显存下降，功劳属于解码范式；而 7.0×/5.6× 的单步加速，功劳才属于 SR-SWA。官方通稿把两件事并列叙述，很容易让人以为是同一个机制带来的。

把两者拆开，整个方案的逻辑才清楚：

SR-SWA 管时间：让每步注意力范围恒定，所以页数增加时单步延迟不涨。
分块解码管空间：让常驻显存只有一个块的大小，所以页数增加时显存放得下。
页级位置编码管外推：让「第 N 页」不产生未见过的坐标，两者才有意义。

这就是「无限」的真实含义

不是某个机制做到了无限，而是三个机制分别拆掉了三个上限：算力上限、显存上限、位置编码上限。任何一环缺失，页数都会在某个数量级撞墙——一代缺第一环，所以停在 40 页。这个拆法也告诉你：想在自己的场景里放宽页数，先看是哪一环先撞墙，别盲目调 chunk size。

06训练：用逐页工具当老师，教出一个会跨页的学生

这一章解释了它为什么能在四个月内迭代：因为既没有重训视觉编码器，也没有重新造标注，而是把「已有的逐页能力」蒸馏成「跨页能力」。

数据引擎：1200 万文档，标签来自两个老师

环节	做法	含义
规模	200 万多页文档 + 1000 万单页文档	多页数据只占 1/6，但决定长文档能力
伪标签来源	MinerU2.5-Pro + PaddleOCR-VL-v1.6，按各自领域强项分工	两个逐页 SOTA 当老师
多样性补充	合成文档生成管线	补稀有版式，不补真实噪声
平衡过滤	用 VLM 做多维特征分析，按版式分布均衡采样	防止长尾版式被淹没
结构精修	MinerU-Popo + 启发式规则，专门调和相邻页的版面不一致	跨页连贯性是人工规则注入的

最后一行值得多看一眼。跨页表格合并这种能力，不是模型自己「悟」出来的，而是先用后处理规则在标注层面把断开的表和段落缝好，再让模型学着复现这个缝合结果。这解释了为什么它在 T-TableTEDS 上能到 71.11 而通用模型全在 26 以下——不是通用模型看不见表，是没人告诉过它们「这两半是一张表」。

训练配置：一次轻量后训练

项目	设置	解读
初始化	从 Unlimited OCR 一代 checkpoint 出发	不是从头训，视觉侧能力直接继承
训练量	1 个 epoch	典型的「换注意力结构后重新对齐」
算力	25 节点 × 8 卡 H800（共 200 卡）	相对基座训练是小规模
批次	global batch 1,600，最大序列 64K	64K 是训练长度，远小于推理时的「无限」
可训练部分	冻结 DeepEncoder 与 aligner，只训 LLM	视觉编码器完全不做域适配
优化器	AdamW + cosine 衰减，初始 lr 2.5e-4	—
框架	MS-Swift	官方称支持社区用 MS-Swift 自行微调

「冻结视觉编码器」是个双刃剑。好处是训练便宜、视觉能力稳定；代价是遇到训练分布外的扫描质量（低分辨率传真、强透视的手机拍照、印章遮挡）时，编码器无法补偿。报告自己也承认训练数据多样性有限。如果你手上的文档以这类为主，先小样本验证，不要直接按宣传的「任意文档」预期铺开。

这套方法的上限在哪

把数据引擎画成一条链，上限就很清楚：

真实文档 → MinerU2.5-Pro / PaddleOCR-VL-1.6 逐页解析 → MinerU-Popo 缝合跨页 → 人工/VLM 抽检 → 训练标签
学生的上限 ≤ 老师的单页能力 + 缝合规则能表达的跨页关系

也就是说，凡是缝合规则表达不了的跨页关系（比如「第 12 页的表格在第 47 页被引用并更新」这种语义级关联），都不会出现在训练信号里。这不是模型的缺陷，是监督信号的边界。

07评测：三个基准，三种不同的可信度

官方给了三张表。它们的信息量不一样，可信度也不一样——把三张表分开读，比看那个「84.6 / 77.1」的标题数字有用得多。

三个基准的分工

基准	文档长度	谁建的	能回答什么问题
MPDocBench	最多 30 页	第三方（Zhou 等，2026）	多页能力是否真的比通用 VLM 强
MarathonDocBench	103–300 页，100 份文档，20.5 万标注元素	百度自建	百页级是否还能维持精度
OmniDocBench v1.6	单页	第三方	为长文档做的取舍有没有伤到单页精度

指标含义先统一：Edit 类是越低越好的编辑距离，TEDS / CDM / F1 是越高越好的结构相似度；带 T- 前缀的（T-TextEdit、T-TableTEDS）专测跨页的文本与表格，不带的是页内。

图 5 · 两基准总体得分（Overall）对比。数据取自报告 Table 1 与 Table 2；条形长度按 0–100 线性换算，两基准共用同一刻度，可直接比长度。得分越高越好。

MPDocBench：赢，但没赢太多

表 5 · MPDocBench（报告 Table 1）。Edit 类越低越好，其余越高越好。第三方基准
模型	Overall↑	TextEdit↓	T-TextEdit↓	FormulaCDM↑	TableTEDS↑	T-TableTEDS↑	HeadingTEDS↑
Unlimited OCR 2	84.59	0.052	0.100	89.39	87.78	89.54	60.10
Qwen3.8-Max	78.30	0.057	0.196	89.24	85.89	67.18	48.80
Qwen-3.8-Flash-Next	77.36	0.078	0.163	86.70	86.24	88.36	45.09
Gemini-3.8-Flash	76.25	0.081	0.122	83.27	83.15	87.41	43.05
Gemini-3.1-Pro Preview	71.79	0.070	0.232	88.37	81.68	61.26	26.94
GLM-5.3-Flash	68.02	0.111	0.344	81.86	83.70	70.71	39.09
DeepSeek-4.1-Flash	66.25	0.114	0.451	82.12	80.14	87.72	32.10
Minimax-M3	62.65	0.167	0.422	81.30	77.91	76.51	40.39
Kimi-K3	60.77	0.162	0.551	41.16	75.45	81.57	39.30
Unlimited-OCR（一代）	61.89	0.167	0.605	73.71	73.51	60.76	31.58

三个观察：

领先幅度不大。84.59 对 78.30，差 6.3 分。在第三方基准上这是「明显领先」，但谈不上代际碾压。
真正拉开的是跨页项。T-TextEdit 0.100 对 0.196（一半），T-TableTEDS 89.54 对 67.18。
FormulaCDM 只赢一点。89.39 对 89.24，几乎打平。公式识别靠的是单页精度，不是长文档能力——这与它的设计取向一致。

MarathonDocBench：赢很多，但基准是自己建的

表 6 · MarathonDocBench（报告 Table 2）。一代因 40 页输入限制未参与。自建基准
模型	Overall↑	TextEdit↓	T-TextEdit↓	FormulaCDM↑	TableTEDS↑	T-TableTEDS↑	HeadingTEDS↑
Unlimited OCR 2	77.06	0.104	0.123	87.93	74.81	71.11	48.20
Kimi-K3	33.74	0.475	0.664	40.50	27.80	26.30	28.90
Gemini-3.8-Flash	28.61	0.519	0.658	26.35	23.40	19.56	27.34
Qwen-3.8-Flash-Next	27.83	0.544	0.753	28.31	25.38	21.04	21.50
Gemini-3.1-Pro Preview	26.97	0.516	0.764	30.44	28.48	21.71	9.68
Qwen3.8-Max	22.93	0.600	0.804	18.82	15.20	13.71	16.09
Minimax-M3	17.97	0.659	0.818	14.20	17.79	14.84	17.16
DeepSeek-4.1-Flash	12.34	0.740	0.933	10.45	12.74	12.59	7.62
GLM-5.3-Flash	7.51	0.860	0.936	4.50	7.12	6.65	6.55

43.3 分的差距是整份报告最大的数字，也是最需要打折的数字。三个理由放在第 09 章系统讲，这里先记一句：通用大模型在这个表里普遍掉到 30 分以下，掉的方式高度一致（文本编辑距离 0.47–0.86），说明它们不是「不会解析」，而是「吃到上百页就失控」。这个现象本身是真的，只是它衡量的不是「谁的解析能力强」，而是「谁能在超长输入下不崩」。

OmniDocBench：单页上被小模型反超

表 7 · OmniDocBench v1.6 单页基准（报告 Table 3）。注意参数量一列。
模型	规模	Overall↑	TextEdit↓	FormulaCDM↑	TableTEDS↑
TeleOCR	1.2B	96.91	0.027	96.60	96.82
OvisOCR2	0.8B	96.47	0.027	97.49	94.58
Qianfan-OCR	4B	93.90	0.040	95.08	90.53
Logics-Parsing-v2	4B	93.33	0.041	95.65	88.42
ABot-OCR	2B	93.30	0.037	94.86	88.69
FireRed-OCR	2B	93.26	0.037	95.44	88.04
Unlimited-OCR 2	3B-A0.5B	94.02	0.038	96.29	89.60
Unlimited-OCR（一代）	3B-A0.5B	93.92	0.042	95.79	90.16
dots.ocr	3B	90.77	0.048	89.95	87.18
DeepSeek-OCR 2	3B-A0.5B	90.25	0.050	91.84	83.89
HunyuanOCR	1B	89.95	0.088	87.68	91.01

这张表最能说明它的定位：单页上它排第三，前两名是两个 1B 级别的小模型，比它高 2.5–2.9 分，而且它比一代只高 0.1 分。也就是说，从一代到二代，单页能力几乎没有变化——所有提升都发生在长文档维度。如果你只处理票据、截图、单页表单，这个模型没有任何理由比 0.8B 的 OvisOCR2 更值得选。

三张表合起来读出的结论

它在「多页（≤30 页）」上领先但幅度有限，在「超长（100+ 页）」上领先幅度极大，在「单页」上落后于专用小模型。这条曲线不是「全面更强」，而是一条明确的能力置换：用单页精度的一点点让步，换长文档的可用性。采购时按这条曲线选场景，不要按标题数字选。

08效率：为什么「注意力少 43 倍」只换来「快 7 倍」

这一章算一笔官方没算的账。算清楚了，你就知道在什么页数区间它才开始划算。

图 6 · 每步可见 token 数随页数变化。折线为可精确推算的量（per_page_image_tokens: 273 × 页数），不是实测延迟；单步延迟的实测倍率见正文的 7.0×/5.6×。注意 2 页处两条线几乎重合（546 对 640）——短文档上稀疏化没有收益，甚至略贵，这解释了为什么它的优势要到 20 页以后才显现。

一笔官方没算的账

按 273 token/页推算，100 页文档的完整视觉上下文是 27,300 个 token，而 SR-SWA 每步只看 640 个——注意力范围压缩了约 43 倍。但官方实测的端到端加速是 7.0 倍（对 Full Attention）、5.6 倍（对一代 R-SWA）。差额去哪了？

答案是固定开销封顶。单步解码的成本大致可以拆成三块：

单步成本 ≈ 注意力计算（∝ 可见 token 数） + MoE 权重读取（∝ 激活参数，固定） + kernel 启动与调度（固定）
把第一项压到接近 0，后两项还在，所以总成本有个地板

这也解释了图 6 里一个反直觉的现象：在 2–5 页这种短文档上，SR-SWA 并不占优势，因为那时完整上下文本来就只有几百到一千多个 token，稀疏化省不出什么，反而多了一层路由开销。优势要到 20 页以后才开始显现，50–100 页才拉开量级。换句话说，页数低于二十，用它没有意义。

表 8 · 官方效率数据与测量条件
指标	数值	测量条件	可信度
单步延迟 vs Full Attention	7.0×	Gundam 模式，batch = 3，每页固定生成 1,024 token，百页文档	官方实测
单步延迟 vs 一代 R-SWA	5.6×	Gundam 模式，batch = 3，每页固定生成 1,024 token，百页文档	官方实测
峰值 KV 显存	47.0 → 1.77 GB	单序列（B=1），百页文档，仅统计 KV 不含权重	官方实测
端到端吞吐	360 → 1,315 TPS	16 并发（B=16）	官方实测
精度随长度衰减	基本平坦	2–30 / 100–149 / 150–199 / 200–249 / 250+ 分档	官方自测
极端长度演示	3,600+ 页	《哈利·波特》全七部、三体全集，非基准测试	单次演示

长度不变性：这张图藏着一个「谁在崩」的信息

报告 Figure 6(a) 把精度按长度分档画出来，基线模型的曲线在长文档端明显下坠，其中一条被标注为「fails 223p」——在 223 页处直接失败，不是分数低而是跑不出结果。Unlimited OCR 2 的曲线从 2 页到 250+ 页基本持平。

这个现象值得单独强调：长文档场景的真实门槛不是「准不准」，而是「能不能跑完」。绝大多数通用模型在百页级不是精度不够，是显存或上下文长度直接把它们挡在门外。这也是为什么第 07 章的 MarathonDocBench 分数会出现那种断崖——30 分以下的那些数字里，有相当一部分是「勉强跑完」的结果，不代表模型的解析水平。

09反证据：八个该打的折扣

这一节是全文最该被认真读的部分。官方材料没有问题，但读法会决定你得出什么结论。

先给数字分级

把全部数字按「是否可独立复算」分成三级，能省掉很多争论：

高可信

由架构直接决定，可从 config.json 与报告公式复算：640 常数、页级位置编码、KV 复用逻辑、块级稀疏性。这些不依赖基准，换谁来测都成立。

中可信

官方实测，但条件明确且可复现：47GB→1.77GB、1,315 TPS、7.0×/5.6×。换硬件数字会变，但量级关系站得住。

低可信

依赖自建基准与非对等比较：77.06 分、+43.3 的领先幅度。方向可能对，幅度不可直接用。

八个具体的折扣

表 9 · 官方口径与需要打的折扣
官方口径	为什么该打折	实际影响
「MarathonDocBench 77.06，领先第二名 43.3 分」	基准由百度自建；报告明说标注先用「一个强的逐页解析器」初始化再人工修订，而训练伪标签同样来自 MinerU2.5-Pro 与 PaddleOCR-VL-1.6——同一批老师既出题又判卷	方向可信（它确实能跑完百页而别人不能），幅度不可直接用
「大幅领先 Qwen / Gemini / Kimi」	通用模型被要求一次性端到端吃下 103–300 页，这不是它们的常规用法；报告没有给「通用模型 + 分段流水线」这一条基线	真实工程里大家会逐页调、再拼接，差距会显著缩小。缺的这条基线恰好是最该比的
「任意页数」「无限」	基准上限 300 页；训练最大序列 64K；3,600 页是单次演示（演示内容与硬件未完整披露）	「无限」是渐近性质，不是 SLA。千页级要自己压测
「精度与长度无关」	只在自建基准上分档验证，档位粗（50 页一档），且未给各档样本量	可作趋势参考，不能当精度承诺
规模「3B / A500M」	同一报告内出现 A500M 与 A570M 两种写法，模型卡只写 3B；差异来自是否计入 embedding（详见 03 章推算）	无实质影响，但是材料仓促的信号，提示其他细节也可能未对齐
「全面 SOTA」	单页 OmniDocBench 94.02 排第三，前两名是 0.8B 的 OvisOCR2（96.47）与 1.2B 的 TeleOCR（96.91）；比一代仅 +0.1	「SOTA」限定在长文档解析，不是全场景
跨页连续性「不丢字、不乱序、不重复」	报告只给了整篇的 T-TextEdit（0.123），没有做「块边界处 vs 块内部」的分层对比，因此无法判断 1 页重叠是否足够	这是最大的未知项。块边界恰是错误最可能聚集的地方，建议自己按边界位置抽样核对
「通用文档解析」	作者自陈训练数据多样性有限；且视觉编码器在训练中全程冻结	域外扫描质量（低清传真、强透视手机拍、印章遮挡）无补偿机制，需先小样本验证

它自己承认的两个短板

报告第 6 节写得比多数论文的 limitation 都直接，值得原样记住：

稀疏注意力不保留全局文档信息，导致对文档级结构（如标题层级）的理解受限。未来可能引入线性注意力来在恒定开销下保留全局信息。这个自陈在指标上有对应的形状——MarathonDocBench 的 HeadingTEDS 只有 48.20，是九项指标里最低的。
训练数据多样性有限，进一步的数据精修会提升鲁棒性与泛化。

这两条合起来意味着什么

它的能力是「局部精确 + 全局模糊」。抄得准，但不知道自己在抄一本书的第几章。如果你的下游任务需要文档级结构（生成目录、按章节切分、判断某段属于哪个小节），现在这个版本不是终局方案——要么自己用版面规则补层级，要么等它把线性注意力加进来。如果你的下游只需要「把这几百页变成干净的 Markdown 再进向量库」，它当前就够用。

10落地：先回答「你的文档有多长」，再谈部署

按第 08 章那笔账，页数低于二十时用它没有收益。所以选型的第一步不是比模型，是数页数。

图 7 · 选型决策树。「20 页」阈值来自第 08 章的注意力范围推算；「300 页」来自 273 × 300 ≈ 8.2 万视觉 token 仍在 131,072 位置上限内（推算）。

部署配方：官方 README 里那些「不设就出事」的参数

这些不是调优建议，是默认值会 OOM 或性能腰斩的项。原样抄下来：

表 10 · SGLang 部署关键参数（据 README 与模型卡）
参数 / 变量	建议值	不设的后果
`--mem-fraction-static`	0.7	用 0.75 在 32+ 并发下余量不足
`--max-prefill-tokens`	2048	临时张量约 `[tokens, context/32]`，4096 时显存翻倍
`--cuda-graph-bs-prefill` 最大值	＝ max-prefill-tokens	偏小回退 eager（变慢），偏大浪费 capture 显存
`full_prefill_max_req`	64	默认 8，16/32 并发会回退 eager
`SGLANG_OPT_UOCR_SAM_REL_POS_BIAS_MB`	64	默认 512，单次分配约 462 MiB 且可能 OOM
`SGLANG_UOCR_MAX_PAGE_TOKENS`	20000	每页输出守卫；过小会截断长页
`SGLANG_UOCR_EANABLE_DOC_LIMIT`	1	0 = 整文档单窗口，千页级必炸（注意官方变量名拼写就是 EANABLE）
`SGLANG_UOCR_SHM_WRAP_MODEL_DATA`	1	大 crop 张量走 `/dev/shm`，否则 pickle 开销显著
no-repeat-ngram logit processor	ngram 35	多页 window 1024 / 单页 128，不设容易复读

三个环境层面的坑：① 必须用仓库自带的定制 SGLang wheel（0.5.20.dev10），与你现有环境大概率冲突，请单独建 venv；② trust_remote_code=True 意味着加载即执行仓库内自定义代码，生产环境要先过一遍 modeling_unlimitedocr.py；③ 模型卡示例的 PDF→图像是 PyMuPDF dpi=300，低于此分辨率会直接影响识别质量。

最小验证路径：一天能跑完的四步

步	做什么	通过标准
1	拿你自己最长的一份文档（务必 > 100 页），用 Transformers 直跑单页 + 多页各一次	能跑通，输出结构（标题/表格/顺序）肉眼可读
2	抽 3 处跨页表格与 3 处跨页段落，逐字对照原文	这是它相对逐页方案的核心卖点，不过关就别继续
3	按页码位置分层抽样：块边界页 vs 块内部页各 10 页，算编辑距离	两者差距 < 2 个百分点可接受；明显偏大说明窗口要调大
4	用 SGLang 起服务，压 B=16 并发，记录 TPS 与峰值显存	与官方 1,315 TPS / 1.77GB KV 同量级即可

第 3 步是官方材料里缺的那一项，也是决定你敢不敢上生产的唯一一项。别省。

11判断

以下是观点，不是共识。依据都写在前面的章节里。

值得记住的三件事

把一个通用难题塞进边界清楚的任务里，是这次真正的贡献。「长上下文」是开放问题，但「抄书」不是——抄书天然局部，只有核对时才回看。SR-SWA 的全部合理性来自这个任务特性，而不是来自某个更强的注意力算子。这个方法论可以搬：语音转写、长视频字幕、长日志解析，都是「输入极长、输出与输入局部对齐」的同类问题。上一代论文就提过 R-SWA 适用于 ASR 与翻译。
页级 0/1 交替位置编码，是被低估的工程技巧。它不提升任何指标，但让「外推」从调参问题变成结构问题。任何做超长序列的团队都值得抄这一手。
它证明了「省算力」和「省显存」必须分开设计。SR-SWA 解决前者，分块解码解决后者，位置编码解决可表示性。三个上限，三把钥匙。只做其中一个，页数还是会在某个数量级撞墙——一代卡在 40 页就是活例子。

该用 / 不该用

现在就值得试

长篇 PDF 入库（教材、技术手册、财报、标书、论文合集），目标是转成干净 Markdown 再进向量库
跨页表格多的文档——这是它压过逐页流水线的真实差异点（T-TableTEDS 71.11 对 26 以下）
显存受限的批处理：KV 峰值 1.77GB + 约 3B 权重，单卡跑长文档的门槛低了很多
作为智能体的「读档」工具：主模型负责理解与问答，它负责把几百页扫描件转成结构化文本

现在不必试

单页票据、截图、身份证件——0.8B 级专用模型更准更省，它在 OmniDocBench 上落后两个小模型
需要文档级结构的任务：生成目录、按章节切分、判断段落所属小节——HeadingTEDS 48.20 是它最弱项
输入以低质扫描/手机拍照为主——视觉编码器冻结，无域适配能力
单次二十页以内的批量任务——稀疏化省不出收益，反而多一层路由开销

下一步会看到什么

报告自己在 limitation 里给了路线：引入线性注意力保留全局信息，同时维持每 token 恒定开销。这句话翻译过来是「想把标题层级这一项补上」。如果这个方向落地，第三代（或 2.x）最可能的指标变化是 HeadingTEDS 从 48 跳到 60 以上，而其他项基本不动。

另一条更值得关注的线索是官方把 SR-SWA 表述为通用机制（「an unlimited-horizon parsing framework」），而不是 OCR 专用。结合一代论文里「R-SWA 适用于 ASR、翻译」的说法，可以预期这套注意力会被复用到语音转写与长文档翻译上。对整个长序列建模领域，这比 OCR 分数本身更有价值。

最后一句

如果只能用一句话总结这份研究：它不是「更强的 OCR」，是「第一个能一口气读完的书童」。单页精度可以更好，全局结构还弱，基准也还需要第三方复现；但「把 3,600 页当一份文档处理，且成本不随页数涨」这件事，在此之前没有开箱可用的开源方案。价值在「能跑完」，不在「跑得最准」。

12参考来源

按证据类型分组。一手材料全部可公开复核；媒体报道只用于确认发布时间与生态数据。

一手材料

技术报告：《Unlimited OCR Works 2 — Pioneering the OCR-3.0 Era: From Long- to Unlimited-Horizon Parsing》，Baidu ERNIE Team，15 页，仓库内 PDF。本文全部机制与分数来源
模型配置：baidu/Unlimited-OCR-2 的 config.json（经 ModelScope 镜像获取）。本文所有架构字段、块大小、窗口、位置编码参数来源
代码与权重：GitHub baidu/Unlimited-OCR（含 README、定制 SGLang wheel、技术报告 PDF），Hugging Face / ModelScope baidu/Unlimited-OCR-2，MIT 许可。部署参数与推理接口来源
上一代论文：Yin et al., Unlimited OCR Works, arXiv:2606.23050（2026-06-22）。R-SWA 与 32K 单次前向的来源
评测数据集：baidu/MarathonDocBench（Hugging Face，README 指向；完整标注的开放程度需自行确认）。

官方发布信息

百度 AI 开放平台公告《【开放公测】文心 Unlimited OCR 2 开源发布，超长文档解析迎来「页数自由」》（2026-10-27）。
百度千帆公众号同题文章（含完整评测图示，但图表为图片、无文字版数值）。
百度智能云文档：cloud.baidu.com/doc/OCR/s/fmr1p39gb。

媒体报道（仅用于确认发布时间与生态数据）

新华社《文心 Unlimited OCR 2 开源发布，超长文档解析迎来「页数自由」》，2026-10-27。
科技日报《一口气读完全套〈哈利·波特〉》，2026-10-27（含 11-12 百度世界大会信息）。
中国网科技、凤凰网、腾讯新闻等转载与拆解，2026-10-27。

本文的推算项（非官方数据）

参数量拆解（专家 FFN × 层数、激活参数含/不含 embedding 的差异）—— 第 03 章。
100 页 ≈ 27,300 视觉 token、300 页 ≈ 81,900 —— 由 per_page_image_tokens: 273 换算。
「注意力范围压缩约 43 倍」与「端到端只快 7 倍」的差额解释 —— 第 08 章。
「20 页以下无收益」的阈值判断 —— 基于固定开销的相对占比推断，非实测。

复核方式：文中所有 config.json 字段都可直接下载核对；技术报告 PDF 在仓库根目录（Git LFS，需从 media.githubusercontent.com 取实体）；两张基准表的原始数值见报告 Table 1 与 Table 2。若发现本文与一手材料不符，以一手材料为准。