優れたパフォーマンスのモデルをデプロイする

機械学習 (ML) モデルの精度が時間の経過と共に向上するにつれて、リソース要件も変化します。最適なパフォーマンスを得るには、AI Center を介して ML モデルをデプロイする際に、処理が必要なトラフィックに対してスキルを適切なサイズに設定することが重要です。ほとんどの場合、インフラストラクチャのサイズは、単位時間 (分または時間) あたりのページ数に対して設定されます。1 件のドキュメントは 1 ページの場合も、複数ページの場合もあります。

ML モデルのパフォーマンスについて

AI Center を介してインフラストラクチャをデプロイする場合、最適なパフォーマンスを得るために留意すべき重要な側面がいくつかあります。

GPU

使用できる GPU インフラストラクチャの種類は 1 つだけです。これは、GPU を有効にするためのチェックボックスで強調表示されます。各スキルは、GPU を持つ単一の仮想マシン (VM) またはノードで実行されます。この場合、スキルはそのノードで使用可能なすべての CPU とメモリ リソースを使用できるため、CPU とメモリは関係ありません。スループットに加えて、GPU は非常に高速です。このため、レイテンシが重要な場合は GPU の使用をお勧めします。

CPU

CPU とメモリは分割できます。つまり、同じノード上で複数の ML スキルを実行できます。隣接するスキルからの妨害を避けるため、各 ML スキルの上限は、選択した層に応じて使用可能なメモリ量と CPU です。CPU を高くすると (ページの) 処理速度が速くなり、メモリを増やすと処理可能なドキュメントの数が増えます。

レプリカの数

レプリカの数によって、ML モデルからの要求を処理するために使用されるコンテナーの数が決まります。この値が大きいほど、並列処理できるドキュメントの量が増えますが、その特定の層の制限が適用されます。レプリカの数はインフラストラクチャの種類 (レプリカあたりの CPU の数、または GPU を使用している場合) に直接関連付けられます。つまり、レプリカとインフラストラクチャのサイズの両方がスループット (ページ/分) に直接影響します。

注:

Multiple replicas multiply the throughput.

ロボット数

ロボットの数はスループットに影響します。効率的なスループットを得るには、ML スキルが過負荷にならないようにロボットの数を設定する必要があります。これはオートメーション自体に依存するため、テストが必要です。一般的には、はじめは ML スキルにあるレプリカ 1 つに対して 1 台から 3 台のロボットを使用します。全体の処理時間 (ML 抽出器を除く) に応じて、ロボットの数 (またはレプリカの数) を増減できます。

インフラストラクチャのサイジングに関連する潜在的な問題

インフラストラクチャのサイズが正しくない場合、モデルに非常に高い負荷がかかるおそれがあります。場合によっては、要求のバックログが発生し、処理時間が長くなり、さらにはドキュメントの処理時に失敗が発生する可能性があります。

メモリ不足

Insufficient memory most commonly encountered on the lower CPU tiers (0.5 CPU or 1 CPU). If you need to process a very large payload (one or several large documents), it can lead to an out of memory exception. This is related to the document size in terms of pages and text density (how much text there is per page). Since the requirements are very specific to each use case, it is not possible to provide exact numbers. You can check the guidelines in the Sizing the infrastructure correctly section for more detailed information. If you encounter an insufficient memory situation, the general recommendation is to go to the next tier.

不十分なコンピューティング

不十分なコンピューティングとは、CPU と GPU の両方を指しますが、CPU のほうで多く発生します。ML スキルの利用可能な容量に対して受け取るページが多すぎると、要求のタイムアウト (ステータス コード 520 および 499)、バックログの発生、さらにモデルのクラッシュ (ステータス コード 503 および 500) が発生する可能性があります。コンピューティングが不十分な状況が発生した場合は、次の層、または GPU 層に移行することをお勧めします。

インフラストラクチャの適切なサイズ設定

一般的なガイドライン

このセクションでは、異なるスキル サイズごとにモデルがどのように実行されるかについての一般的なガイドラインを示します。

重要:

The calculations provided in this section are intended to be used only as general guidelines and should not be interpreted as exact specifications. Performance outcomes can vary and are influenced by different factors such as the size of the document, number of pages, and the specific model being utilized.

注:

Each model generation (2022.10, 2023.4, or 2023.10) behaves differently in relation to resources required and throughput. As models become better in terms of accuracy, this can also impact the performance and demand more resources.

Table 1. 2022.10 Extractor

層	ドキュメントあたりの最大ページ数	予想されるスループット (ページ/時間)	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

Table 2. 2023.4 Extractor

層	ドキュメントあたりの最大ページ数	予想されるスループット (ページ/時間)	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

Table 3. 2023.7 and later versions of extractors

層	ドキュメントあたりの最大ページ数	予想されるスループット (ページ/時間)	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 スキルのサイズは、日、週、月の平均スループットではなく、予想される最大スループット (スパイク) に合わせて設定する必要があります。

注:

When sizing the infrastructure, make sure to start from the largest document the skill needs to handle and the expected throughput.

例

例 1

ML スキルは、v2023.10 の抽出器を使用して以下の処理を行う必要があります。

• 最大 5 ページを含むドキュメント。
• 最大スパイクは 1 時間あたり 300 ページ。

スループットは低い方であり、ドキュメント サイズも小さいため、この例では GPU は必要ありません。0.5 CPU 層または 1 CPU 層のレプリカが 2 つから 4 つあれば十分です。

例 2

ML スキルは、v2023.4 の抽出器を使用して以下の処理を行う必要があります。

• 最大 80 ページを含むドキュメント。
• 最大スパイクは 1 時間あたり 900 ページ。

この例では、4 CPU 層の 3 つのレプリカ、または 1 つの GPU 層で十分です。

注:

A single replica does not have high availability, so it is always recommended to use at least two replicas for critical production workflows.

例 3

ML スキルは、v2023.10 の抽出器を使用して以下の処理を行う必要があります。

• 最大 50 ページを含むドキュメント。
• 最大スパイクは 1 時間あたり 3000 ページ。

この要件を満たすには、次の 2 つの方法があります。

• 3 つの GPU レプリカを使用する。
• 4 CPU 層または 6 CPU 層のレプリカを 12 ～ 15 個使用する。

どちらのオプションでも、ML スキルのレプリカが 3 つ以上あるため高可用性が実現します。

1 つのレプリカのインフラストラクチャのサイズを設定する

You can check the tables from the General guidelines section for the expected throughput from a single extraction replica, depending on the model version and the tier.

注:

To achieve maximum throughput potential, you must keep the extraction replica under constant load.

レプリカを常にビジー状態にするには、以下の条件を満たす必要があります。

• 理想的には、レプリカが 1 つの要求に応答を送信してから、次の要求のデータを受信するまでのアイドル時間が最小限である必要があります。
• レプリカが過負荷にならないようにします。要求は 1 つずつ (順次) 処理されます。つまり常に、処理中のアクティブな要求が 1 つと、保留中の要求のキューが 1 つ存在します。このキューが長くなりすぎると、レプリカは新しい受信要求を拒否し、ステータス コード「429 (too many requests) HTTP」が表示されます。

1 つのレプリカのインフラストラクチャのサイズを調整する場合に留意すべき重要なポイントは、ワークロードのバランスを取ることです。ワークロードが軽すぎてレプリカがアイドル状態のままになったり、重すぎてタスクを拒否し始めたりしないようにする必要があります。

必要なレプリカの数を判断する

必要なレプリカの数を判断するには、以下を行う必要があります。

• レプリカに関連する最もビジーな期間を特定します。たとえば、1 分間のピーク時間や 12 時間に及ぶ期間ではなく、アクティビティが最もビジーな 1 時間を特定する必要があります。この期間を特定したら、その期間中の需要 (ページまたは要求の数) を推定します。
• Divide the estimate by the throughput per replica, described in the Size the infrastructure for one replica section.
• 安全策として若干の余剰容量を追加します。

最もビジーな期間を使用すると、需要が大幅に減ったときにプロビジョニング過剰になる可能性があることに注意してください。これに対処するには、需要に応じてデプロイのサイズを手動で増減できます。これが役立つのは、たとえば、10 個のレプリカが必要な非常にビジーな 1 時間の期間の後に、アクティビティが少なく 2 個のレプリカだけで済む期間が 23 時間続くような場合です。この結果、システムはかなりの時間、プロビジョニング過剰になります。

需要と供給を測定する: ページまたは要求

ページ数とそのページの密度が重要な要因になります。ページ数は要求数よりも関連度が高いものの、実際問題としては、要求の方がカウントするのが容易です。

ヒント:

You can use historical data to make this conversion easier. For a particular skill with a recorded history, you can check the metering telemetry to identify the distribution of page counts for requests made to that skill. For example, if a skill received mostly documents with two or three pages in the last month, you can assume the future trend will continue with an average of 2.5 pages per document.

デプロイがプロビジョニング不足かどうかを判断する

デプロイがプロビジョニング不足かどうかを判断する場合、CPU 使用率は適切ではありません。各レプリカは、保留中の要求のキューに関係なく、要求の処理中に CPU/GPU を最大限に使用するためです。

重要な要因はエンドツーエンドの時間であり、これは待機時間と実際の処理時間の合計です。

たとえば、スループットが約 900 ページ/時、すなわち約 4 秒/ページの層を選択し、5 ページのドキュメントを送信すると、通常はドキュメントあたり約 30 秒かかるとします。

この場合、待機時間は約 10 秒であると見積もることができます。つまり、待機時間が存在しています (これは、レプリカが既存の要求の処理でビジーであったため、要求がすぐには取得されなかったことを意味します)。また、この待機時間が約 10 秒であったことも示しています。

実際のエンドツーエンドの時間 (測定された時間) と予想されるエンドツーエンドの時間 (層の機能として推定された時間) の差が 0 より大きい場合は、レプリカが絶え間なく動作していることを意味します。また、需要の増加に応じて待機時間が長くなる場合は、デプロイに持続的な負荷がかかっていることは明らかです。さらに、ステータス コード 429 (要求が多すぎる) があれば、プロビジョニング不足の証拠となります。

展開が過剰にプロビジョニングされているかどうかを判断する

前のセクションは、デプロイが効果的にプロビジョニングされていることを確認するのに役立ちますが、以下の手順を実行してデプロイを正確に分析することをお勧めします。

• 最もビジーな期間を特定します。この例では、1 時間 (3,600 秒) と仮定します。
• レプリカの現在の数を取得します。ここでは 10 個と仮定します。ここから 36,000 「レプリカ秒」 (「人時」と同様の概念) が得られます。
• 要求の総所要時間 (エンドツーエンドの時間の合計) を求めます。これを 10,000 秒と仮定します。

この例の場合、10,000 は 36,000 よりも小さいため、現在のインフラストラクチャはニーズを上回っていることを意味します。デプロイを 8 個のレプリカに減らしてパフォーマンスを監視してみることができます。これでもスムーズに動作する場合は、レプリカを 6 個に減らすことができます。調整を加えるたびにパフォーマンスを再評価します。