re:Invent 2024: SageMaker HyperPodで実現する高性能分散モデルトレーニング
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - High performance distributed model training with Amazon SageMaker (AIM380)
この動画では、Amazon SageMaker HyperPodにおけるDistributed Trainingについて解説しています。Foundational Modelのトレーニングに必要な計算量が6ヶ月ごとに倍増している現状を踏まえ、SageMaker HyperPod Recipesという新機能を紹介しています。この機能により、Llama 3.1などの人気モデルのトレーニングとファインチューニングを1行のコードで開始できるようになりました。Salesforceでの実例として、AgentForceやRAGforce、SFR-LlamaRankなど、HyperPodを活用して開発された具体的なモデルの事例も紹介されており、企業における大規模言語モデルの実践的な活用方法が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon SageMaker HyperPodの紹介と登壇者の自己紹介
勇敢な聴衆の皆様、昨夜の後にもかかわらず、朝早く8時30分からお集まりいただき、ありがとうございます。本日はご参加いただき、感謝申し上げます。今日は、Amazon SageMakerにおけるDistributed Trainingについてお話しさせていただきます。私はSageMaker HyperPodチームのSenior Product Managerを務めております。同僚たちと一緒に、そして特別なパートナーもお迎えしています。では、Sanjayをご紹介させていただきます。
皆さん、こんにちは。Sanjay Dorairajと申します。Amazon SageMakerのSoftware Development Managerを務めております。本日は、私たちが新しくローンチするHyperPod Recipesという機能についてお話しできることを大変嬉しく思います。それでは、特別ゲストをご紹介します。
皆様、こんにちは。Antonio Ginartと申します。SalesforceでGenerative AIの研究に携わるAI Scientistとして、SageMakerを使用し、彼らと協力してきました。SalesforceでSageMakerを使って実現したことについて、皆様にお話しできることを大変楽しみにしています。
Foundational Modelの進化と分散トレーニングの課題
ありがとうございます、AntonioとSanjay。それでは、早速本題に入らせていただきます。 皆様がなぜここにいらっしゃるのか、このチャートからお話を始めたいと思います。これはStanford AI Reportを執筆し、Foundational Modelの分野における発展を追跡している非営利組織、Epoch AIのデータです。2010年から現在に至るまでのデータを見ると、Foundational Modelのトレーニングに必要な計算量は年間4〜5倍のペースで増加しています。つまり、6ヶ月ごとに計算量が倍増しているということです。2010年のPetaFLOPSから、今日では数千YottaFLOPSにまで達しています。
この計算要件の爆発的な増加に伴い、これらのモデルが使用するデータ量もおよそ8ヶ月ごとに倍増しています。トレーニングデータ量がこのような急速なペースで増加しているため、無限スケールのデータが今後も拡大し続けるのか、それとも最終的にデータが枯渇してしまうのかという懸念さえ出てきています。 このように、モデルは大規模化し、データ量も増加し、その結果として、Time to Marketも増加することになります。私たちが観察しているところでは、これは年々増加傾向にあります。
これらの進展により、Foundational Modelのトレーニングにおいて独特の課題が生まれています。これらのモデルは、GPUなどの数千台のアクセラレーテッドデバイスにまたがって展開されており、インフラを効率的かつ容易に管理することは、お客様にとって大きな課題となっています。これは私たちが代わりに対処したい重要な作業です。2つ目の課題はインフラの安定性です。これらのワークロードの分散トレーニングでは、複数のデバイスが相互に通信を行い、GPUの故障やハードウェアの故障などが発生するため、トレーニングに安定性と回復力のあるインフラが必要です。最後に、これらのモデルの規模とトレーニング時間を考えると、データの規模とモデルのサイズによって数日から数ヶ月かかるワークロードとなるため、トレーニングワークロードのパフォーマンスを可能な限り最大限に引き出したいところです。
そこで私たちは Amazon SageMaker HyperPod を開発しました。 昨年のre:Inventで発表したHyperPodは、数千台のアクセラレーテッドデバイスにわたってトレーニングワークロードを効率的にスケールすることを可能にします。HyperPodはスケールを考慮して設計されており、回復力のあるトレーニング環境を提供し、モデルトレーニングを最大40%加速させ、クラスター環境の詳細な制御を可能にする高度な可観測性ツールを提供します。 HyperPodは、Luma AIやArticul8のようなスタートアップから、Salesforceのような大企業まで、様々なお客様にご利用いただいています。後ほど、Antonioが HyperPodでの経験についてお話しする予定です。
分散トレーニングスタックの最適化とHyperPod Recipesの概要
ここで一歩下がって、分散トレーニングスタックの最適化について考えてみましょう。このダイアグラムは、一般的なオープンソースで構築された分散トレーニングスタックの内訳を示しています。最下層には、デバイスがあります。これは基本的にGPUやTrainiumベースのデバイスなどのアクセラレーテッドデバイスです。デバイスと共に、デバイスのカーネルドライバーがあります。その上にはNCCLなど、NVIDIAの通信レイヤーがあります。
スタックを上に進むと、これらのデバイスすべてを、理想的には同じラックとスパイン上で接続する必要があり、現在のモデルトレーニング状態に関する情報を交換する際に、これらのデバイス間で効率的な通信が必要になります。ここで、ネットワークとハードウェアプログラミングが、これらのアクセラレーターデバイスが効率的に相互通信し、情報を交換・共有できるようにします。その上には、より馴染みがあるかもしれないPyTorch、NeMo、Megatronなどの分散トレーニングフレームワークがあり、トレーニングループをどこでどの程度詳細に制御したいかに応じて、異なる抽象化レベルでモデルトレーニングループを簡単に実行できます。
私たちはこれを見て、 トレーニングスタックを最適化する方法を考えました。現時点で2つの重要な最適化を提供しています：トレーニングライブラリを強化したPyTorchのフォークであるSageMaker Model Parallelismと、re:Inventで発表したHyperPod Recipesです。SageMaker Model Parallelism Libraryは、本質的に一連の組み合わせ可能な トレーニング技術を提供するPyTorchフォークです。これらのオープンソースフレームワークの発展を考えると、例えばNeMo Megatronのベストインクラスのテンソル並列処理を、PyTorch FSDPのワークロードで使用したい場合があります。しかし、そのためには異なるフレームワーク間でこれらのコンポーネントを手動で統合する必要があり、これは差別化されたモデルトレーニングやデータに焦点を当てていないため、不要な重労働となってしまいます。
SageMaker Model Parallelismを使用すると、手動での統合作業なしでPyTorch FSDPと組み合わせ可能なTensor Parallelismを利用できます。また、LLAMAモデルで128Kのコンテキスト長をサポートするContext Parallelismの機能も提供しています。さらにFP8トレーニングも可能で、PyTorch分散トレーニングの基本機能を使いながら、異なるフレームワーク間で最高クラスの機能を自由に選択して組み合わせることができます。
このパッケージの一部として実装した最適化の1つに、非同期チェックポイントがあります。トレーニングワークロードにおいてなぜチェックポイントが必要なのか説明させていただきます。チェックポイントの目的は、モデルの状態を定期的に保存することです。モデルが非常に大きいため、通常1つのGPUには収まりきらず、複数のGPUやアクセラレータデバイスにモデルを分割し、最適化の状態も異なるアクセラレータデバイスに分散させる必要があります。GPUの故障やソフトウェアの不具合でトレーニングが失敗した場合、最初からやり直すのではなく、最後の安全なチェックポイントから再開したいものです。
理想的には、できるだけ頻繁にチェックポイントを取りたいところですが、何千ものデバイスで頻繁にチェックポイントを取ると、GPUが待機状態となり貴重な計算リソースが無駄になってしまうというトレードオフがあります。そこで、チェックポイントを最適化してトレーニングを高速化する方法が課題となります。私たちは、GPUがトレーニングを実行している間に、別のワーカーがAmazon S3にチェックポイントを書き込む非同期チェックポイントを構築しました。また、よりスマートなメタデータキャッシングシステムによる最適化も行っており、このチェックポイント機能はPyTorch NativeのDCPと直接互換性があり、追加のコード変更は必要ありません。
Composable Parallelismから高度なチェックポイント機能まで、これらすべての最適化により、モデルトレーニングのパフォーマンスを最大限に引き出すことができます。フレームワークの各層について説明してきましたが、SageMaker Model Parallel Libraryは、並列化技術やチェックポイントなどの機能といった基本的な構成要素の最適化を支援します。とはいえ、私たちはそこで満足せず、最も人気のある基盤モデルを使用した大規模トレーニングワークロードの実行における複雑さを抽象化する方法について検討を始めました。
今回のre:Inventで、Amazon SageMaker HyperPod Recipesを発表しました。これにより、お客様がLlama 3.1のような一般に公開されている大規模モデルを非常に簡単にトレーニングできるようになります。ここでRecipesについて詳しく説明するため、Sanjayを壇上にお招きしたいと思います。
HyperPod Recipesの詳細と使用方法
私の名前は Sanjay Dorairaj で、SageMaker HyperPod Recipes チームをリードしています。本日は HyperPod Recipes のローンチについてお話しできることを嬉しく思います。これは、特に SageMaker HyperPod 上で Large Language Model の事前学習やファインチューニングを行いたいと考えているお客様にとって、画期的なソリューションだと考えています。事前学習とファインチューニングを始めるまでの時間を数分にまで短縮することができます。 私たちの主な目標は、皆様が事前学習とファインチューニングにほぼ即座に着手できるようにすることです。そこに HyperPod Recipes の真価があると考えています。
始める前に、皆様のことをよりよく理解するために、簡単な挙手をお願いしたいと思います。 現在、LLM の事前学習とファインチューニングを行っている方は何人いらっしゃいますか？ なるほど、何人かいらっしゃいますね。SageMaker のインフラを使って事前学習とファインチューニングを行っている方は？ほぼ同じ数ですね。 では、これから6ヶ月以内に LLM のトレーニングやファインチューニングを始める予定の方は？素晴らしい、かなり多くの方、ほぼ全員ですね。 今日は HyperPod Recipes が皆様にどのようなメリットをもたらすかについて、もう少し詳しくお話ししていきたいと思います。
SageMaker HyperPod は、大規模な分散トレーニングとファインチューニングに最適化された AWS が提供するインフラストラクチャです。お客様が高性能で高い耐障害性を持つトレーニングインフラを確実に利用できるよう、障害からの自動復旧などの強力な機能を備えています。このような最適化されたインフラを提供する一方で、Machine Learning の開発者や研究者である皆様が実際にどのようにトレーニングを開始するかという課題が残っています。 例えば、最初にすべきことは、使用したいモデルを見つけて決定することです。その後、NeMo や PyTorch、あるいはその組み合わせなど、適切なフレームワークを選択するのに何時間も、時には何日もかかることがあります。そして、適切なモデル設定を確保するためにパラメータの最適化に多くの時間を費やします。 そしてようやく、トレーニングとファインチューニングを開始できるのです。
これは非常に手間のかかる作業であり、多くの企業がここで苦労しています。 これらの設定の中には、セットアップに数日から数週間かかる複雑なものもあります。時にはこれらの課題のために、基盤モデルのトレーニングとファインチューニングを諦めてしまう企業もあります。状況を把握していただくために、 Large Language Model の事前学習やファインチューニングについて言えば、70以上の事前学習パラメータと100以上のファインチューニングパラメータを設定する必要があります。 組み合わせを考えると、最適なモデル設定を見つけるために実行する可能性のある組み合わせは数千にも及び、各パラメータの選択が他のパラメータにも影響を与える可能性があります。
もう一つの問題は、新しいモデルが常に追加され続けているということです。 これらのパラメータを確立するのに時間がかかりすぎて、気がつけば別のモデルに切り替えることになり、常に次の最適なモデルを追いかけることになってしまい、実際の事前学習とファインチューニングに着手できないという状況に陥ります。これも、事前学習とファインチューニングに取り組むチームの育成を諦めてしまう企業がある理由の一つだと、お客様から伺っています。 デフォルトの選択が最適でない場合、コストの超過や納期の遅れ、生産性の低下につながる可能性があります。おそらく、皆様の中にもこのような問題に直面している方がいらっしゃるのではないでしょうか。ここで、SageMaker HyperPod と共に、SageMaker HyperPod Recipes が救世主となるのです。
SageMaker HyperPod Recipesは、AWSのSageMakerインフラストラクチャ上で大規模言語モデルの事前学習とファインチューニングを行うための最適化された設定群を提供します。これらの設定は、AWS社内チームによる広範なベンチマーキングを通じて確立されたものです。たった1行のコードで、LlamaやMistralなどの人気のあるオープンソースモデルを、お好みのAWS HyperPodクラスターやSageMaker Training Jobsで事前学習やファインチューニングできるようになりました。Recipesが学習ループの作成から学習ジョブの開始まですべてを担当し、最高クラスの設定で学習を始められます。
たった1行のコードで、GPUとTrainiumのワークロードをシームレスに切り替えることができ、Trainiumがもたらす価格性能比の優位性をさらに活用できます。ユーザーは独自のカスタムモデル向けにRecipesをカスタマイズすることができます。Recipesとモデルを拡張して独自の定義を作成し、HyperPod Recipeのフレームワーク内で作業を続けることができるオプションを用意しています。HyperPod Recipesの使い方は非常にシンプルです。この機能を提供する理由は、すぐに事前学習とファインチューニングを始められるようにするためです。モデル設定の最適化の手間を省きたいと考えています。
新しいモデルが登場したとき、すぐに実験を開始して学習とファインチューニングを実行できます。HyperPod Recipesで必要なのは、Apache 2ライセンスでオープンソース化されているGitHub上からモデルの学習・ファインチューニングRecipeを選択し、AWS環境の前提条件（設定、認証情報、リソース制限、SageMaker HyperPodまたはSageMaker Training Jobsの使用有無、使用するクラスターなど）をセットアップして、Recipeを実行するだけです。SageMaker HyperPod RecipesはGitHub上でApache 2ライセンスで公開されています。
GitHubページには、詳細な動作原理、利用可能なRecipe、サポートされている機能を説明するReadmeがあります。現在、Llama 3.1や3.2を含むLlamaシリーズで30以上のRecipeをサポートしています。例えば、128Kのコンテキスト長を持つLlama 3.1 405Bのファインチューニングをすぐに開始できます。これは私たちの広範な取り組みの成果であり、皆様と共有できることを大変嬉しく思います。NeMoをベースに構築されているため、NeMoに慣れている方にとっては非常に使いやすいものとなっています。オープンソースであることから、AWSアカウントをお持ちでない方でも確認いただけます。GPUとTrainiumに最適化され、ネイティブのNeMoサポートとカスタムモデルのサポートを備えています。
GitHubの重要なフォルダをいくつかご紹介します。launcher scriptsフォルダには、環境変数を設定してNeMoスタイルのランチャーを呼び出す、事前設定されたbashスクリプトが含まれています。より簡単に始められるようにすることが目的で、これらのbashスクリプトを修正して独自の環境固有の設定を指定することもできます。また、recipes collectionフォルダには、Hydraベースのフォーマットで記述された、ファインチューニングと事前学習のためのすべてのRecipeが含まれています。さらに、NeMoランチャーに慣れている方にとって使いやすい、同様の構造で構築されたmain.pyファイルもあります。
Salesforceにおける大規模言語モデルの活用事例
最後に、HyperPod レシピが使用する多くの依存関係を含むDocker コンテナ、つまり環境ベースのファイルシステムを構築しました。HyperPod レシピを使用する際には、トレーニングループを生成するためのロジックの大部分を含むこのコンテナを取り込むことになります。もちろん、必要に応じて独自のカスタムコンテナを使用することもできますが、おそらくその必要はないでしょう。
これが実際のレシピの例です。 ご覧のように、この例ではレシピ情報を提供しています。モデルタイプ（Hugging Face やその他のソースからのものか）を指定し、トレーナーを設定できます。繰り返しになりますが、これらの多くは事前に設定されているので、特に設定する必要はありませんが、アクセラレータを変更することは可能です。これが、コード1行で切り替えられると言った理由です - GPU でのトレーニングに簡単に切り替えられるのです。
こちらは、Slurm を使用する場合のクラスタ設定ファイルの例です。 ここでお使いのインフラに合わせて具体的な設定を追加できます。ご覧のように、ジョブ名のプレフィックスを追加しています。また、6行目に興味深い点があります - Slurm create submission file というものです。レシピを直接使用せず（コマンドを実行してジョブを起動する方法）、代わりにこれを true に設定すると、手動で実行できる Slurm コマンドが生成されます。このように、トレーニングをより簡単に行えるよう、私たちが多くの作業を代行しているのです。
そしてこちらは、これらすべてをまとめる別の config.yaml ファイルです。クラスタタイプやレシピ、その他のパラメータを指定できるトップレベルのファイルです。下部を見ていただくと、必要に応じて独自のコンテナを指定することもできますし、独自の GitHub リポジトリも指定できます。私たちのリポジトリをフォークして独自のリポジトリを使用したい場合は、それも指定できます。このように無限のカスタマイズが可能です - おそらく必要ないとは思いますが、カスタマイズしたい場合にはその機能も用意されています。
次に、実際に実行するコマンドについてお話ししたいと思います。 Slurm を使用している場合は、すでに用意されているランチャーの使用をお勧めします。特に追加で何かする必要はありません。ランチャースクリプトフォルダに移動し、モデルディレクトリで適切なランチャースクリプトを選択してトレーニングを起動するだけで、対応するクラスタでジョブが実行されるはずです。
Amazon EKSをご利用の場合は、HyperPod CLIの使用をお勧めします。HyperPod CLIは、hyperpod start-jobのようなコマンドを備えたもう一つのオープンソースリポジトリで、HyperPod上でコマンドを実行することが容易になります。実際、hyperpod start-jobにレシピをパラメータとして渡すだけで、トレーニングを開始できます。シンプルなワンライナーで実現できるんです。 もちろん、より馴染みがある方法として、NeMo-style launcherを使用することもできます。
SageMaker training jobsでトレーニングを実行したい場合は、Estimatorを生成する際に少し修正するだけです。トレーニングレシピパラメータにレシピを渡すだけでOKです。このパラメータは、HyperPod recipesのローンチの一環として、つい先日のre:Inventのアナウンス時に追加されました。SageMaker SDKのリリースでも、SDK Estimatorに新しいトレーニングレシピパラメータが組み込まれ、SageMaker training jobの一部としてHyperPod recipesを実行できるようになりました。
では、これらがどのように連携して動作するのか、詳しく見ていきましょう。 バックエンドでこれらをどのように機能させているのか、実はとてもシンプルです。HyperPod CLIやSageMaker Python SDKのいずれを使用する場合でも、最終的にはある時点でNeMo-style launcherを呼び出します。NeMo-style launcherは、いわばこのシステムのバックボーンとなっており、その上に様々な抽象化層を構築しています。NeMo-style launcherを呼び出すと、まず最初にコンフィグレーションを解析して、ユーザーが何をしようとしているのかを理解します。
SageMaker HyperPod GPUで実行している場合、GPUのトレーニングループを生成するための対応コードを呼び出します。Neuronの場合は、事前に構築されたレシピを活用するため、Neuron distributed training toolkitを呼び出します。NVIDIA NeMoの場合は、NVIDIA NeMoレシピを直接このフレームワークに渡すことができ、必要に応じてカスタムモデルを持ち込むこともできます。
要件に応じてトレーニングループを構築したら、Slurm、HyperPod、またはKubernetes training jobsなど、適切なクラスター上でジョブを起動します。 つまり、たった1つのコマンドで、30以上のレシピのライブラリから選択し、使用したいクラスターを選び、トレーニングジョブを作成して、お好みのHyperPodクラスターやSageMaker training jobs上でジョブを開始できるようになったということです。ぜひこの機能を使っていただきたいと思います。上部にあるドキュメントページのリンクには、使用方法を段階的に説明する詳細なチュートリアルがありますので、ぜひそちらもご確認ください。それでは、素晴らしいプリトレーニングとファインチューニングをお楽しみください。特別なリクエストがありましたら、講演後に外でお会いできればと思います。ご意見をお聞かせいただければ幸いです。
Salesforceが開発した特殊用途のAIモデルとその成果
それでは、Salesforceでの経験についてお話しいただくために、Tonyに引き継ぎたいと思います。Sanjayさん、ありがとうございます。また、皆様、お時間をいただきありがとうございます。まず、Salesforce AI Researchについて簡単にご紹介させていただき、その後HyperPodの話題に戻りたいと思います。私たちの活動は主に3つあります。私たちはSalesforceのAIリサーチ組織として、アカデミックな研究から顧客との実証実験まで、エンタープライズのユースケースに向けた最先端AIの基礎研究開発を推進しています。これには、最先端のAIをエンタープライズの高価値ユースケースにどう統合できるかについて、顧客との密接な協働を通じた多くの探索的なフィードバックが含まれます。そして最後に、AI側での研究開発や顧客との実証実験で得られた技術を、すべての製品やプラットフォームで一般提供される機能としてどのように組み込むかというプロダクトイノベーションです。
Salesforce AIでは、長年にわたってSageMakerを活用してきました。今年、私たちはHyperPodの活用を開始しましたが、一言で表現すると「手の届くところにあるスーパーコンピュータ」です。さらに言えば、マネージド型のスーパーコンピュータなので、より優れています。ここで少し時間を取って、なぜSalesforceがHyperPodの活用に大きな期待を寄せているのか、その理由についてお話ししたいと思います。このチャートは業界の主要なトレンドを説明するのに役立つと思います。オレンジ色の線をご覧ください。これはMMLUベンチマークのスコアを示しています。これは生成AIモデルの多面的な言語理解を評価するベンチマークで、自然言語理解と高度な学術的な質問応答の複数の側面を捉えています。
2023年にオレンジ色の線が大きく跳ね上がっているのがわかります。これはGPT-4の登場時で、GPT-4が多くのユースケースと期待を解き放った瞬間でした。そして青い線は、オープンソースモデルを表しています。2023年から2024年初めにかけて、Llama 1、Llama 2などで着実に進展していましたが、2024年初めの時点ではまだ大きなギャップがありました。今年初めの時点では、クローズドソースとオープンソースのモデルの間にはまだかなり大きな差がありました。しかし、過去12ヶ月で見られた変化は、このギャップが縮小したことです。AIを活用して製品を開発するエンタープライズの視点から見ると、これは大きな転換点です。最先端のモデルを実際にトレーニングし、ファインチューニングして、特定用途に特化させ、さらなる信頼性と改善をもたらすことができるようになったのです。これは、なぜHyperPodの利用を検討し始めるべきかを理解する上で非常に重要な背景だと思います。それでは、いくつかのレシピについて簡単にお話しします。
今回のre:Inventで発表された重要なリリースの1つがHyperPodです。私たちが特に気に入っているのは、FSDPとContext ParallelismをLow-Rank Adaptation（LoRA）と組み合わせて、さまざまなトレーニングスタックを構成できる機能です。これはHyperPodレシピの一部として利用できる独自の機能セットで、他のフレームワークにはない特徴であり、大幅な作業削減を実現しています。わずか4ノードで、完全な128Kコンテキストを使用してLlama-3.1-405Bをファインチューニングすることができ、量子化を行えば1ノードで実現できます。
これは実際にとても大きな進歩です。私の同僚の研究者の一人が、長いコンテキストのユースケースが必要で、1週間かけてフレームワークを統合し、Context Parallelを実装して長いコンテキストを実現しました。そのモデルのパラメータ数を聞いてみると90億でした。そうなると、4,050億パラメータのモデルには何週間かかっただろうかと考えてしまいます。このように、最大規模の公開モデルでこれらの機能がすぐに使える状態で提供されることは、私たちにとって非常に喜ばしいことです。
少し話題を変えて、私たちの成果についてお話ししたいと思います。Salesforce AIという組織全体として取り組んできた素晴らしいモデルについてご紹介します。これらはすべてHyperPodで学習されたものです。HyperPodや組織全体で開発された優れたモデルのほんの一部ですが、SageMakerとHyperPodを活用して私たちが行ってきた素晴らしい取り組みの一端をお伝えできればと思います。
AgentForceは、今年リリースした私たちのフラッグシップAIプロダクトスイートです。その中核となるモデルの1つがxGen-Sales LLMです。これは、セールスに特化した独自の大規模言語モデルで、通話の要約、顧客プロファイリング、コンタクト情報の充実化、パイプライントラッキングなどの主要機能を備えています。ユーザーは、これから説明するさまざまな用途に対話的に活用できます。このモデルの重要な指標の1つとして、ブラインドテストにおいて、このAIが生成した要約は、人間が作成した要約よりも好まれる傾向にあったということが挙げられます。
この通話トランスクリプトに注目してください。これは、セールスパーソンと顧客が会話している様子を示しています。セールスの通話から得られた記録されたトランスクリプトですね。右側には、AIによって生成された出力が表示されています。顧客の印象、通話の要約、次のステップが表示されています。ユーザーは、AI生成の要約の一部をハイライトすると、AIがその生成部分に関連する通話トランスクリプトの生の根拠を表示してくれます。社内技術とカスタムファインチューニングを活用することで、このようなプロダクトイノベーションを実現することができました。
これはAgentForceに広く統合される予定で、現在進行中のAgentForceカスタマーパイロットですでに稼働しています。次にRAGforceについてお話しします。Retrieval Augmented Generationについてはご存知かもしれません。ご存じない方のために簡単に説明しますと、検索・検索機能と生成言語モデリングを組み合わせたものと考えることができます。より具体的には、ユーザーが質問をすると、セマンティック検索やキーワード検索、ハイブリッド検索などの検索を実行し、その検索結果をモデルのコンテキストに取り込みます。モデルは、In-Context Learningと呼ばれる手法を適用して、これらの記事を活用し、ユーザーの質問に対する適切な回答を生成することができます。これはデモでは素晴らしく機能しますが、実際には多くの問題が発生する可能性があります。RAGのユースケースで企業のお客様と協業する中で気づいた重要な課題の1つは、品質が文書の整理状態に大きく依存するということです。
実際には、多くの企業文書には、矛盾するバージョンや古い情報が含まれています。数ヶ月前のGoogle DocsやQuip Docsには、完全に古くなった情報が含まれていることがあります。文書間でフォーマットが統一されていないことも、モデルを混乱させることがあります。このユースケースに対するパフォーマンスの向上は、企業にとって重要な価値があります。
企業内の文書には豊富なメタデータが存在しますが、モデルがそれらの情報の優先順位付けをどのように扱うべきかを掘り下げて考えると、いくつかの考慮点があります。例えば、あるチームや組織の公式文書としてタグ付けする場合、それは次四半期の計画案よりも優先されます。ただし、その公式文書が6ヶ月以上前のものである場合は、優先度を下げるべきでしょう。ここで問題となるのは、AIにこれらのルールを遵守させ、文脈に忠実に従わせる方法です。
これはSalesforce Researchで取り組んできたことの1つです。 私たちは、この文脈的忠実性という概念を最大化するために、わずか90億パラメータの文脈理解型LLMを訓練しました。私たちの目標は、ハルシネーションを最小限に抑え、ユーザーが複雑な優先順位付けルールを自然言語で提供できるようにし、そのルールをLLMが入力文書セットに適用できるようにすることです。この文脈的忠実性のユースケースにおいて、HyperPodで微調整された90億パラメータのモデルは、はるかに大きなモデルを上回り、RAGベンチマークで最先端の性能を達成できることがわかりました。
ここでさらに掘り下げて、 Re-rankingを含むRAGと検索システムについて詳しく見ていきましょう。Re-rankingをご存じない方もいるかもしれませんが、これはプロセスの検索部分に組み込まれていることが多いものの、実は検索結果の品質に大きな違いをもたらす重要なコンポーネントです。Re-rankerまたはRe-rankingモデルは、特定のユーザークエリや質問に関連する文書を、大量の文書の中から素早く処理して特定することに特化したAIです。フロー図を見ると、ユーザークエリ、文書のナレッジベース、そしてEmbeddingsやキーワード検索を使用して文書を取得するRetrieverがあります。これらの初期結果はRe-rankingフェーズを通過し、Re-rankerが関連性に基づいて順序を並び替えます。この知的レイヤーが検索に適用され、最終的な結果がGeneratorまたはレスポンスLLMに渡されて、洗練された回答が生成されます。
SFR-LlamaRankの主要な技術仕様として、 Llama 38B Instructモデルをベースに微調整を行いました。業界をリードするRe-rankerと比較して、同等かそれ以上の性能を達成しました。Salesforceにとって本当に重要なのは、Re-rankerを持ち、効率性を綿密に管理できることで、エンタープライズレベルで水平方向にスケーラブルな展開が可能なことです。微調整が可能だったため、線形的なキャリブレーションスコアリングを実現し、関連性スコアのランク付けをシステム全体で一貫して行えるようになりました。
少し話題を変えて、 もう1つのモデル、Reward Modelについてお話しします。Reward Modelは、他の種類のモデルほど表面に出てこないかもしれません。これはおそらく、常にユーザーと直接対面するわけではないからですが、舞台裏で非常に重要な役割を果たし、重要なユースケースを持っています。簡単に言えば、Reward Modelは人間の好みを予測できるものです。
多くの場合、Response AとResponse Bのペアワイズ比較として定式化され、モデルはResponse AがResponse Bより優れているかどうかを予測するように訓練されます。これらのReward Modelは、特にRLHF（Reinforcement Learning from Human Feedback）において、教師モデルとして使用されます。これらのReward Modelは、最終的にアシスタントやエージェントとなるモデルの訓練信号を生成する役割を果たします。
訓練時の使用以外にも、様々なユースケースがあります。同じモデルの2つのチェックポイントをA/Bテストしたい場合の自動評価にも使用できます。もう1つの興味深い使用例は推論時で、モンテカルロ探索のような手法を使用できます。モデルから生成された応答のトラジェクトリをサンプリングする際に、Reward Modelからフィードバックを得て、低評価の応答を除外しながら、高評価のトラジェクトリからさらにサンプリングを続けることができます。
SFR-Judgeについて説明しましょう。これはSalesforceの社内Judge Modelです。私たちは様々なサイズのモデルを訓練してきましたが、700億パラメータのバージョンは、Reward Modelingに関する13の評価ベンチマークで最先端の総合性能を達成しています。HyperPod分散環境の4つのノードを使用して、このサイズのモデルまで簡単にHyperPod訓練をスケールアップすることができ、先ほど述べた様々なユースケースで非常に有用であることが実証されています。
AI研究の未来展望とセッションのまとめ
Salesforce AI、そして潜在的にはAI業界全体の今後について、私の個人的な見解をお話ししたいと思います。まず、来年のAI研究で考えるべきいくつかの問題提起から始めましょう。インターネットコーパスのエントロピー率の限界に達しているのでしょうか？これは、Pre-trainingが非常に大規模化していることを表現する専門的な言い方です。Pre-trainingでは、数兆のトークンで訓練を行います。一方、Post-trainingはPre-training後に行われるもので、ベースモデルからInstructモデルやChatモデル、さらにドメイン特化型モデルへと発展させる過程です。
Post-trainingでは、一般的に訓練に使用されるトークン数は数十億程度です。これはスケールアップするでしょうか？データを見つける必要があるという課題があります。おそらくLLMから生成された合成データが役立つかもしれませんし、大規模な人手によるアノテーションが継続的に成長してPost-trainingのスケールアップを支援するかもしれません。このPost-trainingの問題に関連して、推論時の計算という新しい形態が現れ始めています。最近、クローズドソースとオープンソースの両方で、Reasoningモデルと呼ばれる新しいタイプのLLMが登場しています。Pre-trainedのベースモデルからReasoningモデルへと導く、全く新しいPost-trainingプロセスが存在するのです。
私は2025年が推論時間のスケーリングの年になるのではないかと考えています。現在、ほとんどの推論時間による推論モデルは1、2分程度の思考が限界です。おそらく2025年には、何時間、あるいは何日にもわたって一貫した思考を続けられるモデルが登場するでしょう。企業におけるAIエージェントの重要性が増していく中で、マクロな視点で見ると、この状況はMulti-Agent Systemというレンズを通して捉えることができます。Re-rankerやReward Model、xGen-Salesのような、特定のタスクに特化したAIモデルがいくつか存在します。私はこれらをComponentsと呼んでいます。
これらのComponentsは、いわば知的なニューラルI/Oのようなものです。決定論的な関数というよりも、知性を必要とする関数といえます。これらはスマートなComponentsであり、私たちにはAssistantsがあります。これは多くの人がClaudeやChatGPT、Agentforceとの対話で経験しているものです。対話的で低レイテンシー、リアルタイムで、さらに音声や画像に対応するマルチモーダルな能力を備えています。SFR-RAGのようなRAGシステムと統合されており、特に人間との接続や対話の方法において、Assistantsの成長と改善は続くと考えています。
私たちは、数分から数時間、あるいは数日かかる可能性のある長時間実行のAIプロセスに人間を接続できるAssistantsを目にすることになるでしょう。これらは多くのツールを使用し、自身の作業をチェックし、複雑な推論を一貫して生成する信頼性と能力の向上を示すことが期待されます。LLMsのこのような推論スタイルについては、多くの取り組みと考察が行われています。それでは、締めくくりとしてHonorをお招きしたいと思います。ありがとう、Tony。
皆様、今朝は分散トレーニングスタックの複雑さについて説明させていただきました。アクセラレーテッドデバイスから始まり、Amazon SageMaker HyperPodのレシピに至るまで、スタックの構造を詳しく見てきました。重要なポイントは、スタックの各層において、Amazon SageMaker HyperPod上で最高のパフォーマンスを実現するための最適化の機会が存在するということです。私たちのチームはHyperPodレシピを通じて、これらの最適化をすべてパッケージ化してご提供しています。 以上で本セッションを終了させていただきます。ご清聴ありがとうございました。セッション後のアンケートにぜひご協力ください。質問がございましたら、この場にお残りいただければと思います。皆様との対話を楽しみにしております。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion