DruckFin

Googleトランスクリプト：TPU、分散システム、フロンティアAIモデルの共同設計

Google Dev Labs ファイヤーサイドチャット：ジェフ・ディーン（Jeff Dean）、ビル・ジア（Bill Jia）が語るAIシステムのスケーリング（2026年9月20日）

はじめことばとGoogleの初期

ホスト：皆さん、ようこそ。熱意を持ってご参加いただき、本当にありがとうございます。今回で第7回目となるDev Labsですが、開催のたびにより大きく、より素晴らしいものになっています。そして今回は間違いなく過去最高です。非常に多くの関心をいただき、フィードバックにも感謝しています。本日の進め方ですが、いくつかの質問やTPUの進化についてお話しいただきます。ジェフは紹介するまでもない人物ですが、Googleの30番目の従業員です。まずはそのエピソードから始めましょう。また、ビルにも参加してもらっており、質問を投げかけてもらうだけでなく、AIインフラの実行、そのビジョン、そして現在や今後数年間の実行体制について少し裏話を聞かせてもらいたいと思います。よろしいでしょうか？ それでは始めましょう。ジェフ、もう少し詳しく教えてください。あなたはGoogleの30番目の従業員でしたね。

ジェフ・ディーン：はい、そうです。

ホスト：1999年ですね。ここにいる方々のほとんどはまだ生まれていなかったか、生まれていたとしても赤ん坊の頃ですね。当時はいかがでしたか？

ジェフ・ディーン：いやあ、とても楽しかったですよ。入社当時は、パロアルト中心部にある、現在のT-Mobileの店舗の上にあるような小さなオフィスに全員が押し込まれていました。オフィス規模としてはざっとそんな感じです。そして、私たちは非常に高品質な検索プロダクトを作ろうとしていました。私は前職の情報検索、特にウェブのグラフ構造を利用してページ上の既存情報を補強する手法などで、それに触れる機会が少しありました。ですからGoogleは、より研究色の強い環境ではなく、自分の仕事が直接使われる場所でそれを試すのに自然な場所だと思えましたし、最高に楽しかったですね。エネルギーに満ち溢れており、トラフィックは毎週約7%のペースで成長していました。1.07の52乗を計算すれば分かる通り、毎年急成長しており、火曜日の正午にシステムがダウンしないよう必死でした。本当に楽しかったですね。会社が成長し続けるにつれて、より多くのことに取り組んできたわけですが、それを見るのは常にワクワクします。

ホスト：そして2001年には何が起きたのでしょうか？少し時代を進めてみましょう。

ジェフ・ディーン：システムダウンを防ぐために私たちがやっていたことの一つは、検索、インデックス作成、クエリ処理のシステム全体をより効率的にし、異なるデータ構造やコンパクトな表現を使用するように絶えず書き換えることでした。2001年に至る過程で、インデックスのサイズと、インデックス処理能力のキャパシティをどのようにスケールさせているかという点について、あることに気づきました。インデックスを巨大化させるために、インデックスをますます多くのパーティションに分割していたのです。私たちはそれを「シャード」と呼んでいました。そして、より多くのクエリを同時に処理するキャパシティを提供するため、そのシャードごとにコピーをどんどん増やしていきました。最終的には、7つのシャードにそれぞれ10コピーずつではなく、すべてのデータセンターで60のシャードと、それぞれ20コピーを持つような状態になりました。そしてある時計算してみて気づいたのですが、インデックスをディスク上に置く代わりに、もし20コピー×60パーティション分となるはずの1,200台のマシン上に、ウェブのインデックス全体をメモリに載せることができると分かったのです。本当に面白かったですね。検索システム全体が3日間で約4倍に高速化されました。とても楽しかったですよ。

TPUの誕生：音声認識からカスタムASICへ

ホスト：そして2013年には、簡単な概算（バック・オブ・ザ・エンベロープ）計算を行いましたね。

ジェフ・ディーン：はい、そうです。深層学習（ディープラーニング）のトレーニングインフラと、深層学習モデルのトレーニングに取り組み始めました。それが正しい抽象化だと思えたからです。実は私は学部生の頃、1990年にニューラルネットに触れる機会があり、学部論文としてニューラルネットの並列トレーニングをテーマに選びました。なぜなら、「これこそが正しいやり方だ。1台ではなく32台の非力なプロセッサーを使えば、驚異的なモデルをトレーニングできるはずだ」と感じたからです。もっとも、32台どころか、私たちが必要としていたのは数百万倍もの計算能力だったことが分かりましたが。しかし、ムーアの法則の進歩などを経て、2008年か2009年頃からそれが徐々に現実のものとなり始めました。そして2011年、音声、ビジョン、言語向けモデルの分散トレーニングを本格的にスケールさせて実行するプロジェクトを立ち上げました。当時、私たちのデータセンターにはCPUがたくさんありました。多くのCPUです。そこで約16,000基のCPUコアを使用して大規模なビジョンモデルをトレーニングしたところ、驚異的な改善が得られました。音声モデルでも同様の事を行い、モデルの品質が劇的に向上しました。深層音響音声モデルを構築しようと試みた2か月の間に、単語誤り率の改善という意味で、過去20年分の音声研究に相当する成果が得られたのです。これには「これはとてつもなく凄いことになるぞ」と思いました。しかし、どうやってそれをサービング（推論処理）すればいいのか？

当時、私は次のような計算をしました。「もし1億人の人々が毎日数分間スマートフォンに話しかけ始めたら、どうやってそれを処理すればいいのだろうか？」と。判明したのは、Googleが所有するコンピュータの数を倍増させなければ、Googleのほんの小さくて目立たない一部の部門においてすら、より優れた音声認識モデルを展開できないということでした。それは非実用的であることは言うまでもなく、少し過剰すぎると感じました。そこで、専用ハードウェアこそが取るべき道だと判断したのです。それがTPUファミリーの原点です。私たちは、低精度の線形代数演算だけを極めて得意とする、それ以外の機能を持たない専用アクセラレーターを構築したかったのです。それによって音声モデルやビジョンモデルなどをはるかに効率的にサービングできるようになりました。2015年にチップが完成した時点で、当時の一般的なCPUやGPUと比較して、ワットあたり30倍から80倍もの優れたパフォーマンスを発揮することが判明しました。それが最初のイテレーションでした。

ビル・ジア：そうですね。TPU v1は推論を主なターゲットにしていましたよね。そしてその後の世代では、主にトレーニングと推論の両方をターゲットにするようになりました。さらに最近では、トレーニングと推論の性質が多少異なるため、再びそれぞれの路線を分化させ始めています。

ホスト：2017年に論文を発表された際、それが採択されましたね。50年の歴史において最も広く引用されている論文となっていますが――

ジェフ・ディーン：はい、ISCAの歴史においてですね。TPU v1に関する論文は多くの著者によるもので、おそらく35人ほどの著者がいたと思います。コンピュータアーキテクチャの50年の歴史において比較的新しいものであることを考えると、喜ばしいことです。

TPUアーキテクチャ、ソフトウェアスタック、光スイッチングの進化

ビル・ジア：Googleはこれまで最高峰のソフトウェア企業と見なされていながら、ハードウェアのロードマップを推進し始めたというのは本当に驚くべきことです。そしてハードウェアを手がけるというのは一筋縄ではいきません。TPUを素晴らしいものにするためには、多くのボード設計、チップセット設計、そしてTPU自体の設計が必要だからです。それに加えて、コンパイラやフレームワークを非常にうまく機能させる必要もあります。初期の頃、あなたはTPU用コンパイラであるXLAやTensorFlowを強力に推進されました。TPUのためのこのソフトウェアスタックを推進した初期の歩みについてご紹介いただけますか？

ジェフ・ディーン：機械学習の開発者や研究者として私たちが求めるのは、単に自分の高水準なアイデアを表現できれば、優れたパフォーマンスを引き出すために水面下で行わなければならないパフォーマンスチューニングの細かい部分を過度に意識することなく、大規模システム上でそれが魔法のように実行されることだと思います。そのためには、優れたコンパイラ、非常に優れたインターコネクト、そして、「自分のローカルマシンの4つのチップと通信しているのか、それとも大規模分散セットアップの1万個のチップと通信しているのか」という抽象化を表現できるフレームワークが必要です。開発者はそうした違いをあまり意識したくありませんし、両者の環境で別々のやり方をしたくもないわけです。

ホスト：さまざまなTPUのイテレーションと、それが向かう先についてお聞かせください。

ジェフ・ディーン：はい。スロットに収まるPCIeカードに過ぎなかったTPU v1の後――当時、どう使うかも分からずに大量に購入したのですが、当時のCFOのところへ駆け寄り、「これらは大量に買う必要があります、どう使うかは決まっていませんがとにかく使いますから、どうかたくさん買わせてくれませんか？」と頼み込みました。そして実際に大量購入しました。その後、TPU v2は、トレーニングを念頭に置いて設計された最初のシステムとなりました。単一のチップではなく、2Dトーラスで相互接続された多数のチップによるスーパーコンピュータのようなシステム全体として設計されたのです。世代を経るごとに、TPU v3からは液冷を導入しました。システムのチップ表面に配管が張り巡らされるのは常にワクワクするものですが、水漏れは決して良いことではありません。

そしてTPU v4では、ポッドのサイズを拡大するにつれて――TPU v2やv3では256チップ間、1,024チップ間で固定配線されていましたが――システムがより大規模化するにつれて、個々のチップやボード、システムで障害が発生し始めます。何か一部が故障したとしても、はるかにより大規模なポッドのトポロジ全体を引き続き利用できるようにするため、より耐障害性（フォールトトレラント）を高める必要がありました。そこでTPU v4では、マシンラック間に光再構成可能ネットワークという概念が導入されました。

ホスト：つまり、データセンターのフロア全体からレゴブロックのように組み立てることができるわけですね？

ジェフ・ディーン：データセンター内の多くの通路に散らばっているにもかかわらず、これら8つのラックあたかも隣り合っているかのように見せる、微小調整可能なミラーを備えたユニークな小型スイッチを用いて実現しています。これが非常に役立っています。TPU v5、v6、v7はいずれも、計算フォーマットの精度をさらに低下させる（低精度化を進める）ことで非常に大きな効果を上げています。それによりはるかに高いパフォーマンスが得られますが、16ビットのFLOPSもあれば、8ビットや4ビットのFLOPSもある中でFLOPSを比較するのは常に奇妙なものです。機械学習アルゴリズムで活用できれば、低精度なものほど、さらなるパフォーマンスを引き出すための素晴らしい手段となります。

Pathways：不規則性のオーケストレーションと大規模分散トレーニング

ホスト：最初のTPUが2015年で、2017年に論文が発表され、今や伝説となっています。そして2018年には「Pathways」が登場しました。Pathwaysについて、そしてなぜそれがそれほど重要なのかについて少しお話しいただけますか。

ジェフ・ディーン：はい。Pathwaysの開発を始めたのは、より不規則でスパース（希薄）なモデルのトレーニングに対応するためでした。また、大規模な分散トレーニングシステムを駆動する単一のプログラミングモデル、単一のプロセスを私たちが利用できるようにするための基盤となるシステムインフラとして構築しました。プログラマーの立場からすれば、単一のPythonプロセスがまるで8,000台のデバイスが接続されているかのように見え、「素晴らしい、8,000台のデバイス全体でAllReduceを実行したい」と指示するだけで、特に特別なことをしなくてもそれが実行される方がはるかに快適です。

XLAコンパイラなどの基盤ソフトウェアがその一部を処理し、さらに少し高いレイヤーでは、Pathwaysが多数の異なるチップ間でのデータ移動をオーケストレーションします。同じTPUポッド内のチップであれば、通信が必要な場合にはTPUポッド内にあるICI高速リンクが使用されます。しかし、複数のポッドにまたがる処理が必要な場合や、あるポッドのこのチップから別のポッドのあのチップと通信する必要がある場合には、データセンターネットワーク、あるいはオクラホマ州、テキサス州、アイオワ州などのポッドにまたがるトレーニングジョブを繋ぎ合わせている場合は広域ネットワーク（WAN）を使用して、Pathwaysがその転送をオーケストレーションします。これにより、「自分には大量のコンピューティングリソースがあり、システムに最善の使い方を任せる」という優れた抽象化が提供されるのです。

ハードウェア・インフラストラクチャとのGeminiモデル共同設計

ビル・ジア：素晴らしいですね。ジェフ、あなたはごく初期の頃からTPUのネットワーク設計やTPU自体の設計、コンパイラやフレームワーク、そしてデータ移動全体やネットワークトラフィックの再構成などをオーケストレーションするPathwaysに至るまで、深く関わってこられました。これらはすべてAIインフラストラクチャのスタックです。そして現在、あなたは現在のGeminiモデルや将来のGeminiモデルの設計にも深く関わっておられます。これにより、Geminiモデルはインフラストラクチャスタック全体と共同設計（コデザイン）することが可能になっています。あなたの視点から見て、すでにどのようなメリットが得られていますか？ また、モデルの最先端の境界を押し広げていくために、将来に向けてどのようなお考えをお持ちでしょうか？

ジェフ・ディーン：TPUの歴代世代はすべて、私たち自身がMLコンシューティングの大規模なユーザーであり、既存のワークロードとは異なる形でハードウェアに負荷をかけるかもしれない新しい研究アイデアの限界を押し広げようとする多くの人々を抱えているという事実から、多大な恩恵を受けてきました。Alphabetという1つの屋根の下ですべてが揃っていることにより、将来のTPU世代の設計者、コンパイラやインフラのソフトウェア設計者、そして「この手法は小規模ではうまく機能しているようだが、1年後や2年後の大規模な将来のトレーニング実行において極めて重要になると考えており、ハードウェアに確実に実装してほしい」と主張できる機械学習研究者との間で、非常に多くのインタラクションを行うことができます。

コンピュータアーキテクチャの設計者が、自分が今設計しているチップが関連性を持たなければならない2年〜6年の時間枠の中で、急速に変化するAI分野がどこに向かっているのかを孤立した状態で推測しようとするのは非常に困難です。だからこそ、「このアプローチなら機能するはずだ」という洞察や、より多くのイテレーションを得られることが重要なのです。それは単に「こうする必要があると思う」という一方通行ではなく、ハードウェア担当者が「それは難しいが、こういうやり方ならできる。それが役に立つか？」と問いかけ、「はい、それであればまさにこの機能に非常に近いもの、あるいはそれ以上のものを実現できるようになります」というようなキャッチボールが生まれます。これは効果的な共同設計を行う上で極めて重要です。

大規模な信頼性：10万基のTPUにわたるGoodputとフォールトトレランス

ビル・ジア：昨日、私はオープニングの壇上で、Geminiモデルをスケールアップさせていくにつれて――思い返せば、私たちは毎月のように信頼性について話し合う同じ会議に同席していました。私はインフラ側を担当し、ジェフはGoogle DeepMindを代表しています。「Geminiモデルはますます巨大化しており、モデルのトレーニングに膨大な数のTPUを使用することになる。最終的には10万基のTPUを使ってモデルをトレーニングする」と。そこで私たちが共に注視している指標が1つあります。「Goodput（実効スループット）」です。Goodputです。

初期の頃、私たちのGoodputは芳しくありませんでした。一緒に話し合ったことを覚えています。「Badput（無効な稼働時間）がGoodputを圧倒している」と。最初は60%程度でした。モデルの事前トレーニングに向けてより多くのTPUをスケールさせていくにつれ、状況は非常に複雑化しました。より大規模なスケール、より多くのデータ、より高度な並列処理が必要になります。Goodputは当初50%、60%、70%ほどでしたが、それでは到底不十分でした。しかし、要するに、現在では大規模なトレーニングインフラを活用して、はるかに複雑なモデルをトレーニングしており、Goodputは95%、さらには98%にまで高めることができています。

ジェフ・ディーン：はい、それは実際には、優れた運用プラクティス、デプロイ時のチップに対するより厳格なQAテスト、障害にうまく対処してシステムの1パーツがダウンしていても前進し続けられるソフトウェアなど、さまざまな要素の組み合わせによるものです。これらすべての要素が合わさることで、大きな違いを生み出しています。

ビル・ジア：モデルを自社で所有し、データを所有し、さらにハードウェア、ネットワーク、すべてのソフトウェアスタック、そして運用チームまでを自社で所有していることも、大きな強みだと思います。

ジェフ・ディーン：非常に重要だと言えます。もしTPUの個別のトレイについて、それがより大きなシステムの一部であると考えないならば、「まあいいか、1週間後に巡回した時に修理すればいいか」と考えてしまうでしょう。しかし、それが使用中のポッドの一部であり、内部に壊れたトレイが含まれている場合、影響範囲が想像よりもはるかに大きいため、すぐに修理しに行かなければならないのです。

オペレーションの調整とサイレントデータ破損の軽減

ホスト：そしてビル、昨日あなたのキーノートでもOCSとJupiterに関して少し触れられていましたね。それらが信頼性にどのように寄与しているのかについて、少しお話しいただけますか？

ビル・ジア：はい、長い道のりがありました。まず第一に、1万基のチップごと、あらゆるパーツごとに、1日あたりどれだけの割り込み（インターラプト）が発生しているかを監視しました。それを最小限に抑えなければなりません。トレーニングクラスターをスケールアップする際に割り込みが多すぎると、非常に好ましくないからです。私たちが最初に行ったことの一つは、ハードウェアの信頼性の向上です。それだけでなく、昨日も言及しましたが、事前トレーニングが始まる前でさえ、ソフトウェアがフリート全体、つまりすべてのコンポーネントをスキャンして「バイタルサイン（健康状態）はどうか」を確認します。もしバイタルサインに問題があれば、トレーニングが始まる前にそれを修理するか、あるいは除外します。これが第一段階です。

第二段階：トレーニングが開始されます。しかしトレーニングが始まると、ハードウェアのバイタルサインが非常に良好であっても、トレーニングは数週間に及ぶため、依然として問題が発生する可能性があります。どの特定のコンポーネントやサーバーに問題があるのかを特定し、それを修正、除外、あるいは交換して解決するにはどうすればよいか――これが第二段階です。

またジェフが言及したように、多くのオペレーション上の調整も存在します。データセンター側がデータセンターの特定の行の電源をメンテナンスしているまさにその時に、その行がトレーニングを実行していたとしたら、当然ながらそれは非常に好ましくありません。そのため、データセンターのセットアップ担当者、SRE（サイト信頼性エンジニア）、そしてすべてのML研究者やエンジニアの間で密接な調整を行っています。同期を保つ必要があるため、多くの調整が必要です。

さらにジェフは、Geminiモデルの設計やソフトウェア設計の面でも多くの主導権を握っています。時には障害が発生することもありますが、トレーニング自体はデータ並列性とモデル並列性を組み合わせて行われています。それが1つのデータレプリカの範囲内であれば、他のレプリカが処理を継続します。重みが自動的に平均化されるため、1つのレプリカがダウンしたことに悩まされる必要はありません。このように、非常に包括的な改善が重ねられています。何か付け加えることはありますか？

ジェフ・ディーン：いいえ。さまざまなことが起こり得ますし、あらゆる障害の発生パターンを事前に予測することは非常に困難です。そのため、何が原因で障害が起きたのかが必ずしも明確でなくとも、障害を検知できる堅牢なシステムを構築することが重要です。時折、例えば温度が上昇した際にチップの信頼性に問題が生じ、「2＋2を計算したら5になった」といった現象が発生することがあります。

ビル・ジア：それが最も厄介な「サイレントデータ破損エラー（SDC）」ですね。本当に恐ろしいエラーです。

ジェフ・ディーン：はい。それはチップ自体で発生することもあれば、不安定なネットワークリンクで発生することもあり、様々な場所で起こり得ます。私たちはGoogleの初期の頃と同じ原則の多くを活用しています。当時、私たちは安価なコンシューマー向けPCを購入していたため、それらのPCにはECC（誤り訂正メモリ）すらないだけでなく、メモリのパリティチェックすらないものもありました。そのような環境で大量のコンピュータを使用して処理を行うと、メモリ内にランダムなビットフリップ（反転）が発生します。私たちが行った計算の多くは、ビットフリップに対して堅牢である必要がありました。そのためのアプローチの一つは、「10億ページのウェブページを処理している際、そのうちの1ページをドロップしたとしても、おそらく世界の終わりではない」という割り切りです。ハードウェア層の上位にあるソフトウェアでチェックサム（誤り検知）を行うことで、特定のマシンやネットワークリンクの信頼性が低くてもシステム全体を堅牢に保つことができました。

オープンソース戦略：JAX、StableHLO、TPU上のPyTorch

ホスト：Googleはオープンソースを強く信奉していますので、ここで話題をオープンソースに少し切り替えてみましょう。聴衆の皆さんには多くのア学者やパートナーの方々がいらっしゃると思います。GoogleのAIインフラストラクチャ戦略が、リソースが一部に囲い込まれた「ゲーテッド・リソース」にならないようにするという点とどのように関連しているかについてお話ししましょう。私たちが議論してきたすべての技術を世界と共有していきたいと考えています。JAXやStableHLO、そしてオープンソース全体の進化が、これが囲い込まれたリソースにならないことを保証する上で現在いかに重要であるかについてお聞かせください。

ジェフ・ディーン：私たちにとって、より広いエコシステムと連携することは極めて重要です。ソースコードを公開し、人々がそれを見たり、修正したり、改善に協力してくれたりできるようにすること、そして私たちだけで抱え込むのではなく、多くの組織にまたがる協力的なプロジェクトにすることは非常に大切です。だからこそ私たちはTensorFlowをオープンソース化し、JAXをオープンソース化し、XLAコンパイラのためのStableHLO表現をオープンソース化しました。そして今後もさらに多くのものをオープンソース化していく予定です。私たちは長年にわたり、Linuxカーネルをはじめとするオープンソースへの多大な貢献を行ってきました。通常、私たちは共同のオープンソースの取り組みに対して最も多額の貢献を行っている組織の一つです。私たちはそれを信じており、全員が協力し合うことでエコシステム全体が恩恵を受けると考えているからです。

ホスト：PyTorchやMetaでのご経験についてお話しいただくのにぴったりの流れですね。

ビル・ジア：はい。まさにこのファイヤーサイドチャットの直前にもジェフと話していたのですが、ジェフはAIインフラストラクチャのオープンソース戦略を数多く主導してきました。ジェフが言及したように、過去においてGoogleはTensorFlowやJAXをオープンソース化し、KubernetesやAndroidなどもGoogleによって作成・オープンソース化され、数々の素晴らしい成果を生み出してきました。現在、TPUをコミュニティに普及させ、Google Cloud上のTPUを重視する中で、私たちはこのオープンソース戦略をさらに強化しています。

実際、私たちはJAXのコアをオープンソース化するだけでなく、強化学習を行うための「TuneX」（JAXコアの上に構築されています）など、多くの上位レイヤーのライブラリも構築しています。それもオープンソース化しています。チェックポイントの取得方法、推論処理の方法などについても、JAXの上位に多くのライブラリやフレームワークを構築し、それらをオープンソース化しています。人々がそれを利用し、このオープンソース戦略を活用してTPUを直接使ってもらいたいと考えているからです。これが一つ目の取り組みです。

そしてもちろん、お客様が現在いる場所（環境）に寄り添いたいと考えています。そのため、オープンソースコミュニティに存在する成熟したプロダクトも積極的に受け入れています。PyTorchは非常に成熟しており、コミュニティで広く使われています。そこで、「TPU上でPyTorchを採用しよう」ということになりました。現在、「Torch-TPU」と呼ばれるプロジェクトを進めています。現在はプライベートプレビューの段階ですが、来四半期、つまり数ヶ月以内にパブリックプレビューを実施し、第4四半期にはGitHubでパブリックオファーを行い、誰もが利用できるようにしたいと考えています。昨日も言及しましたが、Torch-TPUを使用する場合、バックエンドデバイスをTPUに指定するという数行のシンプルなコード変更だけで、トレーニングや推論のすべてがTPU上で実行されるようになります。現在は、eagerモード（即時実行モード）とコンパイルモードの両方をサポートしています。これがフレームワークレベルでの取り組みです。

また、会場の聴衆の皆さんの多くがvLLMやSGLangを使用されていることと思います。私たちはvLLMやSGLangの開発チームとも協議を行い、こうした上位のオープンソース推論フレームワークがTPU上でも使用できるように取り組んでいます。このように、自社製ソフトウェアのオープンソース化と、コミュニティにおける成熟したオープンソースプロダクトの積極的な採用の両面で、現在多くの作業を進めています。

機械学習によるハードウェア設計の自動化

ホスト：会場には修士課程1年目や2年目のPhD（博士課程）の学生もたくさんいらっしゃいますね。何人がPhDの学生でしょうか？ 彼らが注力すべきことにはどのようなものがあるでしょうか？ 学部生も混ざっていますのでお伝えしておきます。

ジェフ・ディーン：なるほど。キャリアのその段階にいるというのは常にワクワクすることですね。自分が本当に楽しみを見出せることや重要だと思えることを見つけ、世界にインパクトを与えるために何らかの領域を切り開く方法を見つけ出すことができるからです。本当に楽しい時期だと思います。

ホスト：インフラストラクチャの観点から、現在考えておられる物理的なボトルネックは何か1つありますか？

ジェフ・ディーン：数え切れないほどあります。私は、より特化したハードウェア（専門特化型ハードウェア）に対して非常に強気です。それこそがはるかに効率的なシステムを実現する手段だと考えているからです。現在、ごく少数のワークロードが世界中の計算量の大部分を占めるような状況になりつつあります。そう考えると、それは専門特化を強く求めていると言えます。しかし、専門特化における問題は、将来的にやりたいことが変わってしまった場合、愛情を込めて2年間かけてハードウェアとして作り上げたものが、おそらくもはやそれほど関連性を持たなくなってしまうという点です。

そのため、専門特化をうまく機能させるには、ハードウェア設計プロセスの大部分を自動化する必要があります。現在のハードウェア開発の進め方は、大勢のチームを編成するというものです。あるチームが高水準の仕様から低水準のRTL（レジスタ転送レベル）を構築し、手動で翻訳されたものであるため、最初のチームが正しく作業を行ったかを検証する別のチームが存在し、さらにチップを丁寧にレイアウトする別のチームが存在します。もし、強化学習やその他の進化論的手法によって検索可能な自動化ループを数多く作成でき、かつそのループを十分に高速に実行できるよう――現在のEDAツールは一般的に高速実行ようには設計されていませんが――もしそれができれば、設計プロセスの自動化された探索ループをはるかに強力に回すことができ、設計サイクルを劇的に短縮するチャンスが生まれます。

例えば、150人で2年かかる代わりに、10人で3ヶ月で新しいチップを設計できるようになれば、世界中でより多くの専用ハードウェアが見られるようになるでしょう。そして、将来への賭けの不確実性を大幅に減らすことができます。「2年〜6年後にどのようなコンピューティングをしたいか」という賭けが、「3ヶ月〜4年後に何がしたいか」という、はるかに予測しやすい賭けに変わるのです。

推論ワークロード、エージェントシステム、ツールのボトルネック

ビル・ジア：1、2年前を振り返ると、当時の業界やGoogle、そして多くのフロンティアラボの主な焦点は、「モデルを素晴らしいものにするにはどうするか」でした。事前トレーニングや事後トレーニングを機能させることに多大な焦点が当てられていたため、多くのハードウェア戦略はトレーニング側にありました。しかし現在、大規模モデルが成熟するにつれて、多くのトラフィックがエージェントの世界や推論側に移行し始めています。ジェフ、ハードウェア設計の観点から何かお考えがあれば共有していただけますか？ つまり、推論トラフィックに焦点を当て、それを重視したハードウェアをどのように設計すればよいでしょうか？

ジェフ・ディーン：推論とトレーニングは多少異なります。推論の場合、基本的にモデルがすでに存在し、それに対する大量のリクエストを処理するのが目的です。そのため、変更されない情報を移動させる量を可能な限り少なくする必要があります。変更されないものはモデルの重みであり、変更されるものはリクエストやKVキャッシュなどです。したがって、このデータ移動を最小限に抑えることに極めて特化したシステムを設計する必要があります。

さらに、単なる「プロンプトとレスポンス」の関係だけでなく、エージェントが何らかの処理を行い、ツールの呼び出しを決定し、ツールが実行され、その結果が戻ってきて、それをモデルのコンテキストに組み込んで次に何をすべきかを判断するという、より自律的なシステムへと移行していく中で、私たちは「すべてのツールが遅すぎる」ということに気づき始めています。それらのツールは人間の速度でのイテレーションに合わせて設計されていたからです。ツールのプロセスの一部としてコードをコンパイルしている場合、コンパイラが遅いことに非常にフラストレーションを感じるはずです。もし推論ハードウェアを極限まで高速にすれば、人間がコンパイルできるよりも速くコードを生成できるようになり、自分で実行するよりも確実に速くなります。

私たちが取り組んできたことの一つは、社内ツールのいくつかを高速化してより良いものにすることです。プログラミング言語間でかなり効果的に翻訳を行えることが分かっています。なぜなら、自分が行いたいことの完全な仕様がすべて揃っているからです。Pythonのようなインタープリタ言語で書かれたプログラム全体があり、Go、Rust、C++などにおける正確に同等のプログラムが欲しい場合、エージェントはそれを非常にうまく実行できます。これは、「Webサーバーを作ってほしい」とエージェントに依頼し、望み通りではないかもしれないあらゆる前提条件を含めてエージェントが詳細を埋めなければならないような、通常のエージェントとのコーディングのやり取りとは大きく異なります。完全に仕様が指定されたツールであれば、エージェントは非常に優れた仕事をこなすことができます。すべての単体テスト（ユニットテスト）を実行し、すべての単体テストを翻訳し、新しいシステムでそれらを実行し、動作を並行して検証して同じように動作することを確認できるのです。

ビル・ジア：社内でのライブの例として「Project Tern」と呼ばれるものがあります。多くのモデルがTensorFlowで構築されていましたが、私たちはJAXへの移行を進めており、すべてのTensorFlowモデルをJAXに翻訳し、すべての単体テストやコードテストを自動的に実行しています。

ホスト：ところで、NeruIPSでリジェクトされた（不採用となった）ある論文についてですが、皆さんで提出された蒸留（ディスティレーション）に関する論文で、「ほとんど影響がない」と評されたものがありましたね。

ジェフ・ディーン：あぁ、あれですね。モチベーションを高めるための、インスピレーションとなるような話です。蒸留が重要であることが証明されたという。同僚のジェフリー・ヒントン（Geoff Hinton）、オリオル・ビニャルス（Oriol Vinyals）、そして私が、ある形状モデルを取り入れて蒸留を用いて学生モデルに落とし込む方法について執筆して提出した論文です。

ビル・ジア：何年のことでしたっけ？

ジェフ・ディーン：2015年か2016年ですね。もともとは、ビジョン向けにさまざまな種類の特化型モデルの大規模なアンサンブルをトレーニングし、それを蒸留するという文脈で考えていました。論文内で行った一連の実験の一つとして、「20,000のビジョンクラスがあるが、動物用に1つ、車用に1つ、その他もろもろ用に特化したモデルをそれぞれトレーニングし、それらをすべて組み合わせて、すべてのタスクを得意とする単一のモデルに蒸留する」というものがありました。その論文はリジェクトされましたが、問題ありません。arXivに公開しましたし、皆さんが読んでくれました。

ホスト：落胆してはいけないということですね。

ジェフ・ディーン：その通りです。

Q&A：コモディティハードウェア対専用スーパーコンピュータ

ホスト：残り時間が少なくなってきましたので、いくつか質問を受け付けたいと思います。マイクを持って会場を回っているスタッフがいます。あちらに1人いらっしゃいますね。ここから始めましょう。立ち上がって自己ご自身のお名前を名乗り、背景を簡単に一言でご紹介いただけますか？

聴衆（イン：Ying）：インと申します。以前Google Brainに10年間在籍していました。またお会いできて嬉しいです。ビルとジェフへの質問ですが、Googleの初期の時代について、コモディティソフトウェアとコモディティコンピューティングを活用して2000年代初頭にGoogleがスケールしたというお話がありました。現在では、AIスーパーコンピュータはますます特化型になっており、本来のスーパーコンピューティングフレームワークに似てきています。ハードウェアと機械学習システムのこれら2つの異なる設計パターンについて、どのようにご覧になっていますか？ 将来的にはよりコモディティハードウェアに向かうべきだとお考えでしょうか、それとも引き続きスーパーコンピューティングマシンを構築し続けるべきでしょうか？ ありがとうございます。

理想的には単一のチップ上でトレーニングできればそれがベストですが、それでは時間がかかりすぎるか、メモリに収まりません。そのため、問題を多くのチップに分割せざるを得なくなります。どのように分割するにせよ――モデル並列であろうとデータ並列であろうと――通常、かなりの量の通信が発生することになります。だからこそ、マシン間にこのような特殊なインターコネクトが必要になるのです。チップを広範囲に分散させなくて済むようにチップあたりのパフォーマンスを最大化したいところですが、それでもなお大規模に分散させる必要があります。そのため、各チップのパフォーマンスをその環境において最大限に高めるために液冷を使用しているのです。

推論に関しては、専用ハードウェアを使用する方向に向かうとはいえ、特に小規模なモデルにとってはそれほど特殊なものではなくなると考えています。しかし、モデルが大規模化するにつれて、イーサネットのコモディティハードウェアやコモディティネットワークと比較してかなり特殊に見える通信ニーズが生じ始めます。とはいえ、トレーニングに比べれば圧倒的にメインストリーム的でありコモディティ的です。お分かりいただけますでしょうか？

Q&A：オープンソースへの貢献、CUDAパリティ、開発者向けAIエージェント

ホスト：もう一つ質問が来ていますね。

聴衆（アンドラ：Andra）：Uberのアンドラです。JAXとOpenXLAのエコシステム、特にこのオープンソースコミュニティが築き上げてきたものに関して質問があります。現在、これはAndroidやiOSに匹敵するAIインフラの時代であるように見えます。若いエンジニアがOpenXLAのライブラリ関数などに貢献していく上で、どのような可能性や道筋があるとお考えでしょうか？ ほとんどのユーザーはヘビーなCUDAユーザーであるか、あるいはCUDAライブラリをベースにライブラリや関数を構築しています。OpenXLAに関して、若いエンジニアが貢献できる領域とはどのようなものでしょうか？

ビル・ジア：まず第一に、OpenXLAおよびJAX、そしてJAXの上のスタックは完全にオープンソース化されています。これが作業の1つの領域です。もう1つの領域はTorch-TPUです。現在、私たちは社内でMetaと協力して開発を進めていますが、最終的にはGitHubに公開し、コミュニティの研究者やエンジニア全員に貢献してもらえるようにする予定です。これが私たちの2つの並行した取り組みです。オープンソースリポジトリに貢献したいと考えているコミュニティの若いエンジニアの皆さんは、Googleと協力することを大歓迎します。このオープンソースリポジトリをどのように共同開発できるかについて議論しましょう。

さらに、将来的には多くのユーザーがTPUまたはGPU上でJAXスタックあるいはPyTorchスタックのいずれかを使用することになるでしょう。現在、コミュニティの人々がそれを使用する際に何か問題に直面した場合、経験豊富なエンジニアがいるGoogleやNvidiaに問い合わせるか、誰かが質問を理解し、同様の経験から回答してくれることを期待してコミュニティのディスカッションボードに質問を投稿しています。しかし、私の見立てでは、それは非常にスローなプロセスです。オープンソース戦略においてコミュニティが貢献できる領域は何でしょうか？ 例えば、「GPUやTPU上で動作するJAXエージェントやPyTorchエージェント」を想像してみてください。どちらでも構いません。コミュニティの全員がデータソースを持ち寄り、そのエージェントを極めて強力にトレーニングすることに協力したとしたらどうでしょう。想像してみてください。「TPU同僚エージェント」が存在し、トレーニングや事後トレーニング、推論を実行する際に、Googleに問い合わせたりディスカッションボードに行ったりする必要がなく、このエージェントを直接使って支援を受けられるとしたら。もしそのエージェントが大部分の質問に答えられるとしたら素晴らしいことです。しかし、これにはコミュニティ全体の協力が必要です。なぜなら、膨大なデータポイントと経験が必要だからです。

ジェフ・ディーン：オープンソースへの貢献に関するメタな視点についても少しお話ししておきましょう。人々が貢献する方法はたくさんあります。「これをやろうと考えているが、役に立つか、あるいは取り組むべきことについてアイデアはあるか」という点を確認するために、さまざまなリポジトリのオーナーと対話するのは非常に良いことです。「これが5,000行のコードです、どうぞ」と誰かにいきなりコードを投げつける前に、何が役に立つのかについての賛同やガイダンスを得ることを強くお勧めします。もし貢献したいという熱意はあるものの、具体的に取り組むべき特定の対象が特に決まっていない場合でも、役に立つと思われる項目の長いリストが用意されていることがよくあります。

聴衆（アンドラ：Andra）：ご回答ありがとうございます。私が直面した中で一つ躊躇している点は、多くの関数やモジュールカーネルが依然としてCUDAに強く依存しているという現実です。CUDA関数と比較して何らかの汎用的な互換性を持たせるために、JAX、OpenXLA、またはTorch-TPUを使用して同等の機能を実装するトレンドはありますか？ それは良い方向性だと言えるでしょうか？

ビル・ジア：はい、将来的には間違いなくその方向に向かいます。Google社内で、内部のJAXスタックやTPU上のPyTorchスタックを検証する際、私たちはすべてのCUDA関数を調査し、同時に私たちの関数も調査しています。少なくともそれらと同等以上であることを確認しています。したがって、それは私たちが絶対にやり遂げなければならない必要不可欠な要素です。そしてそのレイヤーにおいて、低水準のTPU SDKの作業内容もオープンソース化していきたいと考えています。

ジェフ・ディーン：また、人々はより高い抽象度のレベルで物事を考えるべきだと考えています。JAXやPyTorchの式（エクスプレッション）のレベルで考えるべきであり、「最大のパフォーマンスを引き出すために、TPUカーネル言語であれGPUカーネル言語であれ、どうすれば何らかのカーネルコードを使ってこれを並列化できるか」という低水準のことに必ずしも囚われる必要はありません。コンパイラや基盤システムがそれをうまく処理してくれるため、開発者は行列乗算のような美しい抽象化のレベルで思考すればよいのです。

Q&A：スケーリングネットワーク、3Dトーラス、同期的トレーニング

ホスト：最後の質問に割り当てる時間が残っていますね。最後の質問をどうぞ。

聴衆（ジョン：John）：ニューヨーク大学のジョンです。長年ネットワーキングの研究をしています。ビル・ジアさんや他の登壇者のお話しされたスケーラビリティに関する発表に非常に感銘を受けました。これらのTPUが3Dトーラスで接続されていると伺いました。Ultra Ethernetコンソーシアムやファットツリー・インターコネクトを調査している他の組織と比較して、スケーラビリティの観点から、TPUやGPUを数万基、あるいは100万基規模にまでスケールアップさせた場合、この3Dトーラスはそれほどの大規模なオール・トゥ・オール（All-to-All）通信を依然として処理できるのでしょうか？

ジェフ・ディーン：TPU v5eやTPU v4における私たちの最大規模のポッドは、確か9,600チップ弱です。それが3Dトーラスを用いて構築しているスケールです。それを超える規模においては、複数の3Dトーラス接続ポッドの上位にソフトウェア抽象化としてPathwaysを使用しています。それはデータセンター内のファブリック（データセンターネットワーク）を利用するか、あるいは例えばオクラホマ州にあるビルに5つのポッドがあり、アイオワ州にある別のビルにさらに8つのポッドがあり、それらが高速なWANリンクで結ばれているような複数都市間にまたがるマルチメトロなトレーニングセットアップを利用します。そうした手法により、スケーリングはかなりうまくいっています。

実行している計算をマッピングする際、データ並列ディメンションとモデル並列ディメンションを持つように構成したい場合があります。一般的に、モデル並列の側面は単一のポッドまたはポッドのスライス内に収め、データ並列のレプリカをそれらのポッドやポッドのスライス間にまたがって配置するという構成が好まれます。これは私たちにとってかなりうまくいっています。トーラスベースのネットワークの優れた点は、データセンターのフロアで非常に複雑な配線を必要とせず、ローカルに接続するのが非常に容易であるという点です。

ホスト：あの奇妙なミラー式光スイッチを除けば、ですね。

ジェフ・ディーン：ビル、何か付け加えることはありますか？

ビル・ジア：はい、その通りです。ラック内、キューブ内にはICIがあります。そしてOCS（光回路スイッチ）を使用して9,600までスケールアップします。さらにその上には、Pathwaysソフトウェアによってオーケストレーションされるデータセンターファブリックがあります。10万基を超えるチップ規模に移行する際には、クラウドのデータセンターネットワーキングを使用してすべてを接続します。この種のスケーラビリティは私たちにとって非常にうまくいっています。

ジェフ・ディーン：そして、その規模においてさえ、私たちは完全に同期型のトレーニングを実行できていると言えます。これはMLの再現性や解釈性の観点から非常に好ましいことです。いつの日か非同期トレーニングが再び主流になる時が来るかもしれませんが、これまでのところ、私たちは同期トレーニングをかなり遠くまで押し進めることに成功しています。今後どうなるか見守っていきましょう。

ホスト：素晴らしい締めくくりの言葉ですね。時間となりました。ジェフ、どうもありがとうございました。ビル、お時間をいただきありがとうございました。パティオのすぐ外に、有名なジェフ・ディーンのミームがプリントされたペンやDev LabsのTシャツなど、とてもクールなグッズをご用意しています。皆さん、本当にありがとうございました。