部署高效能模型

随着机器学习 (ML) 模型准确性的提高，其资源需求也会发生变化。为了获得最佳性能，在通过 AI Center 部署 ML 模型时，请务必根据其需要处理的流量适当调整技能的大小。在大多数情况下，基础架构的大小根据单位时间（分钟或小时）的页面数量而定。一个文档可以包含一个或多个页面。

ML 模型性能简介

要通过 AI Center 部署基础架构，需要牢记几个重要的方面，以实现最佳性能。

GPU

只有一种 GPU 基础架构可用。启用 GPU 的复选框会突出显示这一点。每项技能在具有 GPU 的单个虚拟机 (VM) 或节点上运行。在这种情况下，CPU 和内存不相关，因为技能可以使用这些节点上所有可用的 CPU 和内存资源。除了吞吐量外，GPU 的运行速度更快。因此，如果延迟很严重，建议使用 GPU。

CPU

CPU 和内存可以分开，这意味着多个 ML 技能可以在同一个节点上运行。为避免相邻技能的干扰，每个 ML 技能都有其可消耗的内存和 CPU 的数量，具体取决于所选的层。CPU 性能越高，（页面）处理速度就越快，而内存容量越大，可处理的文档数量就越多。

副本数量

副本的数量决定了用于服务 ML 模型请求的容器数量。数字越大，可以并行处理的文档数量就越多，具体取决于该特定层的限制。副本的数量直接与基础架构类型相关（每个副本的 CPU 数量，或者使用 GPU），从某种意义上说，副本和基础架构大小都会直接影响吞吐量（页/分钟）。

注意：多个副本会可成倍提高吞吐量。

机器人数量

机器人的数量会影响吞吐量。为了获得高效的吞吐量，需要调整机器人的数量，以免造成 ML 技能超载。这取决于自动化本身，应进行测试。作为一般准则，您可以使用一到三个机器人作为 ML 技能拥有的每个副本的起点。根据整体流程时间（不包括 ML 提取程序），机器人的数量（或副本的数量）可以更多或更少。

与基础架构大小调整相关的潜在问题

如果基础架构的大小不正确，则模型可能会承受非常高的负载。在某些情况下，这可能会导致请求积压、处理时间过长，甚至导致文档处理失败。

内存不足

内存不足通常出现在较低 CPU 层（0.5 个 CPU 或 1 个 CPU）。如果您需要处理非常大的有效负载（一个或多个大型文档），则可能会导致内存不足异常。这与文档的页面大小和文本密度（每页的文本数量）有关。由于每个用例的要求都非常特定，因此无法提供确切的数字。您可以查看正确调整基础架构大小部分中的准则，以获取更多详细信息。如果遇到内存不足的情况，一般建议使用下一层。

计算不足

计算不足指的是 CPU 和 GPU，尽管这种情况在 CPU 上更常见。当 ML 技能收到与其可用容量相关的页面过多时，请求可能会超时（520 和 499 状态代码）、积压，甚至导致模型崩溃（503 和 500 状态代码）。如果遇到计算不足的情况，我们建议使用下一层，甚至 GPU 层。

正确调整基础架构的大小

一般准则

本部分提供有关模型在每种不同技能规格上执行情况的一般准则。

重要提示：本节中提供的计算仅用作一般准则，不应解释为确切的规范。 性能结果可能会有所不同，并受不同因素的影响，例如文档的大小、页数和所使用的特定模型。

注意：每个模型生成版本（2022.10、2023.4、或 2023.10）在所需资源和吞吐量方面，其行为有所不同。随着模型在准确性方面变得越来越好，这也会影响性能并需要更多资源。

表 1. 2022.10 提取程序

层级	每个文档的最大页数	预期吞吐量（页/小时）	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

表 2. 2023.4 提取程序

层级	每个文档的最大页数	预期吞吐量（页/小时）	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

表 3. 2023.7 和 2023.10 提取程序

层级	每个文档的最大页数	预期吞吐量（页/小时）	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

ML 技能需要使用 2023.10 提取程序处理以下内容：

• 最多包含五页的文档。
• 每小时的最大峰值为 300 页。

由于吞吐量较低且文档较小，因此本示例中不需要 GPU。0.5 个 CPU 或 1 个 CPU 层的 2 到 4 个副本就足够了。

示例 2

ML 技能需要使用 2023.4 提取程序处理以下内容：

• 最多包含 80 页的文档。
• 最大峰值为每小时 900 页。

在此示例中，4 个 CPU 层的三个副本或一个 GPU 层已足够。

注意：单个副本不具有高可用性，因此始终建议对关键生产工作流至少使用两个副本。

示例 3

ML 技能需要使用 2023.10 提取程序处理以下内容：

• 最多包含 50 页的文档。
• 最大峰值为每小时 3000 页。

有两种方法可以满足此要求：

• 使用 3 个 GPU 副本。
• 使用 4 个 CPU 或 6 个 CPU 层的 12-15 个副本。

这两个选项都具有高可用性，因为 ML 技能有两个以上的副本。

调整一个副本的基础架构大小

您可以查看“一般准则”部分中的表格，了解单个提取副本的预期吞吐量，具体取决于模型版本和层级。

注意：要实现最大吞吐量潜力，您必须使提取副本保持恒定负载。

为确保副本始终处于忙碌状态，应满足以下条件：

• 理想情况下，副本发送对一个请求的响应和副本收到下一个请求的数据之间的空闲时间应该最短。
• 副本不应超载。系统会逐个处理请求（串行）。这意味着始终有一个正在处理的活动请求和一个待处理请求队列。如果此队列变得太长，副本将拒绝新的传入请求，并显示 429 (too many requests) HTTP 状态代码。

在调整单个副本的基础架构大小时，要记住的关键点是确保工作负载平衡。工作负载不应太轻，导致副本保持空闲状态，也不应太重，以免其开始拒绝任务。

确定所需的副本数量

要确定所需的副本数量，您需要：

• 确定副本最繁忙的相关时间段。例如，您需要确定活动最忙的一小时，而不是一分钟间隔或 12 小时范围的峰值。确定此时间段后，请估计该时间段的需求（页面数或请求数）。
• 将估计值除以每个副本的吞吐量，如“调整一个副本的基础架构”部分所述。
• 作为安全措施，请添加一些额外容量。

请注意，使用最繁忙的时间段可能会导致在需求明显降低时出现过度配置。要解决此问题，您可以根据需求手动增加或减小部署的规模。例如，如果有一个非常繁忙的一小时间隔需要 10 个副本，然后有 23 个小时的低活动期（只需要 2 个副本），这可能会很有帮助。这种情况可能会导致系统在相当长的时间内处于过度配置状态。

衡量需求和供应：页或请求

页数和页面密度是关键因素。页数比请求数更重要。但是，请求数实际上更容易计算。

提示：您可以使用历史数据来简化此转换。对于具有记录历史的特定技能，您可以检查计量遥测，以确定对该技能发出的请求的页数分布。例如，如果某项技能在上个月收到的大部分文档为两页或三页，则您可以假设未来的趋势将继续，平均每个文档 2.5 页。

确定部署是否配置不足

在确定部署是否配置不足时，CPU 利用率并不相关，因为在处理请求时，每个副本都将最大化 CPU/GPU 使用率，无论待处理请求队列如何。

重要因素是端到端时间，即等待时间和实际处理时间的总和。

例如，如果您选择了吞吐量约为 900 页/小时或约 4 秒/页的层级，并且要发送 5 页的文档，则每个文档通常需要大约 30 秒。

然后，您可以将等待时间估算为 10 秒左右。这意味着需要一段等待时间（即副本不会立即处理请求，因为它正忙于处理先前存在的请求）。这也表明此等待时间约为 10 秒。

如果实际端到端时间（测量时间）和预期端到端时间（作为层级的函数估计的时间）之差大于零，则表示副本正在不间断工作。此外，如果等待时间随着需求的增加而增加，则部署明显正在持续承受压力。此外，任何 429 状态代码（请求过多）都表示配置不足。

确定部署是否过度配置

前面的部分可以帮助确定部署是否已有效配置，但我们建议您按照以下步骤准确分析您的部署：

• 确定最繁忙的时间段。在此示例中，我们假设它为 1 小时（3600 秒）。
• 对于当前的副本数，假设它为 10。这就产生了 36000“副本秒”（与“人时”概念类似）。
• 汇总请求的总持续时间（端到端时间的总和）。假设该时间为 10000 秒。

在此示例中，由于 10000 小于 36000，因此这意味着您当前的基础架构超出了需求。您可以尝试将部署减少到八个副本，并监控性能，如果运行平稳，则将其减少到六个副本。每次调整时重新评估性能。