# Frontier: Exploring Exascale — The System Architecture of the First Exascale Supercomputer > [!abstract] 概要 > 米国エネルギー省(DOE)の計算施設が 2008 年にペタスケールのシステムを配備し始めたとき、DOE はすでにエクサスケールを視野に入れていた。その年に DARPA は、エクサスケールに到達できるかを検討した報告書を公表した。報告書の著者らは、電力、メモリ、並行性、レジリエンスを含む、エクサスケールを追求するうえでの主要な課題をいくつか特定した。この報告書は、エクサスケールへ到達するための DOE の計算戦略に影響を与えた。Oak Ridge National Laboratory の Frontier スーパーコンピュータの配備により、我々は公式にエクサスケール時代に入った。本論文では、Frontier のアーキテクチャと、それがこれらの課題にどう対処するかを論じ、Oak Ridge Leadership Computing Facility の Center of Excellence と Exascale Computing Project による初期のアプリケーション結果のいくつかを述べる。 ## 論文情報 - 著者: Scott Atchley、Chris Zimmer、John R. Lange ほか。ORNL を中心に HPE、Argonne、LBNL、Sandia、LANL、複数の大学が共著する - 掲載: SC '23(Denver、2023 年 11 月 12〜17 日)、ACM。DOI は 10.1145/3581784.3607089。本文 15 ページ - 対象: [[Frontier]]。運用は [[Oak Ridge National Laboratory]] の OLCF、製造は [[Hewlett Packard Enterprise]]、プロセッサは [[AMD]] ## 概要 Frontier のノード、Slingshot ネットワーク、ストレージ、ソフトウェア環境を通覧し、マイクロベンチマークと実アプリケーションの初期結果を示すシステム論文である。全体は、2008 年の DARPA 報告(ExaScale Computing Study)が挙げた 4 課題(エネルギー・電力、メモリ・ストレージ、並行性・局所性、レジリエンス)に照らして Frontier を評価する構成をとる。結論は、コストを無視した報告書の 1,000 倍目標そのものではなく、実アプリケーションの高速化を成功基準にすれば、Frontier は報告書の趣旨を満たすというものである。 ## 問題設定 - 2007 年に DARPA が召集した作業部会が、2015 年頃のエクサスケール配備の実現性を検討した。報告書は 230 ページ超で、難易度の高い順に 4 課題を挙げた - 報告書はエクサスケールを 1 EF の FP64 性能以上と定義し、最初のペタスケール機の最大 2 倍の面積と電力(20 MW/EF まで)を許容した。メモリ容量・帯域、ストレージ容量・帯域などは 2008 年のペタスケール 2 機の 1,000 倍を求めたが、コストは考慮していない - 20 MW は、運用期間中に払う電気代が機械の購入額を超えないための閾値である(1 MW を年 100 万米ドルとする経験則) - 検討した試作設計は最良でも 68〜155 MW/EF と見積もられ、目標に届く道筋は示されなかった ## 提案手法 ここでの「手法」は Frontier の設計そのものである。 ### ノード設計(Bard Peak、Cray EX 235a) - 9,472 ノード。Titan(CPU 対 GPU が 1 対 1)、Summit(1 対 3)に続くヘテロジニアスな太いノードで、比は 1 対 4 である。ただし MI250X は 2 つの GCD(Graphics Compute Die)からなり、OS からは 8 基の GPU に見える - CPU は EPYC 7A53(Trento)。Zen3 の 64 コアを 8 つの CCD に載せ、I/O ダイの PCIe を InfinityFabric に置き換えた特注品である。DDR4-3200 の 64 GiB DIMM を 8 枚持ち、ピーク 205 GiB/s。NUMA は NPS-4 で運用する - GPU は MI250X。GCD ごとに HBM 4 スタックで、ピーク 1.635 TB/s。ノードの HBM 総帯域 13.08 TB/s は CPU メモリ帯域の 64 倍で、Titan の 40 倍・Summit の 16 倍より比が大きい。このため利用者はデータを HBM に置き続けると想定している - CPU 対 GCD は xGMI 2.0(片方向 36 GB/s)、GCD 間は 1・2・4 本の xGMI 3.0(1 本 50+50 GB/s)で twisted ladder 状に結ぶ - NIC は Cassini(200 Gb/s の Ethernet 系、HPE 独自の HPC Ethernet モードで OS バイパス)。4 枚をそれぞれ MI250X の OAM パッケージへ直結する点が設計上の革新である ![[_attachments/Frontier--Exploring-Exascale/fig01-frontier-hall.png]] *図1(Figure 1): Frontier スーパーコンピュータ* ![[_attachments/Frontier--Exploring-Exascale/fig02-node-connectivity.png]] *図2(Figure 2): Bard Peak ノード内の接続。各 CCD は 1 つの GCD と対になる* ![[_attachments/Frontier--Exploring-Exascale/table1-compute-specs.png]] *表1(Table 1): Frontier の計算仕様* ### Slingshot インターコネクト - Ethernet の上位互換で、平均・テール遅延の削減、帯域とメッセージレートの向上のための HPE 独自拡張を持つ([[HPE Slingshot]]) - 3 ホップの[[ドラゴンフライトポロジ]]で 80 グループ(管理 1、I/O 5、計算 74)。計算グループは水冷ブレードスイッチ 32 台が全結合し、各スイッチの 64 ポートは端点 16(L0)、グループ内 32(L1)、グループ間 16(L2)に割り当てる - 計算グループ間は 2 本組のバンドルで、1 グループあたりグローバル 7.3 TB/s 対注入 12.8 TB/s、比は 57%(ネットワークテーパ)。全体のグローバル帯域は 270+270 TB/s である - 直接網なので非最小経路制御を使い、これがさらに実効グローバル帯域を減らす ### ストレージ - ノードローカル: NVMe M.2 を 2 枚 RAID-0 で、約 3.5 TB、読み 8 GB/s、書き 4 GB/s、最大 220 万 IOPS。利用者管理である - センター全体は Summit の GPFS と異なり Lustre で、名を [[Orion]] という。225 の SSU(各 NVMe 24 本と 18 TB HDD 212 本)を、フラッシュの性能層と HDD の容量層に集約し、単一の POSIX 名前空間にする。メタデータサーバにも NVMe を置く - 性能層から容量層への自動移行は本番水準に達しなかったため、Progressive File Layout を使い、各ファイルの先頭 256 KB をメタデータサーバ(Data-on-Metadata)、256 KB〜8 MB を性能層、残りを容量層に置く ![[_attachments/Frontier--Exploring-Exascale/table2-io-specs.png]] *表2(Table 2): I/O サブシステムの容量と理論読み書き帯域* ### ソフトウェア環境 - OS は SUSE Enterprise Linux の派生である HPE Cray OS。演算の大部分を GPU のファームウェア上の軽量な OS が管理するため、システム全体は当初のエクサスケール予測が想定したマルチカーネル構成に近い - 管理は HPCM、スケジューラは Slurm(ノード専有、ジョブ間で checknode、ジョブステップごとの VNI で隔離、トポロジ考慮の配置)。Slingshot の Fabric Manager が経路表を配る - プログラミング環境は HPE の CPE と AMD の ROCm に OLCF 追加分を足す。低水準は HIP(CUDA に近い)で、OpenMP が OpenACC を上回る主流のオフロード手段になった。ベンダーが OpenACC の対応を約束していないことも背景にある ## 新規性 - 個別の新技術ではなく、実機のシステム全体の設計判断と実測を、15 年前の予測文書に照らして総括する点にある - 成功基準を「1,000 倍の資源」から「実アプリの高速化」へ置き直す論証を示す(第 5 節) ## 実験設定 - ノード内: STREAM(CPU・GPU)、CoralGemm(hipBLAS)、CPU から GCD への転送、GCD 間の転送(CU カーネルと SDMA) - ノード間: mpiGraph で Summit の EDR InfiniBand と NIC ごとの帯域を比較、GPCNeT で 9,400 ノード(輻輳源 7,520、被害側 1,880)を使い輻輳制御を測る - ストレージ: fio でノードローカルを、Orion をフルスケールで測る - アプリ: CAAR・INCITE の 6 本(Summit 比 4 倍が目標)と ECP の 5 本(約 20 PF 機比 50 倍が目標) ## 実験結果 - CPU: Trento は NPS-4 で非一時ストアなら最大約 180 GB/s、NPS-1 では約 125 GB/s。GPU の STREAM はピークの 79〜84%。GCD 1 基の FP64 ピークは 23.95 TFLOP/s で、行列コア命令のため FP32 が 24.1、FP64 が 33.8、FP16 が 111.2 TFLOP/s に達した - ノード内: 8 MPI プロセスの CPU から GPU の合計は約 180 GB/s で、Trento の STREAM と一致する。GCD 間は SDMA が転送先のリンク数によらず約 50 GB/s で頭打ち、CU カーネルは 1・2・4 リンクで 37.5・74.9・145.5 GB/s に達する - mpiGraph: Summit の非ブロッキング fat-tree は NIC あたり約 8.5 GB/s に集中するが、Frontier は 3〜17.5 GB/s に広く分布する。最悪の約 3 GB/s は全トラフィックがグローバルリンクを使い、かつ非最小経路で帯域が半分になる場合である。全対全では 8 PPN・128 KiB で 1 ノードあたり約 30〜32 GB/s である - GPCNeT(8 PPN): 孤立時と輻輳時が同等(影響係数 1.0 倍)。32 PPN では平均 1.2〜1.6 倍、99 パーセンタイル 1.8〜7.6 倍の劣化が出るが、Summit の EDR より良い - ストレージ: ノードローカルは逐次読み 7.1 GB/s、書き 4.2 GB/s、ランダム読み 158 万 IOPS。全ノードで読み 67.3 TB/s、書き 39.8 TB/s。Orion はフラッシュ層に収まる小ファイルで読み 11.7 TB/s・書き 9.4 TB/s、大ファイルで 4.9 と 4.3 TB/s。HBM 4.6 PiB を約 180 秒で書き出せ、多くのアプリの I/O は 1 時間あたり 5% 未満になる - アプリ(表6・7): CAAR は CoMet 5.2 倍、LSMS 7.5 倍、PIConGPU 4.7 倍、Cholla 20.0 倍、GESTS 5.9 倍、AthenaPK 4.6 倍。ECP は WarpX 500 倍、ExaSky 234 倍、EXAALT 398.5 倍、ExaSMR 70 倍、WDMApp 150 倍。CoMet は 9,074 ノードで混合精度 6.71 EF を出した ![[_attachments/Frontier--Exploring-Exascale/fig03-fp-performance.png]] *図3(Figure 3): MI250X の 1 GCD で達成した FP64・FP32・FP16 性能とピークの比較* ![[_attachments/Frontier--Exploring-Exascale/table3-cpu-stream.png]] *表3(Table 3): 一時ストアと非一時ストアを使った CPU の STREAM 帯域* ![[_attachments/Frontier--Exploring-Exascale/table4-gpu-stream.png]] *表4(Table 4): GPU の STREAM 帯域* ![[_attachments/Frontier--Exploring-Exascale/fig04-cpu-gpu-bandwidth.png]] *図4(Figure 4): 8 MPI ランクが各自の GCD を同時に対象にしたときの CPU から GPU への合計帯域* ![[_attachments/Frontier--Exploring-Exascale/fig05-gcd-bandwidth.png]] *図5(Figure 5): GCD ペア間の達成帯域。上は CU カーネル転送、下は SDMA 転送* ![[_attachments/Frontier--Exploring-Exascale/fig06-mpigraph.png]] *図6(Figure 6): mpiGraph による NIC ごとの帯域測定(Frontier 対 Summit)* ![[_attachments/Frontier--Exploring-Exascale/table5-gpcnet.png]] *表5(Table 5): 9,400 ノード・8 PPN の GPCNeT* ![[_attachments/Frontier--Exploring-Exascale/table6-caar.png]] *表6(Table 6): Summit 比の KPP 4.0 倍を超えた CAAR・INCITE のアプリ* ![[_attachments/Frontier--Exploring-Exascale/table7-ecp.png]] *表7(Table 7): KPP の 50 倍を超えた ECP のアプリ* ## 考察 - コストを無視した報告書の目標は、資源が 1,000 倍に安くならなかった現実と合わない。CORAL-2 の予算上限は 4〜6 億米ドルで、2008 年の「スパコンは 1 億ドル」の 4〜6 倍だった。DOE は実アプリの高速化に目標を切り替えた - 4 課題の評価: エネルギーは 52 GF/W で目標 50 GF/W 超え(TOP500 と Green500 の同時 1 位)。メモリ・ストレージは HBM 化で解けたがコストの 45% 以上を占め、容量の上限を決める。フラッシュを性能、HDD を容量とする混成が予算内で需要を満たす。並行性は 37,888 基の MI250X 系で 5 億超のスレッドを約 1 GHz で回して満たし、2.5D パッケージが局所性を補う - レジリエンスは苦戦する。報告書は MTTI 24 分、FIT を 10 倍改善しても 4 時間ごとの障害と投影したが、Frontier の実績はこれをあまり上回らない。原因はメモリと電源で、HBM の訂正不能エラー率は Summit の HBM2 を容量比で換算した値と同程度である。長期には 8〜12 時間へ改善する見込みとする ## 強み / 弱点・課題 - 強み: 設計判断、微視的な実測、複数分野の実アプリを 1 本で通覧し、15 年前の予測との突き合わせで論点が整理される - 弱み: HBM の価格は推測(DDR の 3〜5 倍)で、コスト比率も推定である。レジリエンスは定量データがなく、電源対策は「計画がある」に留まる。結果の多くは初期の数値で、ベースラインの機械がアプリごとに異なり(Summit、Titan、Cori、Mira、Theta)、比較の厳密さは限られる