re:Invent 2024: AWSがエネルギー企業とHPC高速化で協業 - Energy HPC Orchestrator
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - An open collaboration for HPC acceleration (ENU305)
この動画では、AWSのEnergy and Utilities Business UnitのCTOであるHussein Shelが、High Performance Computing（HPC）の現代化に向けた取り組みを紹介しています。ShellやOccidentalなどのエネルギー企業と共同で開発したEnergy HPC Orchestratorは、地震探査やReservoir Simulationなどの地下探査ワークロードを、ローコードでオーケストレーションできるアプリケーションです。NVIDIAとの連携によりGPUの活用も進め、Full Waveform InversionやReverse Time Migrationなどの計算負荷の高いアルゴリズムを効率的に実行。数テラバイト規模のデータを扱う大規模な処理を、Serverlessアーキテクチャで実現し、Gen AIやMachine Learningの統合も視野に入れた次世代のHPCプラットフォームとなっています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Energy HPC Orchestratorプロジェクトの概要と目的
皆様、お集まりいただきありがとうございます。カンファレンスの後半のセッションにお時間を取っていただき、感謝申し上げます。私はHussein Shelと申しまして、AWSのEnergy and Utilities Business UnitのCTOを務めております。 本日は、非常に興味深いメンバーの方々にご参加いただいております。OccidentalのKlaas氏、NVIDIAのMarc氏、そしてS-CubeのNikhil氏など、私たちのテクノロジーパートナーの皆様をお迎えし、High Performance Computing（HPC）の現代化に向けた革新的な取り組みについてお話しさせていただきます。
アジェンダと、このコラボレーションがどのように始まったかについてご説明させていただきます。 私たちが直面している課題、この製品に込めた技術とビジョン、そして現在の進捗状況についてお話しします。また、このコラボレーションの一環として構築したアーキテクチャ、設計、そして具体的なAWSサービスについてご説明し、その後デモンストレーションを行います。私が10～15分ほどお話しした後、他のメンバーの方々にもステージに上がっていただき、用意した質問について討議を行います。その後、会場の皆様からのQ&Aの時間を設けております。
クラウドベースHPCの課題と解決策
では、どのように始まったのかについてお話しします。 これは、ShellやOccidentalなどのエネルギー企業とともに行った、AWSにおけるHPCワークロード、特にオイル＆ガスや地下探査分野における参入障壁を取り除くための共同検討から始まりました。つまり、社内だけでなく、他の企業やソリューションプロバイダー、ISV、そして学術機関との協力の仕方を変え、Seismic ImagingやReservoir Simulationなどの地下探査ワークロードに関する最新のHPC技術を活用する方法を模索したのです。そしてもちろん、至る所で話題になっているAIについても、ワークフローの一部として組み込み、お客様やエンジニアの方々が簡単に実験できるようにすることを目指しました。
これが、このコラボレーションの出発点でした。最初は、Amazonでよく行われているように、数人で集まってPR FAQを書くところから始まりました。そのアイデアは製品となり、現在では多くの事業者やお客様によってテストや評価が行われており、多数のパートナーやソリューションプロバイダーとの統合も実現しています。 ご存知の通り、HPCの要件はオンプレミスで利用可能な能力を超えて増加し続けています。クラウドは、バースト的な処理能力の確保だけでなく、イノベーションや物事を異なる視点で見直す機会を提供します。アルゴリズムの精度や解像度の向上、そしてデータサイズやデータセットの増大に伴い、これらの大規模な一枚岩的なワークロードの移行の複雑さも増しています。
多くのお客様は何十年もかけてこれらの作業を行ってきており、実際にビジネス上の課題を解決するため、自社のハードウェア、ソフトウェア、ネットワーク、環境に特化したワークフローを完成させてきました。私たちは、お客様がハイブリッド環境を活用し、既存の取り組みを継続的に発展させながら、さらにその先へスケールアップし、最新技術を活用して、クラウドネイティブの観点からHPCへのアプローチを考えられるよう、クラウドでの再構築をサポートしたいと考えました。 大まかなビジョンとして、Energy HPC Orchestratorは、お客様が異なるコンポーネントをドラッグ＆ドロップすることで、ローコードおよびノーコードのHPCワークフローを構築できるアプリケーションです。お客様独自のカスタムビルドアルゴリズムから、サードパーティのアプリケーション、そして市場や学術機関、新しいパートナーから生まれる新しいアイデアまで、さまざまな要素を組み合わせて、完全なアプリケーションチェーンとワークフローを構築することができます。そして重要な点として、どのようなインフラストラクチャで実行するかを指定することができます。
HPCワークフローにおいて、適切なアプリケーション、インフラストラクチャ、そしてハードウェアを適切なアプリケーションに対してターゲットにできることが重要です。つまり、アルゴリズムの中にはGPUやCPUベースの特定のハードウェアに最適化されているものがありますが、ワークフロー自体は多くの異なるタスクで構成されているということです。お客様は、最適なものを選択し、さらに実験やベンチマークを行う柔軟性を持っています。私たちはそれを迅速に実行できますし、デモではServerlessテクノロジーを使用して、舞台裏でどのようにオーケストレーションが行われているかをご覧いただけます。
市場に出てくるSDKや開発キットとの統合も実現したいと考えていました。そのため、NVIDIAとのパートナーシップは非常に重要です。特にMachine Learning側のアルゴリズムの多くは、パフォーマンスとコストの面でGPU消費に最適化されているためです。これは、お客様が独自のアルゴリズムを構築し、R&Dの観点から、他の形式のハードウェアやイノベーションを使用する本番ワークフローに素早く統合できるようにするための重要な基本要素となっています。
Energy HPC Orchestratorのアーキテクチャと機能
それでは、ソリューションの各部分について少し詳しく説明させていただきます。UIは、フロントで構築をデプロイできる一般的なWebインターフェースで構成されています。異なるリージョンや異なるユーザーによってデプロイされる可能性があるため、静的コンテンツと効率性のためにCloud Frontを利用しています。そして、すべてはCognitoを通じてセキュリティを確保しながら、始めから終わりまで、API Gatewayを通じてシステムのさまざまなコンポーネントがオーケストレーターコアでオーケストレーションされます。メタデータやデータ転送の要件、ストレージの管理にはNoSQLが使用されています。
コアに入ると、次に実行されるワークフローのさまざまな部分をすべて分離できる、本格的なServerlessアーキテクチャになっています。右端に表示されている拡張機能は、パートナーやお客様が開発している秘伝のソースやアルゴリズムを含む重要な部分で、これらはビジネスの収益に大きな影響を与えます。これは彼らが何億ドルもかけて開発した知的財産であり、それを正しく活用し、より大きな全体像の一部として活用することが非常に重要です。
では、私たちが始めた例の一つを見てみましょう。これは実際に最大の実装の一つであり、お客様が一般的に使用するアルゴリズムの一つです - 地震探査のためのReverse Time Migrationとイメージングアルゴリズムです。RTMとFull Wave Inversionは、地下の画像や3Dモデルを見つけ理解するために、24時間365日稼働している最も重い、典型的な分散ワークロードです。このソリューションは、ユーザーからの情報とワークフローの各ステップへの入力を受け取り、ワークフローを特定のコンポーネントとマイクロサービスに分解し、それぞれが独自の入出力の境界内で耐障害性を持って実行されます。
このワークフローは、Lambda サービスを通じて全体が統制され、各イベントベースのタスクのチェックポイントを可能にするキューイングシステムを使用しています。従来は密接に結合していた部分を完全に分離し、画面に表示されているこれらの Microservice 間で必要な情報を取得し、移動できるようにしました。Microservice 間でのデータの移動は多いものの、各 Microservice 内でのデータ移動はできるだけ最小限に抑えるよう努めています。SQS は単にイベントの次のフェーズへの移行を管理・統制するために使用され、複雑なモノリシックな分散バッチ実行から、サーバーレスのイベントベースの実行へとワークフローを移行しています。
パートナー、オペレーター、お客様と協力して、私たちは様々なタスクやエクステンションの入出力を標準化し、誰もが同じように使えるようにしました。というのも、私たちとオペレーターが気付いたのは、ワークフローの大部分は顧客間やユーザー間で非常に似通っているということです。70〜80%は基本的に同じタスクの繰り返しなのです。最後の部分に少し違いがあり、そこで柔軟な統合が可能になっています。
もう一つの例として、Parallel Cluster サービスとの統合についての小さな例をご紹介します。 これは、私たちが実験している密結合ワークロードの観点からのものです。オーケストレーターは、従来型の HPC ベースの異なるアプリケーション間の統合を容易にします。ここで構築できる他のワークフローについて考えてみましょう。例えば、計算流体力学や、石油・ガス以外の HPC アプリケーションなどです。このフレームワークとソリューションを使用して他のアプリケーションを構築できるというのが私たちのビジョンであり、考えです。なぜなら、各要素を分離し、単に入力と出力を接続するだけだからです。
パネルディスカッション：業界リーダーの視点
ここで、スピーカーとパネリストの方々にステージに上がっていただきたいと思います。残念ながら、Shell の Francesco Menapace は急な用事で参加できなくなりましたが、Klaas Koster と Marc Spieler をお迎えしたいと思います。ステージにお上がりいただき、いくつか質問させていただいた後、会場からの質問を受け付けたいと思います。ありがとうございます。はい、ご参加ありがとうございます。照明が少し厳しいですが、Klaas さん、このソリューションのメリットについて、そして Occidental がなぜこのようなプロジェクトに関わっているのか、またイノベーションにどのように役立つのかについてお話しいただけますでしょうか。
私たちにとって、この journey は外部からスタートしました。本日参加できなかった Shell の同僚たちが持っている素晴らしい社内 HPC 能力を、私たちはいつも羨ましく思っていました。しかし、HPC を始めるには膨大な投資が必要です。機器を購入し、その機器を使いこなせるエンジニアを確保し、その機器を最大限活用するソフトウェアを開発する必要があります。通常、何年もの投資と数千万ドルの費用がかかります。Shell や Chevron、BP などの大手オペレーターにとってはそれでも問題ありませんが、私たちにとってはそれは実現不可能でした。
AWSのようなクラウドプロバイダーが提供する素晴らしい機会により、必要な時だけCPUに対して課金され、この種の計算タスクを実行するという全く新しい考え方が可能になり、私たちは地震イメージング分野に参入することができました。すべてを自分たちで書くという選択肢もありましたが、AWSもまたこの分野に興味を持っていました。あなたが導入部分で既に言及したように、実際の作業の多くは秘伝のタレではなく、いわば切手収集のようなものです。IO、データベース、ワークフローなどは自由に共有され、誰も特に競争上の優位性とは考えていません。そこで私たちは、後ほど詳しく説明する様々な良い理由から、誰もが利用できる共通基盤として、この種の計算作業を行うフレームワークを構築できないかという話を始めました。そして、あなた方がそれに興味を持ち、私たちのためにそのような機能を構築してくれました。その後、私たちの同僚の何人かが、私たちも独自に開発した中核となる秘伝のソースコードを必要としていました。そして今、私たちは本当にクラウドでこのような大規模なHPC計算タスクを実行することの利点を実感し始めています。
ご存知ない方のために説明しますと、私たちは数テラバイトの入力データを扱っており、かなり大規模なデータサイズの計算を行っています。
では、NVIDIAのMarcに話を移しましょう。この協力関係の一員となり、Shellとの統合に関する私たちの取り組みについて、どのように感じていますか？特にGen AIや大規模言語モデルの実装の可能性も含めて、今後のお客様にとってどのようなメリットがあるとお考えですか？ご招待ありがとうございます。まず、これまでの会議は非常に刺激的で、AWSが提供する多くの機能について目を開かせていただきました。このイニシアチブは、プラットフォーム企業である私たちにとって特に興味深いものです。なぜなら、ワークロードの異なる部分が異なるスピードで発展していくからです。エコシステムの構築に重点を置く企業として、エネルギー分野のエコシステムは非常に広範で、多くの人々が異なる分野を専門としています。
Klaasが指摘したように、このソリューションスタックは企業が最高の技術を選択し、差別化できる部分で差別化を図ることを可能にします。エネルギー企業が活動する特定の分野に特化してカスタマイズされた新しいワークロードを作成できる能力は非常に重要です。私たちの業界は一つのサイズですべてに対応できるわけではありません。地下環境は、世界のどの地域で作業するか、あるいはどの地域で作業したいかによって大きく異なり、異なるツールには異なる機能があります。
スーパーメジャーにとっては、彼らのニーズに非常に適した技術を開発してきました。指摘されたように、これはすべての企業が可能というわけではありません。大手ISVやソフトウェアプロバイダーは非常に堅牢なソリューションを構築していますが、それらすべての顧客とすべての領域に適したものにする必要があります。そして、小規模なISVは参入して、特定のニーズを持つ1つの顧客を見つけ、その顧客に特化したサービスを提供する傾向がありますが、より広い範囲に展開することはできません。このプラットフォームにより、これらのISV、大手ISV、独立系事業者、さらにはスーパーメジャーでさえも、世界中の異なる地層における個別のワークフローの構築とカスタマイズを本当に始めることができると思います。
そして最終的に、これがどのようにさまざまなHPCやAIのワークロードと結びつくのでしょうか？地下探査に限らずですね。地下探査を選んだ理由は、企業にとって大きなコストがかかるからです。石油・ガス業界のエネルギー企業であれば、おそらく最も高額なHPCワークロードの一つでしょう。しかし、これ以外にもさらに多くの用途があると考えています。業界が長年話し合ってきたものの実現できていなかった、最高のアルゴリズムを選んでワークフローにまとめるということが、これによって可能になるのです。
では、テクノロジープロバイダーの一社として、この分野での取り組みや、私たちがGravitonやカスタムシリコンをどのように活用しているかについてお話しいただけますか。まず、このように一方にテクノロジー大手、もう一方にエネルギー大手を迎えて、ここにいられることを光栄に思います。両社のお話は、私たちのビジョン、つまり自社の専門分野で最高の技術を提供するという目標と一致しています。私たちが専門とするFWI（Full Waveform Inversion）というアルゴリズムは、デモでもご覧いただけますが、地下構造イメージングのデファクトスタンダードとなっています。そのため、当社には大きな成長の機会があります。
エネルギー業界は自社データでの結果を確認したがります。他の顧客のケーススタディを公開することで商談のきっかけにはなりますが、彼らは実際にパイロットを実施したいと考えています。Energy HPC Orchestratorを使用することで、これらのパイロットを非常に効率的に実行し、パイロットから実際の商用ライセンスへと転換することができます。右にいらっしゃるKlaasとは、すでにそれを実現できています。Klaas、Orchestratorでの経験や、これまでの取り組み、結果や機能についてお話しいただけますか？うまく機能していますか？役立っていますか？はい、確かに機能しています。まだ始まったばかりではありますが。
コンセプトの議論から実際の稼働まで時間はかかりましたが、現在はS-Cubeの独自のイメージングアルゴリズムが統合され、NVIDIA Energy SDKにもいくつかの実装があります。私たちも自社のイメージングコードを移植し、Marcが言うように、プロジェクトごとに異なるベストインクラスのソリューションを選択できるようになりました。あるプロジェクトではコスト効率を重視し、別のプロジェクトではスピードを優先するなど、目的に応じて異なるソリューションを適用できるようになっています。
ここで一旦、私たちが話している内容を実際にご覧いただくためにデモをお見せしましょう。Nickにワークフローと結果について説明してもらい、その後いくつか質問をしてから、フロアを開放したいと思います。 ここでご覧いただいているのは、特定の地震波イメージングワークフローの画面録画です。プロジェクトの作成から始まり、名前や予算を設定し、次に進んでいきます。 これが適用される処理シーケンスです。地下構造をイメージングする際、地下には異なる属性があります。 一つは速度と呼ばれ、もう一つは反射率と呼ばれます。反射率を正確に得るためには、高品質で正確な速度モデルが必要不可欠です。
そのため、ここでは異なるブロックが表示されています。左側には、速度モデルを生成するアルゴリズムであるXWIが表示されています。右側には、RTM（Reverse Time Migration）が表示されており、これは反射率を生成します。現在画面に表示されているのは、パラメータがロードされている様子です。これらのアルゴリズムには全て、出力と収束の成功を決定する入力パラメータがあります。これは全て自動的に制御されており、イメージングされるデータに応じてパラメータが設定され、速度モデルから反射率への矢印が表示されています。
別のRTMアルゴリズムを試してみたい場合もあるでしょう。FWIの部分が最も計算負荷の高い処理です。速度モデルが得られた後、反射率を生成するために異なるRTMアルゴリズムを試してみたいかもしれません。ここで見ているのは、RTMの入力設定の方法です。これは私たちがEnergy HPC Orchestratorの開発初期に作成したワークフローですが、それ以降、大きく進化しています。地震波イメージングの開発ペースは非常に速いのです。ここで見ているのは、ジョブの初期化の様子です。つまり、パラメータが設定され、ジョブが投入され、起動されている状態です。FWIは特に計算負荷の高いアルゴリズムなので、ショットは多数のコアに分散され、速度モデルが生成されることになります。
実際の地震波イメージングシーケンスは、もっと複雑です。これは単にインバージョンシーケンスの基本を示すデモに過ぎません。最高品質の結果を得るためには、Full Waveform Inversionアルゴリズムは、速度や反射率、その他の地下パラメータなど、さまざまな属性を生成します。このダイアグラムはもっと複雑になり得ます。これは本当に始まりに過ぎず、あるアルゴリズムが速度モデルを作成し、別のアルゴリズムが反射率を生成するという概念実証です。実際には、これらの属性を同時に生成する非常に複雑なインバージョンシーケンスを使用することで、地下の最も正確な最終結果が得られます。
重要な問題は、それが最も正確だとどうやって分かるのかということです。私たちは結果の品質を評価するための様々なメトリクスの作成に多大な努力を払ってきました。これこそが、オペレーターである私たちの顧客が必要としているものです。つまり、最終結果に対する確信を持つ必要があるのです。Energy HPC Orchestratorを通じて、これらの結果を示し、その品質を検証することができます。様々な収束メトリクスを全て可視化でき、異なる結果を比較して、どれがデータに最も適合しているかを確認することができます。
これは非常に計算負荷の高いプロセスで、局所最小値と呼ばれる問題に陥りやすいものです。これはアルゴリズムの核心部分に関わることですが、だからこそ誰もが簡単にはできないのです。私たちは、海洋環境や陸上環境など、様々な設定に対応する異なるコスト関数を作成し、局所最小値に捕らわれることなく回避することができます。これにより、開発のペースが大幅に向上しました。現在のインバージョンシーケンスを見ると、それがいかに複雑で、最終結果をどのように検証できるかが分かります。そして最終的には、掘削の判断につながります。結局のところ、最も重要なのは、私たちが生成した速度と反射率が、井戸が掘削されたときに得られる読み取り値とどのように比較されるかということなのです。
デモンストレーションとAI統合の可能性
私たちのパートナーシップは、このソリューションを非常に迅速に構築し、ご覧いただいているようなUI/UXエクスペリエンスを作り上げる上で、非常に重要で有益なものでした。私たちは、バックグラウンドでさらに多くのメトリクスやテレメトリを追加し続けています。表示されている各ボックスのコスト予測など、新しい機能が追加される予定です。要件の詳細な検討や顧客との協力を進めていく中で、より充実したソリューションをご覧いただけるようになります。彼らは私たちにとって素晴らしいパートナーであり、このオンボーディングプロセスにおいて彼らの顧客をサポートするGo-to-Marketパートナーとなっています。
ここで聴衆の皆様に注意していただきたいのですが、これはHPCについての講演ですが、今お見せしたデモにはHPCの要素は含まれていませんでした。ボックスが白から緑に変わるまでほんの数秒でしたが、これは単なるサンプルです。実際の数テラバイトのデータセットでこれを実行する場合、CPUで実行すると数百、場合によっては数千のEC2インスタンスを起動することになります。これは数時間、あるいは数日かかる可能性があります。NVIDIA GPUを計算に使用する場合でも、これは依然として大規模な計算タスクです。
Gen AIに関して言えば、まず、私たちが今回構築したものよりも、もっとモダンなインターフェースを作れることを期待しています。これは、キャンバス上にボックスを配置して相互に接続し、パラメータファイルに入力するという、私たちの業界が慣れ親しんできたワークフローの構築方法です。ユーザーをワークフローに導き、特定のモジュールの使用方法や実行順序についてアドバイスするチャットボットやGen AIを実装するのは非常に簡単でしょう。これを生成して、この上に組み込むことができます。現在、いくつかの興味深い研究が進められており、このモデルの導入に機械学習フェーズを組み合わせることで、毎回すべての方程式を計算する必要がなく、ショートカットできる可能性が検討されています。
ここで生成しているデータセットは、依然としてただのデータであり、解釈が必要です。MLによって強化された解釈ワークフローの例は多く存在し、それらを組み込むことができます。そのような処理の中には、複数のツールで同時に実行することで恩恵を受けるものもあるでしょう。これらのプロセスの多くは、小さなチャンクに分けて多数のマシンに簡単に分散させることができ、同様に最後にマージステップが必要になります。このインフラストラクチャの多くは、作業の異なるフェーズにも適用できます。
簡単に言えば、PDEを解くことに基づいたFWIアルゴリズムにニューラルネットワークを組み込むことで、データから最高の結果を得ることができます。これは、各イテレーションの観点から、私たちがすでに実験を行っている分野です。従来のFWIアルゴリズムがデータを処理する前に、どのようにデータを前処理するか、そしてもちろん、ニューラルネットワークを簡単にプラグインできることは非常に有利です。
それでは、インフラ面についてお話ししましょう。AWSが提供している独自のシリコンを活用したGravitonについて、そして異なるオプションの提供についてお話しいただけますか？そして、Markには、GPU側での取り組みについてもお話しいただきたいと思います。Gravitonに関しては、お客様主導で進められてきました。お客様がGraviton上でアルゴリズムをテストし、他のCPUとベンチマークを比較して性能上のメリットを確認できたことで、私たちも容易に適応することができました。また、完全にフォールトトレラントになるようにオーケストレーションにも取り組んできました。現在ではSpotインスタンスがFWIの標準となっており、これにより大幅なコスト削減が実現しています。
なぜこれが重要なのでしょうか？ジョブのコストという点で大きな違いをもたらすからです。しかし、結局のところ、お客様は井戸に何百万ドルもの投資をすることになります。最も重要なのは、より多くの実験やイノベーションが可能になることです。自動化された統計的ML手法を使用して調整できるパラメータが何百もあり、これまでは利用できなかったものです。現在では、予算内でこれらすべてを実行することができます。裏では、アルゴリズムパラメータの微調整が行われており、ハードウェアの発展のおかげで、これらすべてが非常にコスト効率よく実行できるようになりました。
Mark、あなたは多くの事業者やソリューションプロバイダー、そしてこの分野での技術やアルゴリズムを開発している方々と協力されていますね。エネルギー分野のHPCや貯留層シミュレーション、地震イメージングに関するNVIDIAの機能について、そしてこのような学習をどのように取り入れることができるかについて、何かコメントはありますか？まず、Gravitonは素晴らしいソリューションです。ご存知の通り、NVIDIAはARMに力を入れており、ARMのエネルギー効率は、このような高性能コンピューティングやAIによる環境への影響を削減する上で大きな効果があると考えています。以前から、お客様にはGraviton T4インスタンスを確認するようお勧めしてきました。これは主にゲーミング用途ですが、クラウドでは多くの人々がコスト効率の良さから、T4やその他のGPUを大規模に実行しています。そして、Grace HopperやまもなくリリースされるGrace Blackwellのように、ARMとGPUを組み合わせることは明らかに正しいソリューションです。
プラットフォームカンパニーとして、私たちはすべてがGPUに適しているわけではないことを認識しています。高度に並列化され、かなり高いパフォーマンスで処理できるもの - GPUは確かに高価です。私たちは、ドルあたりの最高のパフォーマンスとワットあたりの最高のパフォーマンスを達成することを確実にしたいと考えています。このツールに話を戻すと、時間とともに異なるワークフローやマイクロサービスが可能になるという点で素晴らしいと思います。NVIDIAがマイクロサービスを推進してきたように、NIMSは、AIだけでなくHPCにおいても、異なる領域で実行される様々なモデルが統合されていくと考えています。ワークフローの異なる部分を異なるアーキテクチャで実行する能力、つまりCPUで効率的に実行できるものはCPUで、GPUで効率的に実行できるものはGPUで実行し、理想的な世界では、この2つの間の高速インターコネクトにより、従来GPUへの移植が非常に困難だったアルゴリズムを活用できるようになります。
インターコネクトの遅延などの問題があるため、AWSがまもなく提供するGrace HopperとGrace Blackwellで大きな進展が見られています。私にとって、これはベスト・オブ・ブリードに結びつきます。オーケストレーターの全体的な話は、ベスト・オブ・ブリードです。特定のジョブに最適なアルゴリズムをどのように選択するか？最適なインフラをどのように選択するか？コストと時間をどのように最適化するか？私たちが行うあらゆる側面において -
ほとんどのエネルギー企業は上場企業です。株主に対する責任があり、適切なコストで大きな価値を生み出すことを目指しています。エネルギー企業は非常に大きな数字を扱うため、純利益だと思われがちですが、探査に必要な資金は膨大です。利益率の観点から見ると、より高い利益率が実証されている他の製品を販売したいと考えるかもしれません。世界は多くのエネルギーを必要としていますが、エネルギー自体よりもエネルギードリンクの方が利益率が高いかもしれません。これは、業界が誰にとっても手の届くエネルギーコストを維持する方法を常に模索していることを示しています。
石油とガスは長期的に存在し続けるでしょう。目標は、排出量を削減し、世界にエネルギーを供給しながら、代替手段を模索することです。私たちの地震イメージング・アルゴリズムは現在、地熱エネルギー、炭素貯留、リチウム探査にも活用されています。洋上風力発電所でも、やはり地震イメージングが必要です。会場にはCMGなどのReservoir関連企業もいらっしゃいます。焦点は、いかに環境に優しい方法で炭化水素を抽出するか、そしてCO2や排出物を安全かつ効果的に貯留し、何千年、何百万年先の結果をシミュレーションして地表に戻ってこないことを証明することです。これらは非常に複雑なHPCアルゴリズムであり、この環境でより速くイノベーションを実現できるようになります。
DGX CloudはAWSで利用可能になり、これはAWSインフラストラクチャー上にNVIDIA AIソフトウェアスタックを提供するためのAWSとのパートナーシップの形です。これにより、HPCではなく主にAI向けのアプライアンスのような利用が可能になります。パートナーシップを通じて、私たちの技術はエンドカスタマーやユーザーに届けられます。AWSを通じてDGXの機能をクラウドで提供する能力は、複雑なAIインフラストラクチャーの管理能力はないものの、クラウドでの利用を望むお客様にとって重要になるでしょう。次のデモでは、そのような統合をサービスとして提供するボックスも用意されることを期待しています。
皆様、ご来場いただき、ありがとうございました。アプリでこのセッションの評価をお願いします。また、次回さらに良いものにするためのフィードバックもお願いします。Vegasにお住まいの方以外の皆様、お気をつけてお帰りください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion