30分 エンジニアのテックカンファレンス講演にふさわしい硬派な講演タイトル案を10個考えてください。 ## 1. 発表タイトル、概要（500字以内） - AIスパコン「さくらONE」のオブザーバビリティ - LLM分散学習基盤のオブザーバビリティ LLMなどの大規模なAI基盤モデルの学習は、ハイエンドGPU、高帯域・低遅延のインターコネクトネットワークや分散ストレージを統合した高性能計算機インフラを必要とします。さくらインターネットでは、この要件に最適化したAIスパコン「さくらONE」を開発し、スパコン性能ランキングTOP500で世界49位を獲得しました。講演者は「さくらONE」を対象にオブザーバビリティを向上させる研究開発を行っています。そこで本講演では、 1. 前提知識：分散学習のワークロードとその基盤の特性が、オブザーバビリティ業界が主に対象とするウェブアプリケーションの特性とは大きく異なること 2. さくらONEの事例：実際に収集しているテレメトリーデータとその活用例、および、VictoriaMetrics、VictoriaLogs、Pyroscope、otel-ebpf-profiler、Grafanaを用いたデータ収集・分析システム 3. 最先端の研究動向：eBPFによるGPU処理の計装法など論文で提案されている手法 を紹介します。 ## 2. 参加者が得られる学び (500字以内目安） 想定参加者は、分散学習の基盤開発に関わるエンジニアと、大規模AIモデルの開発がどのようなインフラに支えられ、どのように運用されているかを知りたいエンジニアとなる。前者のエンジニアの方々に対して、実体験に基づいた運用に役立つ技術的知識と最先端の論文に関する知識を提供する。特にデータ分析の際に具体的な勘所や結局使わなかったデータの事例共有する事例は少ない。一方で分散学習の基盤開発に関わる人はそう多くはない。そこで、後者のエンジニアの方々に対して、AIスパコンのような馴染みのないシステムのオブザーバビリティを高めていく事例を提供することで、オブザーバビリティ自体の理解を深めるディスカッションの機会になれることを期待している。 ## 3. 発表の詳細 (1000字以内目安） 本講演では、AIスパコンのオブザーバビリティにおける「見る力」にフォーカスする。 1. はじめに (5分) LLM分散学習は、一つの巨大な計算ジョブを多数のGPUで分散協調して処理するワークロードである。そのため、要求される計算機インフラとして、GPUだけでなく、GPUメモリ上の計算結果を頻繁に同期するための高速なインターコネクト、トレーニングデータやモデルチェックポイントデータを読み込み・保存するための分散ストレージが重要となっている。 開発者がLLM開発に集中するために、このような巨大な計算機基盤を構築・運用するコストを低減する必要がある。 さくらインターネットでは、 主にファシリティ・ハードウェアレベルの収容・電力管理・冷却・修理対応を担うベアメタルサービス高火力PHYを提供している。これらに加えて、さくらONEはデバイスドライバーやCUDA、ジョブスケジューラSlurmなどのシステムソフトウェアの管理、分散ストレージの提供、クラスタの運用サービスを提供するいわゆるスーパーコンピュータである。 講演者はこのAIスパコンを題材に研究開発する機会に恵まれたが、分散学習のワークロードにもスパコンに関する知識も経験もほとんどなかった。そのため、システムの動作のメンタルモデルを獲得するために、さくらONEのオブザーバビリティを必要としていた。 本講演の目的は、ウェブアプリケーションと対比したLLM学習の特性、実環境でのオブザーバビリティに向き合った事例、未だ不足するオブザーバビリティをどう埋めるかの研究動向を紹介することである。 2. AIスパコンの前提知識 (7分) - 分散学習のワークロード - ニューラルネットワークの勾配計算、同期のための論理通信、データ並列とモデル並列。 - AIスパコンのシステム構成 - H100/H200/B200などのGPUスペック、ロスレスネットワークの特性、ストレージの性能特性。 - 一般的なテレメトリー - メトリクス・ログ・プロファイルが主体だが、通常のプロファイリングは実行オーバーヘッドが大きく、問題調査のときのみ有効化される。 - OpenTelemetry文脈での分散トレーシングに相当する概念はない。 - AIスパコンの性能指標 - 実行時間：学習時間 - スループット：FLOP/s（単位時間あたりの浮動小数点数演算数）, TPS(Tokens per sec) - 効率性：実効演算スループット / 理論演算スループット - 消費電力 2. さくらONEの事例（13分） - さくらONEの計算機システムは、NVIDIA H100 GPU 800基、Edge core SONiC搭載の400/800GbEのインターコネクトスイッチ、DDN Lusterストレージ、ジョブスケジューラSlurmにより構成されている。 - ベアメタルサーバーにより構成されており、マルチテナンシーはLinuxユーザー権限レベルで分離される。 - メトリクスとして、Node、Process、DCGM、SONiC、LusterFS、IPMI、Slurmなどの各種Exporter、最小5秒の解像度、ログとしてOSカーネルログとSlurmの管理ログとスイッチのsyslog、プロファイルとしてPythonの関数レベルでのCPUプロファイルを収集している。 - 学習性能をチューニングしたいか、信頼性を確認したいかで着目するデータが異なる。学習性能をみたければ、DCGMのGPUのTensor Coreの利用率などをみる。信頼性については、DCGMのXID errorなどをみる。 - 念のため収集しているがみていないデータも多い。例えばProcess ExporterやCPUプロファイルデータは活用できていない。 - テレメトリーシステム構成： - オブザーバビリティバックエンド：VictoriaMetrics (252K ingestions/sec)、VictoriaLogs、Pyroscope。 - コレクター：OTeL Collector、otel-ebpf-profiler - ダッシュボード：Grafana - ダッシュボードでは、クラスタレベルの概観を見るためにHPE Clusterviewプラグインを採用している。Clusterviewは、様々なコンポーネントのメトリクスを高密度に閲覧できるため、システム管理者からの評価が高い。 - またサーバかネットワークかの問題分離が困難であるため、NIC単位のフルメッシュ状にPingを打ち合うネットワーク監視システム（SIGCOMM'24で発表されたR-pingmesh）の再現実装を開始している。 4. 最先端の研究動向（5分） まだ「見る」ことができていない振る舞いとして、GPU内部の処理、GPUメモリ間の論理通信トポロジーなどがある。さくらONEでは、アプリケーションのログなどにはサービス事業者からは自由にアクセスできないため、ブラックボックスのまま扱うアプローチが必要とされる。GPU内部の処理詳細については、eBPFをGPUに拡張するHCDS'25のeGPUを導入したい。論理通信については、スイッチ側のフローデータを基に空間的・時間的通信パターンを認識するDSN'25のLLMPrismに着目している。 --- 1. はじめに（5分） - さくらONEは、GPU専用サーバのサービスに加え、GPU・集合通信ランタイム、ジョブスケジューラ、分散ストレージ、クラスタレベルでの運用支援等を提供するAIスパコンである。 - 本講演の目的：ウェブアプリケーションと対比したLLM学習のワークロード特性、実環境でのオブザーバビリティ事例、今後の研究動向を紹介。 2. AIスパコンの前提知識（8分） - ワークロード：勾配計算、同期のための集合通信、データ並列とモデル並列 - ジョブスケジューラ：Slurm、Kubernetes - ソフトウェアスタック：CUDA、集合通信ライブラリ（NCCL）、学習フレームワーク（PyTorch）、分散学習フレームワーク（Megatron/DeepSpeed/NeMo） - テレメトリー：メトリクス・ログ・プロファイルが主体。分散トレーシングは一般的でない。 - 性能指標：学習時間、FLOP/s、Tokens/s、実効/理論演算スループット比など - AIスパコンの他社事例 3. さくらONEの事例（12分） - さくらONEはNVIDIA H100 GPU 800基（1計算ノードあたり8基）、SONiC搭載800GbEインターコネクトスイッチ24基、DDN Lusterストレージ、Slurmで構成 - 収集データ - メトリクス：Node、Process、DCGM、SONiC、LusterFS、IPMI、Slurm等の各種Exporter、最小5秒解像度 - ログ：OSカーネル、Slurm管理デーモン、スイッチsyslog - プロファイル：Python関数レベルCPUプロファイル - H100/H200/B200の各GPUクラスタにおけるベンチマーク性能差とテレメトリーデータの代表的な振る舞いを紹介。 - システム構成： - コレクター：OTeL Collector、otel-ebpf-profiler - バックエンド：VictoriaMetrics(252K ingestions/sec)、VictoriaLogs、Pyroscope - ダッシュボード：Grafana（HPE Clusterviewプラグイン） - サーバ/ネットワーク問題切り分けのため、NIC単位フルメッシュPing監視システム（SIGCOMM'24）の再現実装中。 4. 研究動向（5分） - 今後の課題：GPU内部処理と集合通信に関わる細粒度のトレースデータの収集。 - GPU内部詳細にはeBPFをGPU拡張したHCDS'25のeGPU、集合通信にはスイッチのフローデータから通信パターン認識するDSN'25のLLMPrismに着目。 ## 参考文献 - [[さくらONEのMLPerf Trainingベンチマーク2025年春]] - [[2025__arXiv__SAKURAONE - Empowering Transparent and Open AI Platforms through Private-Sector HPC Investment in Japan]] - [[2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]] - [[Transformers in SRE Land - Evolving to Manage AI Infrastructure at SREcon25 Americas]] - [[Unlocking LLM Performance with EBPF - Optimizing Training and Inference Pipelines - KubeCon24 Chaina]] - [[2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]