※本記事は、Prof. Nic Lane氏(University of Cambridge, Flower AI)による講演「Protocol Learning Workshop, ICLR 2026」の内容を基に作成されています。本講演は、ブラジル・リオデジャネイロで開催されたICLR 2026における、Pluralis Research主催のProtocol Learning Workshopにて収録されたものです。同ワークショップには、分散型かつ低帯域幅のネットワークを横断して大規模モデルを学習する研究に取り組む研究者たちが集まりました。Protocol Learningに関する詳細情報は https://pluralis.ai でご覧いただけます。
本記事では、講演の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演をご視聴いただくことをお勧めいたします。
1. なぜ今この話をするのか
1.1 革命のための5つの方向性
今日のこの場で私が話したいのは、次に私たちが実際に何をすべきかということです。研究をすることはパズルの一つのピースに過ぎないと考えています。もし本当にこれが革命であるべきならば、革命は論文だけでは起こりません。今朝、私たちが成功するために必要な要素は何かということを考えていました。この分野には、アカデミアにもスタートアップにもビッグテックにも、多くの勝者が生まれ得ると思っています。そこで今日は、次の5つのことについてお話ししたいと思います。
まず、発明し続けることです。これについては後ほど詳しくお話しします。次に、使いやすくオープンにすることが重要だと考えています。人々にすべてを変えてほしいと思うのであれば、摩擦を減らすためにも、それは使いやすくオープンである必要があります。もう一つ重要なのは、ネットワークを構築することです。Alexはまさにそれを実現しつつあると思いますが、私たちはこれが実現可能であることを示すために、今こそ多くのネットワークを構築する必要があると考えています。
そして、私たちが最近気づいたことがあります。それは、これらの手法が有効であるといくら証明を積み重ねても、多くの人々にとってはそれだけでは決して十分ではないということです。彼らが本当に必要としているのは、いわば活を入れられるような経験、つまり「あなたは疑っていたこの手法で、私はこのモデルを作った。これは素晴らしいものだ」と示されることなのです。ですから4つ目は、これらの手法を使ってモデルを構築することです。そして最後に、人々の困りごとを解決するというカテゴリーがあると思っています。
私たちは、このスタックを分散化し、再発明したいという動機を持っているかもしれませんが、それだけでは十分に思わない人々が大勢いるはずです。ですから、すでに存在していて、かつ議論の余地のない痛点を特定し、そこにこれらの技術で切り込んでいけると考えています。その一例が、GPU不足という問題です。ICLRにいる研究者は誰もが、もっと多くのGPUが欲しいと思っていますし、実現したいアイデアを無数に抱えています。この種の技術は、そうした人々にGPUを提供できます。彼らは分散化そのものやプロトコル、その他のインフラには関心がないかもしれませんが、GPUさえ手に入るのであれば、乗ってきてくれるはずです。人々の痛みを解決するということは、こうして関係者の利害を一致させる重要な要素になると考えています。これら5つのうちのいくつかでも正しく実行できれば、私たちはかなり前進できるはずです。
1.2 スケーリングを守るという情熱の背景
こうした詳細に入る前に、なぜ私がこの分野にこれほど関心を持っているのか、その背景についてもお話ししておきたいと思います。この分野は非常に広く、やや漠然としており、人によって関心を持つきっかけは異なります。Alexは非常に強い物語を語ってくれましたし、私もそれに完全に共感していますが、それとは別に、私が信じているもう一つの物語をお話ししたいと思います。私を毎朝奮い立たせているストーリーは、私たちがスケーリングを続けられるようにすること、そしてそのスケーリングを可能にするインフラが、本当に適切な種類のインフラであるようにすることです。
皆さんもEpoch AIの分析結果をご覧になったことがあると思います。彼らは日々素晴らしい仕事を続けており、その分析によれば、私たちは重要なものすべてを使い果たしつつあります。データも、シリコンも、これらを動かす電力も枯渇していくというのです。私たちには素晴らしいスケーリング則がありますが、それを実現するためのリソースを供給できなければ、そのスケーリング則は無意味になってしまいます。
この不足の根底には、私は人為的な理由があると考えています。それは、データセンターへの依存、つまり今日私たちが知っているデータセンター型インフラで十分だという思い込みから生まれているのです。これが実際には人為的な希少性を作り出しています。ですから、私を毎朝奮い立たせているのは、私たちが今まさに構築しようとしているものが、完全に行き詰まりだと考える既存のAIインフラの置き換えであるという点です。これは完全な行き詰まりです。もしAGIに近いものを作りたい、私たちが目指しているすべての成果を実現したいのであれば、根本的な変革が必要になります。あなたがGoogleであろうと、OpenAIであろうと、Jeff Deanであろうと関係ありません。これを壊して、車輪を再発明しない限り、目指すべき場所には決してたどり着けないのです。
だからこそ、このワークショップがICLRの正式なワークショップの一部ではないということも、実に象徴的だと思っています。それはまさにこの動きの出自を体現しています。これから何が起きるかを議論するのが、このワークショップの意義です。データセンターに代わるもの、私が行き詰まりであり時間と資金の無駄であると考えるものに、何が取って代わるのかということです。
データセンターが今や無意味であるという明確な議論の背景には、AI研究がこれまで長らくビッグテックによって、できる限り速く動く必要があるという前提のもとで、非常に力任せなスタイルで進められてきたというギャップがあります。データセンターによって私たちが到達した数々の進歩を軽視するつもりはまったくありませんが、それは驚くほど一方向的なイノベーションでした。優れたTPUをどう作るか、素晴らしいGPUをどう構築するか、それらをどう高速化するか、そしてそれらをどう一箇所に多く集めるか。それがすべての取り組みでした。何百万人時もの労力が費やされ、今のモデルを作るために山をも動かすほどの努力が払われてきましたが、それらすべてを一言でまとめるなら、考え方が小さすぎたのだと思います。
つまり、今日のAIインフラとは、1000台のGPUから1万台、5万台、10万台へと単純に規模を拡大していくことに過ぎず、この技術が持つ社会的重要性にふさわしい、広大で重要な設計空間を無視しているのです。この分野は社会のあらゆる部分にとって極めて重要であるにもかかわらず、私たちはそれを支えるインフラを非常に一方向的な思考で構築してしまっています。その結果として、これらのシステムはクローズドで単一組織・単一ユーザー向けであり、リソースの共有がまったく行われていません。これはおそらく計算機科学の中で最もリソースが逼迫している分野でありながら、リソースをまったく共有していない唯一の領域です。ネットワーク、ディスク、メモリなど、計算機科学のあらゆる場面でリソース共有は当たり前のことですが、AIデータセンターだけはその例外なのです。これは主にビッグテックの研究所によって主導された、知的な強さと思考の多様性における完全な失敗だと言えます。
これを俯瞰すると、ある程度の年齢の方ならお分かりだと思いますが、今日私たちが知るインターネットの前に存在していたAOLやCompuServeのようなシステムを思い出させます。それらは基本的に、後にインターネットとなるものの代替物でした。ログインして情報を得たり、人とチャットしたりすることができ、私たちが今インターネットでできることのほとんどは、こうしたクローズドなシステムの中ですでに存在していたのです。そして、それこそが今の私たちにとってのデータセンターです。それらはAIインフラが本来あるべき姿の、単なる玩具のような代替品に過ぎません。そして実際、AOLやCompuServeのようなシステムはすべて消滅しましたが、今日私たちが知るAIインフラも同様に消滅するでしょう。
では、それに代わって何を構築できるのでしょうか。私は、インターネットのようなスタイルに置き換えられると考えています。これはAlexが話していたこととまったく一致します。DeepMindで働く人々、ケンブリッジで働く人々、Polarisで働く人々、あらゆる場所で働く人々によるブレークスルーを踏まえれば、本気で取り組みさえすれば、今すぐにでもこれを構築できるという証拠は十分に揃っています。構築できるものとは、任意のサイズのモデルを立ち上げられる、オープンでスケーラブルなリソースのネットワークです。それこそがAIインフラであり、素晴らしい特性を備えることになります。
これと合わせて申し上げたいのは、私たちには「くさび」を見つける必要があるということです。人々が変わらなければならない強力な理由を見つける必要があります。私が非常に注目している、ある意味当然とも言えるくさびの一つが、AIインフラがデータと計算資源の確保に苦戦しているという事実です。私たちはそれらを使い果たしつつあります。現在典型的に学習に使われているデータ量は、数字はやや変動しますが、15兆トークン、35兆トークン、50兆トークンといったところです。しかし、学習に使われていないデータすべてを考慮すると、推定は難しいものの、およそ2000兆トークンほどあると見積もられています。このリソースの圧倒的な差こそが、私たちが準備を整え、説明し、十分な証拠を示せば、人々を変化へと突き動かす本当の要因になるはずです。なぜなら、この規模のデータにアクセスできれば、誰にも打ち負かせないような素晴らしいモデルを作れるからです。それこそが、人々がこのネットワーク型のスタイルへと向かう理由になるのです。
この使われていない大きなデータの塊は、すべてが非公開というわけではありません。「それはすべて非常にプライベートだから、解放するのは非常に難しいだろう」というフィードバックを時々もらいますが、それは完全な誤解です。未使用データの多くは非公開のものではなく、単にアクセスするのが難しく、データセンターに取り込みにくいというだけなのです。それは工場にあるデータであり、IoTデバイスにあるデータであり、車にあるデータであり、ドライブレコーダーにあるデータです。あらゆる気象ネットワークにあるデータも、絶え間なくデータを収集し、まるで消火栓のように大量に流し込んでいます。こうしたデータのすべては、それほどプライベートなものではありません。たとえば気象データは特にプライベートではありませんが、Geminiをはじめとするどんな最新モデルの中にも、それは見当たりません。データセンターに取り込むのが難しいからです。
同じことが計算資源についても言えます。世界中のGPU計算資源をすべて合わせても、それは非常に特殊な種類の計算資源だけを使うと私たちが決めてしまったために生じている「小さな計算資源」に過ぎません。高速に接続されていないもの、CPUであるもの、その他何であれ、AIインフラの外側にあるものはすべて完全に無視されています。計算資源の希少性もまた、データの希少性とまったく同じように、私たちが計算資源をどう活用するかを決めた結果として生じている、いわば人為的なものに過ぎないのです。
2. 発明し続けること
2.1 Sonic Boomプロジェクトと体系的分析の必要性
ここで少し話を戻したいと思います。10分ほど話してしまったでしょうか。大丈夫ですね、戻りましょう。次に何を話すべきかということですが、私たちには体系的な分析を行う切実な必要性があると考えています。ストリートファイターで遊んだことがあるくらいの年代の方なら分かってもらえると思いますが、私たちにはこの分野を体系的に整理する仕事が求められています。素晴らしい論文はすでにたくさんあり、それらは似たようなことを共通して言っていますが、細部に踏み込むと多くの疑問が残っています。どのアウターオプティマイザーを使うのか、どのインナーオプティマイザーを使うのか、それをどうパラメータ化するのか、適切なハイパーパラメータは何なのか。こうしたことはすべて、まだ流動的な状態にあります。
そこで私たちは、Sonic Boomというプロジェクトを立ち上げることにしました。名前は変わるかもしれませんが、大きな目標としては、1000億パラメータ規模の学習runをオープンな形で行い、そのrunに関するすべての詳細、すべてのハイパーパラメータ、すべてを公開したいと考えています。これをHugging FaceとFlowerと共同で進めており、実際に主導するのはAndreです。実際には、これは個々のカードを並べるようなものではなく、比較的大きなデータセンター同士、少なくともアカデミアや小さなスタートアップにとっては大規模と言えるようなデータセンター同士をネットワークで結び、それによって何が可能になるのかを検証する取り組みになります。これは、昨日Percyが話していた完全な透明性の必要性という考え方と非常に近い精神に基づいています。
大きなrunを実現するためには、当然ながら多数の小さなrunを積み重ねる必要があります。この取り組みの中で最も価値があるのは、設計空間を体系的に探索する一連のrunを行い、それを一つひとつ公表していくというコミットメントそのものだと考えています。なぜなら、これによってこの分野に関わるコミュニティが物事の方向性を理解できるようになるだけでなく、同様のrunを行いたいと考えている人々が、そのハイパーパラメータをそのまま活用できるようになるからです。すでに用意されている集中型学習のレシピがある以上、人々は自分でハイパーパラメータを探索することはしないでしょう。しかし、非常に明確なレシピを提供し、彼らの研究のベースラインとしてそのまま使えるようにできれば、人々は使い始めてくれるはずです。これがこの取り組みが重要である理由です。この件についてはFerdinand Monと協力して進めており、どこまで到達できるか見てみたいと思います。
2.2 現場からの批判的フィードバック
発明し続けるということに関連して、私たちの経験についてもお話ししたいと思います。私たちはこれまで多くの論文を発表し、多くの学習runのデモンストレーションを行ってきましたが、その一方で大きな反発も受けてきました。ここで、皆さんの関心を引きそうないくつかの匿名化された声を紹介したいと思います。かなり強力で、なかなか到達するのが難しい結果を人々に見せたときに得られたフィードバックです。相手はビッグテック企業やビッグスタートアップで働く人たちです。
一つ目は、「分散化された学習は、決して従来通りに学習されたモデルほど良くはならない。だから、わざわざやる意味があるのか」というものです。これは、モデルの品質がこうした人々にとって本質的に重要であることを示しています。二つ目は、「フェデレーテッドラーニングは小規模なモデルにしか通用しない」というものです。これらの手法がスケールアップできることを示すことも、この人たちにとっては非常に重要だということです。そして三つ目、これは特に興味深いのですが、「データが極めて機密性の高いものでない限り、これは常に大きなオーバーヘッドを伴い、実用性がない」というものです。このフィードバックが指しているのは、彼らがオーバーヘッドによってこの手法が潰されてしまうか、あるいは集中型学習との差があまりに大きく、割に合わないと本気で考えているということです。そしてそれは、本当にプライバシーが必要とされるほどデータが機密である場合にしか、動機づけにならないとも考えられているということです。
だからこそ、発明し続けることが重要だと思っていますが、同時に、先ほど挙げたその他の要素、つまり使いやすくすること、ネットワークを構築すること、モデルを構築すること、そして人々の困りごとを解決することも、私たちが成功するためには欠かせない要素になると考えています。
3. 使いやすさとオープン性
3.1 Flower Labsとツールキット思想
ここで、私たちが使いやすさとオープン性にどう取り組んでいるかをお見せしたいと思います。ちなみに、これから示すリストは、私が今まさに考えていることをそのまま公開するものです。ですから、このワークショップで皆さんがこれを見て、「ニック、こういうことも考えるべきだ」とか「私も同じようなやり方でこれをやろうとしている」といった声をかけてもらえたら嬉しいと思っています。透明性を大切にしたいという動機から、あえてこの状態のまま共有しています。
使いやすくオープンにするための一つの方法として、私が取り組んでいるスタートアップFlowerがあります。Flower Labsはしばらく前から存在しており、フェデレーテッドラーニングの分野でよく知られていますが、完全にオープンソースであり、近年ではさらに広く「協調的超知能」の実現を掲げるミッションを持っています。私たちがこの会社を設計した一つの方針は、すべてをオープンソースにし、この分野に新しく入ってきた人にとってもとても使いやすくするということです。これを取り上げているのには二つの理由があります。一つは、学生や研究者に、単に手法を発明するだけでなく、それを採用しやすい形で発明することの価値を伝えたいということです。少ないハイパーパラメータで構築できるか、既存のエンベディングや既存のアーキテクチャとそのままインターフェースできるか。こうしたことは、私たちがこの障壁を乗り越えるうえで同じく重要な要素になります。
Flowerで行ってきた取り組みの一つは、分散化やフェデレーテッドなスタイルのネットワーキングを使う「灯台」となるような事例を見つけることです。学習にまつわること、つまりリソースをネットワークでつなぐ必要のあるあらゆる取り組みが対象です。
私たちがツールを構築する際の姿勢についても触れておきたいと思います。分散化やフェデレーテッドな学習を人々に行わせるためのツールをFlowerで構築するとき、私たちの姿勢は、フェデレーテッドに十分だとされる一連のライブラリを寄せ集めただけの「フレームワーク」を作ることではありません。セキュアアグリゲーションのような要素や、その他の構成要素を単に揃えるだけではないのです。私たちの姿勢は、問題を解決するためのツールキットを作るというものです。図の上部に示したような、フェデレーテッドなパイプラインを構築しようとする人が乗り越えなければならないさまざまな障壁を、そのまま置き換えられるような、使いやすいツールキットが必要なのです。実際によく起こるのは、人々が従来のフェデレーテッド対応フレームワークの枠を超えた別のツールを使わざるを得なくなるということです。差分プライバシーを別途実装しなければならなかったり、モデルを圧縮しなければならなかったりと、その道のりは非常に入り組んだものになってしまいます。
私たちの姿勢は、ユーザーにとって完全なソリューションとなるような形でツールを構築することであり、単にこれらを実装するだけの従来型のライブラリを作ることではありません。モデル圧縮のような機能をツールの内部に組み込んだり、デプロイ前にシミュレーションできる機能を組み込んだりします。それが、これが一つの実践方法です。
3.2 Star Cloud協業と既存エコシステムとの互換性
使いやすくするためのもう一つの取り組みとして、既存のツールエコシステムとの互換性を重視しています。たとえば、誰かがFlowerを使って分散化された学習runを行うとき、その人はWeights & Biasesを使ってその学習runをモニタリングすることもできますし、すでに使い慣れている十数種類の既存の集中型ツールのどれかを使うこともできます。学習run自体は従来とは異なるものであったとしても、その人にとってのワークフローはできる限り標準的なままであるようにしたいと考えています。
灯台となる事例の一つとして、Star Cloudとの協業を挙げたいと思います。私たちが彼らと協業を始めたのはおよそ18か月前のことで、当時Star Cloudのことを知っている人はほとんどいませんでした。しかし、私たちは彼らと共同で、実際の1つのノードが宇宙空間の衛星上で稼働するという、初めての分散型学習によるVITの学習runを達成するというマイルストーンに到達しました。そしてこれは、彼らが1億7000万ドルの資金調達ラウンドを行い、評価額が10億ドルを超えたのとちょうど同じ時期に重なっていました。オープンで使いやすいものにすること、そしてこうした灯台となる事例を示すことが、人々に確信を持たせる一つの方法だと考えています。
4. ネットワークの構築とモデルによる実証
4.1 Europe Supergridによるネットワーク構築
ネットワークについてお話ししたいと思います。すでにAlexが一つのネットワークを構築しつつあることを示してくれていますし、これは非常に重要な要素だと考えています。ただ、私はこの分野に関心を持つ研究者にも、さまざまな形でネットワークを形成していく機会があると思っています。人々にこれらの技術に関心を持ってもらい、実際に使ってもらい、それに触れてもらうためです。そういう意味では、唯一無二の支配的なネットワークが一つできるということにはならないと思います。むしろ、従来のオープンソースや研究者主導のやり方のように、これらの技術を使った多くのネットワークが数多く形成される方が良いと思っています。ただし、単に研究を続けるだけでなく、自分自身の人脈、共同研究者たちとのつながりを使って、実際にこれらの技術を使い始めることが必要だと考えています。
先ほどお見せした初期のインターネットの落書きのような図には、ノードが4つほどしかありませんでした。今、オープンソースで利用可能なものを踏まえれば、誰でも、たとえば大学内の3人の共同研究者からなるネットワークを作り始めることができます。仮にすでに2つか3つの大学と共同で研究に取り組んでいるとしたら、この会議が終わった直後からでも、分散化を行う既存のオープンソースのツールを使って、使っているGPUをすべて共有するための小さなネットワークを作り始めることができます。こうして自分たちでこれらの技術を実際に使ってみることを通じて、多くの人々をその仕組みや考え方に触れさせることができます。そしてこれこそが、私たちがこれらの考え方を広めていくための重要な手段になると思っています。
私たちが構築を試みているネットワークの一例が、ヨーロッパ各地のGPUデータセンターをつなぐネットワークです。Flowerでは、これを「Europe Supergrid」と呼んでおり、基本的には先ほど述べたクラブと同じような考え方に基づいています。ヨーロッパの各HPCセンターに所属する人々が、それぞれ数週間分、あるいはいくらかの数のGPUを共有し、それらを一つに束ねることで、たとえばH100同士が互いに通信し合うといった規模の協調的な学習runを実行できるようにするクラブです。現時点でのコミットメントは決して大きな計算資源量ではありませんが、こうした技術を使ってネットワークを構築し始めることで、この分野の採用を加速させることができると考えています。これは、すべてのアカデミアやオープンソースに関わる人々が、前進のための一つの方法として考え始められることだと思っています。
4.2 LizzieモデルとSandia協業による実証
ネットワークの構築と並んで、モデルを構築することも見過ごすべきではないと思っています。もうすぐ素晴らしい学習runが行われそうだという話も耳にしていますが、私たち自身もこのことに気づかされました。私たちはさまざまな人々にこれらの技術について話をし、実際に試してもらいたいと思っていたのですが、彼らからもっとも多く聞かれた質問は、「試すことはできるのか」「そのモデルをテストすることはできるのか」というものでした。そして往々にして、話をしているプロジェクトのモデルはまだ完成していないという状況でした。つまり人々は、これらの手法を使ってポストトレーニングや安全性の作業まで含めて完全に仕上げられたモデルの実例を見なければ、一歩を踏み出そうとは思わないのだということです。
そのため、およそ2週間前に、私たちはLizzieというオープンウェイトモデルをリリースしました。これは、こうした取り組みの実例として、特定の用途向けに完全に作り込んだモデルをリリースし、それが問題を解決するだけでなく、採用の加速にもつながるかどうかを見てみようという試みです。Lizzieは興味深い事例だと考えていますが、こうした重要なニッチを埋める例は他にも多く作れると信じています。
Lizzieは完全に英国内で構築されており、英国社会や英国的な価値観に沿うよう、少なくともその地域にふさわしい回答をするようにポストトレーニングされています。デモをお見せしようと思っていたのですが、時間の関係で割愛します。ただ、慎重に選定した一連の下流タスクにおいて、Lizzieを他のいわゆるソブリンな欧州系モデルと比較すると、かなり良好な結果を示しており、同等か、やや上回る結果になっています。これは二つのことを示しています。一つは、こうした考え方に基づくアプローチが実際に機能し、有用なモデルを得られるということです。もう一つは、英国らしさに向けてポストトレーニングを行ったことが、全体的な汎化性能をそれほど損なっていないということです。これは、私たちがモデルを構築することでこの動きを加速させようとしている一つの例です。
こうした「これを証明するためにモデルを構築する」という新たな姿勢のもう一つの例が、米国のSandia National Labsとの協業です。米国には、エネルギー省がすべてのデータと計算資源を集約し、興味深いモデルを立ち上げるというGenesisと呼ばれる大きな構想があります。これがどこまで進むのかは分かりませんが、私たちはSandia National Labsと協力して、700億パラメータ規模のモデルの学習runを実施する取り組みを進めています。この場合、彼らは従来型のデータを使った70Bモデルの学習を望んでいますが、それによって自分たちのインフラでこの手法が機能することを証明したいと考えています。彼らのインフラはかなり複雑なものです。エネルギー省ならではの事情として、多くのファイアウォールが存在し、あるノードは別のノードと通信できないといった方向性の制約のような、さまざまな課題があります。彼らはこれまで集中型の学習をあまり行ってこなかったため、多くの教育的な取り組みも必要になりますが、非常に刺激的なプロジェクトです。ここでもやはり、このアプローチを広めていくためにモデルを構築するという目的でモデルビルディングに取り組んでいる例だと言えます。
5. ペインポイントの解決、まとめと質疑応答
5.1 学術界のペインポイントと戦略のまとめ
最後に、私たちが検討すべきだと思うのは、人々をこの考え方に頭ごなしに勧誘しようとするのではなく、勝ちを得るという発想です。それは、実際に強い痛みが存在している具体的なペインポイントを特定し、こうした種類のアプローチで解決できる部分を見つけるということです。昨年のICLRに参加されていた方はご存じかもしれませんが、あるキーノートスピーチで、学術界がいかに深刻な計算資源の制約を抱えているかという話がありました。学術機関では、部門ごとに異なるGPUクラスタを持っていることも多く、共同研究者ともそれぞれ別のリソースを持っています。そのスピーカーは、こうしたリソースを一つにまとめる方法さえあればと語っていました。これはまさに、私たちが取り組める一つの例だと思います。これらの手法をカスタマイズしたプロトタイプとして構築し、学術関係者が単純にリソースを共有するために使えるようにすることができるはずです。それは、この種の手法についての知見や経験を広めていくための優れた方法になると思います。
他にも考えられる例としては、大規模な学習runを行う人々が日常的に多くの障害に直面しているという問題があります。これはMetaから提供された、学習runにおいてさまざまな箇所で障害が発生したことを示すデータです。私たちが議論しているこの種の手法は、本質的にはるかに高い耐障害性を持たせることができます。ですから、こうした障害への耐性を動機として、目的に特化した仕組みを構築したり、あるいは私たちのツールや技術がこうした状況下でもきちんと機能するようにしたりすることも、取り組むべき選択肢の一つだと思います。あるいは、さまざまな種類のGPUを横断して連携できる能力を動機とすることも考えられます。これらは、多くの人々の関心を引きうる三つの異なるペインポイントであり、彼らは分散化そのものには関心がなくても、こうした特定のシナリオを解決することには強く動機づけられるかもしれません。ですから、この中から一つを選ぶこともできるはずです。
つまり私が申し上げたいのは、一つを選び、その問題を非常にうまく解決するソリューションを構築し、そのユーザーコミュニティを獲得することで、この分野への関心を裏口から広げていくことができるということです。
5.2 総括と質疑応答
時間の管理があまりできていなかったかもしれませんが、そろそろ終わりに近づいていると思います。皆さんからの質問や議論をとても楽しみにしていますが、まとめとして、ここに挙げた5つの方向性が、今日のこの規模のワークショップを、たとえばICMLのように10倍の規模へと広げていくための助けになると考えています。皆さんがどう考えるか、とても興味があります。聞いていただき、ありがとうございました。
ここから質疑応答に移りました。
Q. 先ほどお見せしたEurope Supergridのスライドについて、あれは使ってよいものなのでしょうか。 A. はい、いくつかのルールに従う形であれば使えると思います。
Q. では、それは誰が所有することになるのでしょうか。 A. それは、いくつもの問題を一度に解こうとしていると思います。長期的な利用のためには所有権に関する疑問がいくつか生じるかもしれませんが、この構想の狙いはあくまでリソースを組み合わせ、学習runのデモンストレーションを行うことで、これが実現可能であることをさらに実証することにあります。長期的で持続可能な本当のインフラを作るという話ではありません。
Q. Lizzieというこのモデルは、どのように学習したのでしょうか。フェデレーテッドな手法を使ったのですか。 A. 私たちがそのモデルをどのように学習したかについては、まだお見せする準備ができていません。ただ、私たちの論文をすべて読んでいただければ、かなり良い見当はつくはずです。正確にどのように行ったかについては、まだ詳しく説明したくないと思っています。仕上げを終えてから、それを公開したいと考えています。
Q. とても興味深いお話でした。技術的な部分についてはまた別途発表があるかと思いますが、一点だけ伺いたいのは、「集中的」とおっしゃるとき、それは技術的には対話的な手法、いわゆるダイロコのようなものなのでしょうか。 A. いいえ、essentially(本質的には)、これは一つのデータセンター内で非常に高速な接続によって密に同期されたGPU群によるDDPです。
Q. なるほど。では手法としては、すでに公表されているダイロコのような方法をお使いなのでしょうか。それとも、ご自身が言及されていたような、データパラレルな手法を独自にお使いなのでしょうか。うまく質問できていなければすみません。 A. 大丈夫です、問題ありません。それはケースによります。私たちはさまざまな設定でさまざまな実験を行ってきましたが、私たちが発表しているエンプティ・ダイアル(empty dial)論文をご覧いただければ、ローカルオプティマイザーとアウターループオプティマイザーを持ち、アウターオプティマイザーがより少ない状態量だけを交換できるようにする方法を提案していることが分かります。具体的には、異なるタイムスケールで異なる種類の状態を交換するという方法です。基本的には、何を、いつ交換するのかについて意図的な設計を行い、その上で収束性を示すというアプローチを取っています。理論的には収束性の証明を拡張する形で示し、実証的にもそれが機能することを示しています。ただ、これは基本的にはローカル学習と同じ設計空間の中にある話であり、私たちが話しているのは、あくまでクラスタや単一のGPU群が多くのローカルな作業を行い、その上にアウターループがある、つまり基本的にはフェデレーテッドラーニングそのものだということです。私たちは、このパラダイムの中で考えているのです。
Q. 非常に興味深い研究ですね、ぜひ確認させてください。 A. ぜひどうぞ。