📖

re:Invent 2024: RobloxのAI大規模運用 - GPU最適化とコスト削減

2024/01/01に公開

AWS

reinvent2024sessio

tech

はじめに

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

📖 AWS re:Invent 2024 - Scaling generative AI models for millions of users in Roblox (GAM310)

この動画では、RobloxのSenior Technical DirectorのIvan MarcinがRobloxにおけるGenerative AIの大規模運用について解説しています。250万人の開発者と7,900万人のデイリーアクティブユーザーを抱えるRobloxプラットフォームで、AI APIの提供やモデルの運用をどのように実現しているかを詳しく説明します。特に、AWS Deep Learning Containersを活用したインフラ管理や、オープンソースモデルの活用によるコスト削減（プロバイダー比10-26%）、Load Multiplierの課題への対処、そしてGPU使用率を20%から80-100%に改善したバッチ処理の実装など、実践的な知見が共有されています。

※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。

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

本編

Robloxにおける大規模AIの導入：概要と課題

まずは会場の皆さまについて理解を深めるため、簡単な質問をさせていただきたいと思います。今回は「Robloxにおける数百万人規模のGenerative AIのスケーリング」についてお話しするので、それぞれのキーワードに関連して、どのような方々がいらっしゃるか確認させてください。まず、Generative AIに実際に取り組んでいる方はどのくらいいらっしゃいますか？素晴らしい、かなりの人数ですね。次に、Robloxのような大規模なスケールで仕事をされている方は？あまり多くないですね。そして、単純にRobloxが好きだから来られた方は？何人かいらっしゃいますね。素晴らしい。これで今日のお話をどのように進めていけばよいか分かりました。

それでは、本日のメインスピーカーをご紹介させていただきます。私ではありません。簡単に自己紹介させていただくと、私はDominic Millsで、AWSのGames部門のSolutions Architectをしております。しかし、本日の重要なスピーカーは、こちらのIvan Marcinです。RobloxのSenior Technical Directorで、Robloxにおけるこの一連の取り組み全体を主導してきた方です。

まず、RobloxがAIに関して何を行っているのか、そのミッションと取り組んでいるプロジェクトについて、そしてAIがRobloxプラットフォームをどのように変革し、プレイヤーにより多くの価値を提供できるのかというビジョンについてお話しします。具体的には、Roblox AI API Suiteについて説明します。これは、AIとGenerative AIをプラットフォームに統合する主要な方法の1つです。その後、アーキテクチャについて詳細な図を用いて説明し、数百万人規模のユーザー（プレイヤーだけでなくクリエイターも含む）を抱える際の具体的な課題について掘り下げていきます。最後に、AWS Deep Learning Containersについて触れます。これはRobloxがそのスケールを管理し、運用の負担を軽減するために活用しているツールの1つです。そして、これらのAIシステムを構築する中でRobloxが学んだ教訓を振り返り、皆さまのプロジェクトに活かせるポイントをお伝えします。

RobloxのAIプラットフォーム：アーキテクチャと実装の詳細

皆様、ありがとうございます。RobloxのSenior Technical DirectorのIvan Marcinです。本日は、私たちがAIをどのように活用しているか、そしてRobloxをより良くするためにリリースしているAIおよびGenerative AI関連の製品やその他の取り組みについて概要をお話しさせていただきます。まず、Robloxとは何か、そのツールと私たちの取り組みについて簡単に説明し、その後アーキテクチャについて、そしてRobloxで直面している課題とその解決方法、そこから得られた教訓について詳しくお話ししていきます。

 これがRobloxの概要と、Robloxで見られるものについての簡単なビデオでした。多くの方が持っている誤解の1つは、Robloxがゲームだということですが、実際にはゲームではなく、他の人々がゲームを作るためのプラットフォームです。Robloxは自らゲームを作るのではなく、プラットフォームとツールを提供して、他の人々がゲームを作れるようにしています。具体的には、Roblox Studioというエクスペリエンス作成用のSDKとツールキットがあります。作られるものには、ゲームもあれば、広告、コマース、その他様々なものがあります。また、Robloxクライアントがあり、これはモバイル端末、コンソール、VRヘッドセット、PC、Macで動作し、実際のエクスペリエンスやゲームをプレイする場所となります。しかし、Robloxの重要な要素の1つがRoblox Cloudで、ここで多くのゲーミング計算が実行されています。これはハイブリッドクラウドインフラストラクチャで、ゲームサーバー、ゲームプレイの物理演算ロジック、カスタム開発スクリプトなどを処理するオンプレミスサーバーが一部含まれています。

クライアントコードはゲームの一部とレンダリングエンジンを実行します。AIについては、様々なAWSソリューションの中でも特にEC2を使用しています。主にGPUコンピュートクラスターにEC2を使用しており、そこで推論の大部分を実行していますが、一部の推論はオンプレミスのCPUや他のマシンでも実行しています。このように、推論とトレーニングのルートを組み合わせて使用しています。

重要なポイントは、私たちが社内エンジニア向けのプラットフォームを構築し始め、それをすべてのRoblox開発者に公開したいと考えたことです。規模感をお伝えすると、現在Robloxには約250万人の開発者がエクスペリエンスを構築しています。約530万のエクスペリエンスがあり、1日のアクティブユーザー数は約7,900万人です。これは、ゲームをプレイしている人数のピーク時の数字です。

私たちにとって、AIとはどのようなものでしょうか？ Generative AIは、チャットボットやエージェントだけでなく、Roblox Studioやエコシステムの様々な場所で使用されています。まず、安全性はRobloxにとって非常に重要です。多くの安全性モデルやツールが統合されています。Hugging Faceで公開している音声安全性モデル、不適切なアバターのモデレーション、不正報告、クリックベイトの検出などがあります。チームは常にモデルをトレーニングし、安全性ソリューションをデプロイしています。

また、コードを書いてエクスペリエンスを開発する際のクリエイター向け機能として、コードアシスタントやCLIPなどの画像生成技術を使用したテクスチャ生成などのツールがあります。プレイヤーにとっては、レコメンデーションの取得、ゲームのマッチング、マーケットプレイスの検索、プレイヤーのエクスペリエンスなどが必要になります。このように、LLMやチャットボットだけでなく、様々なツールが混在しています。

さらに詳しく説明すると、私たちが構築したいと考えたもののひとつは - チームがAIを開発するための内部プラットフォームでした。それが私たちの内部向けRoblox-ML-SDKです。チームはすでにこれを使用してモデルのトレーニング、デプロイ、推論を行っていました。私たちは、これらのツールを実際のRobloxクリエイターや開発者に提供するには何が必要かを考えました。数十のチーム、数百のチームから、250万人の開発者へ - どうすればツールを提供できるか。これが私たちが「Robloxプレイヤースケール」と呼ぶものです。

AIスケーリングの課題：異種クラスターとゲートウェイの活用

Load Multiplierと呼ばれる課題の1つについてお話しします。これは実際に目の当たりにするまで気付きにくい課題かもしれません。例えば、社内向けのChatbotを、より多くのユーザーに提供したいというユースケースがあったとします。数百人のユーザーから数千人へのスケールアップは線形的な拡大です。しかし、他の人々がツールを作るためのツールを開発する場合、スケールは線形ではなく指数関数的になります。X人のクリエイター向けにツールを作ると、それぞれのクリエイターが自分のプレイヤー向けにツールを作ることになります。さらに、彼らのツールの使い方もまた重要です。なぜなら、その使い方をコントロールできないからです。彼らはSDKを通じて何かを組み込み、LLMを呼び出すAPIコールを行い、そのLLMを5回、10回、あるいは20回呼び出すかもしれません。そのため、ツールを使用するクリエイターの数と、彼らのプレイヤーの数、そして彼らが引き起こすであろう使用回数を掛け合わせる必要があります。キャパシティプランニング、負荷予測、QPSの測定を行う際、これらすべてがスケールに対応するための負荷増加に影響を与え、非常に困難な課題となります。

それでは、Robloxで私たちが構築しているものと、そのスケールを実現するために学んだ教訓について、もう少し詳しく見ていきましょう。まず、私たちが提供しているAPIの一例を紹介します。これは資産を翻訳できるAPIです。静的なテキストを取り、翻訳を実行します - 以前は人手による翻訳でしたが、最終的に翻訳モデルに置き換えられました。これは開発者が事前生成されたテクスチャーや事前生成されたFAQなどの静的コンテンツを翻訳するのに役立ちましたが、私たちは開発者が動的コンテンツを翻訳できるようにしたいと考えました。例えば、エクスペリエンス内でのチャット、クエストやストーリーの生成、テキストやテクスチャーに埋め込まれたあらゆる種類のコンテンツなどです。そこで、リアルタイムチャット翻訳に使用していたモデルの1つを取り上げ、APIの背後で開発し、クリエイターに提供しました。

これが、プレイヤー対クリエイターのスケールを考える際の私たちの状況です。少数の静的資産の翻訳から、数十万の同時接続ユーザーを抱えるエクスペリエンスにプラグインできるようになり、そのすべてのコンテンツをリアルタイムで翻訳する必要があります。

アーキテクチャの概要を簡単に説明させていただきます。この図は現在のRoblox AIプラットフォームの構成を示しています。推論とトレーニングの両方のケースを扱い、様々なモデルをトレーニングしています。レコメンデーション、セーフティ、その他のユースケース向けの小規模なカスタムモデルをトレーニングし、LLMのファインチューニングや他の大規模モデルの事前トレーニングも行っています。スタックの中のツールの一部は標準的なものです。Feature StoreやLLMまたは人手によるラベリングのためのGround Truthシステムなど、すべてを備えています。構造化データと非構造化データのストレージには、Vector DB、内部データベース、Data Lakeなど、さまざまなデータストアを組み合わせて使用しています。MLEはこれらのデータソースを自由に使用できます。

トレーニングに関しては、すべてをKubeflow上で実行し、ほとんどのトレーニングはGPU上で行われます。オンプレミスとAWS EC2コンピュートクラスター間でEPSクラスターをオーケストレーションしています。推論については、KubeflowとKServeを使用した推論エンジンのスタックを持っています。TGIやTRTB LLMなど複数のエンジンを実行していますが、現在は主にvLLMに依存しており、その優れたパフォーマンスと機能性から、vLLMの改善に積極的に貢献しています。また、Rayを使用したバッチ推論もサポートしています。クラウドプロバイダー、異なるLLM、さまざまな種類のモデルを組み合わせることができる独自のゲートウェイを構築しました。

それに加えて、実験を実行するための社内プラットフォームなど、一般的なMLワークフローのためのツール群も用意されています。コスト追跡も行っており、誰がリクエストを行い、頻度はどのくらいで、チームやグループごとのコスト配分はどうなっているかなど、すべてのリクエストを追跡しています。各モデルやAIのユースケースに対して課金していないため、クラスター全体での使用状況とコストを厳密に管理する必要があります。可観測性については、Weights and BianesやAriseなどのオープンソースソリューションを含む様々なツールを使用しており、社内のA/Bテストプラットフォームも備えています。

ここまでアーキテクチャとシステムについてご説明しましたが、ここからは私たちが直面している課題についてお話ししましょう。最初の課題は、異なるAI推論のユースケースをどのように組み合わせて管理するかということです。RobloxでAIが始まった当初は、他の企業と同じような状況だったと思います。会場の皆さんにお聞きしたいのですが、OpenAIやAnthropicを使用している方、あるいは複数のプロバイダーを使用したり、オープンソースとプロバイダーを組み合わせて使用したりしている方はいらっしゃいますか？複数のプロバイダーを使用している方は手を挙げていただけますか？あまりいませんね。オープンソースモデルのみを使用している方は？少しですね。AnthropicやOpenAIなどのプロバイダーのみを使用している方は？

私たちの場合、最初はプロバイダーのみを使用していました。パーソナライゼーションなど、自社で訓練する小規模なモデルから始まりました。その後、他のユースケースも組み合わせ始めました。主にコストの観点から、LlamaのようなオープンソースのFoundation Modelを活用することにしました。私たちが発見したのは、オープンソースモデルをホスティングすると、サービス提供のコストがプロバイダーのコストの約10〜26%で済み、現在では10%に近づいているということです。私たちのプラットフォームでは、ホステッドプロバイダーを使用するよりも、オープンソースモデルを実行・デプロイする方が大幅にコスト効率が良いのです。もちろん、オープンソースモデルの品質面ではトレードオフがあります。

しかし、それは各本番ユースケースで検討できるトレードオフです。私たちの場合、データのプライバシーが重要な懸念事項でした。安全性に関するデータなど、非常にセンシティブなデータについては、Roblox外部に送信したくないものがありました。また、さまざまなサイズやバージョンのモデルを試す必要がありました。モデルは繰り返しリリースされるため、複数のバージョンを維持し始める必要があり、さらに異なる組み合わせも試したいと考えていました。

この課題を解決するため、私たちはゲートウェイアーキテクチャパターンを採用しました。異なるユースケースやモデル用に複数のAWS EKSクラスターがありますが、その推論クラスターの前にゲートウェイを構築しました。このゲートウェイはリクエストを受け取り、ChatCompletionsなど、OpenAIプラットフォームとまったく同じようなインターフェースを提供します。バックエンドでは、HTTPリクエストやgRPCを使用して、Robloxでサポートされているすべての言語用のクライアントを作成しました。Python、Go、C#をサポートし、Robloxエンジンで実行できるLuauバージョンも構築しました。このシステムは、あるプロバイダーや別のプロバイダー、Llama 3.1を搭載したクラスターA、Llama 3.2を搭載したクラスターBなど、プロバイダーを多重化し、Roblox開発者にとってできる限り透過的に動作するようにしています。

私たちは、開発者がワークフローで使用できるPythonベースのRoblox ML SDKを構築しました。開発者は単にライブラリをインポートし、Completion APIを使用して、ベンダー、モデル、バージョンといういくつかのパラメータを提供するだけです。これらのパラメータを背後で切り替えることで、クラスター、モデル、バージョン間の負荷分散を処理します。異なるエンジンには異なるインターフェースやパラメータがあり、モデルによってパフォーマンスのレイテンシーも異なります。私たちの解決策は、ゲートウェイレベルでこれらを抽象化することでした。開発者は、コストやスケールに大きく影響するこれらの実装の詳細を気にする必要がなく、ゲートウェイですべてを抽象化し、さまざまな試行を可能にするミニマルなインターフェースを提供しています。

オープンソースモデルを使用する際に興味深い課題が浮上しました。それは、異なるワークロードに対して各モデルがどのように比較されるかを検証する必要があったことです。チームは、1秒あたり数万のクエリを処理する必要があり、サービスのコストを90%削減したいという理由で、ホストされているAPIからオープンソースバージョンへの切り替えについて問い合わせ始めました。各チームにはGPUコンピュートの利用量を決定する予算がありますが、最終的には、彼らはユースケースのコストを削減したいと考えています。私たちは切り替えを非常に簡単にしました - 別のオープンソースモデルに切り替えたい場合は、パラメータを変更するだけで、コンピュートの予約やクラスターのデプロイメントを私たちが処理します。

チームがこれらの切り替えを行う際には、多くの変数が変化します。単にモデルを変更するだけでなく、マシンタイプ、推論エンジン、EKSバージョン、NVIDIAカーネルドライバーに基づいてパフォーマンスが変化します。私たちは最終的に、多数のEKSクラスター、3つの推論エンジン、数十のモデル、そして異なるAMIバージョンという広範な組み合わせを持つことになりました。この複雑さの管理を軽減するのに役立った解決策の1つが、AWS Deep Learning Containersでした。これについては後ほど詳しく学びましょう。では、Ivanにバトンタッチして、また戻ってきます。ありがとう、Ivan。ありがとうございます。

AWS Deep Learning Containersによる運用負荷の軽減

AWS Deep Learning Containersは、特にRobloxにとって、これがなければ存在したであろう膨大な運用負担を軽減するのに役立ちました。このトークとRobloxのワークロードのテーマである「スケール」について掘り下げたいと思います。スケールについて重要なのは、単に大きな数字だけではないということです。多くの異なる要因があり、Ivanが指摘している「スケールファクター」や「乗算的なスケール」という概念が非常に気に入っています。なぜなら、まさにここでも同じことが起きているからです。異なるプラットフォーム、ライブラリ、モデルなど、すべてが掛け合わさって、指数関数的にスケールする組み合わせの問題となっています。

これは人的リソースの問題でもあります。実際にこれを解決する必要があるのは、実在のエンジニアたちです。彼らはMLエンジニアやデータサイエンティストとして非常に価値のある人材です。新しいモデル、新しいプラットフォーム、新しいタイプのハードウェアを導入しようとすると、サポートしなければならないスタックの数は増える一方です。そこでAWS Deep Learning Containersの出番です。 Deep Learning Containersは、AWSが提供する事前パッケージ化されたMLフレームワークのコンテナイメージで、すぐに使用できる状態で提供されています。本番環境での運用に重要な互換性、セキュリティ、パフォーマンス、安定性について検証済みで事前テスト済みであり、最も重要なことに、無料で提供されています。

これにより、Robloxは新しいモデルの採用、新しいハードウェアの導入、新しいクラスターの構築、新バージョンへのアップグレードなど、その都度発生する細かな問題に対処する代わりに、事前にパッケージ化され検証済みの AWS Deep Learning Container を即座に利用できるようになりました。 Deep Learning Container のスタック構成とその位置づけについて詳しく見ていくと、下層にAMIやEC2インスタンス、あるいは同様のコンピュート基盤があり、その上でDeep Learning Containerが動作しています。現在50種類以上のDeep Learning Containerが提供されており、その数は増え続けています。

含まれているコンポーネントの例を見てみましょう。事前インストールされた一般的な機械学習ライブラリ、PyTorchフレームワーク、使用しているコンピュートプラットフォームのパフォーマンスを最適化する設定済みのネットワークドライバー、さらに低レベルではNVIDIAのディープラーニングライブラリなどです。これは一例に過ぎず、50種類以上のコンテナが用意されています。この組み合わせの問題がどこから生じるのか見てみましょう。サポートが必要な異なるフレームワークに対応するためのオペレーティングシステムの変更などが考えられます。Andy Jassyが今週初めのキーノートで述べたように、私たちはTensorFlowが主要なフレームワークになると考えていましたが、突然PyTorchが登場し、現在では最も人気のあるフレームワークとなっています。

Deep Learning Containerを使用することで、Robloxは社内要件が変更された際に柔軟に対応することができます。特にハードウェアの部分に注目したいのですが、ご存知の通り、GPUは制約のあるリソースで、慎重な管理が必要です。より多くの柔軟性とオプションがあることで、より多くのキャパシティを確保できます。これはAWSが推奨する一般的なパターンです。つまり、柔軟に対応できる場合は、異なるインスタンスタイプや異なるコンピュートプラットフォーム、オプションを活用するということです。Deep Learning ContainerによってRobloxは、わずかな統合プロセスを除いて、瞬時に新しいプラットフォームを採用し、他の場所にあるかもしれないキャパシティを活用できる機動性を手に入れました。講演前にIvanと話していた際、AWS Deep Learning Containerから得られたパフォーマンスの指標といくつかの結果について話が出ました。

Deep Learning Container導入以前は、Amazon EKSの新バージョンへのアップグレードに数ヶ月もかかっていたことを私は知りませんでした。すべてのコンテナイメージには旧バージョンに依存するライブラリがあり、それらすべてを更新するか、新バージョンでも動作することを検証する必要があり、これによって開発の機動性がほぼ停止状態になっていたのです。

Deep Learning Containerを使用すれば、新しいコンテナイメージを指定してダウンロードし、クラスター上で起動するだけで準備完了です。CVEセキュリティスキャンも事前に検証済みです。そのため、機動性が向上するだけでなく、パフォーマンスも向上します。最新のライブラリを使用することで、各アップグレードバージョンがもたらすパフォーマンスの改善も理想的に得られます。そして当然ながら、これらすべてがTCOの低減につながります。Robloxのような規模で展開する場合、スケーリング係数を少しでも最小化できれば、大きな効果が得られるのです。

これが本当にこの話の教訓です - 小さな不便、常につまずいてしまう道のちょっとした凸凹を取り除くということです。規模が大きくなるにつれて、それらの小さな支障は山のように大きくなっていきます。これはRobloxにとって、それらを平坦にする方法の1つです。小さな一部分ではありますが、すべての部分が重要で、長期的には積み重なっていくのです。ということで、私が少し触れた自動スケーリングとキャパシティの制約について、もう少し詳しく掘り下げていくために、Ivanにバトンを渡したいと思います。

キャパシティ制約下でのスケーリング戦略

皆さん、こんにちは。私たちが測定していたことの1つは、Deep Learning Containersが異なるバージョンをどのように管理しているかということでした。ここで少し昔の話をさせてください。初期の頃、私たちは異なるバージョンを実行する数十のEKSクラスターを持っていました。コンテナについて考えてみると、AWSが事前に用意したイメージ、つまりコアスタックを持つAMIイメージを提供してくれます。NVIDIAのGPU用のカーネル、ソフトウェアバージョン、テスト済みで検証され、すべてがAMIとしてパッケージ化されているのです。そのため、スタックがすべて揃ったAMIを自動的に入手できます。以前は、更新に何週間もかかり、古いソフトウェアを使い続けていました。事前にパッケージ化されたものを使用することで、かなりの時間を節約できました。ちなみに、皆さんがコンテナを使用しても私には手数料は入りませんよ。

では、さらなるスケーリングの課題についてお話ししましょう。最初の課題は、キャパシティの制約がある場合のスケーリング方法です。会場の皆さんに手を挙げていただきたいのですが、EC2 GPUで計算を実行している方と、ほぼ無制限の計算能力を持つオンプレミスのインフラを使用している方は何人いらっしゃいますか？このケースでクラウドインスタンスを使用している方は？かなりの数の方がいらっしゃいますね。おそらく一部の企業は、お金を生み出す機械のように、GPUを購入して裏庭に置き、24時間365日稼働させ、そして多くのコンピューターを管理するスケールの問題に直面することになるでしょう。これは難しい問題ですが、良い問題と言えます。

私たちはそのカテゴリーには属していません - これらのGPUを入手するためにクラウドを使用しており、キャパシティには制約があります。場合によっては、特定のモデル、特定のタイプのGPUが必要になることがあります。最近はキャパシティの制約が少し緩和されてきていますが、まだ存在しています。H100が必要な場合、数台確保するのに何週間も待たなければならなかった時期は、そう遠い昔のことではありません。これが私たちの課題でした - 特定のモデル、特定のGPUを持つこれらのクラスターがあり、オンデマンドのキャパシティはなく、それらのクラスターを本番環境に投入しなければなりませんでした。

ここで重要なのは、一度外部の利用者、外部の開発者、外部のクリエイターにリリースすると、彼らは「5週間後に製品を使用します」といった事前通知をくれないということです。彼らはすぐに使用したいのです。これは私たちのシステムの1つからのロードグラフです。数日間でこのGPUクラスターのロードがどのようになったかを示しています。利用率が急上昇する部分が見えますね。このクラスターのキャパシティを増やす必要がある場合に備えて、私たちは慌てることになります。GPUをどこから調達するか。まるで、すべてのカーペットをめくり上げ、他のチームから借り、上司にGPUの解放をお願いするようなものです。とにかく何とかしなければなりません。うなずいている方々が見えますね。これが何ヶ月も続いていた日常で、しばらくの間はこの状況が続くかもしれません。これにどう対処すればよいのでしょうか？

私たちのケースでは、これらのユースケースには何らかのオートスケール・ソリューションが必要だということがわかっていました。負荷のスパイクが発生した時により多くのコンピュートリソースが必要になりますが、オンデマンドでリソースが確保できない、あるいは十分な速さで確保できないという状況です。私たちが直面しているのは、「Thundering Herds（雷鳴の群れ）」と呼ばれる現象です。例えば、ゲーム内のイベントで、土曜日の午前9時に新しいアイテムをリリースするといった場合です。数日前に予告はありますが、午前9時になると突然ユーザーが殺到し、同時接続ユーザー数が2倍になったりします。そのため、複数のクラスター、大規模モデル、そして異なるソリューションを組み合わせて負荷をスピルオーバーできるようなソリューションが必要になります。

そこで私たちが構築したのが、負荷スピルオーバーまたはヘテロジニアスクラスターと呼ぶものです。異なるユースケース向けに事前にプロビジョニングされた異なるクラスターを用意し、可能な限り多くのキャパシティを確保しようとしています。そして、独自のオートスケール・ソリューションを構築しました。例えば、P5を実行するEKSクラスターがあります。このオートスケールは空のインスタンスを見つけることは決してありませんが、一応用意されています。2番目のクラスターは、別のユースケース向けで、Inferentiaで量子化モデルを実行し、キャパシティを確保しています。3番目はホストエンドポイントへのフェイルオーバーかもしれません。ゲートウェイには、特定の負荷しきい値に達した時点で、異なるクラスター間で負荷を再ルーティングし始めるロジックを実装しています。

また、クラスターAからクラスターBに負荷を送信しても、クラスターBがその時点で空いていないか利用できない可能性があるため、クラスターCにフェイルオーバーする必要があることも考慮しなければなりません。これが負荷スピルオーバーの問題に対する私たちの解決策です。異なるクラスターとそのキャパシティを認識し、動的にルーティングできるシステムを構築するのです。そしてこれが、私たちが直面している3番目の問題につながります。今や、これらすべてのクラスター、異なるGPUタイプ、異なる制約があり、それぞれが異なる使用率、異なる密度で利用されている状況です。

これは、ある時点で私たちが実行していた異なるGPUとコンピュートタイプのスナップショットです。文字通り、担当者に何が入手可能かを尋ね、あるものは何でも使うという状況でした。選り好みはできない状況だったのです。結果として、GPUやマシンタイプの大きな多様性を抱えることになりました。これらのユースケースは特定のAPIやサービスに割り当てられていました。例えば、あるクラスターは安全性モデレーション用、別のクラスターはリアルタイム翻訳用といった具合です。開発者のテスト用に混合利用されているものもあります - これは遊び用クラスターです。時には、チームが「Llama 3.1 405億パラメーターモデルをテストする必要がある。自分たちのユースケースではより高品質だと思うから」と言ってくることもあります。その場合、通常のクラスターよりも高価になる可能性が高いですが、P5を確保してプラグインし、テストを実行させます。ただし、実際の使用率は低いです。他のクラスターにはクリティカルなワークロードがあり、クラスタースピルオーバーを実装する前は、キャパシティを確保する必要があるなどの理由で、実際に過剰プロビジョニングが必要でした。これが本番環境でのそうしたクラスターの様子です。GPU使用率は平均して20%程度で、かなり低い状態でした。GPUはかなり高価なものです。

私たちにとっての問題は、非常にコスト効率的である必要があるということです。GPUの数が限られているため、GPUの低使用率を放置することはできません。クラスターの密度をどのように高められるか考える必要があります。ここでの重要な教訓は、オンラインバッチング、オフラインバッチング、あるいはその両方の組み合わせにかかわらず、できる限り多くのバッチング処理を実装するようチームに促すということです。オンラインバッチングでは、オンラインでどれだけ多くのリクエストを取得し、それらをまとめて推論エンジンをできるだけ密にパックできるかに焦点を当てています。

私たちは、Rayを使用したバッチ推論パイプラインを持っており、バッチユースケース向けに異なるAPIを提供しています。各チームと協力して推論のユースケースとワークロードを検討し、リアルタイムのレスポンスが絶対に必要でない場合には、バッチ処理への移行を提案しています。既存のクラスターに異なるバッチユースケースを混在させることで、共有GPUプールを作り、利用率を劇的に改善することができました。私たちが「10倍の改善」と呼んでいるものを達成し、利用率を20%から、ほぼ100%、少なくとも80%から100%の間まで向上させました。可能な限りバッチ処理を実装することで、クラスターの密度を高め、大幅なコスト削減を実現できます。

本番環境でのAIモデル評価：課題と解決策

最後の課題は、そして私のお気に入りの一つですが、実際の本番環境でのモデル評価についてです。これは興味深い話題ですが、ここで質問です - モデルが本当に改善されたかどうかをテストする際に苦労した方は手を挙げてください。では、それが簡単だった人は手を挙げてください。誰も手を挙げていませんね - 素晴らしい。私たちにとっても簡単ではありませんでした。品質にせよパフォーマンスにせよ、モデル評価には明確に定義された方法がありません。パフォーマンスに関しては、どの企業やベンダーのスライドでも必ず引用される4つの標準的な指標があります：First Tokenまでの時間、Output Tokenの生成時間、レイテンシー、そして総スループットです。

私たちが発見したのは、ベンダーや企業が一般的に報告する重要度が、実は逆転しているということです。私たちはスループットが最も重要だと考えています。なぜなら、本番環境で最も重要なのは、いかに費用対効果が高く多くのユーザーにサービスを提供できるかだからです。品質や体験を損なうことは避けたいものの、スループットが重要なのは、クラスターをどれだけ密にできるか、同時にどれだけ多くのユーザーにサービスを提供できるかを決定するからです。ユーザーは通常、トークン生成が10-20%遅くなることは許容できますが、1台のマシンからより多くのスループットを得られれば、それだけコストを抑えることができます。

レイテンシーは2番目に重要です。システムが遅すぎるのは望ましくありません。Output Tokenの時間とFirst Tokenまでの時間も重要です - ユーザーにシステムの利用開始まで1分も待たせたくはありません。ただし、場合によっては待機が許容されたり、プリウォーミングを実装したり、他の方法でレイテンシーを隠したりすることができます。例えば、音声アプリケーションでは、アシスタントが生成された応答を返す際に、「うーん、考えさせてください」といった応答を聞くことがあります。これらの音声の断片をキャッシュしたり、事前に生成しておくことで、実際にはリアルタイムではないのに、リアルタイムな対話をしているような体験を作り出すことができます。これがパフォーマンスとスループットが最重要である理由についての私たちの学びの一つでした。次に私たちが発見した問題は、業界全体でより大きな問題だと思われる品質評価についてです。

これは現在、私たちが様々なユースケースやモデルを試している中で、積極的に取り組んでいる課題です。現在私たちが観察しているのは、ほとんどの評価セットが、MMMLUやChatbot Arenaのような学術的なセットに基づいているということです。これらは論文やモデルで主に使用され、報告されているものです。これらは質疑応答、科学的事実、数学、法律、医学といった特定のトピックに焦点を当てた、非常によく確立されたユースケースです - これらは一般的なデータセットとしてはかなり優れています。

ただし注意点として、実際の本番環境での使用ケースでは、これらの質問の5%程度しか活用されない可能性があり、数学や医療に関するトピックは全く含まれないかもしれません。最近、ある研究者がChatbot Arenaのスコアリングシステムのバリエーションに関する論文を発表し、評価データセット自体でモデルをFine-tuningすることで、評価におけるパフォーマンスを向上させられることを発見しました。MMULUやChatbot Arenaのデータセットを入手し、モデルをそれらのデータセットでFine-tuningすると、実際のモデルの精度が大規模モデルほど高くなくても、MMULUやChatbot Arenaで非常に良いスコアを出せるようになります。

これらの評価基準は、テストで高得点を取れるように調整することができます。これは、学生が授業で試験を受けるのと似ています - 運転免許試験の問題を事前に暗記すれば、実際の運転が上手でなくても非常に良い成績を取ることができます。私たちが気付いたのは、独自のデータセットを収集する必要があるということです。私たちは現在、ロギングシステムを構築し、推論から得られるすべてのデータを収集していますが、ポリシーの関係で、どのデータをログに記録し、どのデータでトレーニングできるかについては許可を得る必要があります。

私たちは、モデル自体をテストするためのフレームワークで使用する派生テストデータセットを構築しています。MMULUとChatbot Arenaでテストを行い、さらにNPCファクター、対話、特定の安全性などに関する独自のデータセットでテストを行い、スコアを提供することができます。先週の時点で、最も役立っていた2つの方法があります：1つは、人間のラベラーにサブセットを通すことです - コストはかかりますが、GPT-4で生成した質問をモデルに通し、再度GPT-4に通して回答を得て、それをラベラーに渡してランク付けを依頼します。

また、LLMをジャッジとして使用することもできます - 同じプロセスですが、LLMに渡して、自分で開発した一連の評価基準に基づいて質問を採点するように指示します。これには、回答の一貫性、安全性への配慮、元の質問に基づく正確性などが含まれます。これに基づいてスコアを生成し、異なるオープンソースモデル同士の比較や、異なる量子化バージョンのモデルの比較を行い、MMULUやChatbot Arenaからの評価基準と組み合わせています。最近、包括的でデータセットを追加できるStanfordのフレームワークであるHELMのテストを開始しました。

最後に、常にベンチマークを継続することが重要です。これは現在のAI業界では標準化されていない側面の1つです。CPUのベンチマークは比較的標準化されており、GPUの評価に使用する3D Markのようなツールやシステムが一般的に使用されています。AIではそうではないため、異なるベンダーが異なるパフォーマンスコスト比や数値を報告するので、データセットを自分で実行する必要があります。まとめると、

プロダクション環境でのユースケース運用から得られた重要な教訓をいくつかご紹介します。オープンソースモデルの品質は、各AIプロバiderが提供するホステッドソリューションに着実に近づいています。社内チームが使用パターンやロギング、その他のメトリクスを確認できるよう、使用状況の透明性を確保することが重要です。オープンソースモデルを使用する際は、MMMLUなどの評価指標では高スコアを得られない可能性がありますが、実際のプロダクション環境での使用ケースやテストデータでは、かなり近い性能を発揮し、はるかにコスト効率よく運用できる可能性があることを理解しておく必要があります。

特にAI関連のバージョン管理は非常に複雑になる可能性があり、私たちにとって大きな課題でした。バージョン、モデル、クラスター、Inference Engineカーネルなどのコンポーネントに関する複雑さと作業負荷を管理・削減することで、大幅な時間節約につながります。第三に、可能な限りクラスターを密に活用するよう心がけてください。私たちの場合、クラスター共有において最も重要な要因の1つがバッチ処理でした。クラスターをできるだけ効率的に活用できるよう、負荷を効果的に分散させることも非常に重要でした。

パフォーマンスと品質は依然として大きな課題ですが、これらの分野では興味深い進展が見られています。プロダクション環境でのユースケースには、独自の評価データセットを構築することが非常に有効です。それでは、本日のトークにご参加いただき、ありがとうございました。私とDominic Millsはこの後も会場におりますので、さらに詳しくお話ししたい方、ご質問のある方、その他のリソースについて知りたい方は、QRコードをご利用ください。最後に、朝早い時間にもかかわらずご参加いただき、ありがとうございました。

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