270页1899年药典一次跑完，百度OCR在3张密集表格上卡住了

一张1899年的药典扫描页，左边是发黄的纸，右边是模型重新排出的白底文本，绿色框线把条目逐块圈出来。Maziyar Panahi在X上把Merck 1899年《Manual of the Materia Medica》整本270页塞进一次请求，用一块A100跑完，耗时45分钟，解码速度约217 tokens/s。最后几页和第一页差不多快。270页里262页干净，3张密集表格出现循环，循环后一页返回空。药典里可卡因条目把吗啡列为解毒剂。1899年的剂量，不是医疗建议。

百度给这套模型起的名字是Unlimited OCR 2，开源，MIT，3B参数。它要解决的痛点是长文档解析：传统注意力在解码时每个新token都要扫更长的KV cache，页数一多，延迟和显存一起涨。KV cache可以理解为解码时保留的上下文缓存。SR-SWA把文本和视觉的注意力交互压缩到固定大小的工作参考，比如512个token，只稀疏关注当前页最相关的视觉区域，同时释放不再需要的KV cache。官方说法是每步解码延迟和内存占用几乎不随文档长度增长。

官方benchmark里，Unlimited OCR 2整体分数84.6，领先Qwen3.8-Max的78.3；100页文档每步解码比Full Attention快7.0倍，比R-SWA快5.6倍；300页内保持解析准确率。MPDocBench和MarathonDocBench都是SOTA。数据来自百度自己的模型卡和GitHub，不是独立评测。Maziyar的270页药典测试补了另一面：速度曲线确实平，但真实文档的失败模式不在benchmark的均分里。

评论区有人提醒，释放缓存仍可能丢掉罕见标注。这个担心不空。长文档OCR的难点正在从能不能读，转到会不会在密集表格上循环。3张表听上去不多，放到档案数字化、财报、药典、病历扫描这些场景，一张表卡住就可能让后面整页空白。官方服务栈默认加了no-repeat n-gram和页数守门，SGLang和vLLM里有；llama.cpp没有，所以社区GGUF转换者RX5950XT在模型卡里明确写，极少数页面可能循环，要用-n限制输出。

本地部署也别想得太顺。有人把Unlimited OCR 2转成GGUF，Q8_0 2.92GiB，Q4_K_M 2.01GiB，视觉投影器787MiB。但它需要给llama.cpp打patch，主线目前只支持v1，LM Studio和Ollama不能直接加载。转换者测过，把v2当v1跑，3页文档从第2页开始错乱，字符相似度25.4%；全注意力加普通RoPE只有5.6%。这不是换个量化文件就能解决的事。

百度把长文档解析的账算得很清楚：固定工作集，释放KV cache，让延迟和内存不随页数线性膨胀。这个方向对。Maziyar的测试也说明，270页一次请求已经能跑出可用结果，代价是3张密集表格。下一步该看失败页能不能被定位、重试、跳过，或者交给另一个模型补。均分再高零点几，不如把失败页说清楚。如果你手头有一份没人愿意碰的扫描件，先别问模型能不能读，先问它会在哪一页开始循环。