百度开源新一代文档解析模型：3B总参、5亿激活，如何把“无限页”变成工程现实

一、问题的本质：长文档解析难在哪里

文档解析看起来是一个“输入图片、输出文字”的简单任务，但在真实业务中，它往往要面对几百页甚至上千页的合同、标书、年报、书籍与卷宗。这类场景的难点并不在于单页识别精度，而在于三个相互耦合的工程约束：

1. 上下文长度约束：多数视觉语言模型以“页”或“图块”为处理单元，跨页时依赖外部拼接逻辑。页数一多，序列长度线性增长，注意力计算与显存开销迅速失控。
2. 状态一致性约束：长文档存在页眉页脚、章节编号、表格跨页、脚注延续等结构信息。模型若在长序列中“遗忘”前文，就会出现重复输出、跳页、串行错乱等“断片”现象。
3. 吞吐与成本约束：文档解析是典型的批量任务，单页延迟与单位页成本直接决定方案能否落地。模型再准，如果一张高端加速卡只能跑几十页，工程上就不可行。

传统做法是“切分—分别解析—后处理合并”，但切分点本身会破坏跨页表格与段落连续性，后处理规则又难以覆盖所有版式。百度此次开源的新一代文档解析模型，正是试图从模型侧直接消解第一个与第二个约束，让“一次上传、整本解析”成为默认路径。

二、架构取舍：3B总参数、约5亿激活意味着什么

该模型总参数为3B，单次推理实际激活约500M（5亿）。这组数字背后是明确的设计取向：用稀疏激活换取长序列下的可行算力。

从工程视角看，参数量与激活量的分离带来三点直接收益：

• 显存占用可预期：权重常驻部分与激活部分解耦，长序列推理时的主要开销从“全参数前向”转为“激活路径 + KV缓存”，为千页级输入留出空间。
• 吞吐更稳定：激活量小意味着单token计算量可控，页数增长时延迟曲线更平缓，避免“前几页快、后几百页卡死”的退化。
• 部署门槛下移：官方披露单序列KV显存降低约96.2%，这使得一张普通消费级显卡也能承载完整长序列推理，而不必依赖多卡切分或分段卸载。

需要强调的是，轻量激活并不等于能力缩水。文档解析的核心能力是版式理解、文字识别与结构还原，这类任务对参数规模的需求远低于开放式生成，稀疏设计在这里是“把算力花在刀刃上”的合理选择。

三、评测表现：两个长文档基准上的位置

官方给出的两组数据值得逐条拆解：

基准	考察重点	页数范围	得分	名次
MarathonDocBench	百页级长文档连续解析	103–300页	77.06	第一
MPDocBench	多页跨页结构与上下文一致性	多页跨页	84.59	榜首

MarathonDocBench 的页数区间（103–300页）恰好覆盖了真实业务中最常见的“中长文档”区间——招标文件、审计报告、产品手册多落在此范围。能在该区间拿到第一，说明模型在数百页量级上仍能维持结构还原与文字识别的稳定性。

MPDocBench 则更侧重跨页能力：表格跨页拆分、章节标题延续、页码与目录对应关系。84.59 的得分表明，模型在多页上下文衔接上并非依赖后处理规则拼接，而是具备序列内的结构一致性建模能力。

两组基准合起来回答了一个关键问题：长文档解析的瓶颈正在从“单页精度”转向“长程一致性”，而这一代模型把优化重心放在了后者。

四、极限验证：从3600页到5000页的“不断片”测试

评测分数之外，更有说服力的是极限场景验证。官方演示中将一套七卷本、合计3600余页的PDF一次性输入模型，全程耗时约1小时30分，平均每页约1.5秒，翻页超过3000次且未出现中断或复读。

更具压力的验证是把四部古典长篇小说合并为一份5026页的单一PDF，不分册、不切章、整本输入。模型一路解析至第5026页，输出稳定停在全书收尾的偈语处，未出现跳页或内容错位。

这两个测试的价值在于它们同时压中了三个“魔鬼关卡”：

1. 耐力关：页数上限从上一代的数十页量级直接推到数千页量级，且后半程速度与前半程基本持平，说明延迟不随页数显著劣化。
2. 一致性关：翻到第5000页仍能正确衔接上下文，证明KV缓存与位置建模在超长序列下没有失效。
3. 真实性关：为避免“背训练数据”的质疑，验证方专门构造了一份240页、约17.3万字的原创长卷进行交叉检验，确认模型是在“真看图”而非记忆文本。

对开发者而言，这组验证的启示是：当页数上限不再是约束，文档预处理流水线可以大幅简化——省去切分策略、边界对齐与合并校验，直接降低整条链路的维护成本。

五、工程落地：如何把这套能力接进现有系统

5.1 典型调用形态

从集成角度看，长文档解析的调用可以抽象为“提交—轮询—取回”的异步模式，适合批量任务：

# 示意性伪代码：异步长文档解析流程
task = submit_parse(
    file="contract_1200_pages.pdf",
    mode="full_document",      # 整本解析，不做切分
    output=["text", "layout", "tables"],
)
while not task.finished:
    status = task.poll()
result = task.fetch()          # 返回按页组织的结构化结果

关键设计点在于输出结构：按页组织、保留版面坐标、表格单独成块，便于下游做检索增强生成（RAG）切块与结构化入库。

5.2 与检索增强链路的配合

长文档解析的直接下游通常是知识库构建。整本解析带来的好处是切块时可以看到完整结构：章节层级、表格归属、脚注对应关系都在同一份结果里，切块策略可以基于标题层级而非固定字数，显著降低“半句话被切断”的问题。

5.3 资源规划建议

• 显存：单序列KV显存大幅下降后，单卡即可承载长序列；但仍建议按“并发序列数 × 单序列缓存”估算峰值，避免多任务并发时溢出。
• 吞吐：单页约1.5秒是演示环境下的量级，实际批量任务应做压测，按页数分布（大量短文档 vs 少量超长文档）分别规划队列。
• 降级策略：对超长文档设置超时与分段兜底，虽然模型支持数千页，但工程上仍应保留“按章节分批”的可选路径，以应对极端输入。

六、选型判断：什么时候值得换用长序列方案

并非所有场景都需要“无限页”能力。以下三类需求最能体现该方案的价值：

1. 文档不可切分：合同、卷宗、标书等一旦切分就破坏法律或结构语义的场景。
2. 跨页结构密集：财报、年报、技术手册中大量跨页表格与连续章节。
3. 批处理成本敏感：需要在普通显卡上完成大批量解析，而非依赖高端集群。

反之，如果业务只是单页票据识别或短文档抽取，轻量单页模型仍是更经济的选择。长序列能力的意义在于把“能不能做”变成“怎么做得更省”，而不是替代所有短文本场景。

七、结语

百度此次开源的新一代文档解析模型，核心贡献不在于某一项指标的提升，而在于把长文档解析的工程边界向前推了一大步：3B总参、约5亿激活的稀疏设计控制了算力开销，约96.2%的KV显存下降让普通显卡可承载数千页序列，两个长文档基准的领先与5000页级极限验证则提供了可复现的能力证据。

对开发者来说，更实际的判断标准是：当你的预处理流水线里还留着“切分—合并—校验”三段代码时，或许可以重新评估——这些代码所应对的约束，是否已经被模型侧的能力消解了。