将文档AI投入生产：面向OCR与LLM管道的微服务架构

# 文档AI的工程化实践：面向生产环境的OCR与LLM流水线微服务架构
来源：https://arxiv.org/html/2605.18818
Yao Fehlis, Benjamin Bengfort, Zhangzhang Si, Vahid Eyorokon, Prema Roman, Patrick Deziel, Devon Slonaker, Steve Veldman, Ben Johnson, Joyce Rigelo, Michael Wharton, Steve Kramer Kungfu\.ai

###### 摘要

学术研究通常聚焦于文档理解的新模型，导致文献中在模型定义与生产规模运行模型之间存在巨大鸿沟。为弥合这一差距，我们提出了一种微服务架构，该架构封装了分类、光学字符识别（OCR）以及大语言模型结构化字段提取等多个模型的流水线，并分享了我们以每小时数千份多页文档的规模运行该流水线的实践经验。我们描述了主要的设计决策，包括混合分类策略、将GPU绑定的推理与CPU绑定的编排分离、对流水线中大量IO密集型操作采用异步处理，以及独立的水平扩展策略。通过批量性能分析，我们发现了两个塑造生产部署的意外定性发现：一是端到端延迟中，OCR而非语言模型解析占主导地位；二是系统的饱和并发度由共享GPU推理容量决定，而非工作进程数量。我们的目标是为从业者提供具体的架构模式，用以构建超越基准测试、能在生产环境中有效运行模型的文档理解系统。

## 1 引言

文档理解研究社区不断涌现模型创新——LayoutLM（Xuet al.,2020 (https://arxiv.org/html/2605.18818#bib.bib2)）、DocTR（Mindee,2021 (https://arxiv.org/html/2605.18818#bib.bib10)）、Donut（Kimet al.,2022 (https://arxiv.org/html/2605.18818#bib.bib4)）、Pix2Struct（Leeet al.,2023 (https://arxiv.org/html/2605.18818#bib.bib6)）以及数十种视觉语言模型（VLM）——每一种都在DocVQA（Mathewet al.,2021 (https://arxiv.org/html/2605.18818#bib.bib23)）和FUNSD（Jaumeet al.,2019 (https://arxiv.org/html/2605.18818#bib.bib24)）等基准测试上提升了准确率。然而，对于试图将这些模型部署到每天处理数千份表单的生产系统中的从业者而言，几乎没有关于如何使它们可靠运行所需的工程指导。

从模型检查点到按需模型服务之间存在巨大鸿沟。模型必须被容器化并部署在推理API之后。文档以异构格式到达——多页TIFF、扫描版PDF、照片——且必须在处理前进行归一化，这通常需要GPU加速操作。分类必须将每种文档路由到正确的提取流水线。OCR必须处理扫描伪影、倾斜页面和低质量图像。LLM必须用于提取字段，这些字段需经过验证并以正确的结构化形式输出。所有这些操作都必须有效封装多种模型计算范式——这些范式通常针对批处理（如训练和多实例推理）进行了高效实现，但不适用于在固定内存资源下平衡CPU、GPU和IO密集型操作时动态切换模型类型。

解决按需模型使用仅是第一步：从模型使用迈向生产系统还需要应对一系列其他挑战，包括管理失败与错误之间的差异，确定最适合模型和工作负载的配置，实施超时和重试机制以处理随机性故障，输出置信度分数等模型元信息，以及用于可解释性的模型操作追踪——这些模糊了科学研究与软件工程之间的界限。对于涉及敏感、私密和/或专有信息的部署场景，系统架构必须支持完全在安全的云安全区内和/或使用具备充分扫描、版本控制、日志记录和访问控制的本地计算平台进行数据处理。所有这些都必须在规模化条件下实现，具备可观测的故障、可预测的延迟，当然还有**可控的成本**。

本文描述了一种可扩展且容错的结构化表单处理生产系统架构，用于应对这些挑战。我们还描述了使用此架构构建的一个系统，该系统通过分类、OCR、文本拼接和基于语言模型的字段提取流水线处理扫描的多页文档。最后，我们分享了将架构部署为Kubernetes上的三个微服务（采用基于消息队列的工作分配和对象存储来存储文档）的经验，以及如何将处理文档的成本从每页0.01美元降低至每页0.001美元，同时保持96%的准确率。

我们做出三项贡献。首先，我们描述了架构及其背后的设计决策，包括为何将系统分解为三个服务而非单体架构，以及如何将GPU绑定的推理与CPU绑定的编排分离（§3 (https://arxiv.org/html/2605.18818#S3)）。其次，我们详细阐述了流水线设计，包括一种在成本与准确率之间取得平衡的混合分类策略，以及从原始图像到结构化JSON输出的流程（§4 (https://arxiv.org/html/2605.18818#S4)）。第三，我们报告了批量性能分析中的定性发现，揭示了系统的扩展行为和瓶颈，以及生产运行中汲取的经验教训（§5 (https://arxiv.org/html/2605.18818#S5)）。

## 2 相关工作

#### 文档理解模型。

模型范畴涵盖传统OCR（Tesseract（Smith,2007 (https://arxiv.org/html/2605.18818#bib.bib8)）、PaddleOCR（Duet al.,2020 (https://arxiv.org/html/2605.18818#bib.bib9)））、布局感知Transformer（LayoutLM（Xuet al.,2020 (https://arxiv.org/html/2605.18818#bib.bib2)）、LayoutLMv3（Huanget al.,2022 (https://arxiv.org/html/2605.18818#bib.bib3)））、端到端图像到文本模型（Donut（Kimet al.,2022 (https://arxiv.org/html/2605.18818#bib.bib4)）、Nougat（Blecheret al.,2023 (https://arxiv.org/html/2605.18818#bib.bib7)））、通用型VLM（Anthropic,2024 (https://arxiv.org/html/2605.18818#bib.bib21); Google DeepMind,2024 (https://arxiv.org/html/2605.18818#bib.bib22); Baiet al.,2023 (https://arxiv.org/html/2605.18818#bib.bib19)）、OCR再输入VLM的混合设计（Nacsonet al.,2024 (https://arxiv.org/html/2605.18818#bib.bib18)），以及CPU优化的开源模型如Docling（Aueret al.,2024 (https://arxiv.org/html/2605.18818#bib.bib11)）。每一种都在基准测试上提升了准确率，但未说明如何将这些组件组合成一个生产系统。

#### 生产级ML系统。

生产级ML部署的系统级描述仍比模型论文少见。TFX（Bayloret al.,2017 (https://arxiv.org/html/2605.18818#bib.bib25)）描述了谷歌的端到端ML平台。Uber的Michelangelo（Hermann and Del Balso,2017 (https://arxiv.org/html/2605.18818#bib.bib26)）和Facebook的FBLearner（Dunn,2016 (https://arxiv.org/html/2605.18818#bib.bib27)）涉及ML工作流管理。对于文档处理领域，企业级平台如ABBYY、Kofax以及云服务（AWS Textract、Google Document AI、Azure Form Recognizer）作为商业产品存在，但其架构是专有的且未在文献中记录。近期已有工作开始描述企业级和多模态文档处理系统：IDP Accelerator（Islamet al.,2026 (https://arxiv.org/html/2605.18818#bib.bib12)）提出了一种代理式文档智能框架，包含文档拆分、提取、分析和合规性验证；MMORE（Sallinenet al.,2025 (https://arxiv.org/html/2605.18818#bib.bib13)）描述了一种模块化分布式流水线，用于跨异构文件类型的多模态检索增强生成和提取；以及领域特定系统将OCR、分类器和VLM结合起来，用于保险或密集型文本的企业提取（Chenget al.,2026 (https://arxiv.org/html/2605.18818#bib.bib14); Wang and Shen,2025 (https://arxiv.org/html/2605.18818#bib.bib15)）。这些系统表明大规模文档AI是一个活跃领域；我们的重点是服务级架构以及结构化表单提取流水线的运维经验。

#### OCR 与多模态提取的对比。

无OCR和图像原生文档模型如Donut（Kimet al.,2022 (https://arxiv.org/html/2605.18818#bib.bib4)）推动了更简单的流水线，直接将页面图像发送给VLM。最近的基准测试表明，强大的多模态LLM在某些业务文档提取任务上可能媲美OCR增强方法（Shenet al.,2026 (https://arxiv.org/html/2605.18818#bib.bib16)）。我们的系统采用OCR优先提取，以实现成本控制、可审计性、页面级中间产物以及与纯文本解析模型的兼容性，但架构将此视为可配置的权衡，而非永久性的建模假设。我们建议读者参考我们之前的实用指南（Fehliset al.,2025 (https://arxiv.org/html/2605.18818#bib.bib1)），其中提供了一个能力维度框架（文本识别、结构理解、输出灵活性、空间感知、任务适应性），可据此按部署情况决定OCR与VLM的选择。

#### 文档检索。

ColPali（Faysseet al.,2024 (https://arxiv.org/html/2605.18818#bib.bib28)）引入了用于文档检索的后期交互嵌入，实现了无需OCR的高效页面级搜索。这种检索增强范式补充了我们这样的提取流水线，能够从大型文档集合中选择性地处理相关页面。

## 3 系统架构

该架构将文档理解拆分为三个微服务，每个均可独立部署和扩展（图1 (https://arxiv.org/html/2605.18818#S3.F1)）。这种分解反映了一个基本洞察：推理（GPU绑定、高内存）和编排（CPU绑定、I/O密集型）的计算特性差异巨大，将它们耦合会浪费资源并限制扩展灵活性。

对象存储 关系数据库 网关 摄入、控制、状态 工作队列 工作进程 每文档流水线 预处理、提取、评估 推理服务 (GPU) Claude Sonnet (Anthropic API) 图1：系统架构。网关接受提交，将页面图像持久化到对象存储，将跟踪记录保存到关系数据库，并将文档ID入队到消息队列。工作进程拉取文档，执行CPU绑定的编排，并调用推理服务进行GPU绑定的OCR，以及调用Anthropic API（Claude Sonnet）进行VLM步骤和语言模型解析。将CPU绑定的编排与GPU绑定的推理分离，使得每一层可以独立扩展。通过解耦推理，CPU绑定服务主要利用文档处理所需的I/O密集型操作，从而可以利用异步协程而无需内部并行化。尽管这种方法意味着推理服务无法通过缓冲进行批处理扩展，但确实允许每个服务独立扩展。因此，该架构非常适合针对特定工作负载进行调优，而无需过度配置那些在I/O操作期间闲置的资源。

### 3.1 网关：摄入服务

网关服务是系统的入口和出口。它通过两条入站路径接受文档提交：一条用于客户端同步提交的REST API，以及一条用于上游流水线异步交接的摄入队列。网关负责将页面图像存储到对象存储中，在关系数据库中创建跟踪记录，并将文档ID入队以通知工作进程文档已准备好处理。它还提供一个基于Web的检测界面供人工审核提取结果，并通过状态队列报告处理状态。

网关几乎完全是I/O密集型的，必须能够扩展到预期的摄入吞吐量。例如，商用扫描仪能够以150页/分钟的速度（Ricoh,2024 (https://arxiv.org/html/2605.18818#bib.bib30)）在300 dpi下扫描，产生2-90 MiB的页面图像，需要平均225 MiB/s的带宽。对于物理文档扫描工作负载，这种带宽是“突发性的”，因为扫描吞吐量受限于进纸器大小和设施的正常工作时间。在这个简单的例子中，很容易看出摄入吞吐量通常与系统其他部分的吞吐量根本不同，需要与其它文档处理工作负载不同的扩展策略。

由于扩展策略不同，网关被有意设计得轻量——它不执行任何推理或提取，也不执行任何其他CPU密集型操作。这使其资源占用很小（针对摄入进行了调优），并且故障模式简单：如果网关宕机，则没有新文档进入系统，但正在进行的处理不受影响。

### 3.2 工作进程：流水线编排

工作进程充当流水线的执行引擎。它们编排整个工作流，并根据系统配置执行各个步骤。每个工作进程Pod运行多个并发任务（限制为最大数量以防止资源争用），从消息队列拉取文档ID，并执行已配置的提取流水线。工作进程按需（延迟加载）从对象存储下载页面图像，调用推理服务进行推理密集型步骤，并在完成后上传结构化的JSON结果。

工作进程是CPU绑定且I/O密集型的：它们大部分时间花在等待推理响应、数据库读写、下载和上传图像以及在不同流水线步骤之间编组数据上。因此，我们在每个工作进程内部使用异步任务执行，这样当一个任务等待推理或I/O时，另一个任务可以取得进展。这提供了Pod内的垂直并发，而Kubernetes通过添加更多工作进程Pod提供水平扩展。吞吐量随工作进程并发度增加而增加，直到推理服务或下游API饱和。

系统的有效并发度为`pods × tasks per pod`。在默认配置下（每个Pod 5个任务），部署5个工作进程Pod可提供25个并发文档处理槽。

### 3.3 推理服务

推理服务将GPU绑定的推理隔离在REST API之后，向工作进程暴露OCR模型（例如DocTR（Mindee,2021 (https://arxiv.org/html/2605.18818#bib.bib10)））和VLM能力（通过云API代理到托管服务）。这种分离带来三个好处：

1. **独立扩展**。GPU节点成本高昂。将推理与编排解耦意味着我们根据推理需求而非工作进程数量来配置GPU容量。
2. **模型切换**。新OCR模型可以部署到推理服务而无需修改工作进程代码。例如，我们通过仅更改配置，就在DocTR、Docling（Aueret al.,2024 (https://arxiv.org/html/2605.18818#bib.bib11)）和SmolDocling之间进行切换。
3. **资源隔离**。DocTR需要约800 MB的GPU内存。将其运行在工作进程Pod内要么浪费GPU资源（因为工作进程大部分时间非推理），要么强制进行纯CPU推理（慢3-5倍）。

部署推理服务的一个重要考虑因素是确保计算**错开**。处理单个文档是一个顺序过程，每个步骤依次进行。