Amazon SageMaker を使用して Falcon モデルのパフォーマンスを向上させる | アマゾン ウェブ サービス

テキストを生成する生成 AI アプリケーション用の大規模言語モデル (LLM) をホストするための最適なフレームワークと構成は何ですか? LLM を提供するためのオプションは豊富にありますが、モデルのサイズ、さまざまなモデル アーキテクチャ、アプリケーションのパフォーマンス要件などにより、これは答えるのが難しい質問です。 の アマゾンセージメーカー 大規模モデル推論 (LMI) コンテナー LLM の展開を最適化するさまざまなフレームワークと技術を統合することにより、LLM へのサービスの提供が簡単になります。 LMI コンテナには、と呼ばれる強力なサービング スタックがあります。 DJLサービス これは、基礎となる LLM に依存しません。 これは、特定の LLM のホスティング インフラストラクチャの最高のパフォーマンスを引き出すために調整できるシステム レベルの構成パラメータを提供します。 また、反復バッチ処理またはローリング バッチ処理とも呼ばれる連続バッチ処理などの最近の最適化もサポートされており、スループットが大幅に向上します。

以前の 役職では、LMI コンテナを使用して Falcon ファミリのモデルを SageMaker にデプロイする方法を説明しました。 この投稿では、連続バッチ処理などの手法を使用して、Falcon-40B を提供する際のスループットと遅延を改善する方法を示します。 また、SageMaker LMI コンテナによって提供される構成パラメータを直感的に理解できるようになり、実際のアプリケーションに最適な構成を見つけることができます。

LLM のテキスト生成推論の基礎

まず、テキスト生成のための LLM の推論を実行する方法について、いくつかの基本を見てみましょう。

フォワードパス、アクティベーション、および KV キャッシュ

トークンの入力シーケンスが与えられると、それらは forward pass LLM (Falcon など) のすべての層にわたって次のトークンを生成します。 あ forward pass 入力データがニューラル ネットワークを通過して出力を生成するプロセスを指します。 テキスト生成の場合、前方パスには、初期シードまたはコンテキストを言語モデルに供給し、シーケンス内の次の文字またはトークンを生成することが含まれます。 テキストのシーケンスを生成するには、多くの場合、プロセスが反復的に実行されます。これは、出力シーケンス内のステップまたは位置ごとにプロセスが繰り返されることを意味します。 各反復で、モデルは次の文字またはトークンを生成し、それが生成されたテキストの一部となり、このプロセスは必要な長さのテキストが生成されるまで継続されます。

Falcon や GPT などの言語モデルを使用したテキスト生成は、 autoregressive。 これは、モデルが以前に生成されたトークンに基づいて条件付けしながら、一度に XNUMX つのトークンを生成することを意味します。 つまり、各反復で、モデルは以前に生成されたテキストを入力として受け取り、そのコンテキストに基づいて次のトークンを予測します。 で述べたように vLLM: PagedAttendant を使用した簡単、高速、低コストの LLM サービス、この自己回帰デコード プロセスでは、LLM へのすべての入力トークンがアテンション キーと値のテンソルを生成し、これらのテンソルは次のトークンを生成するために GPU メモリに保持されます。 これらのキャッシュされたキーと値のテンソルは、多くの場合、 KV cache.

プレフィルフェーズとデコードフェーズ

Falcon などの言語モデルによるテキスト生成で使用されるプロセスと同様、自己回帰デコード プロセスには、通常 XNUMX つの主要なフェーズがあります。 prefill フェーズと decode 段階。 これらのフェーズは、一貫した文脈に関連したテキストを生成するために重要です。

プレフィルフェーズには次のものが含まれます。

• 初期コンテキスト – 事前入力フェーズは、ユーザーが提供する初期コンテキストまたはシード テキストから始まります。 この最初のコンテキストは、文、語句、または単一の単語の場合もあります。 これはテキスト生成の開始点を設定し、次に行われる内容のコンテキストを提供します。
• モデルの調整 – 提供されたコンテキストは、言語モデルを条件付けるために使用されます。 モデルはこのコンテキストを入力として受け取り、コンテキストの理解に基づいてシーケンス内の次のトークン (単語または文字) を生成します。
• トークンの生成 – モデルは一度に XNUMX つのトークンを生成し、テキスト内で次に何が来るかを予測します。 このトークンはコンテキストに追加され、効果的にコンテキストを拡張します。
• 反復プロセス – トークンを生成するプロセスは反復的に繰り返されます。 各ステップで、モデルは更新されたコンテキストを考慮しながらトークンを生成します。これには、前のステップで生成されたトークンが含まれます。

プレフィルフェーズは、所定の停止条件が満たされるまで継続します。 この条件には、生成されるテキストの最大長、テキストの終わりを示す特定のトークン、またはユーザーまたはアプリケーションによって設定されるその他の基準を指定できます。

デコード フェーズには次のものが含まれます。

• 完成 – 事前入力フェーズの後、部分的に生成されたテキストが、ある時点で不完全であるか、途切れている可能性があります。 デコードフェーズは、テキストを完成させて一貫性があり、文法的に正しいものにする責任があります。
• 最後のトークンからの続き – デコードフェーズでは、モデルはプレフィルフェーズ中に生成された最後のトークンから開始されます。 このトークンを初期コンテキストとして使用し、テキストを継続するための次のトークンを生成します。
• 反復完了 – プレフィルフェーズと同様に、トークン生成プロセスも反復的です。 モデルは、シーケンス内の先行するトークンを条件として、一度に XNUMX つのトークンを生成します。
• 停止条件 – デコード フェーズにも停止条件があります。これは、最大長に達した場合やテキスト終了トークンに遭遇した場合など、プレフィル フェーズと同じ場合があります。 この条件が満たされると、生成プロセスが停止します。

プレフィル フェーズとデコード フェーズを組み合わせることで、自己回帰モデルで初期コンテキストに基づいて構築され、一貫性があり、コンテキストに関連性​​があり、コンテキスト的に一貫したテキストのシーケンスを生成するテキストを生成できます。

参照する 変圧器ベースの生成モデル用の分散サービス システム プロセスの詳細な説明については、

動的バッチ処理を使用したスループットの最適化

これまでは、単一の入力についてのみ説明してきました。 実際には、推論のためにアプリケーション クライアントからランダムに受信する複数のリクエストを同時に、または時間差で処理することが予想されます。 従来の方法では、基本的なバッチ処理を使用して、スループットと GPU のコンピューティング リソースの使用率を向上させることができます。 バッチ処理では、バッチ内の複数のリクエストの数値表現を効果的に組み合わせ、自己回帰フォワード パスの並列実行を実行します。 このインテリジェントなバッチ処理はサービスを提供する側で行われます。 SageMaker LMI の DJLServing サーバーは、次のパラメータを設定することで、複数のリクエストをバッチ処理して並列処理するように設定できます。 サービング.プロパティ:

• 最大バッチ遅延 = 100 – バッチ集約の最大遅延 (ミリ秒単位)。 デフォルト値は 100 ミリ秒です。
• バッチサイズ = 32 – 動的バッチ サイズ。 デフォルトは 1 です。

これは基本的に、DJLServing が一度に 100 ミリ秒間リクエストをキューに入れるか、キューに入れられるリクエストの数が指定された batch_size までの場合、バッチが推論のためにバックエンドで実行されるようにスケジュールされることを示しています。 これはとして知られています dynamic batching。 バッチ サイズは、その期間内に追加されたリクエストの数に応じてバッチ間で変化する可能性があるため、動的です。 ただし、リクエストには異なる特性がある可能性があるため (たとえば、一部のリクエストは入力トークンが 20 トークン、出力トークンが 500 トークンである一方、その他のリクエストは逆で、入力トークンが 500 トークンだが出力トークンが 20 のみである場合があります)、一部のリクエストは同じバッチ内の他のバッチよりも速く処理を完了します。 これにより、キュー内で処理を待機している追加のリクエストがある場合でも、バッチ内のすべての実行中のリクエストがデコード ステージを完了するのを待機している間に、GPU が十分に活用されなくなる可能性があります。 次の図は、このプロセスを示しています。

連続バッチ処理を使用したスループットの最適化

continuous batching、 としても知られている iterative or rolling バッチ処理では、プリフィル ステージとデコード ステージの違いを利用します。 連続バッチ処理を有効にするために、DJServing は、serving.properties に従って次の追加構成を提供します。

• エンジン=MPI – 連続バッチ処理には MPI エンジンを使用することをお勧めします。
• オプション.ローリングバッチ=auto または lmi-dist – 今後他の最適化とともに最も適切なローリング バッチ アルゴリズムが自動的に選択されるため、auto を使用することをお勧めします。
• option.max_rolling_batch_size=32 – これにより、同時リクエストの数が制限されます。 デフォルトは 32 です。

連続バッチ処理では、サービング スタック (DJLServing) は、バッチ内のすべての実行中のリクエストがデコード ステージを完了するのを待ちません。 むしろ、論理的な中断時 (デコード ステージの XNUMX 回の反復の終了時) に、現在のバッチの処理中にキューで待機している追加のリクエストを引き込みます (そのため、この名前が付けられています)。 ローリングバッチ）。 デコードステージの各反復の終了時に、保留中のリクエストのチェックが行われます。 リクエストごとに、プレフィル ステージを実行し、その後に順次デコード ステージを実行する必要があることに注意してください。 リクエストの最初のプロンプトからのすべてのトークンをプレフィル ステージで並行して処理できるため、新しいリクエストが取り込まれるたびに、バッチの処理中のリクエストのデコード ステージを一時的に停止し、その KV キャッシュを一時的に保存します。メモリ内でアクティベーションを実行し、新しいリクエストの事前入力ステージを実行します。

このキャッシュのサイズは、次のオプションで構成できます。

プレフィルが完了すると、新しいリクエストと古い一時停止リクエストを新しいローリング バッチに結合し、デコード ステージを並行して進めることができます。 一時停止された古いリクエストは中断したところからデコード ステージを続行でき、新しいリクエストは最初の新しいトークンから開始されることに注意してください。

連続バッチ処理は、私たちが日常生活で自然にタスクを並列化するアプローチとほぼ同じであることにすでに気づいているかもしれません。 メッセージ、電子メール、電話通知 (新しいリクエストの可能性があります) がランダムなタイミングで届きます (GPU でランダムに時間差で届く複数のリクエストに似ています)。 これはすべて、電子メールの作成、コーディング、会議への参加など、実行中のタスク (GPU で現在処理されているタスクに似ています) を完了している間に行われます。 論理的な中断では、処理中のタスクを一時停止し、通知を確認して、側で何らかのアクションが必要かどうかを判断し、必要なアクションがある場合は、それを処理中のタスク (実際のローリング バッチ) に追加します。それをToDoリスト（キュー）に入れます。

すべてをまとめる: GPU のメモリ使用率についてどのように考えるか

モデルの負荷テストを行って、ビジネス ユースケースにとってどの構成が最もコスト効率が高いかを確認することをお勧めします。 理解を深めるために、モデルがロードされ、連続するリクエストがローリング バッチで処理されるときの GPU のメモリ フットプリントを視覚化してみましょう。 この投稿では、それぞれ 40 GB のメモリを備えた NVIDIA A5G GPU がインストールされている G10 インスタンス タイプのインスタンスの 24 つに Falcon-3B モデルをロードしていると仮定します。 V4、A5、および H100 GPU シリーズに付属する p100、p100、および pXNUMX インスタンス タイプにも同様の理解が適用できることに注意してください。

以下は、Falcon-40B にサービスを提供するために必要な合計メモリのおおよその値を取得する概要です。

• モデルサイズ = モデルパラメータの数 (Falcon-40B の場合は 40 億) x パラメータあたり 4 バイト (FP32 の場合) = 160 GB
• 推論のために Falcon-40B をロードするために必要なおおよその合計メモリ = モデル サイズ (=160 GB) + KV キャッシュ (アテンション キャッシュ) (=*20 GB) + ML フレームワークによる追加のメモリ オーバーヘッド (約 2 GB)

Falcon-40B の場合、モデルを bfloat16 (2 バイト) データ型に量子化して圧縮すると、モデルのサイズは約 80 GB になります。 ご覧のとおり、これは XNUMX つのアクセラレータ デバイスでサポートされるメモリよりもまだ大きいため、特別な機能を備えたモデル パーティショニング (シャーディング) 手法を採用する必要があります。 テンソル並列処理 (TP) は、複数のアクセラレータ デバイスにわたってモデルにアプローチし、シャーディングします。 5.24 つの A4G GPU デバイスを備えた g10xlarge を選択したと仮定します。 DJLServing (serving.properties) を次のように構成すると、80 GB のモデルの重みが 4 つの GPU すべてに均等に分割されることが期待できます。

tensor_parallel_degree 4 に設定すると、20 GB GPU メモリのうち約 24 GB (約 84%) が、16 つのリクエストが処理される前でもすでに使用されています。 GPU の残りの 2% は、受信リクエストの KV キャッシュに使用されます。 ビジネス シナリオとその遅延とスループットの要件では、3 ～ 5.48 GB の残りのメモリで十分な可能性があります。 そうでない場合は、インスタンス サイズを g8xlarge に増やすことができます。これは 8 つの GPU を持ち、10 に設定された tensor_Parallel_degree を使用します。そのような場合、各 GPU の利用可能な 24 GB メモリのうち約 60 GB のみがモデルの重みに利用されます。残りの GPU の約 XNUMX% がアクティベーションと KV キャッシュに使用されます。 直感的には、この構成によりスループットが向上する可能性があることがわかります。 さらに、バッファーが大きくなったので、 max_rolling_batch_prefill_tokens および max_rolling_batch_size パラメータを調整してスループットをさらに最適化します。 これら XNUMX つのパラメーターを合わせて、モデルのアクティベーション プレフィルと KV キャッシュの事前割り当てを制御します。 GPU メモリ内に KV キャッシュ用の十分なバッファがあると仮定すると、これら XNUMX つのパラメータの数値が大きいほど、スループットが大きくなります。

PagedAttention を使用した連続バッチ処理

PagedAttendance は、UC Berkeley によって開発された新しい最適化アルゴリズムで、固定サイズのページまたはブロックにメモリを割り当てることでアテンション キャッシュ (KV キャッシュ) を非連続にできるようにすることで、連続バッチ処理プロセスを改善します。 これは、オペレーティング システムで使用される仮想メモリとページングの概念からインスピレーションを得ています。

毎回 vLLM 論文では、トークンの各シーケンスのアテンション キャッシュはブロックに分割され、ブロック テーブルを通じて物理ブロックにマッピングされます。 アテンションの計算中に、PatedAttendant カーネルはブロック テーブルを使用して、物理メモリからブロックを効率的にフェッチできます。 これにより、メモリの無駄が大幅に削減され、バッチ サイズが大きくなり、GPU 使用率が向上し、スループットが向上します。

性能比較

デプロイメント構成の効果的な負荷テストを確実に行うには、ビジネス シナリオを検討し、LLM ベースのアプリケーションの入力と出力の特性を明確に定義することから始めることをお勧めします。 たとえば、コールセンターの要約ユースケースに取り組んでいる場合、入力はカスタマー サービス エージェントと顧客の間の 500 トークンのチャット記録など、より大きなテキストで構成される可能性がありますが、出力は比較的小さく、約 100 トークンになる可能性があります。トランスクリプトの概要を表すトークン。 一方、コード生成シナリオに取り組んでいる場合、「ページネーションを含むすべての EC15 リソースを記述するための効率的な実装を Python で作成する」など、入力は 2 トークン程度と短い可能性がありますが、出力は大幅に長くなる可能性があります。さらに大きくなり、500 トークンに達します。 特定のシナリオでは、待ち時間の短縮とスループットの最大化のどちらが最優先であるかを検討することも重要です。

ビジネス シナリオを包括的に理解した後、ホスティング環境に最適な構成を分析して決定できます。 この文脈では、ホスティング環境には、インスタンス タイプやその他の構成パラメータなど、さまざまな重要な要素が含まれます。 tensor_Parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens、 もっと。 私たちの目的は、応答時間、スループット、モデル出力の品質要件をサポートする最も効果的なセットアップを特定することです。

私たちの分析では、従来の動的バッチ処理に対する連続バッチ処理の利点を示すためにパフォーマンスのベンチマークを実施しました。 SageMaker 上の LMI コンテナを使用して、動的バッチ処理と反復バッチ処理のために、serving.properties の次の表に詳しく説明されている設定を使用しました。

動的バッチ処理	連続バッチ処理	PagedAttention を使用した連続バッチ処理
エンジン=Python option.model_id=tiiuae/falcon-40b オプション.tensor_Parallel_degree=8 オプション.dtype=fp16 バッチサイズ=4 max_batch_delay=100 option.trust_remote_code = true	エンジン＝MPI option.model_id = {{s3_url}} option.trust_remote_code = true オプション.tensor_Parallel_degree = 8 オプション.max_rolling_batch_size = 32 option.rolling_batch = 自動 オプション.dtype = FP16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = False	エンジン＝MPI option.model_id = {{s3_url}} option.trust_remote_code = true オプション.tensor_Parallel_degree = 8 オプション.max_rolling_batch_size = 32 option.rolling_batch = 自動 オプション.dtype = FP16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = True

40 つの構成は、実際のアプリケーションを表すいくつかの異なるシナリオで、ml.g16xlarge にデプロイされた FP5.48 データ型を使用した Falcon-XNUMXB についてベンチマークされました。

• 少数の入力トークンと大量のトークンが生成される – このシナリオでは、入力トークンの数は 32 に固定され、128 個の新しいトークンが生成されました

バッチ戦略	スループット (トークン/秒)	レイテンシ p90 (秒)
動的バッチ処理	5.53	58.34
連続バッチ処理	56.04	4.74
PagedAttention を使用した連続バッチ処理	59.18	4.76

• 大量の入力で少数のトークンが生成される – ここでは、入力トークンの数を 256 に固定し、LLM に入力を 32 トークンに要約するよう促します。

バッチ戦略	スループット (トークン/秒)	レイテンシ p90 (秒)
動的バッチ処理	19.96	59.31
連続バッチ処理	46.69	3.88
PagedAttention を使用した連続バッチ処理	44.75	2.67

PagedAttendant を使用した連続バッチ処理では、LMI コンテナを使用しながら SageMaker で動的バッチ処理を使用した場合と比較して、シナリオ 10 では 1 倍、シナリオ 2.3 では 2 倍のスループット向上が得られることがわかります。

まとめ

この投稿では、LLM がメモリをどのように使用するかを調べ、SageMaker 上の LMI コンテナを使用して連続バッチ処理がどのようにスループットを向上させるかを説明しました。 ベンチマーク結果を示すことで、SageMaker 上の LMI コンテナを使用した Falcon-40B の連続バッチ処理の利点を実証しました。 コードは次の場所にあります。 GitHubレポ.

---

著者について

アビ・シヴァディティヤ AWS のシニア ソリューション アーキテクトであり、戦略的なグローバル企業組織と協力して、人工知能、分散コンピューティング、ネットワーキング、ストレージなどの分野での AWS サービスの導入を促進しています。 彼の専門知識は、自然言語処理 (NLP) とコンピューター ビジョンの分野における深層学習にあります。 Abhi は、お客様が AWS エコシステム内で高性能の機械学習モデルを効率的にデプロイできるよう支援します。

ダワル・パテル AWSのプリンシパル機械学習アーキテクトです。 彼は、分散コンピューティングや人工知能に関連する問題について、大企業から中規模の新興企業に至るまでの組織と協力してきました。 彼は、NLPおよびコンピュータービジョンドメインを含むディープラーニングに焦点を当てています。 彼は、顧客がSageMakerで高性能モデルの推論を実現するのを支援します。

ピナック・パニグラヒ は顧客と協力して、AWS 上の戦略的なビジネス上の問題を解決するための機械学習主導のソリューションを構築します。 機械学習に夢中になっていないときは、ハイキングをしたり、本を読んだり、スポーツを観戦したりしています。

アビ・ソダニ AWS ではシニア AI/ML ソリューション アーキテクトの役職を務めており、ジェネレーティブ AI および ML ソリューションに関する技術的な専門知識とガイダンスを顧客に提供することを専門としています。 彼の主な焦点は、デジタル ネイティブ ビジネスが生成 AI および ML テクノロジーの可能性を最大限に実現し、ビジネス目標を効果的に達成できるように支援することです。 アビは、職業上の努力以外にも、ヨガや瞑想などの身体的および精神的な健康を促進する活動に従事するだけでなく、読書などの知的探求にも強い情熱を示しています。

青蘭 AWS のソフトウェア開発エンジニアです。 彼は、高性能 ML 推論ソリューションや高性能ロギング システムなど、Amazon でいくつかの挑戦的な製品に取り組んできました。 Qing のチームは、Amazon Advertising で最初の XNUMX 億パラメータ モデルを成功裏に立ち上げ、非常に低いレイテンシーを必要としました。 Qing は、インフラストラクチャの最適化とディープ ラーニングの高速化に関する深い知識を持っています。

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