百度 Unlimited-OCR 深度解析：R-SWA 注意力机制如何用 3B 参数打爆百亿模型——从 KV Cache 常数化到端到端长文档解析的革命

一、背景：OCR 的演进与长文档困局

OCR 技术的三阶段进化

光学字符识别（OCR）不是一个新领域。从 1990 年代的 Tesseract 到 2026 年的端到端大模型，这条技术路线走了快四十年。回顾一下大致经历了三个阶段：

第一阶段（1990s-2015）：传统流水线时代。

这一阶段的 OCR 系统是典型的模块化架构：

1. 图像预处理（二值化、去噪、倾斜校正）
2. 版面分析（检测文字区域、表格、图片）
3. 文字检测（定位每个字符或文本行的位置）
4. 文字识别（对每个检测到的区域做字符识别）
5. 后处理（语言模型纠错、版面还原）

每个模块各自为政，用不同的算法甚至不同的框架来实现。比如用 OpenCV 做预处理，用 CRAFT 检测文字框，用 CRNN 识别字符，最后用语言模型兜底。问题是，每个模块的错误会逐级累积、放大。检测阶段漏了一个字符，识别阶段再怎么努力也找不回来。这就像流水线上一个工位出了次品，后面的工位只能在次品上继续加工。

第二阶段（2020-2024）：端到端 OCR 萌芽期。

随着 Transformer 和视觉语言模型的爆发，研究者开始尝试用单一模型"端到端"地完成 OCR。从输入图像直接输出文本，不再需要中间步骤的人工设计。代表工作包括 Donut、TrOCR、Nougat 等。

端到端的好处不言而喻。梯度可以端到端地传播，模型能自己学习哪些视觉特征对文字识别最有帮助，不需要人工调优中间模块。但问题也很明显——当时的模型能力有限，在复杂版式、公式、表格等场景上不如流水线方案。

第三阶段（2025-2026）：LLM 驱动的端到端时代。

2025 年底到 2026 年，DeepSeek-OCR 的发布标志着端到端 OCR 进入了新阶段。其核心洞察是：用大语言模型（LLM）做解码器，把 OCR 当作文本生成任务来做。 视觉特征通过视觉编码器打包成 token 序列，喂给 LLM，LLM 逐 token 地生成识别结果。

这个方法效果确实好。DeepSeek-OCR 在多个基准测试上大幅刷新 SOTA，让业界看到了 LLM 驱动的端到端 OCR 的潜力。

但与此同时，一个随着能力提升而来的新问题浮出水面：当文档变长，AI 越处理越慢。

长文档解析的核心悖论

人类抄一本书，抄第一页和抄第一百页，速度几乎一样。我们不会因为已经写了 100 页就变慢。

但 AI 不是这样的。

当前的主流端到端 OCR 模型都用 LLM 做解码器。LLM 的核心是 全注意力机制（Full Attention）：每生成一个 token，都要"回头看"一下之前生成的所有 token。也就是说：

• 生成第 1 个 token，只看输入（视觉 token）
• 生成第 100 个 token，要看输入 + 前 99 个输出
• 生成第 10000 个 token，要看输入 + 前 9999 个输出

这个 "回头看全部" 的操作有两个后果。

后果一：计算量呈二次增长。

全注意力的时间复杂度是 O(n²)，n 是序列总长度。输出 token 数每翻一倍，计算量翻四倍。这不是线性增长，这是爆炸性增长。

后果二：KV Cache 线性增长。

为了不重复计算，LLM 会把中间结果——Key 和 Value 矩阵——缓存起来，这就是 KV Cache。每生成一个 token，KV Cache 就增大一点。到后面，显存吃紧，速度直接垮掉。

在实际应用中，这意味着什么？当前最好的端到端 OCR 模型，处理单页文档效果顶级，但一旦遇到十几页、几十页的长文档，就不得不采用"逐页处理"的笨办法——每一页单独跑一次推理，清空缓存，再处理下一页。跨页的表格、连续的内容流、统一的版面结构……这些信息全部丢失了。

这显然不是 AGI 的路径。人类处理长文档的认知方式是连续的、有选择地记忆和遗忘的。AI 的全注意力机制虽然强大，但走了一条截然不同的路。

问题在于：输出序列的全部历史，真的都需要保留吗？

这就引出了 Unlimited-OCR 的核心贡献——Reference Sliding Window Attention（R-SWA）。

二、核心创新：R-SWA 注意力机制的数学直觉与工程实现

人类抄书的启发

Unlimited-OCR 的技术报告开篇就讲了一个类比：人类抄书。

你抄书的时候，眼睛一直看着原稿，原稿的每一个字你都能看到、都能引用。但你自己写过的字呢？你不会每写一个新字都回头把前面写过的全部读一遍。你大概记得最近几行写了什么、写到哪了，这就够了。第一章抄了什么？不记得了。但没关系，不妨碍你抄第五章。

这个观察背后有一个深刻的 insight：长程解析类任务（OCR、ASR、翻译、字幕生成）中，输出端的上下文需求是局部的，而非全局的。 模型不需要记住所有已输出的内容，只需要记住"最近一段"加上"源输入"。

这就是 R-SWA 的设计哲学。

R-SWA 的技术架构

R-SWA 把 token 分成两类，分别采用不同的注意力策略：

参考 Token（Reference Tokens）： 包括输入图像编码后的视觉 token 和系统提示词。

• 策略：全局可见，全量注意力。
• 作用：模型在任何时候都能看到完整的输入信息，不会丢失源内容。

输出 Token（Output Tokens）： 模型自己生成的历史 token。

• 策略：滑动窗口注意力，最近 N 个 token（默认 N=128）。
• 作用：超出的历史 token 自然"遗忘"，不再参与注意力计算。

形式化地描述，R-SWA 的注意力掩码可以写成：

Attention(Q, K, V) = Softmax(QK^T / √d) V

其中注意力范围为：

• 对所有参考 token：全部可见
• 对输出 token：仅对当前 token 和最近 N 个历史 token 可见

KV Cache 的常数化：从 O(L) 到 O(M+N)

这是 R-SWA 最性感的数学结果。

标准全注意力的 KV Cache 大小为 O(L)，其中 L 是总序列长度。L 从 256 增长到 32768，KV Cache 也从几十 MB 涨到几十 GB。

R-SWA 的 KV Cache 大小为 O(M + N)，其中：

• M = 参考 token 数量（常量，视觉 token 压缩后固定）
• N = 滑动窗口宽度（默认 128，常量）

也就是说，不管你生成 1000 个字还是 100000 个字，KV Cache 大小不变。 这不是渐进意义上的常数，这是真正的常数。

为了直观理解，我们做个计算：

• 全注意力模式：处理 40 页文档，生成约 10000 个 token，KV Cache ≈ 10000 × 128 × 2 × 2 bytes ≈ 5.1 GB（以 GQA 8 头、128 维为例）
• R-SWA 模式：同样任务，KV Cache = (M + 128) × 128 × 2 × 2 bytes，M≈256 视觉 token，总共约 196 KB

差距大概是 26000 倍。

为什么视觉 token 不能参与状态更新

看到这里你可能会想：既然是滑动窗口，把视觉 token 也滑进去不就行了？毕竟输入部分也可以只保留最近一段。

这正是 R-SWA 与普通滑动窗口注意力的关键区别。标准滑动窗口注意力对所有 token 一视同仁，滑到后面，前面的输入内容就看不到了。但 OCR 模型需要全程看到完整的视觉输入——因为输出 token "写到哪了" 这个信息，在滑动窗口里通过因果连续性就能保持，但"原稿长什么样"这个信息，滑动窗口里没有。

如果把视觉 token 放进滑动窗口，随着输出增长，视觉特征会逐步被"滑出"窗口。模型会逐渐"忘记"文档开头的版式和内容，导致识别精度从左到右下降。

R-SWA 通过将参考 token 排除在状态转移之外来解决这个问题。视觉 token 全程参与每个输出 token 的注意力计算，但不参与下一个 token 的隐含状态更新。这就好比你看原稿抄书，每一个字都看着原稿写，但写过就放下了，不需要把写过的东西再读一遍才能写下一个字。

正是这个设计，让 R-SWA 在长文档上保持了与单页相同的精度。

与 Flash Attention 的协同

R-SWA 不是从天而降的，它需要底层算子的支持。Flash Attention v3 内核提供了高效的块状注意力计算，R-SWA 在其上实现了常数化 KV Cache 管理。

实测数据很直观。在 FlashAttention v3 内核下：

• DeepSeek-OCR（全注意力）：per-call 延迟随解码步数一路向上攀升，超过对齐边界还有突变尖峰
• Unlimited-OCR（R-SWA）：per-call 延迟从头到尾一条平直线

这不是微小的改进，这是从"越跑越慢"到"恒定速度"的模式转变。对于需要处理数十页长文档的生产环境，这个差异直接决定了方案的可行性。

三、DeepEncoder 视觉编码：两级压缩架构

Unlimited-OCR 沿用了 DeepSeek-OCR 的经典视觉编码器——DeepEncoder，但在多页场景下做了针对性优化。

两级视觉编码

DeepEncoder 采用了两阶段级联架构：

第一阶段：SAM-ViT（视觉特征提取）

SAM（Segment Anything Model）的 ViT 编码器负责从原始图像中提取细粒度的视觉特征。SAM 的训练数据集覆盖了极其丰富的视觉场景，其 ViT 编码器对各种字体、字号、版式都有很好的泛化能力。输出特征图的分辨率与输入图像尺寸成正比。

第二阶段：CLIP-ViT（语义对齐）

CLIP-ViT 编码器将 SAM-ViT 的视觉特征映射到与语言模型对齐的语义空间。这个步骤的目的是让视觉特征和文字特征能在同一个嵌入空间中做交互。

Bridge 层：16 倍 token 压缩

这是整个视觉编码 pipeline 中最关键的工程创新。两层 ViT 之间插入了一个 bridge 层，将 SAM-ViT 输出的视觉特征做 16 倍压缩。

具体来说，一张 1024×1024 的 PDF 页面，经过 SAM-ViT 编码会产出约 4096 个视觉 token（取决于 patch size），经过 bridge 压缩后只剩下 256 个视觉 token。

这个压缩比不是随便选的。16 倍压缩意味着：

• Prefill 阶段的计算量降低 16 倍
• KV Cache 的视觉部分开销降低 16 倍
• 总序列长度大幅缩短，让长文挡成为可能

两种分辨率模式

Unlimited-OCR 支持两种推理模式：

Base 模式（1024×1024）： 适用于多页文档。每页都是标准分辨率，视觉特征一致性好，但细节能力有限。40 页文档的视觉 token 总量 = 40 × 256 = 10240 个 token，加上输出 token，刚好在 32K 上下文窗口内。

Gundam 模式（动态分辨率）： 适用于单页高精度场景。根据页面内容自动选择最佳分辨率（最高不超过 2048×2048），适用于包含小字、缩放的复杂版面。

DeepEncoder 在训练时被完全冻结，只训练 LLM 部分的参数。这个设计的 rationale 是：DeepSeek-OCR 的视觉编码器已经足够成熟，冻结它可以防止灾难性遗忘，同时减少训练计算量。

四、MoE 解码器架构：大模型时代的小模型美学

3B 总参、500M 激活

Unlimited-OCR 的解码器是一个 Mixture-of-Experts（MoE）架构的 LLM。

• 总参数量：3B（30 亿）
• 激活参数量：~500M（5 亿）
• 专家数量：未明确公开，但从 3B/500M ≈ 6 的比例推测约为 6-8 个专家
• 注意力层：全部替换为 R-SWA

3B 参数在当前大模型生态里是什么水平？GPT-5.6 是万亿级，Claude Mythos 也是万亿级。3B 连它们的零头都不到。

但激活时只用到 500M 参数，这意味着：

• 推理速度极快（参数量少 = 计算量小）
• 显存需求低（A100 80G 上可以跑大批量）
• 部署成本低（单卡即可）

而它的 benchmarks 成绩如何？我们用数据说话。

与百亿参数模型的对比

在 OmniDocBench v1.5 上：

这是一个降维打击。激活参数只有 500M 的模型，击败了 72B、100B 甚至更大的模型。性能差距不是零点几个百分点，而是 4-6 个百分点。

这个结果的启示是：对于 OCR 这类高度结构化的解析任务，模型大小不是关键，架构设计才是。

为什么 MoE 适合 OCR

MoE（混合专家）架构在通用 LLM 中已经很常见（Mixtral 8x7B、DeepSeek-V2/V3 等），但 Unlimited-OCR 把 MoE 用到 OCR 解码器上，有几个特别适配的维度：

1. 任务多样性：OCR 解码器要处理的子任务差异很大。公式识别需要精确的符号级理解，表格识别需要空间关系推理，段落文本需要语义连续性。每个专家可以专注一个子能力。

2. 参数效率：3B 总参中只有 500M 被激活，意味着推理时的计算量是 500M 级别，而不是 3B 级别。对于需要高吞吐量的 OCR 服务，这个效率优势是决定性的。

3. 稀疏门控：不同页面类型（学术论文、报纸、PPT）可能调用不同的专家组合，实现动态的"模型自适应"。

五、训练方案：轻量级续训的艺术

从 DeepSeek-OCR checkpoint 起步

Unlimited-OCR 并不是从头训练的。它的起始点是 DeepSeek-OCR 的训练好的 checkpoint。

训练配置：

• 基础模型：DeepSeek-OCR checkpoint
• 额外训练步数：仅 4000 步
• 全局 batch size：256
• 最大序列长度：32K tokens
• 硬件：8×16 A800 GPU（128 张 A800）
• 冻结部分：DeepEncoder（视觉编码器全程冻结）
• 训练部分：仅 LLM（解码器）
• 优化器：AdamW
• 学习率调度：cosine annealing，初始学习率 1e-4
• 分布式框架：Megatron-LM
• 专家并行：DeepEP，EP=4

训练数据

训练数据包括两部分：

1. 200 万单页 OCR 样本：覆盖各种文档类型（学术论文、书籍、报纸、杂志、表格、公式、手写笔记等），质量较高，标注准确。

2. 20 万多页样本：从已有的单页样本拼装而成。每样本包含 2-50 页，全部打包到 32K 序列长度内。多页样本的比例约为 1:9（多页:单页）。

拼装策略：从同一个文档的不同页面中随机抽取，保持原始顺序。每页之间插入特殊分隔 token，帮助模型识别页面边界。

为什么 4000 步就够了？

你可能疑惑：只用 4000 步续训，如何实现从 87.01 到 93.23 的飞跃？

答案是：架构变革带来的数据效率飞跃。

全注意力模式下，32K 的上下文窗口意味着每步训练的计算量是 O(32K²)。而 R-SWA 模式下，同样 32K 窗口，单步计算量只有 O(M×32K + N×32K)，大约是全模式的 1/100。

换句话说，R-SWA 让模型在同样的硬件资源下，每一轮训练能处理更多数据、学得更快。再加上 DeepEncoder 被冻结（减少参数量 90%+），剩余的可训练参数只有 500M，4000 步足够收敛。

换个角度理解：基础能力（视觉编码）已经通过 DeepSeek-OCR 的训练完成了，Unlimited-OCR 只是教会 LLM 用新的注意力模式（R-SWA）来处理长序列。这是一个"能力迁移"而非"从零学习"的过程。

六、性能基准：全方位 SOTA

OmniDocBench 全面评估

OmniDocBench 是目前业界最权威的文档解析基准之一，涵盖文字识别、公式识别、表格还原、阅读顺序重建、版面分析等多个维度。

OmniDocBench v1.5 结果：

OmniDocBench v1.6 结果：

• Unlimited-OCR：93.92（端到端 SOTA）
• Qianfan-OCR：93.90（百度千帆此前发布）
• DeepSeek-OCR 2：约 91%

Unlimited-OCR 在 v1.6 上以微弱优势领先 Qianfan-OCR，考虑到后者是 4B 参数（比 Unlimited 大 33%），这个成绩含金量更高。

文档类型全覆盖

报告按文档类型拆分了 9 大类：

注意关键词：全部提升，无一例外。这是一个非常强的信号——R-SWA 不是针对某一类文档做了 hack，而是一种通用高效的解码架构。

吞吐量：输出越长优势越大

报告测试了不同输出长度下的 TPS（tokens per second）：

输出 6144 token 时（约 6-8 页密集文本），Unlimited-OCR 比 DeepSeek-OCR 快了 35%。

而且注意趋势：全注意力的 TPS 在下降（5823→>6430），R-SWA 的 TPS 始终稳定在 7800+。这个差距随输出长度递增，到上万 token 时差距会进一步拉大。

长文档专项测试

Unlimited-OCR 的真正战场是长文档。团队自建了多页测试集：

20 页文档一次性处理，编辑距离仅 0.0572（即每 100 个字符错 5.7 个），这个精度已经接近单页水平。40 页精度有所下降（0.1069），但对于粗粒度提取（全文转写、语义搜索）仍然完全可用。

团队特别指出：40 页场景的错误主要来自 DeepEncoder 的 Base 模式（1024×1024 分辨率不足以识别小字），而非 R-SWA 的长程失效。如果配上高分辨率模式或分块编码，精度还能进一步提升。

七、代码实战：从零部署 Unlimited-OCR

从 HuggingFace 下载模型

# 克隆仓库
git clone https://github.com/baidu/Unlimited-OCR
cd Unlimited-OCR

# 安装依赖
pip install torch torchvision transformers accelerate sentencepiece

# 下载模型权重（需要先安装 git-lfs）
git lfs install
git clone https://huggingface.co/baidu/Unlimited-OCR

模型权重文件约 6GB（3B 参数，bf16 精度），下载可能较慢，建议使用 huggingface-cli 的镜像加速：

pip install huggingface_hub
export HF_ENDPOINT=https://hf-mirror.com
huggingface-cli download baidu/Unlimited-OCR --local-dir ./Unlimited-OCR

基础推理示例

import torch
from transformers import AutoModel, AutoProcessor
from PIL import Image

# 加载模型和处理器
device = "cuda" if torch.cuda.is_available() else "cpu"
model = AutoModel.from_pretrained(
    "./Unlimited-OCR",
    torch_dtype=torch.bfloat16,
    trust_remote_code=True
).to(device)
processor = AutoProcessor.from_pretrained(
    "./Unlimited-OCR", 
    trust_remote_code=True
)

# 打开单页文档
image = Image.open("document_page_1.png").convert("RGB")

# 处理输入
inputs = processor(
    images=image, 
    return_tensors="pt",
    resolution_mode="base"  # 可选 "base" (1024x1024) 或 "gundam"
).to(device)

# 生成 OCR 结果
with torch.no_grad():
    generated_ids = model.generate(
        **inputs,
        max_new_tokens=2048,
        num_beams=1,
        do_sample=False,
        temperature=1.0,
    )

# 解码输出
output_text = processor.batch_decode(
    generated_ids, 
    skip_special_tokens=True
)[0]
print(output_text)

多页文档批处理

def process_multi_page(pdf_path: str) -> str:
    """
    多页 PDF 批量识别，利用 R-SWA 的常量 KV Cache 优势
    一次性处理所有页面，而非逐页循环
    """
    from pdf2image import convert_from_path
    import torch
    
    # PDF 转图像（限制页数以防 OOM）
    images = convert_from_path(pdf_path, dpi=150)
    if len(images) > 40:
        print(f"警告：超过 40 页，截取前 40 页处理")
        images = images[:40]
    
    # 批量编码
    all_pixel_values = []
    for img in images:
        inputs = processor(images=img, return_tensors="pt", resolution_mode="base")
        all_pixel_values.append(inputs["pixel_values"])
    
    # 拼接所有视觉 token（这里简化，实际需处理跨页分隔）
    batch_input = torch.cat(all_pixel_values, dim=1)  # [1, total_patches, channels]
    
    # 一次性推理
    with torch.no_grad():
        generated_ids = model.generate(
            pixel_values=batch_input,
            max_new_tokens=len(images) * 512,  # 每页约 512 token
            num_beams=1,
            do_sample=False,
        )
    
    result = processor.batch_decode(
        generated_ids, skip_special_tokens=True
    )[0]
    
    return result

# 使用
full_text = process_multi_page("40_page_report.pdf")
print(f"总识别字符数: {len(full_text)}")

用 SGLang 部署高性能服务

SGLang 是当前最快的 LLM 推理引擎之一，已原生支持 Unlimited-OCR 的 R-SWA KV Cache 管理。

# server.py
from sglang import function, system, user, assistant, gen, set_default_backend
from sglang.lang.backend.runtime_endpoint import RuntimeEndpoint
from PIL import Image
import base64, io

@function
def ocr_document(s, image_base64, prompt="请识别这份文档的所有文字内容，保留原始格式和版式"):
    # 加载图像
    image_bytes = base64.b64decode(image_base64)
    image = Image.open(io.BytesIO(image_bytes))
    
    # 系统提示词
    s += system("你是一个专业的文档 OCR 识别助手。请精确识别图像中的文字，保留原始格式。")
    
    # 多模态输入
    s += user(text=prompt, image=image)
    
    # 生成识别结果（SGLang 自动使用 R-SWA KV Cache 管理）
    s += assistant(gen("ocr_result", max_tokens=4096))

# 设置后端（假设已经启动 SGLang 运行时托管 Unlimited-OCR）
set_default_backend(RuntimeEndpoint("http://localhost:30000"))

# 调用服务
with open("document.pdf.png", "rb") as f:
    img_b64 = base64.b64encode(f.read()).decode()

state = ocr_document(img_b64)
print(state["ocr_result"])

启动 SGLang 运行时：

python3 -m sglang.launch_server \
    --model baidu/Unlimited-OCR \
    --trust-remote-code \
    --tp 1 \
    --host 0.0.0.0 \
    --port 30000

SGLang 会自动检测模型中的 R-SWA 配置，启用常数化 KV Cache 管理。这意味着部署后，每请求的延迟不会随请求内文档页数增加而增长。

八、局限性分析与 next step

当前的边界

Unlimited-OCR 并非没有局限。技术报告坦诚地列了几点：

1. 32K 上下文并非真正"无限"。

Unlimited 的名字更多是愿景而非现实。当前训练上下文是 32K tokens，输入视觉 token（每页 256）加上输出 token（每页约 200-500），处理 40 页文档已经是极限。

真正的"无限"需要 prefill pool 或者外部检索能力，让模型学会像人一样"翻页"——需要时才去取之前页面的 KV cache。

2. Base 模式在高密度文档上精度下降。

1024×1024 的分辨率不足以识别小号字体。40 页场景的错误分析显示，90% 以上的错误来自小字、公式符号等细节，而非注意力机制。配备 Gundam 模式（动态高分辨率）可以缓解，但会增加视觉 token 数量，挤压输出空间。

3. MoE 训练稳定性。

MoE 架构的训练比密集模型更困难——专家坍缩、负载不均衡、通信开销等问题都需要精细处理。报告提到用了 DeepEP 专家并行，但未详细说明是否遇到了这些问题。

4. 没有在纯通用推理任务上验证。

R-SWA 作者明确指出，当前结果只在 OCR 这类"看源+输出"的解析类任务上成立。对于需要全局推理的复杂任务（代码生成、数学证明、长文总结），滑动窗口会不会丢失关键信息？这还需要进一步验证。

下一步计划

报告中的 roadmap 很明确：

短期（128K 上下文）：
继续训练 128K 版本的模型，让单次推理支持 100+ 页文档。这并不是简单增加 max_seq_len，还需要对 RoPE、位置编码、训练数据分布做适配。

长期（Prefill Pool）：
这才是真正有趣的路线。团队想做一个 prefill pool，让模型学会自动管理外部的 KV cache 块。推理时，模型像翻书一样，自动检索并加载需要的 prefill 块，而不是把所有内容塞进上下文窗口。

这个思路如果实现，将是长上下文推理的范式革命——上下文长度不再是硬约束，而是一个由模型自主管理的动态资源。

R-SWA 的通用性展望

R-SWA 的作者在论文标题中用 "Works" 而非 "Model"，暗示这个注意力机制不限于 OCR：

任何带参考 token 的长输出任务——ASR（自动语音识别）、机器翻译、字幕生成、语音合成——都适用同一思路。

参考 token 全程可见，输出区滑动窗口。这个模式天然适合"看着源、连续生成"的场景。

想象一下：

• ASR 任务：参考 token = 音频特征，输出就是逐字转录，转录历史不需要全局注意力
• 同声传译：参考 token = 源语言音频，输出 = 目标语言翻译
• 视频字幕生成：参考 token = 视频帧特征

这些任务的共同点是：生成的信息不是凭空创造，而是对输入的忠实映射。 对于这类任务，输出端的全局注意力可能是"过度设计"——浪费计算资源，且可能引入噪声。

当然，扩展到这些领域还需要各自的适配工作和基准验证。但方向是清晰的。

九、总结与展望

Unlimited-OCR 的技术贡献点

1. R-SWA 注意力机制：将 KV Cache 从 O(L) 常数化为 O(M+N)，从根本上解决了长文档推理的效率瓶颈。这不仅是工程优化，更是对注意力机制适用范围的重新定义。

2. DeepEncoder 的 16 倍 token 压缩：1024×1024 图像 → 256 个视觉 token，将视觉编码效率推到了极致。

3. MoE 架构的 OCR 应用：3B 总参/500M 激活的极致参数效率，以小于竞争对手 1/100 的参数量实现了 SOTA。

4. 从 DeepSeek-OCR 到 Unlimited-OCR 的迁移路线：仅 4000 步续训、冻结视觉编码器，展示了架构升级如何以最低成本实现 6+ 个百分点的性能提升。

对行业的影响

Unlimited-OCR 的出现，可能推动几个方向的转变：

1. 长文档 OCR 的真正落地。之前端到端 OCR 只能处理单页，多页要靠工程 hack。现在一次推理吃下几十页，文档数字化流水线可以大幅简化。

2. 注意力机制的"降维打击"思路。全注意力不是万能的。对特定任务，精心设计的局部注意力 + 参考注意力的组合，可能比暴力堆算力更优雅、更有效。

3. 小模型大能力路线。3B 模型打爆 100B+，验证了"架构 > 规模"的命题。对于预算有限的团队，这意味着一场思路转型——与其追求更大模型，不如花时间设计更聪明的架构。

开放生态

模型权重和代码已完全开源：

• GitHub: https://github.com/baidu/Unlimited-OCR
• HuggingFace: https://huggingface.co/baidu/Unlimited-OCR
• License: 开源许可（具体以仓库声明为准）

可以预见，Unlimited-OCR 将在 RAG 流水线、文档数字化、知识库建设等场景中快速落地。当长本文档的 OCR 不再是瓶颈，下一步的想象空间就打开了——整本书的语义索引、跨页知识图谱构建、PDF 到 Markdown 的零损失转换……这些之前因为 OCR 精度和效率被封印的应用，正在逐一解锁。

论文地址：百度 arXiv 技术报告 "Unlimited-OCR: End-to-End Long Document OCR with Reference Sliding Window Attention"

回到开头的问题：AI 处理长文档，为何越处理越慢？

因为它记住了所有"不该记住"的东西。

R-SWA 告诉我们：在正确的问题定义下，有选择地遗忘，就是最优的记忆策略。