万字深度解析百度 Unlimited OCR：当 R-SWA 注意力机制让「端到端 OCR」一次性解析数十页文档——从架构设计到生产级部署的完整技术指南（2026）

一、背景：OCR 的「长文档之痛」

1.1 传统 OCR 的两条技术路线

OCR（光学字符识别）技术发展了数十年，演化出两条截然不同的技术路线。

流水线（Pipeline）架构是经典方案：先使用检测模型定位文本区域，再用识别模型逐个区域识别，最后通过启发式规则拼接结果。这种方案的优点是每个子任务相对简单、模块可独立优化；缺点是错误会沿流水线累积——检测阶段漏了一个字，识别阶段就永远不可能找回它。而且大量启发式规则意味着工程复杂度高，每换一种文档类型就要重新调参。

PaddleOCR 是流水线架构的代表，至今仍在工业界广泛使用：

# 传统流水线 OCR 的典型流程
from paddleocr import PaddleOCR

ocr = PaddleOCR(use_angle_cls=True, lang='ch')
result = ocr.ocr('invoice.jpg')

# 结果需要手动拼接
text_lines = []
for line in result[0]:
    bbox, (text, confidence) = line
    text_lines.append({
        'bbox': bbox,
        'text': text,
        'confidence': confidence
    })
# 还需要根据 bbox 坐标做阅读顺序排序和段落拼接...

端到端（End-to-End）架构是另一条路：统一神经网络直接「图像→文本序列」，抛弃了中间检测步骤。2025 年 DeepSeek OCR 的出现标志着一个里程碑——它用「高压缩率视觉编码器 + LLM 解码器」的范式，让一张 A100 一天能跑 20 万页文档，在学术界和工业界都引起了巨大震动。

1.2 端到端 OCR 的「阿克琉斯之踵」

然而 DeepSeek OCR 有一个致命短板：随着输出序列变长，KV Cache 线性增长，推理速度逐渐下降，最终要么 OOM，要么卡死。

这个问题的本质原因很简单。标准的多头注意力（MHA）机制中，每生成一个 token，KV Cache 的大小就增加一份。推导公式如下：

KV_Cache_Size = Prefix_Length + Generated_Length

其中 Prefix_Length 是视觉 token 和 prompt token 的数量，Generated_Length 是已生成的文本 token 数量。

假设一个 1024×1024 分辨率的 PDF 页面被压缩成 256 个视觉 token，而视觉 token 与文本 token 的解码压缩比大约是 1:10。那么解析 20 页文档需要：

• Prefix: 256 × 20 = 5120 个视觉 token
• Generated: 5120 × 10 = 51200 个文本 token
• 总序列长度：5120 + 51200 = 56320 个 token

在 56320 的序列长度上运行标准注意力，KV Cache 线性膨胀到数百 GB，显存撑爆只是时间问题。这就是为什么传统端到端 OCR 模型「翻一页快，翻十页开始卡，翻五十页直接 OOM」。

1.3 人类的启示：为什么抄书不会变慢？

想象你手抄一本书的场景。你不会在写第 50 页时还「回忆」第 2 页写了什么。你的注意力自然地集中在三个点上：

1. 原始源书——你要抄的内容来源
2. 刚刚写下的几个字符——保持当前位置的上下文
3. 即将要写的下一个字——推进进度

这就是「软遗忘」的本质：保留参考信息（源书），但对已输出的内容只关注最近的一小段。人类的大脑通过这种机制，在极低的认知负荷下完成了长时程的连续抄写任务。

百度 PaddlePaddle 团队抓住了这个直觉，在 2026 年 6 月开源了 Unlimited OCR——一个让端到端 OCR 模型也能像人类一样「软遗忘」的创新方案。

二、核心创新：参考滑动窗口注意力（R-SWA）

2.1 注意力计算的新范式

Unlimited OCR 的核心创新是 Reference Sliding Window Attention（R-SWA）。它不是在全注意力、稀疏注意力或线性注意力之间做工程折中，而是重新审视了「长时程解析任务中，模型到底需要关注什么」。

R-SWA 将注意力范围划分为两个固定大小的窗口：

Attention(q, K, V) = Softmax( Q · [K_ref; K_win]^T / √d ) · [V_ref; V_win]

其中：

• 参考窗口（Reference Window）：大小固定为 m。包含所有视觉 token 和 prompt token。每个生成的 token 都可以「看到」完整的图像信息。
• 滑动窗口（Sliding Window）：大小固定为 n（默认 128）。只关注最近生成的 n 个 token，更早的历史信息被「遗忘」。

关键公式如下：

对于第 t 个生成的 token，其可关注的 KV 集合为：

K_available = [K_1, K_2, ..., K_m, K_{t-n+1}, ..., K_t]
V_available = [V_1, V_2, ..., V_m, V_{t-n+1}, ..., V_t]

其中 m 是参考 token 数量（视觉 token + prompt），n 是滑动窗口大小（默认 128）。

2.2 KV Cache 管理的数学本质

R-SWA 最令人惊艳的部分是它的 KV Cache 管理策略。与传统 MHA 线性增长的 KV Cache 不同，R-SWA 的 KV Cache 大小是常数：

MHA:   Cache(t) = m + t          # 线性增长，t → ∞ 时 → ∞
R-SWA: Cache(t) = m + min(n, t)  # 有界常数，t → ∞ 时 → m + n

当 n = 128 时，无论输出多少 token，KV Cache 大小始终为 m + 128。这意味着解析 1 页和解析 100 页的推理内存开销几乎相同——这是将「不可能」变成「可能」的关键一步。

实现细节上，KV Cache 被实现为一个容量为 m + n 的队列：

1. 初始化时，预填充参考 KV（m 个 token）
2. 每生成一个新 token，将其 KV 对加入队列
3. 队列长度超过 m + n 时，弹出最早的一个输出 token 的 KV 对

2.3 R-SWA vs 标准注意力 vs 普通滑动窗口注意力

让我们用一个表格来对比三种注意力机制：

普通滑动窗口注意力（SWA） 有一个致命缺陷：它把视觉 token 也放进了滑动窗口中。随着生成过程的推进，最早的视觉 token 被驱逐出 KV Cache，导致模型「忘记」了原始图像的内容。这会造成渐进式模糊——越往后识别率越低，因为模型逐渐丢失了对源图像的感知。

R-SWA 通过将视觉 token 固定在参考窗口中，从根本上解决了这个问题。视觉 token 永远不会被驱逐，模型始终可以「看到」完整的高清图像。

三、模型架构全景

3.1 整体架构

Unlimited OCR 以 DeepSeek OCR 为基线，由三个核心组件构成：

┌─────────────────────────────────────────────────────┐
│                    Unlimited OCR                     │
├─────────────────────────────────────────────────────┤
│  ┌──────────────┐     ┌──────────────────────────┐  │
│  │  DeepEncoder  │────▶│     MoE LLM Decoder      │  │
│  │  (16x压缩)    │     │  (3B 总参 / 500M 激活)    │  │
│  │              │     │  ┌────────────────────┐  │  │
│  │ SAM-ViT →    │     │  │  R-SWA × N layers   │  │  │
│  │ 窗口注意力    │     │  │  参考窗口固定 m     │  │  │
│  │      ↓       │     │  │  滑动窗口 n=128      │  │  │
│  │ 16x压缩      │     │  └────────────────────┘  │  │
│  │      ↓       │     │  ┌────────────────────┐  │  │
│  │ CLIP-ViT →   │     │  │  KV Cache Queue     │  │  │
│  │ 全局注意力    │     │  │  容量 m+n (常数)    │  │  │
│  │              │     │  └────────────────────┘  │  │
│  └──────────────┘     └──────────────────────────┘  │
└─────────────────────────────────────────────────────┘

3.2 DeepEncoder：16 倍视觉令牌压缩

DeepEncoder 最初在 DeepSeek OCR 中提出，是 Unlimited OCR 视觉信息提取的基石。它的设计非常巧妙：

1. 阶段一：SAM-ViT（窗口注意力）
   使用 SAM（Segment Anything Model）的 ViT 编码器，以窗口注意力（Window Attention）处理原始图像，提取丰富的局部视觉特征。这相当于「粗看」整个图像，形成初步的视觉表征。

2. 16 倍令牌压缩桥接
   在 SAM-ViT 的输出和 CLIP-ViT 的输入之间，通过一个 16 倍压缩的投影层，将特征图压缩到原来的 1/16。这个压缩比例非常激进——一张 1024×1024 的 PDF 图像，原始特征图可能有 4096 个 token，压缩后只剩 256 个。

   压缩策略的核心是：用 MLP 将 4×4 的局部特征块聚合成一个 token。这样做的物理意义是：OCR 不需要像视觉理解那样保留精细的像素级信息，它只需要保留足够的文本形状、位置和语义线索，供后续的 LLM 解码器生成准确文本。

3. 阶段二：CLIP-ViT（全局注意力）
   压缩后的 token 进入 CLIP-ViT，使用全注意力建立全局的上下文关系。这相当于「细看」压缩后的特征，理解整个页面的布局和元素之间的空间关系。

这种两级编码策略的核心思想是：在编码阶段用窗口注意力处理高分辨率输入，用全局注意力建立低分辨率特征的长距离依赖，既保留了视觉保真度，又避免了在全分辨率上运行全局注意力的天价计算开销。

3.3 MoE 解码器：3B 总参，500M 激活

Unlimited OCR 的解码器采用混合专家（Mixture-of-Experts, MoE）架构：

• 总参数量：3 Billion (30 亿)
• 激活参数量：~500 Million (5 亿) —— 只有 1/6 的参数在推理时被激活
• 专家数量：具体 MoE 配置沿用了 DeepSeek OCR 的设定（推测为 8 个专家，Top-2 路由）

MoE 的核心思想是「分而治之」：不是让一个巨大的密集模型学会所有事情，而是训练多个小型「专家」模型，每个专家擅长处理某种类型的输入。路由网络（Router）为每个输入 token 选择最合适的 1-2 个专家来处理。

输入 token
    │
    ▼
┌───────────┐
│  Router    │───── expertise scores
└───────────┘
    │         \
    ▼          ▼
┌────────┐ ┌────────┐
│ Expert1 │ │ Expert2 │  ← Top-2 路由
│ (OCR    │ │ (布局   │
│  识别)  │ │  理解)  │
└────────┘ └────────┘
    │         │
    └────┬────┘
         ▼
      输出

MoE 的工程意义非常实际：对于同等质量，MoE 模型的推理成本远低于同参数量的密集模型。500M 激活参数的推理开销，与 500M 参数的密集模型相当，但模型容量却是 3B 级别的。这正是 Unlimited OCR 能在高并发场景下保持 5580 TPS 的原因之一。

3.4 所有注意力层替换为 R-SWA

Unlimited OCR 与 DeepSeek OCR 最关键的架构差异在于：解码器中所有注意力层全部替换为 R-SWA。

这包括：

• 自注意力层（Self-Attention）：从标准 MHA → R-SWA
• 不做交叉注意力（Cross-Attention），因为视觉信息已经在参考窗口中

这种「全替换」策略意味着模型不再拥有「无限回顾全部历史」的能力——它必须在每一层都用同样的窗口限制来「被迫」学习如何在有限的上下文内完成任务。

论文的一个重要实验发现是：这种强制窗口化反而提升了 OCR 精度。在 OmniDocBench v1.5 上，Unlimited OCR 的文本编辑距离比 DeepSeek OCR 降低了 0.035，表格 TEDS 提升了 5.96%。直觉解释是：全注意力在长序列中可能引入无关的远距离噪声，而 R-SWA 迫使模型关注真正重要的局部信息和固定参考信息。

四、训练策略与数据引擎

4.1 数据构建

Unlimited OCR 的训练数据约为 200 万样本，其中：

多页数据的构建方式非常务实：不是去收集真正的多页文档，而是将单页数据随机拼接。这种做法确保了模型能够学会「翻页」的行为模式——在输出 <page> 分隔符后，注意力自动切换到下一页的视觉 token。

4.2 训练配置

为什么冻结 DeepEncoder？因为 DeepEncoder 在 DeepSeek OCR 训练中已经充分优化，OCR 场景下的视觉编码能力已经足够强。重新训练不仅浪费算力，还有可能破坏已有的视觉表征。这体现了工程实践中「不做不必要的事」的务实哲学。

4.3 从 DeepSeek OCR 检查点继续训练

Unlimited OCR 不是从头训练的，而是从 DeepSeek OCR 的预训练检查点继续训练。这不是简单的微调——解码器中的全部注意力层被替换为 R-SWA 后，参数结构已经发生变化。

论文的处理方式是：保留 MLP 和 MoE 路由的权重，将 MHA 的 QKV 投影权重重新初始化为 R-SWA 的形式。这个 Warm-start 策略显著缩短了训练收敛时间——4000 步的训练成本远低于从头训练的 40000 步。

五、代码实战：从部署到生产级使用

5.1 环境配置与模型下载

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

# 2. 创建虚拟环境
python3 -m venv venv
source venv/bin/activate

# 3. 安装依赖
pip install torch>=2.4.0 transformers>=4.46.0 accelerate

# 4. 从 HuggingFace 下载模型权重
pip install huggingface_hub
huggingface-cli download baidu/Unlimited-OCR --local-dir ./models/unlimited-ocr

5.2 Transformers 推理（基础用法）

import torch
from transformers import AutoModel, AutoTokenizer

device = torch.device("cuda:0")
model_path = "./models/unlimited-ocr"

tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)
model = AutoModel.from_pretrained(
    model_path,
    trust_remote_code=True,
    torch_dtype=torch.bfloat16,
    attn_implementation="flash_attention_2",
).to(device).eval()

# 单页 OCR
def ocr_single_image(image_path: str) -> str:
    from PIL import Image
    image = Image.open(image_path).convert("RGB")
    
    messages = [
        {"role": "user", "content": [
            {"type": "image", "image": image},
            {"type": "text", "text": "OCR this image to markdown."}
        ]}
    ]
    
    # 使用 R-SWA 解码（默认窗口大小 128）
    result = model.chat(messages, tokenizer=tokenizer, max_new_tokens=4096)
    return result

print(ocr_single_image("contract_page_1.jpg"))

5.3 多页 PDF 批量解析（生产级用法）

from typing import List
from pdf2image import convert_from_path
import os

def ocr_multi_page_pdf(pdf_path: str, max_pages: int = 50) -> List[str]:
    """
    多页 PDF 一次性解析。
    利用 Unlimited OCR 的 R-SWA 机制，所有页面预填充后一次性解码。
    """
    # 1. PDF 转图像
    images = convert_from_path(
        pdf_path,
        dpi=200,          # 200 DPI for 1024x1024 左右的输入
        first_page=1,
        last_page=max_pages
    )
    
    # 2. 构建多页消息
    content = []
    for i, img in enumerate(images):
        if i == 0:
            content.append({"type": "image", "image": img})
            content.append({"type": "text", "text": "OCR all pages to markdown. "})
        else:
            content.append({"type": "image", "image": img})
        content.append({"type": "text", "text": "<page>"})
    
    messages = [{"role": "user", "content": content}]
    
    # 3. 预填充（Prefill）阶段：所有视觉 token 被编码为参考 KV
    #    R-SWA 确保这些参考 KV 在整个解码过程中不会被驱逐
    result = model.chat(
        messages,
        tokenizer=tokenizer,
        max_new_tokens=32000,  # 32K 上下文
        sliding_window=128,     # R-SWA 滑动窗口大小
        temperature=0.0         # 确定性解码
    )
    
    # 4. 按 <page> 分隔符拆分
    pages = result.split("<page>")
    return [p.strip() for p in pages if p.strip()]

# 执行解析
pages = ocr_multi_page_pdf("annual_report_2025.pdf", max_pages=30)
for i, page_text in enumerate(pages):
    print(f"=== Page {i+1} ({len(page_text)} chars) ===")
    print(page_text[:200] + "...")

5.4 SGLang 高性能推理（生产部署最佳实践）

# 安装 SGLang（R-SWA 已内置支持）
pip install sglang[all]>=0.4.3

# 启动 SGLang 服务
python3 -m sglang.launch_server \
    --model baidu/Unlimited-OCR \
    --trust-remote-code \
    --tp-size 1 \
    --host 0.0.0.0 \
    --port 8000 \
    --context-length 32768 \
    --kv-cache-dtype fp8 \
    --max-running-requests 512

# 客户端调用
import requests
import base64

def sglang_ocr(pdf_path: str):
    with open(pdf_path, "rb") as f:
        b64 = base64.b64encode(f.read()).decode()
    
    response = requests.post(
        "http://localhost:8000/v1/ocr",
        json={
            "file": b64,
            "max_tokens": 32768,
            "temperature": 0.0,
            "sliding_window": 128,
        }
    )
    return response.json()["text"]

# 压测
import concurrent.futures
with concurrent.futures.ThreadPoolExecutor(max_workers=32) as ex:
    futures = [ex.submit(sglang_ocr, f"docs/doc_{i}.pdf") for i in range(100)]
    results = [f.result() for f in concurrent.futures.as_completed(futures)]

5.5 部署踩坑指南

我整理了实际部署中常见的坑和解决方案：

问题 1：Transformers 版本不兼容

Error: 'BaichuanTokenizer' object has no attribute 'sliding_window'

解决：transformers 版本需 ≥ 4.46.0，建议锁定 4.47.0 或以上。

问题 2：Flash Attention 报错

RuntimeError: FlashAttention only supports head_dim=64,128,256

解决：Unlimited OCR 的 head_dim 是 128，兼容 Flash Attention v2/v3。如果仍报错：

model = AutoModel.from_pretrained(
    model_path,
    trust_remote_code=True,
    torch_dtype=torch.bfloat16,
    attn_implementation="eager"  # 回退到 eager 模式
)

问题 3：大字体小字误识别
从长时程解析的评测数据看，40+ 页时编辑距离仍低于 0.11，错误主要源于 PDF 中的小字体文本。建议：

• 输入时提高 PDF 渲染 DPI（从 200 提到 300）
• 或者对页面中的极小字体区域做局部放大预处理

问题 4：显存不够

# 显存不够时，分块处理
model.config.sliding_window = 64  # 减小窗口大小（以精度换显存）
result = model.chat(messages, tokenizer=tokenizer, ...
    sliding_window=64)  # 覆盖默认的 128

当滑动窗口从 128 缩小到 64，KV Cache 减半，精度损失在 1-2% 以内（论文未直接测试此极端，但从 R-SWA 的渐近性能推断）。

六、性能基准与深度分析

6.1 标准基准测试：OmniDocBench SOTA

在权威的 OmniDocBench 基准上，Unlimited OCR 的表现令人印象深刻：

值得注意的是：Unlimited OCR 总体 93.92% 的成绩（OmniDocBench v1.6）是端到端 SOTA，超过了所有同类型的端到端 OCR 模型。

这证明了一个反直觉的结论：给注意力机制加上「强约束」，模型的 OCR 精度反而提升了。论文的解释是：全注意力在长输出序列中可能引入无关的远距离信息作为噪声；R-SWA 通过限制注意力范围，实际上起到了隐式的正则化作用。

6.2 长时程解析：真正的杀手锏

Unlimited OCR 与所有竞品最大的区别在长时程场景：

在 40+ 页的单次解析场景中，编辑距离还能维持在 0.11 以下——这意味着超过 89% 的字符是完全正确的。对于实际应用场景（如发票归档、合同解析、书籍数字化），这个精度已经完全可用。

6.3 推理效率：35% 的速度优势

推理效率上，R-SWA 的优势随着输出长度增长而越发显著：

这个趋势曲线是非常清晰的：输出越长，R-SWA 的恒定 KV Cache 优势越大。在短文档（256 token）场景下两者几乎没有区别，但在长文档（6144 token）场景下，Unlimited OCR 的吞吐量高出 66%——这意味着你的 API 账单直接减半。

6.4 R-SWA 的泛化潜力

论文中强调了一个重要的论点：R-SWA 不仅适用于 OCR。

任何「基于参考的长时程任务」都可以从 R-SWA 中受益：

• ASR（语音识别）：语音特征是「参考」，文本转录是「输出」。R-SWA 可以让模型在数小时的语音中保持恒定的推理速度和内存。
• 同声传译：源语言音频是「参考」，目标语言翻译是「输出」。不需要回忆 10 分钟前的完整历史，只需要最近的上下文。
• 视频字幕生成：视频帧是「参考」，生成的描述文本是「输出」。

这个通用性意味着 R-SWA 可能成为长时程 AI 任务的「基础架构」——就像 Transformer 本身超越了 NLP 领域一样。

七、局限性分析与未来方向

7.1 当前局限

Unlimited OCR 并非完美无缺。论文坦诚地列出了几个关键局限：

1. 32K 上下文上限
虽然 R-SWA 解决了解码阶段的 KV Cache 膨胀问题，但预填充（Prefill）阶段仍然受限于模型的上下文长度。DeepEncoder 的 16 倍压缩虽然已经很优秀，但 50 页文档仍然会产生约 12800 个视觉 token，加上 prompt token，预填充阶段的显存开销仍然可观。

当前 32K 的上下文限制意味着最多约 50-80 页文档。超过这个限制，模型无法预填充所有的视觉信息。

2. 小字体识别仍是瓶颈
从长时程评测数据看，40+ 页时编辑距离上升的主要原因不是 R-SWA 的「遗忘」，而是 PDF 中小字体的像素信息在经过 DeepEncoder 的 16 倍压缩后损失过多。这是一个编码器端的问题，不是解码器端的问题。

3. 训练数据分布偏差
训练数据以单页为主（9:1），多页数据通过拼接合成。合成数据虽然在分布上近似真实多页文档，但真实世界中的多页文档在页面间存在语义连贯性（例如连续段落跨越两页），这是随机拼接无法模拟的。

7.2 未来规划

论文给出了清晰的发展路线图：

短期（128K 上下文）：将模型的上下文长度扩展到 128K。这主要不是 R-SWA 的问题——R-SWA 的解码端可以轻松支持任意长度。瓶颈在预填充阶段的显存开销，需要通过更好的工程优化（如分段预填充、4-bit 量化）来解决。

长期（预填充池 + 自动翻页）：论文提出了一个极具想象力的方案——构建「预填充池」（Prefill Pool）。模型将每一页的预填充 KV 块存储在池中，在解码过程中根据需要自动获取历史页面的 KV 块，就像人类翻书一样。这种方式理论上可以实现「真正无限」的文档解析——不受上下文长度限制，只需要足够的存储空间存放预填充的 KV 块。

扩展应用：R-SWA 迁移到 ASR、翻译等基于参考的长时程任务。

八、总结与展望

8.1 这篇文章的核心结论

1. R-SWA 是长时程 OCR 的架构级突破。它用「强制关注参考 + 局部输出」的注意力模式，将 KV Cache 从线性增长压成了常数，从根本上消除了长序列推理的内存和速度瓶颈。

2. 精度不降反升。在 OmniDocBench 上，Unlimited OCR 以 93.92% 的总分刷新了端到端 SOTA。强制窗口化的注意力机制起到了隐式正则化作用，反而提升了识别精度。

3. 工程落地友好。支持 Transformers、vLLM、SGLang 三种推理框架，模型权重只有 3B 参数（激活 500M），对硬件要求低。一张 A100 可以支撑 512 路并发推理。

4. 通用潜力巨大。R-SWA 不局限于 OCR，ASR、翻译、视频字幕等「基于参考的长时程任务」可以直接受益。

8.2 对技术趋势的思考

从 DeepSeek OCR 到 Unlimited OCR，我们看到一个清晰的技术方向：大模型时代的 OCR，竞争焦点正在从「谁能认得准」转向「谁能处理得长」。

单页 OCR 的精度已经接近天花板（主流模型都在 90%+），真正的差距在于：

• 你能不能一次性处理 50 页合同？
• 你能不能在不分割文档的情况下保持恒定的推理速度？
• 你能不能把长文档 OCR 的成本降到单页 OCR 的水平？

Unlimited OCR 用 R-SWA 回答了这些问题。而更深层的启示是：当模型参数越来越多、上下文越来越长，我们可能需要重新思考「注意力」本身的定义——是不是每一个 token 都应该「注意」到所有其他的 token？人类显然不是这样工作的，R-SWA 证明了机器也可以不是。

8.3 资源链接

• 论文：Unlimited OCR: End-to-End OCR via Reference Sliding Window Attention
• 代码：github.com/baidu/Unlimited-OCR
• HuggingFace：huggingface.co/baidu/Unlimited-OCR
• 在线体验：HyperAI 在线教程