12月に開催されたAWS re:Invent 2024、基調講演のアーカイブから前夜（Monday Night Live）の内容を共有します。
個人的事情として耳が悪く視聴・聞取りが辛いので、動画の文字起こしから生成AIの支援を借りながら、(1)段落分けや日本語訳、(2)サマリを作成したものです。これを読みながら、動画を見ると、分かるかなーとか思いつつ。
サマリ
イベントでは、まずAWSのユーティリティコンピューティング担当シニアバイスプレジデント、Peter DeSantis氏が登壇し、AWSイベント「Monday Night Live」の冒頭で、AWSの技術革新を象徴するアナロジーとして「木」を用い、AWSの取り組みを説明しました。木の幹はカスタムシリコンやサーバーレスコンピューティングなどの主要な技術投資を、根はリーダーシップの細部へのこだわりと文化を表します。DeSantis氏は、リーダーが現場に深く関与し、迅速な意思決定を可能にする「主根」の重要性を強調しました。また、AWSのリーダーシップ原則や文化が技術革新を支える基盤であると述べ、AIアシスタントを活用したプレゼン作成の裏話も披露しました。このスピーチは、AWSの長期的視点と技術革新の価値を聴衆に伝えるものでした。
次の登壇者、AWS Compute Networking副社長のDave Brown氏は、AWSの基盤技術であるカスタムシリコンとNitroシステムの進化について説明しました。Brown氏は、自身が18年前に小規模チームとしてスタートしたElastic Compute Cloud（EC2）の開発経験を振り返りながら、カスタムシリコンGravitonシリーズの進化を紹介。Graviton1から最新のGraviton4までのプロセッサ開発により、実際のワークロードで顧客に大幅な性能向上を提供していると述べました。また、AWS Nitroシステムの革新を通じ、仮想化オーバーヘッドの排除やセキュリティ強化を実現し、柔軟性に優れたサーバーアーキテクチャを構築した点を強調。これらの技術が、AWSのインフラストラクチャを支える鍵であることを伝えました。
Peter DeSantis氏が再登壇し、AIインフラストラクチャとTrainium2について話しました。DeSantis氏は、AIワークロードの急速な進化に伴い、トレーニングと推論に特化した新しいインフラの必要性を強調しました。特に、AIトレーニングにおける「スケールアップ」と「スケールアウト」の課題に触れ、AWSがどのように最適化されたインフラを提供しているかを説明しました。Trainium2チップは、計算能力とメモリ帯域幅を強化し、AIモデルのトレーニングを加速します。さらに、AWSが提供する次世代AIサーバーが、従来のインフラを超えた性能を提供し、エンタープライズ向けのAIアプリケーションに最適な環境を構築していることを紹介しました。
次の登壇者、Anthropicの共同創設者であり最高コンピュート責任者のTom Brown氏は、AWSとのパートナーシップを通じて実現したAIモデルの進化について語りました。Brown氏は、AnthropicのAIモデル「Claude」の最適化とその性能向上におけるAWSの役割を強調しました。特に、Trainium2チップを使用することで、AI推論が60％速くなり、ユーザーの体験が大幅に改善されたことを紹介。また、Claude 3.5の低遅延最適化版がAWS上で他のプロバイダーを凌駕する性能を発揮していることを述べました。さらに、次世代モデル「Claude 3.5 Sonnet」の開発と、そのAIインフラのスケーラビリティに関する詳細も共有しました。AWSとの協力により、Anthropicは信頼性の高い、効率的なAIインフラを提供し、AIの性能を飛躍的に向上させています。
最後に再びPeter DeSantis氏が、AIクラスタとネットワークの革新について語りました。DeSantis氏は、AIインフラの構築には「スケールアップ」と「スケールアウト」の両方の課題があり、特にAIワークロードにおけるネットワークの重要性を強調しました。彼は、AWSが構築した10p10uネットワークについて説明し、このネットワークがどのように数千台のサーバーを接続し、10マイクロ秒未満の低遅延でAIワークロードを支えているかを紹介しました。このネットワークは、大規模な並列処理と密接に接続されたネットワーク構造を備え、AIクラスターのスムーズな運用を可能にします。また、AWSが開発した「ファイアフライ光学プラグ」などの新技術により、ネットワークの信頼性が向上し、設置時間が大幅に短縮されたことも述べました。これらの革新が、AIインフラのパフォーマンスとスケーラビリティを支えていると強調しました。
文字起こし日本語訳
Peter DeSantis: 開会挨拶とイントロダクション (0:21)
（ファンキーなアップビートな音楽）
【アナウンサー】AWSのユーティリティコンピューティング担当シニアバイスプレジデント、ピーター・デサンティスをお迎えください。
（観客の歓声と拍手）
1.はじめに: Monday Night Liveについて (0:39)
ありがとうございます。re:Invent 2024へようこそ。（観客の歓声と拍手）そして、もう一度「Monday Night Live」へお越しいただきありがとうございます。私はこれを「キーノート前夜祭」と呼ぶのが好きです。素晴らしいバンドと美味しいビールがありますが、謝らなければなりません。IPAが用意されていないことがわかりました。IPA好きの皆さんのために、来年はそれを改善します。申し訳ありません。それは私の責任です。
2.AWSの技術革新とその背景 (1:07)
さて、今夜はいつも通り、技術革新について深く掘り下げます。そして「キーノート前夜祭」として、一つのプレゼントを開ける機会があるかもしれません。もしかすると一つだけかもしれませんが、見てみましょう。
しかし、最初に最も重要なことをお話しします。それは「Monday Night Live」で私たちが好んで行うことで、「どのように」という方法論を見ることです。「どのように」は重要です。なぜなら、それがクラウドコンピューティングの最も重要な特性を実現する方法だからです。これらは単なるローンチ可能な機能ではありません。これらは、サービスに設計として組み込む必要があるもので、私たちはまさにそれを行っています。これらは、私たちの構築方法の表れです。
そして今夜、AWSがこれらの能力を提供するうえで、なぜ特別に優れているのかを少し説明するのは楽しいのではないかと思いました。
このキーノートの準備をする中で、私はAIアシスタントを使ってみることにしました。私のチームやAmazon全体のチームが、AIアシスタントを使ってコードを書いたり、クリエイティブを作成したりしている様子に刺激を受けたのです。これは試してみる良い機会だと思い、AIアシスタントにプレゼンテーションをどのように始めたいか、そしてどのように視覚化したいかを伝えました。
するといくつかのアイデアが出てきました。最初のアイデアは「氷山」でした。表面下に何があるのかを話したかったので、氷山のアナロジーが提案されました。しかし、私は氷山のアナロジーが気に入りませんでした。氷山では、見えるのは小さな先端だけで、その下にあるのはただの氷ですから。次のアナロジーはもっと良かったです。それは「宇宙飛行」で、AIアシスタントが、目に見えるのは短い打ち上げだけれど、その背後には多くのエンジニア、オペレーター、デザイナーのチームがいることを説明すべきだと言いました。これは少し納得がいきましたが、それでも完全には私が求めている要点を捉えていませんでした。
そこで、AIアシスタントと何度かやり取りした後、私たちは「木」について話すことに決めました。木は、毎年私たちが議論する大きな差別化された技術投資を象徴しています。例えば、AWSカスタマーに最高のパフォーマンスと最低コストのインフラストラクチャオプションを可能にするカスタムシリコンへの長期的な投資、セキュアなサーバーレスコンピューティングを可能にするAWSカスタムハイパーバイザーへの投資、または差別化されたデータベース機能とパフォーマンスを提供するためのデータベース技術への深い投資などです。
しかし、今夜木について話す前に、根について話したいと思います。木を支え、養うために必要不可欠な構造である「根」についてです。
3. 主根とリーダーシップの詳細へのこだわり (4:00)
まず「主根（Taproot）」について話しましょう。すべての木に主根があるわけではありませんが、主根を持つ木は地表の深くにある水に独自にアクセスできるため、厳しい条件でも繁栄することができます。
AWSとAmazonで最もユニークな点の一つは、リーダーたちが詳細に多くの時間を費やし、その詳細にこだわることです。これは非常に重要です。なぜなら、詳細に関わることで、お客様やサービスで何が本当に起きているのかを知ることができ、それが迅速な意思決定を可能にし、問題の修正や予防を早期に行う助けになるからです。他の場所でも同じようなことが起きるかもしれませんが、通常、その情報が組織の多くの層を通過する必要があるため、迅速には進みません。上司にうまくいっていないことを伝えるのがどれほど楽しいことかを想像してみてください。誰もが好きなことではありませんし、通常、十分に迅速に伝わることはありません。
詳細にこだわりたいと言うのは簡単ですが、それをスケールで実現するための仕組みを構築するのは難しいことです。そして、それこそが私たちがやっていることです。その素晴らしい例の一つが、毎週水曜日に開催されるAWS全体の運用会議です。この会議では、すべてのチームが集まり、問題を議論し、学びを共有し、互いに学び合います。これは、私を含むリーダーたちが詳細に関わり続けるための重要な仕組みです。
詳細に関わることは、他の面でも役立ちます。その一つが、困難な長期的決断を容易にすることです。その良い例が、カスタムシリコンへの投資を始めるという決断でした。今ではこれは明白な決断のように思えますが、12年前には全く明確ではありませんでした。詳細を理解していたからこそ、AWSにとって必要なパフォーマンスとセキュリティをNitroのような技術なしに達成することは不可能だと分かっていました。そこで、私たちはAnnapurnaチームと協力するという決断を下しました。これは、私たちのビジネスにとって最も重要な技術的推進力の一つとなりました。もし私たちが課題を深く理解していなかったら、待つという選択をしていたかもしれません。しかし幸運にも、私たちは待たなかったのです。その決断によって、AWSのストーリーは全く異なるものになりました。今夜、そのストーリーの次の章を共有します。
4. AWSの幅広い技術革新の例: Buttress roots (6:47)
主根のアナロジーはとても好きですが、最も巨大な木を支えるのは深い根だけではありません。木は代わりに水平な根の構造に頼っています。その魅力的な例が、アマゾン熱帯雨林のバットレス・ルートシステムです。これらの地上に広がる根のシステムは、不安定な土壌システムで育つ世界最大級の木々を支えています。バットレス・ルートは木の根元から数百フィートにも広がり、近くの木々と相互に絡み合って、熱帯雨林の巨大な巨木を支える基盤を形成します。
これがAWSのもう一つの独自の特徴、すなわち、スタック全体で革新を起こす能力につながります。データセンターの電力からネットワーキング、チップ、ハイパーバイザー、データベース内部、さらには高水準のソフトウェアに至るまで、これほど多くの重要な構成要素に深く投資している企業はほとんどありません。今週、私たちがこの広範な革新をどのように活用して、皆様であるお客様に非常にユニークで差別化された機能を提供しているかをお見せします。
しかし、バットレス・ルートシステムは、木々が相互に連結する驚くべき方法の一つに過ぎません。おそらく最も驚くべき、そして予想外なものは「ウッド・ワイド・ウェブ」です。私たちはしばしばキノコを地上に生える菌類だと考えますが、実際にはキノコは地面の下で成長する菌類の果実であり、木の根に住む巨大な生物です。木々はこの菌類と共生関係にあり、それを使って互いに情報や資源を共有し合い、コミュニケーションを取ります。この仕組みによって、森は個々の木よりも強くなります。
5.AWS文化の構築とリーダーシップ原則 (8:35)
そしてこれが、私がAWSについて最も重要でユニークだと思う点、すなわち、私たちのすべての活動を支える「文化」につながります。私が1998年に若いエンジニアとしてAWSまたはAmazonに参加したとき、当時の会社の進化の初期段階にもかかわらず、リーダーたちが文化の構築にこれほどまでに注力していることに驚きました。
私たちのシニアリーダーは、今日の会社に成長するための仕組みを構築する時間を惜しみませんでした。リーダーシップ原則を書き留める時間を取り、採用基準を高く保つために「バー・レイザー」プログラムを構築しました。さらに、スケールする過程で善意に頼るだけでなく、毎週の運用会議のような仕組みを構築しました。
振り返ると、これらの投資の緊急性について私がどれほど間違っていたかが明らかです。文化について言えば、それは「あるか、ないか」のどちらかです。そして、もしないなら、それを得るのは非常に難しいです。
私たちの文化はユニークであり、セキュリティ、運用パフォーマンス、コスト、そしてイノベーションに対する揺るぎない焦点を保ちながらスケールする助けとなっています。イノベーションをスケールする精神のもと、今夜は新しい試みをしてみたいと思います。
今夜話すいくつかのイノベーションについて、それを推進しているAWSの他のリーダーから直接聞いていただくのは面白いのではないかと考えました。
Dave Brown: AWSのカスタムシリコンとNitroシステム (10:03)
それでは、AWS Compute Networkingの副社長であり長年のリーダーであるデイブ・ブラウンをステージにお迎えしましょう。（観客の拍手） （アップビートな音楽）
1.EC2の基盤とカスタムシリコンの進化 (10:22)
ありがとう、ピーター。ここに立てることを光栄に思います。私のAWSでの旅は、ほぼ18年前、南アフリカのケープタウンにある14人の小さなチームの一員として始まりました。私たちは、後にElastic Compute Cloud（EC2）となるものを構築していました。私たちの使命は非常に野心的で、クラウドを支える基盤的なオーケストレーションレイヤーを設計することでした。
当時私たちは、それがコンピューティングにおけるはるかに大きな変革の始まりに過ぎないことを知りませんでした。それ以来、私たちはインフラストラクチャのあらゆる側面を再発明し、お客様に最大限のレジリエンス、パフォーマンス、効率性を提供する旅を続けています。この旅の重要な部分を支えているのが、カスタムシリコンの開発です。
2018年に初めてGravitonを発表したとき、それは最速のチップを作ることではありませんでした。むしろ、市場にシグナルを送り、開発者に実際のハードウェアを提供し、データセンターでのArmに関する業界の協力を促進することが目的でした。
その後、私たちはさらに野心的な目標を目指しました。最初の完全にゼロから設計されたプロセッサです。Graviton2では、スケールアウトされたワークロードに特化しました。なぜなら、それが当時お客様が必要としていたものであり、その境界を押し広げるものだったからです。ウェブサーバー、コンテナ化されたマイクロサービス、キャッシングフリート、分散型データ分析などがその例です。そして、この時、Armがデータセンターで本格的に到来した瞬間でした。
Graviton3では、私たちの範囲をさらに拡大しつつ、全体的に大幅なパフォーマンス向上を実現しました。特に、並外れた計算能力を必要とする特殊なワークロードに集中し、その結果は劇的なものでした。
Graviton1からGraviton4への進化 (12:18)
機械学習推論から科学モデリング、ビデオトランスコーディング、暗号化操作に至るまで、多くの計算集約型ワークロードでパフォーマンスを2倍以上に向上させました。そして今日、Graviton4はクラウドでプロセスを構築する中で得たすべての知見を集大成したものです。これは私たちがこれまでで最も強力なチップであり、マルチソケットサポートと従来のVCPU数の3倍の能力を備え、巨大なデータベースや複雑な分析など、最も要求の厳しいエンタープライズワークロードに対するゲームチェンジャーとなっています。
また、Gravitonの各世代において、お客様は最新のインスタンスタイプに切り替えるだけで、即座にパフォーマンスの向上を実感することができました。次に、Gravitonのパフォーマンスを現実のワークロード向けにどのように最適化したかを見てみましょう。
現代のCPUは、命令を取得してデコードするフロントエンドと、それを実行するバックエンドを備えた洗練されたアセンブリパイプラインのようなものです。パフォーマンスを評価する際、異なるワークロードがCPUのマイクロアーキテクチャにどのように負荷をかけるかを見ます。ワークロードがフロントエンドの停止（分岐数や分岐ターゲット、命令の数などが影響する）に敏感なのか、あるいはバックエンドの停止（L1、L2、L3キャッシュ内のデータや命令ウィンドウサイズなどの影響を受ける）に影響を受けるのかを評価します。
伝統的に、プロセスのアーキテクチャに負荷をかけるためにマイクロベンチマークが使用されてきました。例えば、このベンチマークではL3キャッシュを酷使して大量のバックエンド停止を引き起こしています。エンジニアリング用語で言えば、CPUパイプラインがL3キャッシュからデータが追い出されるのを待ちながら、何もせずに手持ち無沙汰でいるということです。
長年にわたり、業界はまさにこのようなベンチマークを最適化することに熱中してきました。しかし、これはマラソンのトレーニングを100メートル走をすることで行うようなものです。どちらも走ることですが、基本的に異なる課題に取り組んでいます。そして、実世界のワークロードは、このようなきれいに整理されたベンチマークとは全く異なる挙動をします。実世界のワークロードは複雑で予測不可能であり、正直なところ、ずっと興味深いものです。
では、このマイクロベンチマークとCassandra、Ruby、Nginxといった現実のアプリケーションを比較してみましょう。これらはお客様が日々使用しているワークロードです。マイクロベンチマークがバックエンドの停止を重視しているのに対し、これらの実世界のワークロードでは全く異なる要因によってボトルネックが発生します。ブランチ予測が多く失敗していたり、L1およびL2キャッシュの命令ミスが多発していたり、TLBミスが生じたりしています。マイクロベンチマークとは異なり、フロントエンドがすべての停止を引き起こしており、フロントエンドの停止がバックエンドの停止を上回っています。
これがAWSで、実世界のワークロードパフォーマンスに執着している理由です。私たちはプロセスを設計する際、ベンチマーク競争に勝つことを目指しているのではなく、お客様の実際のアプリケーションを最適に動作させることを目指しています。
その結果は、現実のワークロードにフォーカスした成果です。Graviton3では、従来のベンチマークがGraviton2に対して30%の改善を示しました。悪くないですよね？でも、もっと驚くべきことがあります。Nginxでテストしたところ、60%の性能向上を確認しました。その理由は、従来のベンチマークではほとんど重視されていなかったブランチ予測ミスを大幅に削減したからです。そしてGraviton4では同じパターンが繰り返されました。マイクロベンチマークでは25%の改善を示しましたが、現実のMySQLワークロードでは40%の性能向上が見られました。これは、大規模データベースを運用しているお客様にとって何を意味するのでしょうか。
これが、Graviton4がお客様に愛される理由です。これは単なるスライド上の数字ではありません。本物のお客様が実際の改善を目の当たりにし、それがさらに彼らのお客様に利益をもたらしています。
AWSでは、Gravitonの利点を語るだけでなく、自分たちのサービスを移行することでそれを直接体験しています。そして、目覚ましいコストパフォーマンスの改善を目の当たりにしています。Aurora、DynamoDB、Redshiftなどのサービスは、Gravitonで実行することで大きな恩恵を受けています。そして、世界最大級のショッピングイベントであるAmazon Prime Dayでは、25万以上のGraviton CPUがオペレーションを支えていました。
最近では、大きなマイルストーンを達成しました。過去2年間で、データセンターに投入された新しいCPUキャパシティの50%以上がAWS Gravitonでした。これはどういうことでしょうか。これは、Gravitonプロセッサが他のすべてのプロセッサタイプを合わせた数を超えていることを意味します。
ただし、Gravitonはシリコンレベルでの革新の最初の場所ではありませんでした。初期の段階で、急増するEC2インスタンスに対して世界クラスのパフォーマンスとセキュリティを提供するためには、スタック全体で革新を起こす必要があると認識していました。
2.AWS Nitroシステムとセキュリティ革新 (18:04)
そのストーリーこそがAWS Nitroシステムです。AWS Nitroシステムはサーバーアーキテクチャを完全に再考したもので、クラウドの構築とセキュリティのあり方を根本的に変革しました。Nitroによって、他のクラウドプロバイダーが今でも直面している従来型の仮想化のオーバーヘッドを排除しました。さらに、Nitroのアーキテクチャがもたらす柔軟性によって、ほぼどんなコンピューターでもEC2インスタンスに変えることが可能になりました。
クラウドでApple Macを動かしたいですか？Nitroならそれが可能です。ベアメタルEC2インスタンスで基盤ハードウェアへの直接アクセスが必要ですか？Nitroならそれも対応可能です。
では、この旅がどこから始まったかに焦点を当てましょう。それはセキュリティです。Nitroはセキュリティを向上させただけでなく、ハードウェアサプライチェーンの整合性に対する私たちのアプローチ全体を変革しました。
クラウドのセキュリティには絶対的な確実性が求められます。AWSでは、すべてのハードウェアが期待通りのソフトウェアを、期待通りの方法で実行していることを知る必要があります。これは単にフリート全体でソフトウェアやファームウェアを更新することを超えています。暗号的証明、つまり「アテステーション」が必要です。これによって、各システムで何が動作しているのかをリアルタイムで把握することができます。
私たちの規模では、それは途方もない挑戦です。考えてみてください。私たちはグローバルなインフラ全体にわたる数百万のコンポーネントの整合性をリアルタイムで証明しています。
では、起動シーケンスを慎重に調整された一連のステップとして考えてみましょう。すべてはROM（読み取り専用メモリ）から始まります。このROMがチップの基本的な部分を起動します。そこから、プロセッサは次のファームウェア層を読み込み、その後、ブートローダーを読み込みます。そして、ブートローダーがオペレーティングシステムに引き継ぎ、最終的にはアプリケーションに至ります。
ここでの重要な洞察は、これらの各ステップが潜在的な弱点、つまり不正なコードが実行される可能性のある場所を表していることです。さらに根本的に、この全体のチェーンは「信頼のルート」に依存しています。したがって、本当の問題は、最初のリンクをどのように検証するかということです。それを行うためには、製造現場までさかのぼる必要があります。
サービスの旅路は、製造の開始から、組み立て、輸送経路、データセンター、そして最終的には設置に至るまで長い道のりです。
起動プロセスと信頼のチェーン (20:38)
各ステップで、何も侵害されていないという確信を持たなければなりません。これは、事後に脆弱性を見つける話ではありません。コンポーネントが製造される瞬間から、実際にお客様のワークロードで動作するまで、途切れることのない管理と検証の連鎖を作り出すことが目的です。では、Graviton4ベースのワークロードの起動プロセスを掘り下げてみましょう。
私たちのハードウェアセキュリティと信頼の基盤は、Nitroチップ自体にあります。各Nitroチップの製造中に、ユニークな秘密が生成され、チップ内に保存されます。これはチップのユニークな指紋と考えることができ、シリコンから外に出ることはありません。
この秘密は公開鍵と秘密鍵のペアの基礎となります。秘密鍵はチップ内に永久にロックされ、公開鍵は私たちのセキュアな製造記録の一部となります。ここから管理の連鎖が始まります。Nitroチップ内の秘密鍵は、測定されたブートプロセスのアンカーとなります。ブートの各段階で、新しい秘密鍵が作成され署名され、前の秘密鍵は破棄されます。
これは安全なバトンを渡すようなもので、各引き継ぎが完璧でなければレースは終了します。この署名の連鎖により、チップの製造品質、ファームウェアのバージョン、アイデンティティに至るまで、すべてを検証することができます。システムはこの完全なアテステーションプロセスを通過するまで、AWS全体へのアクセスが制限されます。そして、失敗した場合は即座に隔離と調査が行われます。
Gravitonでは、このセキュリティの境界をさらに広げています。Nitroのセキュアな基盤の上に、アテステーションをGraviton4プロセッサ自体に拡張しました。これにより、重要なシステムコンポーネント間に相互接続された信頼のネットワークが構築されます。
たとえば、2つのGraviton4プロセッサが連携する必要がある場合、まず暗号的にお互いのアイデンティティを検証し、暗号化された通信を確立します。同じことがGraviton4とNitroの間でも行われ、キー交換がホストのアイデンティティと秘密鍵に基づいて行われます。
これが何を意味するか考えてみてください。CPU間通信からPCIEトラフィックに至るまで、システム内のすべての重要な接続は、製造時から始まるハードウェアベースのセキュリティで保護されています。
NitroとGraviton4が協調して動作することで、連続的なアテステーションシステムを作り出しました。これは単なるセキュリティの漸進的な改善ではありません。NitroのハードウェアベースのセキュリティとGraviton4の強化された能力の組み合わせにより、これまでで最も安全なコンピューティング環境の一つを実現しました。
お客様にとって、これは製造の瞬間から運用のすべての瞬間に至るまで、暗号的に検証されたハードウェア上でワークロードを実行できることを意味します。従来のサーバーやデータセンターでは達成不可能なセキュリティです。
しかし、Nitroで解決できる他の課題は何でしょうか？それを理解するには、ストレージの動態について見る必要があります。
3.ストレージ技術の進化とディスアグリゲーション (23:50)
ハードドライブの容量は絶え間なく進化しています。数年ごとにドライブメーカーはプラッタにより多くのデータを格納する新しい方法を見つけています。AWSの初期、2006年頃を振り返ると、数百ギガバイトのドライブを使用していました。今日では、20テラバイト以上のドライブを導入しています。
同時に、設計、製造プロセス、そして材料の革新により、ストレージ1テラバイトあたりのコストは過去数十年で劇的に下がっています。そのため、ストレージシステムを常に効率的に運用するために、新しいドライブサイズやストレージ技術革新に常に対応できるようにしておく必要があります。
これがどのような複雑さを生むのかをよりよく理解するために、一般的なストレージシステムの設計を詳しく見てみましょう。S3やEBSのようなストレージサービスを考えると、それらは3つの重要なコンポーネントで構成されています。
1つ目は、フロントエンドフリートです。これは、APIトラフィックや認証リクエストを処理し、顧客インターフェースを管理するWebサーバー群です。その背後にあるのが、インデックスまたはマッピングサービスと呼ばれるものです。これはオペレーションの頭脳のようなもので、すべてのデータの場所を正確に追跡します。お客様がデータを読みたいとき、このサービスが正確な場所を教えてくれます。
最後に、ストレージメディア層があります。ここが実際にデータが保存される場所です。では、このストレージサーバーに焦点を当ててみましょう。
従来のストレージサーバーは、ヘッドノードアーキテクチャと呼ばれるものに基づいて構築されてきました。ヘッドノード自体は基本的に標準的なコンピュートサーバーで、CPU、メモリ、ネットワーク機能を備えています。このサーバーは、データ耐久性、ドライブの健康状態の監視、IO操作の調整など、データストレージのあらゆる側面を管理する特殊なソフトウェアを実行しています。
このヘッドノードに接続されているのが、私たちが愛情を込めてJBOD（「ただの一群のディスク」）と呼ぶものです。文字通りそれは、ハードドライブが満載されたシャーシであり、SATAやPCIe接続を通じて直接ヘッドノードに配線されています。
しかし、この設計には問題があります。それは、計算リソースとストレージの比率が設計時点で固定されてしまうことです。一度サーバーを構築して展開すると、CPU、メモリ、ストレージ容量の特定の比率に縛られてしまいます。
ドライブ容量が年々劇的に増加する中で、この固定比率は効果的に管理するのがますます困難になっています。その結果、私たちはストレージシステムの容量を拡大する旅を続けてきました。それは、ドライブサイズとドライブ数の両方を増加させることで実現されました。
当初は比較的控えめな構成で、1サーバーあたり12台または24台のドライブを使用していました。ドライブ技術が進歩するにつれて、より大きなドライブプールを管理する能力が向上しました。ホストあたり36台、次に72台と、密度と管理しやすさのバランスを見つけるためにこれらの数値を押し上げ続けました。
Bargeの教訓 (27:00)
そして私たちは「Barge」を開発しました。Bargeは、これまでで最も野心的なストレージ密度のエンジニアリングプロジェクトでした。1つのホストに288台のハードドライブを搭載した巨大なストレージサーバーです。この数字を少し考えてみてください、288台です。現在の20テラバイトのドライブを使用すると、1台のサーバーでほぼ6ペタバイトの未加工ストレージが得られます。これは、AWSの初期にいくつかのデータセンターが持っていたストレージ容量を超えています。
これはストレージ密度の可能性を極限まで押し広げようとした試みでした。そして、それは印象的なエンジニアリングの成果でしたが、密度の限界についていくつかの重要な教訓を私たちに教えてくれました。
最初の教訓は物理的制約についてです。これは文字通り「重い」制約でした。各Bargeラックの重量は驚くべき4,500ポンド、つまり2トン以上でした。これにより、私たちのデータセンターで実際の課題が生まれました。床を補強し、配置場所を慎重に計画し、これらを移動するために特別な機器を使用する必要がありました。
さらに、288台の回転ドライブを一緒に詰め込むことは、重量を増やすだけでなく、私が「振動オーケストラ」と呼ぶものを引き起こします。通常、ドライブを一緒に配置するのは大した問題ではありませんが、7,200RPMで回転する288台のドライブを持つと、振動の影響が大きくなり、ドライブのパフォーマンスと信頼性に実際に影響を及ぼす可能性があります。
次に、ソフトウェアの複雑さがあります。288台のドライブを1つのホストから管理することは、私たちのソフトウェアシステムを限界まで押し上げました。考えてみてください。処理しなければならないさまざまな障害モード、データ配置アルゴリズムの複雑さ、および大規模なドライブプール全体で一貫したパフォーマンスを維持する課題です。
しかし、おそらく最も重要な教訓は「ブラスト半径」についてでした。Bargeサーバーが故障した場合（サーバーは故障します）、その影響は非常に大きなものとなります。突然、6ペタバイトのストレージが利用不可能になる可能性に直面します。冗長性があったとしても、その大量のデータを復旧するプロセスには多大な時間とネットワーク帯域幅が必要です。
そのため、私たちはBargeに別れを告げる必要があると分かりました。（霧笛の音）これらの教訓を得て、私たちは一歩下がって考える必要がありました。運用の複雑さをどのように減らし、ストレージインフラストラクチャの柔軟性を高めながら、引き続き高性能をお客様に提供できるか？
その答えを見つけるために、私たちはS3、EBS、EFSといったストレージサービスの洞察に目を向けました。これらのサービスはすべて標準のストレージサーバーアーキテクチャ上に構築されていますが、それぞれにユニークな要件がありました。一部のサービスはより多くのメモリを必要とし、一部のサービスはより少ない計算能力を必要としていました。しかし、ストレージ層自体の機能は同一でした。
計算リソースとストレージの緊密な結びつきが私たちを制約しているのでしょうか？計算リソースとストレージを分離する「ディスアグリゲーション」の概念が非常に魅力的に見え始めました。サービスが必要とする直接アクセスとパフォーマンスを維持しながら、計算リソースとストレージを独立してスケールさせる方法を見つけることができれば、両方の利点を享受できる可能性があります。
Nitroを用いたディスアグリゲートストレージの利点 (30:23)
ここで、私たちはすでにツールキットの中に持っていたもの、Nitroを活用することを考え始めました。これまでヘッドノードに接続していたドライブを、JBODエンクロージャー内にNitroカードを直接組み込むことでストレージをディスアグリゲートしました。これらのNitroカードは、ドライブに独自のインテリジェンスとネットワーク接続を与えるものと考えてください。各ドライブは、安全に仮想化された独立したネットワークエンドポイントになります。
このアプローチが非常に強力なのは、ドライブとストレージサービスが必要としていた直接的な低レベルのアクセスを保持しながら、従来の物理的制約を完全に取り払うことができる点です。Nitroはネットワークの複雑さ、暗号化、セキュリティのすべてを処理します。また、Nitroは高性能と低レイテンシを目指して設計されているため、ネットワーク越しであってもドライブのネイティブパフォーマンスをそのまま提供します。
これがデータセンターでどのように見えるかを説明します。一見すると、これは標準的なJBODシャーシのように見えるかもしれませんが、いくつかの重要な違いがあります。先ほど述べたNitroカードが実際にドライブとともに組み込まれています。この設計の美しさは、そのシンプルさにあります。ラックの内部を見ると、従来のストレージサーバーではなく、ネットワークスイッチのように見えるものが確認できます。
さらに、この設計はメンテナンスも簡単にしました。ディスアグリゲートされたストレージアーキテクチャのおかげで、故障したドライブをサービスからすぐに取り外し、数回のAPIコールで別の正常なドライブに置き換えることができます。ホットスワップ可能なドライブコンテナにより、データセンター技術者はサービスの可用性に影響を与えることなく、これらのユニットを簡単にサービスできます。そのため、ドライブの故障はもはや問題ではありません。しかし、ヘッドノードについてはどうでしょうか？ここが非常に興味深いところです。
従来のアーキテクチャでは、ヘッドノードの故障は重大なイベントでした。数十台、場合によっては数百台のドライブへのアクセスを失い、そのサーバーを修理または交換するまで待たなければなりませんでした。Bargeの例を思い出してください。1台のサーバー故障が288台のドライブに影響を及ぼしました。
しかし、ディスアグリゲートされたストレージでは、ヘッドノードの故障はほとんど取るに足らないものとなります。ドライブがネットワーク上で独立してアドレス指定されているため、新しいコンピュートインスタンスを起動して、すべてのドライブを再アタッチするだけで済みます。これは標準的なEC2インスタンスの復旧プロセスと同じで、通常数分で完了します。データ移動も不要で、複雑な再構築プロセスも必要ありません。ただ再アタッチして、操作を再開するだけです。
これらの故障シナリオは、ある重要なことを浮き彫りにします。私たちはブラスト半径を劇的に削減しながら、復旧速度を実際に向上させました。これは、コンピュートとストレージを分離することで可能になることのほんの始まりに過ぎません。
ディスアグリゲートされたストレージのもう一つの強力な利点は、コンピュートとストレージを独立してスケールさせる能力です。S3では、新しいストレージ容量を追加する際に、通常、データを新しいドライブにバランスさせる期間中に計算負荷が増大します。この初期期間に限って計算リソースを一時的にスケールアップおよびスケールアウトし、その後通常の操作に戻すことができます。
この柔軟性により、運用をより効率的に行うことができ、最終的にはお客様により良い価値を提供できます。ディスアグリゲートされたストレージにより、長年私たちのストレージアーキテクチャを制約していた固定比率から完全に解放されました。コンピュートとストレージを分離することで、各コンポーネントを独立してスケールさせながら、クラウド環境で期待されるような高性能を維持できます。ブラスト半径が大幅に縮小し、故障の影響が制限され、復旧が迅速になり、サービスはこれまで以上にレジリエントになりました。
さらに、運用の柔軟性が高まったことで実際の運用上の利益も確認されています。サービスは、ハードウェアの制約ではなく、実際のニーズに基づいてコンピュートリソースを最適化することができます。メンテナンスが簡素化され、キャパシティプランニングが柔軟になり、イノベーションも迅速に行えます。
おそらく最も重要な点は、このアーキテクチャが将来に向けた準備を整えていることです。ドライブ容量が成長し続ける中で、ディスアグリゲートされたストレージは、私たちのインフラを適応させ進化させる柔軟性を提供します。ストレージ密度の課題を解決するために始まったソリューションが、より効率的で信頼性の高いストレージサービスを構築するための基本的な手段へと発展しました。
これをもって、ピーターに戻します。（観客の拍手） （アップビートな音楽）
Peter DeSantis: AIインフラストラクチャとTrainium2 (35:01)
さて、素晴らしいプレゼンテーションでしたね。デイブはAWS Computeにおける革新の数々を垣間見せてくれました。次に、全く異なる種類のワークロードについて数分間お話ししたいと思います。それは人工知能（AI）です。
実際には2つのワークロードがあります。AIモデルのトレーニングとAI推論です。AIワークロードの非常に興味深い点の1つは、全く新しい方法で発明を行う機会を私たちのチームに提供することです。
今夜、私たちはいくつかの革新を取り上げます。例えば、最高性能のチップを開発し、それらを新しい技術で相互接続することに挑戦しています。さらに、ここ10年間で推進してきた革新をこの新しい領域にどのように適用しているかについても説明します。これにより、AWSのパフォーマンス、信頼性、そして低コストをAIワークロードにもたらしています。
私たちは、ウェブサービス、ビッグデータアプリケーション、分散システムのようなスケールアウトワークロードについて多く話してきました。スケールアウトワークロードは、システムに追加リソースを投入すると非常に効率的に実行されます。
1.AIトレーニングとスケールアップの課題 (36:12)
私たちはこれらのワークロードに最適化されたインフラストラクチャを構築するために多大な投資を行ってきました。デイブが先ほど説明したように、そのいくつかの革新について話してくれましたね。しかし、AIワークロードはスケールアウト型ではなく、スケールアップ型のワークロードです。それがなぜなのか、説明しましょう。
AIの能力が急速に進化している背景には、モデルがますます大規模化していることがあります。2022年にこの話をしたときは、数十億パラメータのモデルに興奮していました。昨年は、数百億パラメータのモデルが話題でした。そして、近い将来、最先端モデルは数兆パラメータに達する可能性があります。
この成長の理由は何でしょうか？2020年に研究者が「スケーリング法則」という画期的な論文を発表しました。この論文では、パラメータ数、データセットサイズ、計算量をスケールアップすることでモデルの能力が向上すると仮定されていました。それ以来、より大規模で計算集約型のモデルを構築する動きが加速し、これらのモデルは確かに進化しています。皆さんも日常生活でその進化を体験しているでしょう。
これらのグラフを注意深く見ると、非常に興味深いことが分かります。これらは対数グラフであり、x軸とy軸が対数スケールで表示されています。対数グラフ上の直線は誤解を招く場合があります。
計算量のグラフを詳しく見てみましょう。私たちは通常、線形グラフに慣れています。例えば、xを1増やすとyも1増える、といった線形関係です。しかし、対数グラフでは、直線は乗数的な関係を示します。例えば、xを4倍にするとyが2倍になる、といった具合です。スケーリンググラフで示されているのは驚くべきことです。損失（y軸の測定値）を半分にするには、計算量を100万倍にする必要があります。100万倍です。
このy軸の測定値が50％向上するモデルは、他の多くのベンチマークで非常に賢くなることが予想されます。しかし、この計算量とモデル損失の関係性は、なぜ業界がより良いAIインフラを構築するために数百億ドルを投資しているのかを説明しています。
では、「より良いAIインフラ」とは何を意味するのでしょうか？それを理解するために、大規模なAIモデルがどのようにトレーニングされるかを見てみましょう。
現代の生成型AIアプリケーションの核となるのは、予測エンジンです。トークン（単語の一部）セットを入力として与えると、次のトークンを順次予測します。この非常に基本的な「次のトークンを予測する」スキルから、推論や問題解決といった驚くべき特性が生まれます。
このような予測モデルを構築するためには、モデルを数兆のトークンデータでトレーニングし、トレーニングデータ全体の予測エラーを最小化するモデルウェイトのセットを見つける必要があります。このトークン全体でのトレーニングプロセスには膨大な計算量が必要です。最も大規模なモデルを単一のサーバーでトレーニングするには、最も強力なサーバーでも数世紀、場合によっては数千年かかるでしょう。
そこで、当然のことながら、並列化が必要になります。最も明白な方法はトレーニングデータを分割することです。一見するとこれは簡単なように思えます。例えば、1つのサーバーで1000年かかるものを、1000台のサーバーで実行すれば1年で済むはずです。しかし、これはスケールアウト型のワークロードであれば真実ですが、残念ながらそれほど単純ではありません。
説明したプロセスは「データ並列化」と呼ばれます。そして多くの良いことと同様に、データ並列化にも注意書きがあります。単純な分割統治のアプローチを取ると、独立したモデルがいくつも作られ、最後にそれを結合しようとすることになりますが、それでは機能しません。
データ並列化を採用する場合、すべてのサーバーがモデルウェイトを継続的に共有し結合する必要があります。これにより、大規模なサーバークラスターが1つの統一されたモデルを構築できるのです。
ここで重要になるのが「グローバルバッチサイズ」という概念です。グローバルバッチサイズは、すべてのサーバーから結果を結合する必要がある前に処理できるデータの最大セットを指します。このグローバルバッチサイズは、全体のトレーニングデータの中で非常に小さな割合に過ぎません。
データ並列化が実際にどのように機能するかを説明します。グローバルバッチサイズを超えないデータの塊を取得し、それをさらに均等な部分に分割してすべてのサーバーに分配します。次に、各サーバーが割り当てられたデータをトレーニングし、完了するとクラスター内の他のすべてと結果を結合します。そして、すべてのサーバーが結果を結合したら、次のデータバッチに進むことができます。
実際には、このグローバルバッチサイズ制限のため、トレーニングクラスターを数千台以上にスケールアウトすることは非常に困難です。それ以上進むと、各サーバーが非常に小さなデータしか受け取れず、データを実際に処理するよりも結果の調整に多くの時間を費やしてしまいます。
サーバーを増やし続けても、速度は向上せず、コストだけが増加します。データ並列化とその制限について理解することは、AIインフラの2つの基本的な柱を浮き彫りにします。
1つ目は、グローバルバッチサイズによるスケールアウトの制限があるため、より大きなモデルを構築するには、より強力なサーバーを構築する必要があるということです。これがインフラストラクチャのスケールアップの課題です。
2つ目は、AIモデルを構築する際のスケールアウトの制限にもかかわらず、非常に大規模なクラスターを構築することで大きな価値を得られることです。これをうまく行うためには、効率的なデータセンター、高速スケーリング、優れたネットワークなど、長年にわたって構築してきたスケールアウトツールを活用する必要があります。
まず、これらの課題のうち最初の「スケールアップの課題」を見てみましょう。「最も強力なサーバーを構築する」とはどういう意味でしょうか？それは、可能な限り小さなスペースに、計算能力と高速メモリを詰め込んだ、一貫したコンピューティングシステムを意味します。
では、なぜ可能な限り小さなスペースに詰め込むことが重要なのでしょうか？それは、計算能力とメモリを近くに配置することで、大量の高帯域幅・低レイテンシの接続を使用してすべてを接続できるからです。
レイテンシの部分は直感的に理解できると思いますが、近くにあることでスループットも向上します。理由は、距離が近いほどデータを伝送するためのワイヤーを短くできるため、より多くのワイヤーを詰め込むことができるからです。また、レイテンシが低くなり、データ交換のためにより効率的なプロトコルを使用することもできます。
Trainium2の設計と特長 (43:21)
これは一見すると単純なように思えますが、非常に興味深い課題です。昨年、私たちは次世代のTrainiumチップであるTrainium2を発表しました。そして今夜、Trainium2を使用してAWSで最も強力なAIサーバーを構築する方法をご紹介します。まず、システムの最小構成部分であるTrainium2チップから始めましょう。このチップを活用して最大のAIサーバーを構築する際に直面する技術的な制限についても説明します。
まず、チップはシリコンウェハ上で非常に高度な製造技術を使って作られています。この技術は常に進化しており、最大限のコンピュート能力とメモリをシステムに搭載したい場合、最も高度な製造技術やパッケージ技術を活用して最大サイズのチップを作ることから始めるのが良いでしょう。そして、私たちはまさにその方法でTrainium2を作りました。しかし、最初の技術的な制限に直面しました。それは、シリコンウェハをエッチングするために使用されるレンズ、すなわちレチクルがチップサイズの最大値を約800平方ミリメートル（約1.25平方インチ）に制限していることです。おそらく手に持っているものが1.25平方インチよりも大きく見えると思われるでしょうが、それは私が持っているものが実際のチップではなく、パッケージだからです。多くの人がコンピューターチップというと、マザーボードの中央にあるヒートシンクの下にあるものを思い浮かべますが、実際にはそれはパッケージであり、チップはその内部にあります。
数年前、パッケージは基本的に単一のチップを囲み、それをマザーボードに接続するための簡単な仕組みに過ぎませんでした。しかし今日では、パッケージははるかに高度になっています。先進的なパッケージング技術は、複数のチップを単一のパッケージ内で接続するために「インターポーザ」と呼ばれる特殊なデバイスを使用します。インターポーザ自体が小さなチップであり、通常のPCBベースのマザーボードで得られる帯域幅の10倍の接続を可能にする小型のマザーボードとして機能します。
これまでのGravitonプロセッサの数世代で、私たちは先進的なパッケージング技術を使用してきました。ここでGraviton3とGraviton4をご覧いただくと、それぞれのチップまたはパッケージには複数のチップレットが内蔵されていることがわかります。Graviton4のパッケージには実際に7つのチップレットが搭載されています。中央の大きなチップが計算コアであり、周囲の小さなチップはメモリやシステムバスの他の部分にアクセスするためのものです。この分離により、Graviton4プロセッサのコア数を50％増加させることが可能になりました。
このアプローチはGravitonに非常に有用でしたが、優れたAIサーバーを構築する際には基本的な手法です。こちらが私が手に持っているTrainium2のパッケージです。このパッケージには、中央に並んでいる2つのTrainiumチップが含まれています。それぞれのTrainium2チップは、2つのHBM（高帯域幅メモリ）モジュールの隣に配置されています。HBMは複数のメモリチップを積み重ねた特殊なモジュールで、チップを積み重ねることで同じエリアにより多くのメモリを搭載できます。これは、メモリチップが実際に消費電力が少なく、発熱量が少ないためです。
このパッケージを見ると、計算能力とメモリが非常に多いことがわかります。しかし、なぜパッケージをさらに大きくできないのでしょうか？ここで2つ目の制限に直面します。現在、パッケージのサイズは実際に最大チップサイズの約3倍に制限されています。
この制限を理解するために、さらに詳しく見てみましょう。このイラストでは、いくつかのHBMを取り外し、下にあるインターポーザを覗き見ることができます。インターポーザに接続されるために使用される非常に小さな突起を見ることができますが、これをもっとよく見るための角度があります。これはAnnapurnaチームが私のために作成した非常にクールな画像です。チップの断面を注意深くスライスして、その紫色の線に沿って切断し、顕微鏡を使って横からその画像を拡大しました。すると非常に興味深いものが見えます。左上にはTrainium2の計算チップがあり、その隣にはHBMモジュールが見えます。そして非常に面白いのは、HBMモジュールの層が実際に見えることです。どちらのチップも薄く連続したウェハ上に配置されています。
これがチップ間を接続するインターポーザです。そして、ここで見えるのはインターポーザにチップを接続するための非常に小さな接続点です。これらの接続点は非常に小さいドットで、それぞれ約100ミクロンのサイズしかありません。これはあなたが見た中で最も細かい塩の粒よりも小さいです。そして、これらのすべての接続は、チップが接続された状態を維持するために確実に固定されていなければなりません。
このため、パッケージのサイズには限界があるのです。すべての接続をしっかりと固定できるよう、パッケージが十分に安定していなければならないからです。このように小さな寸法だからといって誤解しないでください。これらのチップには膨大な量の電力と熱が動いています。1つのTrainiumチップが、ある人間が数百万年かかって行う計算量を1秒で処理する能力を持っています。その作業を実行するためには、これらのチップには大量の電力供給が必要です。
これだけの電力を低電圧で供給するには、大きな配線が必要です。「大きい」とは相対的な意味ですが、ここでパッケージの底にある配線を見ることができます。これらの配線は「パワーバイア」と呼ばれ、これらを大きくする理由は電圧降下を防ぐためです。半導体は微小な電気信号の有無を用いて情報を記録・処理します。そのため、チップが電圧降下や電圧低下に直面すると、通常は電力供給システムが調整するまで待機する必要があります。この待機は、チップの最適な性能を発揮するためには望ましくありません。
低電圧で電力を供給する必要がある一方で、電力を高電圧で供給する方が効率的です。そのため、データセンターでは実際には複数の電圧で電力を供給しています。電力はチップに近づくにつれて段階的に降圧されます。最後の降圧はパッケージに入る直前で行われます。
このプロセスがどのように行われるかを見るために、Trainium1のマザーボードを見てみましょう。最後の降圧は、パッケージにできるだけ近い場所に配置された電圧レギュレータによって行われています。ボード上の電圧レギュレータをここで強調表示しています。
Trainium2では、この電圧降下を減少させるために、私たちのチームは電圧レギュレータをチップにさらに近づける作業を行いました。ここでTrainium2のボードを見てください。ボードの上部には電圧レギュレータが見当たりません。その代わり、電圧レギュレータはパッケージの周辺部分の下に配置されています。
これを実現するのは非常に難しい作業でした。なぜなら電圧レギュレータは熱を発生させるため、いくつかの新しいエンジニアリングが必要だったからです。しかし、このレギュレータをチップに近づけることで、短い配線を使用することが可能になりました。
短い配線は電圧降下を減少させます。こちらはTrainium1の挙動を示す画像で、計算負荷が増加するとどのように応答するかを見ることができます。大きな計算負荷がかかったときの電圧降下が顕著に見られます。
負荷が一時的に急増すると、電圧が大きく低下します。この一時的な電圧降下により、チップが最適なパフォーマンスで計算を実行できなくなります。このような極端な変動は、チップに負担をかけ、寿命を縮める可能性があります。
次に、同じ負荷をTrainium2にかけた場合の挙動を見てみましょう。ご覧のように、電圧の顕著な低下はありません。これは配線を短くした結果であり、チップのスロットリングを防ぎ、より良いパフォーマンスを実現しています。
さて、チップについてはこれくらいにして、サーバーを見てみましょう。こちらは2台のTrainium2サーバーが収められたラックです。上部に1台、下部に1台あります。これらは非常に大きなサーバーです。それぞれのTrainium2サーバーは8つのアクセラレータトレイで構成されており、各トレイには2つのTrainium2アクセラレータボードが搭載されています。そして、それぞれに専用のNitroカードが付属しています。
Nvidiaベースのシステムで使用されるGPUと同様に、Trainiumサーバーはアクセラレータです。これらはAIモデルを構築するために必要な計算や操作を実行するために設計されています。しかし、これらはオペレーティングシステムやプログラムを実行するために必要な通常の命令をサポートしていません。そのためにはヘッドノードが必要です。
ここで、私たちのサーバーにおけるエンジニアリングの制限が出てきます。サーバーに搭載できるTrainiumアクセラレータの数は、ヘッドノードがこれらのノードを効率的に管理し、データを供給できる能力によって制限されます。したがって、現行の構成以上にアクセラレータを追加しても、性能を向上させることなくコストだけが増加してしまいます。それは私たちが目指すところではありません。
最後に、アクセラレータ全体とヘッドノードをネットワークに接続するためにスイッチが必要です。
では、Trainium2サーバーはどれほど強力なのでしょうか？Trainium2サーバーは、AWSのAIサーバーの中で最も強力であり、20ペタフロップスの計算能力を提供します。これはTrainium1の7倍、現在の最大AIサーバーの25%増です。さらに、Trainium2サーバーは1.5テラバイトの高速HBMメモリを搭載しています。これは、現在の最大AIサーバーの2.5倍に相当します。
さて、これがスケールアップサーバーですが、最も強力なAIサーバーを構築するだけでは十分ではありません。それを迅速に顧客の手に届けることが重要です。
数年前、新しいチップやサーバーが登場したとき、その採用曲線は次のようなものになることが一般的でした。サーバーの初期段階では、一部の初期採用者、通常は大規模なデータベースや最も要求の厳しいワークロードを持つ顧客が採用します。この初期採用者が新しいハードウェアにワークロードを移行している間に、製造上の課題が解決されることがよくありました。
しかし、AIにおいてはそのようにはいきません。より強力なサーバーがより優れたモデルを構築するための価値を持つため、顧客は最新かつ最高のAIインフラストラクチャへのアクセスを初日から求めています。
この前例のない需要を予測して、私たちはここでもイノベーションを行いました。先ほどのTrainium2トレイをもう一度見てみましょう。ここで興味深いのは、見えない部分です。それは大量のケーブルが見当たらないことです。これは、チームがケーブルの数を削減するために多大な努力をしたからです。
ケーブルの代わりに、これらすべてのコンポーネントは下のマザーボード上のワイヤトレースを介して相互接続されています。なぜこれを行ったのか？それは、ケーブル接続ごとに製造欠陥の可能性があるからです。製造欠陥は生産速度を遅らせる要因となります。
実際、Trainium2サーバーの最もクールな点の1つは、それが自動製造および組み立てを可能にするように特別に設計されていることです。この高いレベルの自動化により、初日から迅速にスケールアップすることが可能になります。
Trainium2は、AWSがこれまでに持つAIサーバーの中で最も強力なものであるだけでなく、最速でスケールアップするように設計されています。
Ultra Serverの紹介 (1:00:19)
NeuronLinkは、私たちが開発した専用のTrainium相互接続技術です。NeuronLinkを使用すると、複数のTrainium2サーバーを1つの論理サーバーに統合できます。このサーバー間を接続する帯域幅は毎秒2テラバイト、遅延はわずか1マイクロ秒です。従来の高速ネットワーキングプロトコルとは異なり、NeuronLinkサーバーはお互いのメモリに直接アクセスでき、これによって「ウルトラサーバー」と呼ばれる特別なものを作成できました。
実はずっと、ハードウェアをステージに持ち込みたいと思っていました。しかし、毎年「画面を隠してしまう」という理由で反対されていました。ところで、申し訳ありませんが今年は画面を隠します。ただ、ウルトラサーバーがどのようなものかを示すために、実際にステージに持ち込むことにしました。（観客が歓声と拍手）
こちらがウルトラサーバーです。64個のTrainium2チップが協力して動作し、現在のEC2 AIサーバーの5倍の計算能力と10倍のメモリを提供します。これが、1兆パラメータのAIモデルを構築するために必要なタイプのサーバーです。
すごいですよね。おそらく、この会場には1兆パラメータのAIモデルを構築することを考えている方が1人はいると思います。ですが、それ以外の方々にも関係する内容があります。ここで、現在多くの方が頻繁に行っているAI推論（インファレンス）について見ていきましょう。
大規模モデル推論は、それ自体が非常に興味深く要求の高いワークロードで、実際には2つの異なる作業に分かれます。最初のワークロードは「プリフィル」（pre-fill）と呼ばれるもので、プロンプトや他のモデル入力がトークン生成の準備として処理されます。このプロセスでは、次のプロセスに引き渡すデータ構造を生成するために、大量の計算リソースが必要です。
プリフィルが完了すると、計算されたデータ構造は次の推論ワークロード、つまりトークン生成に引き渡されます。トークン生成の興味深い特徴の1つは、モデルがトークンを1回に1つずつ順次生成することです。これにより、AIインフラストラクチャに対する要求が大きく異なります。
トークンが生成されるたびに、モデル全体がメモリから読み込まれる必要がありますが、使用される計算リソースはごくわずかです。このため、トークン生成はメモリバスに大きな負荷をかけますが、計算リソースの使用量は非常に少なくなります。これはプリフィルとはほぼ正反対の負荷特性を持っています。
では、これらのワークロードの違いが、あなたやAIインフラストラクチャにとって何を意味するのでしょうか？まず、少し前までは、チャットボットのような多くのワークロードは、主にプリフィルのパフォーマンスを重視していました。これは、ユーザーがプリフィル中に画面を見つめたり、スピニングホイールを眺めたりして待っているのが一般的だったからです。
しかし、トークンの生成が始まると、人間が読む速度より速く生成できればそれで十分でした。それほど高速である必要はありませんでした。しかし最近では、モデルはエージェンティックなワークフローで使用されるようになっています。このような場合、次のステップに進む前に、応答全体を迅速に生成する必要があります。そのため、現在の顧客は高速なプリフィルと非常に高速なトークン生成の両方を求めています。
このような需要の変化は、AI推論インフラストラクチャにとって興味深い現象を引き起こしています。非常に高速な推論を求めるニーズがあるため、AI推論ワークロードもまた、最も強力なAIサーバーを必要とするようになってきています。
2.AI推論とBedrockの最適化 (1:04:01)
さて、これら2つの異なるワークロード（プリフィルとトークン生成）は、相補的な特性を持っている点が素晴らしいところです。プリフィルはより多くの計算能力を必要とし、トークン生成はより多くのメモリ帯域幅を必要とします。そのため、これらを同じ強力なAIサーバーで実行することで、優れたパフォーマンスと効率を実現できます。
そこで、私たちはこう考えました。Trainium2の利点をAWSのお客様に推論用途でどのように提供できるか？この質問に答えるべく、Amazon Bedrockに新たな低遅延最適化オプションを追加したことをお知らせできることをうれしく思います。これにより、最新のAIハードウェアとその他のソフトウェア最適化にアクセスでき、多様な主要モデルで最高の推論性能を発揮できます。（観客の歓声と拍手）
低遅延最適化推論は、特定のモデルに対して本日からプレビューとして利用可能です。そのモデルの1つが、非常に人気のあるLlamaです。特に、Llama 405Bおよび小型のLlama 70Bモデルの低遅延最適化バージョンが、AWS上でどのプロバイダーよりも優れたパフォーマンスを提供するようになりました。（観客の拍手）
こちらが、Llama 405B、最も大きく人気のあるLlamaモデルの性能です。ここでは、リクエストを処理して応答を生成するまでの合計時間を示しています。そのため、プリフィルワークフローとトークン生成ワークフローの両方が含まれています。低いほど良いことを示しています。ご覧の通り、Bedrockの低遅延最適化オプションは、他のオファリングと比較してはるかに低い遅延を実現しています。
しかし、他のモデルを使用している場合はどうでしょう？Anthropicとのパートナーシップにより、新しく非常に人気のあるClaude 3.5モデルの低遅延最適化バージョンを発表できることをうれしく思います。リクエストに応じて、低遅延最適化されたHaiku 3.5は、標準のHaiku 3.5よりも60%高速であり、どこよりも高速な推論を提供します。（観客の拍手）
Llamaと同様に、Haiku 3.5もTrainium2を活用してこのパフォーマンスを実現しています。ただし、この話を信じるかどうかはあなた次第です。
Tom Brown (Anthropic): AWSとのパートナーシップ (1:06:18)
私は先ほど触れた「スケーリング法則」論文の共同著者の1人をこのステージにお招きできることを非常に嬉しく思います。どうぞお迎えください。Anthropicの共同創設者であり、最高コンピュート責任者であるトム・ブラウンさんです。（観客の歓声と拍手） (音楽が流れる)
1.Claudeモデルの最適化 (1:07:05)
ありがとう、ピーター。Anthropicでは信頼できるAIを構築しています。毎日、世界中の何百万人もの人々がClaudeを使って仕事をしています。Claudeはコードを書き、ドキュメントを編集し、ツールを使ってタスクを完了します。正直に言うと、これからお話しするこの基調講演の半分はClaudeが書いてくれました。
さて、AWSとのパートナーシップのおかげで、大企業から中小企業までが、すでに信頼している安全なクラウド上でClaudeを利用できるようになりました。ここからは、私たちのコラボレーションがどのように機能しているのか、もう少し掘り下げてお話しします。まずは、先ほどピーターが触れたClaude 3.5 Haikuについてです。これは最新かつ最速のモデルの1つであり、その小さなサイズにもかかわらず、最大のモデルであるOpusと同等の性能を発揮することもありますが、コストは15分の1です。ピーターが言ったように、私たちは一緒に、この低遅延モードを構築しました。このモードにより、HaikuをTrainium2上でさらに高速に実行できます。今日から、この新しいTrainium2サーバーにリクエストをルーティングするだけで、変更は一切必要なく、APIでスイッチを切り替えるだけで、Haikuを60％速く実行できるようになります。（観客の拍手）この高速化は、インタラクションのループ内で非常に有効です。私はコーダーなので、例えばオートコンプリートを想像してください。キーを押す間の短い時間で補完を表示する必要があります。この60％のスピードアップは、補完が表示されるかまったく表示されないかの違いを生む可能性があります。
では、どうやってこれをそんなに速くしたのか？まずはこのマシンを見てください。すごいでしょう。このマシンを見てください。そして、それに搭載されている各チップには、ピーターが説明したような真剣なスペックがあります。これらのシストリックアレイには、ペタフロップを超える計算能力があります。十分なメモリ帯域幅、迅速な相互接続、優れたスペックを備えています。
しかし、エンジニアなら誰でも知っているように、スペックだけでは不十分です。最高のパフォーマンスを得るには、これらのシストリックアレイが常にデータを供給される状態を保つ必要があります。つまり、メモリや相互接続など、どこからでも入力が遅れることなく処理が順調に進むように、作業をシーケンス化する必要があります。これは、テトリスのようなゲームに似ています。ブロックをぎっしり詰め込むほど、モデルは安価で高速になります。
では、このテトリスゲームをどのように解決したのか？Anthropicのパフォーマンスエンジニアリングチームは、1年以上にわたりAmazonとAnnapurnaと密接に協力して、この課題に取り組んできました。私たちは、コンパイラが多くのことを処理できることを発見しましたが、それでも完璧ではありません。そして、私たちの規模では、完璧を目指す価値があります。Anthropicにとって、1つのパフォーマンス最適化は、新しい100万人の顧客にサービスを提供するのに十分な計算能力を解放することができます。これにより、NKIのような低レベルに移行し、生のハードウェアにできるだけ近いカーネルを書く価値があります。これは、プログラムの最も重要な部分をPythonからCに書き換えるようなものです。
そして、Trainiumの設計は、この種の低レベルコーディングに非常に適していることが分かりました。あまり知られていないことですが、他のAIチップでは、実際にどの命令がカーネル内で実行されているのかを知る方法がありません。そのため、推測するしかありません。それは、目隠しをしてテトリスをプレイするようなものです。Trainiumは、システム内のどこであっても、実行されたすべての命令のタイミングを記録できる、私が初めて見たチップです。
これをお見せしましょう。これがAnthropicで開発した実際の低レベルTrainiumカーネルの例です。ここでは、シストリックアレイがいつ動作しているか、いつブロックされているか、さらに、なぜブロックされていたのか、何を待っていたのかを正確に見ることができます。目隠しを外すことができるのです。これにより、低レベルカーネルの記述が迅速かつ容易になり、私の意見では、はるかに楽しくなります。
さて、楽しい話題といえば、発表したいことがあります。これまで、私たちは推論に焦点を当ててきましたが、Trainiumの名前には理由がありますからね。
2.Project Rainierと次世代モデルのトレーニング (1:10:59)
次世代ClaudeがProject Rainier上でトレーニングされることを発表できることを大変嬉しく思います。この新しいAmazonクラスターには、数十万個のTrainium2チップが搭載されています。（観客の歓声と拍手）
数十万個のチップというのは、数百エクサフロップスに相当し、これまでに使用したどのクラスターよりも5倍以上の性能を誇ります。
では、Rainierは顧客に何をもたらすのでしょうか？世界はすでに、私たちが前回のクラスターで何を成し遂げたかを目にしています。今年初め、AnthropicはClaude 3 Opusを発表しました。これは世界で最も賢いモデルです。
その4か月後、Opusよりもさらに賢く、コストは5分の1のClaude 3.5 Sonnetをリリースしました。そして先月には、3.5 Haikuと、コンピュータを人間のように使うことができるアップグレード版の3.5 Sonnetの両方をリリースしました。
Project Rainierは、私たちの開発をさらに加速させ、研究と次世代のスケーリングを支えます。これにより、顧客はより低コストでより高い知能を、より速い速度で手に入れることができます。また、信頼できるスマートエージェントが、より大きく重要なプロジェクトをサポートします。
Trainium2とProject Rainierにより、私たちは単に高速なAIを構築するだけでなく、スケーラブルで信頼できるAIを構築しています。
ありがとうございました。（観客の拍手と歓声、音楽）
Peter DeSantis: AIクラスタとネットワーク革新 (1:12:29)
ありがとう、Tom。この1年間、Anthropicとの共同イノベーションは非常にエキサイティングな旅でした。今後の可能性に私たちは大いに活力を得ています。
さて、私は先ほど、最高のAIインフラを構築するには最も強力なサーバーを作る必要があると述べました。これがスケールアップの課題です。しかし、それは話の半分にすぎません。
最大のモデルをトレーニングするためには、Project Rainierのような最大のクラスターを構築する必要があります。これが話の後半、スケールアウトの課題です。ここで、AWSがこれまで高性能なスケールアウトインフラでイノベーションを起こしてきた長い歴史が非常に役立つのです。
スケールアウトのイノベーションの素晴らしい例の1つが、弾力的でAIに最適化されたネットワークを構築することです。優れたAIネットワークは、優れたクラウドネットワークと多くの共通点を持っていますが、その全てが大幅に拡張されます。
これをラスベガスの格闘試合に例えるなら、一方的な試合になるでしょう。（ベルが鳴る音）
確かに、クラウドネットワークには、顧客の利用を妨げないよう大量の容量が必要です。実際、この話題については、James Hamiltonが初日のキーノートで語りました。しかし、AIネットワークにはさらに多くの容量が必要です。
各Trainium2ウルトラサーバーには、ほぼ13テラビットのネットワーク帯域幅があります。そしてトレーニング中、全てのサーバーが同時に他の全てのサーバーと通信する必要があります。そのため、ネットワークはこれらのサーバーを遅らせないように、非常に大規模である必要があります。
クラウドネットワークは、成長に対応するために迅速にスケールする必要があります。私たちは毎日、世界中のデータセンターに数千台のサーバーを追加しています。しかし、少し前に触れたように、AIのスケールはそれ以上に急速に進んでいます。
AIインフラの構築に何十億ドルも費やしている場合、それをすぐに設置できるようにしたいと考えるのは当然です。
さらに、クラウドネットワークは信頼性が求められます。そして、クラウドネットワークはそれを実現しており、最も洗練されたオンプレミスネットワークでさえ達成できないほどの高可用性を提供しています。私たちのグローバルデータセンターネットワークは、5つの「9」の可用性を実現しています。
しかし、ここでもAIのワークロードはさらに高い要求を突きつけます。AIネットワークで一瞬でも障害が発生すると、クラスター全体でトレーニングプロセスが遅延し、アイドル状態のキャパシティやトレーニング時間の延長を招く可能性があります。
では、クラウドネットワークのイノベーションを活用して、優れたAIネットワークを作るにはどうすればいいのでしょうか？
こちらが、私たちの最新世代のAIネットワークファブリックの写真です。「10p10uネットワーク」と呼ばれるものです。
1.10p10uネットワークとスケールアウトの課題 (1:15:09)
これは、ウルトラサーバー2クラスターを支えるネットワークファブリックで、TrainiumおよびNvidiaベースのクラスターの両方に使用しています。私たちはこれを「10p10u」と呼んでいます。それは、数千台のサーバーに対して数十ペタバイトのネットワーク容量を提供し、遅延を10マイクロ秒未満に抑えることを可能にするからです。10p10uネットワークは大規模な並列性を持ち、密に接続されたネットワークです。また、このネットワークは弾力性を備えており、数ラックに縮小することもでき、複数の物理データセンターキャンパスにまたがるクラスターにスケールアップすることもできます。ここにあるのは、10p10uの単一ラックです。
さて、スイッチが美しい緑色であることに気付いたかもしれません。実は、緑は私の好きな色で、特にブリティッシュレーシンググリーンが好みですが、この色もなかなか素晴らしいです。ただ、私たちのデータセンターで緑色のスイッチを見るのは初めてだったので、なぜこの色なのかチームに尋ねました。すると、この緑色は「グリーナリー」と呼ばれ、2017年のPantoneカラーオブザイヤーだったそうです。ある供給業者が余った塗料を非常にお得な価格で提供してくれたとのことです。私はこの話が好きです。なぜなら、これは私たちのデザイン哲学を体現しているからです。顧客にとって重要なことにお金を使い、そうでないこと、たとえば塗料にはお金を節約するという哲学です。
もう1つ気付いたかもしれないのは、このラックに非常に多くのネットワーキングケーブルが接続されている点です。緑色ではない部分はネットワークパッチパネルです。このような密なネットワークファブリックを構築するには、スイッチを非常に正確なパターンで接続する必要があります。これを可能にするのがこのパッチパネルです。これらのパッチパネルは長年にわたり非常によく機能してきましたが、10p10uネットワークではケーブルの複雑さが大幅に増加し、状況はかなり混雑してきました。さらに、設置スピードが加速しているため、これはチームにとって革新の絶好の機会となりました。
その革新の1つが、独自のトランクコネクタの開発です。これは、16本の個別の光ファイバーケーブルを1つの堅牢なコネクタにまとめたスーパーケーブルのようなものです。これの何が画期的かというと、複雑な組み立て作業がデータセンターのフロアではなく、工場で行われる点です。これにより、設置プロセスが大幅に簡略化され、接続エラーのリスクがほぼゼロになります。
控えめに聞こえるかもしれませんが、その影響は大きいです。トランクコネクタを使用することで、AIラックの設置時間が54%短縮されました。さらに、見た目もずっときれいになり、緑色のスイッチが一層映えるようになりました。しかし、チームはここで終わらず、さらなる革新を続けました。
次に紹介するのは「ファイアフライ光学プラグ」という素晴らしいデバイスです。この低コストのデバイスはミニチュアの信号反射器として機能し、ラックがデータセンターフロアに到着する前にネットワーク接続を包括的にテストし検証することを可能にします。これにより、サーバー到着後のケーブルデバッグに時間を無駄にすることがなくなります。
AIクラスターの世界では、時間は文字通りお金です。そして、このプラグはもう1つの役割を果たします。それは保護シールとして機能し、光接続部分にホコリが入るのを防ぎます。これは些細に聞こえるかもしれませんが、小さなホコリの粒子でさえネットワークパフォーマンスの低下を引き起こす可能性があります。このシンプルなデバイスはネットワーク性能を向上させるのです。
つまり、この洗練されたソリューションで、2つの重要な課題を解決しました。比喩的に言えば、「1つのスコーンで2羽の鳥を養う」というものです。このような革新のおかげで、10p10uネットワークはこれまでで最速のスケーリングネットワークになりました。
このチャートでは、私たちが異なるネットワークファブリックで設置したリンク数を示しています。10p10uネットワークの成長速度は、私たちにとっても前例のないものでした。過去12か月間に300万本以上のリンクを設置し、それはTrainium2の展開が始まる前のことです。
これが私たちの最後の課題、高いネットワーク信頼性を実現することに繋がります。AIネットワークで最大の障害要因は光リンクです。光リンクは、これまで見てきたケーブルで光信号を送受信する小型のレーザーモジュールです。AWSは独自の光学機器を設計・運用してきた長い歴史があります。その結果、運用の厳密さと大規模なスケールにより、故障率を一貫して下げてきました。
しかし、どれほど故障を減らしても、完全にゼロにはできません。そこで、故障の影響をどうすれば小さくできるかを考える必要があります。すべてのネットワークスイッチには、パケットのルートを決定するデータが必要です。これらはネットワークの「地図」と言えます。AIネットワークでは、この地図が数十万の経路を考慮する必要があります。そして光リンクが故障するたびに、この地図を更新しなければなりません。これをどうすれば迅速かつ確実に行えるでしょうか？
簡単なアプローチは、地図を中央管理することです。1つの「頭脳」がネットワークを最適化するというアイデアは非常に魅力的ですが、問題があります。ネットワークが巨大になると、中央制御がボトルネックになるのです。故障の検知は困難で、スイッチの更新には時間がかかり、中央コントローラーは単一障害点になります。そのため、大規模なネットワークは通常、分散型に移行します。BGPやOSPFのようなプロトコルを使用して、スイッチが近隣の状況を共有し、協力して自分たちに適したネットワーク地図を作り出すのです。これらのアプローチは堅牢ですが完璧ではありません。大規模なネットワークでは、リンクが故障すると、スイッチが協力して新しい最適な地図を見つけるのにかなりの時間がかかります。AIネットワークでは、その時間は作業が止まっていることを意味します。つまり、不十分な選択肢が2つしかない場合、新しい道を切り開く必要があります。
2.SIDRによるネットワークリエンジニアリング (1:21:31)
そこで私たちは、10p10uネットワークにおいて、完全に新しいネットワークルーティングプロトコルを構築することにしました。これを「スケーラブル・インテント駆動型ルーティング」、略してSIDRと呼んでいます。そして、ネットワーク関係者の方ならお気づきかもしれませんが、この名称は少しジョークのようなものでもあります。
SIDRは、中央集権型と分散型の両方の長所を組み合わせた仕組みを提供します。SIDRを簡単に説明すると、中央のプランナーがネットワーク全体を解析して構造を作り上げ、その情報をすべてのスイッチに配信するというものです。これにより、スイッチが障害を検知した際に、迅速に自律的な判断を下せるようになります。
つまり、SIDRは中央制御による最適化と、分散型のスピードと回復力を組み合わせているのです。その結果、SIDRは、10p10uネットワークにおいて、障害に対して1秒以内で応答します。これは、他のネットワークファブリックで使用している代替アプローチと比較して、10倍速い応答時間です。他のネットワークがまだルートの再計算を行っている間に、10p10uネットワークはすでに復旧し、作業を再開しています。
さて、今夜は多くの内容についてお話ししました。NitroやGraviton、ストレージなど、デイブが語った基本的な革新から、Trainium2を使った私たちの最大かつ最強のAIサーバーの構築、そして、これまでのクラウドスケールアウト技術のイノベーションがAIにどのように恩恵を与えているかについてまで触れました。
今夜の内容から、私たちが全スタックにわたって革新を進め、顧客の皆さまに向けて本当に差別化された提供を行っていることを理解していただければ幸いです。
それでは、良い夜をお過ごしください。ありがとうございます。そして、re:Inventをお楽しみください。(観客の拍手と歓声)(音楽)