📖

re:Invent 2024: SageMaker HyperPodで実現するFMの大規模開発

2024/01/01に公開

はじめに

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

📖 AWS re:Invent 2024 - Scale FM development with Amazon SageMaker HyperPod (AIM229)

この動画では、Amazon SageMaker HyperPodを活用したFoundation Modelの開発と運用について、業界をリードする企業のパネルディスカッションが行われています。Hugging Face、Writer.ai、Harperの代表者たちが、数百から数千のGPUを使用する大規模なモデルトレーニングにおける課題と解決策を共有しています。特にWriter.aiのケースでは、HyperPodの導入により、以前は4-6人必要だったAI Opsチームを1人に削減できた点や、クラスターセットアップ時間を72時間以内に短縮できた点など、具体的な改善効果が語られています。また、モデルトレーニングにおける自動復元機能やGPU使用率の最適化、さらにはKubernetesを活用した推論インフラの構築まで、実践的な知見が共有されています。
https://www.youtube.com/watch?v=v7r7Nqow9d4
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。

re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください!

本編

Re:Invent 2024とパネリストの紹介

Re:Invent 2024へようこそ。皆様には今朝のMattのKeynoteと、私たちのGenerative AI Foundation Modelに関する exciting な発表をご覧いただけたことと思います。本日は、ここにお集まりの皆様のために、とても興味深いパネルディスカッションを用意しています。業界をリードする方々をお招きし、Foundation Modelの開発方法や、顧客に向けてどのようなイノベーションを提供しようとしているのかについて議論していただきます。

私はShabaka Boneです。AWSのGenerative AI部門のシニアマネージャーを務めており、差別化されたGenerative AIインフラストラクチャサービスであるAmazon SageMaker HyperPodのGo to Marketをリードしています。本日はJeffにも参加していただいています。それでは、パネリストの皆様に自己紹介をお願いしたいと思います。では、Jeff、お願いします。「はい、喜んで始めさせていただきます。皆様、こんにちは。私はJeffで、Hugging Faceのプロダクトヘッドを務めています。Hugging Faceのミッションは良質な機械学習の民主化であり、これについて詳しくお話しできることを楽しみにしています。」「皆様、こんにちは。私はWassim Shekです。Writer.aiの共同創業者兼CTOを務めています。Writerは企業向けのGenerative AIプラットフォームで、私たちのミッションは企業の働き方を変革することです。ヘルスケアや金融サービス分野で300社以上の企業をリードするプラットフォームとなっていることを誇りに思っています。」「私はRobert Pusです。Harperの共同創業者兼CTOです。私たちは医療画像分野のFoundation Modelと、それらのモデルの推論をサポートする医療グレードのプラットフォームを構築しています。」

Amazon SageMaker HyperPodの特徴と利点

Thumbnail 110

パネルディスカッションを始める前に、HyperPodとその提供価値について簡単にご説明させていただきます。会場の皆様の中で、独自のFoundation Modelの構築を検討されている方、あるいはGenerative AIモデルの本番展開をどのように開始するか検討中の方は何人いらっしゃいますか?皆様はどのようなアプローチをお考えでしょうか?独自のモデルを構築されますか?それとも既存のオープンソースモデルのファインチューニングをお考えですか?どのようにお考えでしょうか?ファインチューニングですか?複数のノードにまたがる複数のアクセラレータGPUでトレーニングを行い、そのアーキテクチャを検討されているということでしょうか?

今おっしゃったように、モデルのファインチューニングや独自のFoundation Modelの構築を検討されているお客様の多くは、通常いくつかの重要な考慮事項をお持ちです。まず最初に考えるのはデータについてです。モデルのトレーニングにデータは十分に準備できているでしょうか?ラベル付けは済んでいますか?どの程度差別化されていますか?モデルのトレーニングに十分なデータ量がありますか?もし不足している場合、どこからデータを収集できるでしょうか?どのような種類のデータを使用しますか?テキストだけですか?マルチモーダルですか?それらが、選択すべきストレージやファイルシステムにどのような影響を与えるでしょうか?

二つ目の考慮事項は、モデルのトレーニングに必要なGPUのパワー、つまりアクセラレータの計算能力についてです。モデルの規模やデータサイズに応じて、どれくらいのGPUが必要になるでしょうか?そしてどのような種類のGPUが本当に必要なのでしょうか?H100が必要ですか?A100で十分でしょうか?GPU以外のソリューションでも対応できるでしょうか?これらはすべて、実際の市場投入までのコストと時間を理解するために、お客様が検討されている事項です。

数百から数千のアクセラレーター計算クラスターを立ち上げることを考える際、このクラスターの管理方法とスケーリング効率の仕組みも重要です。モデルのトレーニングに使用するGPUの数を2倍にした場合、それがトレーニングパフォーマンスに反映されるのでしょうか?もし反映されないのであれば、トレーニングパフォーマンスをどのように改善できるのでしょうか?また、数百から数千のGPUを持つクラスターをどのように管理すればよいのでしょうか?ジョブの投入はどのように行い、クラスターの使用率を100%近くに保つにはどうすればよいのでしょうか?そして、クラスターの稼働時間はどの程度になるのでしょうか?これは直接、インフラストラクチャーとクラスターの回復力に関わってきます。

Thumbnail 330

インフラストラクチャーとクラスターの回復力。これらのGPUはどのくらいの頻度で故障し、データサイエンティストたちは、実際のモデル開発やイノベーションではなく、何が故障したかを分析することにどれだけの時間を費やしているのでしょうか?私たちはこれらの懸念を多くのお客様から耳にし、それらを基に、Amazon SageMaker HyperPodを設計・構築しました。これは前回のre:Inventで発表され、それ以来、お客様から大きな反響をいただいています。分散トレーニング専用に設計されており、特に数百のGPUから、100未満から数万単位までのトレーニングジョブを実行することを検討しているお客様に適しているため、好評を得ています。お客様がモデルのトレーニングに必要とするクラスターのサイズを、簡単にスケールアップ・ダウンすることができます。

HyperPodが実際に提供するものは何か、なぜ分散トレーニング向けにカスタム構築されていると言えるのでしょうか?単一のスパイン上に永続的なクラスターを提供することで、データサイエンティストはより良いトレーニングパフォーマンスを得ることができます。分散トレーニングに必要なフォワードパスとバックワードパスのネットワークオーバーヘッドを即座に削減することができ、これらのノードをデータセンター内で最適に配置し、クラスターとして提供することで、ネットワーク速度を大幅に向上させることができます。また、FSDP、DeepSpeed、その他どのような選択肢であっても、お好みの分散トレーニングフレームワークをサポートしています。さらに、PyTorchを上回るパフォーマンス向上を実現するSageMaker独自の分散トレーニングライブラリも提供しているため、LLaMAやMixtureのファインチューニングを行う場合、これらの独自ライブラリを使用してパフォーマンスを向上させることができます。ただし、これまで使用してきたものを継続して使用したい場合も、その柔軟性は維持されています。

Hugging Faceのミッションとオープンサイエンスへの取り組み

Thumbnail 460

HyperPodの最も重要な価値提案は回復力です。なぜ回復力がそれほど重要なのでしょうか?多くのファインチューニングが行われる規模を考えると、たった1つのGPUの故障でも、トレーニングジョブ全体が停止してしまいます。これは、GPUの故障の原因が、アプリケーションエラーなのか、メモリの問題なのか、熱の問題なのか、あるいは交換が必要な不良ノードなのかを理解しようとする時間を費やすことを意味します。本来費やしたい時間であるモデル開発ではなく、そうした分析に多くの時間を費やすことになってしまいます。

SageMaker HyperPodはこの問題をどのように解決するのでしょうか?クラスターが立ち上がる際に、ノードの詳細なヘルスチェックを実施します。クラスターの作成と更新時に、ヘルスチェックを行い、不良ノードを交換します。クラスターが稼働中は、エージェントが継続的にノードの健全性を監視します。不良ノードを検出した場合、健全なノードのウォームプールから自動的に交換することができます。その後、Amazon S3バケットに保存された最後のチェックポイントからトレーニングジョブを再開するか、あるいは自動で行うオプションを選択することができます。

Thumbnail 570

このレジリエンシーの利点は、多くのマネージドサービスが提供しているものであることに注目することが重要です。基盤となるノードに障害が発生した場合、マネージドサービスが自動的に対処してくれます。しかし、マネージドサービスはインフラストラクチャから抽象化レイヤーを提供します。多くの上級MLユーザーは、インフラストラクチャへのより深いレベルのアクセスやコントロールを求めています。 つまり、ノードへのSSHアクセスが可能で、NVIDIA CUDAテストや分散テストを実行できることを意味します。彼らは、そのレベルの可視性、任意のオープンソースツール、フレームワーク、ライブラリを使用する能力、そしてクラスターやGPU使用率の詳細な視覚的プロファイリングと可視化、さらにクラスターの状況を把握するためのツールを求めています。HyperPodを使用することで、インフラストラクチャのレジリエンシー管理という差別化されていない重労働から解放されます。すべてのノードへのroot権限アクセスが可能になり、ニッケルテストやDC GMテストを実行することができます。

HyperPodはインフラストラクチャ管理の負担を取り除きますが、コンピュート、ネットワーキング、フレームワーク、ライブラリの使用に関するすべてのコントロールは引き続きユーザーの手元に残ります。必要に応じてパフォーマンスを構築し最適化することができます。CloudWatchのContainer Insightsを使用して、クラスターの使用状況を確認し、モニタリングすることができます。

Thumbnail 650

Thumbnail 660

また、データ並列とモデル並列トレーニングのための独自の分散トレーニングライブラリも提供しています。FDPを超える最適化が必要な場合は、これらの独自ライブラリを使用して実現できます。まとめると、Amazon SageMaker HyperPodが提供するのは、お客様がFoundation Modelの開発を真に革新できる方法です。コンピュートをカスタマイズし、AWSが提供するGPUベースおよび非GPUベースのインスタンスを幅広く使用できます。使用したいテックスタックを選択でき、ワークロード全体で使用できる永続的なクラスターを持つことができます。

ノードへのアクセス、root権限でのアクセスが可能で、トレーニングアーキテクチャや推論アーキテクチャを構築する際に必要なすべてのコントロールと柔軟性を持つことができます。SlurmやKubernetesを使用してジョブのオーケストレーションと投入を継続できるため、既存のツールやテクノロジースタックを変更する必要はありません。お好みのツールを引き続き使用しながら、私たちが公開しているモデルレシピを使用して、最小限のオーバーヘッドでこれらのクラスターを簡単にスピンアップして開始することができます。

WriterのFoundation ModelトレーニングにおけるHyperPodの活用

ここで、パネリストの方々にバトンを渡したいと思います。まずはJeffさんから始めましょう。2025年以降のイノベーションについて、どのようにお考えなのかを聴衆の皆様にご紹介いただけますか。Hugging Faceは広く知られているブランドですね。AIコミュニティに多大な貢献をされてきましたが、2025年以降にどのようなイノベーションを起こしていきたいとお考えですか?

ありがとうございます。Hugging Faceについてお話しする前に、Writer AIの皆様に大きな感謝の意を表したいと思います。AIファーストな企業の素晴らしい例を挙げてほしいと言われたとき、私はいつもWriter AIを例に挙げています。なぜなら、彼らは最大限のインパクトを生み出すために必要なことをすべて実践しているからです。1つ目は、オープンサイエンスです - 最先端の研究を行い、可能性の限界を押し広げ、素晴らしい論文を発表しています。2つ目は、オープンソースへの貢献です。Hugging Faceで Writer organizationを見ていただくと、Palmyraファミリーのモデルがあります。14以上のモデルが無料で公開されており、先月だけでも10,000回以上ダウンロードされました。彼らは製品に素晴らしい付加価値を組み込み、顧客に優れた機能を提供しています。

Hugging Faceのミッションは、優れた機械学習を民主化することです。ここでいう「優れた」とは、オープンソースをベースとし、コミュニティ主導で、倫理を第一に構築されているということです。私たちはこれを、オープンサイエンス、オープンソース、そして製品とサービスを通じて実現しています。Hugging Face hubは、オープンモデルを扱う方なら、モデルの検索や探索、評価のために利用されたことがあるでしょう。現在、あらゆる種類の機械学習タスクに対応した100万以上のモデルが利用可能です。700万人以上の人々が、パブリックとプライベートの両方で独自のAIを構築しています。15万以上の組織がhub上でモデルとオープンソースを中心にコラボレーションを行っています。皆さんはTransformers Libraryをご存知かと思いますが、テキスト生成、モデルのデプロイ推論、データセット、高速化など、20以上の異なるツールがあります。私たちのミッションにとって非常に重要なオープンサイエンスについてもっとお話ししたいと思います。パフォーマンスにギャップがある分野で、新しい基盤モデルをコミュニティに提供したいと考えています。これを実現するために、私たちはAmazon SageMaker HyperPodを活用しています。

後ほど詳しくお話しできると思います。HyperPodがこれらの新しいモデルの構築にどのように役立っているのか、詳しくお話ししたいところですが、まずはWriterから始めましたので、Writerのミッションについてお話しいただきたいと思います。Jeffが触れられたLLMsについて - どのように構築されているのか、お客様に何を提供しようとしているのかについてお聞かせください。

ありがとうございます。2020年に創業した時、私たちはAIを通じて企業の働き方を変革するというミッションからスタートしました。2022年、2023年、そして2024年と、明確な段階を経て進化してきています。より大規模で高性能なモデルを構築し、さらなる進歩を遂げてきました。モデルが大きくなり、構造が複雑になるにつれて、より大きな課題に直面してきました。HyperPodは、現在市場で最高の機能を持つフロンティアモデルであるX4を含む、最新のモデル開発に大きく貢献してくれました。

これらのモデルを構築するアプローチは、スケールアップに伴って明らかに変化してきました。1、2十億パラメータのモデルの構築は大きな問題ではありません。最大の課題は、数百十億パラメータのモデルを構築し始める時に現れます。その段階では、技術や知識以外に、故障しない信頼性の高いハードウェアが必要になります。私たちは、より優れた、より複雑なモデルの構築に力を入れています。パラメータ数だけでは意味がないと考えています - より深いモデルが重要なのです。現在のモデルは数百十億のパラメータを持ち、モデル自体に500以上のレイヤーがあるため、より大きなモデルよりも優れたパフォーマンスを発揮しています。

このような3〜5ヶ月にわたるトレーニングには、単なるGPUクラスター以上の信頼性の高いインフラが必要です。どんな障害でもチームや実装に大きな労力を要する可能性があります。HyperPodは私たちに大きな助けとなっていますが、最も大きな支援はオープンソースコミュニティからもたらされています。この素晴らしいオープンソースコミュニティ、特にHugging Faceのサポートがなければ、私たちがイノベーションを起こすことは困難だったでしょう。2週間前に発表した自己進化モデルを含め、私たちが今日までに構築してきたものはすべて、市場で入手可能なオープンソースの科学、論文、モデル、データの上に構築されています。

興味深いですね。そしてRobert、Hopperはヘルスケア分野で画像診断に取り組んでいますが、Foundation Modelの構築についてどのように考えていますか?また、モデル構築にあたってオープンソースコミュニティをどの程度活用していますか?私たちは医療画像データのためのモデルを構築していますが、これは非常に大規模で扱いが難しいものです。16ビットの高解像度画像でトレーニングを行うため、モデルは複数の画像を一度に処理する必要があります。そのためHyperPodが提供する計算インフラを活用する必要があります。これは、特にこれらのクラスター内でデータを大規模に移動する際に、AWSが提供できるサービスとして私たちにとって大きな利点となっています。私たちは、独自のVision Transformerを使用するアプローチと、オープンソースの言語モデルを活用してマルチモーダルソリューションを構築するアプローチの両方を採用しています。

これらのマルチモーダルな画像からテキストへのモデルにより、医療画像の特徴を識別し、さまざまな形式でテキストとして出力することができます。これには、予備的な放射線科レポート、検査での所見リスト、またはXMLを通じたセグメンテーションマスクやバウンディングボックスの表現の出力が含まれます。私たちは複数のアプローチを取っており、HyperPodが提供するパワーを活用することで、私たちが扱う大規模なデータの最適化に大きな利点となっています。

医療画像分野におけるHarperのFoundation Model開発

Jeff、先ほどあなたは科学モデルについて言及し、クローズドモデルと比較してオープンソースコミュニティにより多くのものをもたらしたいとおっしゃいました。それについてもう少し掘り下げてみましょう。これらのモデルを構築する際、データの観点とインフラの側面から、どのような主要な懸念事項がありますか?どのようなことを検討されていて、HyperPodはそれらの要件にどのように対応していますか?

先ほど申し上げたように、私たちのオープンサイエンスチームと研究者の主な目標は、利用可能な最高のオープンモデルとクローズドモデルとの差を縮めることです。GPT-3の時代に、私たちはコミュニティと共にBloomを構築しました。これは発表時点で1,750億パラメータを持つ、最高の完全オープンな多言語Large Language Modelでした。Codexの後、私たちのチームはコミュニティと共にStarCoderファミリーのモデルを構築し、これは発表時点でコード用の最高の完全オープンモデルでした。その後、私たちのサイエンスチームはFIDES-FICSを構築しました。これは発表時点で多言語LLMタスクに利用可能な最高のオープンモデルとなったモデルファミリーです。最近では、わずか2週間前に、私たちのサイエンスチームはSmallLMファミリーのモデルをリリースしました。これもまた、発表時点でこのサイズでは最高のオープンで利用可能なモデルとなっています。

目標はそのギャップを埋めることですが、私たちは常にHyperPodを持っていたわけではありません。約2〜3年前のBloomの時代を覚えています。より良いモデルアーキテクチャを見つけるために科学的な革新を行うこと、それは科学です。しかし、その科学を現実のものにするのは、Hugging Faceで見つけて使用し、ダウンロードできるモデルのチェックポイントです。それは科学の仕事ではなく、ハードコアなエンジニアリングの仕事なのです。Bloomを構築した時、世界中のあらゆる組織から1000人の研究者がこのプロジェクトに貢献するために集まりました。しかし、Bloomのトレーニング中にクラスターを実際に維持していたエンジニアは非常に小さなチームで、リードエンジニアはStas Beckmanでした。StasはGitHubで自身のオープンソースの本を書き、Bloomのトレーニング経験から得た全ての学びと洞察を共有しています。

良いニュースは、今ではHyperPodがあるため、もうその本は必要ないということです。なぜなら、私たちが経験しなければならなかったすべてのことが、今ではHyperPod内の製品やサービスとして提供されているからです。FIDES-FICSやSmallLMについて話す時、これはHyperPodで管理される私たちの内部科学クラスターを活用しています。このクラスターを自動運転モードで運用し、ユーザー(私たちの研究者)により良い洞察を提供し、ビジネスとしてクラスターの使用方法により柔軟性を持たせるために、いくつかの重要な機能があります。約48,000 vCPUのかなり大きなCPUパーティションがあり、これはSpotインスタンスを活用して拡大縮小する自動運転モードでほぼ運用されています。クラスターを1000 GPUまでスケールアップし、低レベルのメトリクスへのアクセスを通じて、問題が発生した際にノードを分離して再起動するか、ノードを維持して修復するかの判断ができるスマートなCPU-GPU管理を実現しています。

また、研究者向けに構築できるメトリクスへのアクセスも可能です。例えば、私たちが深く関心を持っているのは、これらのトレーニングジョブを通じたCO2消費量です。クラスターのユーザーとして、GPUの使用率やパフォーマンスだけでなく、実行中のジョブのCO2消費量についてのメトリクスも得られるように計装しています。また、研究チームやそれ以外からのすべてのジョブに応じて、クラスターを簡単に再構成できる柔軟性も重要です。

そして、数千のGPUへのスケーリングについてはどうでしょうか?HyperPodが導入した自動復元機能は、全体的なトレーニング体験にどのように役立っていますか?まず思い浮かぶのはGPU使用率です。これはGPUレベルで、故障したノードが放置されず自己修復されることを確実にします。また、クラスターレベルでは、ジョブが入ってくるにつれてリソースを効率的に活用することを確実にします。全体を見渡すと、これはクラスター全体でのGPU使用率が大幅に向上することを意味します。

Thumbnail 1620

Thumbnail 1650

そしてWASIMさん、あなたもHyperPodでトレーニングを行っていて、共有したいデータポイントがいくつかあるとお聞きしています。モデルのスケーリングを始めるにあたって、HyperPodがどのように役立ったのか、その経験を共有していただけますか?また、1〜2億からの数百億へのスケールアップについて、HyperPodがどのように役立ったのかについても触れていただけますか?HyperPodを使って実験を始め、実際のトレーニングを開始して以来の最大の変化は、スケーリングの実装を支援するだけでなく、より小さなチームで使用できるようになったことです。 それは、実際のコストをどのように管理し、リソース配分をどのように考えるかということです。

HyperPod以前は、私たちはトレーニングクラスターの種類や、最も安価なGPUについてばかり考えていました。しかし、HyperPodによって、特に大規模な運用において、より重要な要素である回復力と安定性について、より深い洞察が得られるようになりました。HyperPod以前は、トレーニングコストをクラスターのコストに加えて、クラスターのシャットダウンやハードウェア障害による60〜70パーセントの追加コストとして考えていました。これは誰も話題にしていない問題です。FacebookのLLaMaチームの最新モデルでも、確か1時間ごとにGPUが1つ故障するようなクラスター障害について言及していたと思います。

このように考え方を変えることで、コストの捉え方が変わってきました。実際のコストを計算する際、GPUの価格だけを見るのではないということです。確かに良い価格は重要ですが、最安値と比較すると、回復力と安定性の方がはるかに重要です。ジョブを実行する際、それは単なるジョブではなく、全作業を失う可能性があります。ノードを修復するために、複数のタイムゾーンにまたがるチームが何時間も待機する必要があるかもしれません。これらすべてが自動的に、心配なく処理される状況を想像してみてください。特に数週間から数ヶ月にわたる1つのジョブ、1つのモデルを実行する場合、システムがそれを監視できます。

推論インフラの課題とHyperPodの可能性

これは実際に社内で実行しているデータです。まず、セットアップから始めます。数百ノードの単純なクラスターでさえ、接続設定だけで最低72時間かかり、より大規模なクラスターではさらに長時間を要します。同じバージョン、同じソフトウェアバージョン、同じオペレーティングシステム、文字通り同じライブラリをすべてのノードに確実に導入する必要があります。自動化は興味深く、すべてがエンドツーエンドで構築されます。

通常、トレーニングジョブを実行する際には、クラスター、Kubernetes、GPUやハイパーパラメータを監視するために、最低でも4〜6人のAI Opsエンジニアチームが必要です。今では、文字通り1人のエンジニアが監視するだけです。すべてが自動化されており、自動チェックポイント保存、自動修復、不良ノードの交換など、すべてをAWSが処理します。私たちは、コード自体に大きな問題がない限り、プロセスを観察して監視するだけです。つまり、他の5〜6人のエンジニアを会社の他のタスクに振り向けることができるようになりました。

Thumbnail 1850

このように、コストと実際のリソース配分の考え方は私たちに大きな助けとなっています。これは現在、モデルのスケーリング方法、必要なレプリカ数、ノードの割り当て方について、私たちの考え方に影響を与えています。これは私たちの考え方を形作り、また予算の観点からも役立っています。なぜなら、これは現在、GPUクラスターでのモデル構築、エンタープライズ顧客向けの大規模なモデル提供(毎日数十億トークンを高可用性で安定的に処理)において、最大の支出となっているからです。多くのGPUを管理する必要があり、チームとともに多くのリソースが必要です。現在、私たちのチームは複数のタイムゾーンにまたがって働いており、これは困難でしたが、エンドツーエンドで管理できるシステムに移行したことは大きな成果となっています。

現在私たちはAWSを利用していますが、Cernについて特に期待しているのは、推論のためにKubernetes HyperPodパスを活用できると考えている点です。これは次世代モデル、私たちが自己進化モデルと呼んでいるものにとって大きな意味を持ちます。これは新しいタイプのTransformerで、各Transformerレイヤーにメモリーレイヤーを持つフルアテンションメカニズムです。つまり、今日のお客様は、モデルとのやり取りからリアルタイムで学習する独自のモデルを持つことができます。これらのモデルは、Cernクラスター内で安全に分離された状態を保ちながら、Kubernetesのセキュリティに依存して各顧客と各モデルのネットワークを保護することができます。

現在では、クラスターの面倒を見るために以前なら必要だった完全なチーム体制と比べて、通常1人、多くても2人のエンジニアを配置するだけで済んでいます。この可視性は、Opsチームだけでなく、科学者やリサーチチームにも役立っています。利用状況や、事前トレーニングや事後トレーニングの使用状況、問題点、特に大量のデータを扱う際のスケーリングについて、明確な把握が可能になりました。結局のところ、これらのクラスターはGPUだけでなく、監視が必要なCPUやARM、ストレージも備えているのです。AWSチームが全てを確認し、トリガーを設定して評価し、リアルタイムでイベントを発生させることができるツールがあることは非常に役立ちます。同時に、私たちのリサーチチームはAWSとパートナーシップを組んでおり、彼らが使用できるツールで監視を行っています。もはや、AWSのオンサイトチームが管理・監視する、触れることも見ることもできないベアメタルクラスターという状況ではありません。

これは今や1人で何百ものクラスターを監視できるように変化し、リサーチチームも彼らと協力してすべてのデータとモデリングを確認しています。私たちは必要な作業を実行するために80ギガバイト以上のGPUメモリを確保する必要があるため、かなり大きなインスタンスタイプを使用する必要があります。これらのインスタンスタイプへのアクセスは課題となっています。24時間365日の課金で、AWSに準備してもらうための調整と準備期間が必要です。一度それを行うと、私たちの運用の大部分にそのクラスターを活用することになります。基本的に、GPUを使用するものはほぼすべてをそのクラスターで実行しています。クラスターにDocker JupyterHubをインストールし、多くの実験をクラスター上で行っています。

これは、必要なツールをクラスターにインストールし、GPUを最適な方法で使用することを可能にする非常に柔軟なツールです。大規模なトレーニングジョブを実行する場合でも、研究者がクラスター内の数個のGPUで実験を行う必要がある場合でも、ワークロードの種類に応じて必要なことを何でも実行できる柔軟なツールとなっています。私たちが扱う必要のあるデータの種類により、これらの比較的大きなGPUインスタンスタイプへのアクセスが必要となるため、これらは課題となっています。

クラスター自体に独自の分散ファイルシステムをインストールしています。FSXも使用しましたが、FSXではパフォーマンスに関する問題がありました。この仕組みの強みは、必要なツールをインストールするために必要な低レベルまでアクセスできることです。このカスタマイズされた分散ファイルシステムにより、私たちのワークロードを最適化するためにクラスター全体でのデータの保存方法を最適化することができています。

私たちはベストプラクティス以上のもの、つまりライブラリを共有できます。大規模なトレーニングを簡単に実行できるようにするためにNANOというライブラリを構築し、評価を簡単に実行するための軽量な補助ツールであるEvalも用意しました。使用するトレーニング手法は、サイエンスチームが取り組むプロジェクトによって大きく異なります。先ほど1,750億パラメータのモデルBloomについて話しましたが、スマートフォン向けの最小モデルでは10億パラメータ未満、約1億7,500万パラメータまで削減しました。プロジェクトによってGPUの必要数や使用期間が大きく異なりますが、HyperPodではジョブを分離して必要なリソースだけを正確に使用できる柔軟性があり、とても役立っています。

私たちは多くのライブラリを使用してきました。各モデルは異なるタイプのライブラリを使って開発されています。PyTorchは広く活用されており、Megatronはこれらのモデルを構築するために実際に使用している実装の1つです。これがHyperPodの素晴らしい点で、使用するソフトウェアやライブラリに制限がありません。独自のファイルシステムを低レベルでインストールすることもできるのが魅力的な点で、制約がないんです。

特定のSDKや特定の構築方法に限定されない柔軟性があり、これが私たちに多くの自由度を与えています。例えば、最新のモデルでは、まもなくオープンソース化される予定の独自の実装があります。Transformer自体のレイヤー間でキャッシュ管理を行うFrugal Transformerと呼ばれるシステムに関する論文を発表していますが、これをHyperPod上で制限なく実行することができました。

PyTorchを使用する場合や、Nemo Megatronライブラリを利用する他のモデルを実行する場合も同様で、制約なくスムーズに動作します。オープンソースコミュニティは日々素晴らしいものを開発しているため、この柔軟性は今後も続くでしょう。ハードウェア面での柔軟性があり、制限なく任意のライブラリを変更して利用できることは非常に重要です。オープンソースコミュニティのイノベーションのスピードは驚くべきものがありますから。少なくとも私たちの観点からすると、特定のハードウェアや特定のライブラリの使用方法について強い制約があるのは制限的すぎるでしょう。

Robertさん、分散トレーニングライブラリについてはどのように検討されましたか?HyperPodでの動作はどうでしたか?エンジニアリング的な努力は必要でしたか?かなり簡単でした。私たちは主にDeep SpeedとPyTorchを使用しています。現在、別のモデル用にFSDPを実装中です。HyperPodの観点からは、セットアップと実行が本当に簡単です。必要なライブラリをインストールでき、必要に応じて低レベルな操作も可能です。完全なコントロールができることは、このスケールでこのタイプのデータとGPUを扱う際には非常に強力な機能です。ワークフローを最適化し、あらゆる設定を調整できる機能が必要なのです。結果として、かなりの柔軟性を見出すことができ、より制限の多かったSageMaker trainingなどの以前のイテレーションで経験した課題の多くは発生していません。HyperPodへの移行には本当に満足しています。

AWSとのパートナーシップがもたらす価値

トレーニングについては詳しく話してきましたが、トレーニングの後には推論があり、そこには異なる課題があります:スケーラビリティ、スループット、レイテンシーです。Robert、モデルのデプロイについてどのように考えていますか?アーキテクチャの設計や考慮点について詳しく教えてください。医療画像には多くの場合、複数の画像が含まれます。例えば、胸部X線写真は通常、正面と側面の少なくとも2枚の画像があります。2Dマンモグラフィーでは、4K解像度の画像が少なくとも4枚あります。現在、私たちはSageMaker Endpointsを使用していますが、サポートしているインスタンスタイプの制限により、2枚の画像までしか処理できません。そこで、HyperPodをより拡張性の高いアプローチとして検討しています。これにより、2枚だけでなく、4枚、10枚の画像を同時に処理して必要な推論を実行できるようになります。最終的には、その上に独自のキューイングメカニズムを構築することも検討しています。まだその段階には至っていませんが、Q1にローンチする予定です。これが、より多くの画像に対応するためのスケーラブルなアプローチです。

また、永続的なクラスターと既存のGPUキャパシティがあれば、トレーニングに活用できることも重要です。そして、トレーニング完了後は推論にも活用できることで、リソースや二酸化炭素排出量、そしてインフラ利用の総コストを最適化するのに役立ちます。

では、Vimさん、インフラの構築についてはどのように考えていますか?推論に関して、特に気になる点はありますか?私の懸念の一つは、Amazon EKSでモデルを実行することです。AWSの既存技術を使い始める前から、何年もこれを試してきました。これまではベアメタルや単独のサーバーでの実行に頼ってきました。Kubernetesで大規模なモデルを実行した経験があるかもしれませんが、特に複数のノードにまたがってモデルをスケールやオートスケールする方法については、最高の体験とは言えません。実際にかなり難しいのです。

Amazon SageMakerチームが考案したソリューションは、基本的にKubernetesのネットワーキング、分離、オートスケールといった強力な側面を活用しながら、HyperPodと連携して加速されたGPUを管理できるようにしています。これは非常にシームレスで、私たちが実装を楽しみにしていたものです。現在、移行をどのように始めるかを検討しているところです。推論では、モデルの初回実行時間や処理自体だけが問題ではありません。特にエンタープライズでは、1秒あたりのリクエスト数、許可される同時リクエスト数、モデル間の速度、そして可用性に関する側面や99パーセント以上の利用率を確保することなど、さまざまな要素があります。

これは、Serverlessのように考えることができる素晴らしいソリューションですが、依然としてKubernetesであり、利用状況や実装方法を確認することができます。さらに驚いたのは、CFOが気に入ったことです。実際のコストやマージン、顧客のコストやスケーリングについてどのように考えられるかを確認できるようになったからです。多くの顧客は、1日あたりのトークン数よりも、1秒あたりの同時リクエスト数を重視したり、その逆もあったりしますが、これらすべてが顧客により良いサービスを提供するのに役立っています。

現在、Jeff さんは HyperPod クラスターを推論に使用されているのでしょうか?それとも使用を予定されているのでしょうか?現在、私たちには学習に特化したサイエンスクラスターがあり、また推論の多くは Hugging Face を通じて行われる本番用インフラがあります。これらは Hugging Chat(無料で使える오픈소스版 ChatGPT のようなもの)で管理されています。先ほど言及した Inference API では、Hub 上で公開されている100万以上のモデルをページ上で直接試すことができます。また、Inference Endpoints を使えば、プライベートモデルを含む Hub 上のあらゆるモデル用に、専用のインフラを展開することができます。

しかし私たちにとって、推論、特にお客様が自社のインフラ内でモデルをデプロイできる機能は、非常に重要なミッションです。例えば、AWS 上で Hugging Face のモデルを使用する場合、おそらく私たちの Deep Learning Containers を使用することになります。私たちは、お客様が自社のテナント内で、あらゆる種類のトレーニングや推論を行えるよう、すぐに使える Hugging Face モデル用の Deep Learning Containers を構築・維持管理しています。これが重要な理由は、少数の企業が全ての企業やユーザーのエクスペリエンスを支配するような世界は望ましくないからです。私たちの日常体験の多くは既に AI によって支えられており、それはさらに加速していくでしょう。もしその背後にあるモデルが少数だけだとすれば、それは多くの問題を引き起こします。私たちが目指す世界は、

AI が非常に分散化され、全ての企業が自社でモデルを構築・ホストできる世界です。自社でモデルを構築・ホストできて初めて、顧客体験を本当にコントロールし、顧客データを保護することができます。API の背後にある GPT モデルは日々変化することがよくあります。気付かないうちに顧客体験が突然変わってしまい、顧客情報をインターネット経由でサードパーティプロバイダーに送信する必要が生じることもあります。業界が直面するこうした様々な課題に対して、企業が自社の AI をホストしコントロールできるよう、幅広い選択肢を提供することが私たちにとって非常に重要です。

最近の例として、数週間前に発表した Hugging Face Gen Services があります。これは AWS Marketplace で提供されており、最も人気のあるオープンモデルを、お客様自身の AWS テナンシー内で最適化された状態ですぐにデプロイできます。最初の質問に戻りますが、私たちにとって興味深いのは、HyperPod がクラスターの活用方法に柔軟性を与えてくれることです。サイエンスチームのトレーニングワークロードが完全に使用していない時に、サイエンスクラスターの容量を非常にダイナミックな方法で本番インフラに追加することが可能になります。

AWS との協業は非常に相乗効果の高いものです。先ほど言及した SageMaker Deep Learning Containers を使用すれば、Hugging Face モデルのデプロイとトレーニングが可能です。また、新しい Trainium や Inferentia といったカスタム AI アクセラレータを開発するチームとも協力しています。今朝は Trainium 2 が発表され、私たちもとても興奮しています。この協業を通じて、お客様が独自の AI を構築しやすくするだけでなく、よりコスト効率の良いものにすることができます。Inferentia と Trainium は Hugging Face モデルで直接使用できます。私たちはそれを簡単に実現できるようオープンソースを構築し、Marketplace では独自のワークロードをセットアップするためのマシンイメージや AMI を提供しています。

AWSとパートナーシップを組んで最も印象的なのは、テクノロジーというのは単なるソフトウェアやドキュメントを自分で理解するだけのものではないということを、彼らが理解していることです。HyperPodシステム自体はそれほど複雑ではありませんが、まだ新しいテクノロジーです。HyperPodを導入した初期の頃を覚えていますが、チームは私たちとオンラインやSlackで常に連絡を取り、必要に応じて1日に何度も通話をして、エンジニアたちにツールの使い方を指導してくれました。単なる製品を使用しているという感覚ではなく、パートナーシップを通じて、システムの活用や実装について本当に気にかけてくれているのです。これはHyperPodだけでなく、他のサービスでも同様です。私たちは全般的なAWSとのパートナーシップを高く評価していますし、企業規模に関係なく、細部まで気を配ってくれることに感謝しています。正直なところ、AWSとのパートナーシップがあったからこそ、私たちは今の事業を実現できています - AWSがなければ、これは不可能だったでしょう。

私たちはSnowballデバイスからスタートし、データをAmazon S3にロードし、Sparkジョブを通じて大規模な非識別化を行い、それぞれのリージョンにあるコンピュートクラスターに移動させます。そしてそのデータをFSXに移動し、クラスターに展開して、大規模なトレーニングを実行できるようにします。比較的少人数のエンジニアチームで、これまでの成果を上げることができたのは、まさにこの一連のプロセス全体があってこそです。

技術的な観点から見て、このパートナーシップは素晴らしいものでした。サポートの面でも素晴らしいパートナーシップを築けており、何か問題が発生した際にもすぐに解決することができます。さらに戦略的な観点からも、私たちの方向性を理解し、直面している課題を把握し、利用しているサービスの改善に向けたフィードバックを提供するという形で協力していただいています。

そろそろ時間となりましたので、本日ご登壇いただいた3名の皆様に感謝を申し上げたいと思います。また、ここでQ&Aの時間を設けたいと思います。次のセッションが始まるまでの5分間、こちらにおりますので、質問がある方や私たちと話をしたい方は、どうぞ演台までお越しください。本セッションにご参加いただいた皆様、そして時間を割いてお話しいただいたパネリストの皆様に感謝申し上げます。ありがとうございました。


※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。

Discussion