Denise Muyco、RAVELの共同創業者兼CEO – インタビューシリーズ

Denise MuycoはRAVELの共同創業者兼CEOであり、複雑なコンピューティング環境やAIインフラ向けのオーケストレーションソフトウェアの開発を率いています。エンジニアとしての訓練を受けた彼女は、電力インフラ、プロセス最適化、デジタルメディア、データセンター、バーチャルスタジオなど、幅広い分野でキャリアを積んできました。AIに注力する以前、バンクーバーの視覚効果業界向けに共有型の高性能コンピューティングインフラの開発に携わり、約30のスタジオがコンピューティング資源と安全な接続環境を利用できるようにしました。この経験を通じて、高価で制約のある資源を調整する彼女のアプローチが形づくられました。RAVELでは、システムエンジニアリングの視点から、ワークロードの配置、インフラの利用効率、相互運用性、そして分散型AI環境やAI主権をめぐる需要の高まりに取り組んでいます。

RAVELは、クラウド、オンプレミス、ハイブリッドの各インフラにまたがるコンピューティングおよびAIのワークロードを、組織が導入、管理、拡張できるよう支援するソフトウェアを開発しています。製品には、高性能な仮想ワークステーション向けのRAVEL Orchestrate、ワークロードの自動化と最適化を実現するRAVEL Orchestrate AI、ソフトウェアライセンスとテレメトリーを扱うBoostがあります。同社のツールはインフラ、アプリケーション、仮想化、セキュリティを連携させるとともに、一元管理と運用状況の可視化を提供します。RAVELは、データセンター、サービスプロバイダー、企業のITチーム、AI研究グループ、クリエイティブスタジオにサービスを提供しています。デジタルコンテンツ制作をルーツとする同社は、複雑な環境をシンプルにし、チームが利用可能なインフラをより効果的に活用できるよう支援することに注力しています。

エンジニアリング、メディアインフラ、分散コンピューティングが交差する分野で長年働いた後、RAVELを創業されました。最終的に起業を決意したきっかけは何だったのでしょうか。また、生成AIによってコンピューティング需要が大幅に高まるなか、RAVELのミッションはどのように変化してきましたか？

私はエンジニアとして訓練を受け、今日のAIブームが起こるずっと前から、電力、コンピューティング、インフラが交差する分野で働いてきました。キャリアの初期には原子力発電所でインターンをし、その後、メディアや視覚効果の分野で働くなかで、GPU、大規模なコンピューティング需要、物理インフラの制約に触れました。

約16年前、成長を続けるバンクーバーの視覚効果業界は、こうした制約に直面していました。高額なプロジェクト向けに、複雑さを増す映画やテレビ番組のコンテンツを処理（レンダリング）するには、膨大な量の高性能コンピューティング資源が必要でした。しかし、安全な環境で需要のピークに対応できるだけの専用インフラを構築する余裕があるスタジオはほとんどありませんでした。電力もまた制約となりつつありました。私たちは共有インフラを開発し、約30のスタジオが高性能コンピューティングと、安全で広帯域な接続環境を利用できるようにしました。

インフラの共有によって一つの問題は解決しましたが、別の問題が生じました。高価で制約のある資源を、複数の組織やワークロード間でどうすれば効率的に配分できるのか、という問題です。この経験が最終的に、インテリジェントなインフラ・オーケストレーションを実現するRAVELのアプローチにつながりました。

AIは、はるかに複雑で、投じられる資本もずっと大きいものの、根本的には同じ課題を大規模にしたものです。ワークロードやインフラは変化しましたが、高価で制約のある資源を効率よく連携させる必要性は、これまで以上に高まっています。

RAVELを創業する前、バンクーバーのスタジオ、撮影所、制作会社、視覚効果会社など約30社が、高性能コンピューティングインフラを共同で利用できるコンソーシアムの立ち上げに携わりました。この経験から、分散コンピューティングについてどのようなことを学びましたか。また、当時ハリウッドが直面していたレンダリングの課題と、今日のAI業界が抱えるインフラの課題には、どのような共通点があるとお考えですか？

視覚効果業界での仕事を通じて、インフラの構築と構成は問題の半分にすぎないと学びました。高価なコンピューティング資源を安全に共有し、効率的に利用する必要がある一方で、膨大なファイルを転送できる安全なネットワークを含む、より広範なインフラも連携して機能しなければなりませんでした。厳しい予算と納期のなかで、制作チームがより野心的な成果を求める一方、ワークロードのスケジュールを組み、容量を割り当て、膨大なデータを移動させる必要がありました。インフラは、利用効率と性能を高めるために継続的に最適化しなければなりませんでした。

AIは、その根本的な課題をはるかに大規模にしたものです。組織はインフラに多額の投資をしていますが、容量を増やすだけでは、高価な資源を効率的に利用できるとは限りません。また、電力、容量、セキュリティ、経済性、地理的条件、規制、主権に関する要件を背景に、AIインフラは場所、プロバイダー、環境をまたいで、ますます分散するようになっています。レンダリングとAIではワークロードが大きく異なる場合がありますが、重要なインフラ上およびエコシステム上の課題は共通しています。どちらも、高性能コンピューティング、ネットワーク、セキュリティ、ストレージを効率よく連携させる必要があります。

AIインフラが複雑化するなか、コンピューティング資源を追加するだけでは、その容量を効率よく活用するという運用上の課題は解決できません。ここで重要になるのが、オーケストレーションと、より広範なインフラのエコシステムを統制するポリシーです。これらを組み合わせることで、組織は増加する分散環境全体でワークロードを調整しながら、高価で制約のある資源をより有効に活用できます。

RAVELは、自社を分散型AIファクトリー向けのオーケストレーション層と位置づけています。あなたにとって「AIファクトリー」とは何を意味しますか。また、今日のインフラスタックには何が不足しているため、オーケストレーション層が必要なのでしょうか？

私の考えでは、AIファクトリーはGPUや高性能クラスターだけを指すものではありません。コンピューティング、ネットワーク、ストレージ、セキュリティ、電力、冷却に加え、AIワークロードの実行に必要な運用レイヤーを統合したインフラエコシステムです。AIファクトリーは、孤立したクラスターから、複数の拠点や地域にまたがる相互接続されたリソースのエコシステムへと進化しています。こうした複雑さは、手作業や個別に分断されたポイントソリューションでは、ますます管理しにくくなります。オーケストレーション層は、スタックを構成する多様で複雑な要素を連携させ、その基盤にある複雑さの一部を抽象化することで、この課題に対処します。これにより、運用担当者はインフラを連携したシステムとして管理しやすくなります。

組織が既存のデータセンターをAI向けに適応させるなか、多くの施設は、今日のAIワークロードの要求を前提に設計されたものではありません。現在のAIインフラには、3つの主要な問題に分けられる構造的なミスマッチがあります。第一は電力です。大規模なワークロードを実行できる、十分で安定した電力を確保できる場所を見つける必要があります。第二はエコシステムの分断です。AIスタックは、相互運用を前提としていない孤立した環境に分散していることが少なくありません。第三は、運用コストと所有コストの全体像を把握しにくいことです。そのため、AIインフラの実際のコストが見えにくくなる場合があります。その結果、ワークロードが最適化されないまま実行されたり、ハードウェアの利用率が低くなったりするほか、予期せぬ運用コストによって総所有コストが膨らみ、最終的にはトークンコストの上昇につながる可能性があります。

AIインフラは、ハイパースケールクラウド、プライベートデータセンター、オンプレミスシステム、専門GPUプロバイダーなど、さまざまな環境にますます分散しています。こうした異なる環境にまたがってAIワークロードを管理する際、組織が直面する最大の課題は何でしょうか？

ここ数年、AIインフラをめぐる競争は、「より大きく構築する」という単純な前提に基づいてきました。より大規模なデータセンター。より大規模なクラスター。より多くのGPU。より多くの容量。しかし、「より大きく構築する」モデルは、物理的、経済的、規制上の制約にますます直面しています。

電力には限りがあります。送電網への接続には時間がかかります。経済性、地理的条件、主権上の要件が、インフラをどこに構築できるか、そしてどこに構築すべきかを、ますます左右するようになっています。新たな課題は、単にAIインフラをさらに構築することではなく、適切な場所に適切なインフラを構築し、あらゆる環境を連携したシステムとして稼働させることです。容量がハイパースケールクラウド、プライベートデータセンター、オンプレミスインフラ、そして必ずしも相互運用を前提に設計されていない専門プロバイダーに分散している場合、この課題はとりわけ困難になります。

これらの制約のなかでも、電力は最も深刻です。AIインフラをそもそもどこに構築するかを、電力の確保可能性がますます左右するようになっています。

そこで重要になるのがフェデレーションです。フェデレーションは、複数の環境にまたがるインフラを接続し、共通の運用環境を形成します。さらに、インテリジェントなオーケストレーションによって、容量、電力、性能、コスト、ポリシー、レジリエンス、主権上の要件に基づき、ワークロードをどこで実行すべきかを判断します。

AIインフラが拠点やプロバイダーをまたいでさらに広がるなか、競争上の優位性は、単に容量を多く保有することから生まれるわけではありません。その容量を連携させて活用することが重要になります。フェデレーションは、この新たな現実に対応するインフラモデルを構築し、インテリジェントなオーケストレーションは、そのモデルを大規模に運用可能にします。

中南米最大のAIテクノロジーパークおよびデータセンターを開発する当社の顧客の一社、RT-Oneは、南北アメリカ大陸全域にわたるフェデレーション型インフラを計画するなかで、まさにこのモデルを追求しています。分散した容量を接続し、最終的に連携した環境として管理できるようにする取り組みです。

GPU不足は大きな注目を集めていますが、アクセラレーターを単純に増やしても、AI計算能力をより有効に活用できるとは限りません。今日のAIインフラで、最も大きな非効率性はどこにあると考えますか。また、オーケストレーションを改善することで、企業はどれほどの追加容量を引き出せるでしょうか？

AIインフラをめぐる競争では、新たに計画されている容量が何ギガワットに上るか、また、その構築にどれだけの資本が投じられるかが大きく注目されてきました。AIインフラの問題を、単にGPUや容量の不足として捉えたくなるかもしれません。しかし、この見方では非効率性が実際にどこにあるのかを見落としてしまいます。計画中の容量が、そのまま利用可能な容量を意味するわけではない点が重要です。

GPUクラスターは予約で埋まっているように見えても、スタックの別の箇所で性能上のボトルネックが生じると、高価なGPUが稼働しないままになることがあります。ボトルネックの原因としては、ストレージのスループット、データパイプライン、ネットワークの輻輳、ジョブスケジューリングの非効率性、セキュリティ要件のほか、アーキテクチャ、アプリケーション、ドライバー、依存関係間の不整合が挙げられます。GPUを追加しても、利用可能な計算能力が必ずしも増えるとは限りません。

インフラを増やしても、自動的に効率が上がるわけではありません。多くの場合、コストを押し上げる一方で、サイロ化をさらに招きます。

組織が利用率を高め、インフラに関する意思決定を自動化し、ワークロードを利用可能なリソースや事業上の優先事項により適切に合わせるには、可視性と制御性を高める必要があります。可視性と制御性の向上は、インフラリソースの集合体を、より一体的に運用できる環境へと変える助けになります。オーケストレーションによってどれだけの容量を活用できるようになるかを示す、正確で普遍的な数値はありません。ワークロードごとに要件が異なるためです。ただ、明らかなことが一つあります。遊休状態または十分に活用されていない容量への答えは、単に設備を買い足したり、さらに構築したりすることではありません。

RAVELは、インフラ、仮想化技術、IDシステム、アプリケーション間の相互運用性を重視してきました。AIワークロードが複雑化・分散化するなかで、相互運用性の重要性が特に高まっているのはなぜでしょうか。

インフラの異種混在が進むなか、組織には、孤立したインフラのサイロを増やさずに、さまざまな技術や環境を利用できる柔軟性が求められています。相互運用性があれば、異なるベンダーや環境のコンピューティング、ストレージ、ネットワーク、アプリケーションを連携させ、インフラの進化に応じて選択肢を維持できます。しかし、相互運用性だけでは、それらのリソースをどのように使うべきかは決まりません。

そこで重要になるのがオーケストレーションです。環境をまたいで、ワークロードの実行場所や移動方法、ポリシーの適用方法を調整します。AIインフラの分散化とフェデレーション化が進むにつれ、相互運用性はさまざまな技術を横断して運用する柔軟性をもたらし、オーケストレーションはそれらのリソースを一体的に運用できる環境へと変えます。

RAVEL Orchestrate AIは、コンピューティング、ストレージ、ネットワークなどのインフラ技術を横断する共通のオーケストレーション層を提供し、クラウド、オンプレミス、ハイブリッド環境にわたってAIワークロードを調整します。

AIを導入する政府や企業にとって、データ主権は重要な検討事項になりつつあります。主権を備えたAIインフラの拡大によって、組織はワークロードの配置、データ移動、セキュリティ、オーケストレーションについて、どのように考え方を変える必要があるでしょうか。

主権AIは、いまや戦略上の優先事項です。それに伴い、より根本的な問いが浮かび上がります。主権を持つとは、実際にはどういう意味なのでしょうか。議論の中心は、これまで主にデータの保管場所に置かれてきましたが、私はその定義は狭すぎると考えています。

私は主権AIを、国家、企業、政府機関、その他の組織が、自らのAIワークロードをポリシーに基づいて管理できることと定義しています。これには、ワークロードを規律するデータ、モデル、コンピューティングインフラ、アクセス、セキュリティ、運用、管轄権の管理が含まれます。主権を確保するために、すべてのワークロードを一つのデータセンターに置き続けたり、単一の組織が所有するインフラだけで運用したりする必要があるとは限りません。むしろ、組織が、ワークロードの実行を許可する場所、データの保管や移動が認められる範囲、アクセスできる主体、その実行に使用できるインフラ、そして常に維持すべきセキュリティ、規制、地理、運用、事業上のポリシーを定めるということです。このワークロードを中心に据えた定義は、主権をデータの保管場所だけでなく、AI環境全体の管理として捉えるという、業界全体のより大きな動きにも合致しています。

主権AIとフェデレーションが交わる場面で、RAVELのアプローチは特に際立ちます。RAVEL Orchestrate AIでは、主権に関する要件をオーケストレーション層とポリシー層における制約条件として扱えます。ワークロードを、複数のサイト、クラウド、データセンター、エッジ拠点、その他のインフラから成るフェデレーション全体で実行できる場合でも、そのワークロードの主権ポリシーを満たすリソースに限られます。承認された範囲内では、電力、コスト、パフォーマンス、容量、利用率、ネットワーク特性、場所、優先順位などを考慮し、適切なインフラを判断できます。フェデレーションによって主権が失われるわけではありません。むしろ、主権によって定められた境界の内側でフェデレーションを運用できます。たとえば、機微な政府のワークロードは、承認済みの米国内施設だけで運用しながら、複数の認可済みサイト間で動的にオーケストレーションできます。その結果、組織は、最も機微なワークロードをどこでどのように運用するかについての管理権を手放すことなく、分散型AIインフラがもたらす利用率とレジリエンスの利点を得られます。

RAVELは、ワークロードが非常に高いコンピューティング能力を必要とするメディア、エンターテインメント、ゲーム、デザインなどの業界から生まれました。生成AIの要件によって、クリエイティブ分野の専門家が抱えるインフラ課題を解決するために当初開発したプラットフォームは、どのように変化しましたか。

RAVELは、アーティストやエンジニアがすでに高額なコンピューティング、ストレージ、ネットワークリソースを使い、大規模なレンダリング、シミュレーション、コンテンツ制作のワークロードを実行していた現場のインフラ課題を解決するために生まれました。根本的な課題は、利用率とパフォーマンスを最大化しながら、異種混在のインフラをより簡単に利用、共有、オーケストレーションできるようにすることでした。

生成AIによって、同じ課題の規模と複雑さが大幅に増しました。以前は主にアプリケーションやレンダリングのワークロードをオーケストレーションしていましたが、現在はAIモデル、エンジン、エージェント、トレーニングと推論のワークロード、さまざまなGPUアーキテクチャ、急速に変化するソフトウェアスタック、大量のデータ移動に加え、電力、コスト、セキュリティ、可用性に関する大幅に厳しい制約も考慮しなければなりません。

その結果、RAVELは、主にコンピューティングリソースをオーケストレーションする存在から、AIインフラ向けのインテリジェントな制御・最適化レイヤーを提供する存在へと進化しました。Orchestrate AIは、テレメトリーとポリシーを活用し、インフラが利用可能かどうかだけでなく、コスト、速度、電力、パフォーマンス、利用率、場所、データ主権の要件などを踏まえて、ワークロードをどこでどのように実行すべきかを判断します。

AIインフラを、互いに孤立したデータセンターの集合体として扱うことはもはやできず、ガバナンスとセキュリティを維持しながら、拠点をまたいで容量をインテリジェントに活用する能力が組織に求められるため、フェデレーションの重要性もますます高まっています。多くの点で、生成AIはRAVELが解決を目指していた根本的な課題を変えたのではなく、その課題を格段に大きく、複雑にしました。その結果、インテリジェントなオーケストレーション、最適化、フェデレーションの重要性がいっそう高まっています。

機械工学やStarbucksでのプロセス最適化から、デジタルメディア、データセンター、バーチャルスタジオ、そして現在のAIインフラに至るまで、さまざまな分野でキャリアを積んでこられました。そうした工学のバックグラウンドは、会社の立ち上げ方やインフラの課題解決にどのような影響を与えてきましたか？

工学のバックグラウンドは、おそらく会社の立ち上げ方のほぼすべてに影響しています。機械工学では、個々の部品だけでなくシステム全体に目を向け、制約となっているものは何か、エネルギーや資源がどこで無駄になっているか、システム全体の性能をどう高められるかを考えるようになります。Starbucksでは、その考え方をプロセスの最適化に応用しました。その後、デジタルメディアや視覚効果の分野では、システムを構成するものがコンピューティング、ストレージ、ネットワーク、アプリケーション、そして最終的にはデータセンター全体へと変わりました。テクノロジーは変わりましたが、課題への取り組み方はほとんど変わっていません。いつも、次のようなことを問いかけています。ボトルネックはどこにあるのか。十分に活用されていないものは何か。何を簡素化できるのか。そして、一部分だけを最適化するのではなく、システム全体をよりよく機能させるにはどうすればよいのか。

まさにその考え方でRAVELを築いてきました。AIインフラの課題は、GPUを増やしたりデータセンターを建設したりするだけのことではないと思います。コンピューティング、電力、ストレージ、ネットワーク、ソフトウェア、ワークロード、人材、そしてますます重要になる地理的条件やデータ主権も関わる、システム工学上の課題です。世界最速のGPUがあっても、システムの残りの部分が最適化されていなければ、非常に高価なボトルネックを生み出したにすぎません。そこでRAVELでは、テレメトリー、ポリシー、オーケストレーション、フェデレーションを活用し、ワークロードをどこでどのように実行すべきかを継続的に判断することで、インフラ自体をよりインテリジェントにすることを目指しています。キャリアの出発点では物理システムの最適化に取り組み、現在は同じ工学的規律を生かして、AIを動かすインフラの最適化に取り組んでいます。

今後、モデルやエージェント、アプリケーションがますます大規模な分散コンピューティングを必要とするなか、AIインフラはどのように進化するとお考えですか？過去10年間のクラウドコンピューティングと同じように、AIファクトリーが企業インフラの標準的なレイヤーになるとお考えでしょうか？

AIファクトリーは、クラウドコンピューティングと同じように、企業インフラの基盤となるレイヤーになると確信しています。ただし、単一の標準化されたデータセンターやクラウドのような形にはならないと思います。モデル、エージェント、アプリケーションがますます大規模なコンピューティングリソースを消費するにつれて、企業はGPUやCPU、プライベートインフラ、新興クラウド、ハイパースケーラー、エッジ環境、特化型AIシステムが混在する環境で運用することになるでしょう。

電力の確保、コスト、データ主権、パフォーマンス、立地は、コンピューティングリソースの確保と同じくらい重要になるでしょう。本当の課題は、インフラをさらに構築することだけではありません。分散したインフラ全体を、ひとつのインテリジェントなシステムのように機能させることです。未来のAIファクトリーは単一の建物ではなく、コンピューティング、電力、データ、そしてAIワークロードを最適な場所で実行するために必要なリソースを網羅する、フェデレーション型のインフラ環境です。

次の主要なインフラレイヤーは、そこから生まれると考えています。クラウドコンピューティングはサーバーを抽象化し、コンピューティングリソースをより簡単に利用できるようにしました。次の段階では、AIインフラスタック全体の複雑さを抽象化することになります。企業が、個々のモデルやエージェントをどのGPU、データセンター、クラウド、電力源、地域で実行すべきかを手作業で判断する必要はなくなるべきです。インフラ自体がテレメトリーとポリシーを活用し、コスト、速度、電力、パフォーマンス、可用性、データ主権を最適化するための判断を、ますます自律的に行うべきです。それが、RAVELが実現を目指している未来です。組織のポリシーと制御を維持しながら、フェデレーション型のAIインフラ全体でワークロードを移動できる、インテリジェントなオーケストレーションレイヤーです。クラウドは、必要なときにコンピューティングリソースを利用できるようにしました。次世代のAIインフラは、必要なときに最適化できるようにすると考えています。

素晴らしいインタビューをありがとうございました。分散インフラ全体でAIワークロードをオーケストレーションする方法について詳しく知りたい方は、RAVELをご覧ください。