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

機械学習 (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 を使用している場合) に直接関連付けられます。つまり、レプリカとインフラストラクチャのサイズの両方がスループット (ページ/分) に直接影響します。

注: レプリカが複数あると、スループットが増加します。

ロボット数

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

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

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

メモリ不足

メモリ不足が最も多く発生するのは下位の CPU 層 (0.5 CPU または 1 CPU) です。非常に大きなペイロード (1 つまたは複数の大きなドキュメント) を処理する必要がある場合は、メモリ不足例外が発生する可能性があります。これは、ページとテキスト密度 (ページあたりのテキストの量) で測るドキュメントのサイズに関連しています。要件は個々のユース ケースで固有のため、正確な数値を提示することはできません。詳細については、「インフラストラクチャの適切なサイズ設定」セクションのガイドラインをご覧ください。メモリ不足の状況が発生した場合は、一般推奨事項として次の層に進むことをお勧めします。

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

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

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

一般的なガイドライン

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

大事な： このセクションに記載されている計算は、一般的なガイドラインとしてのみ使用することを意図しており、正確な仕様として解釈しないでください。 パフォーマンスの結果はさまざまであり、ドキュメントのサイズ、ページ数、使用されている特定のモデルなどのさまざまな要因の影響を受けます。

注: モデル世代 (2022.10、2023.4、または 2023.10) によって、必要なリソースとスループットとの関連で動作が異なります。モデルの精度が向上すると、パフォーマンスにも影響し、より多くのリソースが必要になる可能性があります。

表 2. 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 スキルは、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 層で十分です。

注: 単一のレプリカには高可用性がありません。したがって、重要な運用環境のワークフローにはレプリカを少なくとも 2 つ使用することを常にお勧めします。

例 3

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

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

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

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

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

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

モデルのバージョンと層に応じた、1 つの抽出レプリカの予想されるスループットについては、「一般的なガイドライン」セクションの表で確認できます。

注: 実現可能な最大限のスループットを達成するには、抽出レプリカに絶えず一定の負荷をかける必要があります。

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

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

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

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

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

• レプリカに関連する最もビジーな期間を特定します。たとえば、1 分間のピーク時間や 12 時間に及ぶ期間ではなく、アクティビティが最もビジーな 1 時間を特定する必要があります。この期間を特定したら、その期間中の需要 (ページまたは要求の数) を推定します。
• この推定値をレプリカあたりのスループットで割ります。詳しくは、「1 つのレプリカのインフラストラクチャのサイズを設定する」セクションをご覧ください。
• 安全策として若干の余剰容量を追加します。

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

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

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

ヒント: 履歴データを使用すると、この変換を簡単に行うことができます。履歴が記録されている特定のスキルでは、使用状況の測定テレメトリを確認することで、そのスキルに対して実行された要求のページ数の分布を特定できます。たとえば、あるスキルが前月に受け取ったドキュメントのほとんどが 2 ページから 3 ページであった場合、今後もこの傾向が続き、ドキュメントあたり平均 2.5 ページになると想定できます。

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

デプロイがプロビジョニング不足かどうかを判断する場合、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 個に減らすことができます。調整を加えるたびにパフォーマンスを再評価します。