re:Invent 2024: AWSでFoundation Modelを効率的にトレーニングする方法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Explore the many ways to train foundation models on AWS (CMP321)
この動画では、AWSでFoundation Modelをトレーニングする方法について詳しく解説しています。AWS Generative AIスタックの全体像から、トレーニングのオーケストレーション手法、そしてAmazon SageMaker HyperPodの具体的な利用方法まで、実践的な内容をカバーしています。特に、P4dやP5インスタンスを使用した大規模分散トレーニングの方法や、FSx for Lustreとの連携、EFAを活用したネットワーキングの最適化など、具体的な実装のポイントを学べます。後半では、NinjaTech AIのCEOが自社のSuperAgentシステムを例に、AWS上でのAIモデルトレーニングの実践例を紹介し、Arena Hardベンチマークで94.3という最高水準のスコアを達成した具体的な手法についても言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSでのFoundation Modelトレーニングの概要
はい、皆さんこんにちは。音声は聞こえていますでしょうか。モデルのトレーニングや推論をどのように行うのか気になっているかもしれませんね。本日は、AWSで Foundation Modelをトレーニングする方法についてお話しさせていただきます。
まず、モデルの複雑さとパラメータ数が年々どのように進化してきたかを見ていきます。そして、AWS Generative AIスタックがどのような構成になっているのか、どのようなツールやサービスが利用可能なのかについて説明します。その後、トレーニングのオーケストレーションの方法とサービスのリファレンスアーキテクチャについて説明します。最後に、NinjaTech AIの事例を通じて、AWS Trainiumを活用したトレーニングについてご紹介します。
機械学習モデルの進化とAWS Generative AIスタック
機械学習の大規模化は1957年のPerceptronモデルから始まり、6,200万パラメータを持つAlexNetへと進化してきました。複雑な問題をより良く理解し、複数のタスクを同時に処理するため、パラメータ数は指数関数的に増加し続けています。そのため、2024年現在では数兆のパラメータを持つモデルが登場しており、私たちの周りの世界をより良く理解しようとする中で、この成長は今後も続いていくでしょう。
これらのモデルをトレーニングするには、ペタフロップス単位で測定される非常に高い計算能力が必要です。2017年の時点では約1万ペタフロップスでしたが、モデルの複雑さが増すにつれて、この需要は増加し続けています。例えば、GPT-4のトレーニングには数千億ペタフロップスが必要で、これらのモデルのトレーニングには数日から数ヶ月かかることもあります。
AWS Generative AIスタックは、インフラストラクチャから始まります。これにはGPU、Trainium、そして推論用のAmazon SageMakerクラスターが含まれます。ネットワーキングにはEFAを使用し、トレーニング用のキャパシティを確保し必要のない時に解放するためのAmazon EC2 Capacity Blocks、そしてNitroインフラストラクチャを使用します。その上に、推論のユースケースの構築と解決を容易にするAmazon Bedrockなどの追加レイヤーを構築します。アプリケーション層には、Amazon Q Business、Amazon Q Developer、そしてコンテンツから自動的にインサイトを抽出するQuickSightのQが含まれています。
本日は主にインフラストラクチャに焦点を当て、特にGPUトレーニングとシステム全体の仕組みについてお話しします。これは、お客様のモデルトレーニングの実態と使用されているツールを観察した結果を反映したものです。まずは、AWSで利用可能なアクセラレーテッドコンピューティングスタックとインスタンスについて見ていきましょう。数年前、私たちはNVIDIA A100 GPUを搭載したP4d およびP4deインスタンスをリリースしました。昨年はP5をリリースし、今年はNVIDIA H100およびH200 GPUを搭載したP5eを導入しました。また、第2世代EFAも導入し、機械学習トレーニングワークロードのスループットとレイテンシーを大幅に改善しています。
AWSは推論用にも様々なGPUインフラストラクチャオプションを提供しています。G5インスタンス、G6インスタンス、より大きなモデルに対応する大容量メモリを搭載したG6eインスタンスなどがあります。また、より優れたコストパフォーマンスを実現するInferentia 1および第2世代のInferentia 2も提供しています。これらのコンポーネントはすべてUltraClustersを通じて統合されています。 UltraClustersは、機械学習インフラストラクチャに前例のないスケールを提供するペタビット規模のファブリックネットワークです。これは、GPUのトレーニングとインフラストラクチャのセットアップに特化したペタバイト規模のファブリックネットワークインフラストラクチャです。
トレーニングに関して、第2世代UltraClustersは第2世代EFAにより16倍優れたスケーリングと低レイテンシーを実現しています。このファブリックでのホップ数を削減することで、EFA、Nitro、そして再設計されたネットワークアーキテクチャによって、非常に一貫したレイテンシーを確保しています。
クラスターはFSx for Lustreと緊密に統合されており、データの読み取り、出力の保存、モデルのチェックポイントに高速ストレージとして機能します。モデルトレーニングには相当な時間がかかるためです。時には対処が必要な障害が発生することもあり、トレーニングを再開できるよう定期的にデータを保存することが重要になります。良い例としては、Metaのトレーニングに54日を要したLLaMA 3、4、5があります。彼らが経験した中断回数を見ると、平均して3時間ごとに中断が発生していました。そのため、大規模なクラスターとコンポーネントでのトレーニングは課題が多く、オーケストレーション、障害への対処、モデルのトレーニング、必要なサービスについての問題が浮上します。
Amazon SageMaker HyperPodによる大規模分散トレーニングの実現
では、Ankurに引き継ぎたいと思います。 私たちは、Self-managedと呼ばれる大規模分散トレーニングと推論を必要とするお客様をサポートするチームに所属しています。SageMakerのような完全マネージド型サービスプラットフォームを使用せず、EC2、S3、FSx for Lustreなどのコアサービスを使用してインフラストラクチャのライフサイクルを作成・管理する上でより多くのコントロールを必要とするお客様向けのチームです。私たちは、Kubernetesに精通しているお客様にはAmazon EKS、Slurmに詳しいお客様にはAWS ParallelCluster、そしてAWS Batchを使用してトレーニングをオーケストレーションするお手伝いをしてきました。これら3つの異なるオプションは、過去4～5年間で数多くのお客様の課題解決に役立ち、大規模インフラストラクチャを構築する際のお客様のニーズについて貴重な教訓を得ることができました。
クラスター作成時における主要なお客様の課題をご紹介します。大規模クラスターのプロビジョニングと管理は、それ自体が困難な作業ですが、そのライフサイクル管理となるとさらに複雑です。通常、お客様はAvailability Zone内で16台や60台のP5インスタンスなどの容量予約を受け入れます。VPCやクラスターの適切なセットアップに必要な正しいスクリプトがない場合、分散トレーニングや分散ワークロードを効率的に実行できる環境を整えるまでに数週間、場合によっては1ヶ月もの時間を失うことがあります。ネットワークの問題やストレージの問題が不可解なエラーとして現れ、パフォーマンスのデバッグに多大な時間がかかることもあります。そのため、クラスターのプロビジョニングと管理は非常に重要であり、私たちは数回のクリックで実装できる使用準備の整ったスクリプトを一箇所に集約することで、これを民主化する取り組みに力を入れてきました。必要なものはすべて一箇所に用意されており、数回のクリックで、パブリックサブネット、プライベートサブネット、S3バケット、FSx for Lustre、そして同一スパイン上のすべてのコンピュートノードを作成し、数分でクラスターを使用可能な状態にすることができます。
次にお客様が抱えていた課題は、インフラストラクチャの安定性についてです。数千個のGPUにまたがる分散トレーニングワークロードを実行する際、どのノード上の1つのGPUが故障しても、トレーニング全体が停止してしまいます。問題の特定に時間とコストがかかり、その原因がソフトウェア起因なのか、ドライバーバージョンの問題なのか、あるいはハードウェアの問題なのかを突き止める必要があります。
私たちは、GPUの故障に対して耐性のあるインフラストラクチャの開発に注力してきました。MaximeがLAMA論文で言及したように、故障の大部分はGPUの故障に起因していました。非常に大規模な環境で作業する場合、故障が発生した際にはそのノードをクラスターから自動的に除外し、正常なノードのセットから代替ノードを補充し、最後のチェックポイントから自動的にトレーニングを再開できるインフラストラクチャが必要です。最後に、分散トレーニングのパフォーマンスについて、Solution Architectとして最もよく受ける質問の1つは、オンプレミスでは問題なく動作するトレーニングがAWS上で実行すると性能の問題に直面するというものです。お客様は、最適なパフォーマンスを得るためのEFA Pluginの環境変数の適切な設定について質問されます。
私たちは、P4dやP5インスタンス、そして最新のP5eインスタンスでパフォーマンステストを済ませた、すぐに使用できるレシピとDockerfileを作成しました。これらはトレーニングジョブにすぐに活用できます。クラスターのプロビジョニングと管理、インフラストラクチャの安定性、そして分散トレーニングのパフォーマンス、これらが私たちがAmazon SageMaker HyperPodというサービスを作成する際に改善を重ねた3つの重要な柱でした。 HyperPodのアーキテクチャについて詳しく説明する他のセッションもありますが、これらが主要なポイントです。
HyperPodの利用方法はシンプルです。試してみたい場合は、アカウントチームに連絡し、来週までに必要なP5ノードの数とAvailability Zoneを指定します。その後、1時間のオンボーディングセッションを設定します。オンボーディングセッションまでに、容量予約を受け入れ、課金が開始されます。セッションの最初の30分で、クラスターの作成についてのワークショップをご案内し、残りの30分でトレーニングワークロードを実行できるようになります。最初の1時間で、ネットワーク、ストレージ、その他すべての設定が正しく行われた状態で、リクエストしたすべてのP5ノードを使用できるようになります。
様々なシナリオに対応したスクリプトを提供しています。Slurmに不慣れな方のために、Nemo、PyTorch、MosaicML、TensorFlow、JAXなど、人気の分散学習フレームワーク用のスクリプトを用意しています。HyperPodでの耐障害性については、ジョブの自動再開用のフラグがあります。皆さんが気をつける必要があるのは、適切な頻度でチェックポイントを保存することだけです。特定のジョブを自動再開させたい場合は、auto-resumeフラグを使用するだけです。
この機能は、HyperPodサービスを通じて動作し、全ノードの全GPUに対して継続的なヘルスチェックを実行します。不具合のあるGPUを検出すると、そのノードはクラスターから削除され、予備セットから健全なノードが追加されます。このプロセスが完了すると、FSx for Lustreに保存された最後のチェックポイントからジョブが自動的に再開されます。これがHyperPodの自己修復クラスターと耐障害性機能の実例です。
使いやすさと柔軟性を重視し、Slurmやそれに類似したシステムを使用してオンプレミスのクラスターで実行できるものは、一部のエッジケースを除いて、HyperPodでも実行できるはずです。完全なSSHアクセスを備えたマネージドEKSクラスターを提供しています。例えば、EKSクラスターを使用する場合、コンテナを作成してポートを実行し、そのポートに接続する必要があるため、コンピュートノードへのSSH接続が面倒になることがあります。しかし、私たちはノードへの直接的なSSHアクセスを提供しているため、EKSで作業する際にコンピュートノードにSSHで接続するのが1行のコマンドで済み、トレーニング環境のカスタマイズも柔軟に行えます。
もう1つ注意点として、HyperPodを使用したEKSクラスターやParallelClusterでは、EKSを使用するノードはEC2コンピュートに表示されます。これらはサービスアカウントに属しているため、ノードはお客様のアカウントには表示されません。ノードの確認は、他のクラスターの詳細と共にHyperPodコンソールで行う必要があります。
私たちは通常、2種類のユーザーと協力しています。1つは、単にジョブを投入し、クラスターのメンテナンスに責任を持たないエンジニアや研究者、もう1つは、データサイエンティストや研究者のためにクラスターの作成と管理を担当するインフラストラクチャーチームです。オンボーディングセッションでは、通常、お客様の管理運用チームからクラスターを作成する担当者が必要です。アーキテクチャには、p4d.24xlargeなどのインスタンスタイプのコンピュートノード、ヘッドノード、ログインノードが含まれます。ヘッドノードは、トレーニングジョブの投入やノードの管理など、クラスター上で何でも実行できます。エンジニアやデータサイエンティストのアクセスをジョブの実行のみに制限したい場合は、ログインノードの概念を使用して、単にログインしてジョブを投入し、ログアウトするだけの環境を提供できます。
このアーキテクチャはマルチユーザーアクセスに対応するよう設計されており、複数のユーザーとプロジェクトのためのクラスターを簡単にセットアップすることができます。データのバックボーンはお客様のアカウント内のAmazon S3に置かれ、FSx for Lustreも同様にお客様のアカウントに自動的に作成されます。お客様のアカウント内のこれらのコンポーネントは、VPCピアリングを介してサービスアカウントのノードと通信します。可観測性については、EC2からデータを収集する多数のPrometheusクライアントがあり、Amazon Managed Grafanaがそのデータを使用してダッシュボードを表示できます。また、AWS IAM Identity Centerとも統合されています。
これらの機能に加えて、これが典型的なアーキテクチャとなります。ここで重要な違いの一つは、分散トレーニングにあまり詳しくない方のために説明すると、分散トレーニングでは全てのノードが同一のサブネット内にある必要があるということです。異なる設定で複数のノードを持つことができる構成をご存知かもしれませんが、最高のパフォーマンスでの分散トレーニングには、ノードが同一のサブネットだけでなく、同一のスパイン上にある必要があります。これはHyperPodで提供している機能です。このアーキテクチャにおけるHyperPodの主な利点は、最初の30分以内にクラスターを立ち上げて実行できることです。次の30分で分散トレーニングジョブを実行でき、全てのノードが動作していることを確認できます。次のステップは、S3バケットから作成されたFSx for Lustreへのデータマッピングを確認し、トレーニングジョブを実行するためのSlurmスクリプトを編集するだけです。
私たちがお客様と一緒に進めるオンボーディングセッションでは、分散トレーニングジョブを実行する際に、コンピュートノード、FSx for Lustre、そしてEFAからのリアルタイムメトリクスを確認できることをお示ししています。これらのダッシュボードを作成できますし、ワークショップではAmazon Managed Grafanaのセットアップとダッシュボードの設定を行うための簡単な手順をご用意しています。このダッシュボードは、P5.48 XLargeの非常に大規模なクラスター、合計1967ノードを示しています。このノードにはいくつかのエラーがあり、GPUで発生しているエラーの数を示す4つの行があります。黄色の部分には、Xエラー、サーマルエラー、そしてGPUの欠落も表示されています。これらのノードについて確認できる情報は多岐にわたり、これらのダッシュボードをカスタマイズすることもできます。私たちは各チームと緊密に連携しているので、カスタマイズが必要な場合は対応可能です。
NinjaTech AIのAIエージェント開発：AWSインフラの活用事例
では、NinjaTech社のお客様をご紹介します。 私はBabak Pahlavanと申します。NinjaTech AIのCEOであり創業者です。NinjaTech AIをご存知の方もいらっしゃるかもしれませんが、おそらく大多数の方はご存じないでしょう。どなたかご存知の方はいらっしゃいますか？お一人ですか？素晴らしい、人気があるようですね。何人かの方がいらっしゃいますね。
私たちは、無制限の生産性を実現する総合的なAIエージェントを提供しています。GenAIのNetflixと考えていただければと思います。基本的に、私たちのミッションは、世界最高のAIモデルとAIエージェントへのアクセスを、月額5ドルからという価格で民主化することです。 私たちは皆、OpenAI、Microsoft、Googleが提供する主力製品をよく知っています。Netflixのアナロジーを続けるなら、これらは大作映画のようなものです。これらすべてに対する入場料は20ドルです。そして、Midjourney、開発者向けのRed Plate、Leonardo、その他のソリューションなど、垂直特化型のアプリケーションがあります - これらはそれぞれお金がかかります。これらは単純明快ではなく、すべてを一度に必要としない場合もあります。時にはOpenAIを使いたい場合もあれば、Claudeを使いたい場合もあり、Geminiモデルを使いたい場合もあります。ここで私たちの出番となります。私たちのサービスでは、オールインワンで、1つのサブスクリプション料金で、通信会社のような合理的な範囲内で、すべてのAIモデルへの無制限アクセスが可能です。さらに、エージェント型の様々なAIスキルへのアクセスも提供しています。
私たちは通信事業者のように、このアクセスをシンプルな方法で提供しています。生産性と使いやすさに重点を置いています。 システムの仕組みについて簡単に説明させていただきます。これはシステムの動作を抽象化して表したものです。プロンプトが入力されると意図を分析し、認識した意図のタイプに基づいて適切なAgentやシステムを起動して質問に答える、高度なオーケストレーションエンジンだと考えてください。
これは、モデルがすべてを処理することを想定している基盤モデル企業とは少し異なります。彼らも様々なサービスに接続する必要がありますが、私たちのシステムは完全にAgent型で、起動されるものに応じて、内部モデルの1つを使用します。コアモデルはLlama 3.1.405Bをベースにしており、他にもいくつかのモデルを組み合わせています。Nemoは批評モデルで、インフラ内部ではPixArt Sigmaなども使用しています。システムは次世代のエージェント型複合AIシステムであるSuperAgentを起動したり、Gemini、Sonnet、Haikuなどの他のモデルと回答を比較したりします。
では、1分間のデモ動画をご覧いただき、この魔法のような仕組みについて説明させていただきます。 試してみましょう。はい、音声は聞こえていますでしょうか？ 現在AWSやAmazonの従業員の方は、aws.MyNinja.aiにアクセスできます。その他の方々はMyNinja.aiで今すぐ製品をご利用いただけます。ご紹介した機能はすべて実際に稼働しており、ご利用可能です。
Generative AIの世界を探求されている方々には、AWSのGenerative AIコンポーネントとそのサポートコンポーネントをお勧めします。スタートアップである私たちにとって、これは本当に救いの手となりました。他のクラウドプロバイダーも試してみましたが。そうそう、Maximeさん、これを言うために報酬をもらっているわけではないことを確認していただけますか？私は有償の講演者ではありませんよね？ はい。
AWSのおかげで私たちの会社は機能しています - AWSがなければ、私たちがやっていることはすべて費用面で実現不可能でした。トレーニング部分からサービング部分、ログ分析、重みの保存方法、顧客データの保存方法まで、システムのあらゆる層が相互に接続され、非常に手頃な価格で提供されています。 AWSがこの分野により多くを展開し始めた時から、私たちは非常に幸運でした。トレーニングの方法と仕組みについて簡単に説明させていただきます。このオーケストレーションシステム全体を実現する方法は、おおよそ6段階のプロセスです。ステップ1は問題を解決するためのトレーニング計画を作成することです。例えば、AIの部分を解決したい場合、それがコーディングの質問なのか、ブレインストーミングの質問なのか、文章作成なのか、画像なのかを判断しようとします。
6ステップのプロセスは以下のように続きます。近々、他のスキルに関する動画と音声も用意する予定です。まず最初に、モデルが実際のプランをどのように立てるかを判断するための計画を立てます。次に、コード生成を行います。Ninjaのテクノロジーは、すべてコード生成に基づいています。私たちは、立てられた計画に基づいてPythonコードを効果的に生成します。
ステップ3では、同様のコードを作成し、実行の検証を行います。生成したコードが実際に動作することを確認したいのです。これらのステップを実現するために、AWS LambdaとAmazon SageMakerを積極的に活用しています。ステップ4では、コードが実行可能であることを確認した上で、意図した機能を実行できるかどうかの検証を行います。ステップ5では、この機能を実現するための適切なコードの部分、適切なバージョンを選択します。ステップ4の結果が最も正確で、達成したい目標に最も近いものから、品質の高いものを選び、それらの検証済みサンプルをストリームに保存します。
Amazon DynamoDBでのユーザーデータ提供と組み合わせて、リアルタイムでのファインチューニングの一連のラウンドを実施します。これにより、Ninjaを使用する際には、バックグラウンドでコードを生成して、アーキテクチャ全体で行われる大規模なオーケストレーションの実行方法を把握します。このシステムは事前にプログラムされているわけではありません。私たちは、適切なステップと適切なエージェントのリアルタイムでのアクティベーションを判断するために、コード生成に依存しているのです。これが私たちが作り上げたプロセス全体です。システムが、様々なStep Functionを考え出すのではなく、シンプルな方法で動作するように、このプロセスを何度も繰り返しています。
これは、これまでに見たことのないアーキテクチャです。他の企業も同様のことを行っているとは思いますが、私たちにとっては、AIモデルを使用してリアルタイムで判断を下し、適切なツールをアクティベートする方法をついに見出すことができました。ツーリング機能を備えたエージェントアーキテクチャについて耳にする機会が増えていますが、これが私たちのソリューションでした。言語モデルの多くがツーリングを可能にすると言われていますが、リアルタイムでコーディングを行い、適切なエージェントをアクティベートするためのコーディングを自身で行えるように教えるまでは、思っていた以上に難しいものでした。研究室では機能しましたが、問題を解決するために自らコーディングする方法を教えるまでは、本番品質には達しませんでした。
AWSのコンポーネントは、あらゆる場所で積極的に使用されています。皆さんもおそらくAmazon CloudWatchを使用されていると思いますが、使用されていない場合は使うべきです。これにより、トレーニングセットとトレーニンググループに関する各ステップの機能について洞察が得られます。実際、私がステージに上がる直前にも、チームがデプロイメントプロセスの問題をデバッグしており、CloudWatchが中心的な役割を果たしていました。CloudWatchは、システム全体にわたって素晴らしい洞察を提供してくれます。AWSのインフラを使用している場合は、必ず使用する必要があります。Amazon DynamoDBは驚くほど高速で、NoSQLベースであり、DynamoDBの速度により、今後のパーソナライゼーションが可能になります。近い将来、システムが各ユーザーに提供する結果が少しずつ異なるようになりますが、これはユーザーのプロンプトをDynamoDBに保存しているからこそ可能なのです。今後パーソナライゼーションを進めていく上で、この速度が非常に重要になります。
Amazon SageMakerは一連のイベントの究極のオーケストレーターであり、私たちは強くお勧めしています。より高度なトレーニングジョブが必要な場合は、SageMakerとHyperPodを強くお勧めします。そして、重みを作成した後、それを保存する方法があります - 安価で超高速で、いつでもデプロイできます。 私たちはこれらすべてを実行し、オーケストレーションの一部として、Agentic Compound AIというコンセプトを生み出すことができました。
実質的に、精度と品質を向上させるために、様々なAIモデルをどのように活用するかということです。皆さんが最初にこれを見る方々です。まだ公開もしていません - 今週中にブログ記事として公開される予定です。真のスタートアップらしく、私たちは週末も働いており、この週末にベンチマークが出揃いました。間もなくそのスニークピークをお見せします。
私たちのSuperAgentには3つのバージョンがあります。Turboは自社でホストしているモデルを使用し、405Bが主力モデルで、さらにCritique Agentも使用しています。Nexusは中規模のSuperAgentで、外部の中規模モデルと私たちの405Bを使用します。Apexが最上位モデルで、GPT-4、Sonnet、Gemini Proを活用しています。また、相乗効果を生み出すために、SonnetをCritiqueモデルとしても使用しています。これこそが私たちが求めていたもので、正しい方程式を見つけることができました。
最近、私たちの取り組みを裏付けるような文献が多く出ています。しかし、私たちは論文を発表するだけでなく、実際にそれを構築しました。これは製品として実際に稼働しています - myninja.aiにアクセスして、製品を使用して試すことができます。コーディングや文章作成の質問に対して、SuperAgentが有効で、Ultra tierで利用可能なApexを使用している場合、3つのバージョンすべてにアクセスできます。Proユーザーは NexusとTurboにアクセスでき、Standardユーザーは Turboのみを使用できます。例えば、Apexは GPT-4、Sonnet、Gemini Proという3つの主力モデルから候補となる回答を得ます。その後、405BとSonnetで批評のラウンドを行い、それらすべてを読み込んで、改善された回答を導き出します。
明日か明後日にはより大規模なベンチマークセットを共有する予定ですが、これは準備ができたので今すぐ共有させていただきます。Arena Hard - ご存知の方がどれくらいいるかわかりませんが - これはチャットボットの品質を評価する500の難しいプロンプト質問のリストです。最高水準はOpenAIの01-miniによって達成されました。ご存知の通り、これは推論モデルです。彼らがこれをリリースした時は本当に素晴らしい成果を上げました。というのも、Sonnetが最高水準だったのですが、01-miniは92点を記録したのです。先週現在、私たちのSuperAgent Apexは、この公開ベンチマークにおいて最高水準を達成しており、これから提出する予定です。そしてこれはすべて検証可能です。
素晴らしいのは、94.3という最先端の性能を達成しているだけでなく、そのために生成するトークン数の平均を見てください。ご存知かもしれませんが、推論モデルは大量のトークンを生成するため、経済的に非常にコストがかかり、また非常に遅いものです。しかしSuperAgentのアプローチを使用すると、アクセスの民主化という私たちのミッションに沿って非常に手頃な価格であるだけでなく、比較的高速で、回答を得るのに何分も待つ必要がありません。コーディング、推論、数学の分野全般にわたって、SuperAgentが実際に非常に素晴らしいものであることが分かってきており、今週末にはこれについてさらに詳しくお話しできる予定です。
本質的には、オーケストレーターを生成する機能と、AWSインフラストラクチャを使用して独自のモデルをファインチューニングできる能力に関するものです。これはもう一つの興味深いベンチマークです。「Misguided Attentions」と呼ばれる13の質問リストがあります。「イチゴには何時間あるか？」や「9.11と9.9ではどちらが大きいか？」といった、LLMをよく混乱させる質問をご存知ですか？ほとんどのLLMは単に9.11と答えてしまいます。これらの質問に対して、私たちのUltraティアのApexは、すでにGPT-4、Sonnet、Llama 405B、さらにはGemini 1.5 Proよりも高いスコアを記録しています。これは私たちが誇りに思うブレークスルーですが、本質的にはAWSが提供するインフラストラクチャによって可能になったものです。これが、実際に試してみた場合の簡単な概要です。
Amazon AWSの従業員の方は左側のバーコードを、一般の方は右側のバーコードを使用して、ぜひ試してみてください。SuperAgentはまだ1週間しか経っておらず、現在まさにローリングアウトしているところです。お願いしたいのは、製品を使用する際にフィードバックを提供し、より良いものにするためにご協力いただくことだけです。
分散ワークロード実行のためのAWSリソースとベストプラクティス
ここでCall to Actionに注目していただきたいと思います。最初に、様々なサービスを通じてインフラストラクチャを構築する方法について話しましたが、分散ワークロードとそのAWS上での実行方法に興味がある方は、Awesome Distributor Training Repoというリポジトリがあります。これは素晴らしいリソースです。VPCの作成方法、HyperPod、Paddle Cluster、Amazon EKS、AWS Batch、その他必要なアーキテクチャの作成方法について、ステップバイステップのガイドラインを提供しています。クラスターを作成する方法があれば、このリポジトリを参照してください。
AWS最適化Dockerfileをカスタマイズする方法もあります。通常、AWS最適化Dockerfileを見て、その末尾に自分のものを追加し、そのコンテナをP4dやP5マシンで使用するだけです。EFAチートシートもあり、これらのワークロードを実行する際に発生する一般的なエラーや問題について説明し、それらのエラーを解消するための環境変数を提供しています。また、異なるタスクを実行するためのサンプルSlurmスクリプトを含むレシピもあります。例えば、MosaicMLを使用してStable Diffusionを実行する方法を知りたい場合は、そのための例があります。Nemoを実行したい場合も、同様に例があります。
PyTorch ライブラリやその他のオープンソースフレームワークを使用した分散学習の設定方法については、ここにあらゆる例が用意されています。Slurm 内でのコンテナの実行に関する詳細については、NVIDIA Enroot と Pyxis を使用しており、それらの例も用意されています。Nemo、MosaicML、そして DDP や FSDP を使用したさまざまな並列化手法について、豊富なコンテンツを提供しています。NCCL テストは、クラスターのネットワーク設定が正しく行われているかを確認する一般的な方法であり、そのためのリソースも用意されています。可観測性については、先ほどお見せした Prometheus-Grafana ダッシュボード用に、Slurm や EKS クラスター上でスクレイパーを設定する方法を示すスクリプトがすべて用意されています。
最後に、プロファイリングについては、Nsight に関する素晴らしいセッションを用意しています。Nsight のインストール方法、Slurm クラスターや Kubernetes クラスター上でレポートを生成する方法、そしてそのレポートを理解する方法について説明しています。Nsight に関する別のセッションが明日と木曜日にありますので、パフォーマンスに関する詳細なトレーニングにご興味がある方は、ぜひご参加ください。以上で私の発表を終わります。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion