> [!abstract] 概要(abstract の日本語訳) > TPUv4(Tensor Processing Unit)は、Google の機械学習訓練向け第3世代アクセラレータであり、カスタムの3Dトーラス型インターコネクトを備えた4096ノードのスーパーコンピュータとしてデプロイされている。本論文では、TPUv4スーパーコンピュータを大規模に運用するためのソフトウェアインフラを設計・運用した経験を述べる。これには自動的な障害耐性とハードウェア復旧のための機能が含まれる。我々は、光回線交換(optical circuit switching)を用いてマシン・チップ・リンクの障害を回避する経路を動的に構成する、ソフトウェア定義ネットワーキング(SDN)アプローチを採用し、TPUv4の高帯域チップ間インターコネクト(ICI)ファブリックを管理する。我々のインフラは障害を検知し、稼働中のワークロードへの中断を最小化するために再構成を自動的にトリガーするとともに、影響を受けたコンポーネントに対する修復・復旧ワークフローを開始する。同様の技術は、ハードウェアとソフトウェア双方のメンテナンス・アップグレードのワークフローとも連携する。我々の動的再構成アプローチにより、TPUv4スーパーコンピュータはシステム可用性99.98%を達成し、訓練ジョブの約1%が経験するハードウェア停止を優雅に処理する。 ## 論文情報 - タイトル: Resiliency at Scale: Managing Google's TPUv4 Machine Learning Supercomputer - 著者: Yazhou Zu, Alireza Ghaffarkhah, Hoang-Vu Dang, Brian Towles, Steven Hand, Safeen Huda, Adekunle Bello, Alexander Kolbasov, Arash Rezaei, Dayou Du, Steve Lacy, Hang Wang, Aaron Wisner, Chris Lewis, Henri Bahini(全員 [[Google]]) - 媒体: 21st USENIX Symposium on Networked Systems Design and Implementation(NSDI '24)、2024年4月16〜18日、Santa Clara, CA - URL: https://www.usenix.org/system/files/nsdi24-zu.pdf ## 概要 TPUv4は4096チップの3Dトーラス型 exascale スーパーコンピュータであり、光回線交換機(OCS)によるキューブ単位の再構成可能性(reconfigurability)と耐障害 ICI ルーティングを核心とする。本論文は、この OCS ベースの再構成アーキテクチャを支えるソフトウェアスタック(Pod Manager・Borg・libtpunet・healthd)と、トポロジ・ルーティング・スケジューリング・障害監視・ハードウェア修復にまたがるエンドツーエンドの耐障害運用を報告する。 ## 問題設定 大規模 ML 訓練は、ワークロードの静的シャーディングとギャングスケジュールされた実行に依存するため、稼働に必要な全計算資源が同時に健全である必要がある。これは以下の理由で年々困難になっている。 - LLM のような現代 ML モデルは前例のない量のハードウェア(計算・アクセラレータ・ネットワーク・ストレージ)を必要とし、期待 MTBF が時間〜分単位まで低下する。 - クラウド/共有クラスタ環境では多数のユーザーが資源のサブセットを奪い合うため、資源割当を継続的に再構成・再バランスする必要がある。 先行世代の TPUv2/TPUv3 は非再構成の固定 ICI メッシュを持つ「静的 pod」であり、以下3つの課題を抱えていた(§2.1)。 1. **ハードウェア停止**: 定期メンテナンスや予期しない障害が ICI リンク・TPU チップ・CPU ホストレベルで発生すると、スケジュール可能なプールから資源が除かれる。再構成性がない場合、1024 ホストを要するジョブの十分な可用性を得るには各ホストが 99.9% の可用性を維持する必要があるが、再構成可能な OCS を導入するとホスト可用性要件は 99% まで緩和される。 2. **ワークロードの断片化解消(defragmentation)**: 多数のジョブが pod のスケジュール可能資源のサブセットを奪い合うため、Borg は小さいジョブをプリエンプトして大きいジョブ向けに連続した TPU を確保する必要がある。OCS ベースの再構成性があれば、物理的な連続性を気にせず任意の空きキューブを OCS でクロスコネクトできる。 3. **デプロイのリードタイム**: 静的 pod は全ハードウェアが設置完了するまで使用できないが、再構成可能な pod では OCS のフットプリントが設置されればキューブは到着次第デプロイ・利用できる。 Figure 1(image: fig01-availability-vs-scale.png)は、TPUv3 の静的 pod と TPUv4 の再構成可能 pod(耐障害 ICI ルーティングあり/なし)について、必要 TPU 数に対するジョブ可用性を実測データで比較したものであり、TPUv3 は 1024 チップ手前で可用性が急落する一方、TPUv4 は約 3200 チップ(約50キューブ、94%)まで高可用性を維持することを示す(§2)。 **Figure 1: TPUv3 静的 pod と TPUv4 再構成可能 pod の可用性比較** ![[_attachments/nsdi24-zu/fig01-availability-vs-scale.png]] (Figure 1. TPU 数に対するジョブ可用性。青線が TPUv3(耐障害ルーティングなし)で 1024 チップ付近で可用性が 0 へ急落する。赤線が TPUv4(耐障害ルーティングなし)、黄線が TPUv4(耐障害ルーティングあり)で、いずれも約 3200 チップ・94% まで高可用性を維持し、それ以降緩やかに低下する。Source: Figure 1.) ## 提案手法 ### アーキテクチャ TPUv4 の計算資源は**キューブ**(cube)単位で組織される。1 キューブは 4x4x4 の 3D メッシュに配置された 64 個の TPU チップからなるハードウェア単位であり、1 スーパーコンピュータ(pod)は 64 キューブ・合計 4096 TPU で構成される(§2.2)。各 TPU マシンは PCIe で接続された CPU トレイと TPU トレイを持ち、TPU トレイは 4 個の TPUv4 チップを 2x2x1 の ICI メッシュで持つ。16 台の TPU マシンが 1 データセンターラックとしてグループ化され、ラック内 ICI リンクが 4x4x4 メッシュを形成してキューブを構成する(Figure 3)。 **Figure 3: 4x4x4 キューブのアーキテクチャ** ![[_attachments/nsdi24-zu/fig03-cube-architecture.png]] (Figure 3. 4x4x4 キューブは 16 台の TPUv4 マシンからなり、各マシンは 2x2x1 メッシュに配置された 4 個の TPU を持つ。TPU 同士は X/Y/Z 次元に沿った ICI(高帯域、赤線)で相互接続され、各面 16 本の光リンクが OCS へのクロスコネクトに使われる。CPU/NIC は低帯域の DCN(ToR・スイッチ、青線)経由でデータセンターネットワークに接続される。Source: Figure 3.) 各 3D キューブは X/Y/Z の各次元 6 面それぞれに 16 本の光 ICI を露出し、1 キューブあたり合計 96 ICI リンクを持つ。**TPUv4 スーパーコンピュータは 64 キューブから構成され、合計 6,144 本の光 ICI リンクが 48 台の独立した光回線交換機(OCS)に接続される**(§2.2)。CPU 側の低帯域データセンターネットワークは別系統で管理される。 Figure 6(image: fig06-ocs-cabling-64cube.png)は、この OCS 配線方式を図示する。各 OCS は 128 ポートを提供し、64 キューブすべてから 1 ポートずつを収容できる。1 つの OCS の各面(リング状に対向する 2 か所)から 2 本の光 ICI リンクが寄与される構成で、1 次元あたり 16 台の OCS が必要になる(3 次元 × 16 = 48 台)。 **Figure 6: OCS 配線方式(64 キューブ × 48 OCS)** ![[_attachments/nsdi24-zu/fig06-ocs-cabling-64cube.png]] (Figure 6. 64 キューブそれぞれが、リングの反対側にある 2 か所から 2 本の光 ICI リンクを 48 台の OCS のそれぞれに寄与する。1 次元あたり 16 台の OCS が必要。X 方向の OCS 群を示す例で、cube 0〜63 の X{0,in/out} 〜 X{15,in/out} ポートが対応する OCS の MEMS ミラーへ接続される。Source: Figure 6.) OCS は、Palomar Optical Circuit Switch([[Palomar Optical Circuit Switch]]、参考文献[25]、Jupiter Evolving, SIGCOMM 2022)を採用する。MEMS(micro-electromechanical systems)ミラーのアレイに基づく、ミリ秒オーダーで切替可能な N×N スイッチであり、論理的な北側の任意のポートと南側の任意のポートの間でプログラマブルなクロスコネクト(xconnect)を確立できる。Ni-Sj 間の接続が確立されると、別のポート組み合わせへ再構成されるまで専用の ICI リンク接続として機能する(§2.2)。 このキューブ単位のフォールトドメイン粒度(16 マシン)は、便宜性(ラック単位のデプロイ・電源・ネットワーキング)と、障害時の相対的に小さいブラスト半径とのバランスを取るために選ばれた。 TPUv4 の OCS 活用は低コストである点も強調される: **OCS と光ファイバのコストは TPUv4 pod の総資本コストの5%未満**であり、稼働電力も pod 総電力の3%未満に留まる。これは InfiniBand のようなパケットスイッチでスケールする代替案よりもかなり低コストである(§2.2)。 ### プログラマブル ICI プロトコル TPUv4 の ICI プロトコルは、再構成性と耐障害性の運用上の複雑さをソフトウェアで扱えるようプログラマブルに設計されている(§2.3)。1 TPUv4 pod は 1 つの ICI ドメインであり、任意の TPU ペア間で RDMA が可能。各 ICI リンクは 50GBps の単方向帯域幅を持つ。プロトコルは 4 層(Table 1)に分かれる: | レイヤー | 機能 | ソフトウェアエージェント | ISA 可視性 | |---|---|---|---| | Transaction | RDMA | XLA | あり | | Routing | パケット転送 | libtpunet | ヒント | | Data | リンク有効化・フロー制御・再送・順序配送 | libtpunet, healthd | なし | | Physical | リンクのクロスコネクト・ポートトレーニング | Pod Manager, chip mgr, healthd | なし | - **Physical Layer**: SERDES・PCS・リンク自動確立モジュールが伝送誤りにもかかわらず高速リンクを構築する。Pod Manager が OCS の MEMS ミラーを回転させて物理チャネルのクロスコネクトを制御し、チップ上のマネージャが物理リンクを自動初期化する。healthd がリンク品質・接続性のシグナルを継続的に読み取ってハードウェア健全性を追跡する。 - **Data Layer**: データはインオーダーで配送され、物理層でデータ損失があれば自動再送する。リンクレベルのクレジットベースフロー制御を強制する。データ層が有効化されると使用可能な ICI ユーザーセッションとなり、有効化前に全データバッファをクリアして前セッションの状態汚染を排除する。片方の端でデータ層が落ちると、機能的なセッションを保証するためもう一方の端も自動的に落とす。libtpunet がセッションの開始・停止コマンドを発行し、最適なフロー制御バッファサイズを調整する。healthd はオンラインリンク修復(§3.6.3)の際にデータ層リンクを明示的に無効化できる。 - **Routing Layer**: libtpunet がグローバル負荷分散を伴うパケット転送テーブルをプログラムする。RDMA 命令内の各パケットは送信元から宛先 TPU へ、宛先チップ ID をインデックスとした各チップの転送テーブルに従って進む。 - **Transaction Layer**: コンパイラが生成する RDMA 命令がハードウェア媒介の転送を開始し、メモリからデータを読み出して ICI スイッチへ供給する。個々の RDMA 群からなるトランザクションが集団通信操作を構成する。 (このプロトコルスタックは Figure 4 で a) TPU チップ構成(Host Interface・TensorCore・SparseCore・ICI Switch・HBM)と b) ICI スイッチ内部構成(Forward Table・tx buffer・Coding・SerDes)として図示されるが、代表図の選定範囲外のため本文引用に留める。) ### ソフトウェアインフラとジョブライフサイクル ユーザーが TPUv4 スーパーコンピュータ上で大規模ジョブを起動する際、希望する 3D スライストポロジ(4x, 4y, 4z)をメタデータとともに指定する(§3.1)。[[Borg]] クラスタスケジューラがリクエストをキューに入れ、スケジュール対象になるとキューブ候補集合を選び xconnect リクエストを発行する。Pod Manager が Borg を定期的にポーリングして保留中の xconnect リクエストを検出し、該当 OCS スイッチに MEMS ミラーを回転させて光 ICI 物理チャネルを確立するよう指示する。全 OCS のクロスコネクトが正しく完了すると、Pod Manager は Borg に確認を送る。承認後、Borg はジョブバイナリを選択されたマシン群にディスパッチし、preflight ヘルスチェックが各 TPU マシンの完全なハードウェア健全性を保証する(失敗すれば別キューブへ再スケジュール)。続いて libtpunet が ICI ネットワークをセットアップ(物理層・リンク層の検証と転送テーブルのプログラム)する。XLA TPU コンパイラが libtpunet の構築したスライストポロジ抽象を取り込み、自動並列化された TPU プログラムを生成する。 (Figure 5 は本文で詳述する Pod Manager・Borg・healthd・libtpunet・XLA の連携フローを図示するが、埋め込みは代表図の選定範囲外としたため図表番号のみ参照する。訓練中、フリートメンテナンスサービスが継続的に全 TPU マシンのハードウェア・ソフトウェア健全性を監視し、異常検知時は Borg へ通知、影響を受けたジョブは可能なら最新チェックポイントを書き込んだ上で再スケジュールされる。障害のあるハードウェアは診断・修復ワークフローへ送られる。Source: Figure 5, §3.1。) **データセンターモデルとスケジューリング**: ソフトウェアスタックの基盤は datacenter model であり、ラック・スイッチ・RPC エンドポイント等のエンティティグラフを表現する専用データベースに格納される(§3.2)。TPUv4 の重要エンティティは、TPUv4 キューブ(トレイ・チップ・静的 ICI 相互接続トポロジを含む 16 マシン)と、キューブから OCS への ICI ケーブリング・光学メタデータである。このモデルはキューブデプロイ・ジョブスケジューリング・OCS xconnect・ネットワークセットアップ・ヘルスチェックの意図を設定し、Borg と Pod Manager 双方の信頼できる情報源(source of truth)として機能する。TPUv4 トポロジはキューブサイズまでは静的にモデル化されるが、それ以上の形状は動的なキューブ xconnect を要する。 Borg Prime(複数レプリカ Borg インスタンスの論理的な集合)は各 TPUv4 ジョブへの適切なマシン割り当てを担当する(§3.3)。各 TPU マシンは borglet デーモンを実行し、Borg Prime と協調してジョブライフサイクルを管理する。計画メンテナンスや予期しないハードウェア障害への応答は、healthd からの重大な機械障害通知や Pod Manager からの OCS 問題通知、Repair Automation System・Package Manager からの通知など複数ソースから集約される。影響を受けた TPU マシンは利用不可とマークされ、実行中ジョブは通知付きで退避し、問題解決までペンディングジョブの割当対象から除外される。Borg Prime は優先度スケジューリングを実装し、断片化解消のため実行中ワークロードをプリエンプトすることもある(小さな複数 sub-cube ジョブの再配置、または大規模ジョブ収容のためのマルチキューブワークロードの別 pod への移動)。 **Pod Manager**(§3.4)は TPUv4 システムにとって重要な高可用サービスであり、Borg から独立した専用ネットワーク制御サーバー上で稼働し、Google の制御プレーンネットワーク経由で Borg・OCS スイッチ等と対話する。主要機能は (1) ユーザー要求のトポロジを構成する OCS xconnect の作成、(2) pod 健全性のリアルタイム監視、の2つ。もっぱらモデルデータ(§3.2)に依拠して自身のサービスを構成し、OCS エンドポイントや配備予定マシンの最新情報を定期的にポーリングする。プライマリ・ホットスタンバイのレプリケーション構成で高可用性を実現し、フォロワーはチェックポイントのコピーを継続的に受け取る(外部にも永続化)ことで高速フェイルオーバーを可能にする。Pod Manager はまた、全光スイッチのハードウェア健全性を RPC 経由で定期チェックし、このテレメトリは §3.6 のフリート健全性管理システムへエクスポートされると同時に、§4.2 の耐障害 ICI ルーティング最適化にリアルタイムで使われる。 **Torus xconnect(§3.4.1)**: 各 3D キューブは X/Y/Z 各次元 6 面に 16 本の光 ICI を露出し(合計 96 リンク)、Pod Manager は各リンクに一意識別子 {cube_id, dim, index, polarity} を割り当てる。48 台の OCS がこれらの ICI をクロスコネクトし(次元ごとに 16 台)、各 OCS には {dim, index} の一意識別子が付与される。1 台の OCS は 128 ポートを提供し、64 キューブ全てから 1 ポートずつを単一接続できるため、任意の (4x, 4y, 4z) トポロジ形状(4x4x4 単一キューブの full torus を含む)を構成可能。同じ {dim, index} パラメータを持つ ICI と OCS が接続されているため、あるOCSが利用不能になると、全キューブが同じ {dim, index} パラメータの ICI リンク 1 本の断線を観測する、という重要な性質がある(§3.4.1)。8x8x8 トーラスの xconnect 手順は4ステップで説明される(Step1: Borg がキューブ UID とトポロジを公開、Pod Manager が各キューブに 3D 座標を割当。Step2: 隣接情報の計算。Step3: 隣接キューブペア間の ICI xconnect 指示。48 全 OCS がコマンドを実行。Step4: 現在の構成とのdiffを取り、変更が必要な接続のみ RPC で xconnect)。 **Twisted-torus xconnect(§3.4.2)**: 通常のトーラスに加え、ユーザー要求があればツイストトーラストポロジもサポートする。ラップアラウンドリンクがベクトルオフセットでシフトされる方式で、TPUv4 は (4k, 4k, 8k) と (4k, 8k, 8k) の2種類の形状ファミリーをサポートする。キューブ座標はレギュラー/ツイストで同一だが、隣接とみなすキューブ面が変わり、Pod Manager は各 OCS に異なる north/south ポートの xconnect を指示する。 **libtpunet(§3.5)**: ICI 物理チャネルが xconnect 完了後に安定すると、Borg がジョブバイナリをホストマシンへディスパッチし、libtpunet がジョブ内で ICI ネットワーク(データ層・ルーティング層)をセットアップする。第一段階はトポロジ発見であり、ボトムアップに各 TPU のローカル隣接 ICI 接続情報をスキャンし、幅優先探索で設定済みグローバルトポロジがユーザー要求と一致することを確認する。この過程で各 TPU に一意なチップ ID が割り当てられ(RDMA 命令の ISA インターフェースの一部として露出)、迂回すべき障害や、システム抽象としてユーザーに露出すべき障害も識別される。続いて libtpunet がトポロジ発見中に集めた情報に基づき各 TPU の転送テーブルを計算・プログラムする(詳細は §4)。libtpunet はリンク RTT に比例したリンクレベルフロー制御バッファサイズも設定し、ジョブの分散 TPU 集合に一貫クロッキングを構成する(クロック構成は任意 ICI パスの最長 RTT を考慮した最小全域木で生成)。最後に libtpunet が ICI セッションを開始し、RDMA を伴う各種コンパイラ生成の集団通信オペレーションの利用を可能にする。ジョブ生存期間中、libtpunet は ICI セッションの健全性を監視し続け、TPU がエラーを観測する・リンク層がダウンする・ドライバがパニックする、のいずれかが起きると PCIe MSI-X 割り込みが発生し libtpunet が Borg に再スケジュールを通知する。 ### ハードウェアメンテナンスと復旧(§3.6) Google はグローバルフリート規模でハードウェア修理・交換や重大なソフトウェア/ファームウェアアップグレードといった破壊的メンテナンスイベントを扱うフリート自動化システムを運用する。フリートメンテナンス自動化システムからのイベントは Borg へ通知され、影響を受けたマシン上で稼働中のジョブを退避、再スケジューリングのためキューに入れる。疑わしい障害の場合、影響を受けたハードウェアは診断と技術者入力を伴う自動診断・修理ワークフローへ送られる。復旧したハードウェアは自動 QA プロセスを経て資源プールに復帰する。TPUv4 向けにはこのシステムを継続的な TPU ハードウェア健全性テレメトリ、ジョブ起動前の明示的な preflight チェック、オンライン ICI リンク修復のスキームで拡張している。 - **healthd(§3.6.1)**: 各 TPUv4 マシンにリアルタイム監視デーモンとして追加された。24 本の単方向 ICI リンク・TPU-CPU 間の PCIe チャネル・4 個の TPU ASIC 自体を含むハードウェア部品を監視する。各部品について healthd が収集するテレメトリデータに基づくハードウェア症状(symptom)が定義される。各 ICI リンクについてケーブル接続とリンク品質がモデル値・所定閾値に対し継続的にチェックされ、検知された症状は重大度でランク付けされ、深刻な症状は healthd が Borg に通知して影響を受けたジョブを退避・再スケジュールさせる。 - **Preflight Check(§3.6.2)**: 全ユーザージョブの実行前に走るチェック。2種類あり、end-to-end チェックはミニサンプルワークロードを実行して TPU ハードウェアを検証(TPU ドライバ・ファームウェア・libtpunet 等の相互作用を含む広範なカバレッジ)、intent-driven チェッカーは物理レベルのハードウェアメトリクスをゴールデン閾値と照合(サブスタンダードなリンク品質等、目立たない問題の検知を可能にする)。preflight が失敗すると borglet が Borg Prime にジョブの再スケジュールを指示する。 - **Online ICI Link Repair(§3.6.3)**: TPUv4 では ICI リンク修復をオンラインで実施でき、リンクの両端(2 台のマシン、またはマシンと OCS スイッチ)にまたがって自動的に協調し、信頼性高く検証できる。Pod Manager は ICI リンクドレインを通じて全 ICI ネットワークメンテナンスを調整する。ドレインされた ICI リンクはユーザーアプリケーションから自動的に除外されるが、破損 ICI を使わない限り TPU 計算資源は影響を受けない(そのマシンへジョブがランド可能)。 ## 新規性 先行研究(TPUv2/v3 の静的 pod、参考文献[19][20])では、compute 資源が固定的な物理隣接に結び付いていたため、資源利用率・断片化解消・デプロイリードタイムの3課題を抱えていた。TPUv4 は Palomar OCS を用いて ICI ファブリックそのものを SDN 的に再構成可能にすることで、キューブ単位の柔軟な組み替え・耐障害ルーティングを実現する。Related Work(§6)で著者らは、OCS の本番データセンターネットワークへの利用自体は既に Jupiter Evolving([[Palomar Optical Circuit Switch]] の元論文、参考文献[25])で報告済みであり、本論文は「OCS を TPUv4 スーパーコンピュータの利用に特化して適用した」点、および「著者らの知る限り exascale スーパーコンピュータに対してこのアプローチを説明した初めての報告」である点を新規性として位置づける。NVIDIA の 2 階層 NVswitch ベース fat tree(NVLink 上)との比較では、OCS は共有トラフィックを制御する必要のある専用物理チャネルを確立するため、パケットスイッチ導入よりもネットワーク設計を単純化し、購入価格とスタンバイ電力の低さが運用コストも下げると位置づける(§6)。 ## 実験設定 - 対象システム: 2 年間の本番運用データを持つ Google の TPUv4 スーパーコンピュータ群(§5「Fleet Statistics」)。ハードウェア: TPUv4 チップ・ICI ケーブル・OCS。 - 評価軸: (1) OCS xconnect 頻度とジョブ投入数の相関、(2) ハードウェア(マシン・ICI ケーブル・OCS)の週次平均故障率、(3) 耐障害 ICI ルーティングを利用するジョブの割合、(4) 耐障害ルーティングによる代表ワークロード(RM/LLM/BERT)への性能影響。 - 性能評価(表2)は、正常時と単一 OCS 故障時の全対全(all-to-all)スループットを 3 スライス形状(4x4x4, 4x4x8 twisted, 4x8x8 twisted)で測定。 ## 実験結果 ### キューブ再構成の規模(§5.1) Google の TPUv4 スーパーコンピュータには毎日数千の訓練ジョブが投入される。あるスーパーコンピュータの 2 か月間サンプルで、ジョブ投入数が多いほど OCS xconnect 変更も増える傾向が示され(Figure 13)、TPUv4 スーパーコンピュータ全体では 1 pod あたり 1 日に数万件の OCS xconnect 変更が発生するという。ワークロードのトポロジは sub-cube の小規模実験から pod の大半を使う LLM 事前学習まで幅広く、埋め込み重視のレコメンデーションモデルはツイストトーラスを、一部の transformer 系モデルはより不規則なトーラストポロジでのモデル並列を採用する傾向が観察された。 ### ハードウェア故障率(§5.2、Figure 12) Pod Manager と healthd が修復・復旧プロセスを自動化する。**平均的なスーパーコンピュータでは、毎日 TPU マシンの 0.08%・ICI ケーブルの 0.005%・OCS の 0.04% が故障を経験する**。これらの値自体は小さいが、各スーパーコンピュータが多数のマシン・ICI・OCS を持つため、影響を受けるジョブ数は非自明である。マシン・ICI 停止は予備の健全キューブへの再構成で自動的に許容される。OCS の停止はスーパーコンピュータ内の全キューブに影響しうるためブラスト半径が大きく、耐障害 ICI ルーティングによってある程度の性能影響を伴いつつ OCS 停止を許容し、他コンポーネントよりも OCS コンポーネントの復旧を優先することでこの影響を最小化している。 **Figure 12: 週次ハードウェア故障率統計(a: マシン, b: ICI リンク, c: OCS)** ![[_attachments/nsdi24-zu/fig12a-machine-failure-rate.png]] (Figure 12(a). マシンの日次平均故障率[%]の週次推移(約100週)。0.04〜0.15%のレンジで周期的に変動する。Source: Figure 12(a).) ![[_attachments/nsdi24-zu/fig12b-ici-link-failure-rate.png]] (Figure 12(b). ICI リンクの日次平均故障率[%]の週次推移。0.002〜0.013%のレンジで、マシンより小さい絶対値だが同様に周期的スパイクを示す。Source: Figure 12(b).) ![[_attachments/nsdi24-zu/fig12c-ocs-failure-rate.png]] (Figure 12(c). OCS の日次平均故障率[%]の週次推移。0.01〜0.08%のレンジで変動し、週 30〜40 と週 60〜65 付近に高いピークが見られる。Source: Figure 12(c).) これら3系列は §5.2 本文が述べる「TPU マシン 0.08%・ICI ケーブル 0.005%・OCS 0.04%」という平均値の元になった時系列であり(論文は集計平均値のみを本文に明記し、グラフ自体には集計値のアノテーションはない)、いずれも一定の周期的な変動を伴いながら、マシン故障率が3系列の中で最も高い水準で推移することを示す。 ### 耐障害ジョブの割合と性能影響(§5.3) これまでの経験上、**全 TPUv4 訓練ジョブの95%が耐障害 ICI ルーティングをオプトインし**、OCS 停止に対する耐性を得ている。残り5%は異なるルーティング戦略による性能非決定性を避けるためオプトアウトする。8か月間のサンプル期間でフリート全体のジョブのうち耐障害ルーティングを実行中の割合は、通常時いつでも2%未満に留まる(Figure 14)。この割合は OCS メンテナンスイベントとイベントあたりの復旧時間と強く相関しており、60日目付近のスパイクは信頼性向上を目的とした計画的なフリート全体の OCS 部品アップグレードによるものである。 **Figure 10: OCS 不可用時の ICI リンク障害パターン** ![[_attachments/nsdi24-zu/fig10-ocs-fault-pattern.png]] (Figure 10. 4x4x8 トーラスの X 次元に沿って1台の OCS が不可用になった例。不可用な OCS により、トーラスの1つの XZ 平面上で2本の X リンクが不可用になる(破線赤)。他の XZ 平面は影響を受けない。OCS 接続性(Figure 6)に起因して、不可用リンクは Z 方向に4ホップごとに周期的に繰り返す障害パターンを形成する。Source: Figure 10.) 耐障害 ICI ルーティングは、故障リンク周辺の輻輳増加によって性能ペナルティを伴う。負荷不均衡は all-to-all・all-reduce を含む集団通信操作に影響する。表2(正常時と単一 OCS 故障時の all-to-all スループット比較)と表3(耐障害ルーティングによる代表ワークロードのステップタイム低下率)を本文の記述から転記する。 **表2: 正常時 vs. 単一 OCS 故障時の all-to-all スループット(§4.3)** | スライス | 故障なし(GB/s) | 単一故障(GB/s) | 単一故障(故障なし比) | |---|---|---|---| | 4x4x4 | 75.9 | 70.0 | 92.2% | | 4x4x8 twisted | 62.1 | 63.2 | 101.7% | | 4x8x8 twisted | 54.3 | 53.7 | 98.8% | (Table 2. レギュラートーラスでは単一 OCS 故障により理想的 all-to-all 性能が 15/16 ≈ 93.4% に低下する(4x4x4 キューブを OCS へ接続する16リンクのうち1本を失うことに相当)。興味深いことにツイストトーラスは 4x4x8 で故障時に性能がわずかに向上しており、これはタイブレークの柔軟性による負荷の次元間シフトが可能なためで、レギュラートーラスでは不可能。) **表3: 耐障害 ICI ルーティングによるステップタイム低下(§5.3)** | ワークロード | トポロジ | ステップタイム低下率 | |---|---|---| | RM-1 | 4x4x8 twisted | 0.5% | | RM-2 | 4x4x8 twisted | 3% | | RM-3 | 4x4x8 twisted | 3.9% | | RM-4 | 4x4x8 twisted | 8.6% | | RM-5 | 4x4x8 twisted | 8.3% | | RM-6 | 4x4x8 twisted | 4.7% | | LLM-1 | 4x4x8 | 2.6% | | BERT-1 | 4x4x4 | 1.2% | | BERT-2 | 4x8x8 | 3.2% | (Table 3. Recommendation Models(RM)・Large Language Models(LLM)・BERT ベースモデルにまたがる主要 Google ワークロードでの実測。all-to-all ヘビーなワークロードでは、オフラインルーティング最適化器が all-to-all 性能を維持ないし改善するため低下は顕著でない。特に埋め込み重視のツイストトーラス形状で顕著。all-reduce ワークロードは近傍通信パターンが50%のスループット低下を受けるためより大きな性能影響を経験する。全体としてはすべてのワークロードでステップタイムのわずかな低下に留まる。) ## 考察 著者らは、TPUv4 の OCS ベース再構成性が可用性・スケジューリング柔軟性・コストの3面で静的 pod を優越すると総括する。特に、OCS 故障の周期的パターン(Figure 10)は cube-OCS 接続性に起因して高い対称性を持ち、これがオフライン整数線形計画法(ILP)によるルート最適化を可能にする(§4.3)。ILP は並進対称性を利用して変数数を削減し、実運用サイズのネットワークで最適解を実用的な時間で求められる。ツイストトーラスにおける OCS 故障時のわずかな性能改善(表2)は、ILP 定式化が実世界性能の近似に過ぎないことを示す好例として位置づけられている。 TPUv4 は前世代比で約 2.1× の性能を提供しつつ、キューブレベルの再構成性と耐障害 ICI ルーティングによりスイッチ故障時にも稼働を継続できる点を成果として結論づける(§8)。このソフトウェアは 2020 年から本番稼働しており、Google Cloud クラスタと社内ユーザーの双方で TPUv4 スーパーコンピュータを運用し、99.98% のシステム可用性を維持している。 ## 強み / 弱点・課題 **強み**: - OCS を用いたキューブ単位再構成性により、静的トーラスが抱える「大規模ジョブほど可用性が急落する」問題を構造的に解消し、実測データ(Figure 1)で裏付けている。 - 故障率(TPUマシン0.08%・ICIケーブル0.005%・OCS0.04%)、コスト(資本の5%未満・電力の3%未満)、可用性(99.98%)、耐障害ルーティング採用率(95%)といった、大規模本番運用でしか得られない一次データを具体的な数値で開示している。 - 障害検知(healthd)・診断・修復・再構成(Pod Manager)・ルーティング最適化(ILP)を一貫したソフトウェアスタックとして統合し、ハードウェアとソフトウェアの共設計(co-design)による解決を提示する。 **弱点・課題(著者らが明示する Future Work、§7)**: - 現行のルーティングは静的な事前計算フォワーディングテーブルに基づくため、ジョブ起動後の動的な負荷分散はできない。著者らは今後 ICI スイッチにランダム化ルーティング機能を導入し、トーラス・ツイストトーラス双方で障害存在下の負荷分散、特に近傍通信パターンの改善を計画している。 - 現状は障害発生時にジョブを中断・チェックポイントから再開する設計であり、著者らは OCS ベースの再構成性とワークロード再構成のより密な統合(障害発生時にホットスタンバイキューブへアクセラレータ状態を永続チェックポイントを経由せず直接マイグレーションする)を将来の課題としている。これには Borg スケジューラ・libtpunet・Pathways ML ランタイムへの変更を要する。 - 本論文自体は評価対象を Google 内の非公開データセット(社内代表ワークロード RM/LLM/BERT の実測)に限定しており、外部で再現可能な公開ベンチマークによる定量評価ではない。