Amazon SageMaker JumpStart でのエンドポイント展開のベンチマークと最適化 |アマゾン ウェブ サービス

大規模言語モデル (LLM) をデプロイする場合、機械学習 (ML) 担当者は通常、モデル提供パフォーマンスの 2 つの測定値を気にします。1 つは単一のトークンの生成にかかる時間で定義されるレイテンシー、もう 1 つは生成されるトークンの数で定義されるスループットです。毎秒。デプロイされたエンドポイントへの 1 つのリクエストは、モデルのレイテンシの逆数にほぼ等しいスループットを示しますが、複数の同時リクエストが同時にエンドポイントに送信される場合、これは必ずしも当てはまりません。クライアント側での同時リクエストの連続バッチ処理などのモデル サービング手法により、レイテンシとスループットには複雑な関係があり、モデル アーキテクチャ、サービング構成、インスタンス タイプのハードウェア、同時リクエストの数、入力ペイロードの変動などに基づいて大きく異なります。入力トークンと出力トークンの数として。

この投稿では、Llama 2、Falcon、Mistral のバリアントを含む、Amazon SageMaker JumpStart で利用可能な LLM の包括的なベンチマークを通じてこれらの関係を調査します。 SageMaker JumpStart を使用すると、ML 実践者は、公開されている基盤モデルの幅広い選択肢から選択して、専用のモデルにデプロイできます。 アマゾンセージメーカー ネットワークから隔離された環境内のインスタンス。アクセラレータの仕様が LLM ベンチマークにどのような影響を与えるかについての理論的原則を提供します。また、単一のエンドポイントの背後に複数のインスタンスをデプロイした場合の影響も示します。最後に、レイテンシ、スループット、コスト、利用可能なインスタンス タイプの制約に関する要件に合わせて SageMaker JumpStart デプロイメント プロセスを調整するための実践的な推奨事項を提供します。すべてのベンチマーク結果と推奨事項は、多用途のベンチマークに基づいています。 ノート ユースケースに適応できるということです。

導入されたエンドポイントのベンチマーク

次の図は、さまざまなモデル タイプとインスタンス タイプにわたるデプロイメント構成の最小レイテンシ (左) と最大スループット (右) の値を示しています。重要なのは、これらの各モデルのデプロイメントでは、デプロイメントに必要なモデル ID とインスタンス タイプが指定された場合に、SageMaker JumpStart によって提供されるデフォルト設定が使用されることです。

これらのレイテンシとスループットの値は、256 個の入力トークンと 256 個の出力トークンを含むペイロードに対応します。レイテンシーが最も低い構成では、単一の同時リクエストに対応するモデルが制限され、スループットが最も高い構成では、可能な同時リクエストの数が最大化されます。ベンチマークでわかるように、同時リクエストが増加するとスループットは単調に増加しますが、大規模な同時リクエストの改善は減少します。さらに、モデルはサポートされているインスタンス上で完全にシャード化されます。たとえば、ml.g5.48xlarge インスタンスには 8 つの GPU があるため、このインスタンスを使用するすべての SageMaker JumpStart モデルは、XNUMX つの利用可能なアクセラレータすべてでテンソル並列処理を使用してシャーディングされます。

この図からいくつかの点に注目することができます。まず、すべてのモデルがすべてのインスタンスでサポートされているわけではありません。 Falcon 7B などの一部の小規模モデルはモデル シャーディングをサポートしていませんが、大規模なモデルではより高いコンピューティング リソース要件が必要になります。第 XNUMX に、シャーディングが増加するとパフォーマンスは通常向上しますが、小規模なモデルの場合は必ずしも向上するとは限りません。. これは、7B や 13B などの小規模なモデルでは、あまりにも多くのアクセラレータ間でシャーディングすると、かなりの通信オーバーヘッドが発生するためです。これについては後ほど詳しく説明します。最後に、ml.p4d.24xlarge インスタンスは、A100G GPU よりも A10 のメモリ帯域幅の向上により、スループットが大幅に向上する傾向があります。後で説明するように、特定のインスタンス タイプを使用するかどうかは、レイテンシ、スループット、コストの制約などのデプロイメント要件によって異なります。

これらの最小のレイテンシと最大のスループット構成値を取得するにはどうすればよいでしょうか?まずは、次の曲線に示すように、2 個の入力トークンと 7 個の出力トークンを持つペイロードの ml.g5.12xlarge インスタンス上の Llama 256 256B エンドポイントのレイテンシとスループットをプロットしてみましょう。同様の曲線が、デプロイされたすべての LLM エンドポイントに存在します。

同時実行性が増加すると、スループットと遅延も単調に増加します。したがって、レイテンシが最も低くなるのは同時リクエスト値 1 のときであり、同時リクエストを増やすことでコスト効率よくシステム スループットを向上させることができます。この曲線には明確な「膝」が存在します。ここでは、追加の同時実行に関連するスループットの向上が、関連するレイテンシの増加を上回らないことが明らかです。この膝の正確な位置は使用例によって異なります。一部の実践者は、事前に指定されたレイテンシ要件 (たとえば、100 ミリ秒/トークン) を超えた時点でニーを定義する場合がありますが、負荷テスト ベンチマークやハーフ レイテンシ ルールなどのキュー理論手法を使用する人もいます。理論上の加速器仕様。

また、同時リクエストの最大数には制限があることにも注意してください。上の図では、ライン トレースは 192 個の同時リクエストで終了します。この制限の原因は SageMaker 呼び出しタイムアウト制限であり、SageMaker エンドポイントは 60 秒後に呼び出し応答をタイムアウトします。この設定はアカウント固有であり、個々のエンドポイントに対して構成することはできません。 LLM の場合、大量の出力トークンの生成には数秒、場合によっては数分かかる場合があります。したがって、入力ペイロードまたは出力ペイロードが大きいと、呼び出しリクエストが失敗する可能性があります。さらに、同時リクエストの数が非常に多い場合、多くのリクエストでキュー時間が長くなり、この 60 秒のタイムアウト制限が大きくなります。この調査では、タイムアウト制限を使用して、モデルのデプロイメントで可能な最大スループットを定義します。重要なのは、SageMaker エンドポイントは呼び出し応答タイムアウトを監視せずに多数の同時リクエストを処理する可能性がありますが、レイテンシとスループットの曲線のニー点に関して最大​​同時リクエストを定義することが必要になる場合があります。これはおそらく、水平スケーリングを検討し始めるポイントです。水平スケーリングでは、単一のエンドポイントがモデル レプリカを持つ複数のインスタンスをプロビジョニングし、受信リクエストをレプリカ間で負荷分散して、より多くの同時リクエストをサポートします。

これをさらに一歩進めて、次の表には、入力トークンと出力トークンの数、インスタンス タイプ、同時リクエストの数など、Llama 2 7B モデルのさまざまな構成のベンチマーク結果が含まれています。上の図は、このテーブルの単一行のみをプロットしていることに注意してください。

このデータには追加のパターンがいくつか観察されます。コンテキスト サイズを増やすと、レイテンシが増加し、スループットが低下します。たとえば、同時実行性が 5.2 の ml.g1xlarge では、総トークン数が 30 の場合、スループットは 512 トークン/秒ですが、総トークン数が 20 の場合は 4,096 トークン/秒になります。これは、入力が大きくなると処理に時間がかかるためです。また、GPU の機能とシャーディングの増加が、最大スループットとサポートされる最大同時リクエストに影響を与えることもわかります。この表は、Llama 2 7B の最大スループット値がインスタンス タイプごとに著しく異なり、これらの最大スループット値は同時リクエストの異なる値で発生することを示しています。これらの特性により、ML 実践者は、あるインスタンスのコストを別のインスタンスよりも正当化することになります。たとえば、低レイテンシー要件を考慮すると、実践者は ml.g5.12xlarge インスタンス (4 つの A10G GPU) ではなく ml.g5.2xlarge インスタンス (1 つの A10G GPU) を選択する可能性があります。高スループット要件が与えられた場合、フル シャーディングでの ml.p4d.24xlarge インスタンス (8 つの A100 GPU) の使用は、同時実行性が高い場合にのみ正当化されます。ただし、多くの場合、代わりに 7B モデルの複数の推論コンポーネントを単一の ml.p4d.24xlarge インスタンスにロードする方が有益であることに注意してください。このようなマルチモデルのサポートについては、この投稿の後半で説明します。

上記の観察は、Llama 2 7B モデルに対して行われました。ただし、同様のパターンは他のモデルにも当てはまります。主なポイントは、レイテンシとスループットのパフォーマンス数値はペイロード、インスタンス タイプ、同時リクエストの数に依存するため、特定のアプリケーションに最適な構成を見つける必要があるということです。ユースケースに応じて上記の数値を生成するには、リンクされたコマンドを実行できます。 ノートここでは、モデル、インスタンス タイプ、ペイロードに対してこの負荷テスト分析を構成できます。

アクセラレータの仕様を理解する

LLM 推論に適したハードウェアの選択は、特定の使用例、ユーザー エクスペリエンスの目標、および選択した LLM に大きく依存します。このセクションでは、アクセラレータの仕様に基づいた高レベルの原理に関して、レイテンシーとスループットの曲線におけるニー点を理解することを試みます。これらの原則だけでは決定を下すのに十分ではありません。実際のベンチマークが必要です。用語 デバイス ここでは、すべての ML ハードウェア アクセラレータを包含するために使用されます。レイテンシとスループットの曲線の曲がり角は、次の 2 つの要因のいずれかによって決まると主張します。

• アクセラレータが KV 行列をキャッシュするためのメモリを使い果たしたため、後続のリクエストはキューに入れられます
• アクセラレータには KV キャッシュ用の予備メモリがまだありますが、十分な大きさのバッチ サイズが使用されているため、処理時間はメモリ帯域幅ではなく計算操作のレイテンシによって決まります。

これはアクセラレータのリソースが飽和していることを意味するため、通常は 2 番目の要素によって制限されることを好みます。基本的に、支払ったリソースを最大限に活用することになります。この主張をさらに詳しく見てみましょう。

KV キャッシュとデバイス メモリ

標準のトランスフォーマ アテンション メカニズムは、以前のすべてのトークンに対して新しいトークンごとにアテンションを計算します。最新の ML サーバーのほとんどは、各ステップでの再計算を避けるために、アテンション キーと値をデバイス メモリ (DRAM) にキャッシュします。これをこれといいます KVキャッシュ、バッチサイズとシーケンスの長さに応じて増加します。これは、並行して処理できるユーザー リクエストの数を定義し、利用可能な DRAM を考慮して、前述の 2 番目のシナリオのコンピューティング制限領域がまだ満たされていない場合に、レイテンシとスループットの曲線の曲がり角を決定します。次の式は、最大 KV キャッシュ サイズの大まかな近似値です。

この式では、B はバッチ サイズ、N はアクセラレータの数です。たとえば、A2G GPU (7 GB DRAM) で動作する FP16 の Llama 2 10B モデル (24 バイト/パラメーター) は約 14 GB を消費し、KV キャッシュ用に 10 GB が残ります。モデルの完全なコンテキスト長 (N = 4096) と残りのパラメーター (n_layers=32、n_kv_attention_heads=32、および d_attention_head=128) を差し込むと、この式は、DRAM の制約により、並列処理できるバッチ サイズが XNUMX ユーザーに制限されることを示しています。 。前の表の対応するベンチマークを観察すると、これは、このレイテンシとスループットの曲線で観察されたニーの適切な近似値となります。などの方法 グループ化されたクエリの注意 (GQA) は KV キャッシュ サイズを削減できます。GQA の場合、同じ係数で KV ヘッドの数が削減されます。

演算強度とデバイスのメモリ帯域幅

ML アクセラレータの計算能力の増大は、メモリ帯域幅を上回っています。つまり、ML アクセラレータは、データの各バイトにアクセスするのにかかる時間内に、より多くの計算を実行できることになります。

　 算術強度、またはメモリ アクセスに対する計算操作の比率により、操作が選択したハードウェアのメモリ帯域幅または計算能力によって制限されるかどうかが決まります。たとえば、10 TFLOPS FP5 と 70 GB/秒の帯域幅を備えた A16G GPU (g600 インスタンス タイプ ファミリ) は、約 116 ops/バイトを計算できます。 A100 GPU (p4d インスタンス タイプ ファミリ) は、約 208 ops/バイトを計算できます。トランスフォーマ モデルの演算強度がその値を下回る場合、メモリに依存します。上記を超えている場合は、コンピューティングに依存します。 Llama 2 7B のアテンション メカニズムでは、バッチ サイズ 62 で 1 ops/バイトが必要です (説明については、「 LLM 推論とパフォーマンスのガイド)、これはメモリに依存していることを意味します。アテンション メカニズムがメモリに依存している場合、高価な FLOPS が使用されないままになります。

アクセラレータを有効活用して演算強度を高める方法は 2 つあります。 操作に必要なメモリ アクセスを減らすことです (これが、 フラッシュ注意 に焦点を当てます）、またはバッチサイズを増やします。ただし、DRAM が小さすぎて対応する KV キャッシュを保持できない場合、バッチ サイズをコンピューティング制限に達するのに十分な量に増やすことができない可能性があります。標準 GPT デコーダ推論において、コンピューティング依存領域とメモリ依存領域を区別する重要なバッチ サイズ B* の大まかな近似は、次の式で記述されます。ここで、A_mb はアクセラレータ メモリ帯域幅、A_f はアクセラレータ FLOPS、N は数値です。加速器の。この重要なバッチ サイズは、メモリ アクセス時間が計算時間と等しくなる場所を見つけることで導き出すことができます。参照する このブログ記事 式 2 とその仮定をより詳細に理解するために。

これは、A10G について以前に計算した演算数/バイト比と同じであるため、この GPU のクリティカル バッチ サイズは 116 です。この理論上のクリティカル バッチ サイズに近づく XNUMX つの方法は、モデルのシャーディングを増やし、より多くの N 個のアクセラレータにキャッシュを分割することです。これにより、KV キャッシュ容量とメモリ制限のあるバッチ サイズが効果的に増加します。

モデル シャーディングのもう 1 つの利点は、モデル パラメーターとデータ読み込み作業を N 個のアクセラレータに分割できることです。このタイプのシャーディングは、モデル並列処理の一種であり、シャーディングとも呼ばれます。 テンソル並列処理。単純に言えば、メモリ帯域幅と計算能力は合計で N 倍になります。いかなる種類のオーバーヘッド (通信、ソフトウェアなど) もないと仮定すると、メモリに制約されている場合、トークンごとのデコード レイテンシが N 減少します。これは、この領域でのトークン デコード レイテンシは、モデルのロードにかかる時間によって制限されるためです。重みとキャッシュ。ただし、実際には、シャーディングの度合いを高めると、すべてのモデル層で中間アクティベーションを共有するためのデバイス間の通信が増加します。この通信速度は、デバイスの相互接続帯域幅によって制限されます。その影響を正確に見積もることは困難です (詳細については、 モデルの並列処理)、ただし、これにより最終的にはメリットが得られなくなったり、パフォーマンスが低下したりする可能性があります。これは特に小規模なモデルに当てはまります。これは、データ転送が小さくなると転送速度が低下するためです。

仕様に基づいて ML アクセラレータを比較するには、以下をお勧めします。まず、2 番目の式に従って各アクセラレータ タイプのおおよそのクリティカル バッチ サイズを計算し、最初の式に従ってクリティカル バッチ サイズの KV キャッシュ サイズを計算します。その後、アクセラレータで利用可能な DRAM を使用して、KV キャッシュとモデル パラメータに適合させるために必要なアクセラレータの最小数を計算できます。複数のアクセラレータを選択する場合は、メモリ帯域幅の GB/秒あたりのコストが最も低い順にアクセラレータを優先します。最後に、これらの構成をベンチマークし、必要なレイテンシの上限に対して最適なコスト/トークンがいくらであるかを検証します。

エンドポイント展開構成を選択します

SageMaker JumpStart によって配布される多くの LLM は、 テキスト生成推論 （TGI） SageMaker コンテナ モデルサービス用。次の表では、さまざまなモデル サービス パラメーターを調整して、レイテンシとスループットの曲線に影響を与えるモデル サービスに影響を与える方法、またはエンドポイントを過負荷にするリクエストからエンドポイントを保護する方法について説明します。これらは、ユースケースに合わせてエンドポイント展開を構成するために使用できる主なパラメータです。特に指定がない限り、デフォルトを使用します テキスト生成ペイロードパラメータ および TGI 環境変数.

TGI サーバーは連続バッチ処理を使用します。これは、同時リクエストを動的にバッチ処理して、単一のモデル推論フォワード パスを共有します。フォワード パスには、プレフィルとデコードの 2 種類があります。新しいリクエストごとに、単一の事前入力フォワード パスを実行して、入力シーケンス トークンの KV キャッシュを設定する必要があります。 KV キャッシュが設定された後、デコード フォワード パスは、バッチ化されたすべてのリクエストに対して単一の次トークン予測を実行します。これが反復的に繰り返されて、出力シーケンスが生成されます。新しいリクエストがサーバーに送信されると、新しいリクエストに対して事前入力ステップを実行できるように、次のデコード ステップは待機する必要があります。これは、それらの新しいリクエストが後続の連続的にバッチ処理されるデコード ステップに含まれる前に行われる必要があります。ハードウェアの制約により、デコードに使用される連続バッチ処理にはすべてのリクエストが含まれない場合があります。この時点で、リクエストは処理キューに入り、スループットの向上はわずかですが、推論のレイテンシが大幅に増加し始めます。

LLM レイテンシのベンチマーク分析を、プリフィル レイテンシ、デコード レイテンシ、キュー レイテンシに分離することができます。これらの各コンポーネントで消費される時間は本質的に根本的に異なります。プレフィルは 1 回限りの計算であり、デコードは出力シーケンス内のトークンごとに 1 回発生し、キューイングにはサーバーのバッチ処理が含まれます。複数の同時リクエストが処理されている場合、これらの各コンポーネントからのレイテンシを解きほぐすことは困難になります。これは、特定のクライアント リクエストによって発生するレイテンシには、新しい同時リクエストを事前に入力する必要性によって引き起こされるキュー レイテンシと、インクルードによって引き起こされるキュー レイテンシが含まれるためです。バッチデコードプロセスでのリクエストの。このため、この投稿ではエンドツーエンドの処理遅延に焦点を当てます。待ち時間とスループットの曲線の曲がりは、キューの待ち時間が大幅に増加し始める飽和点で発生します。この現象はどのモデル推論サーバーでも発生し、アクセラレータの仕様によって引き起こされます。

導入時の一般的な要件には、最小必要スループット、最大許容レイテンシ、時間あたりの最大コスト、および 1 万個のトークンを生成するための最大コストを満たすことが含まれます。これらの要件は、エンドユーザーのリクエストを表すペイロードに基づいて条件付けする必要があります。これらの要件を満たす設計では、特定のモデル アーキテクチャ、モデルのサイズ、インスタンス タイプ、インスタンス数 (水平スケーリング) などの多くの要素を考慮する必要があります。次のセクションでは、遅延を最小限に抑え、スループットを最大化し、コストを最小限に抑えるためのエンドポイントの展開に焦点を当てます。この分析では、合計 512 個のトークンと 256 個の出力トークンを考慮します。

遅延を最小限に抑える

レイテンシーは、多くのリアルタイム使用例において重要な要件です。次の表では、各モデルと各インスタンス タイプの最小レイテンシを示します。設定することで遅延を最小限に抑えることができます MAX_CONCURRENT_REQUESTS = 1.

モデルのレイテンシを最小限に抑えるには、次のコードを使用して、目的のモデル ID とインスタンス タイプを置き換えます。

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

レイテンシーの数値は、入力トークンと出力トークンの数に応じて変化することに注意してください。ただし、環境変数を除き、デプロイメントプロセスは同じままです。 MAX_INPUT_TOKENS および MAX_TOTAL_TOKENS。ここで、これらの環境変数は、入力シーケンスが大きくなるとレイテンシ要件に違反する可能性があるため、エンドポイントのレイテンシ要件を保証するために設定されています。 SageMaker JumpStart は、インスタンス タイプを選択するときに他の最適な環境変数をすでに提供していることに注意してください。たとえば、ml.g5.12xlarge を使用すると、 SM_NUM_GPUS モデル環境では 4 に変わります。

スループットを最大化する

このセクションでは、1 秒あたりに生成されるトークンの数を最大化します。これは通常、モデルとインスタンス タイプの有効な同時リクエストの最大数で達成されます。次の表では、リクエストの SageMaker 呼び出しタイムアウトが発生する前に達成される最大同時リクエスト値で達成されるスループットを報告します。

モデルのスループットを最大化するには、次のコードを使用できます。

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

同時リクエストの最大数は、モデル タイプ、インスタンス タイプ、入力トークンの最大数、および出力トークンの最大数によって異なることに注意してください。したがって、設定する前にこれらのパラメータを設定する必要があります。 MAX_CONCURRENT_REQUESTS.

また、レイテンシーの最小化に関心のあるユーザーは、スループットの最大化に関心のあるユーザーと対立することが多いことにも注意してください。前者はリアルタイム応答に関心があるのに対し、後者はエンドポイント キューが常に飽和状態になるようにバッチ処理に関心があり、それによって処理のダウンタイムが最小限に抑えられます。レイテンシ要件に応じてスループットを最大化したいユーザーは、レイテンシとスループットの曲線の中間点での動作に関心を持つことがよくあります。

コストを最小限に抑える

コストを最小限に抑えるための最初のオプションには、時間あたりのコストを最小限に抑えることが含まれます。これにより、選択したモデルを 1 時間当たりの最低コストで SageMaker インスタンスにデプロイできます。 SageMaker インスタンスのリアルタイムの価格については、以下を参照してください。 Amazon SageMakerの料金。一般に、SageMaker JumpStart LLM のデフォルトのインスタンス タイプは、最もコストの低い展開オプションです。

コストを最小限に抑える 1 番目のオプションには、1 万個のトークンを生成するコストを最小限に抑えることが含まれます。これは、スループットを最大化するために前に説明したテーブルの単純な変換です。最初に、1 万個のトークンを生成するのにかかる時間を数時間で計算できます (6e3600 / スループット / 1)。次に、この時間を乗算して、指定された SageMaker インスタンスの XNUMX 時間あたりの価格で XNUMX 万トークンを生成できます。

時間あたりのコストが最も低いインスタンスは、1 万個のトークンを生成するためのコストが最も低いインスタンスと同じではないことに注意してください。たとえば、呼び出しリクエストが散発的である場合は、XNUMX 時間あたりのコストが最も低いインスタンスが最適である可能性がありますが、スロットリング シナリオでは、XNUMX 万個のトークンを生成するための最も低いコストがより適切である可能性があります。

Tensor 並列とマルチモデルのトレードオフ

これまでのすべての分析では、デプロイメント インスタンス タイプの GPU の数と等しいテンソル並列度を持つ単一モデル レプリカをデプロイすることを検討しました。これは、SageMaker JumpStart のデフォルトの動作です。ただし、前述したように、モデルのシャーディングによってモデルのレイテンシとスループットを改善できるのは、一定の制限までのみであり、それを超えると、デバイス間通信要件が計算時間の大半を占めます。これは、より高いテンソル並列度を持つ単一のモデルよりも、より低いテンソル並列度を持つ複数のモデルを 1 つのインスタンスにデプロイする方が有益であることが多いことを意味します。

ここでは、Llama 2 7B および 13B エンドポイントを、テンソル並列 (TP) 次数 4、24、1、および 2 の ml.p4d.8xlarge インスタンスにデプロイします。モデルの動作を明確にするために、これらの各エンドポイントは XNUMX つのモデルのみをロードします。

これまでの分析では、ml.p4d.24xlarge インスタンスでスループットが大幅に向上していることがすでに示されており、これは多くの場合、同時リクエストの負荷が高い条件下で g1 インスタンス ファミリよりも 5 万個のトークンを生成するコストの観点からパフォーマンスが向上することにつながります。この分析は、単一インスタンス内でのモデルのシャーディングとモデルのレプリケーションの間のトレードオフを考慮する必要があることを明確に示しています。つまり、完全にシャード化されたモデルは、通常、4B および 24B モデル ファミリの ml.p7d.13xlarge コンピューティング リソースの最適な用途ではありません。実際、7B モデル ファミリの場合、テンソル並列次数が 4 ではなく 8 である単一モデル レプリカで最高のスループットが得られます。

ここから、7B モデルの最高のスループット構成には、1 つのモデル レプリカを使用したテンソル並列度 13 が含まれ、2B モデルの最高のスループット構成は、XNUMX つのモデル レプリカを使用したテンソル並列度 XNUMX である可能性が高いと推測できます。これを実現する方法の詳細については、以下を参照してください。 Amazon SageMaker の最新機能を使用して、モデルのデプロイメントコストを平均 50% 削減します、推論コンポーネントベースのエンドポイントの使用を示します。負荷分散技術、サーバー ルーティング、および CPU リソースの共有により、レプリカの数と 1 つのレプリカのスループットの積に正確に等しいスループットの向上が完全に達成されない可能性があります。

水平スケーリング

前述したように、各エンドポイント デプロイメントには、入力トークンと出力トークンの数およびインスタンス タイプに応じて、同時リクエストの数に制限があります。これがスループットまたは同時リクエストの要件を満たさない場合は、デプロイされたエンドポイントの背後で複数のインスタンスを利用するようにスケールアップできます。 SageMaker は、インスタンス間のクエリの負荷分散を自動的に実行します。たとえば、次のコードは 3 つのインスタンスでサポートされるエンドポイントをデプロイします。

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

次の表は、Llama 2 7B モデルのインスタンス数の係数としてのスループットの向上を示しています。

特に、インスタンス数が増えると、マルチインスタンス エンドポイント内でより多くの同時リクエストを処理できるため、レイテンシーとスループットの曲線の屈曲部分が右にシフトします。この表の場合、同時リクエストの値はエンドポイント全体のものであり、個々のインスタンスが受信する同時リクエストの数ではありません。

また、ワークロードを監視し、容量を動的に調整する機能である自動スケーリングを使用して、可能な限り低いコストで安定した予測可能なパフォーマンスを維持することもできます。これはこの投稿の範囲を超えています。自動スケーリングの詳細については、以下を参照してください。 Amazon SageMaker で自動スケーリング推論エンドポイントを設定する.

同時リクエストでエンドポイントを呼び出す

高スループット条件下でデプロイされたモデルから応答を生成するために使用したい大量のクエリのバッチがあるとします。たとえば、次のコード ブロックでは、各ペイロードが 1,000 個のトークンの生成を要求する、100 個のペイロードのリストをコンパイルします。合計で 100,000 トークンの生成をリクエストしています。

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

大量のリクエストを SageMaker ランタイム API に送信すると、スロットリング エラーが発生する可能性があります。これを軽減するには、再試行回数を増やすカスタム SageMaker ランタイム クライアントを作成できます。結果の SageMaker セッション オブジェクトを次のいずれかに提供できます。 JumpStartModel コンストラクターまたは sagemaker.predictor.retrieve_default すでにデプロイされているエンドポイントに新しいプレディクターを接続する場合。次のコードでは、デフォルトの SageMaker JumpStart 構成で Llama 2 モデルをデプロイするときにこのセッション オブジェクトを使用します。

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

このデプロイされたエンドポイントには、 MAX_CONCURRENT_REQUESTS = 128 デフォルトでは。次のブロックでは、同時フューチャー ライブラリを使用して、128 ワーカー スレッドを持つすべてのペイロードのエンドポイントの呼び出しを繰り返します。エンドポイントは最大 128 個の同時リクエストを処理し、リクエストが応答を返すたびに、エグゼキュータは直ちに新しいリクエストをエンドポイントに送信します。

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

これにより、単一の ml.g100,000xlarge インスタンス上で 1255 トークン/秒のスループットで合計 5.2 のトークンが生成されます。この処理には約 80 秒かかります。

このスループット値は、この記事の前の表にある ml.g2xlarge での Llama 7 5.2B の最大スループット (486 の同時リクエストで 64 トークン/秒) とは著しく異なることに注意してください。これは、入力ペイロードが 8 ではなく 256 トークンを使用し、出力トークン数が 100 ではなく 256 であり、トークン数が小さいため 128 個の同時リクエストが可能であるためです。これは、すべてのレイテンシーとスループットの数値がペイロードに依存するということを最後に思い出させるものです。ペイロード トークン数を変更すると、モデルの提供中のバッチ処理に影響があり、その結果、アプリケーションの緊急のプリフィル、デコード、キュー時間に影響します。

まとめ

この投稿では、Llama 2、Mistral、Falcon を含む SageMaker JumpStart LLM のベンチマークを紹介しました。また、エンドポイント展開構成のレイテンシー、スループット、コストを最適化するためのガイドも紹介しました。を実行して開始できます。 関連するノートブック ユースケースのベンチマークを行うために。

著者について

 カイル・ウルリッヒ博士 Amazon SageMaker JumpStart チームの応用科学者です。 彼の研究対象には、スケーラブルな機械学習アルゴリズム、コンピューター ビジョン、時系列、ベイジアン ノンパラメトリック、ガウス プロセスなどがあります。 彼はデューク大学で博士号を取得しており、NeurIPS、Cell、および Neuron で論文を発表しています。

Dr。ヴィヴェク・マダン Amazon SageMaker JumpStart チームの応用科学者です。 イリノイ大学アーバナ シャンペーン校で博士号を取得し、ジョージア工科大学で博士研究員を務めました。 彼は機械学習とアルゴリズム設計の活発な研究者であり、EMNLP、ICLR、COLT、FOCS、および SODA カンファレンスで論文を発表しています。

アシッシュ・ケタン博士 Amazon SageMaker JumpStart の上級応用科学者であり、機械学習アルゴリズムの開発を支援しています。 イリノイ大学アーバナ・シャンペーン校で博士号を取得しました。 彼は機械学習と統計的推論の積極的な研究者であり、NeurIPS、ICML、ICLR、JMLR、ACL、および EMNLP カンファレンスで多くの論文を発表しています。

ジョアンモウラ AWS のシニア AI/ML スペシャリスト ソリューション アーキテクトです。 João は、小規模なスタートアップ企業から大企業まで、AWS の顧客が大規模なモデルを効率的にトレーニングしてデプロイし、より広範に AWS 上で ML プラットフォームを構築できるよう支援しています。

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
• プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
• プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
• プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
• 情報源： https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/