re:Invent 2025: NOAAにおけるHPCとAIの融合による気象予報の革新とAWSインフラ活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Mission-Ready HPC: From NOAA Today to AI Tomorrow (WPS205)
この動画では、NOAAのDavid MichaudとAWSのRayette Toles-Abdullahが、高性能コンピューティングとAIの融合による気象予報の革新について解説しています。HPC市場は2023年に370億ドル規模で、2029年には490億ドルに成長すると予測されています。NOAAは1日に1400万個のプロダクトを生成し、99.97%のオンタイム配信を達成しています。GraphCastベースのAIモデルは、従来25,000コアで1時間半かかった予測を、H-100数個で7分に短縮しました。AWSではHPC7aインスタンス、Elastic Fabric Adapter、FSx for Lustreを標準化し、Hurricane Analysis and Forecasting SystemやRapid Refresh Forecast Systemの運用を支援しています。AWSは米国政府向けに500億ドルのインフラ投資を発表し、1.3ギガワットのコンピュート容量を提供予定です。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
高性能コンピューティングとAIの融合：気象予報の革新
こんにちは。re:Invent へようこそ。大西洋で発達中のハリケーンを追跡している場面を想像してください。多くの命が危機に瀕しており、沿岸コミュニティが影響に備えています。すべての予報の背後に、すべての避難命令の背後に、命を救うすべての決定の背後には、膨大な計算能力が働いています。本日は、National Oceanic and Atmospheric Administration の David Michaud と AWS の Rayette Toles-Abdullah という尊敬する同僚たちとともに、高性能コンピューティングが従来のスーパーコンピュータから AI 主導の予報へとどのように進化しているのか、そして危険な気象現象の予測、追跡、予報の方法をどのように変革しているのかについて探っていきます。これらの現象は私たちの地球に影響を与えています。
高性能コンピューティング と人工知能の融合は進化的なテクノロジーです。しかし、非常に危険なイベントにどれだけ迅速かつ正確に対応できるか、そしてそれによってより多くの命を救うことができるかを革新しています。本日はこの旅を皆さんと一緒に進めることができて興奮しています。私たちのプレゼンテーションは以下のように構成されています。まず この AI と高性能コンピューティングの融合に関して市場が何をしているのかについて話しましょう。2023 年の Hyperion Research によると、HPC 市場は約 370 億ドルで、2024 年には 24 パーセント成長しました。2025 年にはさらに高い数字になると予想しています。
2028 年までに、HPC 市場の 3 分の 1 がクラウド上にあると予想されています。2029 年までに、融合した AI と HPC の市場は 490 億ドルになると予想されています。これは私たちが見ている初期の成果によって市場から大きな検証を受けており、NOAA のような機関が HPC を大規模に実行して生み出している革新に続いています。その時点で David Michaud をステージに招待し、彼は NOAA のケーススタディについて深く掘り下げます。彼は NOAA のミッション、彼らが行う重要な仕事、それがどのように命に影響を与えるのか、そして様々なミッション成果を達成するために NOAA で大規模に使用される膨大な計算能力についてお話しします。
その後、Rayette Toles-Abdullah がステージに登壇します。AWS の Principal Solutions Architect として、彼女は NOAA のスーパーコンピューティングおよび他のクラウド機会に関する能力開発とサービス開発をリードしてきました。彼女は NOAA のミッションを支える アーキテクチャ機能について深く掘り下げます。最後に、私がステージに戻ってきて、この分野で AWS が約束した新しい投資についていくつか議論し、また融合した HPC と AI スペースのクラウドにおける革新の例を私たちの他のパートナーから提供します。それでは、David Michaud にステージにご参加いただけることを光栄に思います。ありがとうございました。
National Weather Serviceの多様なミッション：太陽の表面から海の底まで
こんにちは、皆さん。私の名前は Dave Michaud で、National Weather Service で働いています。National Weather Service での私の役割は、本質的には企業全体で保有しているネットワークの運用管理、すべてのスーパーコンピューティング、すべてのデータ配信システム、そしてメリーランド州 College Park にある国立センターのすべてのローカルサポートを管理することです。 私は NOAA に約 30 年間勤務しています。これは私の人生であり私の情熱なので、本日ここで私たちが行っていることについてお話しできることに非常に興奮しています。
National Weather Service の使命についてお話しすることから始めたいと思います。National Weather Service について人々と話をするとき、私たちが行っていることの多様性に気づいていない人が多いんです。多くの人は翌日何を着たらいいか、傘を持っていく必要があるかどうかといったことを考えています。でも私たちはそれ以上のことをしているんです。National Weather Service は非常に多様な使命を持っています。私たちの領域は大西洋全域から米国本土、そして北半球の太平洋全域まで、予報を行う領域と規模の観点から広がっています。その幅は驚くほど広いんです。太陽の表面から海の底まで、あらゆることを行っています。
太陽の表面の活動を監視し、コロナ質量放出によって生じる電磁的な障害や嵐を予報し、それらが地球に近づくときに監視しています。私たちは従来の予報を行っていますが、National Hurricane Center での熱帯予報も行っており、これらの嵐を監視しています。大西洋と太平洋全域にわたって航空気象を提供しています。航空について考えるとき、私たちは航空会社が飛行効率を計算し、飛行機にどのくらいの燃料を積むかを決めるのに役立つデータを生成しています。すべてのパイロットは離陸前に認定された気象ブリーフを受ける必要があり、私たちのすべてのデータと予報がそれらのメカニズムに供給されています。
津波警報があり、地震活動とそれが海面に与える影響、そしてそれらが陸地に近づくときに与える影響を監視しています。火災気象があり、実際の気象学者が火災司令官とともに森林火災や野火の現場に駐在し、組み込まれています。私が取り上げなかった多くの部分があり、最後の一つは Ocean Prediction Center です。Ocean Prediction Center について考えるとき、海を横切って移動するすべての船舶交通のすべての経済的影響と、やってくるこれらの巨大な嵐を考えてください。これは船舶が嵐を回避したり、嵐の周りを移動したりする必要性を生み出しています。私たちは本当に生命の安全と経済に焦点を当てています。
私たちは米国全体で運営しており、American Samoa からハワイ、グアム、アラスカ、プエルトリコ、米国本土まで、どこでも運営しています。私たちは米国全体の多くのコミュニティに組み込まれています。122 の forecast office があり、これらはおそらくあなたが従来見たり認識したりするであろう気象予報事務所です。私たちは FAA と航空交通管制センターに組み込まれており、意思決定支援を提供しています。河川の頂上と河川の上昇と下降、洪水を予報しています。ユニークなニッチなタイプの気象を見ている特別な national center があり、水文学を見ている water center があります。私たちは本当に意思決定を行う必要がある人々とコミュニティに出ていくように構成されています。
予報から影響評価へ：コミュニティとの信頼関係構築
今日は high performance computing と関連するワークロード、そして私たちが予報士が予報を作成し、予報プロセスを行うのに役立つ大量の予報情報をどのように生成するかについて話します。しかし、使命の観点から、予報は私たちが生成するもののほんの一部であることを見失わないでほしいんです。私たちは過去 10 年ほどの間、コミュニティの意思決定者と協力して、気象の影響がどのようになるかを理解することに本当に焦点を当ててきました。
例えば、私はワシントンDCから来ているんですが、少しでも雪が降ると交通が大混乱になって、それが大きな影響を及ぼします。一方、私が育ったニューハンプシャーでは、1フィートくらいの雪が降っても、人々は問題なく外出して動き回っていました。影響という観点では、場所によって異なる天気や異なるタイプのイベントに対する耐性があるんです。私たちが本当に力を入れているのは、予報を提供することと、コミュニティの意思決定者たちに対してリスク評価を提供することです。彼らはハリケーンの避難指示や高速道路の通行止めなど、コミュニティに対して命を救う指示を出しています。
私たちは本当にコミュニティの意思決定者たちとの信頼関係を構築することに力を入れています。何か起きた時に、誰と一緒に働いているのかを学ぶ必要がないんです。すでに信頼関係があるので、素早く動いて警報を発令することができます。
HPCの進化とミッションパフォーマンス：99.9%のオンタイム配信を実現する14ペタフロップスのシステム
では、High Performance Computing についてお話しします。High Performance Computing について私を興奮させるのは、High Performance Computing やテクノロジーの改善が直接的にミッションパフォーマンスの改善に相関するという点です。High Performance Computing の容量の改善や、High Performance Computing 上でのソフトウェアの動作方法や効率の改善を見ると、それが予報の精度向上、より高い完全性を持つ科学的知見の提供につながり、予報官がミッションをより良く遂行できるようになります。High Performance Computing の改善と予報の改善の間には直接的な相関関係があり、それがさらに信頼関係の向上につながるんです。
ミッションについて、そしてミッション内の多様性についてお話しました。ミッション内での私たちの運用方法は、要件に対して特定の制約を提供し、HPC内での運用方法や HPC 環境内でのワークロードの考え方に影響を与えます。私たちが追求している指標の1つは、プロダクトのタイムリーネスです。毎日、1時間ごとから6時間ごとまで、あらゆる場所で実行されるモデルのサイクルがあります。非常に時間駆動型で、本質的に周期的な性質を持っています。ハリケーンが上陸する場合、予報官が意思決定者と相互作用する必要がある特定のケイデンスがあり、その意思決定者はアップデートを求めています。一般の人々もアップデートを求めており、そこには特定のタイムリーネスとリズムがあり、それが一定レベルの信頼を生み出しています。
プロダクトのタイムリーネスの観点から、私たちはスーパーコンピュータから1日に1400万個のプロダクトを生成しています。私たちは、各プロダクトが前日のいずれかの時点から15分以内に生成されたかどうかを尋ねることで、自分たちを評価しています。そうであれば、私たちは良好です。そうでなければ、私たちは自分たち自身に対して私たちのマークをチェックし、タイムリーネスの数値と統計を削減します。私たちは99.9%のオンタイム配信を達成しようとしています。99%のメトリクスを持っていると思いますが、実際には定期的に約99.97～99.98%のオンタイム配信を達成しています。
タイムリーネスと私たちがソリューションを生成・構築する方法の観点から、私たちは約14ペタフロップスずつ、つまりシステムあたり約40,000コアの2つの高性能スーパーコンピュータを持っています。それらは異なる電力網で動作しており、1つは東海岸、もう1つは西海岸にあります。私たちは10分以内にそれらのシステム間で運用を切り替えることができます。10分以内に、実質的に問題なく、私の予報操作全体をあるシステムから次のシステムに移動させることができます。これが、私たちが定期的にシステムで見ている可用性とデータ移動のタイプです。
気象予測ワークフローの複雑性：データ同化から推論モデルまで
ワークフローについて話しましょう。モデリングシステムは一般的にシステムに流入するデータを持っています。私たちは一貫した基準で1日に数十億の観測データをスーパーコンピュータにストリーミングしています。1つのフィードを運用用のプライマリスーパーコンピュータにストリーミングし、別の並列フィードをバックアップスーパーコンピュータにストリーミングしています。予報を生成するための時間カットオフが来たら、そのデータをダンプして、データの品質管理を行い、その後、分析ステートと呼ぶものを実行します。
本質的には、物理ベースの予報モデルを使用して観測データを遡って見ます。3時間先まで実行して予報を行い、観測データで再度確認します。3時間先まで実行して、データで再度確認します。3時間先まで実行して、その後再度確認して最終的な分析ステートを行います。これにより、モデルが認識する非常に連続的な大気が得られます。実世界ではすべてのデータ観測があり、常に連続しているわけではありません。モデルが持つすべてのデータポイントで正確に観測ポイントがある場合でも、データ同化プロセスを通じてそれを調整する必要があります。
その後、モデル予報を実行します。これは将来に向かって実行されます。数日先まで実行される予報もあります。グローバルモデルは16日先まで実行され、その他のモデルは2週間実行されます。また、9ヶ月先まで実行される結合気候分析システムもあります。モデルが実行されている間、各タイムステップでモデルメモリを出力して準備し、その情報をファイル形式で出力して、人々がダウンロードして見ることができるようにし、予報官が検査できるようにする必要があります。
統計的なポストプロセッシングであれ、モデルへの調整であれ、派生フィールドの追加であれ、一定量のポストプロセッシングがあります。全体的なワークロードの観点からこれの興味深い部分は、予報モデルの特定の部分が大量のコアを必要とし、大規模に並列化されているということです。グローバル予報モデルは、物理ベースのモデルを操作するために1時間半の期間に約25,000コアを必要とします。モデル分析は非常に似ていますが、その後、これらのジョブの周りで実行される多くのシリアルポストプロセッシングがあります。
現在、アーキテクチャを構築する方法は、40,000個の同じ種類のHPCコアを持っています。メモリが高いものもありますが、実際にはHPCタイプのプロセッシングではない多くのプロセッシングがあります。しかし、それはデータが実行される場所に近接している必要があるため、HPCで実行されます。これは、クラウドを見始めるときに興味深いユースケースを提示します。また、さまざまなタイプのインスタンスで得られる柔軟性と、オンプレミスシステムを購入する際にアーキテクチャが正確に何であるべきか、また複数のコアワークロードとシリアルワークロードの間で正確なバランスが何であるべきかについて事前に予測しようとすることを比較します。
これが私たちの本番環境スイートの様子です。ちょっと混乱しているように見えますよね？ 80種類の異なるモデルがあります。すべてスケジュール管理されていて、まるでテトリスのパズルのようにすべてを詰め込む必要があります。一般的に1日に4回のピークとバレーが見られます。スケールの下部を見ると、グリニッジ標準時のゼロから次のゼロまでの24時間の期間です。それぞれのレイヤーは、私たちが実行している異なるタイプのモデルワークロードを表していて、それらが互いに積み重なっています。
ここで興味深いのは、私たちがタイムリネスメトリクスを持っているということです。一般的に、日々のベースでは、物事はかなりスムーズに進行し、すべてうまくいきます。特定の日には、システムに不具合が生じて、ワークロードがバックアップされることがあります。オンプレミスシステムでワークロードがバックアップされた場合、オンプレミスシステムではピークを一定以上に上げることができないため、トラフィック制御を行う必要があります。追いつくために、特定のモデルまたは特定のモデルサイクルを削減する必要があることがよくあります。
クラウド環境を検討する場合、異なる方法でバーストできるため、より迅速な追いつきサイクルが実現できる可能性があります。これらは、オンプレミスとクラウドセットアップの利点を比較検討しようとしているときに、私たちが検討している種類のものです。AI の観点からの補足として、inference モデルについて多くの議論があり、これについては後ほど説明します。inference モデルを見るときに興味深いのは、特殊性を持つニッチでカスタムメイドの AI モデルを生成するのが非常に簡単だということです。1つは標準的なグローバル予報モデルかもしれません。別のものは熱帯予報に向けられているかもしれません。また別のものは特定のドメインスペースや水文学、またはその他のものに向けられているかもしれません。
本番環境でシステムを確実に運用するための実装を管理しながら定期的に物事を実行しようとしている場合、非常に多くの異なるモデルを実行している状況に簡単に陥る可能性があり、それは変更管理の観点からはかなり混乱した状況になります。
AI を見ると、それは興味深いものですが、変更管理の観点からも興味深いことです。問題は、500個のモデルを管理するつもりなのか、それとも、より少ない数のモデルで整合性を得ることにより多く焦点を当てるつもりなのかということです。 前のスライドで示したのは、モデリングスイートの一般的なレイアウトで、これは私たちの通常のルーチンスケジュール作業の大部分を表しています。約80種類の異なるモデルがあります。それらはすべてデータをダンプしており、すべて初期状態を大気に設定しており、すべて将来に向けて予報を行っており、すべてデータをポストしており、すべてが互いに積み重なっています。
他にも、オンデマンドの柔軟な環境に適した様々なワークロードがあります。その一つが熱帯低気圧予測またはハリケーン予測です。現在、本番環境では、最大12種類の異なるハリケーンモデリング実行を実行できる予約済みスロットがあります。これらの黄色いボックスはそれぞれのモデルのドメインを表しており、そのモデルは境界条件として全球モデルを使用しながら、嵐とともに移動します。本番環境では、1日4回、任意の時点で最大12個のこれらを実行できます。
問題は、本番の観点からそのコンピュート容量を予約しておく必要があり、いつでもそれらの嵐を実行する準備ができている必要があるということです。つまり、システム上のスペースは、前のスライドで示した大規模な本番環境を拡張することができません。モデルを実行する必要がある場合、素早くそれらをスピンアップする必要があります。環境がスピンアップするのを待つことはできません。実行を開始する必要がある時点で、そこにいる必要があります。これは、このようなオンデマンド実行でワークロードをアーキテクチャリングする際の、もう一つの興味深い側面です。
また、開発ワークロードもあり、これを「サージワーク」と呼びたいです。開発者は常にモデルの改善に取り組んでいますが、過去30年間の観測データを遡って見て、それを最新のテクノロジーとモデルに適用して、いわゆる再解析データセットを作成したい場合もあります。現在のモデルを使用して連続した大気に適合させ、グリッドに適合させて、きれいで整然とした状態にします。これを30年間遡って行い、30年間先に進めて1日4回の予測を行うことで、膨大な計算ワークロードが生成されます。しかし、これを常に行う必要はありません。これはサージワークロードの一例です。
別の例としては、その数値気象予測の物理ベースのモデル全体を取得して、それを AI モデルに適用し、そのようなワークロードを実行するようにモデルをトレーニングすることが考えられます。これはワンタイムサージの一例です。オンプレミス環境では、ワークロードの優先順位を変更するか、より多くの予算を取得して、その時間をかけて改訂し、床に配置してから、おそらく6～8ヶ月後にワークロードの実行を開始できるようになります。これは開発サージワークロードの一例です。少し話を変えますが、これは私たちにとって新しいものです。特に推論ワークロードである AI ワークロードです。本番環境で運用上実行するものは、これらを試験中であり、現在リアルタイムで実行中です。
AIベースの気象予測の衝撃：1時間半から7分へ、そしてデータ配信の課題
現在、グローバル予測モデルでトレーニングされた GraphCast ベースのモデルがあります。モデリングシステムには2つのタイプがあります。決定論的システムは、1つの初期条件から単一のモデル実行を行うことを意味し、またはアンサンブルで実行することができます。これは初期条件を取得して、わずかに摂動させてから、将来に向かって実行することを意味します。
これが不確実性の計算に役立つんです。同じモデルを使って、わずかに異なる初期条件から始まる31種類の異なる予測スイートを見ると、将来の予測にどの程度のばらつきが生じる可能性があるかを示す指標が得られます。推論実行は16日先まで実行されます。物理ベースのモデルでこのような実行を行うには、約1時間半で25,000コアが必要になります。このモデルはH-100を少数個用意するだけで、7分で実行できます。これは本当にゲームチェンジャーです。
グローバルアンサンブル予測も非常に似た性質を持っており、これらをリアルタイムで運用的に実行することにもう間もなく成功しそうです。私たちはそれについて非常に興奮しており、このミッションに乗り出しています。しかし、AI の観点から物理ベースのモデルと比較すると、注意が必要な点があります。明日、観測値から直接 AI モデルに一気に切り替えるのでしょうか？いいえ、少なくとも今のところは相互依存関係があります。物理ベースのモデルを使って AI モデルを訓練する必要があり、これらは統計ベースのモデルであり、その後、推論の観点から本当に素早く実行できます。
私たちが話しているモデル実行は、物理ベースのモデルと非常に似たパフォーマンスレベルで実行されていますが、これらは物理ベースのモデルから訓練されているということを念頭に置いてください。つまり、これは私たちが持っている相互依存関係です。AI ベースのモデルを訓練するために、物理ベースのモデルで再解析または大規模な訓練データセットを実行するために、依然として大きなリソースが必要ですが、これは興味深い文脈です。運用の観点から、物理ベースのモデルを定期的に実行するために必要な計算容量の量を見ました。今、推論実行が1時間半対7分で実行されることを考えてみてください。これは、高性能コンピューティングについてどのように考えるかの性質を本当に変えます。そして、その規模での推論実行でさえ、それらが本当に真の HPC なのかどうかという疑問を生じさせます。私たちはそれを理解しようとしています。
私たちが理解しようとしている別の興味深い側面は、そのデータを公開に移動することの影響です。データ移動のタイプについて、すぐに統計情報を提供します。物理ベースのモデルで1.5時間の期間にわたって大量のデータを出力することから、同じ量のデータを7分で出力することに移行しています。顧客の観点からすると、彼らはすべてそのデータが出ていて利用可能であることを期待しています。今、データストリーミングの問題があり、多くの顧客が同じ正確なデータを同時に探しており、すべてが7分の期間に圧縮されています。データ配布の観点からすると、これについて考えるのは本当に楽しくありません。
もう一つの側面は、これらのモデルの進歩を見ることです。進歩という点では本当に速いペースですが、もう一つの問題は、データの完全性と科学的完全性が非常に重要であるということです。モデルを実装する前に、大規模な検証プロセスを経る必要があります。異なる季節でこれらがどのように機能するかを理解するために、遡及的に見直したいと思います。例えば、ハリケーンモデルを更新している場合、それが検証されていることを確認するために、90～100の異なるストームでそれを実行したいかもしれません。対流圏または中緯度を改善している場合、熱帯地域に影響を与えていないことを確認する必要があります。これはハリケーン実行のパフォーマンスなどに影響を与えるでしょう。
このペースでの進歩とモデルの改善には、モデルの検証にさらに多くの自動化と洞察を加えることに真摯に取り組む必要があり、科学的な完全性を確保する必要があります。これは私たちにとって課題です。
データの配信について最後に説明させてください。私たちは1日あたり約12～15テラバイトのデータを生成し、それを一般に公開しています。1日あたり約300テラバイトを配信しており、つまり1ヶ月あたり約10～11ペタバイトのデータをストリーミング配信しています。これらのモデル実装がより高い解像度に達するにつれて、配信量は一定ではありません。その成長に対しても計画を立てる必要があります。
そのデータ配信の約50パーセントをコンテンツデリバリーサービスにオフロードしており、残りの約50パーセントはオンプレミスのシステムからウェブサービスまたはAPI ベースの観点でストリーミング配信しています。私たちのサービスには1日あたり10億を超えるヒットがあります。そのうち約80パーセントはコンテンツデリバリーサービスを通じてオフロードしています。しかし、私たちの負荷は、気象イベント、ハリケーンイベント、吹雪、津波イベントなど、進行中の状況に基づいて変わります。
これは最近経験した津波のケースの例で、ロシア沖で地震が発生し、盆地全体に津波に関する多くの警告と注意報が生成されました。通常、私たちの津波に関するウェブサービスには1日あたり約250万ヒットがあります。12時間で、それが約10億ヒットまで急増しました。これは、これらのイベントを通じて対応する準備ができていなければならない方法の良い例です。
NOAAのクラウドHPC戦略：HPC as a Serviceによる研究から運用への加速
それでは、Rayette にバトンを渡して、クラウドに関するより実践的で技術的な側面について説明します。私の名前は Rayette Toles-Abdullah です。2020年4月から NOAA の solution architect としてサポートを開始しました。NOAA のような素晴らしいミッションをサポートし、生命と財産を守るのに役立つ人になれることに興奮していました。確かに私はそれを真摯に受け止めており、AWS に所属する NOAA の従業員です。
NOAAのHPCへの取り組みについて説明するために、私たちは2020年初頭から2020年後半にかけて、オンプレミスで実行しているモデルの一部をクラウドでベンチマークすることを検討し始めました。概念実証を検討し始め、実際にMPIアプリケーションを移植しました。これが完了するまでに最も時間がかかった部分でした。GFSやGEFSなどのモデルのベンチマークが完了し、これらのモデルがクラウドでどのように実行されるかについて必要なメトリクスと厳密な情報を得た後、私たちはAWSパートナーと話し合い始めました。これらのパートナーは私たちの力を増幅させるもので、NOAAの科学者と研究者向けのサービスを拡大するのに役立ちました。
私たちは途中で学習曲線を平坦化しました。クラウドでHPCを行っている科学者や研究者の中には、ブラックボックスのような部分があるので、私たちはenablementセッションを設定して、これがクラウドでどのように機能し、どのように見えるかを誰もが理解できるようにしました。クラウドではいじるノブが少なくなっています。これはオンプレミスで行うことができたものですが、不要であることもわかりました。私たちはHPC専門家と協力して、これを有効にするのに役立ちました。Aaron Boucherという、実際にこれを有効にするのに役立ったHPC専門家に対して、恥ずかしげもなくプラグを挿したいと思います。
NOAAには、クラウド上のNOAAで今日見られるHPCの観点から有効にするのに役立ったスペシャリストがいます。NOAAがクラウド上のAWS上で科学者と研究者に提供している2つのサービスがあります。彼らは自分たちで自己管理型HPCクラスターを実行し、クラスターを構築し、それらのクラスターを相互接続し、オンプレミスで行うようにヘッドノードとコンピュートノードを持つことができます。または、利用可能なHPC as a Serviceサービスを活用することができます。
その場合、私たちはParallel WorksおよびGDITと提携し、GDITがプライムとして、科学者がジョブを実行するための統一された簡潔なインターフェースを提供しました。どちらの方法でも、アーキテクチャは同じに見えます。NOAAは目的別に構築されたHPC EC2インスタンスで標準化しました。これらはSupercompute 2025で導入されたHPC7aインスタンスであり、HPC8aインスタンスは2026年にリリースされます。彼らはこれらのインスタンスで標準化しています。これらはオンプレミスと同様に密結合されたクラスターです。Cluster placement groupsを使用して、これらのクラスターがAWS内で互いに近い位置にあるようにすることができます。
彼らは Elastic Fabric Adapter を標準化して使用しており、これによってクラスタノード間でサブマイクロ秒レベルの接続性が得られます。これはオンプレミスで見られるのと同じです。彼らは FSx for Lustre をファイルシステムとして標準化して使用しており、これによってストレージシステムで高いスループットが得られます。これと同じくらい重要なのは、Amazon S3 とネイティブに統合してデータをインポート・エクスポートできる機能です。つまり、クラウド内でそのような高価なストレージを常に継続的に保持する必要がないということです。モデルが出力したデータをエクスポートして、そのデータに対してポストプロセッシングを行ったり、S3 からそのデータを使って将来の分析を行ったりできます。永続的な FSx for Lustre ストレージを持つ代わりに、より安価なオブジェクトストレージを使用できるわけです。
実行が終わったら、このクラスタは基本的に終了され、次に実行する必要があるジョブに進みます。オンプレミスのワークフロー機能の一部は存在しています。彼らは依然として PBS をジョブ管理に使用しています。SLURM を使用することもできますし、AWS Step Functions と Lambda 関数を使ってワークフロー管理を処理することもできます。ただし、彼らはオンプレミスで現在使用しているツールの一部をワークフロー管理とジョブ管理に使い続けることを好む傾向があります。
HPC as a Service オファリングについて説明します。これは NOAA の科学者と研究者が研究から運用への加速を実現するために重要でした。彼らは簡潔なウェブポータルを持っています。ウェブポータルにアクセスして、必要なコア数、必要なメモリ量、必要な EC2 インスタンスタイプ、必要なストレージのタイプを選択して、ジョブを実行するだけです。これが行うことは、科学者と研究者をクラスタの設定、ネットワークの構築方法、バックエンドの設定をどのように調整するかについての心配から解放することです。
基本的に彼らが選択したものからインフラストラクチャアズコードを使用して、ジョブを実行するための完全なクラスタがデプロイされます。これらのジョブは、例えば Hurricane Analysis and Forecasting System について説明したときに述べたような、実際のパフォーマンス機能で実行されます。このオファリングが登場したことで、私がこれからお話しする収束を見ることができた時期がありました。科学者たちが来て、今すぐ HPC クラスタが必要だ、オンプレミスのキューを待つことはできないと言うようになったのです。
彼らは R&D をやりたくて仕方がないんです。なぜなら今すぐそれを終わらせたいからです。私たちは XYZ 年またはその月までに運用開始を目指しており、このような容量と機能を持つことができたというのは NOAA にとって大きな成功でした。この観点からお話しできるユースケースが何つかあります。 最大のものであり、David が先ほど話していたのと同じものが Hurricane Analysis and Forecasting System、つまり HAFS です。私たちはこれを AWS でハリケーンシーズン中にリアルタイムで数年間実行してきました。21 メンバーのアンサンブルが 1 日に 2 回実行されます。そのデータの出力は Amazon S3 にエクスポートされ、科学者たちと共有されるので、彼らはそのデータを見て、どこに改善が必要かを確認することができます。これにより、彼らはオンプレミスで実行できるようになるのを待つことなく、または必要な分析を実行した後に待つことなく、問題を解決し、さらには時間をかけてモデルを改善することができます。
当時、私たちは 399 個の HPC6a.48xlarge Amazon Elastic Compute Cloud、つまり EC2 インスタンスを実行していました。1 日に 2 回のラボ結果とラボ実行を行っていました。これは、彼らがテストベッドを行い、モデルから出てくるデータをリアルタイムで分析しようとしていた時に有益でした。もう 1 つの素晴らしいケーススタディが出てきました。それは RFUS、つまり Rapid Refresh Forecast System と呼ばれるものです。 私の理解では、RFUS は 2026 年に運用開始予定です。彼らがそれを実現できた理由の 1 つは、AWS を活用してモデルを実行できたからです。これもモデルアンサンブル実行で、彼らは 1 日中一貫して実行していました。彼らは Lustre ファイルシステムを標準化し、高いスループットを実現しました。彼らは目的別に構築された HPC インスタンスを標準化し、また、これらのモデルからのデータを AWS Open Data にエクスポートして、モデルがどのように実行されるか、そしてどのように調整できるかについてのさらなる分析と理解を活用することができました。
AI天気予報の民主化とHPC・AI融合の未来：500億ドルの投資が切り拓く新時代
彼らはまた、オンプレミスよりも 15% 高速に実行されることを発見しました。また、コスト性能の観点からは 25% 優れていました。 しかし、先ほど言ったように、収束がありました。私たちは HPC as a service オファリングで数年間取り組み、その後、興味深いことを発見しました。科学者と研究者たちは Jupyter notebooks へのアクセスを望んでいました。彼らは AI/ML サービスへのアクセスを望んでいました。また、これらのモデルから出力される大規模なデータセットを分析する機能を持つ必要がありました。私たちは、大規模な密結合 HPC クラスターの使用から、このオファリング内の AI/ML サービスへの収束を見てきました。私たちがそれを実現している間、私たちは理由を尋ねていました。そして David が先ほど説明しました。私たちは最初はなぜかわかりませんでしたが、後で理解しました。 私たちは AI 天気予報への収束が来ているのを見ていました。David が先ほど従来の数値天気予報モデルについて話しました。これらは物理ベースです。センサー、ブイ、衛星からのデータを取得し、その観測データを取得して、オンプレミスのスーパーコンピューターでそれらの計算を実行して、分析、予報、および再分析を取得します。ただし、AI 天気予報では、少し異なります。数値天気データ出力を使用したデータのトレーニングがあり、その後、そのトレーニングデータで推論が行われるという意味です。
私にとって驚くべきことは、SageMaker Jupyter notebook から、数時間ではなく数分で、科学者と研究者が天気予報を行うことができるということです。彼らは必要な出力とデータを取得します。これは天気予報を民主化します。David が先ほど話した課題があり、今はより多くのデータが入ってきています。これは良い問題だと思いますが、この収束が問題を解決し、AI 天気予報で他の科学的進歩を推進するのにどのように役立つかも見ることができます。
これは私がここで使用している、またはこのスライドで示している単一の GPU インスタンスです。密結合された大規模な HPC クラスターの代わりに。 David は NOAA が取り組んでいる利用可能なモデルについて話しました。他にもモデルがあります。FourCastNetv2、Pangu-Weather、GraphCast、Aurora です。これらはすべて AWS で単一の GPU で実行することができます。または、David が先ほど話していたようなアンサンブルがある場合、本質的には複数の GPU を見ることになります。しかし、ここでの考え方は、Jupyter notebook から、数時間ではなく数分で AI 天気予報を実行できるということです。
それを証明するために、証拠は結果に表れるということですね。私は科学者ではなく、テクノロジストなので。FourCastNetv2 という小規模な AI モデルを実行することができました。ここに見えるのは Hurricane Helene がフロリダを通ってノースカロライナに入ってくる様子です。ここに私の名前が見えますね。これは私が見つけたオープンソースコードに基づいて実行している私のノートブックです。つまり、テクノロジストである私自身でも、こうした実行ができるということです。研究者や科学者たちが、クラウドで利用可能な必要な容量とコンピュート選択肢を使って、自由にこうした予測を実行できる能力を持つことを想像してみてください。
では、Vicky が HPC と AI の未来についてお話しします。ありがとう、Rayat。皆さんは National Oceanic and Atmospheric Administration の同僚から素晴らしいケーススタディを聞きました。スーパーコンピューティングを使ってミッション課題を解決し、適切なミッション成果を達成する素晴らしい事例がありました。そして Rayat から、AWS がそのインフラストラクチャにどのように電力を供給し、National Oceanic and Atmospheric Administration をサポートしているかについて聞きました。
では、HPC と AI の未来はどのようなものでしょうか。AWS では、それは明るいと考えています。約1週間前、私たちは米国政府向けの新しい AI とスーパーコンピュータセンターを構築するために、500億ドルのインフラストラクチャ投資を発表しました。この500億ドルの投資は、1.3 ギガワットのコンピュート容量に相当し、U.S. gov cloud のワークロード、秘密領域、極秘領域を含む様々な政府機関のミッション、および全てのデータ分類に対応します。
この投資は、National Oceanic and Atmospheric Administration のような顧客や、その他多くの機関から見られている実世界のイノベーションに基づいています。イノベーションを促進するために、これらの例のいくつかを皆さんにご紹介したいと思います。まず、S2 Labs というパートナーがいます。彼らは subsurface mapping を行っています。Subsurface mapping とは何でしょうか。基本的には、掘削を行わずに、地下の構造物が何であるかを把握しようとすることです。
それはインフラ、ケーブル、パイプライン、または建設材料かもしれませんが、特に掘削ができない場合に、地下に何があるのかを特定する必要があります。2004年、Hurricane Ivan がオフショアの石油掘削装置を破壊し、すべての重要なインフラが海に落ち、数メートルの堆積物の下に埋もれました。それは有害廃棄物でもあったため、従来の音響方法を使った18年間の試行錯誤を経ても、そのインフラがどこに埋もれているのかを特定することはできませんでした。しかし S2 Labs が deep learning と applied physics を使用し、スーパーコンピューティンググレードの API と共に推論を適用するまで、成功することはありませんでした。彼らはそれを前例のない明確さで実現することができました。それほどまでに、彼らは実際に400メートル × 400メートル × 60メートルのエリアを5秒以内にマップできるワークフローを開発しました。これは29.5個のフットボールフィールドです。ここでの重要なイノベーションは、これが多くの異なる業界に適用可能であるということです。石油とガス、エネルギー、ユーティリティ、都市開発、建設安全、その他多くの業界です。これは、HPC と AI の融合と、それがもたらす成果を見ている素晴らしい例です。
もう一つ例を見てみましょう。複数の専門家チームが一堂に集まって協力し、何らかの分析を提供する必要がある意思決定を行う際に、課題に直面したことがある方も多いと思います。これはエンジニアリング分野、科学分野、さらには金融サービス分野でもよく起こります。例えば、ローンを承認する場合などです。Senera という process automation 企業のパートナーがいます。彼らはエンジニアリング分野で、多くの他のコンポーネントで構成されているエンジニアリング部品の見積もり依頼を提供する必要があるドメインに取り組みました。これらのコンポーネントはそれぞれ組み立てられる必要があり、監視される必要があり、異なるエンジニアリング専門家によって情報が提供される必要があります。すべての情報を統合する必要があり、彼らはそれをモデル化し、HPC performance-grade APIs と AI/ML を使用してそのための解決策を作成しようとしました。
彼らは Amazon Bedrock、NVIDIA 上で実行されている EC2 インスタンス、および追加の AI/ML ベースの inferencing に基づいてソリューションを開発しました。彼らが行ったことは、複数の異なる専門家からの複雑なエンジニアリング部品のアセンブリを取得し、彼らの専門知識をすべて活用して、この情報を収集し、それを通じて推論し、結果を提供する multi-agent AI システムを実行することでした。彼らは時間を 3 週間から数分に短縮しました。繰り返しになりますが、これは HPC スーパーコンピューティングをパートナーと一緒に適用して非常に複雑な問題を解決する方法の素晴らしい例です。これら 2 つの例は氷山の一角に過ぎません。HPC と AI/ML のこの融合で可能な革新の領域は多くあり、特に米国政府向けに行っている投資を考えると、これは将来さらに高度になると確実に言えます。
簡単に要点をまとめます。HPC と AI/ML のクラウドでの融合について話すことから始めました。2023 年には、HPC の市場規模は約 370 億ドルでした。これは 2024 年に 24 パーセントの成長で急速に進んでいるのが見られ、その後 2029 年までに、アナリストは融合市場が約 490 億ドルになると言っています。その後 David が登壇して NOAA のミッションについて話しました。予測だけではないことを忘れないでください。彼らは非常に重要な多くの他のことを行っています。そして Rayat が登壇して、NOAA のミッションをサポートしているインフラストラクチャ、コンピュート、キャパシティ、およびアーキテクチャについて話しました。楽しんでいただけたと思います。お時間をいただきありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion