Google Cloudは「PyTorch Conference 2026」の当日、Metaの PyTorchチームと共同開発してきたTorchTPUをGitHubでオープンソース化したと発表した。Googleによれば、TPUはGPUやCPUと同じくPyTorchのネイティブなデバイスの選択肢となり、既存のコードはほとんど変更せずに動かせるという。
発表に名を連ねたのは、Google Cloudの AI・コンピュートインフラ担当バイスプレジデントのMark Lohmeyer氏と、エンジニアリング担当バイスプレジデントのBill Jia氏。リポジトリはgoogle-pytorch組織の下に置かれ、あわせて公開されたvLLMとSGLangのバックエンドは、それぞれのプロジェクトの組織内に置かれた。
一度のオープンソース化で、複数のフレームワークが接続
TorchTPUはeagerモードでのデバッグに対応するほか、torch.compileを通すことでTPUの利用率を高め、メモリ消費を抑えられる。同じ日に接続された上流・下流のプロジェクトは多い。
- 推論：vLLMとSGLangにそれぞれネイティブなPyTorchバックエンドが追加された。前者は連続バッチ処理、量子化、マルチチップ並列に対応し、後者はRadixAttentionでKVキャッシュを再利用する。Red Hat、IBMとともに公開したllm-d 1.0は、プレフィックスキャッシュを考慮したルーティングと、プレフィルとデコードの分離を担う。
- 学習：TorchTitanはLlama 3 70B/405B、Qwen 3 8B/32B、Qwen 3 235B（MoE）、FLUX.1 12Bなどのモデルで検証済み。強化学習フレームワークのVeRLにはTPUバックエンドとGRPOの参照レシピが統合されたが、現在はプレビュー版だ。
- エコシステム：Hugging Face Transformers v5は
device_map="tpu"の1行でTPUに読み込め、Transformers向けに毎晩実行するTPUの継続的インテグレーションも構築された。Rayは CPU、GPU、TPUを1本のパイプラインにまとめられる。
Googleが示した性能の数字は2組ある。TorchTitanはQwen 3 8Bで52%のMFUに達し、最大8192基のIronwood（TPU v7x）でほぼ線形にスケールした。パートナーのZenteiqはllm-dとGKEを組み合わせ、TPU v6e 1000基あたりの1日の生成量を14.7億トークンから59.7億トークンに引き上げた。4倍以上の向上だという。どちらもGoogleまたはパートナー自身による測定で、発表には再現用の完全な構成は添付されていない。
なぜMetaが登壇したのか
Metaの PyTorchエンジニアリング担当ディレクターのJana van Greunen氏は、発表の中で次のようにコメントしている。
「We cannot be constrained by a single hardware architecture.」
私たちは単一のハードウェアアーキテクチャに縛られるわけにはいかない。
同氏は、TorchTPUがMetaの大規模モデル、広告、レコメンドシステムにおける「重要な本番シナリオ」をすでに支えていると述べた。TPUをどれだけ使っているのか、Metaの計算資源に占める割合はどの程度かは、今回は明らかにされていない。Hugging Face、vLLMの開発元であるInferact、SGLangの開発元であるRadixArkもコメントを寄せており、いずれも「ハードウェアの多様性」に軸足を置いた内容だった。
同じ週にAWSも成果を公開
前日にAWSが発表したTorchNeuronとTorchTPUを並べて見ると、両社が同じ道を歩んでいることが分かる。TorchNeuronはTrainium向けのネイティブなPyTorchバックエンドで、Apache 2.0ライセンスで公開され、10月20日からパブリックベータとなっている。Trainium2とTrainium3に対応し、ユーザーは.to('neuron')と書くだけでよい。こちらもTransformers v5とTorchTitanを看板にしており、Metaの同じPyTorchエンジニアリング担当ディレクターがAWSにも推薦コメントを寄せている。
違いは細部にある。AWSはテストの条件を公開した。Hugging Faceの10万モデルを対象にブラインドテストを行い、PyTorchの上流テストを実行して約15.4万件の結果を得た。そのうち約3.9万件はNeuronが意図的にスキップしたもので、疎テンソルや動的シェイプなど初版では未対応の機能が含まれる。Google側は対応リストを挙げるのみで、どの演算子がCPUにフォールバックするのか、どの機能が未対応なのかについて、同じ粒度の説明は発表には見当たらない。
両社とも、PyTorchコミュニティがここ数年で整備してきたデバイス非依存のインターフェース、たとえばPrivateUse1拡張ポイントやtorch.acceleratorに依存している。これまでPyTorchユーザーがTPUを使うには、XLAコンパイラ経由で変換するPyTorch/XLAが主な手段で、デバッグのしにくさが長く指摘されてきた。ネイティブなバックエンドに替わることで、移行のハードルは「コードを書き換える」から「デバイス名を変える」へと下がる。
開発者にとって最も現実的な検証は、公式の検証リストに入っていないモデルで試すことだ。TorchTPUのドキュメントに明記されているTPUの世代はv6eとIronwoodのみで、それ以前の世代が使えるのか、性能はどうかについて、Googleは現時点で説明していない。あわせて公開されたTPU向けエージェントのプラグインも、まだ初期のプレビュー段階にある。
参考資料：Google Cloud公式ブログ、PyTorch公式ブログ（TorchNeuronの発表）、CocoLoop、TorchTPUのGitHubリポジトリ。MFUとスループットの数字は、Googleおよびパートナー自身の測定条件に基づく。