# AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性 ## 概要 2025 年 12 月 22 日の情報処理学会中国支部主催講演会資料。AI スパコンを、深層学習ワークロード、GPU と集団通信、クラスタ構成、さくら ONE の実測、学習ジョブ履歴、MLPerf 型ベンチマーク、オブザーバビリティ、障害管理研究動向の順に縦断して説明する。既存の [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] が論文として詳細な測定結果を提示するのに対し、本資料は講演向けに、なぜ AI スパコンでテレメトリ・計装・ネットワーク監視が必要になるかを概念地図として整理する。 公式ページでは、講演日時は 2025 年 12 月 22 日 15:00-16:30、講師は [[Yuuki Tsubouchi|坪内 佑樹]] 氏(さくらインターネット株式会社 さくらインターネット研究所 上級研究員)と記載される。SpeakerDeck の説明欄も同じ講演概要を掲げ、LLM 学習には数百から数万基の GPU、高帯域・低遅延ネットワーク、分散ストレージを統合した AI スパコンが不可欠で、ボトルネックや原因特定が困難になるため観測性向上とテレメトリ分析が研究されていると位置づける。 ## 主要メッセージ - AI 学習ワークロードは計算機・ネットワークアーキテクチャを逆向きに規定する。Transformer の大規模な行列積和演算は GPU の多数コア・Tensor Core・HBM に適合し、モデル大型化はメモリ壁とノード間通信をボトルネックにする(p.14-20, p.28, p.41)。 - 分散学習では、データ並列、パイプライン並列、テンソル並列、シーケンス並列、3 次元並列を、NVLink/NVSwitch と RDMA/RoCE の階層に合わせて配置する必要がある(p.24-35, p.38-45)。 - [[SAKURAONE]] は TOP500 ISC 2025 で世界 49 位、IO500 で世界 9 位を示し、2025 年 11 月時点では CYC/CYB を加えた 3 クラスタ構成として説明される(p.54-57)。 - SAKURAONE の GPT-3 175B 事前学習ベンチマークは、未検証値ながら MLPerf Training の比較軸で 32 ノード 105.310 分、96 ノード 41.862 分を示し、ノード数 3 倍に対し学習時間 2.51 倍短縮、MFU 38.3% から 35.9% という範囲に収まる(p.74-81)。 - AI スパコンサービスでは責任境界が観測性を制約する。プロバイダはユーザーのアプリケーションコード計装やアプリケーションログ取得ができないため、まず GPU・NIC・ストレージ・Slurm 履歴などのリソース分析を OTel + Grafana で整備し、次にワークロード分析へ踏み込む(p.85-101)。 - 未解決ギャップは、学習処理過程のボトルネック特定、アプリケーションかインフラかの切り分け、マイクロバースト監視の 3 点で整理される。GPU ゼロコード計装、R-Pingmesh 型の RoCE 能動プロービング、障害管理研究の観測点・診断アルゴリズム・侵入度の分類が対応する研究方向になる(p.102-124)。 ## 口頭説明・補足 - 講演者の自己紹介では、はてなでの Mackerel 立ち上げや SRE、さくらインターネット研究所、京都大学岡部研究室での博士後期課程を経て、クラウドアプリケーションのテレメトリ・信頼性技術を GPU/HPC へ拡張しているという経緯が補足される。 - 講演の狙いは、AI 学習ワークロードを起点に計算機・ネットワークアーキテクチャが最適化される状況で、処理性能低下や障害時対応にテレメトリ技術で貢献することに置かれる。 - SAKURAONE のジョブ履歴では、GPU 電力のヒートマップからクラスタの空き状況を把握し、空きが多い期間には顧客側の管理者がジョブ投入を促す運用が語られる。 - 第 3 章の口頭まとめでは、64 ノード級の大きめのジョブで途中フェイルする性能劣化・安定性問題があり、数週間で修正できても不安が残るため、安定していた 32 ノードへ寄せる判断が起こったと説明される。これは、LLM 開発では最高性能だけでなく「安定に開発を進められること」が重視されることを示す。 - 故障対応では、SAKURAONE はリザーブドノードを契約してもらい、故障ノードを一旦サービスアウトして代替ノードで継続し、その間に NVIDIA やスイッチベンダーへ修理依頼する形が現実的とされる。 - 集団通信中の GPU 故障に対する即時切替は、集団通信が固定メンバーで進む前提を持つため難しく、現時点ではチェックポイントからの復旧が標準的な期待値として説明される。 - 推論ワークロードは TTFT や最終応答までの時間などレイテンシ指標が中心で、GPU 故障時は別 GPU へルーティングできるため、学習より障害管理がやりやすい可能性がある。ただし、講演時点の同社推論サービスは大規模展開前とされる。 - 顧客ワークロード予測は、LLM 単体なら Transformer の通信パターンが比較的予測可能でも、顧客ごとの開発計画や通常 HPC ワークロードの混在までは見通せないため難しいと説明される。 - Transformer へのインフラ投資がいつまで妥当かは社内でも読めない論点として語られる。一方で、積和演算中心の構造が続く限り GPU は比較的転用可能で、変化が大きい場合はソフトウェアスタックの更新が必要になりうる。 - グローバルバッチサイズなどのチューニングは、自動調整ツールがあっても代表的なパラメータ組み合わせから少しずつ調整する試行錯誤が残ると補足される。 ## Q&A - **障害時の復旧**: 高価な GPU ノードが故障した場合、リザーブドノードへ交換して利用を継続し、故障ノードはサービスアウトして修理する。ハードウェア故障は自社だけで直せない範囲があり、GPU ベンダーやスイッチベンダーとの切り分けを要する。 - **故障率のばらつき**: 国内事業者間でも GPU クラスタの故障率に関する実感は異なり、空冷/水冷や温度管理などの要因が絡む可能性がある。講演者の認識では、同社環境は極端に故障が多い側ではない。 - **集団通信中の GPU 故障**: 学習中の瞬時 GPU 切替は現実的でなく、チェックポイント復旧が標準になる。したがって、学習クラスタではストレージの信頼性も復旧設計の一部になる。 - **推論との違い**: 推論はスループットだけでなく TTFT と応答完了までのレイテンシを分けて測る。故障時はリクエストを別 GPU にルーティングできるため、学習より復旧設計の自由度が高い可能性がある。 - **AI 計算特性の予測**: LLM の 1 ジョブ内通信パターンは予測しやすいが、サービスとして受ける顧客ジョブ全体や将来ロードマップは読めないため、平均的な設計目標を狙うしかない。 - **Transformer 以後**: Transformer 最適化に大きく投資するリスクは認識されているが、現時点では事前学習はまだスケールする印象が強い。GPU は汎用演算器なので、積和演算中心なら転用可能だが、ソフトウェアスタックは変わりうる。 - **データ・同期・チューニング**: Transformer でテンソル並列を使う限り、細かく分割してすぐ同期する構造は残る。同期を減らして後でマージできれば通信量は減るが、計算依存関係上は難しく、インフラ側だけで工夫できる余地は限られる。 ## 視覚的に重要な図表 **p.57 さくら ONE の 3 クラスタ** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-057.png]] 第一クラスタ(H100)、第二クラスタ CYC(H200)、第三クラスタ CYB(B200)の計算ノード数、GPU、CPU、メモリ、ストレージ、インターコネクトを並べ、さくら ONE が単一クラスタでなく世代の異なる複数クラスタ群として扱われることを示す。 **p.78 GPT-3 事前学習のスケーリング評価** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-078.png]] 32 ノードと 96 ノードの time-to-train、MFU、TFLOPS/GPU、tokens/sec/GPU を並べ、ノード数増加に対する学習時間短縮率と効率低下を定量化する。 **p.85 AI スパコンサービスのオブザーバビリティ** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-085.png]] ユーザー視点の学習処理性能・計算資源利用率と、プロバイダ視点の障害・故障管理・計算資源利用率を、ワークロード分析とリソース分析に分ける。 **p.99 データパイプラインの構成** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-099.png]] GPU ノード、ログインノード、インターコネクトスイッチから OTel Collector Gateway を経由し、VictoriaMetrics、VictoriaLogs、Pyroscope、Grafana へ流す構成を示す。 **p.105 深層学習の処理過程をトレースしたい** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-105.png]] 順伝搬、逆伝搬、重み更新、集団通信をスパンとして扱い、各スパンの経過時間やリソース消費を測りたいという、学習ワークロードトレーシングの目標粒度を示す。 **p.114 R-Pingmesh** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-114.png]] RNIC to RNIC の能動プロービングで RoCE ネットワークを監視し、サービストラフィックに対応した RNIC 単位のプロービング、RoCE パケットによるプローブ、継続的な RTT・パケットロス計測を組み合わせる。 **p.121 主要な研究トレンド** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-121.png]] AI スパコン障害管理研究を、観測点(ホスト/アプリ内部からネットワーク・インフラへ)と分析手法(ドメイン知識活用から機械学習活用へ)の 2 軸で整理する。 **p.126 まとめ** ![[_attachments/ai-supercomputer-llm-benchmarking-and-observability/page-126.png]] 深層学習と計算機アーキテクチャ、さくら ONE 構築、ジョブ分析とベンチマーキング、可観測性の向上と課題を 1 枚に集約する。 ## 概念・実体への接続 - [[Yuuki Tsubouchi]]: SRE/AIOps から AI スパコンの性能計測・可観測性へ研究領域が広がったことを、講演者本人の研究年表として示す。 - [[SAKURA Internet]] / [[SAKURAONE]]: マネージド GPU スパコンサービスとしての構成、TOP500/IO500、3 クラスタ展開、MLPerf 型ベンチマークの実測を扱う。 - [[LLM分散学習]] / [[並列化戦略]] / [[集合通信]]: DP/PP/TP/SP/3D 並列と AllReduce/AllGather/ReduceScatter を、GPU メモリ壁とノード間通信ボトルネックに接続する。 - [[GPU観測性]] / [[LLM学習モニタリング]]: GPU プロファイラのユーザー管理・重いオーバーヘッド、Zero Code 計装の限界、学習処理過程の分散トレース化を課題として接続する。 - [[RDMAネットワーク監視]] / [[R-Pingmesh]]: NCCL エラーだけではアプリケーション側かネットワーク側かを切り分けにくい問題に対し、RoCE 能動プロービングを補助線として示す。 ## 限界・不確実点 - transcript は添付テキストを `.raw/slides/ai-supercomputer-llm-benchmarking-and-observability/transcript.md` に保存して参照した。ただし自動文字起こし由来と思われる誤認識・重複があるため、数値・固有名・スライド対応は PDF と公式ページを優先する。 - 文字起こしは 59:58 までで終わっており、講演全体または質疑応答の全てを含むかは不明。 - SpeakerDeck ページ上に公開日を明示する行は確認できなかった。`date_published` は公式講演ページの講演日 2025-12-22 を採用した。 - ベンチマーク値にはスライド上で `unverified` と明示されたものが含まれる。MLCommons による検証済み結果とは区別する必要がある。 - p.90-98 の Grafana スクリーンショット内の細かな数値やタイムスタンプは、contact sheet では読めない箇所があるため、source ページでは構造と用途に限定して記述した。