百度 PaddleOCR 团队开源的 HPD-Parsing（Hierarchical Parallel Document Parsing）把文档解析从“按顺序生成整页结果”改造成“全局协调、局部并行”的执行模式。它瞄准的是一个直接影响生产系统的问题：复杂页面包含标题、正文、表格、公式和图片等不同区域，如果所有内容都挤在一条串行链路中，慢区域会拖住整页，计算资源也难以充分利用。
从单序列生成转向分层调度
传统串行解析可以抽象为：模型读取页面，然后从第一个元素开始，依次生成布局和内容，直到整页结束。这种方式实现简单，但存在两个明显限制。
一是不同区域相互阻塞。表格或公式通常比普通文本更难处理，一个复杂区域就可能抬高整页延迟。二是长文档会形成更长的生成序列，吞吐量容易受单条解码链路限制。
HPD-Parsing 引入了职责不同的两层分支：
- 主线布局分支统一理解页面结构，确定区域、层级和阅读顺序。
- 内容分支接收主线分发的局部区域，并行完成内容解析。
- 聚合阶段依据布局信息把局部结果重新装配成结构化页面。
这里的关键不是简单地“多开几个线程”，而是先由全局分支建立页面约束，再让局部任务并发执行。否则，多个识别任务即使跑得很快，也可能无法恢复正确的标题层级、跨栏顺序和图文关系。
来源摘要还提到渐进式机制，但没有给出其接口和调度细节。因此在工程实现中，不应预设具体算法；更稳妥的理解是：系统需要允许布局信息和局部内容逐步产生、逐步汇总，而不是等待所有阶段完全结束后才交付结果。
吞吐提升来自哪里
层级并行主要改变了关键路径。假设一页包含四个区域，解析耗时分别为 80、120、500 和 100 毫秒。完全串行时，内容阶段约需 800 毫秒；资源充足且任务相互独立时，并行阶段的理论下界接近最慢区域的 500 毫秒，再加上布局分析、调度和聚合成本。
实际收益会受到以下因素约束：
- 内容分支能否组成高效批次，而不是产生大量细碎请求。
- 表格、公式、文本等任务是否争抢同一块 GPU 显存。
- 页面裁剪、序列化和跨进程传输是否抵消推理收益。
- 聚合器能否稳定恢复阅读顺序，并处理分支超时或失败。
- 并发数是否有上限；无界并发通常只会把瓶颈推向显存、队列或下游服务。
因此，评估 HPD-Parsing 一类架构时，不能只看单页平均延迟。更有价值的指标包括每秒处理页数、P95/P99 延迟、GPU 利用率、区域队列等待时间、失败重试率，以及结构恢复准确率。
可以这样实践：搭一个最小层级并行解析器
下面的 Python 程序是一个可直接运行的架构示例，并非 HPD-Parsing 官方 API。它用布局分支生成区域任务，通过有界并发执行内容解析，再按照阅读顺序组装结果。接入真实系统时，可将 detect_layout 替换为布局模型，将 parse_region 替换为 OCR、表格或公式解析服务。
保存为 hierarchical_parser.py，使用 Python 3.11 或更高版本运行：
import asyncio
from dataclasses import dataclass
from time import perf_counter
@dataclass(frozen=True)
class Region:
index: int
kind: str
content: str
latency: float
async def detect_layout(page: str) -> list[Region]:
# 示例假设：布局分支已经确定区域类型和阅读顺序。
await asyncio.sleep(0.05)
return [
Region(0, "title", "层级并行文档解析", 0.08),
Region(1, "text", "主线分支理解页面结构。", 0.12),
Region(2, "table", "Q1:120,Q2:180", 0.50),
Region(3, "formula", "throughput=pages/time", 0.10),
]
async def parse_region(region: Region, slots: asyncio.Semaphore) -> dict:
async with slots:
await asyncio.sleep(region.latency) # 替换为真实模型或 HTTP 调用
return {
"index": region.index,
"type": region.kind,
"content": region.content,
}
async def parse_page(page: str, max_concurrency: int = 3) -> list[dict]:
regions = await detect_layout(page)
slots = asyncio.Semaphore(max_concurrency)
tasks = [asyncio.create_task(parse_region(r, slots)) for r in regions]
results = await asyncio.gather(*tasks)
return sorted(results, key=lambda item: item["index"])
async def main() -> None:
started = perf_counter()
result = await parse_page("demo-page.png")
elapsed = perf_counter() - started
print(f"elapsed={elapsed:.2f}s")
for block in result:
print(f"[{block['type']}] {block['content']}")
if __name__ == "__main__":
asyncio.run(main())
运行命令：
python hierarchical_parser.py
这个示例保留了三个生产系统必须具备的约束：布局分支掌握全局顺序，内容任务可以并行，信号量限制同时执行的任务数。继续改造成服务时，还应为每个区域设置超时，并让聚合器记录部分失败，而不是因为一个表格解析失败就丢弃整页。
例如，可将内容任务包装为带超时的调用：
async def parse_with_timeout(region, slots, timeout=2.0):
try:
return await asyncio.wait_for(
parse_region(region, slots),
timeout=timeout,
)
except TimeoutError:
return {
"index": region.index,
"type": region.kind,
"content": None,
"error": "timeout",
}
落地时先验证四件事
引入层级并行解析前，应先用真实文档建立基线。测试集需要覆盖多栏排版、跨页表格、公式、旋转文本、扫描件和超高分辨率页面，不能只使用布局规整的电子 PDF。
上线检查可以压缩为四项：
- 结构正确性：并行结果能否恢复阅读顺序、标题层级及区域关系。
- 资源边界：并发数、批大小、显存水位和队列长度是否可控。
- 故障隔离：单个内容分支超时后，页面能否返回带错误标记的部分结果。
- 端到端收益：在目标硬件和真实文档分布下，吞吐提升是否覆盖调度、裁剪与聚合开销。
HPD-Parsing 的价值不只是缩短一次模型推理，而是把文档解析变成可调度的分层工作流。对于批量归档、知识库入库和复杂 PDF 抽取等吞吐敏感场景，这种架构值得评估；但若页面很简单、请求量很低，额外的任务编排和结果聚合也可能得不偿失。最终决策应同时依据解析质量、尾延迟和单位页面成本。