📖

re:Invent 2023: AWSが語るSageMakerによる数百のFM推論のスケーリング

2023/11/28に公開

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら!

📖 AWS re:Invent 2023 - Scaling FM inference to hundreds of models with Amazon SageMaker (AIM327)

この動画では、AWSのMachine Learning SpecialistのDhawal Patelが、Amazon SageMakerを使用したFoundation Modelの推論のスケーリングについて解説します。Salesforceの事例を交えながら、数百のFoundation modelを効率的にデプロイする方法や、新しいSageMaker Inference Component Endpointの活用法を紹介。コスト削減と性能向上を両立させる具体的な戦略が学べる、最新のAI基盤構築に関する貴重な情報が満載です。
https://www.youtube.com/watch?v=6xENDvgnMCs
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。

本編

自己紹介とセッションの概要

Thumbnail 0

Thumbnail 20

みなさん、こんにちは。Parsonでこのような素晴らしい会場に皆様とご一緒できることを大変嬉しく思います。本日のセッション「Amazon SageMakerを使用したFoundation Modelの推論のスケーリング」にご参加いただき、ありがとうございます。 もし、この発表全体とこれからご覧いただくデモが生成AIを使って作られたと言ったら、驚かれるでしょうね。実際には、手作業で準備しましたが、そのような方法で作れたらいいなと思います。

自己紹介させていただきます。私はDhawal Patelと申します。AWSのMachine Learning Specialistのソリューションアーキテクチャチームを率いています。Salesforceのようなお客様がAWS上で機械学習ワークロードをスケーリングする際のサポートを行っています。本日は、SageMaker Product teamのInferenceを担当している同僚のAlan Tanも同席しています。彼は本日発表するSageMaker Inferenceの新機能についてお話しします。また、Salesforceの機械学習プラットフォームの構築を担当されているVice PresidentのBhavesh Doshi様にもご参加いただいています。彼のチームがSageMakerを使用してFoundation modelの推論を効率的にスケーリングする方法についてお話しいただきます。Bhavesh様、本日はお越しいただき、ありがとうございます。

簡単な質問をさせていただきます。手を挙げてお答えください。現在、生成AIアプリケーションを開発している方はいらっしゃいますか?ほぼ全員ですね、素晴らしい。そのためにオープンソースのFoundation modelを使用している方は?かなり多いですね。SageMakerを使ってモデルをデプロイしている方は?素晴らしい。アプリケーション開発において、推論に複数のFoundation modelを使用する必要がある方は?素晴らしいですね。今日は素晴らしい聴衆の皆様にお集まりいただきました。このセッションをきっと楽しんでいただけると思います。

Foundation Modelsの概要と課題

Thumbnail 140

Thumbnail 160

それでは始めましょう。私たちは今、組織が戦略的に生成AIアプリケーションを日々の業務に組み込むという、パラダイムシフトを目の当たりにしています。これにより、新たな可能性が開かれ、かつてない生産性の向上が実現されています。 生成AIアプリケーションを構築するための中核となるのがFoundation modelです。Foundation modelは、一般的なタスクに優れた、あるいは特定のタスクに微調整可能な、大規模な事前学習済みのTransformerベースのモデルです。通常、本番環境で使用するエンドツーエンドの生成AIアプリケーションを構築する際には、複数のFoundation modelが関与します。

例を挙げましょう。生成AIチャットボットアプリケーションには、有害性検出、PII検出、要約、Q&Aモデル、ワークフロー生成、検索モデル、埋め込みモデルなど、さまざまなFoundation modelが必要です。このリストはまだまだ続きます。さらに、お客様は自社の顧客データセットやドメインデータセットに基づいて、これらのFoundation modelの精度を向上させたいと考えています。これらのモデルをさらに微調整し、本番環境にデプロイしたいと考えています。また、画像、テキスト、コード、動画などのマルチモーダルデータを使用したいと考えています。結果として、数十から数百のFoundation modelを大規模にデプロイする必要が出てきます。これらのFoundation modelをスケーラブルかつコスト効率よくホストする方法が必要となります。

Thumbnail 260

Thumbnail 300

これらのモデルは非常に大規模で、数千億のパラメータを持ち、ロードするには数百ギガバイトのメモリが必要です。これらは transformer アーキテクチャに基づいており、高価なハードウェアでも驚くほど遅い場合があります。これらの foundation model のパフォーマンスチューニングに必要な反復的な実験を考えてみてください。最高の応答時間とスループットを低コストで達成する必要があります。 また、これらのモデルを分離し、その影響範囲を管理するためのガードレールを実装することも忘れないでください。

Thumbnail 320

Thumbnail 330

影響範囲を制御し、ガードレールを設置して、あるモデルが他のモデルに問題を引き起こさないようにし、ノイジーネイバーの問題を防ぐのです。 ちなみに、これらの foundation model をホストするために、数百のインференスエンドポイントを用意することになるかもしれません。これにより、運用上のオーバーヘッドが増加することになります。

Foundation Modelのデプロイメントプロセスと課題

Thumbnail 350

では、1つの foundation model を本番環境にデプロイする過程をご紹介し、Amazon SageMaker を使用して、どのようにしてコスト効率よく数百の foundation model を大規模に展開できるかを見ていきましょう。始めましょう。 foundation model をホストするために最初に行うのは、そのサイズを計算することです。この場合、Llama 2-13B モデルを例にとると、モデルのサイズは主にパラメータの数と各パラメータのサイズに依存します。Llama 2-13B には130億のパラメータがあり、各パラメータは4バイト(FP32)を占めます。

Thumbnail 380

Thumbnail 410

Thumbnail 420

モデルのパラメータをロードするだけで約52ギガバイトのメモリが必要になります。大規模言語モデルの foundation model では、入力トークンを受け取り、これらのトークンを反復的に処理して次のトークンを出力する自己回帰的なデコーディングプロセスがあります。このプロセス全体で、メモリに保持しなければならないアテンションキー値テンソルが作成され、 それがさらに4〜10ギガバイトのメモリを占めます。 さらに、PyTorch や NVIDIA CUDA などのフレームワークを使用する必要があり、これらが追加で2〜3ギガバイトのメモリを占めます。

つまり、Llama 2-13B の1つのインスタンスをロードするだけで、合計約65ギガバイトのメモリが必要になるのです。もちろん、量子化メカニズムなどの異なる技術を使用してモデルのサイズを圧縮することもできますが、それには精度の低下というトレードオフが伴います。そのため、今回はパラメータあたり4バイトを使用し続けることにします。したがって、1つのインスタンスに対して65ギガバイトのモデルを扱う必要があります。

Thumbnail 460

Thumbnail 500

さて、ロードする必要のあるメモリ容量は65ギガバイトです。そこで、インスタンスを選択します。この場合、8台のNVIDIA A100 GPUを搭載したML Instance P4dを選びました。各GPUには40ギガバイトの高帯域メモリが搭載されています。明らかに、65ギガバイトのモデルをどのGPUのメモリにも収めることはできません。そこで、モデルパーティショニングロジック、つまりモデルパラレルロジックを使用して、 モデル全体を2つのシャードに分割します。8台のGPUのうち2台を使用することになります。

Thumbnail 520

では、残りの6台のGPUはどうでしょうか?それらは単に遊んでいる状態です。つまり、計算能力とメモリの75%が空いたままで遊休状態なのです。もっと効率的にできないでしょうか?考えてみましょう。 同じモデルのコピーを追加で読み込み、残りの3台のGPUにロードして、メモリの使用率を最大化するのはどうでしょうか。これらのモデルを追加のGPUにロードすると、最終的に4つのモデルコピーが得られ、GPUの使用率を100%まで引き上げることができる可能性があります。

ただし、これはモデルが十分な本番トラフィックを受け取り、計算能力の使用率を100%まで引き上げられるかどうかによります。モデルが期待するほど頻繁に呼び出されない場合、アイドル状態のままとなり、最適な価格性能比は得られません。これを念頭に置いて、このモデルを本番環境に投入し、モデルのトラフィックに応じてスケールさせましょう。

Amazon SageMakerの推論オプションとLarge Model Inferenceコンテナ

Thumbnail 580

そのために、Amazon SageMaker inferenceは、あらゆるユースケースに対応する、最も幅広く深い推論オプションを提供しています。完全マネージド型のSageMaker real-time inferenceエンドポイントを使用し、RESTful APIでこのエンドポイントを呼び出してストリーミングレスポンスを取得できます。SageMakerは大規模データセット向けのオフライン推論オプションもサポートしています。

ペイロードのサイズが画像や動画のように大きい場合は、SageMaker asynchronous inferenceエンドポイントを使用し、トラフィックに応じてゼロまでスケールダウンできます。単一のモデルやモデルのアンサンブルをホストすることができます。また、これらのモデルをシリアル推論パイプラインにオーケストレーションし、まとめてワークフローを調整することもできます。SageMakerエンドポイントは、同じエンドポイント内で複数のモデルをホストすることも可能です。ハードウェアとインフラストラクチャの面では、CPU、AWS Inferentia、NVIDIA GPU、あるいは完全サーバーレスを選択できます。

Thumbnail 670

Thumbnail 680

SageMakerのリアルタイム推論エンドポイントを使用して、チャットボットのユースケースにLlama 2-13Bモデルをホストしてみましょう。 Llama 2があり、次にこのモデルをホストするコンテナを選択する必要があります。今回は、Large Model Inference(LMI)コンテナを使用します。このコンテナの使用をお勧めする理由は、SageMakerのLMIコンテナに新機能が多数追加され、平均で20%のレイテンシ削減が実現できるからです。最適化されたall-reduceアルゴリズムなどの新しい最適化が導入されました。また、TensorRT-LLMバックエンドとの統合により、応答時間とスループットの面で最適化されたパフォーマンスが得られます。したがって、推論時の基盤モデルのホスティングにはLMIコンテナを使用することをお勧めします。

Thumbnail 730

Thumbnail 740

Thumbnail 760

LMIコンテナを用意し、機械学習インスタンスを選択します。今回は、先ほど言及した8つのGPUを搭載したP4dを使用します。次に、ユーザートラフィックに基づいて水平方向にスケールするための自動スケーリングポリシーを設定します。これをSageMaker推論エンドポイントに適用し、スループット、ハードウェア使用率、または応答時間の目標に応じて、任意の数のインスタンスに水平方向にスケールします。ユーザーはRESTful APIを使用してエンドポイントを呼び出し、ストリーミングレスポンスを取得できます。これで、Llama 2モデルが本番環境で稼働し、チャットボット用にスケールアウトしています。

SageMaker Inference Component Endpointの導入

Thumbnail 780

Thumbnail 790

Thumbnail 810

Thumbnail 820

さて、チャットボットアプリケーションのコンテンツをモデレートしたいとします。そこで、有害性検出エンドポイントを追加します。また、顧客のPIIデータを保護したいので、PIIエンドポイントも追加します。さらに、チャットボットが幻覚を起こす可能性があることに気づき、検索と埋め込みモデルを追加することにします。開発者向けに追加のユースケースをサポートし、コード生成にチャットボットを使用できるようにしたいので、コード生成エンドポイントも追加します。そして、多言語サポートと音声生成も必要になります。さらに、顧客データに基づいてこれらのモデルをファインチューニングしたいと考えています。このようにエンドポイントの数が増え続けます。

Thumbnail 840

Thumbnail 850

Thumbnail 860

ホストおよび管理するエンドポイントの数が増えていくのがわかります。これにより運用オーバーヘッドが高くなります。このままでは効率的にスケールすることができません。SageMaker上でこれらの基盤モデルをより効率的にサービス提供し、Generative AIアプリケーションを構築するためのより良い方法が必要です。では、同じSageMaker推論エンドポイントにより多くのモデルをパッキングできないでしょうか?その方法を見てみましょう。これらの基盤モデルを1つのSageMakerエンドポイントにホストするのはどうでしょうか?それは良い選択肢ですが、これらのモデルがそのインスタンスの機械学習アクセラレータに収まらない場合、すべてのモデルを同時にホストすることはできません。

Thumbnail 880

では、どうすればよいでしょうか?ここで、SageMakerのマルチモデル推論エンドポイントを使用できます。SageMakerマルチモデル推論エンドポイントは、複数の基盤モデルを共同ホストし、フリート内の複数のMLインスタンスに分散させるための完全管理型オプションです。ユーザーによって呼び出されるモデルに基づいて、これらのモデルを動的にロードします。

このダイナミックローディングは呼び出し時に発生します。また、スマートなルーティングロジックを使用して、特定のモデルの推論トラフィックを、すでにメモリにロードされているインスタンスにのみルーティングし、コールドスタートを回避します。さらに、モデルの人気度に基づいてレプリケーションを行います。あるモデルが高いトラフィックを受けている場合、動的に多くのレプリカを立ち上げます。これってすごくないですか?

Thumbnail 990

ただし、これらのモデルに最初に来る呼び出しリクエストは、コールドスタートの遅延を経験することになります。これらのモデルは大規模なので、高帯域幅メモリにロードするのに数秒から数分かかる可能性があり、超低遅延を求めるアプリケーションには適していないかもしれません。では、どうすればいいのでしょうか?超低遅延アプリケーションで複数のfoundation modelを大規模に推論用にホストするには、複数のfoundation modelを単一のエンドポイントにパッキングして、運用オーバーヘッドを抑えてコストを削減する必要があります。そして、コールドスタートの遅延に悩まされないようにする必要もあります。

Thumbnail 1000

Thumbnail 1010

推論リクエストが来る前にこのメモリを早めにロードし、メモリにピン留めすることができます。そして、モデルのニーズに基づいて、機械学習アクセラレータの細かい割り当てを行うことも確認する必要があります。また、機械学習インスタンスだけでなく、モデルに基づいた細かい自動スケーリングポリシーを提供するためのガードレールを設けたいところです。高いトラフィックを受けているモデルはスケールアウトでき、ほとんどトラフィックを受けていないモデルはスケールする必要がなく、コスト削減のためにゼロまでスケールダウンできるようにすべきです。

Thumbnail 1050

さらに、モデル固有のレスポンスタイム、モデル固有のスループット、モデル固有のハードウェア使用率など、観測性のためのモデル固有のメトリクスが必要です。これらのニーズを満たすために、このセッションでは、これらの要件を満たす新しいSageMaker Inferenceエンドポイントコンポーネントの立ち上げと、SageMakerのその他の性能向上機能の数々を発表できることを嬉しく思います。それでは、これらの新機能の詳細について、Alan Tanにバトンを渡したいと思います。ありがとうございました。

SageMaker Studio UIを使用したモデルデプロイのデモンストレーション

Thumbnail 1120

さて、これらの新機能について学ぶのが楽しみな方はいらっしゃいますか?素晴らしい。Dhawal、背景と顧客が直面している課題を紹介してくれてありがとう。まず、1つから数百のモデルを効率的にデプロイできる柔軟性を追加しました。これは、単一のエンドポイントに複数のモデルをパッキングすることで実現しています。この柔軟性により、ユースケースの変化に応じてエンドポイントを拡張できます。単一のエンドポイントに複数のモデルをデプロイすることで、顧客は平均して推論コストを50%削減できることがわかっています。エンドポイントにデプロイされた各モデルは、独自の自動スケーリングポリシーを持つことができます。つまり、モデルを個別にスケールできるのです。

私たちは、効果的な自動スケーリングポリシーを設定するためのデータを提供する、新しい一連のCloudWatchメトリクスとCloudWatchログを公開しました。さらに、エンドポイントにデプロイされた各モデルをゼロまでスケールダウンすることができます。これにより、他のモデルをロードするためのハードウェアを解放できます。また、特定のハードウェアリソースを異なるモデルに専用に割り当てることもできます。例えば、モデルAに2つのGPU、モデルBに1つのGPUをインスタンス上で割り当てるといった具合です。SageMakerはこの情報を使用して、高い利用率と可用性を実現するために、インスタンス上でモデルを効率的にパッキングします。さらに、より迅速にトラフィックを処理できるインスタンスやモデルのコピーにリクエストをルーティングする新しいスマートルーティングアルゴリズムも導入しました。

Thumbnail 1230

これにより、平均して20%のレイテンシ低減が実現します。これらの機能は、SageMaker互換のどのコンテナでも使用できます。AWSが公開しているコンテナでも、自分で構築したコンテナでも構いません。ただし、2つのSageMaker APIに応答することを確認する必要があります。1つはヘルスチェック用、もう1つはもちろん推論リクエストに応答するためのものです。

Thumbnail 1240

では、この新しいリリースでSageMakerのエンティティがどのように進化したかを見てみましょう。まず、エンドポイントがあります。これは、セットアップしたインフラストラクチャとモデルの抽象化に過ぎません。このエンドポイントを通じてHTTPリクエストを行い、推論結果を得ることができます。そして、エンドポイントの背後には、SageMakerが代わりに管理する一連のMLインスタンスがあり、パッチ適用、ヘルスチェック、問題が発生した場合のインスタンス置換などを行います。

Thumbnail 1270

Thumbnail 1280

Thumbnail 1290

Thumbnail 1300

これらの機能を有効にするために、Inference Componentsと呼ばれる新しいSageMakerオブジェクトを追加しました。Inference Componentは、デプロイされトラフィックを処理する準備ができたモデルの抽象化と考えることができます。Inference Componentには5つの主要な要素があります。まず、コンテナの場所です。このコンテナにはモデルサーバーがあり、推論ロジックが含まれており、モデルの重みをどのように扱うかを知っています。そして、もちろんあなたが所有するS3バケット内のモデルの重みの場所が必要です。

Thumbnail 1310

また、このモデルを実行するために必要なCPUコア数、GPU数、あるいはInferentiaやTrainiumインスタンスを使用している場合はNeuronデバイスの数、そしてCPUメモリ量を指定することもできます。さらに、先ほど言及したモデルピニングなどを行うために、このモデルの初期コピー数を指定することもできます。Inference Componentはスケーリングの単位でもあります。つまり、各Inference Componentに対して自動スケーリングポリシーを設定できます。これらは互いに大きく異なる場合があります。エンドポイントには1つ以上のInference Componentを配置でき、SageMakerがインスタンス上でそれらのInference Componentの配置を処理します。

Thumbnail 1350

Thumbnail 1360

推論コンポーネントのデプロイは非常に簡単です。3つの簡単なステップで行えます。 まず、エンドポイント設定を作成して使用したいインスタンスを選びます。次に、そのインスタンスにアクセスできるようにエンドポイントを作成します。 最後に、推論コンポーネントを作成します。これにより、モデルがエンドポイントに効果的にデプロイされ、そのモデルにトラフィックを提供できるようになります。また、デプロイされたモデルを管理するための一連のライフサイクル管理APIもリリースしました。これにより、新しいモデルの追加、既存モデルの削除、さらに新しいバージョンがある場合などにモデルを更新することができます。

オートスケーリングポリシーの設定とCloudWatchによる監視

Thumbnail 1400

Thumbnail 1410

では、自動スケーリングと配置ロジックの詳細、そしてコスト削減のために使用率を最大化する方法について、もう少し深く見ていきましょう。例として、コミック本のMLアプリケーションを考えてみましょう。 このアプリケーションは、コミック本の画像を生成し、ストーリーやセリフの作成も支援します。このアプリケーションでは2つのモデルを使用します。 1つ目はStable Diffusionモデルで、1つのA10G GPUを使用します。これはG5インスタンス上のGPUです。このモデルは、リクエスト数やトラフィック量に応じて1コピーから4コピーまでスケールするように設定します。

Thumbnail 1440

これを4つのGPUを持つ単一のエンドポイントにデプロイします。例えば、G5 12xlarge インスタンスを使用します。最小コピー数を1と設定したので、SageMakerはGPUの1つに1コピーを配置しました。 次に、Llama 2-13Bモデルもあります。これは量子化されているので、より小さなGPUに収まりますが、それでも2つのA10G GPUが必要です。ただし、他の設定は全く同じです。この場合、SageMakerはLlama 2-13BモデルをStable Diffusionモデルと同じインスタンスに配置しているのがわかります。

Thumbnail 1470

Thumbnail 1490

Thumbnail 1500

また、トラフィックの変化とスケーリングの動作を確認できるように、自動スケーリングモニターを表示しています。 アプリを使用している多くの顧客が、まずストーリーを書き始め、ナラティブを共有し始めたとしましょう。すると、Llama 2モデルへのトラフィックが増加します。この場合、SageMakerはこのインスタンスに空きGPUが1つしかないことを認識します。 そこで、実際に2つ目のインスタンスを起動してより多くのGPUにアクセスし、SageMakerはトラフィックに対応するのに十分なコピーを2つ目のインスタンスに配置します。

Thumbnail 1510

ストーリーの執筆が終わり、より多くの人々がコミック本のパネルやグラフィックの生成を始めたとしましょう。 すると、Stable Diffusionへのトラフィックが増加します。SageMakerは残りの空きスロットを使用して、Stable Diffusionの別のコピーを起動し、使用率を最大化します。SageMakerは、推論コンポーネントのスケーリングポリシー要件を満たすために必要に応じてインスタンスをスケールアップします。また、可能な限り空きスロットを埋めようとします。

Thumbnail 1540

Thumbnail 1550

Thumbnail 1560

SageMakerは、モデルがスケールダウンする場合でも、新しいハードウェアスロットが空く場合でも、全く同じことを行います。例えば、ユーザーがストーリーを書くのをやめて、Llama 2のトラフィックが減少したとしましょう。SageMakerはLlama 2モデルをスケールダウンします。これにより、既存のインスタンスで2つのGPUスロットが空きます。その後、より多くの人々がコミックブックのグラフィックを生成し続ける場合、SageMakerは残りのスロットも使用してスケールアップします。コスト最適化のため、新しいインスタンスを作成する前に、既存のスロットを再利用します。

Thumbnail 1570

Thumbnail 1600

実は、もうひとつの最適化が近々導入される予定です。例えば、深夜0時や午前3時など、誰もコミックブックのグラフィックを生成していない時間帯を考えてみましょう。トラフィックがないため、Stable Diffusionモデルをゼロまでスケールダウンすることができます。すると、2つのインスタンスが基本的に50%しか使用されていない状態になります。SageMakerはこれを検知し、コスト最適化のためにそれらを1つに統合します。つまり、50%しか使用されていない2つのインスタンスの料金を支払う代わりに、1つのインスタンスの料金だけを支払えばよいのです。

スマートルーティングとスケーリングの実演

Thumbnail 1610

デフォルトでは、SageMakerはリクエストをランダムにルーティングします。これは、モデルのレイテンシーが短く、リクエスト間で比較的一貫したレイテンシーが得られる従来のMLモデルでは上手く機能してきました。しかし、foundation modelsでは、入力に応じて推論のレイテンシーが数秒から数分まで変動する可能性があります。リクエスト間でも非常に大きな変動が見られます。ランダムルーティングでは、偶然にも短時間で処理できるリクエストが2つの長時間のリクエストの後ろに並んでしまうことがあります。これにより、クライアントにとってのエンドツーエンドのレイテンシーが長くなってしまいます。

Thumbnail 1660

この問題に対処するため、least outstanding requestsと呼ばれる新しいルーティングアルゴリズムを導入しました。これにより、トラフィックを処理する準備ができているインスタンスやモデルのコピーにリクエストがルーティングされます。その結果、リクエストの分散がより均等になります。ご覧のように、短時間で処理できるリクエストがより速く処理されるようになりました。これにより、エンドツーエンドのレイテンシーが大幅に改善されます。

Thumbnail 1690

Thumbnail 1700

今年の初めには、レスポンスをストリーミングで返す新機能もリリースしました。チャットボットのトークンなど、リアルタイムでレスポンスを送信するアプリケーションを作成できます。動画生成アプリケーションを構築している場合、動画フレームもリアルタイムでストリーミング返すことができます。この機能は、先ほどお話しした新機能とも互換性があるので、エンドポイント内の各モデルからレスポンスをストリーミングで返すことができます。

Thumbnail 1720

新しい詳細なCloudWatchメトリクスとCloudWatchログを導入し、より効果的なデバッグとモニタリングを可能にしました。CloudWatchメトリクスについては、モデルごとまたはインファレンスコンポーネントレベルでモニタリングできる新しいハードウェア使用率メトリクスを追加しました。また、予約効率メトリクスを追加し、予約されたハードウェアユニットがどれだけ使用されているかを確認できるようになりました。さらに、呼び出しメトリクスを細分化し、各モデルへのリクエスト数や、失敗・成功の数を確認できるようにしました。

同様に、CloudWatchログも細分化し、インファレンスコンポーネントやモデルに特化したログを取得できるようになりました。例えば、Llama 2インファレンスコンポーネントがライブラリを見つけられずに起動できなかった場合、それを簡単にデバッグし、その後インファレンスコンポーネントを更新することができます。

Thumbnail 1800

お話しした機能はすべて、SageMaker Python SDK、SageMaker Studio UI(後ほどデモをお見せします)でサポートされており、標準のAWS SDKやAWS CLIツールでも利用可能です。もちろん、インフラストラクチャをコードとして管理するために、これらの機能はすべてAWS CloudFormationでも利用できます。では、インタラクティブなUIを通じて、これらの新機能のデモをご覧いただきましょう。

SalesforceのEinstein 1 Platformの概要

SageMaker Studio UIの画面が表示されています。これは新しいUIなので、最近ご覧になっていない方には少し違って見えるかもしれません。例として、コード生成モデルを使用して新しいMLアプリケーションでコードを生成し、さらにその製品の使用方法を教えたり問題をトラブルシューティングしたりするチャットボットがあるとします。コスト削減のために、これら両方のモデルを1つのエンドポイントに統合したいと考えています。

Thumbnail 1860

Thumbnail 1870

すでにこれらのエンドポイントをデプロイし、アプリケーションが動作しているので、ここのモデルセクションに移動して、このアプリケーションを支えるモデルを確認できます。デプロイされたすべてのモデルが表示されます。上部には「登録済みモデル」と「デプロイ可能なモデル」の2つのタブがあります。デプロイ可能なモデルは、以前にデプロイされたモデルです。クリックすると、デプロイされたモデルのリストが表示されます。既存のアプリケーションがあるため、以前使用したモデルを検索できます。この場合、数日前にこのアプリを作成したので、その日付で検索できます。

Thumbnail 1900

Thumbnail 1910

Thumbnail 1920

ここにモデルのリストが表示されています。このデモでは、より新しいバージョンなので、最初の2つのモデルを使用します。codegenモデルとLlama 2モデルの2つを複数選択します。ここで新しいモデルを作成することもできますが、今回はこれらをデプロイするだけにします。そこで、デプロイをクリックします。すでにエンドポイント名が生成されていますが、後で見つけやすくするために、より具体的な名前に編集します。ここにデモ用のエンドポイント名を入力します。

Thumbnail 1960

また、高性能を得るために、すでに使用しているP4dインスタンスを選択します。インスタンス数は1のままにして、必要に応じてSageMakerにスケールアップさせます。これらのモデルは両方とも1つのGPUに収まるので、GPU数も1のままにします。コピー数も1のままにして、必要に応じてSageMakerにスケールアップさせます。これらのモデルはどちらもGPUバウンドなので、CPU メモリもそのままにしておきます。新しいモデルを追加したい場合はできますが、今回はこの2つにします。デプロイをクリックします。

Thumbnail 1970

Thumbnail 2010

エンドポイントが作成され、モデルがデプロイされたという成功の通知が表示されています。これには数分かかるので、時間を飛ばします。戻ってくると、エンドポイントが稼働中で、デプロイした2つのモデルも稼働中であることがわかります。このUIから直接これらのモデルをテストして、期待通りに機能しているか確認できます。ここで推論のテストをクリックします。ここにあるモデルのドロップダウンで、2つのモデルを切り替えることができます。

Thumbnail 2020

Thumbnail 2030

まずはLlama 2モデルを試してみましょう。ここにサンプル入力を貼り付けて、下部の送信リクエストをクリックします。リクエストが返ってきて、良好な結果が得られました。同じことをcodegenモデルでも試してみます。codegenモデルはコードを生成するので、Hello World関数を生成して完成させるためのプロンプトを貼り付けます。再び送信リクエストをクリックすると、Hello World関数が返ってきました。どちらも良好な結果なので、これら両方のモデルに対してオートスケーリングポリシーを設定しましょう。

Thumbnail 2050

Thumbnail 2070

モデルを読み込むために更新をクリックします。まずはLlama 2モデルの設定をしましょう。右側のオートスケーリングの編集をクリックします。ここで上部に2つのプロパティが求められています:スケールインとスケールアウトのクールダウンです。これは、次のイベントをトリガーするまでの待機時間を決定します。これはデフォルトのままにしておきます。妥当な値のようです。インスタンス数の範囲は、このモデルのコピーをいくつまでスケールさせるかを指定します。このデモではこれもそのままにしておきます。ターゲットメトリクスは、スケーリングの基準となるメトリクスです。これは、このモデルの各コピーに対するリクエスト数です。このデモで簡単にトリガーできるように、値を1にします。最後に、オートスケールの権限を持つRole ARNを選択するだけです。

codegen25モデルについても、非常によく似たことを行います。再度「edit autoscaling」をクリックし、ほとんどのデフォルト値はそのままにしておきます。ただし、invocationsを2に変更します。これは、2つのスケーリングポリシーが実際に異なることを区別できるようにするためです。これで、バックグラウンドで2つのautoscalingポリシーが設定されました。これは実際には、Application Auto Scalingを使用して実装されており、CloudWatchのアラームとメトリクスも作成されます。これらを使用して、autoscalingがいつ発生するかを監視したり、それらのモデルへのリクエスト数を監視したりすることができます。

Thumbnail 2170

ここで、バックグラウンドでダミーのリクエストを送信しています。そして、AWSコンソールを使用してCloudWatchメトリクスを実際に監視できます。AWSコンソールに素早く切り替えて、CloudWatchをクリックします。左側の「all alarms」をクリックして、すべてのアラームを確認します。推論コンポーネントごとに2つのアラームが作成されていることがわかります。1つはスケールアップ用、もう1つはスケールダウン用です。これらのアラームがトリガーされ、実際にスケールアップする時間まで早送りしましょう。ここではllama2モデルを見てみましょう。

Thumbnail 2200

Thumbnail 2220

これらのモデルが現在アラーム状態にあることがわかります。llama2モデルを見てみましょう。アラーム状態になっているということは、autoscalingポリシーが発動し、スケールアップしていることを意味します。過去5分間ほどで1を超えるリクエストがあったため、CloudWatchが「アラームだ」と言っているのがわかります。SageMaker Studioに戻って、モデルタブを開き、実際にスケールアップしたことを確認できます。llama2モデルが現在5コピーになっていることがわかります。送信したトラフィックに基づいて、1から5にスケールアップしたのです。

Thumbnail 2240

スケールダウンの様子も見てみましょう。ここで2つ目のアラーム、つまりスケールダウン用のアラームを見ることができます。同様にクリックして詳細を確認できますが、設定した通り1未満になるとスケールダウンします。トラフィックがすでに減少し始めているのがわかります。更新ボタンを押して、数時間後の確実にスケールダウンしているはずの時間まで早送りしましょう。このアラームも現在アラーム状態になっていることがわかります。つまり、モデルがスケールダウンしているはずです。SageMaker Studioに戻って再度確認すると、コピー数が1に戻っていることがわかります。1コピーから5コピーに増え、そして再び1コピーに戻るのを見ることができました。

Thumbnail 2290

これでデモを終わります。次は、SalesforceがSageMakerを使用して、高性能かつ低コストで効果的にfoundation modelsをホストする方法について、Bhaveshにお話しいただきます。

Einstein 1 PlatformのTrust層とアーキテクチャ

Alan、ご紹介ありがとうございます。こんにちは、Bhaveshです。Salesforce Einstein 1 Platformと、AWSチームと共に取り組んだGenerative AIの革新、特に基盤モデルの推論をスケールアップするための取り組みについてお話しさせていただきます。まず、このセッションにご参加いただいた皆様に感謝申し上げます。また、信頼できるAIプラットフォームを顧客に提供するこの旅に同行してくださったAWS SageMakerチームにも感謝いたします。そして、Bay Area、Seattle、Israel、Indiaにいる私のSalesforceチームにも感謝します。彼らの懸命な努力があってこそ、ここで発表する機会をいただけました。

Thumbnail 2360

Thumbnail 2380

では、本題に入りましょう。皆さんはSalesforceをご存知か、Salesforceの顧客でいらっしゃいますよね?はい、素晴らしいです。Salesforceは1999年以来、顧客が自社の顧客と全く新しい方法でつながることを支援するというミッションを掲げてきました。これがCustomer Relationship Managementソフトウェアスイートの前提です。ご存知の通り、Salesforceは市場シェアで圧倒的に1位のCRMです。私たちにとって、すべてはCustomer 360から始まります。Salesforceは、顧客とのすべてのやり取りを360度の視点で捉えた単一の情報源を提供します。これがSalesforceがもたらす大きな力です。企業が生産性を向上させるためにAIを活用しようとする中で、

Thumbnail 2430

素晴らしい顧客体験を提供するために、企業は重要な課題に直面しています。ほとんどの組織では、データが切り離された島のように散在しているため、効果的にデータを活用できません。データが正しく接続されていなければ、どれだけのAI、自動化、パーソナライゼーションを行っても機能しません。

Thumbnail 2470

そこで私たちはEinstein 1 Platformを作り出しました。これは、すべての顧客データをあらゆる顧客体験にわたって接続し、AIアプリケーションと体験の構築を可能にする1つのプラットフォームです。このプラットフォームについて詳しく見ていきましょう。私たちは、統合された、インテリジェントで、自動化された、カスタマイズが容易で、オープンな信頼できるAIのプラットフォームを提供するためにEinstein 1 Platformを構築しました。Sales、Service、Marketing、Commerceなどの主要なCRMアプリケーションだけでなく、Data Cloudもこのプラットフォームにネイティブに統合されています。

新しいメタデータフレームワークにより、切り離されたデータの島を持つのではなく、CRM外のデータでさえも1つのプラットフォームからアクセス可能になりました。これにより、すべてのアプリケーションが同じ言語で話すようになり、各顧客に対する包括的な単一の情報源が得られます。予測だけでなく生成的なユースケースにも対応したEinsteinによるネイティブAIを提供します。Data Cloudと深く統合されており、リアルタイムのデータアクセスを備えた包括的なデータレイクを提供し、これはGenerative AIのユースケースに非常に有用です。

お気に入りのアプリケーション(Slack、Tableau、Herokuなど)や、その他の一般的なアプリケーションや生産性スイートからアクセスできます。ローコードやノーコードのオプションでカスタマイズも簡単です。そのため、プラットフォームの全機能を活用しつつ、同様に統合され、自動化され、インテリジェントな独自のアプリケーションを構築できます。これはオープンなエコシステムのおかげであり、MuleSoftを使用して必要な統合を行うこともできます。

Thumbnail 2560

また、このプラットフォームでは、業務の流れの中で各クラウドにGenerative AIのユースケースをもたらしています。これは主要な運用上の課題や機会に対応するものです。例えば、Sales GPTは見込み客へのメールを自動化し、営業担当者が顧客との時間をより多く取れるようにします。Service GPTはサービス対応、ケースの要約、ナレッジ記事を自動化します。マーケティングではセグメント生成とキャンペーン作成に焦点を当てています。Commerce GPTは、動的な商品説明と、パーソナライズされた商品発見のためのコンシェルジュサービスに重点を置いています。

同様に、Developer GPTは自然言語を使用してコードを作成し、チャットベースの支援やコーディングの自動補完を行います。これらのEinstein GPTアプリケーションはすべて、各クラウドのワークフローでGenerative AIを使用しています。私たちは、ビジネスに最も大きな影響を与え、価値を引き出すところにAIをもたらしています。その一例を見てみましょう。画面の右側に、コパイロットの体験が表示されています。ここでは自然言語で質問できます。この場合、ケースの要約を求めると、次のアクションを決定するのに役立つ完全な要約が提供されます。

Thumbnail 2660

次に、Einstein 1 PlatformのTrust層とアーキテクチャを見てみましょう。これはHyperforceパブリッククラウドインフラストラクチャ上で提供され、コンプライアンス要件を満たしながら、すべてのデータとAIサービスを安全にデプロイおしてスケールすることができます。オープンモデルエコシステムを備えており、APIを介してSalesforce外部でホストされている基盤モデルへの安全なアクセスを提供します。また、独自の基盤モデルを持ち込んで、Generative AIへの投資を再利用し、自社のインフラでそれらのモデルを実行することもできます。

また、基盤モデルをホスティングする機能も提供しています。プライベートモデルが必要な場合は、これらの基盤モデルの一部を微調整することもできます。Einstein Trust層には、セキュアなデータ、動的検索、データグラウンディング、有害性検出、マスキング、ゼロリテンション、監査などの機能が含まれており、プラットフォーム全体でAIの責任ある使用を確保します。Salesforceにとって信頼が最優先事項であるため、このTrust層は、自社のCRMのデータを使用してこれらのAIモデルをグラウンディングできるようにするセキュリティガードレールを提供しますが、ゼロデータリテンションなどの制御によってデータのセキュリティとプライバシーを保護します。

SalesforceとAmazon SageMakerの連携:Foundation Modelsの推論スケーリング

数百の基盤モデルの推論をスケールアップするために、私たちはAmazon SageMakerチームと広範に提携してきました。これらのモデルを自社のVPCではなく、Hyperforce上でテナントごとに実行できるようにしています。このアプローチにより、データのセキュリティとプライバシーの最高基準を維持しながら、堅牢なAI機能を提供することが可能になります。

また、データマスキングを使用してこれらのモデルがプライベートなPIIデータを見ることがないようにし、有害性検出と監査証跡を通じてより良い出力を確保しています。SalesforceにおけるAIは、新しいEinstein Copilot Studioなどのローコードビルダーを通じてカスタマイズ可能です。これは先ほどデモンストレーションしたEinstein Copilotの設定レイヤーであり、質問をしたりアクションを取ったりすることで時間を節約することができます。

Thumbnail 2790

Amazon SageMakerとの関係は、これらのGenerative AIのユースケースにとどまりません。予測的および生成的ユースケース、さらにマルチテナントの推論とトレーニングについても提携してきました。SageMakerと協力して、Data Cloud内のデータをデータコピーなしでSageMakerで利用できるようにしました。また、高速トランスフォーマーダイナミックバッチングなどのイノベーションを含む Large Model Inference コンテナでのモデル推論の最適化にも取り組んでいます。

Thumbnail 2830

Thumbnail 2840

これらは、Salesforceで開発したり、現在SageMaker JumpStartを通じて使用している基盤モデルの一部です。この例では、そのうちの2つに焦点を当てます。 約75 GBのGPUメモリを必要とし、現在高いトラフィックがあるCodeGen-16Bモデルと、55 GBのGPUメモリを必要とし、現在はトラフィックが少ないものの、スケールアップが予想されるTextGen-13Bモデルです。

Thumbnail 2860

現在の展開戦略はこのようになっています:SageMaker Single Model Endpointsを使用しています。これらのモデルはどちらも2つのGPUを必要とします。トラフィックが多いCodeGenモデルを2つ、TextGenモデルを1つ展開しています。どちらもP4dインスタンス上に展開されています。Single Model Endpointなので、2つのP4dインスタンスが必要です。このような展開は皆さんにも馴染みがあるでしょうか?ご覧のように、非常に高価で大幅に使用率が低い2つのP4dインスタンスを使用しなければなりません。

Thumbnail 2920

さて、これをスケールアップすることを考えてみましょう。トラフィックだけでなく、モデルの数も増やすとなると、運用上の悪夢です。非常に難しく、リソースの利用効率が悪いため、依然としてコストがかかります。小規模で同質なモデルには適している Multi-Model Endpoints を検討しましたが、 これらの大規模な基盤モデルの場合、メモリにロードする必要があるため、SageMaker Inference Component Endpoint が私たちにとって最適なソリューションでした。

Thumbnail 2930

SageMaker Inference Component Endpoint を使用することで、両方のモデルを同じインスタンスにデプロイすることができました。ピンク色のモデルA(CodeGen)のコピー1とコピー2、そして青色のTextGenモデルが見えますね。これにより、パフォーマンスに影響を与えることなく、P4dインスタンスをより効率的に利用できるようになりました。Single Model Endpoints での従来のトラフィック処理と、Inference Component Engine を使用した新しい方法を並行して比較しましたが、スマートルーティング機能のおかげで、パフォーマンスの低下は見られませんでした。

Thumbnail 2990

モデルがスケールアップするにつれて、どのような状況になるでしょうか?当初、Single Model Endpoints でスケールアップする場合、インスタンスを追加する必要がありました。 トラフィックが3倍になった場合、CodeGenモデル用にもう1つ、TextGenモデル用にもう1つのインスタンスを追加する必要があり、合計4つのインスタンスが必要になります。しかし、Inference Component Endpoint を使用すると、トラフィックが増加しても、リソースをより効率的に利用できます。

Thumbnail 3010

同じスループットを得るのに必要なのは、P4dインスタンス3つだけです。繰り返しになりますが、リソースの利用効率が向上し、インスタンス数が減少するため、結果的にコストが削減されます。

Thumbnail 3030

では、私たちが得た教訓は何でしょうか?Inference Component Endpoints を使用したスケーリングでは、管理すべきエンドポイントが1つで済むため、特に数百のモデルにスケールアップする必要がある場合に非常に便利です。ハードウェアリソースの利用効率が大幅に向上します。重要なポイントは、各モデルを独立してスケールできることと、Auto-scaling 機能がこれらのリソース管理に非常に役立つことでした。Alanが言及したScale to Zero機能は、特に本番環境以外で非常に有用でした。テストやパフォーマンス環境では、テスト実行のために一定期間スケールアップし、終了後すぐにスケールダウンすることができました。これは、Single Model Endpoints や他のソリューションでは不可能なことです。

Thumbnail 3090

コスト削減は、先ほどお示ししたように、スケールアップするにつれて増加し、パフォーマンスも同等でした。では、主な学びは何でしょうか?まず最初に行うべきは、同じハードウェアを使用する基盤モデルを特定し、それらを単一のエンドポイントでホストすることです。推論コンポーネントを使用すると、多くの手間が省け、パフォーマンスに影響を与えることなくコンピュート・フットプリントを削減できます。自動スケーリング機能は非常にうまく機能しました。入ってくるトラフィックに基づいて、モデルの使用量を上下にスケールすることができました。

Thumbnail 3150

Alanが言及したスマートルーティング機能は、パフォーマンスの同等性を得るのに非常に役立ちました。特にCodeGenモデルでは、ファーストバイトレイテンシーが重要でした。これはほとんどのユースケースに当てはまるので、レスポンスストリーミングを使用してください。最後に、大規模モデル推論コンテナは、基盤モデルの推論を行う上で、他のコンテナと比べて非常に有用でした。これらが私たちの主な学びです。

Large Model Inferenceコンテナの新機能と最適化

では、Dhawalに戻します。Bhavesh、素晴らしい事例をありがとうございました。ここからは、最近導入したいくつかの機能について詳しく説明します。2日前、大規模モデル推論コンテナに新機能をリリースしましたので、簡単に説明したいと思います。SageMakerでの基盤モデルのホスティングに関しては、すでにDeepSpeedをサポートしている大規模モデル推論コンテナがあります。これはHugging FaceやAccelerateなど、他のモデル並列アプローチもサポートしています。そして今回、TensorRT-LLMのサポートも追加されました。

また、all reduceのための追加の最適化技術も導入しました。これにより、モデル並列分散推論のためのNVIDIA GPU間の内部通信が最適化されます。これらの機能を使用することで、以前のバージョンの大規模モデル推論コンテナと比較して、平均で20%低いレイテンシーを実現できるようになりました。したがって、テキストや大規模言語モデル、Stable Diffusionタイプのモデル、あるいはテキストから画像や画像からテキストへの変換モデルなど、どのタイプの基盤モデルでも、SageMakerの大規模モデル推論コンテナを使用してください。

Thumbnail 3290

また、Stable Diffusionバックエンドのサポートもあります。さらに、Flan-T5やT5ファミリーの基盤モデルをホストするためのFasterTransformerなど、他の最適化エンジンもサポートしています。この単一モデル、単一推論コンテナを使用して、さまざまな基盤モデルを大規模にホストできます。異なるタイプのモデルやエンコーダーアーキテクチャ、デコーダーアーキテクチャに対して異なるコンテナを使い続ける必要はありません。これは統一された単一の大規模モデル推論コンテナであり、標準化してコスト効率と高性能を実現できます。

Thumbnail 3300

さて、これらを踏まえて、foundation modelsの推論性能を向上させるためのリファレンスと、2日前に大規模モデル推論コンテナで発表した新機能をいくつかご紹介します。詳細な情報はこちらでご覧いただけます。QRコードをスキャンしていただければ、リソースに直接アクセスできます。

セッションの締めくくりと質疑応答の案内

以上で終わりですが、このセッションに関するフィードバックをいただけると大変嬉しく思います。アプリでAIM 327を選択し、ぜひフィードバックをお寄せください。Bhavesh、ありがとうございました。Alan、ありがとうございました。そして、皆様、ご参加いただき誠にありがとうございました。ここでしばらく待機していますので、ご質問がある方はどうぞお気軽にお声がけください。喜んでお答えいたします。本当にありがとうございました。


※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。

Discussion