Googleの新型AI演算チップ「TPU 8t」と「TPU 8i」は何が違うのか？

左がTPU 8i、右がTPU 8t

　Alphabet傘下のGoogle Cloudは、4月22日から4月24日にかけて米ラスベガスにて開催中の年次イベント「Google Cloud Next '26」において、AI演算向けのTPU(Tensor Processing Unit)の第8世代製品となる「TPU 8t」、「TPU 8i」の2製品を発表した。

　Google Cloudは、2015年に最初のTPUをカスタムシリコンとして投入した。TPUはその名前の通りTensorCoreと呼ばれる行列積和演算に特化した演算器を搭載しており、AIの学習や推論処理などに利用できる。

　同社は、記者会見や分科会(ブレイクアウト)などで、今回発表したTPU 8tとTPU 8iのアーキテクチャなどを説明しており、そこから見えてきた第8世代TPUの詳細に関してお届けしていく。

スループット重視だったAI学習向けシリコン。だが推論では低遅延が求められる

前世代となるIronwood

　これまでAIの演算装置(GPUやTPUなど)に求められていたのは、データ処理のスループットだった。スループットとは、非常にざっくり言えば一定時間にどれだけのデータ処理ができるかを意味する。というのも、特にAIの学習では、膨大なデータを処理する必要があるため、スループットが高ければ高いほど、処理時間を短くすることができるのだ。

　AIモデルなどを開発する多くの企業では、この学習演算処理にかかる時間がモデル開発の足かせとなっており、より高いスループットの高い演算環境が必要とされている。それが多くの企業がNVIDIA GPUを選択してきた大きな理由だ。

　従来はGPUやTPUが8基程度の小さなクラスターで演算されてきたが、今ではNVLinkを利用したスケールアップで72基、さらにスケールアウトして1万基や数十万基のGPUで大規模に演算させるといったことが当たり前になっている。スループットを上げるには、GPUを多数接続して利用することが有効だからだ。

TPUの歴史

　GoogleのTPUもそれは同様だ。2025年に発表された第7世代のIronwoodでは、NVIDIAのGPUで言えばNVLinkに相当する「3D Tours」というチップ間インターコネクトの機能を利用して、9,216基までスケールアップでき、その後はEthernetを利用してスケールアウトできるように設計されている。

　だが、そうしたAI向け演算装置の市場も大きく変わろうとしている。その最大の要因は、AIエージェントなどの普及により、従来CPUで行なわれていた推論処理を、GPUやTPUを利用してある程度大規模に演算する必要が出てきていることにある。ただ、学習は「一定時間に処理できるデータ量」をできるだけ多くするというスループット重視なのだが、推論はスループットが重要な処理もあるが、主に「レイテンシ」(遅延)ができるだけ少ないことが同時に求められる。

　たとえば、LLMの応答性を考えてみよう。ChatGPT、Claude、GeminiのようなAIチャットボットに何かの処理をお願いしたとき、応答がすぐに返ってこないといった経験は誰もがあるだろう。その裏側でチャットボットは、データをデータセンターに送り、データセンター側で何らかのプロセッサがその処理を行なって、結果を返す。

　そのとき、プロセッサの処理が遅くなればなるほど、応答は遅くなる。そうした遅れがレイテンシであり、これが増えれば増えるほどチャットボットのような「推論エンジン」の応答性は悪くなる。結果としてユーザー体験に影響したり、あるいはアプリケーションとして成立するのが難しくなったりする。このため、推論の世界ではレイテンシをいかに短くするかが重要なのだ。

同じアーキテクチャだが異なる最適化で学習用/推論用チップを実現

主に学習用になるTPU 8tと主に推論用となるTPU 8i

　Google Cloudは前世代となるIronwood世代で、9,216基の大規模なポッド(クラスター)を学習用、256基と小規模なポッドを推論用といったように、ポッドのサイズを変えることで各用途に対応してきた。しかし、サイズを小さくして推論用とすることはできるが、TPU自体の設計は同じなので、推論に求められる低遅延というニーズは満たせていなかった。

　そこで今回の第8世代TPUでは、主に学習向けとなるTPU 8t、主に推論向けとなるTPU 8iと、用途ごとにTPUの基本的な設計を分けてきた。末尾の「t」が学習を意味するTrainingの頭文字で、「i」が推論を意味するInferenceの頭文字であることは言うまでもない。

　なお、「主に」と書いたのは、TPU 8tを推論に使うことは可能だし、TPU 8iを学習に利用することも可能だからだ。

Google Cloud GTM戦略・製品管理担当レオ・レン氏

　Google Cloud GTM戦略・製品管理担当レオ・レン氏は、「従来のIronwoodでは1つのチップで大小2種類のポッドを用意することで、学習と推論それぞれのニーズを満たそうという考え方だったが、推論向けには低遅延やキャッシュが重要だということがはっきりしてきたため、より多くのキャッシュを搭載し、HBMメモリも学習向けよりも大容量とし、さらにネットワークトポロジーに関しても大きく変えた」と説明する。シンプルに学習と推論では、前者がスループット重視、後者が低遅延重視とニーズに違いがあるため、今回はチップを2種類に分けたということだ。

NVIDIA Groq

　こうしたトレンドは別にGoogle Cloudだけに限らない。3月のGTCでNVIDIAが投入することを明らかにしたGroq LPUも基本的には同じ考え方だ。NVIDIAでは、Vera Rubinはスループットに最適化されており、学習と大規模な推論などに最適と説明している。その一方で、遅延が重要視される推論処理はGroqに任せる。これが基本戦略ということになる。

　NVIDIAとGoogle Cloudの考え方で最も大きく異なるのはソフトウェアの部分だ。NVIDIAの場合、まったく新しいアーキテクチャを採用したことで、これまでCUDAを利用していた顧客がGroqに対応しようとすると、CUDAではない新しいGroqのソフトウェア開発モデルを使わなければならない。それに対してGoogle Cloudの方は基本的に同じアーキテクチャであるため、ソフトウェア開発モデルはどちらも同じで、そのまま学習にも推論にも利用できる。

　NVIDIAの考え方は、ソフトウェア開発者が新しいモデルを学習する必要があるというデメリットはあるが、完全に新しいアーキテクチャにすることで超低遅延を実現しやすくなるというメリットがある。Google Cloudの考え方は、新しいアーキテクチャほどの低遅延は実現できないが、その反面ソフトウェア開発者にとっては従来の学習/推論で使ってきたソフトウェアのコードや経験がそのまま使い回せるというメリットがある。

　どちらのアプローチにも一長一短があるが、Google Cloudのレン氏は「バランスだ」と述べており、Google Cloudとしては、同じアーキテクチャでありながら、用途ごとに最適化した2つのチップに分けたのだと説明した。

LLM向け機能を搭載したTPU 8t

TPU 8t、メインのダイは1つで、ICIのダイが2つ、さらにHBMは6チャンネル搭載されていることが分かる

　TPU 8tとTPU 8iはそれぞれ何が違うのだろうか。Google CloudがNextで公開した情報をもとに、前世代となるIronwood、TPU 8t、TPU 8iの違いを表と図にしたものが表1と図1だ

TPU 8t、TPU 8i、Ironwoodの違い(Google Cloudの資料より筆者作成)

　TPU 8tとTPU 8iの物理的な最大の違いは、チップレットのダイ構成だ。ぱっと見て分かることは、ダイ構成の観点から言えば、TPU 8iはIronwoodとほぼ同じ構成で、TPU 8tは異なっているという点だ。

　2025年に発表されたIronwoodでは、パッケージ上にダイは3つ搭載されていた。うち2つはTensorCoreのダイで、もう1つがスケールアップ時に使うチップ間インターコネクト(ICI)のダイになる。その意味で、TPU 8iはダイ構成は同じだ。TPU 8iはTensorCoreのダイが2つとICIという3つのダイ構成になっている。

TPU 8tのブロックダイアグラム

　それに対して、TPU 8tの方はTensorCoreが1つで、ICIが1つという2ダイ構成になっている。イメージとしては巨大なTensorCoreが1つのダイ上に統合されているといった形になる。なお、Google CloudはこのTensorCoreのマイクロアーキテクチャに関して何も説明していないため、どういう違いがあるのかは不明だが、TPU 8tのスループット(FP4時)は12.6PFLOPSと、Ironwood(4.61PFLOPS)の2.73倍になっていることからも分かるように、ダイが2つから1つに減っているのにこれだけの性能が向上しているということは、TPU 8tのTensorCoreの内部演算器などが大幅に増えていると考えられるだろう。

Sparse CoreがLDEに対応

　もう1つのTPU 8tの大きな強化点は、Sparse Coreと呼ばれる、データの処理をオフロードするための特殊なアクセラレータが、新しくLLM処理時のアクセラレーションに対応していることだ。LDE(LLM Decoder Engine)と呼ばれる機能がそれで、

• 固定のヘビーワークロードの処理を加速
• MoE向けの通信処理をオフロードする
• LLMデコーダエンジンがプレフィル(Prefill)とデコード(Decode)フェーズをオーバーラップして実行する

という3つの機能が追加されている。特にLLMが処理を行なう際に、KV Cacheと呼ばれるGPUやTPUメモリ上に展開されるデータキャッシュの作成(Prefill)とトークンの生成(Decode)をオーバーラップして行なうことが可能になっており、それによりLLMの演算処理をより高速に実行できるようになる。

　レン氏が「実際の利用環境では、顧客は学習と推論を同じTPU上で行なうことが多いため、こうしたLLMデコーダエンジンの追加が必要だった」と説明する通りで、今回新たにLDEの機能が追加されたSparse CoreがTensorCoreのダイに2つ搭載されていることが大きな特徴になっている。

最大9,600基まで大規模化可能に。TPUDirect Storageでストレージ転送も強化

3D Toursの帯域幅が2倍に

　そしてTPU 8tのもう1つの強化点は、スケールアップ、スケールアウトネットワークの強化だ。スケールアップネットワークに関しては、Google Cloudが3D Toursと呼ぶ機能が用意されている。この3D Toursの特徴はチップとチップを3Dで接続できることで、スイッチチップがなくても大規模にスケールアップできることだ。多くのスイッチチップが必要になるNVIDIAのNVLinkと比較して、低コストでかつ低消費電力でスケールアップすることができる。

　今回その帯域幅が2倍の2.45TB/sに強化されており、スケールアップ時の性能が引き上げられた。さらに従来のIronwoodでは1ポッドあたり最大9,216基だったものが、今回のTPU 8tでは9,600基までスケールアップできるようになっている。

TPUDirect Storageに対応

　また、HBMメモリ同士のDMA転送となるRoCE V2のRDMAに加えて、ストレージへのRDMAとなる「TPUDirect Storage」にも対応し、ストレージからメモリへのデータの読み込みが高速化されている。

　スケールアウトネットワークについても、Virgo Networkと呼ばれるという新しい技術が採用されている。

Virgo Network

　レン氏によれば「従来のIronwoodでは200Gb/sのEthernetだったが、Virgoでは400Gb/sのEthernetに強化されている」という。これにより、スケールアップでは9,600基までだが、Virgoを利用してスケールアウトすると、最大で13万4,000基まで1つのTPUとして扱うことが可能になる。この規模は十分巨大なGPUクラスターに匹敵する規模で、TPUを利用したAIデータセンターの性能を引き上げられる。

大容量キャッシュと高速メモリで低遅延に最適化されたTPU 8i

TPU 8i

TPU 8iのブロックダイアグラム

　それに対して、TPU 8iはすでに説明した通り推論に特化した設計になっている。ダイ構成は別にして、TPU 8tとの違いは大きく以下のようなものが挙げられる。

• キャッシュメモリ(SRAM)の容量が3倍
• メモリ容量が288GB(1.33倍)で、HBM3eを採用して帯域幅も1.32倍
• Sparse Coreのより推論に特化したSC-CAE(Sparse Core-Collective Acceleration Engine)をICIダイに統合
• スケールアップネットワークとしてBoardfly Topologyを採用

　まずメモリ階層の改良については、メモリを読み込むときの帯域幅を向上させ、キャッシュメモリの容量を増やすことで、低遅延でメモリにアクセスできるようにしている。TPU 8tの128MBに比べて3倍となる384MBのSRAMが搭載されるほか、メモリもHBM3e(TPU 8tはHBM3)となっている。さらに、メモリコントローラがそれぞれのダイに4基、パッケージ全体で8基(同6基)搭載されており、TPU 8tよりも広帯域なメモリ帯域幅になっている。

SC-CAE(Sparse Core-Collective Acceleration Engine)

　そしてもう1つの大きな改良は、SC-CAEをICIのダイに統合していることだ。IronwoodやTPU 8tでは、Sparse CoreはTensorCore側に実装されている。それに対してTPU 8iのSC-CAEは、Sparse Coreとしての動作だけでなく、CAEと呼ばれるメモリへの特定の呼び出し処理をオフロードする仕組みが用意されている。それにより、メモリの遅延をできるだけ抑えており、Ironwoodと比較して遅延を5倍少なくした。

Boardfly Topology

　レン氏によれば「SC-CAEは同時にスケールアップネットワークのBoardfly Topologyと組み合わさって動作し、チップ間で通信が必要なときでもネットワークのオーバーヘッドを小さくし、レイテンシを削減する」とのことだった。

　Google Cloudが公開した資料によれば、Boardfly Topologyでは、基板上の4つのTPUが相互に接続され、その基板がラック内の8つそれぞれに接続され、さらにラックが36基それぞれに接続されることで、最大1,152基という構成が実現されているという。

PyTorchにもネイティブ対応へ。CUDAからの移行も簡単に

　なお、今回Google Cloudは「契約上の理由により」チップの設計や製造をどこに委託しているのか、あるいはプロセスノードはどの世代なのかなど、サプライチェーンの質問には一切答えなかった。このため、プロセスノードが進化したのか、そうではないのかなども不明だ。どこが設計しているのかなどの質問が答えにくいことは理解できるのだが、どこのファウンドリで、どのプロセスノードなのかは、半導体の基本情報として公開してしかるべきだと思うので、ぜひ将来はきちんと公開してほしいと感じた。

PyTorchのTPUネイティブサポートがまもなく提供開始

ネイティブ対応前に修正する部分

ネイティブ対応後に修正する部分はわずかに3カ所

　あわせて、TPUにおいてPyTorchのネイティブサポートを開始する計画を明らかにした。同社の場合、基本的にはオンプレミス向けの外販は行なっていないため、何らかのGoogleのミドルウェア(従来ならVertex AI、今回それはGemini Enterprise Agent Platformに名称変更された)などを経由して利用するか、VMを経由して、自分でソフトウェアを用意するという2つの使い方が考えられる。

　後者の場合はJAXなどがこれまで奨励されてきたが、PyTorchがTPUをネイティブサポートすると、CUDA+GPUからの乗り換えが容易になる。PyTorchのCUDA向けコードからTPU向けに書き換えるには多くの部分を修正する必要があり、かなりの大作業だったが、今回のPyTorchのネイティブサポートにより、わずか3行を書き換えるだけでこれが可能になるという。PyTorchを利用してAIのコードを書いているプログラマーにとってはよいニュースで、かつ、CUDA GPUからTPUへの移行もより容易になる。