AI 早报
产品上新

百度 Unlimited-OCR 登四榜第一:用恒定 KV cache 把 32K 长度一次吃下几十页文档

不止分数登顶——核心创新在注意力层:把解码端 KV cache 钉死,显存不随输出长度增长,从而把长文档 OCR 从『拼接分段』工程难题变成端到端单次推理。

2026年6月30日 · 周二 深度报告 中置信 重要度 5/5
#OCR#百度#开源模型#MoE#长文档#R-SWA#DeepSeek-OCR#HuggingFace#GitHub
本文要点
  • 解码端 KV cache 状态迁移:由『随输出长度线性增长(标准 self-attention / MLA)』→『恒定(R-SWA)』,整本数十页 PDF 在 32K 窗口内单次推理
  • 长文档 OCR 工程边界:由『分段切批 + 多次调用 + 后处理拼接』→『单次请求』,把传统 OCR pipeline 的『分段头脚合并』难题下沉到模型内
  • DeepSeek-OCR 视觉压缩范式的产业化:由『论文级技术报告』→『带 vLLM/SGLang/Docker 完整推理栈 + HF Spaces Demo 的生产可用』

百度 Unlimited-OCR:把多页 PDF 的工程难题,塞进一次前向推理里

把视角翻过来:这件事的本质不是「又开源了一个 OCR 模型」

如果只盯着 GitHub Star 数与 Hugging Face 下载量,这个故事平平无奇——2026 年 H1 中国大厂差不多每隔一两周就要发一个开源模型,登顶几个榜单,然后留下一片讨论热度。值得花一篇深度调研来写的,是更底层的一件事:百度 PaddlePaddle 团队这次用 R-SWA 把 OCR pipeline 里那条「分页独立识别 + 后处理合并」的工程引线,从外部代码挪进了模型权重本身。

这件事放在 2026 年的长文档 AI 语境下,杠杆效应相当大。DeepSeek 在 2025-10 用 DeepSeek-OCR(arXiv 2510.18234)把「视觉压缩文本」这条路线跑通——encoder 端用 DeepEncoder 把单页压缩到 100 个 vision token 就能超 GOT-OCR2.0(256 token),<800 token 就能超 MinerU2.0(每页 6000+ token)。换句话说,encoder 这条路的 token 经济性问题,在 2025-Q4 已经基本被解决了。留给 2026 年从业者要解决的,是另一半问题:decoder 的 KV cache。

任何在生产环境跑过 DeepSeek-OCR、Qwen-VL、InternVL 长文档版的人都知道,真正卡住长文档的不是 encoder(视觉 token 已经被压到 3-5k 量级),而是 decoder:标准 self-attention 在 32K 输出时 KV cache 接近 32K × hidden × 层数 的体量,FP32 下动辄十几 GB。MLA(Multi-Head Latent Attention,Kimi / DeepSeek 路线)在 KV 压缩上激进一些,做到了『随长度亚线性增长』,但不是『恒定』。Unlimited-OCR 在 arXiv 2606.23050 的标题《Unlimited OCR Works》以及摘要里反复强调的”KV cache constant across decoding steps”,翻译到工程语言是:32K 输出长度下,显存占用与输出长度解耦——这件事一旦成真,「单卡一次解析几十页 PDF」就从理论变成落地方案。

所以接下来要回答的是三个问题:用什么方法做到(R-SWA 的核心机制)、代价是什么(不是免费午餐)、对谁有利(工程替代与商业冲撞)。

机制:为什么 R-SWA 能让 decoder 显存不再随长度增长

OCR 的计算图可以拆成「encoder 把像素压成 vision token + decoder 自回归吐出文本」两步。Unlimited-OCR 的底座是 DeepSeek-OCR 的 DeepSeek3B-MoE-A570M(总参 3B / 激活 570M),encoder 部分基本沿用,全部工程与研究赌注都压在 decoder 这一侧。

论文摘要透露的核心机制浓缩成一句话——用 R-SWA(Reference Sliding Window Attention)替换 decoder 中所有 self-attention 与 cross-attention 层,在保持 OCR 性能的同时,让 KV cache 在整个 32K 解码过程中保持恒定显存占用。

为什么这件事难、为什么这件事有意思?三件事:

第一,Sliding Window Attention(SWA)不是新东西。 Mistral 7B、LongLLaMA 在纯文本 LLM 上已经验证过这条路径:把 attention 限制在一个固定长度的窗口里,让 KV cache 随窗口大小而非序列长度增长,从而压低长上下文成本。但视觉-语言多模态方向上,直到 Unlimited-OCR 之前,没有任何可工业部署的多模态 SWA 实例——OCR / 文档理解任务对「跨页表格」「跨段引用」的远距离依赖要求,刚好是朴素 SWA 的软肋。

第二,「Reference」钩子是分水岭。 朴素 SWA 让远距离 token 看不见,R-SWA 加了一个 reference 机制作为钩子——论文里没有展开 reference 的具体形式(只说”reference information preserved”),但综合 README 里的 DeepseekOCRNoRepeatNGramLogitProcessor 与 ngram_window 参数来看,R-SWA 的 reference 并不是简单地把历史 token 全量存下来,而是用某种压缩 / 摘要形式把窗口外的历史信息以低成本方式带进当前步。这与 Mistral 7B 的纯 SWA、Google 的 InfLLM、StreamingLLM 思路都不完全一致,值得作为独立子研究方向。

第三,『恒定 KV cache』的工程含义是分页被吃掉了。 以前做长文档 OCR 的工程师要写「跨页表格合并」「跨段段落 ID 去重」「版心错乱重排」「横排 + 竖排 + 角标 + 脚注尾巴」这一整套后处理——所有这些工序的根源,都是因为 OCR 模型一次看不完全本 PDF,被迫把『读全文』拆成『分页独立识别 + 后处理合并』两步。R-SWA 把 decoder 显存从「随输出长度增长」压成「恒定」之后,模型一次前向就能吐完所有页的文字,这些跨页合并问题直接从外部代码下沉到模型权重里。

这件事的工程杠杆,可以拿一个真实场景量化:一份 50 页的招股书 PDF,过去要切成 50 次独立 OCR 调用、然后合并表格与段落;现在理论上一次请求,在 32K 输出窗口内完成。这不是分数涨 0.5 个点的提升,这是工程层面的『流程砍没』——把过去属于『工程师加班』的事,直接变成模型能做的事。

落地的全栈:六天把『论文 → 权重 → Demo → 推理框架官方支持 → Docker』铺齐

如果只看方法创新,Unlimited-OCR 只是另一个值得 arXiv 收录的 OCR 工作。真正让人侧目的是它在 2026-06-22 到 2026-06-28 这六天里把整套工业推理栈一次性铺齐——这件事的节奏,在开源 OCR 历史上是没有先例的。

日期事件为什么这一步关键
2025-10-21DeepSeek-OCR(arXiv 2510.18234)发布,3B/570M MoE + DeepEncoder 路线公开给 Unlimited-OCR 留好了底座与可改造的 attention 起点
2026-06-22百度 PaddlePaddle 推 baidu/Unlimited-OCR,HF baidu/Unlimited-OCR 模型卡 MIT 协议同步上线论文没发的当天,权重已经能被下载,意味着工作不是「先写论文再加代码」
2026-06-23论文《Unlimited OCR Works》(arXiv:2606.23050,17 位作者)上 arXiv;ModelScope 同步上线推理脚本论文与权重双轨,没有 PR stunt 嫌疑
2026-06-24Hugging Face Spaces 上线 Web Demo,默认用 base 配置一次解析多页 PDF用户当天就能在浏览器里点几下验证「一次解析数十页」
2026-06-28vLLM 官方 upstream 支持合并,Docker 默认 CUDA 13.0 + Hopper/CUDA 12.9 双镜像发布这是决定性的差异点:DeepSeek-OCR 当年(2025-10)上线三个月后才陆续合入 vLLM,Unlimited-OCR 第二周就位
2026-06-30实测热度:GitHub Star 12.3k、HF 月下载 429,056,Fenng 等技术 KOL 集中转发进本周四榜第一
推理参数与硬件栈(展开看)

来自 GitHub README,可直接复现的配置:

  • Transformers(NVIDIA GPU):base_size=1024,image_size 分两档:640(代号 gundam,单图,带 crop_mode=True)或 1024(代号 base,单图 / 多页 / PDF);
  • vLLM:官方 recipe 已合并,Docker 默认 CUDA 13.0,另提供 Hopper/CUDA 12.9 镜像;
  • SGLang:本地 wheel 安装,自定义 DeepseekOCRNoRepeatNGramLogitProcessor,推理脚本 infer.py;
  • 通用解码参数:max_length=32768,no_repeat_ngram_size=35,ngram_window=128(单图)/ 1024(多图);
  • 关键依赖 pin:torch==2.10.0,transformers==4.57.1,Pillow==12.1.1,einops==0.8.2,addict==2.4.0,easydict==1.13,pymupdf==1.27.2.2,psutil==7.2.2。

DeepseekOCRNoRepeatNGramLogitProcessor 这个细节值得玩味:虽然 README 没有给出完整架构图,但解码端的『no-repeat』约束通常意味着解码时 token 的重复抑制规则被改写了,这一点本身就暗示 R-SWA 与 vanilla self-attention 的差异点不只在注意力计算,还在输出端的 logit 处理——而后者在论文摘要里几乎没有展开,意味着这可能是后续会披露的另一条独立创新线索。

把这条节奏摆出来,可以看到百度这次的核心策略不是「先声夺人的单点创新」,而是「把单点创新同步工业化」——方法是国产开源模型越来越少的执行力。这也是为什么 GitHub Star 在仓库 commit 仅有 8 次的情况下冲到了 12.3k:因为 infra 团队可以直接拉镜像上线,而不需要 fork 模型自己改 attention。

对照一张表:三件事在同一坐标下重排

把 Unlimited-OCR 放进 2026 年中国 OCR / 文档 AI 的坐标里看,需要三个参照系:作为底座的 DeepSeek-OCR、作为同门老兵的 PaddleOCR-VL-1.6、作为工业化标准的 vLLM。三者在不同维度上的差异,清晰地显示 Unlimited-OCR 的定位。

维度DeepSeek-OCR(2025-10)Unlimited-OCR(2026-06)PaddleOCR-VL-1.6(2026-05)
底座架构DeepSeek3B-MoE-A570M(3B 总 / 570M 激活)同底座,改动集中在 decoder attention0.9B 单体 VLM,非 MoE
上下文窗口8K token(默认)32K token(max_length=32768)PP-StructureV3 工程拆批为主
单次多页支持需切批 + 后处理数十页 PDF 一次前向(摘要宣称)多页需要 PP-StructureV3 流水线拆分
KV cache 性质随长度增长(MoE decoder 标准 self-attention)R-SWA,恒定 KV cache单体 VLM,KV cache 仍随长度增长
推理后端Transformers / vLLM / SGLangTransformers / vLLM / SGLang / Docker Model RunnerPaddle / Transformers / ONNX / OpenVINO / TensorRT
OmniDocBench v1.6<800 token 超 MinerU2.0(出自 DeepSeek-OCR 摘要)摘要未给出官方对比分(claim 5 caveat)96.3%(PaddleOCR 仓库 README)
开源热度对照HF 月下载 2,209,138(发布近半年累计)HF 月下载 429,056(发布 8 天)GitHub Star 84.3k(发布 8 年累计)

⚠ 注意第三行的对称性:DeepSeek-OCR 与 Unlimited-OCR 是技术继承关系(同底座 / encoder 沿用),PaddleOCR-VL-1.6 与 Unlimited-OCR 是同业竞争关系(同榜单 / OmniDocBench v1.6),这是讨论这件事时不可混淆的两条线——前者看「增量创新」,后者看「市占率」。

第二行到第四行连读可以看出 Unlimited-OCR 的真实定位:不是「更大的 OCR 模型」,而是「OCR 模型的一种新推理范式」——同样的参数量、不同的 attention 实现、不同的工程可用性。这就是为什么 3B/570M 这个数字与 DeepSeek-OCR 完全一致——因为创新根本不在参数量上,在 decoder 的 attention 层。

三层影响:对企业、对云厂商、对模型路线

这一节把这件事的影响拆给三类读者看,不空喊「重大意义」。

对做长文档 AI 应用的乙方 / SaaS 团队(直接受益方): RAG、合同审查、招股书解析、扫描件底库、知识库构建这类场景,过去三年最大的工程摩擦全部是「跨页识别 + 合并」——工程师要为每个客户场景写一套分页 + 合并 + 重排的代码。Unlimited-OCR 提供了一个 max_length=32768 + 恒定 KV cache 的端到端方案之后,这层工程摩擦可以直接砍掉,转向「文档预处理 + 字段抽取 + 检索增强」。等 HF Demo 跑过自家棘手的几类文档做小批量 A/B 之后,就可以下线自研 OCR pipeline。

对云厂商 OCR API(直接压力方): 阿里云、腾讯云、华为云、百度自家智能云的 OCR API 多采用「按页计费」的商业模式,底层依赖 PaddleOCR / 自研 pipeline 实现。Unlimited-OCR + vLLM + 单卡 A100 / H100 就能跑多页 OCR,对 API 层的定价权构成正面冲击——尤其是当开源 HF 月下载量稳定突破 50 万后,客户自建 OCR pipeline 的边际成本会向「一次买卡 + 自部署」倾斜,而不是「按调用页数付费」。这事对厂商的商业 OCR API 是结构性压力,不是短期竞品冲击。

对模型路线本身(被忽视但最长远的影响): R-SWA 的思路一旦在 OCR 上被验证,几乎必然会被迁移到 ASR(语音识别输出动辄数千 token)、语音翻译(输入 5s → 输出 30s 长度)、视频字幕 OCR(每帧少量 token 但总长度极大)、多模态长文档 RAG 等同样「输出远超输入长度」的场景。论文摘要明说『R-SWA is a general attention mechanism, applicable to ASR and translation』——这不是客套话,而是作者在论文里把这件事讲成通用化方向,90 天内大概率会有 ASR 版 R-SWA 或跨模态 R-SWA 工作出现。这件事对模型路线本身的意义,可能比对 OCR 本身的意义更大。

早报观点

判断 1:这次登顶的本质不是『分数第一』,是『一次性多页 OCR 的工程天花板被砸穿』。 OmniDocBench / Fox 分数后续会跟进,但在 2026-06-30 这个时点,百度真正拿到的是『中国 OCR 工程师再也不用为长 PDF 写分页拼接代码』的入场券——这是一个比榜单分数更有杠杆的市场。谁先用、谁就能从「堆人维护 OCR pipeline」里抽身,把工程资源投到「文档级 AI 应用」本身的差异化上。

判断 2:代价要看清楚——R-SWA 不是免费午餐。 论文摘要里『保持性能』这四个字是定性表述。sliding window attention 的传统成本是对『窗口外的 token 注意力』的处理,reference 机制怎么补偿远距离依赖、有没有引入新的超参数需要工程师在生产中调,这些都要等 PDF v1 全本与开源社区的复现实验。从 DeepSeek-OCR 的复现历史看,『官方宣称 97%』到『他在 A100 上能跑出 95%』通常有 1-2 个点的工程磨损,R-SWA 同样不会例外。更要留意的还有 no_repeat_ngram_size=35 / ngram_window=128 vs 1024 这种解码端约束的副作用——它意味着同一文档多次调用可能产生差异性输出,对流水线稳定性是新挑战。

判断 3:被忽视了的两件事。 (a) DeepseekOCRNoRepeatNGramLogitProcessor 这个细节:它的存在意味着 R-SWA 不只动了 attention,还可能把解码端的 logit 处理一并改了,这才是和 vanilla DeepSeek-OCR 真正的分水岭,值得独立写成一篇子研究。(b) 与中国 OCR 老兵的同业竞速:PaddleOCR-VL-1.6 已经在 OmniDocBench v1.6 上拿到 96.3%,而 PaddleOCR 仓库 Star 已经 84.3k、月下载 200 万+,对百度自家其他 OCR 团队构成『同门 PK』。百度要警惕的是:开源 Unlimited-OCR 是否会蚕食 PaddleOCR 的商业版本定位——这是百度内部的产品矩阵问题,外部观测半年内能看出端倪。

判断 4:R-SWA 的真正战场可能在 OCR 之外。 OCR 这个赛道虽然热闹,但调用频次天花板有限(月下载百万级 vs 大语言模型 API 月调用百亿级)。如果 R-SWA 在 90 天内被证明可以推广到 ASR / 语音翻译 / 视频字幕 OCR / 多模态长 RAG,这件事的影响力维度会从「OCR 工具升级」跳到「模型架构范式」——这才是百度 PaddlePaddle 团队这次最有想象空间的押注。

反面 caveat:本文描述的『数十页 PDF 一次前向』目前仅来自论文摘要 + GitHub README,目前公开渠道未公布真实的『页数上限 + 不同文档类型(论文 / 财报 / 扫描件 / 表格密集)下的识别率』。在工业落地评估上,建议先在自家最棘手的几类文档上做小批量 A/B,再下结论是否替换现有 OCR pipeline。同时,OmniDocBench v1.6 官方对比分尚未公布——PaddleOCR-VL-1.6 的 96.3% 是当前该榜单的开源最佳,Unlimited-OCR 的真实位次,至少要等 PDF v1 才能定。

对谁有利:对内做长文档 AI 应用(RAG、合同审查、招股书解析、扫描件底库)的乙方最有利,等 HF Demo 跑过自家文档基线即可;对云厂商 OCR API 是潜在压力——Unlimited-OCR + vLLM + 单卡 A100 就能做多页 OCR,与卖『按页计费』的商业 OCR API 形成正面竞争。

30-90 天内可验证的四件事

避免空喊「未来可期」,把可验证的跟踪点列出来,而不是「继续点赞」:

  1. OmniDocBench v1.6 / Fox 长文档 benchmark 的官方分数与第三方复核。论文摘要没给数字,这是 Unlimited-OCR 当前最大可信度缺口。看 HF 仓库 leaderboard 提交、papers-with-code 列表更新,以及独立第三方测评的提交。这是「分数故事」是否成立的关键证据。
  2. GitHub Star 增速曲线。12.3k 起步,30 天内能不能破 30k、年内能否摸到 PaddleOCR(84.3k)量级,直接决定这件事是不是『年度开源模型候选』还是『半年热度』。
  3. R-SWA 思想外溢。arXiv 90 天内是否出现 ASR / 视频 OCR / 多模态长上下文版的 R-SWA 工作。如果出现了,说明 Unlimited-OCR 的『注意力创新』也被社区认可;如果只局限在 OCR,说明它的通用化尚需时间。
  4. PaddleOCR 的回应节奏。PaddlePaddle/PaddleOCR 当前 star 84.3k、月下载 200 万+;百度同门产品的相争——PaddleOCR-VL 是否在下一个版本(v3.8)里回应『一次解析多页』叙事,会告诉我们百度对这件事的内部重视程度,也告诉我们这是「公司战略」还是「团队级别探索」。

信源说明

  • GitHub baidu/Unlimited-OCR(star 12.3k、fork 967、commit 8、MIT、时间线 2026-06-22→2026-06-28):用于仓库热度、时间线、推理参数与依赖版本、致谢信息。
  • Hugging Face baidu/Unlimited-OCR 模型卡(发布 2026-06-22、月下载 429,056、点赞 1.42k、MIT、ParseBench Mean 46.17 / Text Content 86.81):用于发布时间、license、推理配置、第三方榜单引用。
  • arXiv 2606.23050 «Unlimited OCR Works»(17 位作者,2026-06-23 上 arXiv,cs.CV):用于 R-SWA 方法描述、KV cache 恒定宣称、数十页单次解析宣称、ASR/MT 迁移暗示。
  • arXiv 2510.18234 «DeepSeek-OCR: Contexts Optical Compression»(Wei/Sun/Li,2025-10-21):用于 3B/570M MoE 底座、DeepEncoder 思路、20x 压缩比 ~60% / 100 token 超 GOT-OCR2.0 的基线参照。
  • Hugging Face deepseek-ai/DeepSeek-OCR 模型卡(月下载 2,209,138、olmOCR-bench Overall 75.7、MDPBench 51.8):用于 DeepSeek-OCR 实测分数与生态规模参照。
  • PaddlePaddle/PaddleOCR 仓库(Star 84.3k、v3.7.0 at 2026-06-11):用于中国 OCR 生态基线参照、PaddleOCR-VL-1.6 96.3% OmniDocBench 对照。
  • Fenng X 介绍推文(https://x.com/Fenng/status/2071478374875455791):用于热度参考与转发链——属二手介绍,事实部分以仓库与论文为准。

显式信源限制:GitHub Star / HF 月下载为 2026-06-30 实时快照,采集后会变化;论文摘要页未给出 OmniDocBench / Fox 等长文档 benchmark 的官方数字,本文相关数值(35 DeepSeek-OCR 的 97% @ 10x、~60% @ 20x)均出自 DeepSeek-OCR 自报,需要独立第三方复核;DeepSeek-OCR 月下载 2.2M 系发布近半年累计,与 Unlimited-OCR 发布 8 天的 42.9 万同口径下不可直接比较。