- 概述
- Document Understanding 流程
- 快速入门教程
- 框架组件
- ML 包
- 概述
- Document Understanding - ML 包
- DocumentClassifier - ML 包
- 具有 OCR 功能的 ML 包
- 1040 - ML 包
- 1040 附表 C - ML 包
- 1040 附表 D - ML 包
- 1040 附表 E - ML 包
- 1040x - ML 包
- 3949a - ML 包
- 4506T - ML 包
- 709 - ML 包
- 941x - ML 包
- 9465 - ML 包
- 990 - ML 包 - 预览
- ACORD125 - ML 包
- ACORD126 - ML 包
- ACORD131 - ML 包
- ACORD140 - ML 包
- ACORD25 - ML 包
- 银行对账单 - ML 包
- 提单 - ML 包
- 公司注册证书 - ML 包
- 原产地证书 - ML 包
- 检查 - ML 包
- 儿童产品证书 - ML 包
- CMS1500 - ML 包
- 欧盟符合性声明 - ML 包
- 财务报表 (Financial statements) - ML 包
- FM1003 - ML 包
- I9 - ML 包
- ID Cards - ML 包
- Invoices - ML 包
- 中国发票 - ML 包
- 希伯来语发票 - ML 包
- 印度发票 - ML 包
- 日本发票 - ML 包
- 装运发票 - ML 包
- 装箱单 - ML 包
- 护照 - ML 包
- 工资单 - ML 包
- 采购订单 - ML 包
- 收据 - ML 包
- 汇款通知书 - ML 包
- UB04 - ML 包
- 水电费账单 - ML 包
- 车辆所有权证明 - ML 包
- W2 - ML 包
- W9 - ML 包
- 其他开箱即用的 ML 包
- 公共端点
- 硬件要求
- 管道
- Document Manager
- OCR 服务
- 深度学习
- 训练高效能模型
- 部署高效能模型
- Insights 仪表板
- 部署在 Automation Suite 中的 Document Understanding
- 在 AI Center 独立版中部署的 Document Understanding
- 许可
- 活动
- UiPath.Abbyy.Activities
- UiPath.AbbyyEmbedded.Activities
- UiPath.DocumentProcessing.Contracts
- UiPath.DocumentUnderstanding.ML.Activities
- UiPath.DocumentUnderstanding.OCR.LocalServer.Activities
- UiPath.Intelligent OCR.Activities
- UiPath.OCR.Activities
- UiPath.OCR.Contracts
- UiPath.OmniPage.Activities
- UiPath.PDF.Activities
部署高效能模型
随着机器学习 (ML) 模型准确性的提高,其资源需求也会发生变化。为了获得最佳性能,在通过 AI Center 部署 ML 模型时,请务必根据其需要处理的流量适当调整技能的大小。在大多数情况下,基础架构的大小根据单位时间(分钟或小时)的页面数量而定。一个文档可以包含一个或多个页面。
要通过 AI Center 部署基础架构,需要牢记几个重要的方面,以实现最佳性能。
只有一种 GPU 基础架构可用。启用 GPU 的复选框会突出显示这一点。每项技能在具有 GPU 的单个虚拟机 (VM) 或节点上运行。在这种情况下,CPU 和内存不相关,因为技能可以使用这些节点上所有可用的 CPU 和内存资源。除了吞吐量外,GPU 的运行速度更快。因此,如果延迟很严重,建议使用 GPU。
CPU 和内存可以分开,这意味着多个 ML 技能可以在同一个节点上运行。为避免相邻技能的干扰,每个 ML 技能都有其可消耗的内存和 CPU 的数量,具体取决于所选的层。CPU 性能越高,(页面)处理速度就越快,而内存容量越大,可处理的文档数量就越多。
副本的数量决定了用于服务 ML 模型请求的容器数量。数字越大,可以并行处理的文档数量就越多,具体取决于该特定层的限制。副本的数量直接与基础架构类型相关(每个副本的 CPU 数量,或者使用 GPU),从某种意义上说,副本和基础架构大小都会直接影响吞吐量(页/分钟)。
如果基础架构的大小不正确,则模型可能会承受非常高的负载。在某些情况下,这可能会导致请求积压、处理时间过长,甚至导致文档处理失败。
内存不足通常出现在较低 CPU 层(0.5 个 CPU 或 1 个 CPU)。如果您需要处理非常大的有效负载(一个或多个大型文档),则可能会导致内存不足异常。这与文档的页面大小和文本密度(每页的文本数量)有关。由于每个用例的要求都非常特定,因此无法提供确切的数字。您可以查看正确调整基础架构大小部分中的准则,以获取更多详细信息。如果遇到内存不足的情况,一般建议使用下一层。
本部分提供有关模型在每种不同技能规格上执行情况的一般准则。
层级 | 每个文档的最大页数 | 预期吞吐量(页/小时) | AI 单元/小时 |
---|---|---|---|
0.5 CPU/2 GB 内存 | 25 | 300-600 | 1 |
1 个 CPU/4 GB 内存 | 50 | 400-800 | 2 |
2 个 CPU/8 GB 内存 | 100 | 600-1000 | 4 |
4 个 CPU/16 GB 内存 | 100 | 800-1200 | 8 |
6 个 CPU/24 GB 内存 | 100 | 900-1300 | 12 |
GPU | 200-250 | 1350-1600 | 20 |
层级 | 每个文档的最大页数 | 预期吞吐量(页/小时) | AI 单元/小时 |
---|---|---|---|
0.5 CPU/2 GB 内存 | 25 | 40-100 | 1 |
1 个 CPU/4 GB 内存 | 50 | 70-140 | 2 |
2 个 CPU/8 GB 内存 | 75 | 120-220 | 4 |
4 个 CPU/16 GB 内存 | 100 | 200-300 | 8 |
6 个 CPU/24 GB 内存 | 100 | 250-400 | 12 |
GPU | 200-250 | 1400-2200 | 20 |
层级 | 每个文档的最大页数 | 预期吞吐量(页/小时) | AI 单元/小时 |
---|---|---|---|
0.5 CPU/2 GB 内存 | 25 | 60-200 | 1 |
1 个 CPU/4 GB 内存 | 50 | 120-240 | 2 |
2 个 CPU/8 GB 内存 | 75 | 200-280 | 4 |
4 个 CPU/16 GB 内存 | 100 | 250-400 | 8 |
6 个 CPU/24 GB 内存 | 100 | 350-500 | 12 |
GPU | 200-250 | 1000-2000 | 20 |
预期吞吐量用于表达每个副本(以页面/小时为单位),以及最小和最大预期吞吐量,具体取决于文档本身。应根据最高预期吞吐量(峰值)调整 ML 技能的大小,而不是一天、一周或一个月的平均吞吐量。
示例 1
- 最多包含五页的文档。
- 每小时的最大峰值为 300 页。
由于吞吐量较低且文档较小,因此本示例中不需要 GPU。0.5 个 CPU 或 1 个 CPU 层的 2 到 4 个副本就足够了。
示例 2
- 最多包含 80 页的文档。
- 最大峰值为每小时 900 页。
在此示例中,4 个 CPU 层的三个副本或一个 GPU 层已足够。
示例 3
- 最多包含 50 页的文档。
- 最大峰值为每小时 3000 页。
- 使用 3 个 GPU 副本。
- 使用 4 个 CPU 或 6 个 CPU 层的 12-15 个副本。
这两个选项都具有高可用性,因为 ML 技能有两个以上的副本。
您可以查看“一般准则”部分中的表格,了解单个提取副本的预期吞吐量,具体取决于模型版本和层级。
- 理想情况下,副本发送对一个请求的响应和副本收到下一个请求的数据之间的空闲时间应该最短。
- 副本不应超载。系统会逐个处理请求(串行)。这意味着始终有一个正在处理的活动请求和一个待处理请求队列。如果此队列变得太长,副本将拒绝新的传入请求,并显示
429 (too many requests) HTTP
状态代码。
在调整单个副本的基础架构大小时,要记住的关键点是确保工作负载平衡。工作负载不应太轻,导致副本保持空闲状态,也不应太重,以免其开始拒绝任务。
- 确定副本最繁忙的相关时间段。例如,您需要确定活动最忙的一小时,而不是一分钟间隔或 12 小时范围的峰值。确定此时间段后,请估计该时间段的需求(页面数或请求数)。
- 将估计值除以每个副本的吞吐量,如“调整一个副本的基础架构”部分所述。
- 作为安全措施,请添加一些额外容量。
请注意,使用最繁忙的时间段可能会导致在需求明显降低时出现过度配置。要解决此问题,您可以根据需求手动增加或减小部署的规模。例如,如果有一个非常繁忙的一小时间隔需要 10 个副本,然后有 23 个小时的低活动期(只需要 2 个副本),这可能会很有帮助。这种情况可能会导致系统在相当长的时间内处于过度配置状态。
页数和页面密度是关键因素。页数比请求数更重要。但是,请求数实际上更容易计算。
在确定部署是否配置不足时,CPU 利用率并不相关,因为在处理请求时,每个副本都将最大化 CPU/GPU 使用率,无论待处理请求队列如何。
重要因素是端到端时间,即等待时间和实际处理时间的总和。
例如,如果您选择了吞吐量约为 900 页/小时或约 4 秒/页的层级,并且要发送 5 页的文档,则每个文档通常需要大约 30 秒。
然后,您可以将等待时间估算为 10 秒左右。这意味着需要一段等待时间(即副本不会立即处理请求,因为它正忙于处理先前存在的请求)。这也表明此等待时间约为 10 秒。
如果实际端到端时间(测量时间)和预期端到端时间(作为层级的函数估计的时间)之差大于零,则表示副本正在不间断工作。此外,如果等待时间随着需求的增加而增加,则部署明显正在持续承受压力。此外,任何 429 状态代码(请求过多)都表示配置不足。