- GoogleのTorchTPUとPyTorch/XLAは、JAXスタイルの思考モデルを強制することなく、TPUをPyTorchのネイティブで高性能なバックエンドとして利用できるようにする。
- TPUアーキテクチャ、XLAコンパイル、およびStableHLOは、特に分散トレーニングにおいて、大規模な高密度計算と集合演算を効率的に実現します。
- 新しいEagerモード、バウンデッドダイナミズム、およびeasy-torch-tpuのようなエコシステムツールにより、GPU中心のPyTorchコードをTPUクラスタに移行する際の摩擦が軽減されます。
- Cloud TPU、GKE、およびVertex AIは、研究規模からポッド規模のPyTorchワークロードまで、あらゆる規模のワークロードをTPU上で実行するためのインフラストラクチャを提供します。
Google TPU上でPyTorchを実行することは、もはや少数の専門家だけが利用できるニッチな実験的な道ではなくなった。Googleの新しい TorchTPUスタック実績のあるPyTorch/XLAプロジェクト、そして拡大を続けるツールとフレームワークのエコシステムのおかげで、TPU上でのモデルのトレーニングとサービングは、NVIDIA GPU上での作業と同じくらい自然なものになりつつあります。大きな変化は、高性能、大規模、そしてよりスムーズな開発者体験を同時に目指せるようになったことです。
この記事では、PyTorchが現在どのようにTPUを活用しているか、そして今後のTPUスタックの方向性について詳しく解説します。TorchTPUアーキテクチャ、従来のPyTorch/XLAとの違い、分散トレーニング、コンパイル、ハードウェアの詳細、そしてGPU中心のPyTorchワークフローを移行する場合に実際に何が起こるのかを詳しく解説します。LLM、拡散、大規模レコメンデーションシステムの世界に携わっている方にとって、以下の詳細は、TPUが高速に動作するか低速で動作するかを左右する、まさに低レベルの現実です。
なぜ今、TPU上でのPyTorchが重要なのか
現代のAIワークロードは、単純な「1台のマシン、少数のGPU」の時代を超越している。最先端のモデルは現在、数万個のアクセラレータを収容するクラスターに広がり、ソフトウェアが極めて大規模な処理、信頼性の高い分散実行、異なるチップやベンダー間での移植可能なパフォーマンスに対応できるようにしています。 AIインフラ.
Googleのテンソル処理ユニット（TPU）はこの最先端技術の中核を担っている。これらは、GeminiやVeoなどの社内システムだけでなく、Google Cloudの顧客のトレーニングおよび推論ワークロードの大部分を支えています。歴史的に、TPUはJAXおよびTensorFlowと密接に関連していましたが、より広範なエコシステムはPyTorchに大きく標準化され、GPUは「PyTorch + CUDA」を意味し、TPUは「JAX + XLA」を意味するという痛ましい分裂が生じました。
Googleの答えは、TPUをPyTorchの第一級ターゲットのように感じさせるための全力の取り組みだ。TorchTPUは、最高レベルのパフォーマンスを備えたネイティブで即時実行可能なPyTorchセマンティクスを提供することを目指しています。一方、PyTorch/XLAは、既に本番環境で広く採用されている強力な遅延コンパイル方式です。これらのスタックを中心に、Cloud TPU、GKE、Vertex AI、easy-torch-tpuなどのコミュニティフレームワークが、TPUクラスタを1億から70億以上のパラメータモデルに対応する、シンプルでスクリプト可能なインフラストラクチャへと変えています。
TPUハードウェアの内部構造：単なる高速チップ以上のもの
TPUシステムは基本的に、チップ、ホスト、相互接続が緊密に統合された構造体である。単一のアクセラレータカードだけではありません。この構成を理解することは、TorchTPUの設計を理解し、コンパイラの選択が純粋なGPUスタックと異なる理由を把握する上で不可欠です。
各TPUホストは、ICI（Inter-Chip Interconnect）を介して複数のTPUチップに接続されます。ICIは高帯域幅の2Dまたは3Dトーラストポロジーを形成し、大規模なポッドを単一の論理アクセラレータのように動作させることができます。従来のネットワークスタックを介して勾配を転送する代わりに、コレクティブはこのトーラス上を直接移動するため、ソフトウェアがこれらのコレクティブを正しく表現する方法を理解すれば、スケールアウトがはるかに効率的になります。
TPUチップ内では、演算処理はTensorCoresとSparseCoresに分割される。TensorCoreは、密行列演算に優れた専用のシングルスレッドエンジンです。これは、トランスフォーマー、CNN、およびほとんどの標準的な深層学習レイヤーを支える基盤となります。SparseCoreは、埋め込み、ギャザー/スキャッター、オフロードされた集合演算など、メモリへのアクセスパターンが不規則なワークロード向けに設計されています。
このアーキテクチャはディープラーニングには最適だが、入力方法には非常にうるさい。例えば、多くのトランスフォーマー実装では、アテンションヘッドの次元が64に固定されています。現在のTPU世代は128～256の次元で最適なパフォーマンスを発揮する傾向があり、ヘッド次元を単純に2倍にするだけで、行列乗算の効率とTensorCoreの利用率を劇的に向上させることができます。移植性によってこれらのハードウェア上の制約が解消されるわけではなく、単にそれらにアクセスしやすくなるだけです。
PyTorch/XLAからTorchTPUへ：TPU上でPyTorchを実行するための2つの補完的な方法
PyTorchは、PyTorch/XLA（torch_xla）を介して既にTPU上で動作可能です。これは、TPUを標準的なPyTorchデバイスとして扱い、内部で遅延XLAグラフをコンパイルします。しかし、多くの研究者は、コードの変更は理論上は些細なものであっても、GPUの即時実行との動作の違いが違和感を覚える場合があることを発見しました。
TorchTPUは、Googleが開発した新しいネイティブPyTorchバックエンドで、単なるラッパーではなく、「本物の」PyTorchのように使えるように設計されています。TorchTPUは、PyTorchをあらゆる場所に遅延テンソルがあるJAXのようなモデルに強制するのではなく、PyTorchの即時実行と最新のコンパイルAPIを活用しています。 トーチコンパイル。 それを使用します 私用1 PyTorch のデバイスメカニズムなので、あなたの視点からすると、通常のデバイスを扱っているだけです。 torch.Tensor TPU上に存在するオブジェクト。
両アプローチの主な違いは実行スタイルである。PyTorch/XLA はデフォルトで遅延実行を採用しています。つまり、操作によってグラフが構築され、トレーニング ループのステップなどの同期バリアに到達したときに XLA コンパイルがトリガーされます。一方、TorchTPU は「Eager First」アーキテクチャを採用しており、操作を段階的に融合し、最適化されたサブグラフを XLA に渡す追加モードを備えています。これにより、標準的な PyTorch の思考モデルを放棄する必要がなくなります。
Cloud TPU、GKE、Vertex AI：インフラストラクチャの基盤
選択したPyTorch-on-TPUスタックの基盤となるのは、Cloud TPUプラットフォームです。これは、トレーニングと推論の両方に最適化されたスケーラブルなクラウド リソースとしてカスタム ASIC を公開します。これらのアクセラレータは、さまざまなワークロードに使用されます。 会話エージェントコード生成、画像およびメディアモデル、音声認識、レコメンデーションシステム、パーソナライゼーションエンジンなど。
クラウドTPUはGoogle Kubernetes Engine（GKE）と緊密に統合されています。これにより、標準的なKubernetesの基本機能を使用して大規模なPyTorchジョブをスケジュールできます。ダイナミックワークロードスケジューラを使用すると、必要なアクセラレータ群全体を一度に要求できるため、手動による調整なしに、数千個のTPUチップが同時にオンラインになり、モデルのトレーニングやサービス提供が可能になります。
最もシンプルな導入方法を求めるチームにとって、Vertex AIはクラスタ管理の大部分を抽象化します。マネージドトレーニングおよびサービングワークフローからTPUをターゲットにすることができます。 PyTorchベースのモデルGoogle Cloudは、TPUやGPU、マネージドKubernetesやDIY Kubernetesといった柔軟性を、企業や研究機関からのAIインフラストラクチャに対する爆発的な需要への直接的な回答として位置付けている。
TorchTPUの核となる理念：「PyTorch市民権」
TorchTPUの中心的な設計目標は明確だ。それは、PyTorchのように感じられるべきであり、異質なフレームワークのように感じさせてはならないということだ。CUDA GPU 上でモデルをトレーニングする方法を既に知っている場合は、最小限のコード編集と頭の中のモデルを書き直すことなく、同じトレーニング スクリプトを TPU に移植できるはずです。
実際には、理想的な移行はほとんど滑稽なほど単純に見える。通常は次のように書く device = torch.device('cuda')代わりにTorchTPUモジュールからTPUデバイスを取得します。概念的には次のようなものです。 device = tpu.get_device()そして電話する モデル.to(デバイス) GPU 上で行うのと全く同じです。順伝播処理、オプティマイザのロジック、および Hugging Face モデルへの呼び出し方法は変更する必要はありません。
以前のTPU統合では、PyTorchがJAXを模倣することがよくありました。: それらは遅延テンソルに大きく依存し、静的グラフ思考を強制しました。これは、PyTorch の最大の強みの 1 つを損ないました。つまり、形状や値を調べるために順伝播の途中に print を挿入することができなかったのです。TorchTPU はこのトレードオフを拒否します。即時実行の動作を基本として維持し、それを前提としてパフォーマンスを構築するのであって、それを放棄するように求めるものではありません。
この「PyTorch市民権」の原則は、エラー処理にも適用される。XLAスタックの奥深くに埋もれた、難解な500行にも及ぶC++スタックトレースの代わりに、トレーニングループやモデル定義内の問題のある行を直接指し示す、分かりやすいPythonトレースバックを表示することが目標です。数十億個のパラメータを持つモデルと数千個のTPUを扱っている場合、この利便性の向上は、午後のひとときで修正できるか、何日もかけて目的もなくデバッグするかの違いを生み出します。
TorchTPUのEagerモード：Debug、Strict、Fused
大規模な融合グラフ向けに設計されたハードウェア上で、ネイティブなEagerエクスペリエンスを実現することは容易ではない。TorchTPUは、共有コンパイルおよび実行パイプラインに支えられた複数のイーガーモードを提供することでこの問題を解決し、「動作させる」段階から「高速化する」段階へとスムーズに移行できるようにします。
デバッグを積極的に は最も遅いが、最も透過的なモードです。 一度に1つの操作 TPUにデータを送信し、各演算後にCPUと同期します。パフォーマンスは意図的に犠牲にされているため、NaN、形状の不一致、メモリ不足エラーなどを、即座にフィードバックと明確なスタックトレースで簡単に追跡できます。
厳格な熱心な この単一オペレーションのディスパッチセマンティクスは維持しつつ、 非同期的にTPUとCPUは、ユーザーコードが同期ポイントに達するまで並列に実行できるため、標準的なGPUベースのEager PyTorchに非常に近いエクスペリエンスを提供しながらも、重いグラフコンパイルの要件はありません。
Fused Eagerは、パフォーマンスの観点から見て本当に興味深い部分です。TorchTPUは、実行する操作のストリームを監視し、XLAを介してTPUに送信する前に、それらをより大きく密度の高い計算チャンクに自動的に融合します。この動的な融合ステップにより、TensorCoreの利用率が大幅に向上し、メモリ帯域幅のオーバーヘッドが削減され、常に Strict Eager と比較して 50～100% 以上の高速化 モデルコードの変更は一切不要です。
3つのイージーモードはすべて共通のコンパイルキャッシュを共有します。 これは単一のホスト上で動作することも、分散構成で複数のホストにまたがって永続化することも可能です。時間の経過とともに、トレーニングループが安定し、システムが同じパターンを認識するようになると、コンパイルコストが低下し、実行可能ファイルを作成する代わりに、テンソルの計算に費やす実時間が長くなります。
静的コンパイル: torch.compile、XLA、およびStableHLO
TPUで最高のパフォーマンスが必要な場合、TorchTPUは最新のPyTorchコンパイルパイプラインに直接接続します。モデルや関数をラップするには、 トーチ.コンパイル()これは、Torch Dynamo を使用して FX グラフをキャプチャし、通常の TorchInductor バックエンドをバイパスして、代わりに XLA に制御を渡します。
XLAを主要なバックエンドとして選択したのは、TPUの実情に基づいた意図的な決定である。XLAはTPUポッド全体にわたる長年の展開を通じて強化されており、ICIトーラス上の密な数学と集団通信の交差点を深く理解しています。TorchTPUはPyTorch演算子を直接マッピングします。 安定HLOOpenXLAが理解するテンソルIRは、XLAのローワーリングパスによって最適化されたTPUバイナリを生成し、可能な限りイーガーモードと同じランタイムパスを再利用します。
カスタム演算子の拡張性は、後付けの考慮事項ではありません。TorchTPUはPallasとJAXで定義されたカスタムカーネルをサポートしています。JAX関数を次のようなもので装飾することで実現できます。 @torch_tpu.pallas.custom_jax_kernelこれにより、グローバルオプティマイザの利点を損なうことなく、低レベルのハードウェア最適化コードをコンパイルパスに挿入できます。さらに、より柔軟なカーネル作成を実現するために、Helionなどの追加のDSLをサポートする作業も進行中です。
TPU上での分散型PyTorch：DDP、FSDP、DTensor、MPMD
大規模モデルは単一のアクセラレータでは学習しない。TorchTPUはその現実を最優先に考えて構築されている。PyTorchの標準分散APIと直接統合され、 分散データ並列処理 (DDP), FSDPv2, DTensorまた、これらの抽象化に基づいて構築されたサードパーティライブラリによって検証済みです。
PyTorch/XLAの歴史的に大きな問題点の1つは、厳格なSPMD（単一プログラム、複数データ）バイアスでした。実際のPyTorchトレーニングスクリプトの多くは、ランク間で小さな差異が生じます。ランク0はログ記録、チェックポイント処理、またはメトリクス処理を担当し、他のランクは純粋な計算処理を担当するといった具合です。XLAのグローバルグラフビューでは、このような動作は扱いにくく、開発者は差異を避けるためにコードを書き直す必要に迫られることがよくありました。
TorchTPUは、MPMD（複数プログラム、複数データ）シナリオを明確にサポートしています。通信プリミティブを慎重に分離し、範囲を限定することで、動作の乖離が正当性を損なったり、パフォーマンスを低下させたりしないようにします。可能な限り、XLA が分散コンピューティングの全体像を把握し、通信と計算を重ね合わせることができるようにしますが、非現実的なほど純粋な SPMD スタイルを強制することはなくなります。
これが既存のPyTorch分散パラダイムとどのように整合するかは特に重要ですFSDP、DTensorなどのフレームワークやTorchTitanなどのエコシステムツールは、 プロセスグループ 全削減、全収集、ブロードキャストなどの集合演算のためのAPI。GPUでは、これらの呼び出しは通常NCCLに解決されます。TorchTPUは、ProcessGroupレイヤーでこれらの集合演算をインターセプトし、StableHLO集合演算に変換します。StableHLO集合演算は、TPUハードウェアとICIトーラスによってネイティブに実行されます。FSDPやDTensorの観点からは何も変わりません。単に異なるバックエンドが見えるだけです。
PyTorch/XLA：遅延実行、同期ポイント、および実用的なヒント
TorchTPUは長期的な完全ネイティブパスではあるものの、PyTorch/XLAは依然としてTPU上でPyTorchを実行するための重要なツールである。CUDAのEager Executionに慣れている場合、PyTorch/XLAにおける最大の概念的変化は、テンソルが 怠惰な操作はグラフを記録します。実際の実行とコンパイルは、明示的または暗黙的に同期したときに発生します。
同期ポイントとは、PyTorch/XLAが構築済みのグラフをXLAに渡してコンパイルと実行を行う箇所のことです。典型的な障壁としては、次のような電話が挙げられます。 torch_xla.sync() または、より上位のユーティリティなど xm.optimizer_step(optimizer)これは、分散環境においてオプティマイザを段階的に実行し、デバイス間で勾配を同期させる機能です。
この遅延モデルはパフォーマンスに大きな影響を与える特定のグラフ（または新しい入力形状を持つグラフ）が初めて実行されるときはコンパイルコストがかかりますが、構造が安定している限り、その後の反復処理ははるかに高速に実行されます。これが、形状の安定性（固定シーケンス長、一貫したバッチサイズ）が PyTorch/XLA ワークロードにとって非常に重要な理由であり、 入力値を固定サイズにパディングする これは非常に一般的なパターンです。
PyTorch/XLA のマルチプロセス トレーニングは、独自の便利なツールを使用します通常はコアとなるトレーニング関数をラップします（例： _mp_mnist_fn）そして、デバイス間で起動します。 torch_xla.launchデータ読み込みは以下によって管理されます torch_xla.distributed.parallel_loader.MpDeviceLoaderこれは、標準的な PyTorch DataLoader を受け取り、各プロセスが一意のデータ シャードを参照できるようにしながら、バッチを適切な TPU デバイスにプリフェッチします。
TPU上でのデータロード、分散実行、およびAMP
効率的な入力パイプラインは、GPUと同様にTPUにおいても非常に重要である。PyTorch/XLA では、 MPデバイスローダー ホスト側のデータ読み込みとデバイス側の実行をオーバーラップさせ、バッチを直接TPUに供給することで、アクセラレータが新しいデータを待機している間の長時間のアイドル期間を回避するのに役立ちます。
分散トレーニングの場合、xm.optimizer_step(optimizer) は通常のオプティマイザステップ以上の処理を行います。デバイス全体で勾配全削減を実行し、それらを平均化し、重み更新を適用し、必要な同期を処理するため、通常は各イテレーションで個別の明示的な同期呼び出しは必要ありません。 xm.is_master_ordinal(local=False) 重複を避けるため、メトリクスとチェックポイントの処理は1つのプロセスのみが行うようにしてください。
TPUにおける自動混合精度演算（AMP）は、GPUにおけるものとは若干異なる動作を示す。TPUはネイティブにサポートしています bfloat16 (BF16)これはfloat16よりもはるかに広い指数範囲を提供し、通常は安定性のために明示的な損失スケーリングを必要としません。PyTorch/XLAはPyTorch AMPを拡張し、必要に応じてBF16とFP32の間で自動的にマッピングを行うため、TPU上での混合精度トレーニングが簡単かつ堅牢になります。
モデルの保存には、TPU固有のベストプラクティスも存在する。電話をかけることもできます トーチ.保存 デバイステンソルから、一般的には シリアル化の前に状態辞書をCPUに移動 PyTorch/XLAを使用する場合、標準的なGPUマシンなどのTPU非搭載ハードウェア上での再読み込みが容易になります。
Easy-torch-tpuと実世界のTPUトレーニングフレームワーク
公式スタックに加えて、コミュニティはTPUの導入を容易にするためのより高レベルのフレームワークを構築している。。 一例は aklein4/easy-torch-tpuこれは、Google Cloud TPU クラスター上での PyTorch/XLA ワークフローを簡素化するために特別に作成された軽量トレーニングフレームワークです。
Easy-torch-tpuは、Hypercomputer/torchprimeのような大規模で柔軟性に欠けるコードベースに代わる、よりシンプルで柔軟な選択肢として位置づけられています。その設計上の優先事項は明確です。簡単なセットアップ、分かりやすいカスタマイズ性、そしてスムーズな統合です。 gcloud sshクラスターワークフローを駆動します。意図的に「学術規模」の実験、つまり約32～64個のTPUチップ上で10億～1億のパラメータ範囲のモデルを対象としています。
拡張性はサブクラス化と設定ファイルによって実現される。新しいサブクラスを追加することで、独自のアーキテクチャ、トレーニングループ、オプティマイザ、データローダー、さらにはカスタムのシャーディングおよび再マテリアライゼーション戦略を組み込むことができます。これにより、フレームワークの分散処理とロギングの基盤を再利用しながら、自由に実験を行うことができます。
このフレームワークは主要なエコシステムツールと緊密に統合されています。重みとバイアスのサポートにより、実験の追跡が容易になり、Hugging Faceとの統合により、データセットの読み込み、事前学習済みチェックポイントの取得、および後で標準的なGPUベースのPyTorchで実行できるモデルの保存が簡素化されます。リポジトリにはインストール手順書、スターターサンプルが含まれており、コミュニティからのフィードバックに基づいて積極的に進化しています。
制限事項、デバッグ、およびパフォーマンス上の落とし穴
これらの改善にもかかわらず、TPU 上で PyTorch を実行することはまだ完全にスムーズとは言えません。大規模なモデルや動的なワークロードを扱う際に、どこで問題が発生する可能性があるかを理解しておくことは、多くの時間を節約することにつながります。
グラフの再コンパイルは、依然として最大の隠れたパフォーマンス低下要因の一つである。同期ポイント間で計算グラフや入力形状が変更されるたびに、XLAは再コンパイルが必要になる場合があり、その際に目立った一時停止が発生します。これは、言語モデリングや生成ワークロードでよく見られる、可変長シーケンスや適応型バッチサイズの場合に特に顕著です。
サポートされていない、または部分的にしかサポートされていないオペレーターは、知らず知らずのうちにパフォーマンスを低下させる可能性があります。PyTorch/XLA と TorchTPU は幅広い演算子カバレッジを目指していますが、一部の ATen 演算にはまだネイティブの XLA ダウンローイングがない場合があります。そのような場合、実行は CPU にフォールバックする可能性があります。これは技術的には正しいのですが、桁違いに遅くなる可能性があります。組み込みのデバッグユーティリティとメトリクス (例: torch_xla.debug.metricsCPUのフォールバックや予期しない再コンパイルが発生している箇所を特定するのに役立ちます。
Nsightやnvprofといった従来のGPUプロファイリングツールでは、TPUカーネルの内部構造は確認できません。その代わりに、ボトルネックを把握するために、XLA固有のプロファイリングフック、TPUランタイムメトリクス、および高レベルのログ記録に頼ることになります。多くのチームは、ベストプラクティス（静的な形状、慎重なデータロード、再コンパイルの監視）を採用すると、予測可能なパフォーマンスに迅速に収束することに気づいています。
Googleのコンパイラロードマップは、これらの問題点を明確にターゲットにしている。XLAにおける高度な境界付きダイナミズムの取り組みは、モデルが新たなコンパイルをトリガーすることなく、シーケンス長やバッチサイズの変化に対応できるようにすることを目的としています。また、TPUカーネルのプリコンパイル済みライブラリの拡充により、新しいグラフの最初のイテレーションにおけるコールドスタートのレイテンシを大幅に削減することを目指しています。
ロードマップとエコシステム：TPU上での摩擦のないPyTorchを目指して
今後の展望として、GoogleのTorchTPUロードマップは野心的であり、より広範なPyTorchエコシステムと密接に連携している。公開用のGitHubリポジトリが計画されており、そこには詳細なドキュメント、アーキテクチャチュートリアル、トレーニングとサービス提供の両方のシナリオに対応した再現可能なサンプルが含まれる予定です。
PyTorchのHelion DSLとの統合が間近に迫っているこれにより、XLAやハードウェア固有のコードの最も深い層に踏み込むことなく、カスタムTPUカーネルを作成するための開発者の選択肢が拡大されるはずです。動的な形状に対するネイティブで第一級のサポート トーチコンパイル 現代のシーケンスベースモデルの現実を反映して、これも優先事項の一つである。
マルチキューのサポートも重要な重点分野です。多くの本番環境におけるPyTorchコードベースは、非同期実行パターンとメモリ/計算ストリームの分離に大きく依存しています。これらの慣習を大規模なリファクタリングなしにTPUにスムーズにマッピングできるようにすることで、大規模で成熟したプロジェクトにおける移行の摩擦を大幅に軽減できます。
深いエコシステム統合は既に始まっているTPU Pod のフルサイズへの強力なスケーリングを検証し、vLLM や TorchTitan といった主要な PyTorch ベースのシステムと連携させるための取り組みが進められています。同時に、Google は Meta および PyTorch コミュニティと緊密に連携し、TorchTPU の主要部分をオープンソース化することで、普及と透明性の向上を加速することを検討しています。
これらすべては、TPU容量が劇的に拡大しているという、より大きなビジネス環境を背景としている。Google Cloudは数十億ドル規模のAIインフラ契約をさらに締結しており、Anthropicは最大100万個のTPU（ギガワット級の容量）へのアクセスを計画している。さらにGoogleはオンプレミスのデータセンター向けにTPUを直接販売している。TPUがGoogle社内専用のニッチなリソースだった時代はとうに終わった。
まとめると、PyTorch on TPU の話は「風変わりな脇道」から「標準的な選択肢」へと驚くほど速いスピードで移行している。TorchTPUのネイティブなEager Experience、PyTorch/XLAの実績あるLazy Execution、easy-torch-tpuのようなフレームワーク、そしてそれらを取り巻く豊富なCloud TPUインフラストラクチャのおかげで、主流のPyTorchモデルを（多くの場合、デバイス文字列の変更だけで）利用可能な最大規模のAIスーパーコンピュータ上で効率的に実行できるようになりました。スタックが新しい思考モデルを強制するのではなく、馴染みのあるPyTorchの慣用表現に収束していくほど、ハードウェアの選択を根本的な設計上の制約ではなく、実装の詳細として扱うことがより現実的になります。
