re:Invent 2025: AWS storageでGen AIとMLワークロードを高速化するアーキテクチャとコスト最適化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Accelerate gen AI and ML workloads with AWS storage (STG201)
この動画では、AWS storageを活用したAIユースケースの構築方法が解説されています。プロンプトエンジニアリングから始まり、RAG（Retrieval Augmented Generation）によるセマンティック検索、S3 Vectorsを使った最大90%のコスト削減を実現するベクトル管理、メタデータフィルタリングによる検索精度向上、MCPを活用したエージェント構築まで段階的に説明されます。さらに、supervised fine tuning、distillation、alignmentといったモデルカスタマイズ手法や、Amazon FSX for Lustreを用いた大規模モデルトレーニング、S3 Express One Zoneによる一桁ミリ秒のレイテンシー実現など、実践的なアーキテクチャが紹介されています。Metaが140テラビット毎秒のスループットを達成した事例や、バイオテック企業が3000万の科学論文を活用してリサーチ期間を大幅短縮した事例も取り上げられています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AI を機能させる鍵はあなたのデータ：生成 AI の課題と解決アプローチ
みなさん、ご参加ありがとうございます。素晴らしい参加者の皆さんですね。私の名前は Monica Vyavahare で、Amazon S3 のシニアプロダクトマネージャーをしており、AWS storage のプリンシパルプロダクトマネージャーの Jordan Dolman と一緒にいます。今日は、お客様が AWS storage を使って新しい AI ユースケースを構築・スケールしている方法についてお話しします。みんなが生成 AI で構築したいというのは周知の事実ですが、本当の課題は、それをあなたのデータ、あなたのビジネスに対して、コスト効率の良い方法で機能させることです。今日は、お客様が AWS storage を使ってこれをどのように実現しているかをお見せします。
AI を機能させるための鍵はあなたのデータです。汎用的な AI は汎用的な答えをくれますが、あなたのデータ、例えば顧客フィードバックや 使用パターンといったものが、AI をあなたのビジネスにとって価値あるものにするのです。今日、お客様を差別化しているのは、マルチステップの AI エージェントワークフローを推進するための関連データにアクセスする能力です。AI エージェントが適切なタイミングで適切なデータにアクセスできれば、あなたのビジネスと顧客をより良く理解でき、それはあなたの生産性を劇的に向上させるのに役立ちます。
では、コアな課題から始めましょう。生産性を向上させたい特定のタスクがあり、既存の大規模言語モデル、つまり LLM を使いたいとします。ファウンデーショナルモデルをそのまま使いたいのですが、自分のデータに基づいて応答してほしいのです。しかし、ここが問題です。LLM は静的なデータで学習されています。最新の情報やあなたのビジネスコンテキスト、あなたのユースケースを知らないので、汎用的な答えを出したり、時には幻覚を見たりするのです。
では、既存のファウンデーショナルモデルを使ってあなたのビジネスのための AI ワークフローを構築する方法について、いくつかのアプローチについて説明します。これは今日ほとんどの人が始める場所です。なぜなら、アイデアと持っているデータから高い生産性へ進むのは非常に簡単だからです。今日、異なるアプローチをカバーしていく中で、コスト、時間、複雑さが増していきますが、同時に出力品質も劇的に向上するので、このスケール上のどのアプローチがあなたのビジネスに適しているかを選ぶことができます。
プロンプトエンジニアリングによる個人生産性の向上とそのスケーリングの課題
では、最もシンプルなアプローチから始めましょう。プロンプトエンジニアリングです。特定のタスクとデータを念頭に置いている場合、おそらくプロンプトエンジニアリングから始めているでしょう。LLM に例、コンテキスト、制約を与えて応答をガイドするのです。個人的な例をお話しします。Amazon では、何かを構築したり立ち上げたりする前に、PR FAQ ドキュメントから始めます。これはプレスリリースと、お客様が立ち上げ後に何を聞くのか、どのような難しい質問で私たちに挑戦するのかを予測するための一連の内部および外部の FAQ で構成されています。これは問題から逆算して、正しい製品の形を定義し、正しいものを構築する方法を正確に知るのに役立ちます。
このPR FAQドキュメントを作成するのに役立つように、CLIで使用するマークダウンファイルにプロンプトを保存しておいています。その中に、過去に承認されたPR FAQの良い例を含めています。昨日聞いたような大きなローンチなどですね。また、顧客との会議のメモのようなコンテキストも含めているので、実際の問題ステートメントが何かを具体的に定義して絞り込むことができます。さらに、法務部門からのメッセージングに関する法的ガイドラインのような制約条件も含めています。その結果、個人の生産性が本当に向上しました。以前は良い初稿を作成してレビューポイントに到達するまでに数週間かかっていたプロセスが、今では数分で何かを得られるようになり、数日以内にレビュー可能なドラフトを得られるようになりました。それをステークホルダーとチームでレビューできるようになったんです。
ですから、これは本当に生産性を向上させてくれたのですが、このような機能をチーム全体に拡張して、みんなが恩恵を受けられるようにするにはどうすればいいでしょうか？数百のドキュメントや複数の異なるデータソースを含める必要がある場合、スケールしますか？すべてのコンテキストを手動で追加することはできません。なぜなら、あなたも経験されているはずですが、コンテキストウィンドウがオーバーフローしてしまい、そうなると品質が低下する傾向があるからです。本当に必要なのは、モデルに 大量のデータへのアクセスを与えることですが、同時に、最も関連性の高い情報のみを見つけて使用する能力を与えることです。そうすればコンテキストウィンドウが圧倒されることはありません。
RAG（Retrieval Augmented Generation）によるセマンティック検索の実現
RAG、つまりRetrieval Augmented Generationは、この問題に対するスケーラブルなソリューションです。関連情報を取得し、元のプロンプトをその関連コンテキストで拡張し、それを使用してより良い応答を生成します。覚えておいてください。私たちは、ファウンデーションモデルに進化し続けるあなたのデータへのアクセスを与えようとしており、すべてをプロンプトに手動で読み込む必要はないのです。
プロンプトを強化するために、RAGを使用します。これはセマンティック検索を使用して、任意のサイズのデータレイクから関連データを見つけて返します。 これがどのように機能するかです。まず、データをベクトルに変換します。ベクトルは基本的にはデータの数値表現で、その意味をキャプチャしています。既存のすべてのデータがベクトルに変換されたら、AIモデルにプロンプトを作成するとき、そのクエリもベクトルに変換されます。
空間的類似性を使用して、そのクエリベクトルを他のすべてのベクトルに対して検索し、類似したコンテンツを見つけます。その後、これらの近い一致を使用して元のプロンプトを拡張し、その拡張されたプロンプトをモデルに入力してより良い応答を得ます。モデルが学習した一般的な知識ではなく、この焦点を絞った関連コンテキストは、より正確な回答を得るのに役立ち、モデルが幻覚を起こす可能性も低くなります。
S3 へのデータ取り込みとベクトル化パイプラインの構築
RAG を使ってセマンティック検索でデータを活用する前に、まずデータを何らかの形式で用意して、アクセスしてベクトル化できるようにする必要があります。ほとんどのお客様は S3 を使ってデータを保存しています。それは S3 が低コストで、どのようなワークロードサイズにも対応できるスケーラビリティを備えているからです。データを S3 に取り込む主なアプローチは 2 つあります。1 つはバッチ取り込み、もう 1 つはリアルタイム取り込みです。
バッチは、ドキュメンテーション、履歴レコード、常に進化しているわけではない製品カタログなど、データが頻繁に変わらない場合に便利な手法です。バッチを使うもう 1 つの良い理由は、データを前処理する必要がある場合です。チャンキングや埋め込みの生成のような前処理が必要な場合、これはリアルタイムでスケーラブルに行うことはできません。2 番目の手法はリアルタイム取り込みで、ライブソーシャルメディアフィードやカスタマーサポートコールのライブトランスクリプトなど、データが頻繁に変わる場合に適しています。お客様が何を言っているかについて古い情報を持ちたくないので、1 週間前のバッチ操作や毎月のバッチ操作では古いデータになってしまうため、使用することはできません。
Amazon Kinesis または SQS を使用して、リアルタイムストリーミングデータを取り込む簡単な方法があります。これはデータを収集、処理、S3 に読み込みます。バッチ取り込みにもいくつかの方法があります。RAG ワークフローの場合、通常はバッチを選択するお客様が多いです。なぜなら、より簡単でコスト効率が良いからです。
では、データが S3 にあり、RAG でセマンティック検索に使用できるようにベクトル化したいとします。ベクトルとは何でしょうか？ベクトルは基本的に、セマンティック検索を通じて RAG をより強力にするメカニズムです。あらゆる種類のデータをベクトル化できます。この例では、テキストドキュメントを使用しましょう。ドキュメントがあり、それらはチャンクに変換されます。チャンクは基本的には、この場合テキストの有限の文字セットです。その後、これらのチャンクは埋め込みモデルを通じて、ベクトルを生成するために処理されます。また、一部の埋め込みモデルは、検索を絞り込むのに役立つメタデータも付加します。
これらの埋め込みとメタデータはベクトルデータベースに保存されます。これらのベクトルは、後でクエリを拡張するために使用できるように、進化するデータをキャプチャしていることを忘れないでください。このパイプラインでは、いくつかの選択肢があります。1 つは、データソースを選択する必要があります。これは S3 バケットまたはプレフィックスで、より細かい粒度が必要な場合はプレフィックスを選択できます。また、チャンキング戦略を選択する必要があります。映画スタジオであり、ここでやっているようなテキストドキュメントではなく、データが映画だと想像してください。アクト単位でチャンキングするか、シーン単位でチャンキングするか、またはより細かい時間枠でチャンキングするかを選択できます。その後、埋め込みモデルを選択し、最後にベクトルストアを選択する必要があります。
このパイプラインは自分で管理することもできますが、Amazon Bedrock の Knowledge Bases を使えば、それを自動で管理してくれます。このパイプライン全体を簡単に設定できる方法があります。素晴らしいのは、新しいドキュメントをアップロードすると、そのドキュメントが既にベクトルとして取り込まれて、ベクトルデータベースに格納されるということです。
Amazon S3 Vectors の登場：ベクトルストレージの経済性を変革
ベクトルは RAG に不可欠ですが、大量のベクトルを管理するのは難しく、コストもかかります。ここ数年、お客様から主に 3 つの問題をお聞きしています。1 つ目はコストです。従来のベクトルデータベースの多くは、ストレージ、メモリ、クエリを 1 つのユニットとしてバンドルしているため、大規模なベクトルセットをデプロイするのは非常にコストがかかります。
また、スケーラビリティも課題だとお聞きしています。小規模な概念実証から大規模な本番データセットへのスケーリングが難しいということです。そして最後に、粒度の問題があります。マルチテナントアプリケーション向けに数百万の個別インデックスが必要なお客様が多いとお聞きしており、そのスケールに達すると、コストが急増する傾向があります。これらすべてを通じて聞こえてきた本当のテーマはコストでした。お客様はベクトルを保存・管理するより効果的な方法が必要でした。だからこそ、今週 Amazon S3 Vectors の一般提供を開始しました。
この発表を非常に誇りに思っています。ベクトルストアとクエリにネイティブ対応した初めてのクラウドオブジェクトストアです。そして AI の経済性を完全に変えました。S3 Vectors は、ベクトルのアップロード、保存、クエリで最大 90% のコスト削減を実現します。頻繁に実行されるクエリをキャッシュできるため、100 ミリ秒のウォームクエリレイテンシを提供し、コールドクエリレイテンシは 1 秒未満です。1 つのインデックスあたり最大 20 億個のベクトルを保存でき、1 つのバケットあたり最大 10,000 個のインデックスを持つことができます。つまり、ベクトルバケットあたり 20 兆個以上のベクトルを保存でき、そのようなバケットを 10,000 個持つことができます。また、高速な取り込みも提供しているため、すぐに作業を開始できます。使用した分だけお支払いいただき、最良の点は、これが S3 の上に構築されているため、お客様は S3 について知っていて愛用している属性、つまり可用性、耐久性、セキュリティ、コンプライアンスにアクセスできるということです。
ベクトル価格設定は従来のベクトルデータベースとは根本的に異なります。ほとんどのベクトルデータベースはコンピュート、メモリ、ストレージをバンドルしており、すべてを一緒にお支払いいただきます。事前にキャパシティをプロビジョニングしてから、24 時間ずっと料金をお支払いいただきます。S3 Vectors がこれを完全に変えた方法は、実際の使用状況に合わせた 3 つの従量課金の価格設定コンポーネントを導入したことです。まず、取り込みに対して料金をお支払いいただきます。ベクトルデータベースに入れるベクトルに対してです。2 つ目はストレージです。S3 の業界トップクラスの経済性を活用して、ベクトルを非常に低コストで保存できます。そして最後に、クエリです。実際に実行するクエリに対して料金をお支払いいただきます。キャパシティプランニングは不要で、インフラストラクチャのオーバーヘッドもありません。これは、アプリケーションのワークロードが変動する場合に非常に役立ちます。
昼間はチームがたくさんのクエリを実行しているかもしれませんが、夜間や営業時間外はほとんど使用されていません。このようにして、あなたが実際に使用している時間に、使用している分だけの料金を支払うことになります。
こちらは顧客の事例です。私たちは今年の夏に Vectors のパブリックプレビューをローンチしましたが、この顧客はその時からずっと私たちと一緒にいます。彼らがどのようにスケールしているかを見るために、私たちは本当に彼らと一緒に仕事をしてきました。この企業はバイオテック企業で、S3 Vectors を使用して科学文献に対するセマンティック検索を行っています。彼らのチームは博士号を持つ科学者と起業家で構成されており、彼らの目標は本当に医薬品開発における次のブレークスルーを発見することです。そのためには、既に存在する科学文献と知識の膨大なコーパスを知り、吸収する必要があります。これは朝食の時に数論文を読むだけではありません。この問題の規模は3000万の科学論文です。
S3 Vectors と統合する前は、このリサーチフェーズには数週間かかっていました。そしてご想像の通り、すべての知識を吸収することは不可能です。S3 Vectors と統合した後、彼らのパイプラインはこのようになっています。彼らがアクセスできた科学文献のコーパス全体を取り込みました。それらは数百万のベクトル埋め込みに生成され、現在 S3 Vectors に格納されています。彼らが仮説を探索する際、これらのベクトルに対してセマンティック検索を実行して、近くにあるものと関連性のあるものを理解するのと同じくらい簡単です。これにより彼らのリサーチタイムラインが大幅に短縮されました。
メタデータフィルタリングで RAG をさらにスマートに
では、ここまでで何をしてきたかをまとめましょう。ベクトル化されたすべてのデータが S3 にあり、それに対して RAG ワークフローを実行してより関連性の高いコンテキストを取得しています。しかし、ここが重要な点です。このデータに対して RAG ワークフローを実行する場合、すべてのデータに対して検索しています。メタデータフィルタリングを使用することで、RAG をさらにスマートにすることができます。このメタデータフィルタリングは検索スペースを絞り込むことで、クエリをより高速に、より正確に、そしてあなたが実際に達成しようとしていることに対してより的確にします。例えば、3000万のドキュメントの代わりに、この企業は遺伝子合成に関するドキュメントのみを選択することができます。
Glue を使用して構造化データをカタログ化でき、非構造化データにカスタムメタデータを追加できます。メタデータフィルタリングを RAG ワークフロー内で直接使用できます。これはあなたの検索をより高速で効果的にするために WHERE 句を追加するようなものです。データを処理し続けると、より多くのメタデータが生成されます。この豊富なメタデータはあなたの AI 操作全体の神経系になります。メタデータはあなたが見ているデータが何であるかというコンテキストを与えます。これは Q4 の売上データです。また、データが実際にどこから来たのか、そしてどのように変換されたのかというラインエージを与えます。これは問題の根本原因を特定するのに本当に役立っています。最後に、個人識別情報などの機密データを自動的にタグ付けして、正しく管理されるようにする分類を与えることができます。
メタデータは、AI がデータが何であるかだけでなく、ビジネスにとって実際に何を意味するのかを理解するのに役立ちます。 ここまでで、完全な RAG システムを構築しました。データを S3 に取り込み、セマンティック検索のためにベクトル化し、メタデータフィルタリングでより効果的にし、コスト効率の良いベクトルストレージを導入しました。多くのお客様はここで止めることを選択します。なぜなら、これはすでに非常に強力な AI エンジンであり、大規模な結果を提供するからです。
複雑なタスクを実行する AI エージェントと MCP による標準化
しかし、もっと先に進みたいとしたらどうでしょう？「この問題を探索するのに似た科学文書は何か」というような単一の質問ではなく、複雑なタスクを分解し、ツールとその他のデータへのアクセスで強化し、複雑な問題を推論させたいとしたらどうでしょう？先ほど、PRFAQ の作成で生産性を向上させるために使用した例を使って、プロンプトエンジニアリングを紹介しました。今、来年のロードマップシーズンに入っており、re:Invent での今週のお客様との多くの会話、そして過去 1 年間の会話を通じて、来年何を構築するかを定義するのに役立てることができました。
このすべての情報と複数の異なるツールを使用して、ロードマップエージェントを作成できますか？今週のメモからのお客様フィードバックと、オンラインで持っているプロダクトレビューが必要だとしたらどうでしょう？S3 テーブルでお客様の使用データをチェックして、トップカスタマーを見つけたい。そして、それらを組み合わせて、お客様が議論している主な課題を見つけたい。それぞれの課題に対して、起動すべき新機能のピッチとして、それぞれの PRFAQ を作成したい。これには、LLM が複雑なタスクを推論し、複数のデータソースとツールを使用し、それらのアクションを実行する必要があります。RAG ではもう十分ではありません。今、エージェントが必要です。
エージェントを使用すると、LLM に事前にツールのセットを与えます。ドキュメントへのアクセスのための Bedrock Knowledge Bases、使用統計へのアクセスのための S3 テーブル、ソーシャルメディアからお客様フィードバックを取得するための API などです。 ここが大きな転換点です。これまでプロンプトエンジニアリングでは、ステップバイステップでモデルをガイドする必要がありました。今、エージェントはステップを判断し、どのデータが必要かを判断し、それを取得するための正しいツールが何かを判断します。この図を見ると、すでにゴール、指示、コンテキストでモデルにプロンプトを与えていました。ツールがここで不足していた部分です。 これはすべて、この基盤モデルを使用してアクションを実行しているエージェントに供給されます。
これらのツール統合をすべて管理することは、非常に複雑になり始める可能性があります。ここで MCP が登場します。 MCP、つまり Model Context Protocol は、ツールがエージェントと接続する方法の標準になりつつあります。これは、HTTP がアプリケーションがバックエンドと通信する方法を標準化した方法と非常に似ています。これには 2 つの部分があります。MCP クライアントと MCP サーバーです。MCP クライアントは方法を定義します。データベースをクエリする方法、ナレッジベースを検索する方法です。MCP サーバーは実際にそれを実行します。それらの制約とルールをチェックし、その後、そのクエリを実際に実行し、設定方法に基づいて結果をカスタマイズします。
AWSは、皆さんのエージェントが適切なツールを通じて適切なデータを見つけるのを支援するために、当社のサービスと外部サービス向けにいくつかのMCP serverを構築しています。例えば、Bedrock Knowledge Bases用のMCP serverがあります。これで、APIコールは不要で、自然言語を使ってナレッジベースをクエリできるようになりました。これにより、ナレッジベースの特定のセクションをターゲットにしてフィルタリングできます。結果のサイズを設定したり、出力を再ランク付けして、検索対象との関連性を向上させたりできます。
これは会話形式でも行えます。つまり、ロードマップエージェントが「顧客が製品レビューで報告している主な制限事項は何か」と質問できるようになり、すべて設定可能です。セマンティック検索用のRAGに加えて、データをフィルタリングして見つけるための従来の方法も必要です。そこでメタデータが活躍します。S3 Metadataを使ってメタデータを生成して検索でき、これは構造化データと非構造化データの両方に対応しています。
このしくみについて説明しましょう。PDFやCSV、オーディオファイル、ビデオファイルなど、様々な種類のデータがあり、すべてS3バケットに格納されているとします。まず、ソースバケットを設定し、ソースバケットでS3 Metadataを設定します。次に、S3 Tableバケットを作成します。ここがクエリ可能なメタデータテーブルが存在する場所です。これらは両方とも、単一のAPI呼び出しまたはS3コンソールで数回クリックするだけで実行できます。
最後に、S3がそのテーブルバケットにメタデータテーブルを生成し、データが変化するにつれて数分ごとに自動的に更新されます。新しいオブジェクトに対して自動更新され、システムメタデータを自動的に追跡し、カスタムメタデータを設定することもできます。RAGワークフローはこのデータをメタデータフィルタリングに活用して、より最適化されたターゲット検索を実現できます。また、独自のユースケースのために自分でクエリすることもできます。
Athena、Quick Suite、Spark、またはSQLベースのプロセスを使用して、メタデータから貴重なインサイトを得ることができます。これはRAGと分析に非常に有用ですが、エージェントにとっても有用です。これで、このリッチなカタログ化されたメタデータが得られ、エージェントもこれにアクセスできます。今年、Amazon S3 Tables用のMCP Serverもローンチしたので、自然言語を使ってS3 TablesとS3 Metadataと対話できるようになりました。もうSQLは不要です。
では、私のロードマップエージェントに戻りますが、これは顧客の使用状況のテーブルをチェックして、私が解決している特定の問題に対して上位10社の顧客が誰であるか、そして彼らの月間使用状況がどのようなものであるかを確認することができます。これはすべて AWS MCP のオープンソースリポジトリで利用可能で、セットアップは本当に簡単です。では、これをすべてまとめてみましょう。私たちはプロンプトエンジニアリングから始めました。LLM に例、制約、コンテキストを与えて、より良い応答を得るというものです。
その後、RAG を追加しました。LLM に、より関連性の高いデータへのアクセスを与えて、そのコンテキストを埋め、元のプロンプトを拡張するというものです。これをサポートするためにデータをベクトル化しました。メタデータフィルタリングについて説明して RAG 検索をターゲット化し、また S3 Vectors についても話しました。これはベクトルストレージを管理するための費用対効果の高い方法です。
その後、エージェントにレベルアップしました。LLM に複数のツールに接続して複雑なタスクを実行する能力を与えたのです。
そして最後に、MCP についても話しました。これはエージェントがツールに簡単に接続できるようにする標準です。これが最新の AI スタックであり、多くの顧客がここで止まります。なぜなら、これは本当に強力でスケーラブルだからです。
さらに先に進みたいという顧客もいます。より高度なワークロードについて議論するために、Jordan をステージに招待したいと思います。
モデルの重みを調整する：ファインチューニングへの移行
ありがとうございます。では、Monica は、プロンプトエンジニアリングを使用してより良い構造を提供し、RAG を使用してモデルの出力を改善するためにより多くのデータを提供する方法について、たくさん話しました。
これは多くの場合に機能しますが、私たちが今話した多くのデータと構造は、アプリケーションのコンテキストウィンドウに存在しています。これはモデルの短期記憶のようなもので、それが固定されているため、時には既製品を使用する代わりに、実際にそのコンテンツの一部をモデル自体に埋め込む必要があります。
では、モデルが今日どのように機能し、どのように構築されているかを考えてみましょう。
私たちがアクセスできる既に存在しているすべてのモデルは、大規模なデータセットで訓練されており、訓練に使用された知識は、モデル自体の重みに深く埋め込まれています。そのデータは、プロンプトをモデルに導入して応答を得るときにアクセス可能ですが、探している知識が利用できない場合、または構造がアプリケーションと一致しない場合、実際にはそれらの重みを調整し、モデル自体を更新して、正しい種類の出力を得る必要があります。
もちろん、それにはデータが必要で、どのくらいのデータを持っているかによって、モデルの出力を訓練して改善するために使用できるさまざまなテクニックがあります。データの量が少ない場合は、モデル全体の重みを更新しようとするのではなく、本当にモデルの一部だけを更新することに焦点を当てたいのです。データから最大の価値を得るには、データにラベルを付けることでさらに多くのガイダンスを提供したいのです。そうすることで、入力と探している望ましい出力が非常に明確になります。
小さなラベル付きデータセットに基づいて、モデルが特定の出力を生成するように導こうとしており、モデルの小さな部分またはサブセットに焦点を当てるつもりです。より多くのデータがある場合は、そのラベル付けを使用してガイダンスを提供し、実際にモデルの重みをさらに更新することに拡張できます。これは、モデルに指定された情報を教えるというよりも、あなたが取り組んでいるドメインで考えるのを助けるようなものです。それはモデル自体にまだ組み込まれていない可能性があります。
膨大な量のデータがある場合は、実際にそのラベル付けステップをスキップして、continued pre-training に似たものに直接進むことができます。これは元のモデル開発者が中断したところから再開し、その新しいコンテンツをそれらのモデルの重みに組み込むようなものです。これをサポートするために利用可能なサービスは Amazon Bedrock と Amazon SageMaker AI です。主に推論側、アプリケーションビルダー側にいることに気づいた場合、Bedrock が本当にあなたが操作したい場所です。
自分自身をモデルビルダーまたはモデル開発者と考える場合は、SageMaker AI が行き先です。これらの両方のケースで、これからお話しする、モデル自体を更新する機能がありますが、各サービスは本当に特定のタイプのユーザーエクスペリエンスのために洗練または調整されています。それでは、このラベル付きデータを使用してモデル自体を実際に更新するためのさまざまなテクニックについて説明しましょう。3つのテクニックから始めます：supervised fine tuning、distillation、alignment です。
ラベル付きデータを活用した3つのテクニック：supervised fine tuning、distillation、alignment
ML の分野では、これらの言葉の多くが飛び交っていることを知っています。ですから、今日の目標の1つは、各テクニックがどのように異なるのか、そしてそれがデータにとって何を意味するのか、ストレージにとって何を意味するのかについて、誰もが明確に理解していることを確認することです。では、supervised fine tuning についてお話ししましょう。前に述べたように、ラベル付きデータは、モデルに「ここに入力があります、ここに見たい出力があります」と伝えようとしているときに本当に役立ちます。これは同じ流れの中にあります。
入力は何になるのか？ユーザーは何を言っているのか？このやり取りの一部として、他にどのようなコンテキストが利用可能なのか、そして最適な単一の応答または出力は何なのか？ 翻訳や要約のような何かに対しては、シンプルなモデルが使用されるかもしれません。これはテキストからテキストへ、テキスト入力、テキスト出力です。ラベル付きデータは次のようなものになるかもしれません。非常にシンプルなプロンプトと、あなたが見たいと思う望ましい出力です。これは非会話型のモデルです。
もっと会話型のモデルがある場合、これはより多くのチャットボットのような体験になります。 ラベル付きデータは実際には、ユーザーとアシスタントのタグが必要になることに気づくでしょう。つまり、誰が実際にプロンプトを導入していて、誰が応答しているのかというようなものです。そのラベル付きデータの一部は、エージェントとユーザーの間を行き来する複数のターンを持つこともできます。これはそのラベル付きデータセットの一部です。さて、私がこれをすべてスライドの上に置いている理由は、組織全体で生成および収集しているデータについて考えるときに、このデータが将来どのように使用されるかを事前に考えることが本当に役に立つからです。
これは特に、将来のトレーニングに使用するために数十万のデータポイントを生成することを期待していない場合に当てはまります。そしてあなたはラベル付きデータセットに依存するつもりです。コールセンターログまたは他の種類のやり取りから出てくるデータにラベルを付けたいかもしれない方法について事前に考えることは本当に役に立つことができます。別の例があります。 これは別のタイプのモデルで、画像からテキストへですが、やはり画像参照があり、その後に説明またはキャプションがあります。基本的には、この種の画像を見たときに、白いスポットのあるオレンジ色の猫の漫画で応答してほしいと言っています。
今日私が共有したこの教師あり微調整の例は Amazon Bedrock で利用可能です。ですから、一般的にはアプリビルダー向けに意図されていますが、Bedrock で作業するときにもこの種の機能が利用可能です。これらのモデルをカスタマイズするためです。次の機能は、基礎となるモデル自体を調整するかもしれない場所は distillation です。
これは、大規模モデルを使っていて、そこから得られる出力が本当に気に入っているけれど、ユーザーの行動やアプリケーションの要件に対して、モデルがちょっと遅いという場合に役立つかもしれません。コストが高いかもしれませんが、やはり出力が気に入っていて、より小さくて機敏で低コストのモデルから同じような出力を生成しようとしても、気に入った結果が得られないという状況ですね。Distillation は supervised fine tuning のいとこのようなものです。
ここでもプロンプトが入ってくるわけですが、この場合、実は出力レスポンスを提供しません。出力は大きな teacher モデルによって生成され、その後入力と融合されて、基本的には小さな student モデルを訓練するためのラベル付きデータとして使用されます。ここでもちょっと複雑になってきます。テキストをたくさん詰め込みすぎないようにしようとしていますが、ここで重要なのは、この3行目に user というロールがあるのが見えることです。そしてテキストとコンテキスト、それから質問がありますが、assistant のレスポンスはありません。これは、assistant のレスポンスが大きな teacher モデルから来るからです。これは、実は全ての答えを持っていなくても、大規模モデルが気に入ったコンテンツを生成することを知っている場合に、かなり役立ちます。distillation のようなものを使うことができます。
そして3番目のテクニックラベル付きデータで本当に役立つことができるのは alignment です。これは知識のための訓練というより、トーンや、もしかしたらコンプライアンス、レスポンスにガードレールを追加することについての訓練です。これは組織のブランディングにとって本当に役立つことができるものです。fine tuning と同様に、プロンプトは何か、コンテキストは何かを提供したいのですが、この場合、好ましいレスポンスと好ましくないレスポンスを提供したいのです。
ここで、実は例が本当に役立つと思います。提供しようとしているこのラベル付きデータには、異なるレスポンスのスコアまたはガイダンス、そしてどちらが好ましいかが含まれています。ここで、モデルに対して、どの出力を見たいかだけでなく、それが別の出力とどのように比較されるかを教えているので、時間とともに好ましい出力に向かって本当に理解し、形作ることができます。この種の direct preference optimization、この alignment テクニックに興味がある場合、SageMaker AI にシフトする必要があります。これは今日の Bedrock では利用できません。
ラベル付きデータを使用した3つの異なるテクニックがあります。また、今日共有した例は実際の例で、supervised fine tuning、distillation、alignment に対してその種の構造と構文を使用できるということも注目する価値があります。ただし、すべてのモデルで機能するわけではありません。事前に作業する予定のモデルの特定の入力、特定のラベル付きデータ要件を確認して、実際にデータを適切に構造化するか、もちろん後で変更することもできます。
継続的な事前学習とゼロからのモデルトレーニング：大規模データとインフラの統合
では、左側のラベル付きデータから始まって、今は右側まで進んできました。ゼロからの新しいモデルの継続的な事前学習とトレーニングですね。最後にこのスライドの1つに戻ってくることになります。ここでも、大量のデータがあるわけですが、モデルの出力にまだ満足していなくて、さらに進めたいという状況です。ここで最適な選択肢は継続的な事前学習ということになります。
ここでは、ラベル付きのデータセットを用意する必要はありませんが、新しい知識、新しいトーン、データ間の新しい関係性をモデル自体に深く組み込むことができます。ただし、実際には、作業しているモデルが、作成しようとしているモデルとは構造的にまったく異なるデータで学習されているケースもあります。例えば、言語が異なる場合もあります。あるいは、大規模言語モデルではなく、天気予報モデルや創薬の基盤モデルのようなものかもしれません。その場合は、本当にゼロからモデルを構築することになりますが、それは問題ありません。必要なデータがすべてあれば大丈夫です。ここではそのことについて話していきます。
継続的な事前学習またはゼロからのモデルトレーニングを行う場合、以前のフェーズとの大きな違いの1つは、これがはるかにリソース集約的な取り組みであるということです。
これはより多くのリソースを必要とする取り組みであり、データ、コンピュート、ストレージの統合が本当に重要になってきます。理由は、ゼロからモデルをトレーニングするか継続的な事前学習を行うために必要な膨大な量のデータを、ストレージから効率的にGPUまたはアクセラレータインスタンスにロードする必要があるからです。さまざまな理由で、定期的に中間チェックポイントをストレージに書き込むこともあります。インフラの問題が発生した場合に復元するための安全なポイントを確保するためにチェックポイントを書き込むこともありますし、モデルを評価して、時間をかけて異なるデータセットでトレーニングを試したい場合に戻りたいポイントになることもあります。
これらすべてのケースで、GPUに取り込む必要があるデータが大量にあり、GPUから非常に迅速に取り出したいチェックポイントデータがあります。これらのGPUおよびアクセラレータインスタンスがデータを処理できるレートについて、ご理解いただくために、テキストベースのモデルを扱っている場合、通常、1つのGPUあたり約128メガバイト/秒が見られます。複数の異なるGPUでの分散トレーニングを想像してみると、その数はかなり高くなる可能性があります。毎秒数十ギガバイトになります。より豊かなメディア、マルチモーダルモデル、またはビデオを扱っている場合、これらのアクセラレータおよびGPUインスタンスにデータを駆動するために必要なスループットはかなり大きくなる可能性があります。
パフォーマンスに影響を与えるもう一つの要因は IO のサイズ、つまり、ある時点でのリクエストに対して取得しようとしているデータのサイズです。ストレージからデータを読み取ることを考えると、そのデータを取得するのにかかる時間は、リクエストのオーバーヘッドとデータ自体、つまりペイロードを移動させる時間の組み合わせです。リクエストのオーバーヘッドには、そのデータへのアクセス権があることを認証すること、GPU またはアクセラレータインスタンスとストレージ間でデータを実際に取得するためのネットワークレイテンシー、そしてストレージシステム内でデータがどこに存在するかを把握するためのメタデータルックアップが含まれます。
小さなファイルや小さな IO、小さなオブジェクトを扱っている場合、そのオーバーヘッドに費やす時間が実際には読み取り全体を支配することになります。ここで重要なのが、低レイテンシーストレージ、つまり認証を実行でき、ネットワークパスを短縮でき、メタデータルックアップを非常に迅速に実行できるストレージを持つことで、ジョブの完了時間に大きな影響を与えることができます。これらのモデルをトレーニングしたり、継続的な事前トレーニングを行ったり、モデルをゼロからトレーニングしたりすることは、かなり費用がかかる可能性があります、ですから、これらのインスタンスが常にビジーな状態を保ち、トレーニングが効率的であることを確認することは、インフラストラクチャ側にとって役立つだけでなく、最初の場所でこれらのモデルを開発している人々に対応を提供し、迅速に反復するのにも役立ちます。これは本当に協調的で反復的なワークロードだからです。
AWS ストレージポートフォリオ：FSX ファイルシステムによる研究開発の加速
AWS が保有しているストレージポートフォリオの中で、ファイル側には Amazon EFS、つまり Elastic File System があります。Amazon FSX があり、これは商用およびオープンソースのファイルシステムで、クラウド内で顧客に代わって管理されています。これは RDS に似たようなものです。FSX ファミリー内にはさまざまなファイルシステムオファリングがあります。Amazon S3 を使用したオブジェクトストレージ、そして EBS を使用したブロックストレージがあります。特にモデルトレーニングの場合、顧客が使用する共有ストレージオファリングは FSX と Amazon S3 ファミリー内に該当します。
さらに一歩進めると、顧客がどのストレージサービスを使用するかについて考える方法は、通常、ユースケースによって異なります。研究開発側で作業している場合、ファイルシステムは共有ストレージの推奨されるアプローチです。より固定されたデータパイプラインを備えた本番ユースケースに最適化されたものを探している場合、それは Amazon S3 とオブジェクトストレージがより最適化される場所です。ファイル側について詳しく見てみましょう。ここでの私の目標は、AI と機械学習で一般的に言及されるこれらすべての異なる用語を理解し、各ユースケースに対してどのサービスを使用するかを知っていることを確認することです。
研究開発の場合、特定のユースケース向けに構築および設計されたさまざまなファイルシステムがあります。単一のサーバーに依存するスケールアップファイルシステム、より大きくまたはより小さくすることができるファイルシステムは、ポートフォリオの一部であり、アーキテクチャの一種です。その後、複数のサーバーを一緒に結合してより高いレベルのパフォーマンスを提供するこれらのスケールアウトファイルシステムがあります。
Amazon FSX for Open ZFS はオープンソースのファイルシステムで、私たちが顧客のために完全に管理しています。これはスケールアップ型のファイルシステムで、通信に NFS を使用しています。これは EC2 インスタンスや他のクライアントインスタンスとファイルシステムが通信する最も標準的な方法です。ホームディレクトリ、開発環境の保存、Git リポジトリの保存など、超低レイテンシーのワークロードに理想的です。
これは開発者がデータを保存したい場所です。例えば Kubernetes ベースの開発者環境スタックがあって、研究者のインスタンスが起動と停止を繰り返されるような場合でも、その間に共有ストレージを提供したいのであれば、Open ZFS の共有ファイルシステムのようなものは非常に価値があります。一方、複数のサーバーを組み合わせることで、Amazon FSX for Lustre のようなものにたどり着きます。 これもまた、顧客のために私たちが管理するファイルシステムなので、顧客は Lustre が何であるか、どのように機能するかについて考える必要がありません。
顧客にとっては、これは単にインスタンスにマウントするマウントポイントになり、ファイル API を使用します。ファイルを開く、読む、書く、閉じるという非常にシンプルなインターフェースです。しかし、得られるパワーは、ストレージに対して非常に高いレベルのスループットと I/O、またはトランザクションを駆動する能力です。これは顧客がトレーニングデータを保存し、チェックポイントデータを受け取って復元するために推奨するソリューションです。本当にスケーラブルなパフォーマンスを提供しているからです。 これらのオファリングで行ったことの一例は、顧客が Elastic Fabric Adapter や GPU Direct Storage のような強化されたネットワーク機能を FSX ファイルシステムで実際に使用できるようにしたことです。
このネットワークスタックにより、顧客は FSX for Lustre ファイルシステムから CPU メモリまたは GPU インスタンスと加速器インスタンスの GPU メモリに直接データを読み込むことができます。これはパフォーマンスのために最適化されているため、これらの特定のワークロードにはこれらのファイルシステムを推奨しています。これらのネットワークスタックを使用するためにこれらのステップを実行する必要はありませんが、利用可能です。一度セットアップしたら、これらのネットワークスタックによって実現される高いレベルのスループットを達成するために特別なことをする必要はありません。 ファイルシステムに歴史的に関連付けられている課題が 1 つあります。多くのファイルシステムは SSD ベースのディスク、ソリッドステートディスクに基づいています。なぜなら、多くのファイルベースのアプリケーションは非常に低いレイテンシーの応答と高いトランザクションレートを期待しているからです。
SSD ベースのファイルシステムの課題の 1 つは、高額になる可能性があることです。大量のデータがあり、その一部はホットで一部はコールドの場合、すべてをSSD ベースのファイルシステムに保存することは理想的ではありません。データボリュームが急速に増加および減少している場合、そのデータをサポートするために SSD ディスク上に適切な量のストレージを持つことも課題になります。この課題に取り組んでいて、ホットとコールドのストレージオファリング間でデータを移動しようとしている方々にとって、それは単に運用上のオーバーヘッドが増えるだけです。 過去 1 年間に FSX オファリングで行ったことの 1 つは、FSX Intelligent-Tiering を追加したことです。これは S3 Intelligent-Tiering で見られる概念と非常に似ています。
ファイルシステムには事実上無制限のエラスティックストレージがあります。Glacier Instant Retrieval のようなサービスでおなじみかもしれない、1ギガバイトあたり半ペニーという価格ポイントを実現しています。SSD ベースのティアを含むホットなティアから、コールドなアーカイバルインスタントアクセスティアまで、データを自動的に移動させています。かなり長い間、ファイルシステムを使いたいけれど大量のデータを持っているお客様は、すべてのデータがファイルインターフェースを通じてアクセスされるにもかかわらず、コスト上の理由だけで Amazon S3 とファイルシステムの間でデータを分割していました。 これにより、お客様は単一のファイルシステムで作業でき、さまざまなティアのすべての利点を活用できるようになります。ホットなデータに対しては SSD のパフォーマンスが得られ、過去数日間使用されているホットなデータに対しては頻繁にアクセスするティアのコストが得られます。そしてデータがどんどんコールドになるにつれて、それをアーカイブしていき、0.5 ペニーという価格ポイントまで自動的にコスト削減が実現されます。
ホットとコールドのデータが混在している場合、これは非常に簡単で使いやすいものです。これは FSX for Lustre または FSX for Open ZFS ファイルシステムでアクセス可能です。S3 の S3 データレイクにデータが保存されているお客様の場合、FSX を S3 データレイクと統合するための他の機能もあります。 1 つのオプションは、ファイルシステムを S3 バケットに接続し、データへのポインタであるメタデータをファイルシステムにロードすることです。これらはファイルとして表示されるため、ディレクトリを開くと、S3 データが EC2 インスタンス上に通常のディレクトリとして表示されます。
そのデータにアクセスすると、バックグラウンドでファイルシステムに遅延ロードされ、EC2 インスタンスに通信または共有されます。 S3 に新しいデータを追加すると、それが自動的にファイルシステムに表示される可能性があり、ファイルシステムに新しいデータを書き込むと、 それが自動的に S3 にプッシュバックされる可能性があります。これは非常に強力なアーキテクチャです。Matt Garman の基調講演を見た場合、 このアーキテクチャが何度か表示されているのを見たかもしれません。お客様はこれを好みます。なぜなら、ストレージと IT 管理者は S3 データレイクでデータを操作することを考えることができ、研究者はファイルシステムが提供する直感的で協調的なインターフェースを持つことができるからです。基調講演に含まれていた例の 1 つは Adobe です。 彼らはこの特定のアーキテクチャを使用して、S3 に大量のデータを保存し、ファイルシステムを通じてアクセスしています。彼らはこれを多くの研究に使用して、実際にどのモデルが本番環境に移行されるのか、どのモデルが有用で価値を追加するのかを判断し、最終的には S3 を使用して本番トレーニングの一部を実行しています。
ファイルシステムにデータを保存することを選択した場合、実は今年、実は今週、そのデータを幅広い Amazon Analytics サービスでアクセス可能にするための新しい機能を追加したことは、おそらく注目する価値があります。 前述の例では、S3 データを含むデータレイクがあり、FSX for Lustre ファイルシステムを通じてアクセスできます。この場合、FSX ファイルシステムにデータがあるが、Amazon S3 でアクセスしたい場合、現在は FSX ファイルシステムに接続できる アクセスポイントという概念があります。Open ZFS ファイルシステムまたは現在は NetApp ONTAP ファイルシステムに保存されている可能性のあるデータにアクセスできます。 これは、オンプレミスから NetApp ファイルシステムでデータをクラウドに移行し、そのデータを Amazon Bedrock でアクセス可能にしたいお客様にとって非常に役立ちます。前述のファインチューニングまたは蒸留ユースケースのためです。すべてのそのデータは、これらの S3 アクセスポイントを使用して、これらの AWS サービスのすべてでもアクセス可能になります。
Amazon S3 Express One Zone と ML 最適化：Meta の事例とまとめ
これまで、Amazon FSX を使用して、これらの研究開発アプリケーションに必要なパフォーマンスを加速して提供することについて話してきました。S3 でこれらの ML ワークロードに対して最適化するために何をしたかについて、少し話しましょう。 Amazon S3 には多くのストレージクラスがあります。左側のものは、ホットなデータに使用されるものです。左端の Amazon S3 Express One Zone と Amazon S3 Standard の両方は、さまざまなアプリケーションに対して非常に高いレベルのスループットを提供します。Amazon S3 Express One Zone は Amazon S3 と異なり、はるかに低いレイテンシーを提供します。しかし、実際には継続的な事前トレーニングまたはモデルをゼロから トレーニングしている場合、すべてのデータがこれら 2 つのクラスのいずれかにあることを期待する必要があります。なぜなら、それが頻繁にアクセスされ、右側のさらに先のティアのリクエストコストプロファイルを持ちたくないからです。
Amazon S3 Express One Zone がこのようなユースケースに対して最適化している方法の一つは、get リクエストや put リクエストのたびに認可リクエストを行わないことで、より低いレイテンシープロファイルを提供しているということです。実際には、セッションベースの認可を使用しているので、一度認可を行えば、その後はオブジェクトストレージから読み書きしたり、入力を取得したりして、より低いレイテンシーを実現できます。もう一つの特徴は、名前に表れているように Amazon S3 Express One Zone ということです。
このS3ストレージクラスをアベイラビリティゾーン内にデプロイしているので、GPU やアクセラレータインスタンスと同じ場所に配置されており、ネットワークパスも短縮されます。セッションベースの認可と GPU やアクセラレータインスタンスとのクラスターの同じ場所への配置という、この二つの機能により、小さなオブジェクトを扱う際に本当に役立つ、一桁ミリ秒のレイテンシーを実現することができます。小さなオブジェクトと相まって重要なもう一つの特徴は、非常に高いレベルのトランザクション毎秒を最初から備えていることで、このストレージクラスでは数十万のトランザクション毎秒が利用可能です。
このような種類のトレーニングを多く行っているお客様の興味深い例として Meta があります。 彼らは非常に高いスループットのオブジェクトストレージクラスを求めて私たちのところに来ました。それは非常に高いレベルのトランザクション毎秒と、この一桁ミリ秒のレイテンシーを備えたものです。私たちは彼らと協力して、140 テラビット毎秒のスループットレベルを達成するために S3 Express クラスターをスケールしました。これは毎秒 17 テラバイトです。ここは明らかにスーパーコンピューティングストレージの範囲であり、クラウドでこれらのモデルをトレーニングするために利用可能です。このような規模で何かを行うことを誰もが期待しているわけではありませんが、小規模から最も要求の厳しいワークロードのニーズを満たすためにスケールする能力まで、私たちが持つ機能を示しています。
インフラストラクチャの一部をデータセンター内で物理的にコンピュートに近づけることに加えて、S3 で実行する可能性のあるワークロード、特に機械学習に対して API をもう少し近づけようとしました。 その例として、Mountpoint for Amazon S3 と Amazon S3 connector for PyTorch があります。多くの機械学習ワークロードとライブラリはファイルインターフェースに依存しており、データにアクセスするためにファイルインターフェースを使用することを期待しているため、Amazon Mountpoint for S3 を追加しました。これは Amazon S3 に完全に最適化されたコネクターです。世界中には、オブジェクトストレージと連携してファイルインターフェースを提供するコネクターが多くありますが、S3 がどのように機能するかを活用するために完全に最適化されたものが必要でした。
これは読み取り専用の機械学習ワークロードに非常に役立ちます。モデルをトレーニングして S3 上の大量のデータを読み取ろうとしている場合、Mountpoint for Amazon S3 を使用してそのデータに読み取り専用でアクセスし、ファイルオープンと読み取り API を効果的に S3 get に変換するというシンプルなプラグインです。一方、インターフェースを単に入れ替えるだけでは十分でない場合があることがわかっているワークロードもあります。そのような場合、スタックの上の方に進みたいと考えており、それが PyTorch 用のコネクターのようなものが登場する場所です。ここでは実際にファイルインターフェース全体を入れ替えて、Amazon S3 に対して本当に最適化されたものを開発しました。これにより、より多くのストリーミングとプリフェッチングを行って、S3 からそのトレーニング作業のための EC2 ノードにデータを取得することができます。
では、データを使ってモデルを改善するためのさまざまな方法をすべてカバーしてきました。推論の場合、つまりモデル自体を変更せずに推論時により良い出力を得ようとしている場合は、プロンプト、ナレッジベース、メタデータがあります。または、基盤となるモデル自体を変更する必要がある場合は、ラベル付きデータまたはラベルなしデータを取得して、ここにあるいくつかのテクニック—fine tuning、distillation、alignment、continued pre-training、または一からモデルをトレーニングする—これらはモデルビルダーペルソナにより関連してきます。
もっと詳しく知りたい場合は、今後24時間以内にいくつかのセッションがあり、興味深いかもしれません。私の共演者 Monica と私は、ご質問があればそばにいますので、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion