一句话总结PaDoc 把端到端文档解析的解码图从「一条长链」改成「布局串行规划 各区域内容并发生成」的分支树靠祖先注意ancestral attention保证可见性、靠 vLLM 前缀缓存复用整页上下文——同骨干对照下吞吐翻倍、P95 延迟减半解析质量还没掉。做文档解析或 MLLM serving 的人值得一看。导语先问一个可能戳到你的问题做 RAG、做过 OCR pipeline、或者用过 MinerU 这类工具的人大概都被同一件事折磨过端到端的文档解析模型准是真准慢也是真慢。你丢一页双栏、带三个表格两个公式的论文页进去让它吐回整页 Markdown它能让你等上几十秒。原因藏在它的解码方式里——它把整页的布局、阅读顺序、每段文字、每个表格、每条公式全部展平成一条长长的自回归 token 序列然后像一个特别认真但特别慢的抄写员一个字一个字往外蹦。更要命的是自回归有条铁律前一个区域没写完后一个区域就不能动笔哪怕右下角的广告和左上角的标题八竿子打不着也得乖乖排队。那想要快怎么办传统答案是「裁剪式两阶段」——先用布局检测器把每个区域裁出来再分别识别区域之间天然能并行。快是快了可副作用很要命裁掉之后每个区域成了孤岛看不到整页上下文多栏阅读顺序、跨栏表格、图表标题和正文的对应关系特别容易出错而且每个裁出来的小块都得重新跑一遍视觉编码算力也白费。所以问题就来了能不能鱼和熊掌都要——既不裁剪、保留整页上下文又能让不同区域并行解码快手联合北大刚放的这篇 PaDocarXiv:2608.06146说能。这篇就来聊聊它怎么做到的以及为什么我觉得它值得做 serving 的人认真看一眼。想自己动手试 论文arXiv 2608.06146 代码GitHub · Longin-Yu/Padoc 基准OmniDocBench v1.6业界常用的文档解析评测集 这篇论文到底想解决什么问题先把「端到端文档解析为什么慢」这件事讲透。文档解析的任务是把一张页面图像变成结构化输出——哪些是标题、哪些是正文、阅读顺序是什么、表格怎么还原、公式怎么转写。端到端的多模态大模型MLLM简单说就是能同时读图和生成文字的大模型做法是把所有这些压成一条自回归序列一次性生成。问题在于这条序列的「关键路径长度」布局 token 加上所有区域的内容 token全得串成一串。打个比方这就像让一个抄写员抄一份多栏报纸规定他必须从左上角第一个字一路抄到右下角最后一个字、中途不许跳着抄。哪怕第四版的股市行情表和第一版的头条毫无关系他也得先把头条抄完才能动行情表。一页里区域越多、每个区域越长他排队要等的时间就越久——而且这个等待是累加起来的不是只取最慢的一个。裁剪式两阶段绕开了串行但代价前面说了丢上下文、重复视觉编码。PaDoc 要回答的研究问题一句话就能说完——在一个 MLLM 里能不能既保留完整页面上下文又把不同区域的内容解码并行起来答案藏在一个朴素到几乎像废话的观察里。️ 它的思路是什么一个直觉大部分时候区域之间是「各管各的」PaDoc 的全部巧思建立在一个看起来像废话的假设上一个区域里的内容主要由它自己那一小块图像决定跟别的区域关系不大。第三段正文写什么取决于第三段那块图的像素不太取决于第五段的表格长什么样某个公式的转写取决于那个公式区域的图像跟隔壁段落的文字无关。论文管这个叫「区域特定内容充分性」region-specific content sufficiency——听起来理所当然但它一旦成立整页的生成就能被重新拆解成两条流布局流按顺序吐出每个区域的位置和类型。这个必须串行因为区域的排布有先后依赖——要知道前面区域占了哪里才能定下一个区域的位置。内容流每个区域一条吐出该区域的文字 / 公式 / 表格。这些可以并行因为只要它依赖的布局已经生成完就不用等别的区域。再打个比方这像装修一栋楼先由一个「布局工」按顺序敲定每个房间的位置和用途布局流串行因为他要统筹整体某个房间一旦定好立马派一支装修队进去施工内容流并行因为各房间装修互不干扰所有装修队共享同一张楼层平面图。数学上这就是把解码深度从「所有区域内容长度相加」压缩成「取最长那条布局-内容路径」D 顺序 ℓ ( 布局 ) ∑ k ℓ ( Y k ) ⟹ D PaDoc max ⁡ k { ℓ ( B ≤ k ) ℓ ( Y k ) } D_{\text{顺序}} \ell(\text{布局}) \textstyle\sum_{k}\ell(Y_k) \quad\Longrightarrow\quad D_{\text{PaDoc}} \max_{k}\{\ell(B_{\leq k}) \ell(Y_k)\}D顺序​ℓ(布局)∑k​ℓ(Yk​)⟹DPaDoc​maxk​{ℓ(B≤k​)ℓ(Yk​)}这个公式的全部作用就是一句话从「排队挨个来」变成「同时开工、只等最慢的那个」——这就是并行省时间的本质。图说三种范式对比——(a) 串行端到端把所有内容排成一条长链(b) 裁剪式两阶段快但每个区域成孤岛、要重复视觉编码© PaDoc 在共享整页前缀上让内容流分叉并行兼得上下文与速度。这张图是理解整篇论文动机的钥匙。怎么让一个模型「只看自己的前缀」你可能会问道理懂了可一个自回归模型怎么让它「生成区域 k 的内容时只看区域 k 的布局、不看别的区域」答案是祖先注意ancestral attention——一套注意力可见性规则。简单说每个 token 只能看到两类东西一是它的「祖先」页面图像 → 它所属区域的布局 → 它自己在该区域内更早的位置二是同一区域里比它早的 token别的区域的布局和内容一律看不见。更妙的是这套规则在训练阶段就能用标准的下一令牌监督next-token SFT就是让模型预测下一个词的那种最普通的训练实现根本不用设计什么特殊损失函数——可见性掩码直接把「树形依赖」焊进了模型。他们还做了一个叫tree-varlen树形变长打包的工程实现把这种不规则的可见性模式拼成一次标准的 FlashAttention 调用不必存一个跟序列长度的平方成正比的巨大掩码矩阵——序列长达 16384 的时候这个细节决定了能不能训得动。图说三种注意力后端的训练单步耗时越低越快——PaDoc 用的 tree-varlen 打包最省时因为它复用了生产级 FlashAttention、不必存稠密的二次掩码Dense SDPA 最慢Flex Attention 居中。推理时把树翻译成 vLLM 的「共享前缀多请求」训练解决了推理怎么并行这里有个很漂亮的工程映射布局流和每条内容流被直接当成 vLLM 里的并发生成请求它们共享的那段「图像 布局前缀」的 KV cache键值缓存注意力计算中复用的中间结果靠 vLLM 自带的**自动前缀缓存automatic prefix caching**自动复用。换句话说PaDoc 不需要改任何推理内核——它把「树形并行」翻译成了推理引擎本来就擅长的「一堆请求共享前缀」场景。这一步是它能真正落地、而不是只停留在论文 demo 里的关键。 效果到底怎么样先说结论质量不掉速度翻倍。而且这个结论是用同一个骨干Qwen3-VL-2B对照得出来的——基线叫 Sequential SFT和 PaDoc 用一模一样的模型、一模一样的训练数据唯一差别就是解码图是「一条链」还是「一棵树」。这点很重要效率上的提升可以干净地归因到方法本身而不是靠换更大的模型刷出来的。质量这块在 OmniDocBench 上 PaDoc 拿到端到端解析器里顶级的分数Overall 94.24——端到端解析器里最顶尖那一档综合分越高越好Text Edit 0.038——文本编辑距离所有方法里最佳越低越好代表文字识别错得最少Formula CDM 95.59——公式识别准确度最佳越高越好也就是说并行解码没有付质量代价——这正是这套方法最该被记住的卖点。速度更直观单张 A800、384 页测试子集上、五个并发级别的对比⚡ 吞吐量提升67.4%–118%——拿 C16 举例原来每秒处理 0.75 页PaDoc 干到 1.64 页翻了一倍多⏱️ P95 延迟降低39.2%–54.9%——长尾请求正是 serving 最在意的指标直接砍掉四到五成图说五个并发级别下的平均解析时间与 P95 延迟——PaDoc端到端、2.1B的曲线在端到端解析器里最低最快并且接近紧凑的两阶段系统HunyuanOCR-1.5 1.0B、MonkeyOCRv2 0.7B。收益定位是「端到端范式内部的大幅加速」而非碾压所有范式。一个值得注意的趋势吞吐提升随并发升高而收窄C16 的 118% 一路降到 C256 的 67%。这其实符合直觉——并发越高、GPU 本来就越忙并行解码能填进去的「空闲空当」越少收益边际递减。但 P95 延迟全程稳定砍掉四到五成对实际用户体验的改善才是最实打实的。我倾向于把这个结果理解成PaDoc 的收益定位是「端到端范式内部的大幅加速」——它让你不必为了速度去牺牲上下文完整性、退回裁剪式两阶段。论文也很诚实地说它是「接近」紧凑的两阶段系统而不是碾压所有范式。 为什么你要关心这事跟你的关系看你属于哪类人。做文档解析 / OCR / 知识库的人这是个现成可试的 serving 加速方案。代码开源、基于 Qwen3-VL-2B参数不大、好部署、和 vLLM 集成可以直接拿去压测自己的文档流。文档解析是 RAG 的第一道工序这道工序快了、上下文又不丢不裁剪下游检索和生成的质量都跟着受益。做 MLLM serving / 推理加速的人换个角度看PaDoc 真正的贡献不是「文档解析快了」而是它示范了一套通用的结构化并行解码范式——「祖先注意 tree-varlen 打包 vLLM 前缀缓存」。任何输出具有「骨架 填充」结构的生成任务都能套这个思路大纲与各节、JSON schema 与各字段、代码骨架与各函数体……只要「填充部分之间条件独立」这个假设大致成立就能把串行链拆成并行树。关注文档智能赛道的人文档解析的 MLLM 化是这两年最明确的趋势MinerU、Dolphin、SmolDocling、Qianfan-OCR 一波接一波但 serving 成本一直是落地拦路虎。PaDoc 直接砍的就是这个成本——一倍吞吐、一半延迟对大规模文档数字化金融研报、专利、学术、政务是算得过来的账。一条可操作的建议如果你正打算把端到端 MLLM 文档解析推到生产先别急着上 Sequential 基线拿 PaDoc 的开源实现在你自己的并发场景下压一下——尤其是 P95这个数往往决定你能不能过 SLA。 理性看待该夸的夸完了也得说几个值得留个心眼的地方。第一整套方法的理论基石——「区域特定内容充分性」假设——并不是在所有文档上都成立。区域内部的文字、公式、表格确实主要由本区域视觉决定但文档里有一类信息天然跨区域多栏文档的阅读顺序读完左栏接右栏、跨页表格的延续、脚注与正文、图表标题与正文引用、公式编号互引。这些恰恰是 OmniDocBench 里「Read Order」指标考察的对象。而 PaDoc 报告了 Read Order却没单独把它和 Sequential 基线拎出来对比——这其实是我读这篇时最想核的一个数。如果在该子项上 PaDoc 落后那说明并行可能是用「跨区域建模能力」换的效率只是被文本、公式这些区域内部强项的综合分盖住了。要复用的话建议先去原文表格把这个子项翻出来。第二那 67–118% 的吞吐提升高度依赖 vLLM 的自动前缀缓存能把公共前缀的 KV 复用好用满。换一个前缀缓存较弱或不支持的推理后端比如某些 TensorRT-LLM / SGLang 配置收益大概率缩水。论文把实现锚定在 vLLM 上没给跨后端的验证——如果你的技术栈不是 vLLM落地前得自己测一遍。第三训练门槛摆在那128 张 A800、约 1100 万样本个人复现基本不现实。不过代码开源、模型基于 Qwen3-VL-2B推理侧试一试是完全可以的这已经是诚意之举。总的来说这是一篇方法巧互信息假设 → 因式分解 → 祖先注意、工程实vLLM 集成、不改正文内核、收益大吞吐翻倍、P95 减半、质量不掉的扎实工作不是那种只刷分的论文。带上「假设何时会失效」「收益是否绑死后端」这两个问题去读你能从里面拿走的东西会比看摘要多得多。作者lusca版本lusca-paper-blog v1.5.0出处https://github.com/yjmm10/lusca-skill/tree/main/skills/lusca-paper-blog