百度开源了Unlimited-OCR，这是一款30亿参数的文档模型，它的招牌特性不只在于读得有多准确，更在于它如何应对长度。它可以拿起一份40页的PDF，在演示中甚至是一整本书，并在单次前向传播中完成解析，同时让内存占用保持平稳。该模型采用MIT许可证，凭借30亿参数、在其混合专家设计中约有5亿活跃参数，体量小到足以在你自己的硬件上运行。

这件事为何重要，需要稍作展开。在这类读取文档的模型里，处理长序列时昂贵的部分是KV cache，也就是模型在通读一段序列时所维持的运行内存。通常这个缓存会随长度线性增长，于是文档越长，所耗费的内存和延迟就越多，而极长的文档要么被切成碎片，要么变得不切实际。让这个缓存保持平稳，正是让单次通读整本书依然廉价的原因。

百度为此采用的机制是一种它称为Reference Sliding Window Attention（即R-SWA）的注意力机制，它把缓存从线性压缩到恒定。其思路是一种拆分：模型始终能看到完整的参考内容，也就是文档的视觉token和提示词，但在输出端，解码器只保留最近生成的128个token作为它的工作记忆。因此无论它已经生成了多少页，它向前携带的内存都不会增长。它构建在DeepSeek-OCR的DeepEncoder之上，把SAM-ViT与CLIP-ViT级联，并施加16倍的token压缩，在模型开始读取之前，就把一张1024乘1024的页面变成区区256个视觉token。

数据支撑了这一设计。在OmniDocBench v1.6基准上，Unlimited-OCR取得了93.92%的总分，百度称之为新的最先进水平。在它自己的长文档测试集上，单次解析的20页文档落在0.0572的编辑距离，即便是40多页的文档也保持可用，为0.1069。更能说明问题的是延迟图表：DeepSeek-OCR每次调用的耗时会随着解码而攀升，并在对齐边界处出现尖峰，而Unlimited-OCR的延迟无论序列多长都保持为一条平直的线。按百度的说法，它彻底击败了DeepSeek-OCR，考虑到它本身就构建在DeepSeek-OCR自己的编码器之上，这一点尤为引人注目。

之所以值得关心，要回到文档实际存在的地方。企业内部大多数有用的数据都躺在长篇PDF、合同、手册和扫描书籍里，而把这些喂进检索系统，一直意味着要支付不断增长的内存税，或者把它们拆成丢失上下文的碎片。一个能在单次传播中、以恒定内存解析整份长文档，并且你可以在MIT许可证下自行部署的模型，正是对准了这个数据摄取难题。诚实的提醒依然成立：OCR基准只衡量很窄的一个切面，真正的难关是杂乱的扫描件、密集的表格和手写字迹，分数会在那里下滑，而依托DeepSeek-OCR的编码器意味着这些收益是一次架构上的精炼，而非从零开始的设计。但对长文档解析而言，恒定缓存是那种正确的想法，它会悄悄让文档AI技术栈的其余部分运行起来更便宜。