OpenAIのポッドキャスト第18回である。AIモデルの学習効率を飛躍的に向上させるための新しいスーパーコンピューター・ネットワーク技術「MRC（Multipath Reliable Connection）」について解説している。従来のデータセンターネットワークが抱える通信のボトルネックや機器の故障といった課題を、MRCがいかにして克服し、研究者がインフラを意識せずに最先端のモデル開発に専念できる環境を実現したかを、開発陣が詳細に語っている。この技術は業界全体の発展のため、オープン標準として公開される予定である。
新たなネットワーク技術がもたらすAI学習の進化
こんにちは、アンドリュー・メインです。OpenAIポッドキャストへようこそ。本日のエピソードでは、スーパーコンピューターによるモデル学習をいかに改善していくかについて話し合います。コアネットワーキングチームのマーク・ハンドレーと、ワークロードシステムズのグレッグ・スタインブレッカーをお迎えしています。ブレイクスルーによって学習がどれほど効率化され、誰もがよりスマートなモデルをより早く手に入れられるようになったのか、お二人に語っていただきます。
これにより、スケールを続ける上での主要な障壁の1つを取り除くことができました。世界最速クラスの膨大な数のGPUを、単一のタスクで連携させるという話です。研究者たちが、今使っているクラスターがどんなネットワークプロトコルを使用しているかを意識しなくなったとき、私たちの勝利だと言えます。
複雑なシステムへの探求とデータセンターとの出会い
まずは、これまでの経歴について少し教えていただけますか。
私は大学の学部で物理学と数学を学び始め、複雑なシステムがどのように機能するのかを根本から理解したいと考えていました。物理学の中でも、途方もなく複雑な対象を取り上げ、完全に嘘っぱちであってもそのシステムについて何かを教えてくれるシンプルなモデルを構築し、そこから直感を養ってさらに複雑なモデルを構築していくというアプローチが昔から好きでした。そして結局、量子コンピューターを構築しようと博士課程に進みました。
野心的な博士課程ですね。
ええ、ちょっとしたことです。残念ながら私が好きだったのは巨大で複雑なシステムでして、ご存知の通り量子コンピューターはまだ機能しないため、今のところスケールしないんですよね。いつか機能する日は来るでしょうが、まだです。それで、量子コンピューターの光を制御するために設計していたチップを見てみたんです。そして、あれ、これってネットワークスイッチみたいだな、これをネットワークスイッチとして使ったらどうなるだろう、と思ったんです。
そこですぐに気づいたのは、学界は実際のデータセンターのワークロードがどのようなものか、あまり分かっていないということでした。非常に小規模なおもちゃのようなモデルはたくさんあるのですが、あまり参考になりません。
そこで私は、フェローシップを得るために産業界の企業に売り込みを行いました。彼らが私の博士課程の最後の2年間を支援してくれました。そしてしばらくその企業で働き、実際のデータセンターネットワークに何が求められているのかを理解するために、初期のネットワークハードウェアの構築などに携わりました。
そこで分かったのは、従来のデータセンターのネットワークハードウェアにはまだまだ余裕があり、最適化の余地が山ほどあるということでした。私の小さな光学チップは必要ありませんでした。そんな手の込んだことは不要だったのです。しかし、非常に面白い問題が山積していました。
ちょうどその頃、AIブームが始まりました。私たちは巨大なGPUクラスターを構築する必要があると判断し、特にそのGPUクラスターのためのネットワークを構築する必要がありました。そこで私は、何を構築すべきかを把握するためのシミュレーションの構築に巻き込まれました。そして、これらのシステムのシミュレーションを構築する過程で、システムがどう機能しなければならないかについて多くを学びました。
ある時点で、実際のものを自分で作ってしまえばいいのではないかと思いました。それで、シミュレーションを構築するためのソフトウェアを書くことから、GPU同士が通信できるようにする実際のソフトウェアを書くことへと移行したのです。
そして1年ちょっと前に、ここOpenAIに来て同じようなことをしつつ、実際のモデル学習により近いところで働くことになりました。現在私が所属しているチームは、大まかに言えば、GPUをいかに効率的に使用しているかを確認する責任を負っています。モデルの学習は最大限のスピードで行われているか。ネットワークがボトルネックになっていないか。何か障害が起きたときにどう対処するか。効率的に再起動できているか。ハードウェアの癖をどう回避するか、といったことです。今では世界で最も面白いハードウェアをいじり、そこから最後の一滴までパフォーマンスを絞り出そうとしています。
インターネットの標準化からデータセンターへの移行
マーク、あなたはコンピューター同士を通信させて有意義な作業を行わせるという分野でかなりの経験をお持ちですが、あなたの経歴についても詳しく教えてください。
私はOpenAIにいない時はユニバーシティ・カレッジ・ロンドンの教授をしておりまして、もう何十年もネットワーキングの研究を続けています。もともとは、インターネットでビデオ会議をできるようにする研究から始めました。当時のコンピューターはとても遅かったので、それは非常に困難な課題でした。
その後、それを実現する方法を考案したところ、突然世界中が関心を持ち始めました。私たちが作成したその標準規格は、現在皆様のスマートフォンが4Gや5Gネットワークと通信するために使用されている技術そのものです。誰もが実際にその技術を利用できるように、ありとあらゆるものの標準化を進めるというのが、私の人生の最初の部分でした。
標準化の問題点は、全員が合意しなければならないということです。ですから、何事においても全員の合意を得るにはとにかく長い時間がかかります。
しばらくして、私はデータセンターの世界で起きていることに関心を持つようになりました。データセンターには、何か違うことができるという大きな利点がありました。世界中と合意する必要はなく、構築している間だけ関係者と合意すればよかったからです。
そうして私は、このデータセンターのネットワーキングという分野は非常に面白い場所だと考えるようになりました。
AI時代のネットワークが抱える特殊な課題
今これほど多くのGPUをスケールさせているという事実だけでも、本当にあっという間に起きたことなので、非常に興味深い問題ですよね。私たちは今でもGPU、つまりグラフィカル・プロセッシング・ユニットを使っていますが、ようやくこの処理に次世代のチップを使い始めようとしている段階です。私たちがこれについて考える方法をアップデートし、使用するツールをアップデートするために、どれほどの労力が費やされたのでしょうか。これが本日のテーマであるMultipath Reliable Connectionに繋がるわけですが。
ネットワークの観点から言いますと、私たちが従来構築してきたデータセンターは、インターネットでやってきたことから派生したものでした。インターネットで通信を行う場合、非常に多くの人々が通信をします。膨大なデータが移動していますが、誰もがそれぞれ個別の会話を行っています。
ですから一般的には、同じ共有ネットワークに通信を追加すればするほど、全体が平準化され均等になります。これは素晴らしいことです。大数の法則を活用できるわけですから。
残念ながら、私たちがモデルの学習を行っているときの状況を見ると、それとは完全に正反対なのです。世界最速クラスの膨大な数のGPUを、単一のタスクで連携させようとしているわけですから、事態は困難になります。
このすべてのデータをインプットし、AIモデルがそのデータから並列に学習できるようにするプロセスこそが、より賢く優れたモデルの構築を可能にしています。
しかし、もし1つのGPUの動作が少し遅くなったとしましょう。そうすると、他のすべてのGPUがそれを待たなければならなくなります。それはすべて無駄な時間です。あるいは、あるGPUに宇宙線が当たってビットが反転し、停止してしまったとします。そうなると、そのステップ全体が無駄になる可能性があり、ロールバックするか、あるいは停止して何が起きたのか状況を確認しなければなりません。そして、私たちが状況を確認している間、すべてのGPUは有益な作業をしていないことになります。
ここで重要なのは、GPU間の通信が実は計算の一部であるということです。彼らは別々のことをしているわけではなく、全体で1つの大きな計算を行っているのです。計算のそのステップの結果に合意するために、実際にGPU同士が通信し合う必要があります。
これはネットワークにかける負荷としては、考えうる限り最悪のワークロードです。そのため、業界はこの数十年間、これをどう実行するかについて徐々に改善案を生み出してきました。しかし最近までは、それが本当に問題になるほどの規模ではありませんでした。インターネットで行ってきたのと同じことを、ただ少し大きくするだけで済んでいたのです。
しかし、もはやそれでは通用しなくなりました。だからこそ私たちは、スケールアップしていく中でこうした非常に同期性の高いワークロードに対処するため、根本的に異なる問題解決の方法を考えようとしたのです。
ネットワークインフラとAI学習の密接な関係
AIは世界の多くのものを根底から覆しました。テクノロジー企業が構築するデータセンターに対する考え方も間違いなく覆りました。ウェブ時代の従来のハイパースケーラーでは、これを構築するチームは個々のワークロードから非常に切り離されていました。目標は基本的に、計算リソースの海を提供することだったからです。
しかしAIは、私たちに全く異なる考え方を強いました。特にOpenAIは、システムの設計がモデルの学習と不可分であること、そしてインフラチームを別の建物に座らせてただ計算リソースの海を提供させ、モデルチームを別の場所に座らせてそのリソース上で最高のモデルを作らせるというようなやり方ではダメだということに、いち早く気づきました。システム全体にわたって協調設計を行わなければならないのです。
ですから私のチームは、文字通り研究者たちの隣に座り、どうすれば彼らのワークロードを既存のサーバーに最適に適合させることができるかについて、毎日話し合っています。その過程で、どこに課題があるのかを多く学びます。私たちは大規模な学習の実行中はオンコール待機しています。何か壊れて修復不可能な問題が起きれば、真夜中であっても叩き起こされます。
そうしたプロセスを経て、次世代ではこれらの問題を解決したらどうなるだろうかと考えるようになります。ウェブ規模のワークロードと同じ特性を持つデータセンターを構築するのをやめたらどうなるか。代わりに、こことこことここを修正したらどうなるか。私たちにとって、ネットワークはまさに悩みの種でした。
そうですね。データセンターのネットワークを構築する際、これらのすべてのGPUが計算を行い、同時に通信する必要があるため、膨大な帯域幅が必要になります。問題は、それを1つのスイッチや、単一のスイッチの階層では構築できないということです。スイッチの階層の階層を構築しなければなりません。
つまり、あるGPUから別のGPUへ通信する際、そのネットワークを通るトラフィックの経路は多数存在するということです。私たちが何千ものスイッチを組み込んでいるため、トラフィックがネットワークを通る経路は数千通りにもなります。これらの建物の1つには、数千台のスイッチがありますから。
そこで興味深い問題が生じます。ある場所から別の場所へ行くのに、どの経路を選ぶべきかということです。
もし、あるGPUから別のGPUへできるだけ早く送信したいという要件があり、ネットワークの経路をランダムに選んだとします。運良く他の誰も同じ経路を選ばなければ、それは素晴らしいことです。しかし運悪く2人が同じ経路を選ぶと、速度は低下します。もし10人が同じ経路を選べば、非常に遅くなります。
インターネットの設計時に用いていたこの統計的多重化という手法は、データセンター用のネットワークを構築しようとすると、あまり上手く機能しないのです。そこで私たちは、少し違う設計を試みることにしました。
先ほどお話ししたワークロードの同期性が、なぜこれほど問題になるのかについて、少し明確にしておきましょう。平均的なGPUのペアがどれだけ速く通信できるかが重要なのではありません。常に、発生しうる絶対的な最悪のケースが問題になります。
互いに通信しようとしている何千ものGPUがあると考えてみてください。数万のリンク上に、数万、あるいは数十万のネットワークフローが存在します。しなければならないのは、ネットワーク全体を見て、ここで最もボトルネックになっているリンクはどれかと探すことです。
すべてが足並みを揃えて進行しているため、その1つのリンクが、すべてのGPUがどれだけ速く作業できるか、データを移動させるのにどれだけの時間がかかるかを決定してしまいます。
ですから、以前は平均的な統計の恩恵を受けていたかもしれませんが、もはやそのような贅沢は許されません。その代わり、私たちはしっぽのしっぽ、つまりP100と呼ばれる100パーセンタイルの統計に左右されるのです。これにより、大数の法則に頼ってうまくやれる場合とは、まったく異なるシステム要件が求められます。
もう1つの問題は、私たちがネットワークを構築する際、可能な限り最高のネットワークを構築しているということです。最高の機器ベンダーに行き、最高の光学機器などを利用します。しかし、本当に規模を大きくすると、常に何かが故障するようになります。
リンクが切れ、スイッチが混乱して再起動が必要になり、といった具合です。こうした故障の1つ1つが、ネットワーク上を流れるトラフィックに影響を与えます。
100パーセンタイルしか気にしないという状況でネットワークのリンクが切れたらどうなるでしょうか。当然、問題が発生します。ルーティングが再収束してトラフィックを別の経路に移すまでの間、少し時間をとられます。そこでグリッチが発生します。それが長時間のグリッチになると、コストの無駄になります。さらに悪いことに、通信転送の1つが完全に失敗してしまう可能性もあります。たった1つの転送が失敗しただけで、ジョブ全体がクラッシュしてしまうことだってあるのです。
私たちは、そのような問題は絶対に避けたいと考えています。ネットワークに生じる可能性のある一時的な輻輳だけでなく、障害が発生した際にも、単に作業を継続し、基本的には何も気づかないような耐性を持つネットワークの利用方法を構築したいのです。
しかしそれには、最初からネットワークプロトコルを別の方法で設計する必要があります。既存のネットワークプロトコルにこれを後付けすることはできません。
お話を伺っていると、非常に興味深い問題ですね。1000個のGPUなら10回に1回しか失敗しないかもしれないと言えても、10万個のGPUになれば、常に失敗が起きるということです。規模を拡大するたびに、それを解決しなければならないわけですね。どこで壊れるのかと探せば、至る所で壊れているわけです。
その機器の平均故障間隔について考えてみると、建物のどこかで何かが故障するまでの時間というものがあります。当然ながら、機器のコストが同じであれば、規模が大きくなるほどその時間はどんどん短くなります。そして最終的には、同期性の高い大規模なワークロードでは何も作業が進まなくなるほど頻繁に何かが故障する地点に到達します。そんな事態は避けなければなりません。だからこそ、うまくいくように別のやり方をしなければならないのです。
ええ。非常に単純な計算ですが、故障が独立して発生すると仮定してシステムの規模を2倍にすれば、故障と故障の間隔は半分になりますよね。平均故障間隔が半分に減るわけです。
ここでネットワークについて考える上で重要なのは、すべてのGPUに対して、数十から数百のネットワークコンポーネントがあるということです。たとえば、1つのGPUが1つのネットワークアダプタに接続されているとしましょう。そのネットワークアダプタに光トランシーバーが入っていれば、おそらく4つのレーザーがあります。そのトランシーバーの反対側にも、さらに4つのレーザーがあります。つまり、その1つのGPUを最初のホップのスイッチに接続するだけで、すでにGPUの数よりも1桁多いレーザーが存在することになります。そこに複数層のスイッチングが加わると、ネットワークの末端にあるコンポーネントよりも数桁も多いコンポーネントがネットワーク内に存在し始めることになります。
これほどまでの帯域幅が必要だからです。私たちはこれらのネットワークを構築しなければなりません。先細りにしてネットワーク内に数個のコンポーネントしか持たせないようにすることはできません。それではGPUを飢えさせてしまうからです。GPUは可能な限り速く計算を行うという本来の能力をフルに発揮できなくなってしまいます。GPUを遊ばせておくことになり、時間と資金とエネルギーの無駄遣いになってしまいます。
モデルの学習速度も遅くなり、悪いことずくめです。だからこそ非常に巨大なネットワークを構築したのですが、今度はネットワークの末端にあるよりもずっとずっと多くのコンポーネントがネットワーク内に存在することになります。同じ建物の中に、文字通り数百万の光リンクが存在するのです。
とてつもない規模ですね。データセンターは元々どのようなものだったかというお話がありました。クラウドを検索したり、メールをチェックしたりする際、1つのサーバーと通信し、そこにはバックアップがあるかもしれません。データセンター内でコンピューター同士が通信する量が、ほんの数年前に人々が接続しようとしていた量よりも多くなるなんて、想像もしていませんでした。
では、これらのプロトコルはどのように進化してきたのでしょうか。私がネットワーキングの世界に入るきっかけの1つになった、非常に鮮明な記憶があります。2017年にOFCという光通信のカンファレンスに参加したのですが、そこでFacebookの発表者がいました。
彼は、エンドユーザーに提供するトラフィックと、データセンター内部を流れるトラフィックを積み上げ折れ線グラフにして提示しました。エンドユーザーに送信するトラフィック量は一定に保たれているにもかかわらず、データセンター内部のトラフィックは爆発的に増加していたのです。これはGPUクラスターやAIが登場するずっと前の話です。つまり、AIがもたらしたのは、人々が以前から抱えていたシステム上のあらゆる課題を取り上げ、その難易度を極限まで引き上げたということなのです。
新技術「MRC」による通信の最適化
この問題に対処するため、Multipath Reliable Connection、つまりMRCという手法に取り組んでこられたのですね。
その洞察の基本は、ネットワークの輻輳を管理しようというところにあります。そのために組み合わせられる要素がいくつかありまして、最初の洞察は、パケットを多数の経路に分散して送信すれば、ネットワーク全体の経路間で非常に均等に負荷分散できるということでした。それを行って十分な容量を持つネットワークトポロジを構築すれば、ネットワーク内にホットスポット（混雑箇所）を発生させることはありません。
ただ1か所、複数の送信元が同時に同じ宛先に送信しようとした場合のみ輻輳が発生しますが。
しかし、同時にいくつかの問題も残ります。パケットが異なる経路を通るため、転送中に順序がバラバラになる可能性があるのです。もし輻輳を起こしてパケットの損失を発生させてしまった場合、それが失われたのか、それとも順序がバラバラになっただけでまだ待つべきなのかを判断するのが少し難しくなります。
そこで第2の要素として、私たちが「パケットトリミング」と呼んでいる技術が登場します。
ネットワーク内で輻輳を発生させ、キューをオーバーフローさせてしまうような場合、通常は単にパケットを破棄します。すると曖昧さが生じます。失われたのか？ どれくらい待てばいいのか？ と。
しかし私たちが代わりに行うのは、パケットのペイロード（データ本体）を切り落とし、小さなパケットヘッダーだけを宛先に転送することです。宛先は即座に再送を要求することができ、私たちはそのパケットを再送できます。
これにより、輻輳によってパケットが失われたのか、それとも順序が入れ替わったためにまだ待つべきなのかという曖昧さが完全に排除されます。
面白いですね。つまり「そこにいますか」という確認部分だけを先に通し、状況を把握してから残りを送るという確認作業を確実に行っているわけですね。
はい、まだ待つべきなのか、もう待たなくていいのかを明確に知る必要があるのです。
ユーザーへの恩恵とネットワークの自己修復
これにより、エンドユーザーにはどのようなメリットがあるのでしょうか。
最大のメリットは、より優れた、より知的なモデルをOpenAIからより早く受け取れるようになるということです。
MRCによって、私たちの研究および展開のパイプラインのあらゆる部分が加速されます。個々のユーザーは、自分のジョブが失敗しないか心配したり、ジョブがどのようにスケジュールされたか、他の人のジョブと同じラックに配置されたことでパフォーマンスが変わってしまうのではないかと心配したりする必要がなくなります。
これにより、私たちは最先端のモデルをはるかに速く、より高い信頼性で学習させることができ、パイプラインのサイクル全体をはるかに高速かつ確実に回すことができるようになります。ですから、私たちからますますエキサイティングなリリースが継続的に発表されることを期待していただければと思います。
雰囲気は良いですか。
ええ、雰囲気は良いですよ。とても良い雰囲気です。このアイデアは、私たちが過去数十年間に取り組んできた多くの研究作業から生まれました。私たちは根本的に新しいものを発明しているわけではありません。他の人々が発明したものを利用し、その組み合わせをまとめて1つの機能セットにしているだけなのです。
そうして、これに興味を持つ人々でグループを結成しました。そして昨年、ついにこれをデプロイできる段階に到達しました。最初のハードウェアが利用可能になってから数か月のうちに、実際にモデルの学習を実行し、すべてが稼働する状態まで持っていくことができました。
これによって、先ほどお話ししたような輻輳を引き起こさないという結果が得られました。
2つ目の非常に素晴らしい特性は、ネットワークで何かが故障した場合、そこを通るすべてのフローがおそらくその故障の影響を受けるということです。しかし、その影響はほんのわずかです。ネットワークを往復する数回のラウンドトリップタイムのうちに、私たちは故障したリンクの使用を停止します。
ですから、リンクの故障がネットワークをダウンさせるという問題は単に消え去ります。ある側のネットワークインターフェースから別のネットワークインターフェースへ向かうすべてのフロー自体が、ネットワークを通過する際にそうした故障を回避していくのです。
まるで自己焼きなまし（セルフアニーリング）のようですね。
まさにその通りです。マークは少し控えめに言っていますが、もう少し強調すべきかもしれません。マーク、謙遜しすぎですよ。
従来、ネットワーク上のリンクがダウンした場合、そのリンクの片側にあるスイッチ、あるいはおそらく両側のスイッチがそれに気づきます。しかしその後、そのリンクがダウンしたことをすべての隣接スイッチに伝えなければなりません。さらにその隣接スイッチは、自分のすべての隣接スイッチにそれを伝えなければなりません。つまり、分散システムの問題になるのです。
これは従来、BGP（Border Gateway Protocol）と呼ばれる技術で解決されてきました。これは基本的にゴシッププロトコルのようなもので、ある場所のリンクが、おそらくネットワークを5つか7つホップして遠く離れた場所にあるスイッチに「やあ、このリンクを通ってもあの宛先には行けないよ。他のリンクを使わなきゃダメだ」と最終的に伝えるためのものです。
これはコンバージェンス（収束）時間を伴う分散システムの問題です。MRCがやったことは、それを取り上げ、調整の必要性を壊したことです。すべてのエンドポイントが独立して非常に素早く「あ、あの経路は使うべきじゃないな」と検知し、ただ使用をやめるのです。
これは直感に反するかもしれません。なぜなら、リンクがダウンしたことを教えてくれる中央の権威機関があって、そこが情報を配信してくれた方が簡単だと思われがちだからです。
ウェブサイトの更新を待ったことがある人なら誰でも、それが上手くいかないことは知っていますよ。
その通りです。中央の権威機関というのは、一般的に単一障害点（SPOF）とも呼ばれますからね。ですから、その代わりに私たちがここでやったのは、秒単位、悪くすれば数十秒かかる可能性のあるコンバージェンスのプロセス全体を待つ必要をなくしたことです。その代わり、一般的にはミリ秒単位で誰もが気づき、そのリンクの使用をただやめるのです。
これは非常に大きなことです。以前はリンクがダウンすると、ネットワークが安定するのを待つためにジョブ全体が数秒間停止していました。その時間もまた、GPUが有益な作業をしていない時間です。スケールアップしていくと、そうした個々の数秒間がどんどん積み重なっていきます。
今回私たちが観察したところでは、データセンターの建設中にこれをオンにしました。マークが言ったように、ハードウェアが到着してから数か月でジョブを立ち上げて学習を開始できました。
こうした建物を建設するには、多くの手作業が必要です。あるデータホールからの光ファイバーが入ってくる共有ポイントがあり、技術者たちが別のデータホールを組み立てようとしている、といった状況が多々あります。そうした手作業がすべて行われていたため、リンクは常にアップしたりダウンしたりを繰り返していました。自然故障で予想されるよりもはるかに頻繁にです。
しかし私たちは気にしませんでした。気づきもしなかったほどです。MRCがすべて対処してくれました。単に「あ、あの経路は使えないな。次へ行こう」と検知するだけです。気にすることはありませんでした。信じられないほどでした。
複雑さの排除と完全な静的ルーティング
さらにこれに加えて得られるメリットがあります。MRCが障害を自動で回避してくれるようになると、従来ネットワーク内で機能する経路を見つけるために動かしていたルーティングプロトコルについて考えることになります。ルーティングプロトコル自体が複雑ですし、スイッチも複雑で、スイッチのソフトウェアも複雑です。これらはすべて故障する可能性のあるものです。
私たちは、実はMRC自体がどの経路がまだ機能しているかを把握できることに気づきました。そこで実際、ルーティングプロトコルをオフにすることに決めたのです。最大規模のスイッチにおいて、完全に静的なルーティングを使用しています。
いくつかの経路が壊れている？ 誰も気にしません。MRCが、壊れていてもまだ機能する経路を見つけて進み続けます。これにより、もはや必要のない複雑さがネットワーク管理からごっそり取り除かれます。
スイッチのコントロールプレーンが収束したかどうかなど気にする必要はありません。収束する必要がないからです。完全に静的です。起動時に設定を持ち、起動後はルーティングテーブルを変更することはありません。
業界全体へのオープンソース化という決断
非常に多くの人々と協力した一大プロジェクトですね。パートナー企業について少しお話しいただけますか。
はい、Fairwaterデータセンターを構築しているMicrosoftと協力しています。そして、NVIDIA、Broadcom、AMD、Intelと協力してこの仕様の標準化を進めてきました。さらに、これらすべての企業と協力して新しいスーパーコンピューター用のハードウェアを実際に構築しています。
興味深いですね。この技術のユーザーとして、人々の考え方を聞いていると「次のモデルはいつ出るの？」といった声があります。まるで毎年提供されるソフトウェアアップデートのように考えているのです。でも違いますよね。すべてのモデルは本質的に研究プロジェクトであり、学習中に何が起きるかに左右されます。どのくらい時間がかかるかを見積もり、どこに着地するかを予測しようとします。しかし、こうした信頼性は信じられないほどの強みになりそうですね。
本当にそうです。以前からここにいる人たちと話をしていると、過去がどれほどひどかったか、どれほど頻繁に夜中に叩き起こされていたかという恐怖体験ばかり耳にします。カフェテリアを歩いていて、ネットワーキングに取り組んでいる人たちが悲しそうな顔をしているのを見たのを覚えています。学習の実行中に何が原因で停止したのか分からなかったからです。本当に大変でした。
今では、MRCを導入したクラスターがいかに安定しているか、いかにうまく機能しているか、そして研究者たちが基本的にこのことについて考える必要がなくなったことについて、誰もが口を揃えて肯定的なフィードバックをくれます。統計を見てみると、どれほど頻繁に色々なものが壊れているかに気づき、それでも彼らが全く気づいていないことが分かります。
ある意味、これが理想形ですよね。先ほどインフラの限界を押し広げていると言いましたが、ですからインフラを完全に無視できる時代は絶対に来ないでしょう。研究者がインフラについて考えなくて済むというのが理想の世界ですが、そうなることはありません。しかし、研究者が「ネットワークが」とか、この特定のクラスターが使っているネットワークプロトコルを知る必要がなくなった時、私たちは勝利したと確信するのです。
誤解しないでいただきたいのですが、他にも壊れるものはたくさんありますし、やるべき仕事は山ほどあります。しかし、これによって継続的にスケールするための主要な障壁の1つを取り除くことができ、より新しく優れたモデルをより早く提供できるようになりました。私たちは開発スピードを含め、あらゆる面でスケールアップしようとしています。
そして皆さんは、これを誰もが使えるようにオープンにすることを決断しましたね。
はい、この仕様はOCPを通じてオープン標準として公開される予定です。おっしゃる通り、私たちはこれを誰もが使えるようにオープンにすることを決定しました。
私たちはオープン標準とオープンソースを強く信じています。私たちはネットワークのすべてをイーサネットの上に構築していますが、これは利己的ではなくオープンな標準です。業界全体がスピードを持ち、私たちが取り組もうとしている困難な課題に業界がついてこられるようになれば、私たちにもメリットがあります。ですから、この分野で最良だと考えるソリューションを皆で展開しようとすることは、全員の利益になります。
AIの構築規模については多くの報道がなされていますが、個人的なレベルでは、もしそのサプライチェーンが分断されてしまったら本当に残念なことだと思います。少しでも有利に立とうとして、人々が全く異なる技術や基盤ハードウェアに投資してしまうような状況です。
これがオープン標準になることを私は本当に嬉しく思っています。OpenAI以外の多くの人々に利益をもたらすでしょう。また、私たちが皆で同じ方向に向かって推し進めていけば、私たち全員の利益にもなります。インフラというのは業界全体の運命共同体のようなものです。これをオープンソース化し、皆を巻き込んでいくことは非常に良いことだと考えています。
コラボレーションが進むという意味でも有益に思えますね。世界中に複数の拠点を持ち、多くのパートナーが関わるStargateのようなプロジェクトや、Microsoft、Fairwaterについて考えてみても、計算リソースというのは決して十分になることはないという前提があります。お互いに協力してそれを最大化し、継続していく方法を考える方が、「これは非常に限られたリソースだ」と囲い込むよりも、おそらく関わるすべての人にとって良い結果をもたらすでしょう。
先ほどイーサネットなどについておっしゃったように、私たちが今持っているものや、ワールド・ワイド・ウェブなど素晴らしい技術の多くは、「これを共有しよう、そうすれば得られる利益がはるかに大きくなるから」と気づいたことで生まれました。
ええ、私たちがやろうとしていることはただでさえ困難なのですから、誰もが常に車輪の再発明をしなければならないような状況は避けるべきです。これが正しい道だと信じていますし、他の皆さんにも私たちと同じ方向に進んでいただきたいと願っています。
MRCとイーサネットの未来
この技術の限界はどこにあるのでしょうか。
MRCは柔軟な標準規格です。イーサネットの上に構築されているため、イーサネットが拡張すればMRCも拡張します。イーサネットは個々のデバイスが互いに通信するために使用するプロトコルだと考えてください。MRCはその上に位置します。マークが話していたような静的ルーティングを組み込み、私たちが「輻輳制御」と呼んでいるものを組み込みます。これは基本的に、リンクの故障やトラフィックの送信方法に関する選択によって問題のある状況に陥った場合、エンドポイントがそれにどう反応して、ネットワークを公平かつ効率的に使用できるようにするかというものです。
私のネットワーキングの経験から言うと、やるべき仕事は常にあります。それを改善し、ネットワークをより公平にする方法は常に存在するでしょう。ネットワークには根本的な限界があります。具体的には、光の速度という既知の速度制限です。ネットワーク内である地点から別の地点へ光が到達するまでの時間には、下限があります。しかし、私たちはそれぞれのリンクをどんどん高速化し続けるでしょう。
そうなれば、特定のタイミングで1つの接続あたりどれだけのデータを保留できるかという動作点も常に変化します。そして、特定の世代で手元にあるハードウェアを最大限に活用するために、継続的なエンジニアリングの努力が常に求められます。しかし、私たちが次の数世代へと限界を押し広げ続ける中で、MRCは私たちが構築していくための非常に柔軟で強力な基盤を与えてくれると信じています。
重要なのは、おっしゃる通りそれがイーサネットベースだということです。現在のイーサネットは、10年前、20年前、30年前、あるいは40年前のイーサネットとは全く異なります。イーサネット自体が長年にわたって非常に進化してきました。そして私たちがしているのは、世界中のネットワーキング業界によるその開発のすべてを活用するということです。ですから私たちは、イーサネットを前進させてきたその革新の波に乗り続けたいと考えています。
そのすべてがどちらにせよ起きているわけですから、MRCがインテリジェンスをネットワークの末端に押しやっている以上、イーサネットがスケールし続ける限り、私たちのネットワークのコアもスケールさせることができます。そして少なくとも近い将来、それがスケールし続けないという明確な理由は特に見当たりません。誰にも分かりませんが、私より賢い人たちが、それをさらに40年間機能させる方法を見つけてくれるかもしれません。
とはいえ、私たちがやっている重要なことの1つは、実際にネットワークから複雑さを排除しようとすることです。先ほど申し上げたように、私たちはルーティングをオフにし、各パケットは実際にネットワークを通じてソースルーティングされます。私たちはIPv6セグメントルーティングという技術を使用しており、これにより個々のパケットのアドレスには、ネットワークを通過する際にパケットが経由する正確なスイッチのセットがリストされます。
つまり、スイッチ自体は本当にシンプルで良いということです。ネットワークの一部を単純化できるのは本当に素晴らしいことです。スケールさせ、高い信頼性でスケールさせようとする場合、ネットワークの中間部分を可能な限りシンプルにすることは、私たちに計り知れないメリットをもたらします。
ここでもう1つ、イーサネットには豊かで素晴らしい歴史があるというお話がありました。私たちが今もイーサネットの上に構築しているのは、それがオープン標準だからです。業界全体がそれを支持し、同じ方向に進んでいるからです。それこそが私たちがMRCにも期待していることです。次のレイヤーがAIのシステム課題に備え、広く普及するのを見たいのです。もしこれがOpenAI専用のものだったら、これほどうまくはいかないだろうと考えています。
OpenAIがこれらの問題を解決するために時間とエネルギーと人材を投資しているわけですが、MRCを誰もが利用できるようにしているとはいえ、専門チームが今これに取り組んでいるということは、OpenAIにとっても多くのメリットや強みをもたらしているに違いありませんね。
多くのメリットを得ようと努力しています。繰り返しになりますが、私の役割は「手持ちのものをどうやって最大限に活用するか」という観点です。文字通りの環境保護主義的な意味ではありませんが、ある意味ではそうです。もしこれらに電力を消費するのであれば、生産的に使用されたいですし、効率的に使用されたいのです。
MRCのもう1つの利点は、複数の経路にパケットを分散させる特性があるため、ネットワーク内のデバイス数がはるかに少ない、はるかにシンプルで小規模なネットワークを構築できることです。
これは直感的には分かりにくいかもしれませんが、要するに、私たちははるかにフラットでスイッチの階層がはるかに少なく、消費電力もはるかに少ないネットワークを構築できるということです。コストも大幅に下がります。余分なスイッチの階層に余分な電力を費やす必要がないため、1ワットあたりで実行できる有用な作業量が増加します。一般的に電力は直接GPUに供給され、実際に作業を行うために使われます。
宇宙データセンター構想に対する現実的な視点
データセンターについて語る際、学習用と推論用があるという話が先ほども出ましたね。ChatGPTに質問する際、データセンター全体と通信する必要はなく、質問に答えてくれる数個のGPUがあれば十分です。しかし次のステップとして、宇宙にデータセンターを置こうという話もあります。私の疑問は常にこうです。推論を行うGPUを搭載した衛星を持つことはできるでしょう。しかし、巨大なネットワーク上で数千、あるいは数十万マイルも離れて物理的にリソースを分散させると、1つのセンターに集中している場合に比べてスピードの利点がすべて失われてしまうように思えます。光の速度が敵になるわけですから。
私たちがStargateデータセンターで行っているような学習を宇宙で行うことは想像しがたいですね。レイテンシーだけでも大きな問題になりますし、日常的な故障率も問題です。MicrosoftやOracleの技術者が毎日行って修理しなければならない状況ですが、軌道上ではそれは困難です。
そうですね。あらゆる議論が可能だと思いますし、私もこの点については深く考えたことがあります。物理学のバックグラウンドがありますし、衛星を設計する人たちと一緒に働いたこともありますから。
しかし、多くの賢明な人々がその側面について双方から非常に妥当な議論を行ってきたと思います。最大の障壁は、やはり故障率でしょうね。GPUは世代を重ねるごとに強力になり、高価になり、重要になります。私たちは自動的に故障を迂回する素晴らしい技術を地球上で開発していますが、もしこれらを宇宙に打ち上げたなら、すぐに使えなくなったハードウェアを大量に抱えることになると思います。
技術者を宇宙に送り込める世界があるか？ もしかしたらあらゆる方法が可能になるかもしれません。私の夢見がちな部分は、それは本当にクールだと言っています。しかし現実的な部分は、地球上でこれをやるのさえ本当に難しいと言っています。
ええ、私たちは毎日あらゆる面で限界を押し広げようとしています。MRCを立ち上げるだけでも、私たちと他の多くの企業のエンジニアとの緊密な協力が必要な巨大な取り組みでした。場合によっては、修復やテストのために直接マシンに触れる必要もありました。これらのシステムは、地球上で構築し、機能させ、パフォーマンスを発揮させるだけでも十分に難しいのです。その限界を押し広げ、さらに複雑さを加えるとなれば、なぜそれを宇宙でやる意味があるのかについて、よほど強力な根拠を示さなければなりません。
ですから、地球上にさらに多くの計算センターを建設してください。お願いします。というのも、私たちがここでやろうとしているのは、大量の計算リソースを構築して、世界の知能の総量を増やすことなのですから。
素晴らしいですね。お二人とも、本日は本当にありがとうございました。
コメント