re:Invent 2024: AWSがGenerative AI向けデータ基盤構築を解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Build a data foundation to fuel generative AI (STG201)
この動画では、Generative AIアプリケーション構築のためのデータ基盤について、Amazon S3のシニアマネージャーとAmazon FSxのプリンシパルプロダクトマネージャーが解説しています。Foundation Modelの活用方法として、RAG、Fine-tuning、Continued Pre-trainingなどの手法を比較し、それぞれのデータ要件を説明します。また、PinterestやBooking.com、LG AI Researchなどの具体的な事例を交えながら、Amazon S3やAmazon FSx for Lustreなどのストレージサービスの選び方や、データの準備、ガバナンス、パフォーマンス最適化について詳しく解説しています。特にAmazon FSx for LustreではGPUDirect Storageのサポートにより、150ギガバイト/秒という高スループットを実現できる点が注目です。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Generative AIの基礎：データの重要性と本セッションの概要
すごい人数ですね。身が引き締まる思いです。皆様、この忙しいre:Inventの週の中で、私たちと1時間を共に過ごすことを選んでいただき、ありがとうございます。新しい学びを得ていただければと思います。本セッション「build a data foundation to fuel generative AI」へようこそ。私はBijeta Chakrabortyと申します。Amazon S3のシニアマネージャーを務めております。本日は、Amazon FSxのプリンシパルプロダクトマネージャーであるJordan Dolmanと共にお話しさせていただきます。
ご存知の通り、Generative AIは今や事実上あらゆる業界を変革しています。テキスト、音声、動画など、新しいコンテンツを生成する能力は日々向上しています。例えば、ヘルスケア分野のお客様は患者記録を分析して個別化された治療計画を生成されていますし、自動車業界のお客様は新しいコンセプトを生成することで、エンジニアリングとデザインの革新を進めています。私たちが確信しているのは、データがGenerative AIの核心であるということです。データこそが、皆様のアプリケーションを差別化し、組織のイノベーションを加速させる要素なのです。
本日のセッションでは、お客様がどのようにGenerative AIの構築に向けて準備を進めているのかをご紹介させていただきます。お客様から最もよくいただく質問は、Foundation Modelsについてどのように考えるべきか、どのようなデータに関する考慮事項に注意を払うべきか、そしてこれらすべてをサポートするためにどのようなストレージインフラが必要なのか、というものです。
Foundation Modelsの活用方法：RAGからFine-tuningまで
まずはFoundation Modelsについてお話ししましょう。非常に大まかに言うと、できることは2つあります。1つは既存のFoundation Modelを再利用すること、もう1つは新しいモデルを訓練することです。既存のFoundation Modelを再利用する場合にはいくつかのアプローチがありますが、最初に最もシンプルなアプローチであるRetrieval Augmented Generation（RAG）についてお話ししたいと思います。RAGでは、モデルを再訓練することなく、組織のデータを使用してモデルの出力をカスタマイズすることができます。
RAGの仕組みを分解してご説明しましょう。最初のステップとして、Foundation Modelの構造化に使用したい組織のデータで情報ライブラリを作成します。このライブラリを作成した後、ユーザーがクエリを投げかけると、このライブラリを使ってFoundation Modelの出力を構造化します。この一連のプロセスは「プロンプティング」と呼ばれます。実際、プロンプトとは、モデルがより適切で関連性の高い応答を提供できるよう導くために使用される、キュレーションされたテキストや指示のセットなのです。
AWSでは、RAGワークフローを構築するために必要なツールがすべて揃っています。例えば、Amazon Bedrockを使用すると、Amazon S3バケットやその他のデータソースにある組織のデータを使用してナレッジベースを作成できます。また、Amazon BedrockではAmazonのTitanやAnthropic Claudeなど、様々なFoundation Modelにアクセスすることができます。こちらが、RAGを組織内で活用している顧客の一例です。
Pinterestについてはみなさんもご存知かと思います。Pinterestはビジュアルインスピレーションプラットフォームで、S3上に1エクサバイトに迫る、最大級のデータレイクを保有しています。Pinterestの目標は、Large Language Modelと、S3に保存された既存のデータを活用して、分析業務の生産性を向上させることでした。データエンジニアは日々、様々な質問に答える必要があります。Pinterestは、これらのテキストベースの質問をSQLクエリに変換したいと考えていました。そこで、Large Language ModelとS3の既存データを用いたRAGワークフローの助けを借りて、テキストベースの質問をSQLクエリに変換できるクエリツールを構築しました。このクエリツールにより、データエンジニアの生産性は約40%向上しました。
このスライドに戻って、既存のFoundation Modelを再利用する別のアプローチについてお話ししましょう。それは、Fine-tuningです。RAGよりも少し複雑です。Fine-tuningでは、事前学習プロセスでカバーされていなかった特殊なタスクを実行できるようにモデルを適応させます。これにより、学習時間が短縮され、モデルの精度が向上し、カスタマイズが可能になります。Fine-tuningでは、企業固有のドメイン特化データを使用して、特殊なタスクを実行できるようにモデルを適応またはカスタマイズします。これは、モデルの専門知識を拡張する必要がある場合にのみ行います。例えば、医療診断モデルを開発する場合、厳選された医療記録データセットで既存のFoundation Modelをファインチューニングすることで、適切で正確な応答を得ることができます。
ご想像の通り、Amazon Web Servicesには、Fine-tuningに必要なツールがすべて揃っています。例えば、Amazon BedrockやAmazon SageMaker Canvasがあります。Fine-tuningには、高品質でラベル付けされたデータへのアクセスが必要です。また、モデルへのアクセスも必要で、SageMakerでは学習率やバッチサイズなどのモデルのハイパーパラメータを実験的に調整することができます。これにより、特定のデータや目的の成果に合わせてFine-tuningプロセスをカスタマイズすることができます。
こちらが、Fine-tuningを活用している顧客の例です。12月という時期にぴったりの、私の個人的なお気に入りの事例、Booking.comをご紹介します。 Booking.comは、会話的な方法でカスタマーに個別化されたレコメンデーションを提供するAIトリッププランナーの構築を目指していました。しかし、これらのレコメンデーションを生成する際に、レイテンシー、データ、インフラストラクチャに関する様々な課題に直面しました。Booking.comには、長年にわたる予約レビューと顧客レビューという最も価値のあるデータセットがあります。このレビューデータセットの上にRAGワークフローを構築し、高度にパーソナライズされた旅行レコメンデーションを生成できるようにしました。さらに、既存のFoundation ModelであるLlama 2をFine-tuningして、70億パラメータを持つインテント検出モデルを作成しました。このインテント検出モデルと、予約レビューに対する拡張RAGを組み合わせることで、会話的な方法でカスタマーに高度にパーソナライズされたレコメンデーションを提供するAIトリッププランナーを作成することができました。
独自モデルのトレーニング：Continued Pre-trainingと新規モデル構築
スライドに戻って最後に説明したいのは、Continued Pre-trainingと新しいモデルのトレーニングについてです。これら2つのアプローチを検討されているということは、おそらくRAGやFine-tuningで望む結果が得られなかったのでしょう。Continued Pre-trainingでは、モデルプロバイダーが終えた地点から再開し、企業のデータを使って専門知識だけでなく、モデルの一般的な知識も拡張していきます。新しいモデルのトレーニングは、その名の通り、モデルを一から構築することです。これは、必要とするモデルがまだ存在しない場合にのみ行うべきアプローチです。
Continued Pre-trainingと新しいモデルのトレーニングは、どちらも非常にリソースを必要とし、専門的なスキルが求められます。しかし、モデルの精度と関連性は、先ほどの2つの手法であるRAGとFine-tuningよりもはるかに優れています。特に新しいFoundation Modelをトレーニングする場合は、大規模なデータセット、専門的なスキル、そして専門的なインフラストラクチャーへのアクセスが必要です。AWSでは、Amazon SageMakerやGPUインスタンスへのアクセスが可能です。また、Amazon S3に加えて、Amazon FSx for Lusterのような専門的なストレージサービスも利用できます。
ここで、独自のモデルをトレーニングした顧客の例をご紹介します。LG AI Researchは、LGの研究拠点です。彼らは人間の脳を模倣し、高度な学習能力と優れた判断力を持つFoundation Modelの作成を目指していました。そのようなモデルがまだ存在しなかったため、独自のモデルを作ることを決めました。Amazon SageMakerとAmazon FSx for Lusterを使用して1年以内に、ExaoneというFoundation Modelを作成することができました。Exaoneは3,000億のパラメータを持つマルチモーダルモデルで、画像とテキストの両方のデータでトレーニングされています。人間のように考え、学習し、自律的に行動することができます。当初、LG AI Researchはオンプレミスでの構築も検討していましたが、コストなどの課題があり、最終的にAmazon SageMakerが彼らのプロジェクトに最適だと判断しました。アーキテクチャ図からわかるように、Amazon S3バケットからGPUインスタンスにデータを読み込むためにAmazon FSx for Lusterを使用しています。これらのGPUインスタンスでトレーニングを行う際、チェックポイントとモデルのアーティファクトが生成され、それらを右上の別のAmazon S3バケットにアーカイブしています。
Generative AIのためのデータ戦略：発見から準備まで
既存のFoundation Modelの使用や再利用、そして新しいモデルのトレーニングについて、いくつかの方法を見てきました。ここで、これらすべてのアプローチで考慮すべきデータに関する考慮事項について簡単に説明しましょう。具体的には、データディスカバリー、データ準備、データガバナンスについて説明します。
まず、データディスカバリーのプロセスでは、データソースとデータフォーマットを特定する必要があります。最初にデータソースから見ていきましょう。
Generative AIアプリケーションについて考える際、様々なデータソースが存在します。社内のWiki、社内文書、サポートログ、チケット情報といった内部データソースに加えて、パブリックデータセットの活用も検討に値します。これらのパブリックデータセットには、多くのお客様が新しいモデルのトレーニングに使用しているCommon Crawlデータベースのような学術データやWebクロールデータが含まれます。また、Shutterstockや金融関連ではBloombergのようなライセンスコンテンツプロバイダーからデータを購入することも選択肢の一つです。
データソースを検討した後は、実際に扱うデータフォーマットについて考える必要があります。私たちは様々なデータフォーマットを目にしますが、これらのフォーマットは使用する基盤モデルや目指す成果によって異なってきます。Amazon S3では、特にParquetファイルのような構造化データを多く見かけます。実際、Parquetは優れたクエリパフォーマンスにより、S3で最も急速に成長しているデータフォーマットの一つです。また、音声、テキスト、画像、PDFなどの非構造化データフォーマットも、Generative AIワークロードの大部分を占めています。
データソースとデータフォーマットを検討した後は、これらすべてのデータをAmazon S3データレイクに統合していきます。最初に考慮すべき点は、データをバッチで読み込むか、リアルタイムで読み込むかということです。例えば、履歴レコードや製品ドキュメントのように、データの変更頻度が低い場合は、バッチモードでのデータ読み込みが適しています。また、データのトークン化やベクトルデータベースへの埋め込みの作成など、大規模な前処理が必要な場合も、バッチ処理での読み込みを検討する必要があります。
AWSでは、S3にバッチでデータを読み込むための様々なオプションを提供しています。例えば、AWS CLI/SDK、AWSとの間でファイルを移動するためのAWS Transfer Family、オンプレミスからS3にデータを移動するためのAWS DataSync、さらには異なるソースからデータを自動的に発見してカタログ化し、S3に読み込むAWS Glue Crawlersなどがあります。もう一つのオプションは、リアルタイムでのデータ読み込みです。ライブカスタマーサポートやソーシャルメディアなど、頻繁に変更されるデータの場合は、リアルタイムでのデータ読み込みが望ましいでしょう。Amazon Kinesisファミリーのサービスは、リアルタイムでデータを収集、分析、処理し、Amazon S3バケットに読み込むことができるため、リアルタイムデータの取り扱いに最適です。全般的に見て、RAGワークフローでは、実装がシンプルでコスト効率が良いため、バッチでのデータ読み込みが好まれる傾向にあります。
さて、すべてのデータをAmazon S3バケットに取り込んだ後は、どうすればよいでしょうか？次のステップは、このデータを充実させるための関連メタデータを追加することです。これには様々な方法があります。例えば、RAGワークフローでは、タイトル、要約、カテゴリーなどの説明的なメタデータが検索型ワークフローに非常に効果的です。一方、Fine-tuningや事前学習では、より広範なアノテーションが必要となります。例えば、お客様は指示-応答形式や質問-回答形式、感情分析形式などを使用します。これらの形式を使用することで、特定の文章の解釈方法だけでなく、同様の文章の解釈方法もモデルに教えることができるためです。多くのお客様が、このようなデータの分類とラベリングにLarge Language ModelsやAmazon SageMakerを活用しています。
データ準備の実践：テキストデータの処理からVector Embeddingsまで
さて、データにメタデータを追加しましたが、これをどのように保存すればよいのでしょうか？AWSには複数の選択肢があります。まず、Amazon S3にはObject Tagsという機能があり、これを使ってS3のデータにユーザー定義のメタデータを追加することができます。お客様の中には、このメタデータをAmazon S3バケット内のデータと一緒に保存する方もいます。また、多くのお客様は、DynamoDBテーブルやRedshiftテーブル、あるいはより優れたクエリパフォーマンスを実現するIcebergテーブルなど、独自のメタデータストアを選択しています。
Amazon S3バケットに保存されているデータは、そのままではFoundation Modelで利用できない可能性があります。バックグラウンドでデータの準備が必要になります。データの準備方法は、S3バケット内のデータフォーマットによって大きく異なります。ここでは、テキストデータの場合のデータ準備プロセスの例を見ていきましょう。
左側から始めると、まずデータソースを特定します。新しいデータを取り込むか、Amazon S3の既存のData Lakeから始めるかのどちらかです。これらの大規模なデータセットやドキュメントを、コンピュータが扱いやすい小さなテキストチャンクやトークンに分割します。次に、これらのテキストチャンクを、コンピュータが理解しやすい一連の数値（Embeddings）に変換します。これらのEmbeddingsを、Amazon OpenSearch Serviceなどのベクトルデータベースやベクトルストアに保存します。これらのベクトルデータベースは類似性検索に非常に効率的で、このような検索ワークフロー向けに特別な索引システムを備えています。
テキストを小さなテキストチャンク（トークン化と呼ばれる）に分割する話をしました。トークンの目的は、コンピュータが素早く処理できる程度に小さく、かつ文脈や意味を保持できる程度に大きいサイズにすることです。ここでは、株主向けレターを小さなテキストチャンクやトークンに分割する例を示しています。トークンは必ずしも単語と一致するわけではありません。フレーズが1つのトークンになることもあれば、1つの単語が複数のトークンに分かれることもあります。目安として、750単語で約1,000トークンになりますが、使用するモデルによって異なる場合があります。
データ準備プロセスで触れたVector Embeddingsについても説明しましょう。Embeddingとは、テキスト、単語、フレーズを高次元空間における一連の数値で表現したものです。テキストの意味だけでなく、2つのテキスト間の関係性も表現します。例を見てみましょう。ここには映画のデータベースがあります。宇宙に関連する3つの映画、「Inception」「Space Odyssey」「Apollo 13」を取り上げてみました。それぞれの映画にタイトル、公開年、ジャンル、監督、簡単なあらすじなど、いくつかの要素で注釈を付けていきます。「Inception」の場合、「2010年公開のSFアクション映画、監督はChristopher Nolan、他人の夢に入って秘密を盗み出す特殊な能力を持つ泥棒の物語」となります。
そこから、Embedding Modelを選択して、Embeddingsと呼ばれる一連の数値を生成します。この演習では、これらの数値が先ほど取り上げたテキストを表現していると仮定します。これらのEmbeddingsを作成したら、Amazon OpenSearch Serviceのようなベクトルデータベースに保存します。ユーザーが「宇宙と夢に関する映画をおすすめしてください」といった質問をLarge Language Modelにすると、そのユーザーの質問がEmbeddingsに変換されます。アプリケーションはバックエンドで、このユーザーの質問に最も近いEmbeddingを探し、そのテキストを取得し、宇宙と夢に関する映画であるInceptionをおすすめするというわけです。
これらの異なるプロセスは、試してみようとする人にとって面倒に感じるかもしれませんが、Amazon Bedrock Knowledge Basesを使えばその必要はありません。すべてが完全にマネージドされているのです。Amazon Bedrock Knowledge Basesを使用すると、Foundation ModelsをAmazon S3などの独自のデータソースに安全に接続でき、適切な情報でPromptを補完してFoundation Modelsの出力を構造化し、導くことができます。
Generative AIにおけるデータガバナンスの重要性
データガバナンスについて話しましょう。Generative AIアプリケーションに関して、データペリメーターをどのように考えるべきでしょうか？この会場にいらっしゃる皆さんのほとんどは、データペリメーターという概念をすでにご存知だと思います。データペリメーターとは、信頼できるIDが期待されるネットワーク内の信頼できるリソースにアクセスすることを確実にするための、一連のガードレールと権限のことです。ビジネスクリティカルなアプリケーションで行っているこれらすべてのことを、入力にも拡張する必要があります。
トレーニングデータ、モデルの成果物のログ、チェックポイントなど、Generative AIワークロードの入力と出力にもデータペリメーターを拡張する必要があります。これは、お客様がインターネットの公開データセットを使用したり、ライセンスされたコンテンツジェネレーターからデータを購入したりする場合に特に重要です。多くの場合、お客様はこのデータをコンテンツジェネレーターのS3バケットから、モデルのトレーニングに送信する前に、信頼できるネットワーク内の自身のS3バケットにコピーします。もう1つの考慮事項は、コンテンツジェネレーターとの契約条件に基づくデータの有効期限です。バケットにライフサイクル有効期限ポリシーを設定するだけで、希望するタイミングでデータを確実に期限切れにすることができます。
このデータペリメーターを設定したら、このデータを徹底的に監査できるようにする必要があります。Amazon BedrockはAWS CloudTrailとよく統合されており、この統合により、モデルがいつ呼び出されたか、どのIPアドレスから呼び出されたかなどの詳細を確認することができます。CloudTrailはデータイベントと管理イベントの両方を提供します。データイベントでは基礎となるデータにアクセスした人を確認でき、管理イベントではモデルを呼び出した人とデータの取得が行われた時期を確認できます。Knowledge Basesの独自データソースとしてAmazon S3を使用している場合、常に比類のない詳細な監査、コンプライアンス、セキュリティ機能を利用できます。
Generative AIのためのストレージインフラ：Amazon S3とAmazon FSx for Lustreの活用
まとめますと、Foundation Modelを再利用する様々なアプローチや、新しいモデルをトレーニングする方法について説明しました。 また、データの発見、データの準備、データガバナンスなど、データに関する様々な考慮事項について議論しました。これらすべてを理解していただくために、RAGのクイックデモをご覧いただきましょう。
このデモでは、re:Inventのセッションを推奨するAIアシスタントを作成します。私は特にネットワーキングのトピックに興味を持つIT管理者という役割を演じています。ご覧いただくのは、2つのシンプルなCSVファイルの作成です。1つ目のファイルには、すべてのre:Inventのトピック、残席数、開催日が含まれています。2つ目のCSVファイルには、re:Inventに参加する人々の役割と、彼らが興味を持つトピックが記載されています。これらをAmazon S3バケットにロードし、Bedrockのナレッジベースと連携させ、トークン化を行い、エンベディングを確認し、最後にAmazon BedrockとAmazon S3をClaudeという大規模言語モデルと組み合わせてこのナレッジベースをテストし、最も適切なre:Inventセッションを推奨できるかどうかを確認します。
こちらが先ほど説明したCSVファイルで、re:Inventセッション、残席数、開催日が記載されています。今回は5つのセッションを選びました。もう1つは、参加者の役割と興味のあるトピック、つまりIT管理者とネットワーキングが記載されているものです。これらをAmazon S3バケットにロードします。 では、Amazon Bedrockに移動し、ナレッジベースを作成します。ここでいくつかの異なるデータソースをお見せしたいと思います。Amazon S3を選択し、先ほど2つのCSVファイルを作成したバケットのARNを指定します。
チャンキングとパースの設定にはいくつかのオプションがありますが、非常にシンプルに保つため、ほぼすべてデフォルトの設定を使用します。 次に進み、エンベディングモデルの選択では、Cohereが提供するEmbed Englishを使用します。 ベクトルDBについては、いくつかの選択肢があります。新規作成か既存のものを再利用するかを選べますが、私は持っていないので新規作成を選びます。 次へ進み、設定した内容を確認し、ナレッジベースを作成します。 この処理には通常数分かかるので、最後までスキップしましょう。
数分後、ナレッジベースが作成されました。 次にテストを行います。まず、モデルを選択します - Anthropic Lightを選びましょう。 ここで興味深いのは、Claudeにシステムプロンプトを与え、残席数が0より多いre:Inventセッションを推奨するAIアシスタントであることを伝えます。また、私がIT管理者であり、興味のあるトピックを指定します。
システムプロンプトをClaudeに与え、Amazon S3のデータをナレッジベースとして接続しました。これらのインプットを使って、Claudeにre:Inventのセッションを推薦してもらうテストをしてみましょう。 先ほど作成したナレッジベースから情報を取得しているところです。利用可能なセッションと残席数に基づいて、12月4日に開催される「Design Well-Architected Networks on AWS」への参加を推奨してくれました。このセッションにはまだ15席の空きがあります。さらに、残席数順にいくつかの推奨セッションも提示してくれています。このシンプルな例は、Amazon BedockのナレッジベースとAmazon S3の既存データを簡単に連携できることを示しています。
それでは、Generative AIのストレージインフラに関する考慮事項について、Jordanに説明してもらいましょう。 大まかに言うと、ストレージとの連携方法にはブロック、オブジェクト、ファイルという3つのインターフェースがあり、Amazonのストレージポートフォリオにはそれぞれに対応するサービスがあります。Amazon EBSは弊社のElastic Block Storageで、Generative AIの文脈では主にGPUインスタンスのブートボリュームとして使用されます。Amazon S3は非構造化データ向けの大規模なオブジェクトストレージで、本セッションの主なテーマでした。また、階層的なデータ構造やファイルロック機能、使い慣れたツールやサービスとの統合が必要な場合に利用される、いくつかのファイルシステムも提供しています。
ファイルシステムのポートフォリオには、主にAmazon FSxとAmazon EFSという2つのサービスファミリーがあります。Amazon FSxには、ハイパフォーマンスコンピューティングやAI/MLワークロード向けに特別に設計されたAmazon FSx for Lustreがあります。また、開発ツールやアプリケーションのホスティングなど、Generative AI領域で活用されるOpenZFSやNetApp ONTAPもあります。Amazon EFSは完全サーバーレスな弊社のElastic File System製品で、Generative AIの文脈では、ユーザー共有やインファレンスワークロードに使用されているのをよく見かけます。このセッションの残りの部分では、Generative AIアプリケーションのトレーニングやサポートで主に使用されるAmazon S3とAmazon FSx for Lustreに焦点を当てて説明していきます。
さて、 先ほど説明したデータアクセスオプション（ブロック、オブジェクト、ファイル）は、ストレージサービスの選択に大きな影響を与えます。しかし、特定のアプリケーションに対してどのストレージサービスを使用するかには、他の要因も影響します。データセットのサイズは、ストレージサービスに必要な容量に影響を与えます。また、そのストレージサービスとの間でどれだけ速くデータを移動する必要があるか、つまりスループット容量にも影響します。実際のファイルやIOリクエストのサイズも、どのストレージサービスがワークロードに最適かを決める要因となります。これは、小さなファイルを扱う場合、そのファイルの取得時間はレイテンシープロファイルに大きく依存するためです。
これから先のスライドでストレージサービスのレイテンシープロファイルについて説明していきます。また、ワークロードのアクセスパターンも、特定のアプリケーションに使用するストレージサービスの選択に影響を与えます。これには、1秒あたりのIO数やトランザクション数が含まれ、これらは実行するワークロードの種類や、ストレージサービスにデータを要求する同時GPUまたはユーザー数によって決まります。これら3つの要因 - データセットのサイズ、ファイルサイズ、アクセスパターン - が組み合わさって、ワークロードに必要なパフォーマンスプロファイルが形成されます。
Generative AIのワークロードにおいて、パフォーマンスは特に重要です。なぜなら、トレーニングであれインファレンスであれ、多くのワークロードがコンピューティングリソースのスケーリング能力に依存しているからです。いずれの場合も、コンピューティングのスケールに応じてデータアクセス能力も同様にスケールすることが重要です。もしそうでなければ、ストレージがボトルネックとなり、GPUリソースが十分に活用されなくなってしまいます。その結果、ワークロードの完了に時間がかかり、最終的に必要以上のコストがかかることになります。
ここで、RAG、Fine-tuning、そして既存のモデルをベースにした継続的な事前学習といった、さまざまなGenerative AIアプローチにおけるストレージの役割に焦点を当ててみましょう。私たちが発見したのは、これらのお客様グループが実はストレージを同じ視点で見ているということです。つまり、同じようなストレージ要件を持っているのです。具体的には、既存のFoundation Modelを使用しているお客様は、ホットデータとコールドデータの両方に対してコスト効率の良いデータ保存場所を提供し、高性能なデータ取得・処理能力を備え、AIやMLワークフローと深く統合されたストレージを求めています。
ご覧の通り、コスト効率の良いストレージという観点では、Amazon S3が多くの基準を十分に満たしています。Amazon S3をご利用になった方や、この会議に以前参加された方はご存知かもしれませんが、S3にはさまざまなストレージクラスがあり、それぞれが異なるパフォーマンスプロファイルに対してコスト最適化されています。Amazon S3 Express One ZoneはAWSで最も低レイテンシーのオブジェクトストレージとして最適化されています。S3 StandardからGlacier Deep Archiveまでの他のストレージクラスは、異なるワークロードパターンに対して、数十ミリ秒から数分、数時間のアクセス時間を提供します。S3 Intelligent Tieringを使用すると、S3 StandardからGlacier Deep Archiveまでのスペクトル全体にわたってデータを効率的に保存できます。
Generative AIのコンテキストでは、既存のFoundation Modelを使用してワークロードを構築する際に、データの階層化が特に重要であることがわかりました。RAGベースのワークロードでは、既存のFoundation Modelが大量のデータにアクセスできるようにする必要があります。先ほどのデモでご覧いただいたように、モデルはナレッジベースにアクセスし、プロンプトに対する応答の一部として関連コンテンツを取り出すことができました。この場合、ストレージサービスからの応答を迅速に返す必要があるため、10ミリ秒のアクセスを提供するS3 Standard、S3 Standard-IA、Glacier Instant Retrievalは、RAGベースのワークロードに適したストレージクラスとなります。
Fine-tuningや継続的な事前学習を行う場合は、価格とパフォーマンスの面で最大の効果を得るために、トレーニング時にデータをS3 Standardに置くことが重要です。ただし、トレーニングワークロードが完了したら、Fine-tuning用のラベル付きデータや継続的な事前学習用のデータコーパスをGlacier Deep Archiveまで階層化することは、クラウドでのコストを最適化する合理的な方法です。また、お客様からよく質問されるのは、ストレージを最もコスト効率よく使用する最善の方法や、使用されないデータを見つける方法、そしてそのコンテキストでストレージをどのように考えるべきかということです。Storage Lensのようなストレージサービスを使用すると、S3データレイクを分析して最適化する方法を見つけることができますが、率直に言って、最もコスト効率の良い方法の1つは、S3 Intelligent Tieringを使用してハンズオフアプローチを取り、アクティブに使用されていないデータを見つけてこれらのストレージクラスに移動する作業の多くをAmazon S3に自動化させることです。
既存のFoundation Modelを活用する際に、お客様から次によく聞かれるのが、高性能なデータ検索と処理の必要性についてです。これは、Amazon S3が特に優れている分野の一つです。なぜなら、特定のバケット内で多数の異なるリクエストへの並列アクセスをサポートできるからです。 場合によっては、ワークロードに必要なパフォーマンスレベルを確保するために、データを再設計したり、S3データレイク内の複数のバケットにまたがってデータの配置を計画したりする必要があるかもしれません。一般的に、Amazon S3は高度な並列アクセスを念頭に設計されており、RAGのための前処理やデータ取り込みをサポートし、さらに推論ワークロード時のデータアクセスもサポートすることができます。
既存のFoundation Modelを活用する際に、お客様から最後によく聞かれるのが、AIとMLワークフローとの統合についてです。先ほどのデモでは、Amazon S3がAmazon Bedrockとどのように連携するかを見ていただき、また、AWS GlueやAmazon Athenaを使用してデータカタログを作成・インデックス化する方法についても説明しました。これらの機能の一部は、Amazon S3単体でも十分に実現可能です。ただし、ファイルベースのアクセスに依存するワークロードもあり、オブジェクトストアであるAmazon S3は必ずしもネイティブな互換性を提供していません。
これは、私たちが過去数年間にわたって重点的に取り組んできた分野です。お客様がGenerative AIアプリケーションを構築する際に必要とする一般的なワークフローとAmazon S3との互換性を確保してきました。Amazon SageMakerでは、File ModeとFast File Modeを提供しており、S3データレイクから直接GPUインスタンスにデータをロードすることができます。また、Amazon S3 Connector for PyTorchをリリースし、マルチパートのダウンロードとアップロードを使用してデータのトレーニングや、トレーニングデータの読み込み、チェックポイントの書き込みを最適化したライブラリを提供しています。
ファイルインターフェースを必要とするより広範なワークロードに対して、専用のソフトウェアパッケージを提供していない場合のために、Mountpoint for Amazon S3をリリースしました。 Mountpoint for Amazon S3をご存じない方のために説明すると、これはS3オブジェクトに対してローカルファイルシステムのAPIコールを提供するファイルクライアントです。これにより、S3データレイクに対してファイルインターフェースを使用した単純な読み書きが可能になります。共有ストレージのようなロック機能やファイルの名前変更などの機能は提供しませんが、多くのワークロードにおいて、S3データレイクへのスケーラブルなアクセスをファイルインターフェースで実現する簡単な方法となっています。
先ほど、Amazon S3が高いスループットを提供すると申し上げましたが、Mountpointコネクタは、ワークロードを実行している特定のインスタンスを確認し、S3からコンピュートインスタンスへのI/Oを並列で処理するために最適な数の並列スレッドを自動的に起動することで、最適なデータ転送を実現します。また、データキャッシング機能も追加しました。先ほど言及した10ミリ秒のレイテンシでも、すべての低レイテンシワークロードには十分ではない場合があります。このような場合、既に読み込んだデータをEBSやローカルNVMeにキャッシュすることで、後続のアクセスのパフォーマンスを向上させることができます。
既存のFoundation Modelを使用する際のお客様のストレージの種類やストレージ要件についてお話ししてきました。多くの方にとって、それで十分かもしれません。しかし、独自のモデルをトレーニングされる方々のために、そのようなワークロードもサポートできるストレージ機能を用意していることもお伝えしたいと思います。 独自のモデルをトレーニングするお客様からは、MLライブラリとの幅広い互換性、スケーラブルなパフォーマンスと低レイテンシー、そして直感的で協調的な環境が求められていると聞いています。
既存のモデルを使用する場合と、一からモデルをトレーニングする場合では、大きく異なります。 一からモデルをトレーニングする場合、多くの場合、特定のドメインやトレーニングアプローチに特化した様々なライブラリにアクセスする必要があります。例えば、DeepSpeedを使用してデータを分割し、クラスター内の複数のGPUノード間でデータ並列処理を実行することもあるでしょう。
また、Megatron-LMを活用してモデルを分割し、トレーニング目的でGPUノード間に分散させることもできます。音声認識を扱う場合は、NeMoを活用することもできます。これらの専門的なライブラリは、幅広い互換性があり、ワークロードのトレーニング時にこれらのライブラリを実行して活用できる環境があれば、すべて利用可能です。これらはすべて、Amazon SageMaker HyperPod内でも利用可能で、SageMakerのフルマネージド型GPU機能を活用しながら、GPUを継続的に稼働させ、効率的なログ記録を行うと同時に、実際のノードで必要なライブラリをSSH経由で実行することができます。
お客様から次に求められているのは、スケーラブルなパフォーマンスと超低レイテンシーです。ストレージからデータを取得してトレーニングインスタンスに供給する必要性についてお話ししてきました。トレーニングプロセス中のノード障害に備えて、あるいは後でトレーニングプロセスでの特定の変更の前後でモデルの精度を再評価できるように、モデルの状態を中間段階でストレージに保存する必要があるかもしれません。
re:Inventでの議論の多くを占めているテキストベースのモデルについて多く話してきました。テキストベースのモデルでは、モデルのトレーニングに使用される各GPUあたり約128メガバイト/秒のスループットが必要です。マルチモーダルモデルやビデオベースのモデルを扱い始めると、ストレージのスループット要件は増加します。GPUインスタンスに2ギガバイト/秒のスループットを供給しようとしていて、100個のGPUがある場合、ストレージのスループット要件は急速に積み上がっていきます。
先ほど、GPUワークロードの最適化において重要となるレイテンシーについて触れました。ストレージサービスからデータを読み取るリクエストを行うたびに、認証や認可のオーバーヘッド、そして実際にデータが格納されているディスクを特定するためのメタデータ検索のオーバーヘッド、さらにネットワーク自体の往復レイテンシーが発生します。このオーバーヘッドは、各リクエストで要求するデータ量が比較的小さい場合を除いて、通常は問題になりません。特に創薬のGenerative AIアプリケーションでZARファイルを扱う際によく見られるような、多数の小さなファイルを扱う場合は、低レイテンシーのストレージレイヤーを使用することが重要です。これにより、これらのI/Oの往復に伴うオーバーヘッドコストやトレーニング時間を最小限に抑えることができます。
お客様から聞いている最後のポイントは、モデルのトレーニングは本質的に共同作業であるということです。ドメインエキスパート、ML Ops担当者、クラウドアーキテクト、そして多くの場合、特定のドメインの研究者など、様々な人々が協力して作業を行います。彼らが求めているのは、使い慣れたインターフェース、POSIXパーミッション、そしてクラウドの多くの機能を活用しながらも、お互いのデータを上書きすることなく、一貫したデータアクセスを実現することです。
新しいモデルのトレーニングのために、お客様はAmazon FSx for Lustreを選択しています。これは世界で最も人気のある高性能ファイルシステムで、国立研究所や世界をリードするML研究者によって使用されています。他のファイルシステムと同様に、コンピュートノードにマウントしてデータを共有し、読み書きができます。POSIXパーミッションをサポートし、ユーザー間のコンテンツの上書きを防ぎ、高いパフォーマンスを実現しながら、共同作業環境で直感的に作業することができます。
ビデオトレーニングにおけるパフォーマンス要件について触れましたが、Amazon FSx for Lustreは、毎秒数百ギガバイトのスループット、ZARファイル用の毎秒数百万のI/O、そして小規模なI/Oに最適なサブミリ秒の一貫したレイテンシーをサポートしています。さらに、ファイルシステム間のパフォーマンスを向上させる新機能をリリースしました。
この新機能は、ファイルシステムと単一のGPUインスタンス間のパフォーマンスを向上させるもので、Elastic Fabric AdapterとGPUDirect Storageのサポートを含みます。これにより、クラウドにおけるGPUインスタンス向けの最速ストレージが実現しました。LustreファイルシステムとGPUメモリ間で直接データの読み書きが可能になり、メモリコピーやCPUを経由する必要がなくなったため、GPUインスタンスのCPU負荷を最小限に抑え、レイテンシーを削減し、スループットを最適化できます。特にI/O負荷の高いコンテキストでGPUを最大限に活用したい場合、これは非常に有用な機能となります。各クライアントインスタンスで150ギガバイト/秒のスループットを実現します。
Amazon FSx for Lustreについて、最後にお伝えしたいのはAmazon S3データレイクとの連携機能です。Amazon S3データレイクをFSx for Lustreファイルシステムに接続することができます。S3にオブジェクトを配置すると、データを実際に移動することなく、データレイク内のファイルやオブジェクトをファイルシステム上で透過的に表現できます。そして、EC2インスタンスがコンテンツを要求すると、FSxはリアルタイムでそのデータを取得できます。あるいは、ファイルシステムに事前にデータをロードすることも選択できます。 レイテンシーを最適化したい場合、S3バケットにデータを追加する際に、ファイルシステムと自動的に同期させることができ、 メタデータが再び表示されるようになります。また、ファイルシステムにデータを書き込む場合、そのデータを自動的に Amazon S3に送り返し、S3バケットとデータを同期させることができます。
私たちが発見したのは、多くのユーザーにとって、これが両方の利点を兼ね備えた素晴らしいソリューションだということです。 ユーザーは、インタラクティブな研究のために直感的で協調的なファイルシステム環境を求めると同時に、ストレージやIT管理者がデータを前述の方法で管理し、データパイプラインを最新の状態に保ち、すべてのトランザクションを管理・監査し、組織やチーム間でデータを簡単に共有できるようにすることを望んでいます。
この「両方の良いとこ取り」アプローチを採用している素晴らしい事例が、Adobeです。LG AI Researchと同様に、彼らもAmazon FSx for LustreとAmazon S3の両方を使用しています。この場合、FSx for Lustreを使用して、研究者やドメインエキスパートと共に様々なモデルを試験・実験しています。顧客にとって有用と思われる興味深いモデルを見つけると、それらを改良し、最終的にAmazon S3上で本番トレーニングを行い、S3データレイクを通じてデプロイします。これは、FSx for LustreのようなファイルシステムとAmazon S3のようなデータレイクの両方の利点を活用する素晴らしい方法です。
セッションのまとめと今後の学びのための推奨セッション
まとめると、私たちはアプローチの選択、データプランの作成、ストレージプランの作成について話し合いました。 アプローチを選択する際、RAGは既存のモデルを使用し、モデル自体に組み込むことなく独自の外部データセットにアクセスさせたい場合に理想的です。モデルに解釈させて独自の応答を生成させるのではなく、情報のソースまで直接アクセスできるため、非常に正確な結果を得ることができます。また、Fine-tuningについても説明し、データにラベルを付けて既存のモデルに特殊なタスクを教える方法や、そのためのデータ準備プロセスについても触れました。Continued pre-trainingや独自のモデルをゼロから構築する場合については、既存のモデルで正確な結果を得る方法、あるいは既存のモデルが存在しない場合にニーズを満たすものを確実に作成する方法について説明しました。
データ発見については、 自社組織、パブリックまたはアカデミックなデータセット、あるいはサードパーティからのデータライセンス取得など、データを確保できる様々な選択肢について説明しました。これらはすべて、現在の私たちの顧客が活用している選択肢です。また、データを持っているだけでは、生成AIアプリケーションで使用できる状態に最適化されているとは限らないということについても説明しました。RAGワークロードなどでは、リアルタイムでRAGワークロードによって識別できるように、データを前処理して準備する必要があります。
つまり、データをトークン化し、チャンク分割し、Vector Databaseに格納することで、ユーザーがアプリケーションを使用してプロンプトを生成する際に、簡単にマッチングできるようになります。また、Fine-tuningを行う場合、モデルに特殊なタスクを教えるためにデータをラベル付き構造で準備することが、出力の精度を高める上で重要です。セキュリティとガバナンスの面では、IAMパーミッションやライフサイクル管理など、データに関する政府やライセンスのポリシーを遵守するためのツールについて説明しました。
そして最後に、ストレージ計画の作成について説明しました。既存のFoundation Modelを基に開発を行う場合、Amazon S3はホットデータとコールドデータの両方に対して費用対効果の高いストレージを提供します。RAGベースのワークロードでは、ミリ秒または数十ミリ秒レベルのS3ストレージクラスを使用することになりますが、トレーニングを行ってそのデータをよりコールドな階層に移行する場合は、ストレージクラスの全範囲を活用できます。Amazon S3がデータの取得と処理に対して高いスケーラビリティを提供し、アプリケーション構築に必要な主要なAI/MLワークフローのほとんどと統合できることについても説明しました。もちろん、オブジェクトストアが完全に互換性がない領域では、Mount Pointがそのギャップを埋めるのに役立ちます。
そして、Foundation Modelをゼロから構築する場合、Amazon FSx for Lustreを使用することで、GPUリソースを最適化するのに役立つ、事実上あらゆるMLライブラリにアクセスできることについて説明しました。GPUインスタンスに対して数十ギガバイトのスループット、集約で数百ギガバイト/秒のスループットを提供し、Amazon S3バケットとの接続やデータの同期機能を含む直感的なコラボレーション環境を提供することで、データをAmazon S3データレイクに保存しながらユーザーにコラボレーション環境を提供できることについても説明しました。
さらに詳しく知りたい方のために、いくつかのセッションをピックアップしています。Generative AIワークロードのトレーニングに特化したAmazon SageMaker HyperPodの使用に関するセッション、先ほどのデモと同様に既存のFoundation Modelを基に開発する場合のAmazon Bedrockの使用に関するセッション、そしてオブジェクトストレージとファイルワークロードの両方でストレージから最高のパフォーマンスを引き出すためのセッションをいくつか推奨しています。以上でセッションを終了とさせていただきます。ご質問がある方は、Bijetaとわたしがこの前にいますので、しばらくお待ちしています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion