工程笔记 · 私有文档 AI

ProsGrow 如何实现每小时处理 45,978 个文档问题

通过减少隐藏的工作负载不均衡,ProsGrow 将同一组八张 GPU 上的文档问答吞吐量从每小时 44,608 个问题提升至 45,978 个问题。该速率来自完整的 DocVQA 验证集测试,并同时评估了回答质量与性能。

· 更新于 · ProsGrow AI 工程团队 · 阅读约 5 分钟

文档问答:同一组八张 GPU 上,每小时处理量从 44,608 个问题提升至 45,978 个,增长 3.07%。

问题:问题数量相同,实际工作量却可能不同

私有文档服务需要准确、按时完成积压任务。给每张 GPU 分配相同数量的问题看似合理,但如果某个工作进程收到更多高分辨率页面或更长的多模态提示词,最慢的工作进程就会决定整批任务何时完成。

ProsGrow 发现了这种隐藏的不均衡,并在同一节点上评估了由性能分析指导的任务分配。吞吐量从每小时 44,608 个文档问题提升至 45,978 个,增长 3.07%。结果表明,即使请求数量看起来均衡,多模态服务仍可能存在未被利用的算力。

基线 → ProsGrow 优化结果

两次测试均在同一组八张 GPU 上使用 Qwen3.6-27B BF16 和 vLLM 0.25.1。每个请求提供一张页面图像及一个问题,并要求简短回答。完整的验证工作负载包含 1,285 张页面图像上的 5,349 个问题。

基线按问题数量进行均衡。ProsGrow 通过工作负载分析减少各副本之间分配工作量的差异,同时保留同一页面重复查询的局部性。

每小时回答的文档问题数

基线:按问题数量均衡44,608 个问题/小时
ProsGrow:由性能分析指导的分配45,978 个问题/小时 · +3.07%
使用相同的八张 GPU、BF16 模型、完整验证集和服务设置。两种分配方式都将同一页面的所有问题保留在同一副本上。柱形从零开始;收益来自工作分配方式的改进。
指标按数量均衡的基线ProsGrow 分析指导的任务分配
整节点完成任务的时间窗口431.676 s418.821 s · 缩短 2.98%
文档问题/小时44,60845,978 · 提高 3.07%
各副本提示词 token 数的最大值/最小值1.0759×1.00017×
平均 ANLS0.964020.96531

所有问题均成功完成,精确匹配率为 91.92%。按实测每页 4.16265 个问题计算,吞吐量相当于每小时 11,045 张页面图像。这一换算取决于每页的问题密度。

性能分析揭示了什么

相同的问题数量掩盖了最重与最轻提示词工作负载之间 7.59% 的差异。性能分析揭示了这种不均衡;选定的分配方式将差异降至 0.017% 以内。最终,按共同时间窗口计算的吞吐量达到独立单 GPU 速率八倍的 98.61%。

当多个问题涉及同一页面时,均衡工作量还必须保留复用能力。两种分配方式都保留了这种局部性,优化测试记录到 76.06% 的多模态处理器缓存命中率(包括预热)。实测收益来自在这一服务基础上更均匀地分配工作。

提示词规模并不能解释每个慢任务:页面形状、批处理和请求尾部耗时仍会影响完成时间。有价值的信号是名义上均衡的请求与其实际产生的工作量之间的差距,而非一条通用的调度规则。

权衡:显存余量与精度

大型页面图像使显存余量不仅成为性能约束,也成为正确性问题。选定的服务配置能够接纳整个验证集,并在预填充利用率、延迟以及最大页面所需的余量之间取得平衡。

我们还在相同的文档任务约定下测试了一个更小的混合 NVFP4 检查点。它的磁盘占用为 20.43 GiB,而 BF16 为 51.75 GiB;但其吞吐量为每小时 44,970 个问题,比 BF16 结果低 2.19%。平均 ANLS 从 0.96531 降至 0.96314,精确匹配率从 91.92% 降至 91.14%。因此,我们在这一已预热的文档服务配置中保留了 BF16。

在量化路径中,图像预处理、视觉编码器和长多模态预填充仍然消耗大量资源。在所测试的运行时策略下,更小的权重并未改善峰值显存余量。NVFP4 将整台服务器处理每个问题的能耗降低了 2.33%,但对这一工作负载而言,该收益不足以抵消吞吐量与质量方面的代价。

这对私有文档服务意味着什么

按实测速率,这次调度调整使每个节点每小时约多完成 1,369 个问题。对于包含重复页面查询的积压任务,同样的八张 GPU 因而能够完成更多有效工作。投入生产前,需要针对实际情况进行具有代表性的性能分析,或使用经过验证的成本估算器评估新页面;本次基准测试所用的成本数据来自同一个固定语料库。

优化测试的请求延迟中位数为 4.521 秒,p95 为 9.411 秒。自由文本问题的 ANLS 为 0.93498,低于整体平均水平。试点需要根据客户的页面构成设定质量目标,并根据错误回答的代价制定适当的审核策略。

从实测问题处理量到成本模型

成本模型将每小时的基础设施成本除以实测每小时 11,045 个等效页面处理能力中已售出的部分。这与本地吞吐量提升 3.07% 的比较是两项独立分析。

每 1,000 个等效页面的基础设施成本估算
节点采购成本全部产能获得付费使用10% 付费需求
$100,000$0.49$4.21
$150,000$0.69$6.22

模型假设按三年摊销、每年 5% 维护费、每月 720 小时、电价 $0.10/kWh,并使用 1.30 的用电系数计入制冷及设施开销;服务器工作功率为 7.476590 kW,空闲功率为 1.016 kW。当付费需求为 10% 时,售出量为基准产能的 10%,节点仍需承担摊销、维护和空闲用电成本。模型不包括人工、应用运营、网络、存储和服务预留成本。

作为价格参考,AWS Textract 的 Queries 定价示例 5列出了美国西部(俄勒冈州)每 1,000 页 $15 的价格,核对日期为 2026 年 9 月 15 日。报告中每 1,000 页 $10 的示例服务价格比该参考低 33.33%。这只是一个定价情景;我们的实测工作负载约为每页 4.16 个问题,并未验证提取质量、功能覆盖或交付服务是否等价。

方法与局限

  • 模型与运行时:Qwen/Qwen3.6-27B,版本 6a9e13bd6fc8f0983b9b99948120bc37f49c13e9,BF16;vLLM 0.25.1 搭配 FlashAttention 2。在八张 RTX PRO 6000 Blackwell Server Edition GPU 上运行八个独立副本,每张 GPU 标称显存为 96 GB。服务设置保持一致;关闭思考和前缀缓存,开启多模态处理器缓存。
  • 数据与评分:使用 lmms-lab-encoder/DocVQA 版本 539088ef8a8ada01ac8e2e6d4e372586748a265e 的完整验证集:5,349 个问题、1,285 张不同图像。请求使用确定性采样并要求简短回答。质量和产能数据来自同一次覆盖完整验证集的优化测试。
  • 指标定义:平均归一化 Levenshtein 相似度(ANLS)衡量与参考答案的相似程度;精确匹配指标会统一大小写和空白字符。这些 DocVQA 指标并不直接衡量字段级业务错误。
  • 计时边界:从已预热的 API 文档问答请求开始,到答案完成为止,使用同步的节点共同时间窗口。每小时速率由一次约七分钟的测试换算而来。PDF 导入、企业连接器、结构校验、人工审核、冷启动和可用性工程不在测量范围内。
  • 比较局限:尽管温度为零,批次形状的变化仍使 35 个归一化预测结果发生变化。ANLS 的小幅提升属于观察到的数值变化,不能证明调度改善了模型准确率。匹配条件下的调度比较是本地基准测试,并非重复的生产试验或厂商认证结果。页面处理速率换算仅适用于本次问题密度。

私有文档问答与多模态推理

对于私有文档问答,这项基准测试有助于将多模态推理处理能力与待处理文档量及处理期限联系起来。其计量单位是已回答的问题,而非已导入的 PDF 或经过核验的业务字段。客户部署时,应在评估 GPU 服务性能的同时,评估有代表性的页面图像、答案质量和审核流程。

用您的文档工作负载作为基准

ProsGrow 可以围绕您的页面构成、提取质量、处理时限和治理要求设计私有文档试点。

讨论文档试点