https://docs.google.com/forms/d/e/1FAIpQLScjDWvZ4yRMsnglidaDJDCE7eYfC_oiqfDzuGEfQCmENNjvVw/viewform - deadline： 2026/03/25(水) 23:59 (日本時間) - 発表時間：30分 ## 発表のタイトル / Title - SRE for AI/HPC：1000基規模のGPUクラスタにおけるSRE事例 <- これにする！ - 1000基のGPU規模で構成されるAIスパコンのためのSRE - 1000基のGPU規模のAIスパコンのためのSRE - SRE for AI Supercomputer on 1,000 GPUs - GPUクラスタのためのSRE - SRE界におけるAIスパコン：数百〜1000基規模のGPUクラスタの信頼性エンジニアリング - SREからみるAIスパコン探究 - SRE for AI/HPC：数百〜1000基GPUクラスタでのSRE事例 ## 発表の概要 / Abstract > 1000文字以内でご記入ください。採択された場合、この情報は SRE NEXT オフィシャルサイト上で公開されます。 LLMに代表される大規模なAI基盤モデルの分散並列学習は、多数の高性能GPU、高帯域・低遅延のインターコネクトネットワークや分散ストレージを統合した、HPC（高性能計算）分野のスーパーコンピュータ相当の計算機インフラを必要とします。さくらインターネットでは、主にAI学習向けに設計されたAIスパコン「さくらONE」をサービスとして提供しています。さくらONEは、世界スパコン性能ランキングTOP500にて、初号機が2025年6月世界49位、弐号機、参号機が同年11月に93位、136位にランクインしました。初号機はNVIDIA H100 GPU 800基、弐号機はH200 440基、３号機はB200 384基、４号機はB200 1000基以上で構成されています。 AIスパコンは、クラウド上のウェブアプリケーションとは異なる信頼性特性があります。ハードウェア障害の割合が大きいことや、ユーザーインターフェイスがジョブスケジューラであること、構成要素の一箇所の故障や劣化が、ジョブの停止や性能低下を引き起こすストラグラーを抱えやすい構造があります。そのため、障害パターンが異なる、あるいは、よく知られたSREのプラクティスやツールがそのまま適用できないケースが多々あります。AIスパコンは現在のAI開発の源泉となる重要なインフラですが、SREのコミュニティではその実態を知る機会はほとんどありません。 本講演では、一般的なウェブアプリケーションのSREと対比しながら、AIスパコンのためのSREをテーマに、1年半積み重ねた事例を紹介します。まず背景知識として、MetaやByteDanceなどのハイパースケーラーが発表した学術論文やUSENIX SREconでの講演をもとに、AIスパコンの信頼性に対する先端的なアプローチを解説します。 次に、さくらONEでのSRE事例として、2025年1-3月の障害件数20件などの実際に発生した障害の分析や、ユーザージョブの傾向分析、ジョブスケジューラSlurmに基づいたGrafana App Pluginの開発、教師なし機械学習によるAIOps、Slurmオペレーションの自動化、SLI/SLOを導入する難しさなどについて紹介します。 ## 聞いた人が得られるもの / Audience Takeaways* > この発表を聞いた参加者が何を持ち帰れるかを、200文字以内でアピールしてください。この情報は、採否を判断するための情報として、スタッフのみが閲覧します。 AIスパコンのSREとはどのようなものか、論文の知識と実システムの運用データを交えて概観できます。障害分析・アラーティング・オブザーバビリティ・オペレーション自動化・SLI/SLO設計など多様な事例を扱いながら、ウェブアプリケーションとの対比を通じて、馴染みのない環境での信頼性エンジニアリングのアプローチを学べるとともに、SRE本来の考え方を再確認する機会となります。 ## 発表の詳細 / Session Details* > 予定している発表の詳細を、3000文字以内で可能な範囲でご記入ください。詳しく書かれているほど、スタッフが採否を判断する際の助けになります。この情報は、採否を判断するための情報として、スタッフのみが閲覧します。想定しているセッションのアウトラインを具体的に記載することを推奨します。また、可能であればアウトラインの大項目に対して想定時間を記載してください。なお、必ずしも3000文字である必要はありません。 〇1. はじめに(5分) - なぜこの話をするのか？ AI基盤モデルの開発に必要な分散並列学習は、一つの巨大な計算ジョブを多数のGPUで分散協調して処理するワークロードである。そのため、要求される計算機インフラとして、GPUだけでなく、GPUメモリ上の計算結果を頻繁に同期するための高速なインターコネクト、トレーニングデータやモデルチェックポイントデータを読み込み・保存するための分散ストレージが重要となっている。 開発者がLLM開発に集中するために、このような巨大な計算機基盤を構築・運用するコストを低減する必要がある。 さくらインターネットでは、 主にファシリティ・ハードウェアレベルの収容・電力管理・冷却・修理対応を担うベアメタルサービス高火力PHYを提供している。これらに加えて、さくらONEはデバイスドライバーやCUDA、ジョブスケジューラSlurmなどのシステムソフトウェアの管理、分散ストレージの提供、クラスタの運用サービスを提供するいわゆるスーパーコンピュータである。 AIスパコンは、クラウド上のウェブアプリケーションとはワークロードや信頼性の特性が異なる。伝統的にスパコンでは、構成要素のどこか一箇所の故障や劣化が、ジョブの停止や大幅な性能低下を引き起こす。また、さくらONEというプラットフォームサービスとしての規約による制約により、ユーザージョブのログやスクリプトへのアクセスはできない。そのため、信頼性の責任範囲の切り分けが困難である。 本講演では、一般的なクラウドアプリケーションと対比したAIスパコンの特性、実環境でのSREに向き合った事例、サービス制約の範囲内で理想的な信頼性エンジニアリングへのギャップをいかに埋めるかの探究を紹介する。講演者は、ソフトウェアエンジニアの経験と博士学位を保持しているバックグラウンドを活かして、論文の知識と実システムでの運用事例を交える。 昨年では、さくらインターネットから「さくらONE」に関する類似のトピックで講演をしてきたが、「信頼性」に直接的に着目した講演は本講演が初となる。 ○2. AIスパコンの信頼性の前提知識(7分) 本節では、AIスパコンのためのSREに関する基礎知識と世の中の先端的な取り組みを紹介する。 AIスパコンのワークロードとシステム構成： 分散並列学習のワークロードの基本は、深層ニューラルネットワークの勾配計算と勾配同期のための集団通信である。勾配同期のために、データ並列やモデル並列など複数の並列手法を組み合わせ、複数のGPUノードが協調して単一のジョブを処理する。 AIスパコンのシステム構成は、１ベアメタルサーバあたり4〜8基のGPUが搭載され、ノード内の高速バス通信としてNVLink/NVSwitch/PCIeスイッチなどのノード内高速バス通信ネットワーク、ノード間を高速低遅延のRDMAネットワークで接続し、計算の途中経過を定期保存するチェックポインティングと大規模な学習データの並列読み出しを処理する分散並列ストレージとストレージネットワークにより構成される。 先端的な取り組みのサーベイ： USENIX SREconでは、直近2年の間に9件のAIインフラに関するトークがあり、AIインフラのためのSREが準主要なトピックの一つとして扱われている。SREcon25 AmericasにおけるAnt Group, "Transformers in SRE Land: Evolving to Manage AI Infrastructure"での特定GPUの問題を統計的機械学習により自動検知する手法の事例紹介を皮切りに、SREcon25 EMEAではBloomberg, Clockwork, Grafana Labs, Anthropicから、AI学習またはAI推論、GPU性能のeBPF計装などに関するトークがあり、そして、今年SREcon26 Americasでは、NVIDIA、ミシガン大学、TikTok、Clockworkから4件のトークがあった。 学術論文としては、MetaがHPCA2025で発表した "Revisiting Reliability in Large-Scale Machine Learning Research Clusters"がAIスパコンのSREに関する金字塔的な論文である。本論文では、Slurmのジョブログ11ヶ月分400万件のデータをもとに、ハードウェア故障率を分析し、ETTR、GoodputなどのAIスパコンならではの信頼性指標を設計している。 ○ 3. さくらONEにおけるSRE(15分) 本節では、特に学術論文との関わりのあるSREアプローチを紹介します。 障害分析とジョブの傾向： さくらONE初号機における2025年1-3月でのクラスタの利用傾向は、1）GPU占有時間の大半はユーザ主導の意図的な中断が占める一方、失敗ジョブのGPU占有時間は0.3%に留まった。2)小規模ジョブが大多数を占める一方、大規模ジョブがGPUリソース占有時間の大部分を消費している。3)ジョブの多くは短時間で終了するが、大規模ジョブでは実行時間の分布の裾が長い、4) プロジェクトの進行に伴い，大規模ジョブから中規模ジョブ中心へとリソース利用が推移している。 といった観察結果が得られている。 また同期間に、20件の障害が発生し、内訳はGPU故障9件、NVLink/NVSwitch3件、インターコネクトスイッチ5件、ストレージスイッチ1件、NIC1件、IPアドレス設定ミス1件である。しかし、これらの障害がユーザージョブに影響があったかを判定することは実は難しい。その理由としては、プラットフォームサービスの制約によりアプリケーションログにアクセスできないことから、ジョブの履歴上はステータスがFAILEDであっても、ユーザースクリプト側の問題かインフラの問題であるかを区別することは難しいためである。 （発表当日は、2025年4月以降のデータや他のクラスタのデータも含める予定） アラーティング： 障害分析を踏まえて、アラーティングの設計指針を示す。ウェブアプリケーションであれば、HTTPリクエストのエラー率やレイテンシの統計要約値を元にアラーティングすればよい。しかしながら、AIスパコンでは、前述したようにジョブの失敗が必ずしもプラットフォーマー側の障害要因とは限らない。そのため、ジョブの失敗率を指標としてアラーティングすることは有効ではない。そのため、GPUやNVLink/NVSwitch、NIC、ストレージなどの構成要素単位で、ユーザージョブの影響度合いに応じて、Severityを細かく仕分けし、 泥臭く設定している。 オブザーバビリティ： AIスパコンではジョブを基本単位としてワークロードが管理されるが、ジョブを基本にしたUIをもつオブザーバビリティツールがほとんどない。そこで、ジョブスケジューラSlurmを対象に、ジョブ単位でメトリクスを可視化するGrafana App Pluginを開発した。以前に講演者が主著論文として公開したMetricSifterを本プラグインに組み込み、メトリクスを教師なし機械学習で自動フィルタリングしている。 また、AIスパコンを構成する複雑なRDMAネットワークをNIC to NICで常時ping監視するために、ACM SIGCOMM 2025の論文で提案されたR-Pingmeshを再現実装した。 オペレーション自動化（トイルの削減）： Slurmで管理されたクラスタ向けに「問題のあるノードにジョブを流さない」ためのツールを開発した。ジョブ開始前後に自動でGPUノードの状態をヘルスチェックし、異常があればSlurmに介入してジョブの失敗を未然に防ぐ。 また、Grafana MCP Serverを使用したAIエージェントにより、Grafana Alert Managerの設定を自動化している。 SLI/SLO： MetaのHPCA2025の論文をもとにSLI/SLOを設計しようと試みたが、スパコンとしてのサービス仕様の差異により、そのまま採用することは難しい。そこで、さくらONE向けに簡易化されたSLO設計を紹介する。 ○ 4.まとめ(3分) SREに関する様々な取り組みを散発的に行ってきたが、まだ信頼性を中心に体系的にシステムの運用を設計できている感覚を持てていない。その大きな理由の一つは、プラットフォームサービスの制約によりユーザージョブの内部情報にアクセスできないためである。今後はeBPFによる自動計装や機械学習による推定などを導入して、制約の範囲で、信頼性にアプローチするよりよい方法を探究していく。 今後の発展的な取り組みとして、さくらONEやその他のクラウドサービスから得られたテレメトリーデータをもとに、時系列基盤モデルを開発していく。 --- - [[2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] - Ant Group, "Transformers in SRE Land: Evolving to Manage AI Infrastructure", https://www.usenix.org/conference/srecon25americas/presentation/ding - [[Transformers in SRE Land - Evolving to Manage AI Infrastructure at SREcon25 Americas]] - Bloomberg, Dashboards & Dragons: Reliability Magic for AI Platforms, https://www.usenix.org/conference/srecon25emea/presentation/griffith - Clockwork.io, Resilience for AI Workloads at Scale: The Fast and the Finicky!, https://www.usenix.org/conference/srecon25emea/presentation/ekmekcioglu - Anthropic, SRE for AI and AI for SRE, https://www.usenix.org/conference/srecon25emea/presentation/underwood - Grafana Labs, Auto-Instrumentation for GPU Performance using eBPF, https://www.usenix.org/conference/srecon25emea/presentation/grcevski - NVIDIA, "Operating Tens of Thousands of GPUs on Hyperscalers: Failure, Firmware, and the Illusion of Capacity", https://www.usenix.org/conference/srecon26americas/presentation/hoffman - University of Michigan, "Beyond Loss and Accuracy: Closing the Observability Gaps in AI Training with TrainCheck", https://www.usenix.org/conference/srecon26americas/presentation/jiang-yuxuan - TikTok, "Observability for LLMs: Understanding What’s Happening Under the Hood", https://www.usenix.org/conference/srecon26americas/presentation/munaf - Clockwork.io, "The Gashlycrumb Tinies of AI Networking You Must Know (or Languish!)", https://www.usenix.org/conference/srecon26americas/presentation/ekmekcioglu