re:Invent 2024: S3活用でAI革新を実現 - Canva、Bria AI、Anthropicの事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Data on AWS: The key to success for 3 AI innovators (STG208)
この動画では、Amazon S3を活用してAIモデルのトレーニングやデータ処理を大規模に行っている3社の事例が紹介されています。Canvaは300ペタバイト以上のユーザーコンテンツを管理し、Content Moderationプラットフォームを構築。Bria AIは5ギガバイトのParquetファイルを活用し、数ペタバイト規模のデータを処理してGenerative AIモデルのトレーニングを実施。Anthropicは200ペタバイトのデータセットを2週間で処理し、S3 Express One ZoneやCross-bucket Replicationを活用して1秒あたり1,500ギガバイトという驚異的なスループットを実現しています。3社とも、S3の柔軟なスケーラビリティとIntelligent-Tieringによるコスト最適化を高く評価しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSストレージを活用したイノベーション：セッション概要
はい、こんにちは。月曜日の午後、本日のセッションへようこそ。今週は多くのAWSのスピーカーからお話を聞く機会があると思いますが、本セッションでは私たちの素晴らしいカスタマーの方々をお招きして、AWSとAWS Storageを活用してどのようにイノベーションを起こしているかについてお話しいただきます。私はAmazon S3のProduct Managerを務めるAndrew Kutsyで、本日のホストを務めさせていただきます。本日は、CanvaのJosh Smith、Bria AIのBar Fingerman、そしてAnthropicのNova DasSarmaにご登壇いただきます。私個人としても、データがイノベーションを推進する方法について多くの議論ができる本日のセッションを大変楽しみにしています。
今日は、お客様が取り組んでいる3つのテーマに焦点を当てます。これらは、私が日々お客様とお話しする中で非常によく出てくるテーマです。CanvaとBria AI、Anthropicから、これらの分野がどのように進化しているのか、そしてなぜそれらが彼らのビジネスにとって重要なのかについてお話しいただけることを嬉しく思います。まず、データ品質の重要性と、大量の生データから高品質なデータセットを作成するために、この1年で確立されたパターンについてお話しします。次に、ストレージから最大限のパフォーマンスを引き出し、コンピュートを活用する方法について。そして、大規模なスケールを実現するために、ビジネスのニーズに応じて柔軟にスケールできるよう、今から考えておくべきことや実施すべきことについてお話しします。
データキュレーションとスケーリングの重要性
私は、この素晴らしい3人のお客様のスピーカーの前座に過ぎませんが、まずは私がこれらの課題をどのように考えているかについて、少しメンタルモデルをお話ししたいと思います。まず、私たちが皆直面しているかもしれない課題から始めましょう。それは、大量の生データの取り扱いです。販売取引から顧客とのやり取り、IoTストリーム、画像カタログまで、あらゆるものが含まれます。そして多くの場合、組織内のチームは、ビジネス上の質問に答えたり、分析的な問題を解決したり、Machine Learningモデルの微調整に適切なデータを見つけたりするために、これらのデータすべてを必要としているわけではありません。多くの場合、必要なのはデータのクリーンで焦点を絞ったビューなのです。
ここで、データキュレーションという考え方が出てきます。これは、特定のタスクのためにより専門的なデータセットを構築・作成することです。今週、データプロダクトについて耳にする機会があると思いますが、これは組織内の他のプロダクトと同じように、データをプロダクトとして扱うという考え方です。大量のデータを一回限りで使用するのではなく、目的に応じてキュレーションされたデータコレクションを構築するのです。例えば、機能の採用状況について質問に答えようとするProduct Managerや、特定のモデルトレーニングタスクに適切なデータを見つけようとするML研究者のためのものです。本日は、Canva、Bria AI、Anthropicが、彼らの大規模なデータコレクションを研究者にとってより使いやすく、アクセスしやすいものにした実践的な方法についてお話しいただきます。
パフォーマンスに関して、お客様は通常、集約されたスループットを大規模に柔軟にスケールできることという文脈で考えています。コンピュートがどこにあるかに関係なく、ほとんどのお客様が最適化しようとしているパターンは、Amazon S3や AWS File Servicesのようなストレージとコンピュートの間に存在する利用可能な帯域幅をいかに最大限活用するかということです。多くのお客様にとって、ストレージは実際には全体のコストのごく一部に過ぎません。Machine Learningのトレーニングワークロードを考えてみると、そのコストの大部分はGPUの使用によって発生していることがわかります。
ここまでお話ししてきましたが、重要なポイントは、ストレージのパフォーマンスにボトルネックがある場合、エンドツーエンドのワークロード全体が停滞し、完了までに時間がかかってしまうということです。コンピュートがアイドル状態になり、結果として請求額の大部分を占める部分が増加してしまいます。S3に関して言えば、本日お話しする3つの基本的な考慮点があります。それは、リクエストレートのパフォーマンス（1秒あたり、または単位時間あたりに実行できるリクエスト数）、リクエストごとのスループット（各リクエストで1秒あたりに転送できるバイト数）、そしてファーストバイトレイテンシー（各リクエストで、最初のバイトがクライアントに届くまでの待ち時間）です。これらの特性を最適化するための方法は多くありますが、パフォーマンスは非常に深い主題でもあります。木曜日に開催される「Amazon S3でのストレージパフォーマンスの最適化」セッションへの参加をお勧めします。このQRコードをスキャンすると、詳細をご確認いただけます。
最後にもう1点、スケールについてお話しさせていただきます。これは、これまで話してきたすべての自然な発展形です。アプリケーションは確実にスケールしていきますが、私たちのチームが絶え間なく注力しているのは、ストレージサービスが確実に機能するようにすることです。数百のオブジェクトから数百万、数十億のオブジェクトへとスケールする際に、実際にこのことについて考える必要がないようにしています。例として、Amazon S3のS3 Intelligent-Tieringというストレージクラスを挙げてみましょう。S3 Intelligent-Tieringは、データのアクセスパターンの変化に基づいて、アクセス層間でデータを自動的に移動し、コストを最適化します。ワークロードがギガバイトからテラバイトへとスケールする際も、コストとパフォーマンスのトレードオフを手動で最適化したり心配したりする必要はありません。
Canvaのデータ戦略：Trust & Safetyの実現
それでは、データのキュレーションとスケールへの対応について話していただくために、Josh Smithさんをステージにお招きしたいと思います。月曜日の午後4時ということで、皆様ご参加いただきありがとうございます。私はJosh Smithと申します。Canvaのエンジニアリングマネージャーで、Core Dataチームを率いています。私たちは当然、データに関するすべてのことに大きな関心を持っており、本日はTrustとSafetyに関する興味深いトピックについてお話ししたいと思います。
Canvaをご存知ない方のために説明させていただきますと、Canvaはオンラインの共同ビジュアルデザインツールです。自分のコンテンツを使って、ほぼどんなものでもデザイン、アップロード、作成することができます。PowerPointに対して少し意地悪な言い方になりますが、プレゼンテーションに関してはPowerPointよりもはるかに優れており、今晩PowerPointを使わなければならないのは残念です。しかし、これは人々が何でもデザインできるツールです。強調したいのは、実際にユーザーが自分のコンテンツ、自分がアップロードしたものを使用して、Canva.comで独自の作品を作り出しているということです。
多くの企業と同様に、私たちは最近、AIをすべての業務の最前線に取り入れるというミッションを掲げています。社内では「AI Everywhere」と呼んでいますが、実際に120以上のMLベースのMicroservicesを運用しており、まさにあらゆる業務の中心となってきています。Canvaは実は比較的若い企業で、2012年に創業しました。謙虚な始まりから、現在では月間アクティブユーザー数が2億人を超えるまでに急成長しました。この2億人のユーザーは300億以上のデザインを作成しており、このユーザー数とその活動の爆発的な増加は、コンテンツの大幅な増加につながっています。現在、S3上に300ペタバイト以上のデータを保存しており、想像できると思いますが、それに伴う興味深いエンジニアリングの課題には事欠きません。
ここで疑問に思われるかもしれません。私たちは企業として面白いAIの取り組みをしたいと考えており、このような膨大なユーザーコンテンツがあるのだから、単純にそれを使ってML関連の取り組みができるのではないか、と。しかし、エンジニアリングの面白い課題の多くがそうであるように、残念ながらそれほど単純ではありません。そのデータの使用に関して、信頼性と安全性を確保したシステムを構築する必要があるのです。
ユーザーの話に戻りますと、2億人の月間アクティブユーザーの中には、Canva.comを利用する様々な立場の人々がいることを考慮する必要があります。個人のコンテンツクリエイター、非営利団体、教育機関、大企業、そしてその中間に位置する様々な組織があります。私たちが真剣に考えなければならない問題は、これらすべての人々にとって安全なプラットフォームをどのように確保するかということです。
安全性について議論を始めると、最初に直面する問題の一つがContent Moderationです。Canvaにアップロードされるコンテンツの中には、サイト上に掲載したくないものもあります。私の犬が上下逆さまに転がっている少し面白い写真を例として挙げましたが、これは私たちのサイトに望まないコンテンツの種類を示す軽い例えです。これに対して何も対策を講じなければ、深刻な問題につながる可能性があります。AIに関して、特に強調したいのは、このような不適切なコンテンツが管理されないまま、MLモデルの学習データとして使用された場合、望ましくない結果を生み出す可能性があるということです。ここで言う不適切なコンテンツとは、NSFWコンテンツだけでなく、ヘイトスピーチ、誤情報、詐欺など、対処が必要な様々な問題を含みます。
この課題に対処するため、各チームが独自のContent Moderationソリューションを考案するのではなく、すべてのCanvaサービスが利用できる中央集権的なモデレーションプラットフォームを構築しました。アーキテクチャ図を見ていただくと、同期的ではなく非同期的に処理が行われていることがわかります。新しいコンテンツが入ってくると、それをキューに入れてワーカーに処理させます。そのコンテンツに対して複数の異なるモデルを実行し、そのコンテンツが安全か否か、あるいは人間のモデレーターの介入が必要かどうかを、ある程度の確信度で判断します。NSFWの例では、Amazon Rekognitionを重要なAWSサービスとして活用しており、規模感を示すと、Rekognitionだけでも1日約7,000万件のコンテンツチェックを実行しています。
重要なポイントは、モデルは信頼度を示すことはできても、保証を与えることはできないということです。何かが良いか悪いかを100%確実に判断することはできないため、時には人間のモデレーターが介入する必要があります。もう1つの課題は、モデルは教えられたこと、あるいは認識するように設定されたことしか検出できないということです。ユーザーが不適切なコンテンツを直接報告してくることが多く、そういった不適切なコンテンツは同様のものが集まって見つかることが頻繁にあります。問題のある項目が1つだけでなく、よく似た一連のコンテンツを調査する必要が出てくるのです。私たちはこのレビューとコンテンツのフラグ付けのために、社内で様々なツールを開発しています。特に興味深いのは、類似コンテンツにフラグを付けるシステムを構築したことです。サイトに掲載すべきではないと思われるコンテンツを1つ見つけた場合、それに似た一連のコンテンツを見つけることができます。
では、これはどのように機能するのでしょうか？私のもう1匹の犬のMaxの2枚の画像を例に見てみましょう。これらは同じ画像ですが、右側のMaxの写真には鼻に小さな緑の点があるという違いがあります。人間の目には基本的に同じように見えますが、残念ながらマシンにとっては、これら2つのコンテンツの生のハッシュ値を取ると、全く異なるハッシュになってしまいます。ハッシュの仕組み上、入力の微細な変化が出力に大きな違いをもたらすためです。そのため、類似コンテンツや同一のものにフラグを付けたい場合、MD5ハッシュは適切な方法とは言えません。
私たちは実際、Perceptual Hashingと呼ばれる別のアルゴリズムを使用しています。Perceptual Hashingは非常に興味深いものですが、今はアルゴリズムの詳細を説明する時間がありません。基本的に、視覚的に似ているものを探すのです。この2つの画像間では、ハッシュの違いが実際にはごくわずかであることがわかります。特に注目すべきは2つの緑色の文字です。これら2つのハッシュ間の違いは、本質的に2文字だけであることがわかります。この距離、つまり異なる文字数が小さい場合、高い信頼度でフラグを付けるべきものだと判断できます。
Bria AIのデータパイプライン：ペタバイト規模の処理
これは興味深いですが、どうやってスケールさせるのでしょうか？私たちが実際にスケールを実現するために構築したのは、公開された研究に基づいてDynamoDB上で動作するアルゴリズムです。類似画像の閾値を3文字の違いに設定した場合、そのハッシュをセグメントに分割することができます。44個のセグメントを探すことで、3文字の違いしかない結果を必ず見つけることができます。これは鳩の巣原理と呼ばれる数学的原理に基づいており、少なくとも1つの完全一致が必ず存在することが保証されます。これらのチャンクは、すでに処理済みの画像と新しく入ってくる画像の両方について、DynamoDBに保存します。そして、これらのチャンクのいずれかで完全一致が見つかれば、それは類似画像だとわかります。素晴らしいのは、DynamoDBのget itemコールだけで実装できるため、非常にパフォーマンスが高く効率的だということです。課題あるいはチューニングのパラメータは、チャンクの数です。チャンクが多いほど、より多くのDynamoDBクエリが必要になるためです。このサービスを最初にローンチしたときには、チューニングのプロセスが必要でした。
チャンクの数が多すぎたため、Amazon DynamoDBへのクエリが多くなりすぎてしまい、チャンクの数を減らすことを検討する必要がありました。
その例から少し話を戻しましょう。安全性について少し触れましたが、今度は信頼性についてお話ししたいと思います。 信頼というのは非常に興味深い概念です。ユーザーは私たちにデータを預けており、私たちはそのデータを適切に扱っているということを信頼してもらう必要があります。 Canvaでは、ユーザーが不快に感じることは一切行わないというスタンスを取っています。私たちは、すべてのユーザーが自分のデータの使用について同意するかどうか、自分で判断できるように権限を与えたいと考えています。これは、プラットフォームとしてユーザーの信頼を維持し、ユーザーの意思を尊重する上で極めて重要だと考えています。
これが重要なのは、ユーザーの意思だけでなく、法的な観点からも同様です。GDPRや、子どものデータ処理に関する規制を定めたCOPPAについてご存知の方もいらっしゃるでしょう。これは私たちが日常的に直面するユースケースの一つですが、他にも私たちが何をできて何をできないかを定める規制は数多くあります。私たちは法規制とユーザーの意思の両方を尊重する必要があります。
もう一つの課題は、Data Scientistがこういった事柄に煩わされたくないということです。法的な問題は複雑で、すべてのユーザーのプライバシー設定を考慮するのは困難です。私たちは、Data Scientistには本来の目的である機械学習の開発に集中してもらい、彼らの時間を効果的に使ってもらいたいと考えています。 これを実現する一つの方法が、プラットフォームの活用です。ML Dataset Serviceと呼ばれる別のサービスがあり、CanvaのData Scientistがユーザーコンテンツを含むデータセットを必要とする場合、このサービスにアクセスして、必要なユーザーの種類や実験に必要なパラメータを指定します。
サービスにリクエストを送ると、先ほどと同様に非同期で処理され、ワーカーによって処理されます。 そこから、Privacy Preference Serviceと呼ばれるサービスに分散されます。 このサービスには、規制やプライバシーの同意設定の多くが保存されています。実際、データの処理方法に関する500以上の法的ルールを管理しています。特に重要なのは、マーケティング資料をユーザーに送信できるかどうかといった判断です。これはこのサービスが使用されるフローの一つに過ぎず、最も一般的な用途は、マーケティングチームに対してスパムメールを送れない人を通知することです。
これらのプライバシー設定を追跡することは非常に重要で、Data Scientistが指定したパラメータに合致し、データ使用に同意しており、法的に処理可能なユーザーのリストを返します。そこから、データは様々なサービスに分散されているため、ソースサービスに振り分けられます。 これらのサービスは、保存しているコンテンツの種類に応じて名付けられており、Media Service、Video Service、Document Serviceなどがあります。すべてのソース素材に振り分けられ、 そしてML Dataset Serviceによってすべてのコンテンツが使用可能なS3バケットにまとめられます。
この素晴らしい点は、データが格納されるバケットによって、データの更新が確実に行えることです。ユーザーのプライバシー設定が変更された場合や、法規制が変更された場合でも、これらのデータが常に最新かつ有用な状態に保たれることを確実にできます。左側にいるData Scientistは、これらのことを気にする必要がありません - 彼らは単にクールなMLの作業に集中できるのです。彼らからすれば、このサービスにリストを渡すだけで、データセットが返ってくるだけです。私たちが全てを処理できているわけです。 ここでの重要なポイントをまとめますと - この講演の2つの重要なテーマは、トレーニングに入る前に考えることです。トレーニングについては、他の2人のスピーカーが詳しく話してくれます。
トレーニングに入る前に、データの処理方法や、システムに入力されるデータの種類について、しっかりと考える必要があります。望むような方法でデータを扱えるでしょうか？2つ目は、Canvaがプラットフォームに多大な投資をしているということです。モデレーションプラットフォームやMLデータセットのプラットフォームについて話しましたが、これらへの投資は、Data Scientistの作業を加速させるのに役立ちます。彼らは特に意識することなく、正しいことを行うことができます。以上で私の発表を終わります。Andrewに引き継ぎたいと思います。
ありがとう、Josh。では、質問をさせていただきます。 セッションを聞いていて、私が非常に興味を持ち、皆さんも興味があるのではないかと思うことがありました。最後の部分で、ScientistやResearcherが使用する様々なデータセットについて話され、プライバシー設定のデータセットについても少し触れられましたが、このトレーニングワークフローには他にどのようなデータセットが含まれているのでしょうか？その点について少しお話しいただけますか？
最後に話したデータは、ユーザーが投稿する非構造化のコンテンツ、つまり生のデータです。しかし、私たちが扱うデータはそれだけではありません。非常に重要なものの1つとして、製品に組み込まれた分析データがあります。ユーザーがアプリをどのように使用しているか、いつ特定のものをクリックしたか、そこで何が起こったかといったものです。そのため、Data Scientistはかなりの量の分析イベントデータにもアクセスできます。また、ユーザーが特定のサブスクリプションプランを利用しているかどうかなど、他のソースからの構造化データも複製して、クロスリファレンスができるようにしています。これはデータエコシステムの一部ですが、非常に重要な部分です。
Bria AIのデータカタログとアトリビューション：Apache Icebergの活用
では、Bria AIのBar Fingermanをお招きしたいと思います。皆さん、こんにちは。私はBria AIでエンジニアリングを統括しているBarです。私たちは、ビジュアル領域における基盤モデルをゼロから訓練することを可能にする、コアテクノロジーとインフラストラクチャを担当するグループです。Bria AIについて簡単に説明させていただきますと、私たちはビジュアル領域における開発者向けのGenerative AIプラットフォームで、基盤モデルをゼロから訓練しています。 私たちのユニークな点は、完全にライセンスされたデータで訓練を行っていることです。つまり、データプロバイダーとパートナーシップを結び、彼らからデータを提供してもらい、モデルを訓練し、最終的に生成された画像についてデータプロバイダーにアトリビューションを行い、ロイヤリティを還元しています。
私たちが開発した製品は、主に3つのコア製品があります。1つ目は、ライセンス付きオープンソースとして提供するFoundation Modelです。これは、データサイエンスチームや研究チームが独自に開発・Fine-tuningできるように、ソースコードとweightsを提供するものです。2つ目は、APIのサポートです。開発したモデルをAPIでラップし、REST APIとしてお客様に提供します。これには、背景の削除や置換、オブジェクトの消去など、画像と動画の両方における様々な種類の生成AIパイプラインが含まれます。3つ目のソリューションは、生成をカスタマイズする機能です。お客様独自のブランドやIDをお持ちの場合、そのデータを使用して生成スイート全体をお客様のブランドやスタイルに合わせてカスタマイズすることができます。
しばらく前、私たちは取り組むべき課題があることに気づき、社内では「Foundation Model Machine」と呼んでいます。最初に始めた時点で、ペタバイト規模のデータがあり、この膨大なデータを処理して最終的に多くのモデルを生み出すような仕組みを作る必要がありました。現在では約50のモデル、つまりFoundation Modelやコントロールネット、アダプターなどの補助的なモデルを持っています。その仕組みを構築する必要があったので、今日は、これらのモデルをゼロから学習させる能力を実現するために構築したデータの流れとインフラについてご説明します。 先ほど申し上げたように、すべてはデータプロバイダーから始まりました。
私たちは、この分野で長年活躍してきた多くの業界大手と提携しています。Getty Images、Envato、Alamyは、私たちのデータパートナーのほんの一例です。このデータをシステムに取り込む際、まずデータパイプラインを通して処理します。独自のアルゴリズムを使用した自動データパイプラインを作成するために懸命に取り組み、この生データをシステムに取り込んでいます。その後、これらのパイプラインは実際のデータを生成し、データから得られるすべての知見を分類するための表形式のカタログに挿入します。
そこから、スーパーコンピューターに移ります。高スループットの帯域幅で接続された256台のNVIDIA H100 GPUを活用し、1つのモデルに対して2週間、時には数ヶ月かけて学習を行います。ペタバイト規模のデータに対する非常に重い処理作業です。その後、提供するInferenceサービスに移ります。お客様のインフラでモデルを実行することも、私たちのInference機能を使用することもできます。Attribution engineを備えており、各生成に対して、データプロバイダーの元のデータセットまで遡って、顧客ごとの生成ごとに適切なAttributionを提供することができます。これにより、データパートナーがクリーンで安全なデータを提供し続けるインセンティブが生まれ、私たちがモデルを学習してAttributionを返すというサイクルが生まれます。これは私たちが全体的に行っているバリューチェーンです。
それでは各セクションを詳しく見ていきましょう。まず、データパートナーと協力することで、良い基盤から始めることができます。開発者は通常、時間の少なくとも50～60%をコンテンツモデレーション、事前のデータキュレーション、Hallucinationや不確実性への対応、時には望ましくないコンテンツが生成されるのを防ぐための後処理に費やしています。データセットに不適切なコンテンツや商標が含まれていないデータパートナーと協力することは非常に便利です。簡単な例を挙げると、私たちの最新のText-to-imageモデルでNikeの靴を生成しようとした時、確かに靴は生成されましたが、モデルはNikeというブランドを知覚的に理解していません。Nikeブランドを一度も見たことがないため、それを生成する方法を知らず、単にNikeのブランディングのない普通の靴が生成されただけでした。
次に直面した課題は、データを取り込み、モデルのためのインサイトを抽出するデータパイプラインの構築でした。1000台以上のGPUを備えたデータパイプラインを構築しましたが、これらのGPUは学習用のものより安価なAWSのA5（NVIDIA A10 GPU）を使用しています。画像や動画を含む数ペタバイトのMultimodalityデータを取り込み、独自のアルゴリズムとMultimodality LLMを使って画像に関する質問をしたり、説明を取得したり、従来型のComputer Visionクラシファイアを使ってデータを抽出したりしています。分割統治アプローチを採用し、高価なGPUでの学習時ではなく、より安価なGPUで事前に処理を行うことで、コストを4分の1に削減し、学習時間も大幅に短縮できることがわかりました。
これらのデータパイプラインの出力が最終的にすべてのデータの断片に関するインサイトを生成した後、それらを分類し、情報を効果的に整理するという課題に直面しました。
この課題に対処するため、データの分類と高速なクエリ機能の実現に取り組みました。データのサブセットにアクセスしてその内容を理解する必要のあるリサーチチームや、データを分析してデータパートナーと協力する必要のあるデータエンジニアリングチームがいます。受け取った数ペタバイトのデータを可視化するために、多くのタスクを実行する必要があります。そこで、Fire Hose、AWS Glue、クエリ用のAthenaという3つの主要コンポーネントからなるデータカタログを構築することにしました。データカタログの各JSONはFire Hoseを通じてGlueに取り込まれ、バックエンドではApache Icebergテーブルが使用され、そしてAthenaでクエリを実行します。
AWS GlueとApache Icebergを使用することで、いくつかの有益な機能が得られることがわかりました。テーブルフォーマットにより、テーブルに効率的に行を追加できるため、Icebergテーブルが管理してくれることでデータエンジニアリングの労力を大幅に削減できます。もう1つの利点は、高速なクエリ時間のためのパーティショニングです。私たちは画像メタデータを含む多くの小さなJSONファイルを扱っていますが、Icebergはこれらの小さなファイルを大きなファイルに自動的にコンパクト化する機能を持っており、バックグラウンドで労力をかけることなく高速なクエリを実現できます。さらに、アルゴリズムの変更やLLMの更新、クラシファイアの調整を頻繁に行うため、機能が壊れたり不適切な分類が生成されたりすることがあります。数百万件のレコードのロールバックを手動で管理するのは困難ですが、IcebergとGlueを使用することでこれらの状況に効果的に対処できます。
最近経験した実際の使用例を紹介します。画像モデルのトレーニングのため、あるリサーチャーは特定の条件を満たすデータセットを必要としていました：幅と高さの積が1024×1024の画像、審美性スコアが6以上（画像の審美性を測定）、モデル最適化のための特定のアスペクト比、透明な背景を持つ画像の除外などです。もう1つの例として、各画像のPerceptual Hash（P-hash）の使用があります。データパートナー、フォトグラファー、アーティストと協力する際、彼らは時として複数のデータベンダーと仕事をすることがありますが、シンプルなクエリで学習時の重複を簡単に見つけて除去することができます。
最新のビデオモデルでは、モーション（動き）スコアを評価するためのデータエンジニアリング作業が必要でした。ビデオモデルのトレーニングでは、フレーム間の遷移関数を学習する際にピークモーションが重要となります。静的なビデオは私たちの目的にとってはそれほど重要ではないため、トレーニングに最適なモーションスコアを評価したいと考えました。異なるスコアバケットから1000枚の画像をランダムサンプリングし、私たちの目視評価と照らし合わせて理想的なモーションスコアを調べたところ、6という値が最適であることがわかりました。このクエリによって、必要なデータエンジニアリング作業を実行することができました。
Anthropicの大規模データ処理：S3の活用と最適化
データサブセットを確定した後、実際のトレーニングフェーズに進みます。前述の通り、この作業には非常に強力なNVIDIA H100 GPUの大規模なフリートを使用します。私たちは、ペタバイト規模のデータに対して何百万回もの反復が必要なトレーニングアルゴリズムを開発し、そのデータを数日から数週間、時には数ヶ月にわたってクラウドにストリーミングします。コンピュートレイヤーには多くの最適化が必要ですが、ここではデータの側面に焦点を当てます。最終的に、私たちは比較的小さな（通常1〜5メガバイトの）画像ファイルを扱った経験に基づいて、クラスターへのデータストリーミングのためのアーキテクチャを開発しました。
データコンポーネントについて、AWSは接続の確立よりもスループットと帯域幅に最適化されていることがわかりました。長期間にわたってクラスターに何百万もの接続を開くことは、実験にとって有害となります。テストを通じて、5ギガバイトから10ギガバイトの間でサイズを試した結果、5ギガバイトのParquetファイルが私たちにとって最適に機能することが判明しました。
これらのParquetファイルはAmazon S3に保存し、トレーニングプラットフォームであるAmazon SageMakerに統合されているS3のFast File modeを使用してクラスターに接続します。これにより、アルゴリズムはローカルファイルシステム上のファイルと同じように扱いながら、必要に応じてS3からクラスターにストリーミングすることができます。各GPUは独立したユニットとして機能し、データロードには分割統治アプローチを実装しました。GPUが順番にシャードをリクエストするのではなく、各GPUが事前に割り当てられたシャードを把握し、反復プロセス中にそれを取得する方が効率的です。
このアーキテクチャにより、クラスターへの接続や外部ストレージの同期が不要なため、簡単にゼロにスケールダウンすることができます。ファイルストレージとして既に使用しているS3を利用し、必要に応じてデータをクラスターにストリーミングするだけです。クラスターがストレージと同じリージョンに存在するため、データ転送料金が発生せず、コスト効率も優れています。各GPUが独立して動作するアクセスパターンにより、高度に最適化されたパフォーマンスが得られ、モデルトレーニングが可能となっています。
最後のコンポーネントは、データパートナーへのアトリビューション（帰属）を提供するAttribution Engineです。例えば、私たちの最新モデルであるBRIA-2.3を使用して、Inference Serviceを通じて森の中を走る2人の子供の画像を生成する場合、Attribution Engineはデータパートナーを遡って、誰がクレジットを受けるべきかを特定します。私たちは、カタログと同じインフラストラクチャを採用しており、Apache IcebergテーブルとAWS Glueを使用してすべての記録を保存し、レポートの生成やデータパートナーへの支払い計算を可能にしています。
アトリビューションの規模について、過去1年間を振り返ると、驚くべき成長を遂げています。過去6ヶ月だけでも、単一のモデルに対して1億行のアトリビューションデータが蓄積され、過去1年間で合計20億行のアトリビューションに達しました。これは50以上あるモデルの中の1つに過ぎず、2025年に向けて少なくとも10倍の増加を見込んでおり、この成長する規模に対応できる堅牢なソリューションが必要となっています。Apache Icebergテーブルを使用したAWS Glueは、この膨大なデータセットのリアルタイムクエリを効果的にサポートできることがわかりました。
ご清聴ありがとうございます。私たちのすべてのモデルはオープンで、Hugging Faceを通じて利用可能です。Playgroundで実験したり、コンテンツを生成したり、Control Netを使用したりすることができます。私の言葉を鵜呑みにせず、ぜひご自身でお試しください。
このトークで私が特に印象に残ったのは、アトリビューションにIcebergを使用している点で、これは本当に素晴らしいですね。20億レコードについて言及されましたが、今後1年でBriaはどこまで成長すると思われますか？単純な経済単位で考えてみましょう。例えば、1人の顧客がInferenceを行い、1つのデータプロバイダーがいるとします。1回のInferenceに対して、この特定のデータパターンでは10枚の画像が返される可能性があります。なぜなら、生成されるコンテンツのピクセルを構成するのに10枚の画像が役立つからです。1回のInferenceが10倍になり、さらに複数の顧客、複数のデータプロバイダーがいることを考えると、この掛け算は膨大になります。1人の顧客が月に1億回の生成を行う可能性があるからです。さらにデータパートナーと帰属される画像の数を掛け合わせると、とてつもない数字になります。つまり、新しい顧客がInferenceを行うたびに、規模は指数関数的に成長していくのです。結果として、これは無限のスケールになっていきます。そのため、このスケールに対応するための何かを考え出す必要がありました。
Anthropicのデータ戦略：Deduplicationとストレージ管理
次に、AnthropicのNova DasSarmaをお招きしたいと思います。皆さん、こんにちは。AnthropicのNovaです。ご存知の方もいらっしゃるかもしれませんが、私たちはAIアシスタントのClaudeを開発しているAIリサーチ＆セーフティカンパニーです。本日は、Amazon S3が私たちのデータ処理能力をどのように革新したかについて、つまり私たちがS3をどれだけ使用しているかについてお話しできることを嬉しく思います。これは非常に大きな journey でした。昨年も少しお話ししましたが、今日はそこからいくつかの変更点についてお話しします。S3の使用規模を拡大することを検討されている方も、大規模なAIインフラがどのようなものかに興味がある方も、きっと有益な洞察が得られることと思います。
それでは、規模に関するスライドをご紹介します。以前の古いモデルでは、本日他の方々もお話しされていたように、大規模なデータの重複排除を行っていました。私たちが扱っている規模感をお伝えすると、2週間ごとに約200ペタバイトのデータセットを処理しています。これを分かりやすく例えると、DVDを積み上げて約230マイル（約370キロメートル）の高さになります。この規模に到達するまでには、様々な課題がありました。その一つは、私たちが妥協を許さない姿勢を貫いたことです。データをシャード化したり、効率性のために様々な譲歩をしたりする方法はたくさんありましたが、私たちはそれを選びませんでした。以前は重複排除のサイクルに4～5日かかっていましたが、これは研究者にとって非常に扱いづらいものでした。研究者は常にこれを実行できる環境を求めています。そこで、様々な最適化を重ねた結果、現在では200倍大きい200ペタバイトのデータセットを1～2日で処理できるようになりました。
本日は様々なサービスについてお話ししてきましたが、私たちはS3を愛用しています。高性能なIOPS集約型の操作、例えばシャッフルなどには、3つの異なる方法を使用しています。S3 Express One Zoneのおかげで、HadoopやEBS、EFS、その他の共有ファイルシステムを使用せずにこれが可能になりました。私たちはこの作業をS3内で完結させたいと考えています。S3 Express One Zoneを使用すると、シャッフルに必要な数のIOPSを必要な速度で実行できるため、大容量のディスクを用意する必要がありません。マルチリーダーの帯域幅集約型の操作には、Cross-bucket Replicationを使用しています。これにより、データを計算リソースと同じ場所に保存できますが、必ずしもそこで処理する必要はありません。私たちはGPUや他のアクセラレーターを使用しており、データを同じ場所に配置したいと考えていますが、大規模なシャッフルやフィルタリングを行う場合、同じリージョンにいられない可能性があります。そのため、Cross-bucket Replicationが役立っています。また、転送コストを抑えるためにGateway Endpointsも使用しています。Gateway Endpointsを使用すると、転送コストを削減できるからです。
規模を拡大する中でコストを管理する上で、Amazon S3 Intelligent-Tieringが非常に重要な役割を果たしています。私たちは言語モデルを学習させており、そのモデルのチェックポイントは非常に大きく、アクセス頻度も極めて低いものです。これらにアクセスできないと非常にコストがかかってしまいますが、90%以上は二度と使用されることがありません。そのため、Intelligent-Tieringは自動的にティアを下げてくれる非常に良いオプションとなっています。
それでは、これらのモデルチェックポイントについてもう少し詳しく見ていきましょう。 ここでの重要な最適化の一つは、ユーザーにとっても S3 にとっても使いやすい形でモデルチェックポイントのS3構造を設計したことです。S3はプレフィックスを活用し、複数のプレフィックスに分散させることを得意としており、一方でユーザーはファイルシステムのような構造を好みます。メタデータの操作はそれほど重要ではないため、メタデータを分離して標準的なファイルシステムのような構造にしました。チェックポイント自体は逆順のキー構造を採用しています。まずRun Typeがあり、これは教師あり学習（SL）や強化学習（RL）のRunを示し、次にRun Name、そしてチェックポイントタイプ（永続的、定期的、一時的）が続きます。その後にチェックポイント番号が来て、これは最初のチェックポイント、1万トークン、100億トークン、10兆トークンのチェックポイントなどを示します。
モデル自体を保存するために、スループットに最適化された構造を使用しており、パスの最初の部分でシャード化できるようになっています。これにより、同じバケット内の複数のプレフィックスに書き込みを分散させているため、それらのプレフィックスはウォームな状態を保つことができます。ユーザーは依然としてディレクトリ内をリストアップして必要なものを確認することができます。ここでシャードを効果的に使用することは、私たちのワークロードに大きな影響を与えました。なぜなら、オブジェクトのリスト化は望ましい操作の逆だからです。シャード化によって503エラーや速度低下を回避できており、これは数千台や数万台のマシンで復元や実行を行う際に重要です。
Storage Elasticityをクリックしてみましょう。 クラウドの素晴らしい点の1つは、ワークロードに応じてIOPSを上下にスケールできることです。私は主にデータセンターベースの環境で働いた経験がありますが、そこでのリスクの1つは、データセンターに十分なディスクを設置できていない、十分なSSDがない、十分なIOPSがないということでした。必要なIOPS数とバンドワイス量までスケールするには、多くのインフラを遊ばせておく必要がありました。このマルチテナントインフラの素晴らしい点は、弾力的にスケールできることです。これは、サーバーの1台が故障して、この巨大なModelのチェックポイント全体を複数のマシンに同時にリストアしなければならないような、バースト的なトレーニングパターンに最適です。
賢明な方法もありますが、ここでは時にシンプルな方法を取ることができ、大量のバンドワイスを確保できるのは素晴らしいことです。ピーク時のためのプロビジョニングは不要で、オーバープロビジョニングのコストもかからず、キャパシティプランニングがとても容易になります。キャパシティと言えば、これは昨年の数字です。プロビジョニング不要で800ギガバイト/秒という話をしていました。今年は新しい数字があります：1,500ギガバイト/秒です。つまり、単一のRegionで持続的に毎秒テラバイト級のエグレスを達成しています。これは我々の全てを数えているわけではありませんが、素晴らしい数字なので、評価に値します。この倍増により、世界最高のコードモデルであるClaude 3.5が実現しました。
これを分かりやすく説明すると、約3ペタバイトのNetflixのカタログ全体を1秒以内に転送できる計算になります。15ペタバイトのLibrary of Congress（アメリカ議会図書館）の全コンテンツを転送するのに30秒もかかりません。最新のNVMeドライブでも、毎秒7ギガバイト程度しか出せません。それは多くのドライブが必要になるので、誰か他の人がそれを担当してくれるのは嬉しいことです。では、もう少し具体的な話をしましょう。
私たちは s5cmd を多用していますが、Accelerated Instancesを使用しているため、AWS Common Runtime (CRT)ベースのS3クライアントも使用しています。これは自動的に行われますが、それ以外のマシンでも自動化されていると思います。これにより、より良い接続管理が可能になります。前述の通り、何かをするたびに新しい接続を作成しなければならないのは非常にコストがかかります。TLSの起動コストを償却することは非常に価値があります。私たちはこれを行うために多くのコードを持っていましたが、CRTがそれらの多くを置き換えてくれたおかげで、大規模な操作でより良いスループットを得られるようになりました。
できるだけ多くの非同期I/O操作を実行できるようにしたいと考えています。データを事前にキューに入れておくことで、RAMに数ギガバイトのデータを保持しておき、レイテンシーのジッターを吸収することができます。S3がそのスループットにスケールできる限り、好きなだけレイテンシーを隠すことができます。これは私たちにとって便利なことであり、S3を使い続けている理由の1つです。
これが私たちのデータ戦略にどのような影響を与えているかについてお話ししましょう。最も大きな点は、より大規模なデータセットに対してフィルタリングを継続して実行できるようになったことです。前回この話をしてから約200倍にスケールアップしており、より包括的なDeduplication戦略を実施できるようになりました。ここに、異なるPrefixに保存された異なるシャードのデータを示す素晴らしい図があります。シャード内でDeduplicationを行い、そのデータの一定割合に対してシャード間で処理を行うという方法があります。特に画像領域でのPerceptual hashを使用するような意味的なDeduplicationを行う場合、シャードの境界で多くのロスが発生し、効果的なスケーリングが非常に困難であることがわかりました。
テキスト領域やその他の領域でも同様の手法を適用することができます。意味的なDeduplicationは、グローバルなDedupeでより効果を発揮します。ご覧の通り、より多くのデータを削除でき、そのデータの使用方法についてもより深く理解できています。これにより、最終的なモデルの品質をより正確に把握できます。なぜなら、データセット内の重複は多くの場合、モデルの性能低下につながるからです。スケールアップしながらも、迅速な開発サイクルを維持しつつグローバルなDedupeを継続できることは、私たちにとって非常に価値があります。
私たちは、自動的なストレージクラスの移行を実現するS3 Intelligent-Tieringを好んで使用しています。ここに示すのは、私たちが行っている異なる種類のストレージの比率です。これはCloudWatchから取得したスライドです。また、潜在的な削除対象となる大きなPrefixを見つけるために他のツールもいくつか使用しています。例えば、ある開発者が不要と思われるShuffle sortコンポーネントを数ヶ月間保存していたことを発見しました。大きなPrefixの監査を行うことで、多くの問題を解決できました。また、Terraformを使用してバケット間でLifecycle ruleを標準化し、中断されたMultipart uploadの期限切れ、過去のバージョンの削除、Intelligent-Tieringへの移行、古いデータの削除などを行っています。
いくつかの学んだ教訓をご紹介します。キー構造を設計する際は、将来のスケーラビリティを考慮する必要があります。Prefixについて考え、命名規則を実装することで、Data Scientistやその他のデータ消費者といったユーザーのニーズを満たしながら、必要なスループットを確保することができます。S3の機能をより活用することをお勧めします。S3は優れたObject Storeですが、それ以上の機能を備えています。コスト管理のためのS3 Express One ZoneやIntelligent-Tieringの活用、そして移行戦略について検討してください。大量のデータが一箇所に存在する場合、すべてのデータを同時に移行する必要はありません。
質疑応答：チェックポイント管理とマルチモーダルデータの扱い
あなたの規模で特に目立つのは、Checkpointストレージについてですが、それをどのように管理されていますか？どのように削除を行い、どのくらいの期間保持していますか？
Checkpointについて少しお話ししましょう。先ほど説明したこの重要な構造についてですが、私たちは階層的なCheckpointシステムを使用しており、時間の経過とともにデータを段階的に削減していきます。特定のCheckpointを保持しておく必要性は、指数関数的に考えることができます。S3 Inventory Reportを活用して、時間の経過とともにCheckpointを削除するプロセスを実行し、コストを削減しています。これはIntelligent-Tieringの仕組みと似ており、連携して機能します。
3つの異なる種類があります。明示的なもの、30日程度で削除される一時的なもの、そしてPeriodicとPermanentのスナップショットです。名前付けはあまり良くないのですが、Periodicスナップショットも実は永続的なものです。ただし、一定のトークン数ごとに保存され、Permanentスナップショットは実行が進むにつれて指数関数的に保存されます。
大量のデータを扱い、さらに多くのマルチモーダルデータでトレーニングを行っているとのことですが、マルチモーダルデータはどのように管理されているのでしょうか？これは興味深い点です。マルチモーダルは私たちにとって面白いデータの課題でした。テキストは圧縮が非常に簡単です。先ほどの200ペタバイトという数字は、主にテキストデータを指しています。しかし、画像の場合はサイズがもっと大きく、また小さなファイルが多数存在するといった特徴があります。
データの準備には、事前に行うものと、ジャストインタイムで行うものの2種類があります。基本的に、マルチモーダル関連はすべてジャストインタイムです。非常に多くのファイルを保存していますが、簡単に言えば、すべての画像ファイルをS3に置いて、必要な場所にプレフィックスで到達できるようにしているだけです。非同期IOと高スループットに最適化されたS3スタックがあれば、あまり深く考える必要がありません。これはほとんどのユースケースでうまく機能しています。
開発サイクルに関して考慮すべき課題があります。小規模なモデルの方が、大規模なモデルよりも速くトークンを消費することがあるのです。大規模モデルは一定のスループットで問題なく動作しますが、小規模モデルの方が問題を引き起こしやすく、しかもその数が多いのです。これは私たちが検討している課題の一つです。具体的にどのようにスケールアップするかは、ユースケース次第ですが、現時点ではS3が期待通りに機能しています。
最後に、スピーカーの皆様に感謝を申し上げたいと思います。Canvaのジョシュさん、Bria AIのバーさん、そしてAnthropicのNova DasSarmaさんにご登壇いただきました。皆様、ありがとうございました。良い一週間をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion