一张表跨了两页，第一页给出表头和单位，第二页继续列数字。逐页识别以后，两段文字可能都没有错字，但拼起来却不知道后半部分属于哪一列。长文档解析经常卡在这种关系上，而不只是单个字识别不准。
百度 Unlimited-OCR 尝试在一次解析中处理多页输入，并针对长输出调整注意力机制。本文依据 2026 年 9 月 23 日官方仓库和论文，说明怎样设计自己的验证；没有在本机运行 GPU 模型，也没有测得速度、显存或准确率。官方仓库
长输出为什么会增加解码负担
使用语言模型生成解析结果时，输出越长，通常需要维护的历史状态也越多。论文以 DeepSeek OCR 为基础，提出 Reference Sliding Window Attention，也就是 R-SWA，目标是在解码过程中控制 KV cache 与注意力计算开销。论文原文
这个改动针对的是一类资源瓶颈。它不表示输入页数可以无限增加，也不表示整台机器的内存消耗恒定。图像编码、模型权重、输入预处理和其他缓存仍然占用资源。
同样，多页同时进入上下文只是让模型有机会看到前后关系，不保证每个跨页表格都恢复正确。是否漏掉表头、单位或脚注，需要在输出中实际检查。
选型时可以把问题拆成两项：它是否更适合你的长文档结构，以及在目标硬件上能否承受任务规模。只证明其中一项，还不足以决定上线。
先准备一份能人工核对的资料
第一轮选几页到十几页的文档，包含一张跨页表、一段跨页列表和普通正文。最好是你熟悉的资料，能够说明每个检查点的正确结果。
以虚构设备目录为例，可以安排第一页表头写“重量，单位千克”，下一页继续列型号。问题分别问某型号重量、两个型号是否属于相同系列，以及脚注排除了什么情况。
另放一个空白单元格，检查模型会不会根据相邻行补出数值。空白可能表示未提供，而不是零，也不一定表示与上一行相同。评估时应把这种区别写进标准答案。
保留输入页的原始顺序与渲染参数。文件名按数字排序容易把第十页放到第二页前面，采用固定宽度编号或明确列表，可以避免预处理阶段就打乱资料。
PDF 在示例中先转为图片
官方 Transformers 示例使用 NVIDIA GPU，并给出 Python、CUDA 与依赖版本。它通过模型的单图或多图入口处理图片；PDF 示例先用 PyMuPDF逐页渲染，再把图片列表交给多页解析。
因此，“支持 PDF”不等于直接读取 PDF 的原生文字层。对于本来就能可靠抽取的电子文档，可以先保留原生解析基线，再比较是否值得使用视觉模型。
渲染分辨率需要固定。提高分辨率可能让小字更清楚，也会增加预处理和传输负担；压得太低则可能丢掉小数点与脚注。不要一边调整分辨率，一边更换模型参数，却把全部变化归因于模型。
双页扫描、旋转页、裁切不完整和低对比度页面，也应在预处理时单独标记。模型输出异常时，先看它真正收到的图像，避免在错误输入上反复调提示词。
三条运行路线怎样选
仓库提供 Transformers、vLLM 和 SGLang 相关路径。初次验证可以从与目标硬件匹配的一条开始，固定版本，不必同时部署三套环境。
Transformers 示例便于查看模型加载与调用参数。服务化框架则还涉及请求格式、并发、模型加载和服务日志。把模型变成 HTTP 接口以后，文档转图、任务队列和输出校验仍需应用自己处理。
官方示例中的单图与多页配置并不完全相同，不能把某个单图参数组合原样套到多页请求。遇到输出不完整时，先核对所用版本的示例和限制，再判断是否属于模型能力问题。
示例包含远程模型代码加载相关设置。实际部署应固定模型修订和依赖，检查采用的代码，而不是每次启动都无条件跟随最新文件。这样出现变化时，至少能复现上一轮环境。
一次处理多少页，应该由样本决定
官方示例设置了较长的输出上限，但这不是固定页数承诺。一页密集表格与一页大幅插图，对输出长度的需求不同。即使输入页数一样，解析结果也可能差很多。
可以逐步增加页数，记录输出是否完整、是否截断、是否出现重复，以及耗时与峰值显存。先找出任务开始不稳定的位置，再给实际批处理留出余量。
整篇输入有助于保留跨页上下文，但失败后可能需要重做较大范围。分组处理更容易重试，却要处理组间边界。选择分组时，尽量沿章节或表格边界切开，不要把一个跨页表格从中间截断。
如果必须保留重叠页来维持上下文，合并时按页与区域核对重复内容。直接删除相同段落可能误伤本来就重复出现的说明或表头。
重复控制不能代替完整性检查
官方推理示例提供了重复片段相关参数。它们表明长输出需要关注循环或重复，但参数并不能证明结果已经完整。
解析结束后，检查每个输入页是否有对应输出，文档末尾是否真正到达，章节编号有没有突然跳过。再查看重复段落是模型错误，还是源文档中本来就存在的页眉、表头或条款。
对表格，不仅检查行数，还要检查列对齐、单位和空值。对于公式或编号，保留原图位置，避免后处理把特殊符号清理掉以后仍宣称无损。
原始输出与清理后的版本分别保存。发现错误时，可以判断问题发生在模型生成、格式解析还是自己的去重规则中。
与逐页方案比较时，保持条件一致
比较的重点可以放在跨页关系。用同一份输入分别逐页解析和多页解析，再回答相同问题，检查引用是否能回到正确页。
字符准确率仍有价值，但不足以说明结构质量。数字都识别正确、归属却错了的表格，在实际使用中仍可能失败。可以另统计表头关联、阅读顺序、页码定位和完整性。
计时包含转图、模型推理与后处理，也分别记录各阶段。否则一个方案预先准备好图片，另一个从 PDF 开始处理，比较就不公平。
对于失败样本，保留原因而不是直接从平均值中排除。服务真正运行时，这些文件仍会进入队列，它们的重试和人工检查会影响总成本。
部署成服务，还需要哪些结果记录
每个任务保留输入摘要、模型修订、参数、图片列表和输出状态。页面顺序与原始 PDF 对照关系尤其有用，后续知识库引用或人工复核都依赖它。
并发从小规模开始测。单个任务能够完成，不代表同时处理多个长文档时显存仍足够。出现资源不足时，应让任务明确失败或重新排队，不能把半截输出当成完整结果。
服务入口也要限制文件大小、页数和请求时间。限制值来自目标机器测试，不宜照搬别人的配置。超出范围的文件可以分组处理或交给其他流程。
对超时或中断的任务，保存已完成的状态和原始响应。客户端没有收到完整结果，不能直接推断服务端没有继续计算；重试前检查任务标识，避免同一长文档反复占用资源。如果框架没有现成的任务持久化能力，就由调用层明确安排，而不把网络重连等同于推理恢复。
哪些结果足以支持采用
如果你的失败集中在跨页表格、列表延续和长输出，而该模型在相同样本上改善了这些问题，同时资源消耗可接受，就有明确的试点价值。
如果主要资料是简单电子 PDF，或者瓶颈来自旧版文档、错页与损坏扫描，先修输入和原生抽取可能更直接。模型结构上的进展不能替代资料治理。
最终可以保留一组固定回归文档，升级前重新运行。对已经发现的漏页、重复、单位丢失和截断逐项检查，再增加近期真实失败样本。这样的记录比一次演示更能说明它是否适合你的文档工作。