> [!abstract] 概要(arXiv abstract の日本語訳) > SAKURAONE は SAKURA Internet Research Center が開発・運用する managed な high performance computing(HPC)クラスタである。KOKARYOKU PHY bare metal GPU platform 上に構築され、大規模言語モデル(LLM)訓練を含む先進的ワークロードに最適化されている。ISC 2025 TOP500 において SAKURAONE は HPL で 49 位にランクされ、フルオープンな networking stack——SONiC を用いた 800 GbE——を採用するトップ 100 唯一のシステムであり、vendor-neutral 技術のスケーラビリティを実証している。実測性能は 33.95 PFLOP/s(HPL Rmax)、396.295 TFLOP/s(HPCG)、FP8 を用いた HPL-MxP で 339.86 PFLOP/s である。システムは 100 ノードからなり、各ノードは 8 基の NVIDIA H100 GPU と 2 PB の all-flash Lustre ファイルシステムを備え、RoCEv2 上の rail-optimized な 800 GbE leaf–spine fabric で相互接続される。単一の研究プロジェクトによる排他利用を通じて、開発関連ジョブの特性を観測した。先行する HPC 研究と整合して、小規模ジョブが件数で支配的だった一方、少数の大規模ジョブが GPU 資源時間の大半を占めた。プロジェクトの進行に伴い、資源利用は大規模ジョブから中規模ジョブへとシフトし、初期の大規模訓練から反復的な改良への移行を反映した。これらの観測は、統一されたプロジェクトワークロード下での GPU クラスタの実世界における利用動態を例示する。 ## 論文情報 - タイトル: SAKURAONE: An Open Ethernet-Based AI HPC System and Its Observed Workload Dynamics in a Single-Tenant LLM Development Environment - 著者: [[Fumikazu Konishi]]・[[Yuuki Tsubouchi]]・[[Hirofumi Tsuruta]](全員 equal contribution、[[SAKURA Internet]] Research Center) - 媒体: MLSys 2026 採録(arXiv プレプリント、cs.DC / cs.NI) - arXiv ID: 2604.13600(v1 2026-04-15 / v2 2026-04-16)、DOI: 10.48550/arXiv.2604.13600 - 謝辞に SIP「Integrated Health Care System」(JPJ012425)の支援、ELYZA の LLM 研究者の協力を記載 ## 概要 日本の商用セクター向けに、オープンで分離された(disaggregated)Ethernet ネットワーキング([[SONiC]] + RoCEv2)を中核に据えた 800 GPU 規模の AI–HPC クラスタ SAKURAONE を提示する経験報告(experience report)。アーキテクチャと標準 HPC ベンチマーク結果に加え、June 2024–March 2025 に実施した日本語 medical-LLM プロジェクト(continued pretraining + fine-tuning)を単一テナントで排他運用した際の、ジョブ・資源・障害のワークロード動態を Slurm/テレメトリのログから定量的に観測する。 ## 問題設定 - **対象規模**: ハイパースケール(数万 GPU)ではなく、日本を含む多くの事業者が主力とする中規模(数百 GPU オーダー)の本番クラスタ。この規模の LLM 向け運用データは公開例が乏しく、本論文は 800 GPU クラスタのテレメトリでその空白を埋めることを狙う(§1)。 - **単一テナント設定**: テナント間の競合や heterogeneous scheduling といった交絡要因を排し、開発フェーズ横断でのワークロード特性・資源需要の変化を明瞭に観測できる。ただしマルチテナント環境への直接的な一般化は限定される(§1)。 - **目的**: (i) 信頼できる大規模な計算アクセスによる国の AI R&D・産業競争力の強化、(ii) government cloud 統合を含む次世代 HPC クラウド基盤の補強。要件は予測可能な容量・ロスレスなインターコネクト上の multi-GPU/multi-node 訓練・all-flash Lustre による持続的な I/O・セキュアなリモートアクセス(§3)。 ## 提案手法 - **アーキテクチャ**: 計算・インターコネクト・ストレージ・セキュアアクセス・オブザーバビリティの 5 サブシステムで構成。管理・テレメトリはアウトオブバンドで read-only 動作する。訓練網とストレージ網を論理的・物理的に分離し、集団通信のトラフィックと I/O バーストの干渉を最小化する(§4)。 - **計算ノード**: Supermicro SYS-821GE-TNHR(8U 空冷)× 100。各ノードは Intel Xeon Platinum 8580+ × 2(計 12,000 cores)、DDR5 1.5 TB、NVIDIA H100 SXM 80GB × 8(計 800 GPU)、NVLink/NVSwitch、ローカル NVMe 7.68 TB × 4(表1)。 - **インターコネクト**: rail-optimized leaf–spine、800 GbE(2× 400 GbE)、RoCEv2。スイッチは Edgecore AIS800-64O(Broadcom Tomahawk 5、51.2 Tb/s、[[SONiC]])。2 pod 構成で各 pod に leaf 8 台(計 16)+ spine 8 台。各計算ノードは 8× 400 GbE の GPU-fabric リンクを提示する(§5.2、表3)。NIC–GPU の affinity は `nvidia-smi topo -mp` でプロファイルし、NIC0–7/9 を inter-node の集団通信(NCCL/MPI over RoCEv2)、NIC8/10 をストレージ専用に分離する(表2)。 - **ストレージ**: 共有の all-flash Lustre 2 PB(1 PB の想定出力 + 2 倍の安全マージン)。DDN ES400NVX2-NDR200 × 4、TLC SSD 30.72 TB、各ノードは 2× 400 GbE で storage plane に接続。エンドツーエンドで約 100 GB/s を目標とし、checkpoint と data generation を同時に支える(§4.3、§5.3、表4)。 - **システムソフトウェア**: Rocky Linux 9.4、module 環境、CUDA 12.x / cuDNN / NCCL、Singularity/Apptainer + Pyxis、Slurm Workload Manager 22.05.9 による優先度・ポリシーベースのスケジューリング(§5.4)。 - **設計の核となる工夫**: ロスレスな RDMA を実現する RoCEv2 の輻輳制御。ECN/PFC をベンダ検証済みの値に調整(ECN min/max = 2 MB/10 MB、ECN max marking probability = 1%、PFC priority queue 3、shared-buffer dynamic alpha=1)。PFC バッファはベンダのデフォルトを維持し、ECN 閾値のみ DCQCN の早期飽和を避けるよう調整する(§8.2、表15)。 ## 新規性 - **トップ 100 で唯一のフルオープンなネットワーキングスタック**: 既存研究の多くがシミュレーションかプロプライエタリ(InfiniBand)なシステムを対象とするのに対し、本論文は SONiC/SAI ベースの完全にオープンな Ethernet ファブリックを本番で運用し、InfiniBand 級の効率を達成したことの実証的な証拠を、継続的な LLM 訓練のテレメトリとともに提示する(§9 Related Work、Difference)。 - **中規模・単一テナントの LLM 開発のワークロード動態の公開**: ハイパースケール(Jeon 2019, [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], Kokolis 2025)に偏る公開運用データに対し、100–1,000 GPU 規模・単一プロジェクトの LLM 開発という未踏領域の参照点を与える(§8.6)。 ## 実験設定 標準 HPC ベンチマークで汎用クラスタと比較可能にする(§6)。 - **HPL**: HPL-NVIDIA 25.4.0、N=2,706,432、NB=1024、16×49 grid(784 GPU)。 - **HPCG**: 3.1、784 process(16 threads/process)、global grid 4096×3584×3808(約 55.9B unknowns)。 - **HPL-MxP**: HPL-MxP-NVIDIA 25.4.0、N=2,989,056、NB=4096、24×32 grid(768 GPU)、Sloppy FP8(type=1)。 - **IO500**: 10-node と 96-node を比較。 - **MLPerf Training v4.1**(非公式・未検証): GPT-3 175B pretraining と Llama 2 70B LoRA fine-tuning。比較対象は NVIDIA Eos(DGX H100 SuperPOD, InfiniBand)の公式 v4.1 結果(§6.6)。MFU は H100 SXM dense Tensor Core peak 1,979 TFLOPS/GPU 基準。 ## 実験結果 - **HPL**: 33.95 PFLOP/s sustained(43.31 TFLOP/s/GPU)、単一 GPU の peak GEMM 55.34 TFLOP/s、GPU あたり効率 約 78.3%、実行 389.23 s(表5)。 - **HPCG**: validated 396,295 GFLOP/s、観測された peak メモリ帯域 3.316 TB/s、総メモリ 39.96 TB(表6)。 - **HPL-MxP**: 観測された Rmax 339.86 PFLOP/s(442.52 TFLOP/s/GPU)、LU-only 539.19 PFLOP/s、residual 5.01×10⁻⁵ で validation PASSED(表7)。 - **IO500**: 96-node はメタデータ重視のワークロード(mdtest stat/find)で 10-node を上回り総合スコアも高い(181.91 → 214.09)が、IOR 帯域では 10-node が優る場面がありバックエンドの帯域飽和を示唆する(§6.5、表8)。 - **MLPerf GPT-3 175B**(未検証): time-to-train は 32N 105.31 / 64N 58.30 / 96N 41.86 分。MFU は 38.3% / 41.2% / 35.9%。NVIDIA Eos との比は同一ノード数で 1.02–1.26 倍(表9, 12)。PyTorch Profiler では 32N で GPU の計算 81.7% / 通信 16.4%、NCCL カーネルは SendRecv(PP)が 91.2% を占める(表10)。 - **MLPerf Llama 2 70B LoRA**(未検証): 96N で 1.26 分(表11)。 ## 観測(単一テナント運用、Dec 2024–Mar 2025) - **Obs.1 キャンセルが支配的**: CANCELLED ジョブが GPU 時間の 73.5% を占め、FAILED は 16.9%(件数)ながら GPU 時間の 0.3% に留まる。早期終了は loss curve を実時間で監視して非生産的な訓練を止める適応的な制御であり、不安定さではなく資源効率上の実践である(§7.2)。 - **Obs.2 ロングテール分布**: 全ジョブの 76.9% が単一ノード、86.4% が 4 ノード以下だが、これら小規模ジョブは GPU 時間の 1.8%・4.6% のみ。17 ノード以上は件数 3.3% で GPU 時間の 73.3% を消費する(Jeon 2019, Kokolis 2025 と整合)。 - **Obs.3 利用率の規模依存**: 17–32 ノードの大規模ジョブ(主に CPT)は GPU 利用率の中央値 98.4%・低利用時間 1.1%。1–2 ノードの小規模ジョブは中央値 23.4%/17.7%・低利用時間 69.2%/75.9%(dataset 準備・評価など CPU/I/O 律速)(§7.2、図5)。 - **Obs.4 実行時間のロングテール**: 大半は数十分で完了するが、17–32 ノードの 13.6% は連続 1 週間超(CPT のフェーズに起因)。 - **Obs.5 フェーズ遷移**: mid-Jan–early-Mar 2025 は 17–32 ノードの大規模ジョブ(CPT)が継続的に投入され、mid-Feb 以降は 3–16 ノードの中規模ジョブ(fine-tuning)が漸増する。大規模な pretraining → 中規模な fine-tuning という LLM 開発のライフサイクルを捉える(§7.2、図7)。 - **Obs.6 障害**: 3 ヶ月で 21 件の障害。GPU 関連(ECC/HW error/unresponsive)が 9 件(42.9%)で最多、インターコネクトのスイッチ 5 件(23.8%)、NVLink/NVSwitch/PCIe 4 件(19.0%)。21 件中 10 件がノード単位の再起動で復旧、3 件がベンダ交換。1 月に集中(13 件)し burn-in 期を示唆する。MTTF/MTTR は Slack 由来の不正確なタイムスタンプのため非報告(§7.2、表13)。 - **Obs.7 ポートあたりの帯域**: 代表的な 2 ジョブで inter-node の単一ポートの peak は 19–23 GB/s。Job A は 8 ポート均一(約 22.6 GB/s)、Job B は rail ごとに非対称(6 ポート約 18.9 GB/s、2 ポート約 8.0 GB/s)で、NVLink/PCIe 側にも同じ非一様性が現れた(§7.2、表14)。 ## 考察 - **オープンで分離された設計の含意**: 完全にオープンな Ethernet が HPC・AI 双方で競争力のある性能を出せることを実証する。ただし安定動作には firmware/kernel/RDMA スタックの版の整合と、ECN 閾値・PFC・NCCL の channel striping の精緻な調整が不可欠で、InfiniBand に比べてより深い層をまたいだ専門知識を要する(§8.1)。 - **スケジューリングへの示唆**: 多数の短いジョブと長時間の大きいジョブの共存はスケジューリングの課題を生む。長大なジョブの checkpoint 完了を安全な中断点とする checkpoint ベースのプリエンプションが、単一テナントでも短いジョブの待ち時間を削減しうる(§8.5)。フェーズ遷移は静的な資源割当の最適性を否定し、伸縮的(elastic)な再配分を要求する(§8.4)。 - **一般化可能性の切り分け**: 環境固有のもの(テナント間の競合の不在・単純な queue ポリシー・最小限の queueing 遅延)と、テナント形態に依存しないもの(歪んだ資源消費の分布・フェーズ駆動の規模シフト)を区別する。後者はマルチテナントの研究(Jeon 2019, Kokolis 2025)と整合し、中規模領域の参照点となる(§8.6)。 ## 強み / 弱点・課題 - **強み**: 本番の一次運用データ(著者所属クラスタの排他運用)に基づく定量的な観測。標準 HPC ベンチマークと MLPerf 比較で性能を多面的に裏付ける。オープンなネットワーキングの輻輳制御の実値(表15)を開示し再現性に資する。 - **弱点・課題(論文が明示)**: 単一テナント・単一プロジェクトのため、スケジューリング・キューイングの観測のマルチテナントへの一般化は限定的。MLPerf 結果は未検証(非公式提出)。ECN/PFC 計測の 60 秒解像度は秒未満の集団通信のバーストを平滑化し peak を過小評価しうる。ECN marking rate / PFC pause counter は観測期間中に未収集で、帯域の輻輳への帰属ができない。MTTF/MTTR は記録精度の不足で非報告。マルチモーダル/RAG タスクやエネルギーのメトリクスは今後の課題(§8.8)。