> [!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 networking([[SONiC]] + RoCEv2)を中核に据えた 800 GPU 規模の AI–HPC クラスタ SAKURAONE を提示する経験報告(experience report)。アーキテクチャと標準 HPC ベンチマーク結果に加え、June 2024–March 2025 に実施した日本語 medical-LLM プロジェクト(continued pretraining + fine-tuning)を単一テナントで排他運用した際の、ジョブ・資源・障害のワークロード動態を Slurm/telemetry ログから定量的に観測する。 ## 問題設定 - **対象規模**: hyperscale(数万 GPU)ではなく、日本を含む多くの事業者が主力とする mid-scale(数百 GPU オーダー)の production クラスタ。この規模の LLM 向け運用データは公開例が乏しく、本論文は 800 GPU クラスタの telemetry でその空白を埋めることを狙う(§1)。 - **単一テナント設定**: cross-tenant contention や heterogeneous scheduling といった交絡要因を排し、開発フェーズ横断でのワークロード特性・資源需要の変化を明瞭に観測できる。ただし multi-tenant 環境への直接的な一般化は限定される(§1)。 - **目的**: (i) 信頼できる大規模計算アクセスによる国の AI R&D・産業競争力の強化、(ii) government cloud 統合を含む次世代 HPC クラウド基盤の補強。要件は予測可能な capacity・lossless interconnect 上の multi-GPU/multi-node 訓練・all-flash Lustre による持続 I/O・secure remote access(§3)。 ## 提案手法 - **アーキテクチャ**: 計算・interconnect・storage・secure access・observability の 5 subsystem で構成。management/telemetry は out-of-band で read-only 動作。訓練網と storage 網を論理的・物理的に分離し、collective traffic と I/O burst の干渉を最小化(§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(Table 1)。 - **interconnect**: 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、Table 3)。NIC–GPU affinity は `nvidia-smi topo -mp` でプロファイルし、NIC0–7/9 を inter-node collective(NCCL/MPI over RoCEv2)、NIC8/10 を storage 専用に分離(Table 2)。 - **storage**: 共有 all-flash Lustre 2 PB(1 PB 想定出力 + 2× safety margin)。DDN ES400NVX2-NDR200 × 4、TLC SSD 30.72 TB、各ノードは 2× 400 GbE で storage plane に接続。end-to-end 約 100 GB/s を目標とし checkpoint と data generation を同時に支える(§4.3、§5.3、Table 4)。 - **system software**: Rocky Linux 9.4、module 環境、CUDA 12.x / cuDNN / NCCL、Singularity/Apptainer + Pyxis、Slurm Workload Manager 22.05.9 による priority/policy ベース scheduling(§5.4)。 - **設計の核となる工夫**: lossless RDMA を実現する RoCEv2 の congestion control。ECN/PFC を vendor-validated に調整(ECN min/max = 2 MB/10 MB、ECN max marking probability = 1%、PFC priority queue 3、shared-buffer dynamic alpha=1)。PFC buffer は vendor default を維持し、ECN 閾値のみ DCQCN の早期飽和を避けるよう調整(§8.2、Table 15)。 ## 新規性 - **トップ 100 で唯一のフルオープン networking stack**: 既存研究の多くが simulation か proprietary(InfiniBand)システムを対象とするのに対し、本論文は SONiC/SAI ベースのフル open Ethernet fabric を production で運用し、InfiniBand class の効率を達成したことの実証的証拠を、継続的 LLM 訓練の telemetry とともに提示する(§9 Related Work、Difference)。 - **mid-scale・単一テナント LLM 開発のワークロード動態の公開**: hyperscale(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**(非公式・unverified): 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、per-GPU 効率 約 78.3%、実行 389.23 s(Table 5)。 - **HPCG**: validated 396,295 GFLOP/s、観測 peak メモリ帯域 3.316 TB/s、総メモリ 39.96 TB(Table 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(Table 7)。 - **IO500**: 96-node は metadata 重視ワークロード(mdtest stat/find)で 10-node を上回り総合スコアも高い(181.91 → 214.09)が、IOR 帯域では 10-node が優る場面があり back-end の帯域飽和を示唆(§6.5、Table 8)。 - **MLPerf GPT-3 175B**(unverified): 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×(Table 9, 12)。PyTorch Profiler では 32N で GPU compute 81.7% / communication 16.4%、NCCL kernel は SendRecv(PP)が 91.2% を占める(Table 10)。 - **MLPerf Llama 2 70B LoRA**(unverified): 96N で 1.26 分(Table 11)。 ## 観測(単一テナント運用、Dec 2024–Mar 2025) - **Obs.1 cancellation 支配**: CANCELLED ジョブが GPU 時間の 73.5% を占め、FAILED は 16.9%(件数)ながら GPU 時間の 0.3% に留まる。早期終了は loss curve を実時間監視して非生産的訓練を止める適応的制御であり、不安定さではなく resource-efficiency practice(§7.2)。 - **Obs.2 long-tail 分布**: 全ジョブの 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)は median GPU 利用率 98.4%・低利用時間 1.1%。1–2 ノードの小規模ジョブは median 23.4%/17.7%・低利用時間 69.2%/75.9%(dataset 準備・評価など CPU/I/O 律速)(§7.2、Figure 5)。 - **Obs.4 runtime の long tail**: 大半は数十分で完了するが、17–32 ノードの 13.6% は連続 1 週間超(CPT phase に起因)。 - **Obs.5 フェーズ遷移**: mid-Jan–early-Mar 2025 は 17–32 ノードの大規模ジョブ(CPT)が継続投入され、mid-Feb 以降 3–16 ノードの中規模ジョブ(fine-tuning)が漸増。大規模 pretraining → 中規模 fine-tuning という LLM 開発ライフサイクルを捉える(§7.2、Figure 7)。 - **Obs.6 障害**: 3 ヶ月で 21 件の fault。GPU 関連(ECC/HW error/unresponsive)が 9 件(42.9%)で最多、interconnect switch 5 件(23.8%)、NVLink/NVSwitch/PCIe 4 件(19.0%)。10/21 が node-level restart で復旧、3 件が vendor 交換。1 月に集中(13 件)し burn-in 期を示唆。MTTF/MTTR は Slack 由来の不正確な timestamp のため非報告(§7.2、Table 13)。 - **Obs.7 per-port 帯域**: 代表 2 ジョブで inter-node 単一 port peak は 19–23 GB/s。Job A は 8 port 均一(約 22.6 GB/s)、Job B は per-rail 非対称(6 port 約 18.9 GB/s、2 port 約 8.0 GB/s)で NVLink/PCIe 側にも同じ非一様性が現れた(§7.2、Table 14)。 ## 考察 - **オープン disaggregated 設計の含意**: フル open Ethernet が HPC・AI 双方で competitive な性能を出せることを実証。ただし安定動作には firmware/kernel/RDMA stack の版整合と、ECN 閾値・PFC・NCCL channel striping の精緻な調整が不可欠で、InfiniBand 比でより深い cross-layer の専門知を要する(§8.1)。 - **scheduling への示唆**: 多数の短ジョブと長時間の大ジョブの共存は scheduling 課題を生む。長大ジョブの checkpoint 完了を安全な中断点とする checkpoint-based preemption が、単一テナントでも短ジョブ待ち時間を削減しうる(§8.5)。フェーズ遷移は静的資源割当の最適性を否定し、elastic な再配分を要求する(§8.4)。 - **一般化可能性の切り分け**: setting-specific(cross-tenant contention の不在・単純な queue policy・最小 queueing 遅延)と tenancy-independent(歪んだ資源消費分布・フェーズ駆動の規模シフト)を区別。後者は multi-tenant 研究(Jeon 2019, Kokolis 2025)と整合し、mid-scale 領域の参照点となる(§8.6)。 ## 強み / 弱点・課題 - **強み**: production の一次運用データ(著者所属クラスタの排他運用)に基づく定量観測。標準 HPC ベンチマークと MLPerf 比較で性能を多面的に裏付け。open networking の congestion-control 実値(Table 15)を開示し再現性に資する。 - **弱点・課題(論文が明示)**: 単一テナント・単一プロジェクトのため scheduling/queueing 観測の multi-tenant 一般化は限定。MLPerf 結果は unverified(非公式提出)。ECN/PFC 計測の 60 秒解像度は sub-second collective burst を平滑化し peak を過小評価しうる。ECN marking rate / PFC pause counter は観測期間中未収集で帯域の congestion 帰属が不能。MTTF/MTTR は記録精度不足で非報告。multimodal/RAG タスクや energy metric は future work(§8.8)。