# スーパーコンピュータアーキテクチャの教科書 本書は 1964 年の CDC 6600 から 2026 年のエクサスケール機までを横断する 72 本のソースを読み、スーパーコンピュータのシステムアーキテクチャが何を制約として、どの選択肢の中から現在の形を選んできたのかを整理した教科書である。 扱うのは計算機としての構造であり、設置設備の電力や冷却の工学、LLM 学習の運用手順、RDMA カウンタによる監視手法は姉妹ページへ譲る。 本文の主張はすべて wiki 内のソースへ遡れる。 数値には評価条件を併記し、条件の異なる数値を同じ表に並べない。 wiki のソースから確認できなかったことは、そのように本文へ明記し第 21 章へ送る。 **読み方の指針**: 座標系だけを先に得たいなら第 1 章。設計の選択肢を学びたいなら第 II 部。現代機 1 台ごとの構成を引きたいなら第 III 部と第 18 章の比較表。批判的な視点を得たいなら第 20 章。 **姉妹ページとの分担**。 ノード内部の PCIe、NVLink、CXL の詳細は [[ホストネットワークとインターコネクトの教科書]] が扱う。 電力と冷却の設備工学は [[AIデータセンターファシリティの教科書]] が扱う。 LLM 学習の並列化戦略、障害診断、復旧の運用は [[LLM学習インフラ実運用の教科書]] が扱う。 RDMA の計装点とカウンタによる監視は [[RDMAネットワークモニタリングの教科書]] が扱う。 本書ではこれらを繰り返さない。 --- ## 第 0 章　前史 ### 0.1 科学計算のための計算機という問題設定 スーパーコンピュータという語が指すのは、同時代の汎用計算機を大きく上回る数値計算性能を科学技術計算へ提供する最高性能級の計算機である。 何をもって最高性能級とするかは時代ごとに外から与えられてきた。 1970 年代後半には米国エネルギー研究開発局が定めた「クラス VI」の要件、すなわち毎秒 2,000 万回から 6,000 万回の浮動小数点演算が、その定義軸として機能した (Source: [[スーパーコンピュータ]])。 系譜の出発点に置くべきは 1964 年に出荷された CDC 6600 である。 Control Data Corporation の Thornton(Control Data Corporation)は、この機械の設計方針を「回路性能の向上と並列動作」の 2 つに置いた。 高速な演算を担う中央プロセッサを、入出力と制御を担う 10 台の周辺プロセッサから中央メモリだけを介して隔離し、中央プロセッサが演算以外の仕事で中断されない構造を作った。 中央プロセッサの内部では 24 個の中央レジスタが 10 個の機能ユニットを中央メモリから隠し、スコアボードが各レジスタと機能ユニットとオペランドトランクの使用状況を追跡して、発行の制約を「ユニットが空いている」と「二重の結果割り当てがない」の 2 つだけに絞った。 機能ユニットをレジスタの背後に隠したことで各ユニットを個別に単純化でき、その分だけ速度を上げられた (Source: [[@1964__AFIPS FJCC__Parallel Operation in the Control Data 6600]])。 ![[_attachments/Parallel-Operation-in-the-Control-Data-6600/fig03-block-diagram.png]] **図0-1**:CDC 6600 のブロック図。左が 12 本の入出力チャネルを持つ 10 台の周辺プロセッサ、右が 24 個の演算レジスタと 10 個の機能ユニットからなる中央プロセッサで、両者は中央メモリだけで接している。本文が述べた「演算を入出力と制御から隔離する」構造と「機能ユニットをレジスタの背後に隠す」構造が、この 1 枚に同時に現れている。 (Source: [[@1964__AFIPS FJCC__Parallel Operation in the Control Data 6600]], 図 3) この設計が後世へ残した最大の遺産は、性能の機構そのものよりも、その機構を利用者に見せないという方針である。 6600 の論文は、並行性を得るためにプログラムを特別な書き方にする必要はないと明言している (Source: [[@1964__AFIPS FJCC__Parallel Operation in the Control Data 6600]])。 同じ方針は 14 年後の CRAY-1 でも、自動ベクトル化コンパイラ CFT がソース修正も言語拡張も求めないという形で繰り返される (Source: [[@1978__CACM__The CRAY-1 Computer System]])。 さらに 14 年後の CM-5 では、擬似乱数による経路選択によって利用者が病的な通信パターンを避けるプログラミングをしなくてよいという設計目標として現れる (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 ハードウェア機構で利用者の負担を隠すという思想が、約 30 年の間に 3 度、別の層で独立に採用されている。 ### 0.2 並列化への最初の反論 並列機の系譜を語る前に、その前提を疑った議論を置いておく必要がある。 1967 年、IBM の Amdahl(International Business Machines Corporation)は、並列処理による性能向上が厳しく制限されると論じた。 根拠は 2 つある。 1 つは、本番実行命令の約 40 パーセントがデータ管理のオーバーヘッドであり、これが本質的に逐次的であるため、この部分だけでスループット向上が逐次処理性能の 5 倍から 7 倍に制限されるという観察である。 もう 1 つは、物理問題が持つ不規則性である。 N 次元の最近傍計算では境界の幾何が最近傍 3 の N 乗、次近傍 5 の N 乗という形で効き、不均質性、伝播速度の変動、空間掃引にともなう転置と入出力の負荷が加わるため、実問題の性能は理想的な抽象モデルから 0.5 桁から 1 桁劣化する (Source: [[@1967__AFIPS SJCC__Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities]])。 この議論が扱っているのは固定サイズの問題、すなわち強スケーリングである。 問題規模を拡大する弱スケーリングには言及していない (Source: [[@1967__AFIPS SJCC__Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities]])。 以後の系譜は、この反論をどう回避するかの歴史として読める。 CM-5 は 16,384 ノードの超並列機として 1 テラフロップス級を目標に据え、大域同期を専用の制御網へ逃がした (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 Beowulf は数百ノードの規模で、明示的な大域同期を要しないアプリケーションだけが伸びることを実測で示した (Source: [[@1998__IEEE Aerospace__An Assessment of Beowulf-class Computing for NASA Requirements]])。 Amdahl が名指しした大域同期とデータ管理のオーバーヘッドは、消えたのではなく、専用ハードウェアと応用の選別によって迂回されてきた。 --- ## 第 1 章　座標系 本書で扱う全ソースは、次の 5 軸のどこかに配置できる。 以降の章はこの座標の上で読んでほしい。 ### 1.1 5 つの軸 | 軸 | 値 | 何を決めるか | |---|---|---| | A 並列性の供給源 | パイプラインとベクトル / 超並列 MPP / コモディティクラスタ / アクセラレータ混在 / データフローとウェーハスケール | 演算性能をどこから調達するか | | B メモリとデータ移動 | 分散メモリと局所キャッシュ / HBM 積層 / CPU と GPU の統合メモリ / オンチップ SRAM 常駐 | 演算器を飽和させられるか | | C 結合網と通信意味論 | トーラス / ファットツリー / Dragonfly / Ethernet ベース、および MPI と RDMA と網内集約 | 規模を伸ばしたとき何が律速するか | | D 設計の目標関数 | ピーク性能 / 実効性能 / 電力あたり性能 / 調達コスト | 何を最大化するか | | E 用途 | 科学計算(倍精度、疎) / AI(低精度、密) / 混在 | どの評価が意味を持つか | 軸 A の値は歴史的な順序を持つが、置き換わったのではなく積み重なっている。 Fugaku は SVE による長ベクトルを持ちながら 158,976 ノードの超並列機であり (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])、Frontier はコモディティに近い AMD 製プロセッサをアクセラレータ混在構成で束ねている (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 軸 B は本書で最も繰り返し現れる制約である。 CRAY-1 が主記憶帯域 80 百万語毎秒という足かせを 8 本かける 64 要素のベクトルレジスタで補ったのと同じ構図が (Source: [[@1978__CACM__The CRAY-1 Computer System]])、A64FX が DDR を積まず HBM2 だけを持つ判断や (Source: [[A64FX]])、Cerebras CS-3 が外部メモリへのアクセスそのものを 44GB のオンチップ SRAM で排除する判断として現れる (Source: [[ウェーハスケールエンジン]])。 軸 C は規模の関数として効き方が変わる。 数十ノードでは結合網はほとんど効かず、数千ノードではトポロジの直径とコストが効き、数万ノードでは輻輳制御の実装品質が桁で効く。 第 9 章で示すとおり、同じ Dragonfly 系でも輻輳制御の有無で実効性能の劣化幅が 100 倍変わる (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 軸 D は何を測るかで答えが変わる。 本書では、ピーク性能と実効性能と電力あたり性能を、必ず区別して記す。 2008 年の DARPA 報告が定義したエクサスケールは HPL の演算速度だけでなくメモリ容量を含む多属性の 1,000 倍だったが (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 2 Defining an Exascale System]])、2020 年代の到達判定は狭義の FLOPS 基準へ収斂した。 このずれは第 20 章で扱う。 軸 E は、どの数値を信じるかを決める。 Cerebras CS-3 はステンシル計算でピーク比 88 パーセントという高利用率を示す一方 (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])、同じ CS-3 が LLM 推論では 1 ジュールあたり 0.15 トークンにとどまり、H100 の 0.91 トークンを下回る (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 評価対象のワークロードが異なるため単位も異なり直接比較はできないが、「このアクセラレータは効率が高い」という言明が文脈依存であることは、2 本を並べて初めて見える。 ### 1.2 軸の被覆 5 軸のどの値にも、本書の母集団には少なくとも 1 本の文献がある。 値が空の軸はない。 ただし軸 A のうちデータフローとウェーハスケールは Cerebras の 2 本に依存しており、他社の実装による裏づけを持たない。 この偏りは第 21 章に記録する。 --- ## 第 I 部　系譜 技術路線ごとに 5 章を立てる。 年代で切らないのは、同じ年代に複数の路線が並走し、後から一方が他方を吸収するという動きが繰り返されるためである。 --- ## 第 2 章　パイプラインとベクトル ### 2.1 ベクトル機の 2 世代 ベクトルプロセッサは、ベクトル全体に 1 つの命令で同じ演算を施し、パイプライン化された機能ユニットへ要素を 1 クロックあたり 1 個ずつ流し込む計算機である。 CDC STAR 100 と TI ASC を第 1 世代、CRAY-1 を第 2 世代とする分類がある (Source: [[ベクトルプロセッサ]])。 2 つの世代を分けるのは、演算対象をメモリから直接読むか、ベクトルレジスタに置くかの差である。 CRAY-1(1978 年)の設計を見ると、この判断の動機がはっきりする。 Cray Research の Russell は、8 本かける 64 要素のベクトルレジスタ(総量 4,888 バイト、6 ナノ秒の高速記憶)を積んだ理由を、主記憶帯域が 80 百万語毎秒しかなくこれを補う必要があったためだと明記している。 さらにチェイニングという機構を持つ。 ある機能ユニットが 1 クロックに 1 個ずつ出す結果を、ベクトル演算の完了を待たずに別の機能ユニットの入力へ直接流し込むもので、中間結果を主記憶へ書かずに済む。 IBM 360/195 のデータフォワーディングに似ているが、195 が利用者から扱えずスカラー値に限られたのに対し、CRAY-1 は自動でベクトルにも適用する (Source: [[@1978__CACM__The CRAY-1 Computer System]])。 短ベクトルでの損益分岐点が、第 2 世代の実用性を決めた。 数学ライブラリ関数の実測では、ベクトル長 1 で 1 結果あたり約 340 クロックを要するのに対し、ベクトル長 64 ではベクトル版が約 8 クロックから 25 クロック、スカラー版が約 110 クロックから 160 クロックとなり、交差点は 2 要素から 4 要素である (Source: [[@1978__CACM__The CRAY-1 Computer System]])。 ![[_attachments/The-CRAY-1-computer-system/fig07-scalar-vector-timing.png]] **図2-1**:CRAY-1 のスカラー実行とベクトル実行の 1 結果あたりクロック数を、ベクトル長 1 から 64 で比較したもの。上側の水平な 4 本がスカラー、右下へ下がる 4 本がベクトルである。本文が挙げたベクトル長 1 での約 340 クロック、ベクトル長 64 での 8 から 25 クロック、そして交差点が 2 要素から 4 要素に来るという数値は、この交差の位置に対応する。 (Source: [[@1978__CACM__The CRAY-1 Computer System]], 図 7) 短いベクトルでもスカラーより速いという性質が、ベクトル機を特殊用途から汎用の科学計算機へ押し上げた。 物理設計も性能の一部だった。 円筒形の筐体(12 個のくさび形カラムを 270 度の弧に並べる)は配線距離を短縮するためのもので、この小型化が 12.5 ナノ秒のクロックの前提になっている。 発熱密度が CDC 7600 の約 4 倍に達したためフロン冷却と新開発の冷却バーを要した。 信号完全性のために全信号経路長を揃え、IC 全体の 10 パーセントから 20 パーセントがパディング目的で置かれている (Source: [[@1978__CACM__The CRAY-1 Computer System]])。 ### 2.2 日本のベクトル機と自動ベクトル化 日本の 3 社(Fujitsu、Hitachi、NEC)は、Cray とは異なる並列化の単位を選んだ。 東京大学の Oyanagi の調査によれば、日本の機種は 1 つの制御プロセッサの下で多数のベクトルパイプを動かす方式を採り、少数パイプのプロセッサを並列化する Cray X-MP と対照的である。 ベクトルレジスタは Cray より大きく、リスト指定ベクトル命令(ギャザとスキャッタ)を最初から実装していた。 Cray-1 と初期の X-MP にはこれがなかった (Source: [[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。 レジスタ構成の柔軟性にも差がある。 Fujitsu VP の 8K ベクトルレジスタは、1024 要素かける 8 本から 32 要素かける 256 本まで動的に再構成できる (Source: [[ベクトルプロセッサ]])。 CRAY-1 の 64 要素固定長とは思想が異なる。 もう 1 つの差は利用者像である。 日本の 3 社はメインフレームの延長として機械を作り、非専門家でも使えるよう、システム定義関数に頼らない完全な自動ベクトル化コンパイラの整備を普及の条件とみなした。 第 1 世代ではメインフレーム技術がスーパーコンピュータへ移り、第 2 世代では VP2000 や SX-3 の技術がメインフレーム(M-1800、ACOS-3800)へ逆に移ったため、開発費を数百台のメインフレームで償却できたと著者は述べている (Source: [[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。 自動ベクトル化の到達点については、2 つのソースの記述が食い違う。 > [!contradiction] 分岐を含むループのベクトル化がいつ可能になったか > CRAY-1 の論文は、CFT コンパイラが GO TO、IF、CALL を含むループを当面ベクトル化しないと明記する (Source: [[@1978__CACM__The CRAY-1 Computer System]])。 > 一方で日本のスーパーコンピュータ開発史は、Hitachi の M-280H IAP コンパイラが IF 文つき DO ループの自動ベクトル化を世界で初めて支えたと述べる (Source: [[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。 > 両者は同時代の異なる到達点を示しており、どちらが誤りというより、ベンダー間で能力差があったことを示す。 > 機構の側では、Fujitsu FORTRAN77/VP が条件文つきループを、真の割合とロードストア頻度に応じてマスク付き演算、圧縮と伸張、間接アドレス指定の 3 方式から選んでいたことが記録されている (Source: [[自動ベクトル化]])。 コンパイラの能力を横断比較した数値も 1 つだけある。 Nobayashi と Eoyang による Livermore Fortran Kernels 24 本の解析では、日本 3 社、とくに Hitachi のコンパイラが Cray、Alliant、Titan、Convex をベクトル化能力で僅かに上回った (Source: [[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。 ただしこの調査自体が各社提供の諸元(ピーク性能)に依拠しており、持続性能や実アプリケーションでの比較はコンパイラ評価を除いて示されていない (Source: [[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。 ### 2.3 ベクトル機の到達点 日本の 3 社の性能諸元は、ベクトル機の伸びの速さを示す。 第 1 世代では Hitachi S-810/20 が最大 630 メガフロップス、Fujitsu VP-100/200 が 285 と 570 メガフロップス、NEC SX-1/2 が 570 と 1300 メガフロップスである。 第 2 世代では NEC SX-3 が 690 メガフロップスから 22 ギガフロップスまでの 8 モデルを持ち、サイクルは 2.9 ナノ秒まで下がった。 第 3 世代では NEC SX-4 が 1 ギガフロップスから 1 テラフロップス、主記憶帯域は最大 512 GB/s に達する。 いずれもピーク性能の諸元値であり、実アプリケーションの持続性能ではない (Source: [[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。 1990 年代前半に 3 社の方針は分岐した。 Hitachi は共有メモリ型マルチプロセッサへ、Fujitsu はクロスバー結合の分散メモリ型ベクトル並列(VPP500)へ、NEC は共有メモリ型ノードを束ねるクラスタ(SX-4)へ向かった (Source: [[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。 ベクトル機は単体の高速化から、ベクトルノードの並列化へ主戦場を移したことになる。 --- ## 第 3 章　超並列機の時代 ### 3.1 CM-5 の 3 網分離 Thinking Machines の CM-5(1991 年発表)は、単一網で済ませるという当時の定石を退け、機能ごとに 3 つの網を分けた。 データ網(4 分木のファットツリー)、制御網(完全 2 分木)、診断網(JTAG を拡張した木)である (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 データ網が 4 分木のファットツリーである理由は、根に近いほど帯域が太くなる構造にある。 メッセージは送信元と宛先の最小共通祖先まで上ってから下る。 上りの経路選択を擬似乱数で行うことで負荷が自動的に分散し、利用者が病的なトラフィックを避けるプログラミングをしなくてよくなる。 2 分木ではなく 4 分木を選んだのは、ピン数とケーブル線数と最大ケーブル長のトレードオフによる (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 ![[_attachments/The-Network-Architecture-of-the-Connection-Machine-CM-5/fig02-binary-fat-tree.png]] **図3-1**:ファットツリーの概念図。葉にプロセッサ、内部ノードにスイッチを置き、根に近づくほどチャネル容量が太くなる。原図は 2 分木で描かれており、CM-5 のデータ網が 4 分木を使うことは原図のキャプション自身が注記している。本文が述べた「根に近いほど帯域が太くなる」構造と、利用者パーティションごとに専用の部分網を与えられるという性質が、この図の区画分けに対応する。 (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]], 図 2) 制御網はブロードキャスト、リダクション、前方と後方のスキャン、router-done、大域操作を持つ。 スキャンをハードウェアに持たせた判断は、CM-2 の経験から来ている。 多くの高性能データ並列アルゴリズムがスキャンを多用していた (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 前作 CM-2 の SIMD を捨てて MIMD を採りながら、SIMD の長所(データ共有と高速同期)を制御網で取り戻す同期 MIMD という位置づけになる (Source: [[Connection Machine CM-5]])。 診断網の独立は、機能依存の診断が持つ限界への対応である。 CM-1 と CM-2 では診断を書くのが難しく、網羅性が曖昧で、根本原因の報告精度が低かった。 IEEE 1149.1(JTAG)をシステム全体へ並列に拡張し、0 と 1 と B のワイルドカード表記による診断仮想アドレスで部分集合を並列に指定できるようにした。 機内検査の単一縮退故障の網羅率は 99 パーセントを超える (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 性能値は、初版時点のスナップショットとして著者自身が位置づけている。 ランダムな置換で 1 プロセッサあたり 4 メガバイト毎秒超、最近傍などの局所パターンで 15 メガバイト毎秒。 網の遅延は機械規模に応じて 3 マイクロ秒から 7 マイクロ秒で、プロセッサの送受信命令の実行時間を含む。 2K ノード構成では半分ともう半分の間の帯域が各方向 10 ギガバイト毎秒である。 最大構成は 16,384 ノード、1 テラフロップス超、約 30 メートル四方であり、論理設計は 100 万ノードまで拡張できる (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 データ網は配送を保証する代わりに、プロセッサが到着メッセージを最終的にすべて取り出すことを契約として要求する。 これを怠るとデッドロックしうるため、直接プログラミングした場合の危険は利用者側に残る (Source: [[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])。 利用者の負担を隠すという第 0 章の思想は、網の内部では貫かれているが、契約の境界には残る。 ### 3.2 専用低電力ノードという路線 CM-5 から 14 年後、IBM の Gara ら(IBM T. J. Watson Research Center)は Blue Gene/L で別の方向から超並列に到達した。 設計原理は明快である。 空冷ラックではワット毎ラックがほぼ定数(約 20 キロワット)であるため、ラックの性能は電力あたり性能で決まる。 そこで低周波かつ低電力の組込み PowerPC 440 コア(電力目標は 1 コアあたり 1 ワット)を採り、電力あたり性能で高周波かつ高電力のプロセッサを 2 倍から 10 倍上回ると主張した (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]])。 電力を複雑さの根本要因とみなし、低電力化によって設計、検証、立ち上げ、実装を簡素化するという論理も明示されている (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]])。 性能あたり電力を最適化すると、副次的に開発の難易度まで下がるという主張である。 網は CM-5 と同じく機能別に分離された。 点対点用の 3 次元トーラス、集合演算をハードウェアで行う集合網、低遅延バリア網、制御用の Fast Ethernet と JTAG、入出力用の Gigabit Ethernet の 5 つである。 大域通信の支配と小メッセージへの対処として、集合網に整数演算(最小、最大、和、ビット論理)をハードウェアで実装し、遅延を典型的なスーパーコンピュータの網の 10 分の 1 から 100 分の 1 以下に抑えた (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]])。 ![[_attachments/Overview-of-the-Blue-Gene-L-system-architecture/fig04-networks.png]] **図3-2**:Blue Gene/L の網のうち 3 つ。(a) が点対点用の 3 次元トーラス、(b) が集合演算用の大域集合網、(c) が制御用の Fast Ethernet と JTAG および入出力用の Gigabit Ethernet である。本文が述べた 5 網の機能分離のうち、点対点と集合演算と制御と入出力の 4 系統がこの 1 枚に描かれている(低遅延バリア網は本図には含まれない)。 (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]], 図 4) ファットツリーではなく 3 次元トーラスを選んだ理由は規模にある。 ノード数が極端に多いため、リンク長が段数に応じて増大するファットツリーではなく、短い配線で済むトーラスが選ばれた (Source: [[IBM Blue Gene／L]])。 数値は設計値と仕様値である。 65,536 ノード完成時のピーク性能 360 テラフロップス、1 ラック 1,024 ノードで総電力 27.5 キロワット、ノード間接続の 85 パーセント超がラック内で完結する。 3 次元トーラスはノードあたり 6 本の双方向リンクを持ち、ノード通過のハードウェア遅延は約 100 ナノ秒、64 かける 32 かける 32 構成で最大ホップ数 64、最悪ハードウェア遅延 6.4 マイクロ秒である。 集合網のハードウェア遅延は 5 マイクロ秒未満、全域の浮動小数点和は網を 2 回使うため約 10 マイクロ秒。 バリア網は 64Ki ノードで往復遅延 1.5 マイクロ秒未満 (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]])。 > [!note] リンク帯域の表記が文献間で揃っていない > 設計者自身による一次記述は「6 本の双方向リンク、リンクあたり各方向 1.4 Gb/s、合計 2.1 GB/s」とする (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]])。 > 一方 Hennessy と Patterson の付録 F は「6 本の 350 MB/s 双方向リンク」「リンククロック 700MHz の両エッジを使い 1.4 Gbps(175 MB/s)を各ビットシリアルリンク方向ごとに実現」と記す (Source: [[IBM Blue Gene／L]])。 > 350 MB/s かける 6 は 2.1 GB/s であり合計は一致するが、リンク単体の帯域表記の粒度が異なる。 > 本書では一次記述の表記を採る。 著者自身が認める限界も明快である。 対象は拡張性のよいアプリケーション群に限られ、汎用性は主張しない。 クロック網には冗長性がない。 PowerPC 440 は L1 のコヒーレンスを持たずソフトウェアが L1 を管理する必要があるため、対称型マルチプロセッサとしての利用には難点がある。 トーラスの非最小経路制御による障害回避は性能とソフトウェアへの影響をともない一般用ではない (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]])。 --- ## 第 4 章　コモディティクラスタへの転回 ### 4.1 Beowulf が示したこと クラスタコンピューティングは、各ノードが独自の OS を持つ市販計算機を中程度から高程度のレイテンシを持つ LAN などで結び、1 つの並列計算資源として使う方式である。 ベクトル機や SIMD 機の専用ハードウェア機構とも、ノード間を密結合する MPP とも区別される (Source: [[クラスタコンピューティング]])。 1998 年、Sterling(JPL)、Becker(GSFC CESDIS)、Warren(Los Alamos National Laboratory)らは、大量市販の汎用部品で組んだ Beowulf 級システムを NASA の要求に照らして評価した。 1996 年 9 月に LANL と JPL/Caltech へ約 5 万ドルの 16 ノード系を設置し、200 万粒子の N 体重力シミュレーションで 1.19 ギガフロップスと 1.26 ギガフロップスを持続した。 SC'96 では Fast Ethernet 16 本のポイントツーポイント線(100 Mbps)で 2 系を接続し、コードの再最適化なしに持続 2 ギガフロップス超を得ている。 約 32 ドル毎メガフロップスであり、当時のベンダー製品の約 10 倍の価格性能比にあたる。 ただしベンダーの値下げによって差が 4 倍にとどまる場合があることも、著者は併記している (Source: [[@1998__IEEE Aerospace__An Assessment of Beowulf-class Computing for NASA Requirements]])。 なぜ市販 PC で足りたのか。 PC の浮動小数点性能は直近 3 世代で約 18 倍(結論部では約 20 倍)に伸びており、ワークステーション用プロセッサの約 5 倍を大きく上回っていた (Source: [[@1998__IEEE Aerospace__An Assessment of Beowulf-class Computing for NASA Requirements]])。 商用市場の物量が、専用設計の改良速度を追い越した時期にあたる。 ### 4.2 数百ノードで現れる壁 同じ論文は、数百ノード級(著者らが dreadnought 級と呼ぶ規模)で何が律速するかも示している。 ハイパーキューブやトーラスのようなノード経由の通信トポロジは大規模化できるがバイセクション帯域が伸びず遅延が増える。 ネットワーク費用は規模に対して超線形に増え、クロススイッチの費用はポート数の 2 乗で効く。 Fast Ethernet の 2 段ツリーは約 240 プロセッサまで容易に組めるが、ルートスイッチが全体ランダム通信のボトルネックになり、スパニングツリーの経路制御のためスイッチを複数並べてもバイセクション帯域を増やせない (Source: [[@1998__IEEE Aerospace__An Assessment of Beowulf-class Computing for NASA Requirements]])。 伸びるアプリケーションの条件も明示されている。 並列 out-of-core 形式であること、明示的な大域同期を要しないこと(陽的時間刻みの格子 CFD は隣接間のペア通信で済む)、通信を 1 回の大規模通信にまとめること、の 3 つである (Source: [[@1998__IEEE Aerospace__An Assessment of Beowulf-class Computing for NASA Requirements]])。 第 0 章で見た Amdahl の指摘、すなわち大域同期とデータ管理の逐次部分が並列化を阻むという議論が、30 年後のコモディティクラスタで同じ形をとって現れている。 通信網の選択が性能に与える影響を、同じ部品構成で切り分けた比較もある。 LANL の実験では、ASCI Red が 16 プロセッサの Loki(Fast Ethernet)に比べ全体性能で 25 パーセントから 30 パーセント高かった。 Fast Ethernet の NIC は約 50 ドルでアプリケーション間レイテンシ約 100 マイクロ秒(80 マイクロ秒未満も観測)、Myrinet は帯域 1 Gbps 超でレイテンシ 20 マイクロ秒未満だが NIC が約 1,400 ドル毎ポートである (Source: [[@1998__IEEE Aerospace__An Assessment of Beowulf-class Computing for NASA Requirements]])。 価格性能比の優位は、遅延に鈍感なアプリケーションを選ぶことと引き換えに得られていた。 実際、NAS ベンチマーク(SP、LU、BT)が約 100 マイクロ秒のレイテンシで 200 プロセッサ超でも理想に近い持続性能を示したことについて、著者は「遅延に鈍感になるよう作られたコードに限る」と明記している (Source: [[@1998__IEEE Aerospace__An Assessment of Beowulf-class Computing for NASA Requirements]])。 ### 4.3 クラスタが要求したソフトウェア コモディティクラスタの普及は、ハードウェアと同時に 2 種類のソフトウェアを必要にした。 資源管理と並列ファイルシステムである。 2003 年、LLNL の Jette と Grondona は SLURM を、数千ノード規模の Linux クラスタ向けにシンプルさ、オープンソース、移植性、スケーラビリティ、耐障害性、セキュリティ、システム管理を設計方針として構築した。 特徴的なのは、SLURM 自身がデフォルトで単純な FIFO スケジューリングのみを実装し、優先度決定やジョブ順序の変更を Maui Scheduler や DPCS のような外部スケジューラへプラグイン経由で委譲する設計である。 スケジューリング判断をあえて外部エンティティに委ねている。 ノードとパーティションの状態や設定をビットマップで保持し AND 演算することで、数万件規模の個別ノード設定比較を回避した (Source: [[@2003__JSSPP__SLURM - Simple Linux Utility for Resource Management]])。 インターコネクトの性質が資源割り当てにも染み出す。 Quadrics インターコネクトはハードウェアのメッセージブロードキャストに連続ノード割当を要求するため、SLURM は可能な限り連続ノードを優先して割り当てる (Source: [[@2003__JSSPP__SLURM - Simple Linux Utility for Resource Management]])。 性能は 1000 ノードクラスタでの `/bin/hostname` 実行で測られた。 2002 年 11 月、開発途中でチューニング未実施の段階、1 ノードあたり 2 タスクという条件で、SLURM は Quadrics RMS と同等(950 ノードで約 5 秒)であり、IBM LoadLeveler より約 80 倍高速だった。 LoadLeveler は全ノード数域で約 10 秒とほぼノード数に依存しない (Source: [[@2003__JSSPP__SLURM - Simple Linux Utility for Resource Management]])。 並列ファイルシステムの側は Lustre が担った。 2003 年の設計解説で Cluster File Systems の Schwan は、1,000 ノード規模ではメタデータのロック方式とオブジェクトベース入出力の設計選択が全体のスケーラビリティを左右すると述べている。 親ディレクトリの一括ロックは単一利用者には効率的だが、2,000 プロセスが同一ディレクトリで同時にファイルを作成する状況では直列化がボトルネックになる。 そこで lookup に操作の意図を渡し、競合が低い場合はライトバックロックを返し、競合が高い場合はサーバ側で処理を完結させ状態コードのみを返す方式へ整理した。 オブジェクトプロトコルは、共有ブロックファイルシステムが持つ共有ディスクのコストとブロック割り当てロックの問題を、ストレージターゲット側にオブジェクトとブロックの割り当てを持たせることで回避する (Source: [[@2003__CFS__Lustre building a cluster file system for 1,000 node clusters]])。 この設計は 2001 年から 2005 年に書かれた 539 ページの設計文書に詳しい。 クライアント(数万台)、OST(数千台)、MDS(数十台)の 3 種のノードに分離し、Portals というネットワーク抽象化層が RDMA をネイティブに支援して TCP のバッファコピーモデルを回避する。 分散ロック管理は VAX Cluster DLM を基盤に 6 段階のロックモードとエクステントおよびインテントロックを統合した。 対称クラスタはメンバーシップとクォーラムのスケーラビリティ不足で棄却され、クライアントを比較的権限の弱い外部システムとみなす非対称構成が採られた。 基盤ファイルシステムに ext3 を選んだ理由は、XFS や ReiserFS に対し性能差が最小限でありながらコードサイズが ReiserFS の 10 パーセント、XFS の 3 パーセントに収まることだった (Source: [[@2019__arXiv__The Lustre Storage Architecture]])。 --- ## 第 5 章　日本の専用機路線と京 ### 5.1 京が解こうとした 3 つの課題 Blue Gene/L が示した専用低電力ノードの路線を、日本は別の形で進めた。 富士通の追永勇次(富士通 次世代テクニカルコンピューティング開発本部)は、100 万コア級の超並列で 10 ペタフロップスの実行性能を得るための阻害要因を 3 つに整理している。 並列アプリケーションのスケーラビリティは演算時間に対する通信時間の比で決まるという前提から、規模拡大にともなう通信時間の増大、処理の不均衡、入出力時間の増大を課題とし、それぞれに対して通信と入出力の時間削減(Tofu、VISIMPACT、ファイルシステム)、処理遅延と不均衡の最小化(Tofu、高機能バリア、OS ジッタ対策)、阻害要因の可視化(チューニングツール)を対置した (Source: [[@2011__応用物理__次世代スパコン「京」のコアテクノロジ]])。 VISIMPACT は 8 コアを 1 プロセスとして扱うことでプロセス数を 8 分の 1 に抑え、通信時間を削減する。 抽出した実プログラム 146 本を 1 ノード 8 コアで実行した評価では、90 パーセントで性能が向上し、10 パーセントは 6 倍以上向上した (Source: [[@2011__応用物理__次世代スパコン「京」のコアテクノロジ]])。 高機能バリアインタフェースの設計根拠は、ハードウェアとソフトウェアの実装コストの差にある。 コア間バリアがハードウェアで約 0.1 マイクロ秒、ソフトウェア実装で約 2 マイクロ秒と 20 倍の開きがあるため、粒度の小さい演算ループにも自動並列化を適用できるようになる。 768 プロセスでの評価では、ソフトウェア実装比でバリア同期が 6.7 倍、縮約演算が 7.5 倍高速化した (Source: [[@2011__応用物理__次世代スパコン「京」のコアテクノロジ]])。 OS ジッタ対策の論理は、逐次計算と並列計算で問題の性質が変わることに基づく。 逐次計算では平均値のみが問題になるが、並列計算では同期の繰り返しによって遅延が蓄積する。 そこで長いノイズを 50 マイクロ秒以下に、平均ノイズ率を一般的な Linux の 10 分の 1 から 100 分の 1 に抑え、高機能バリアインタフェースを使った協調スケジューリングでノイズの影響を一斉化し低減した (Source: [[@2011__応用物理__次世代スパコン「京」のコアテクノロジ]])。 ファイルシステムはジョブ用(ローカル)と一般利用者用(グローバル)を分離し、入出力の干渉を隔離した (Source: [[@2011__応用物理__次世代スパコン「京」のコアテクノロジ]])。 この 2 層構成は後の Fugaku にも引き継がれる (Source: [[Fugaku]])。 なお本稿は 2011 年 3 月受理の解説記事であり、実験の節を持たない。 多重転送性能は実測と明記されているが、VISIMPACT の効果と高機能バリアの実行時間、姫野ベンチマークの結果については実測かシミュレーションかが本文に明記されていない。 OS ジッタの図は Bertsimas bound モデルによる実行時間上限の計算であり、京の曲線は達成値ではなく目標値である (Source: [[@2011__応用物理__次世代スパコン「京」のコアテクノロジ]])。 ### 5.2 Tofu が選んだ直接網 京の結合網 Tofu は、間接網を使う既存機より 2 桁大きい 10 万ノード級のスケーラビリティを狙った。 富士通の Ajima らは、その根拠を投資構造の差に置いている。 間接網(外部スイッチ)はノード数の増加に応じてスイッチ規模が増えるのに対し、直接網の 6 次元メッシュとトーラスではノードあたりのハードウェア量が規模にほぼ依らず、ICC チップ 1 個と約 2.2 本のケーブルだけで済む。 ケーブルを追加するだけでノード数を増やせる (Source: [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]])。 6 軸の役割分担は物理実装に対応する。 X と Y はラック間、Z と B はシステムボード間(B 軸は 3 枚のボードをリングで結び冗長性を持たせる)、A と C は長さ 2 でボード上のプロセッサを結ぶ。 利用者には 1 次元から 3 次元のトーラスを見せつつ、XYZ のいずれか 1 軸と ABC のいずれか 1 軸を組み合わせて 3 つの空間を作る。 ![[_attachments/Tofu--Interconnect-for-the-K-computer/fig02-6d-topology.png]] **図5-1**:Tofu の 6 次元メッシュとトーラスの模型。大きな格子が X、Y、Z の 3 軸、右上の拡大図が A、B、C の 3 軸にあたる。本文が述べた「X と Y はラック間、Z と B はシステムボード間、A と C は長さ 2 でボード上のプロセッサを結ぶ」という役割分担が、この入れ子構造として見える。 (Source: [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]], 図 2) B 軸の 3 ノードリングが持つ一筆書きの性質を使って単一ノードを避けたランクマッピングを行うことで、障害ボードの保守と交換の最中も他のボードは稼働を続けられる (Source: [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]])。 集団通信は専用ハードウェア(TBI)で処理される。 主記憶を経由するソフトウェア処理では遅延が大きく OS ジッタの影響も受けるためである (Source: [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]])。 ICC の仕様は設計値である。 動作周波数 312.5 MHz、スイッチング容量 100 GB/s、リンク速度は双方向 5 GB/s、ポート数 10、65nm CMOS、ダイサイズ 18.2 ミリメートルかける 18.1 ミリメートル、論理ゲート 4800 万。 ホップあたり遅延は仮想カットスルー方式による設計値で約 0.1 マイクロ秒、パケット長 2KB 以下でのバンド幅効率の理論値は 90 パーセント以上である (Source: [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]])。 リンク帯域は片側 5 GB/s、ノードあたり 10 リンクで合計 100 GB/s(双方向計)であり、多重転送は実測で 1 多重 4.7 GB/s、4 多重 15 GB/s と 3 倍以上に伸びる (Source: [[Tofu Interconnect]])。 本稿は設計解説であり評価の節を持たないため、TBI の効果を定量で確かめるには応用物理の解説記事が必要になる (Source: [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]])。 2 本のソースは競合ではなく、設計の記述と効果の測定という役割分担の関係にある。 > [!note] 次元数の表現が 2 本のソースで異なる > 応用物理の記事は「従来の 3 次元トーラスに対し、ノード間リンク数を 6 から 10 に増やした 6 次元メッシュとトーラス」と記す (Source: [[@2011__応用物理__次世代スパコン「京」のコアテクノロジ]])。 > Tofu の専門論文は 6 次元(X、Y、Z、A、B、C)を座標軸として定義し、リンク数の増分という表現を採らない (Source: [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]])。 > 同じ設計を指すが説明の切り口が異なる。 ### 5.3 日本における計算機を作るという営み 系譜を人の側から見た記録も 1 本ある。 東京大学の平木敬は最終講義で、計算機を作る研究が構想、予算獲得、基本設計、詳細設計、外注作業、製造と組立、テストとデバッグという長い工程を経ること、国家規模のスーパーコンピュータでも完成まで長い年月を要することを述べている。 FLATS(1978 年から 1982 年)、SIGMA-1、GRAPE-DR(2004 年から 2009 年)、遠距離研究データ共有と遠距離 TCP 通信の高速化に取り組んだ Data-Reservoir プロジェクト(2001 年から)が取り上げられる (Source: [[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]])。 ただしこのソースには制約がある。 自動字幕の取得に失敗したため文字起こしが存在せず、音声のみに依存する発言、質疑応答、細かな経歴説明は未確認である。 記録されているのは映像フレームから読み取れた範囲にとどまる (Source: [[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]])。 --- ## 第 6 章　アクセラレータの到来 ### 6.1 GPU クラスタの最初期 2004 年、Stony Brook University の Fan らは、コモディティ GPU を 32 ノード分クラスタ化し、格子ボルツマン法による都市規模の流体シミュレーションを実行した。 当時の GPU はグラフィックスパイプラインとして使うしかなく、計算データをテクスチャの色成分として配置し Cg フラグメントプログラムで計算するという方式だった (Source: [[@2004__SC__GPU Cluster for High Performance Computing]])。 構成は Pentium Xeon 2.4GHz のデュアル CPU と GeForce FX 5800 Ultra 128MB を 1 Gigabit Ethernet で結んだ 32 ノードで、GPU 追加分の理論ピークは 512 ギガフロップス、GPU の価格は 12,768 ドル、GPU 追加分の価格性能比は 41.1 メガフロップス毎ドルである(クラスタ全体は約 136,000 ドル)。 480 かける 400 かける 80 の格子で、ニューヨーク市タイムズスクエア周辺の約 1.66 キロメートルかける 1.13 キロメートル、91 ブロック約 850 棟のモデルを、30 GPU ノードで 1 ステップ 0.31 秒で回している (Source: [[@2004__SC__GPU Cluster for High Performance Computing]])。 通信の扱いに 3 つの工夫がある。 通信と計算のオーバーラップ、隣接ノード間の交換を複数ステップに分け斜め方向の第二近傍通信を最近傍中継の間接パターンにすること、GPU から CPU への境界データ読み出しをフラグメントプログラムで 1 テクスチャへ集約して API 呼び出し回数を削減することである (Source: [[@2004__SC__GPU Cluster for High Performance Computing]])。 スケーリングの限界も明確に出ている。 各ノード 80 の 3 乗のサブドメインという条件で、1 ノードでは GPU 高速化が 6.64 倍、30 ノードで 4.62 倍、32 ノードで 4.54 倍に下がる。 28 ノードまでは通信を計算に完全に重ね合わせられるが、それ以降は非重複部分が生じる。 32 ノードでの並列効率は 66.8 パーセント(49.2 メガセル毎秒)である (Source: [[@2004__SC__GPU Cluster for High Performance Computing]])。 なお CPU 側の比較は各ノード 1 CPU スレッドのみで SSE 最適化を適用していないため、比較条件には限界がある (Source: [[@2004__SC__GPU Cluster for High Performance Computing]])。 律速の所在が、以後 8 年にわたって同じ場所に現れる。 2004 年の論文は AGP 8x の非対称帯域(下り 2.1 GB/s、上り 133 MB/s)が GPU クラスタの通信全体を制限すると指摘した (Source: [[@2004__SC__GPU Cluster for High Performance Computing]])。 ノード間のネットワークは 1 Gigabit Ethernet から InfiniBand、Gemini へと大幅に高速化したが、アクセラレータとホストを結ぶノード内の接続は、以後の世代でも繰り返し名指しされる。 ### 6.2 Roadrunner とペタフロップスの突破 2008 年、Los Alamos National Laboratory の Barker らは、汎用 Opteron と専用アクセラレータ PowerXCell 8i を同数組み合わせたヘテロジニアス構成で、世界で初めて持続 1 ペタフロップスを突破した Roadrunner を報告した (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])。 設計の骨子は、2 つの弱点を相互に補うことにある。 Cell BE の倍精度が弱い(単精度 217.6 ギガフロップス毎秒に対し倍精度 21.0)ため、倍精度浮動小数点ユニットを完全パイプライン化して再設計した PowerXCell 8i(SPE ピーク 102.4 ギガフロップス毎秒)を使う。 PowerPC コアが弱い(Opteron の約 4 分の 1)ため、Opteron コア 1 個を PowerXCell 8i 1 個に対応させる。 ノードは 1 枚の Opteron ブレードと 2 枚の Cell ブレードからなる triblade 構成で、Cell 同士の通信は必ず Opteron を経由する (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])。 ![[_attachments/Entering-the-Petaflop-Era--The-Architecture-and-Performance-of-Roadrunner/fig01.png]] **図6-1**:Roadrunner の計算ノード(triblade)の構造。上部の 2 枚の QS22 ブレードに PowerXCell 8i が 2 個ずつ、下部の LS21 ブレードに Opteron が 2 個ある。2 枚の Cell ブレードの間に直接の線が無く、すべての経路が中央の HT2100 を介して Opteron 側へ降りていることが、本文の「Cell 同士の通信は必ず Opteron を経由する」という記述に対応する。SPE の 102.4 Gf/s と PPU の 6.4 Gf/s という表記は、本文が述べた Cell 内部の性能の非対称を示している。 (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]], 図 1) システム全体は 3,060 ノード、12,240 基の PowerXCell 8i と 12,240 の Opteron コアで、倍精度ピーク 1.38 ペタフロップス毎秒、単精度 2.91 ペタフロップス毎秒。 全体ピークの約 95 パーセントが PowerXCell 8i に由来する。 2008 年 5 月に納入前の初期構成で LINPACK 1.026 ペタフロップス毎秒を記録し、2008 年 6 月の Green500 では 437 メガフロップス毎ワットで 3 位に入った (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])。 通信階層の深さが性能を決めた。 別ノードの Cell への 0 バイトメッセージは 8.78 マイクロ秒を要し、その内訳は Cell から Opteron への DaCS と PCIe が 3.19 マイクロ秒を 2 回、Opteron 間の MPI と InfiniBand が 2.16 マイクロ秒である。 すなわち 8.78 マイクロ秒のうち 6.38 マイクロ秒がノード内の転送で失われている (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])。 メモリ帯域の非対称も大きい。 STREAM TRIAD の実測は Opteron が 5.41 GB/s、PowerXCell 8i の PPE が 0.89 GB/s、SPE が 29.28 GB/s である (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])。 Sweep3D による評価では、全 3,060 ノードで Opteron 比約 2.3 倍の実測が得られた。 一方、検証済みモデルで PCIe がピーク性能を出すと仮定した場合の最良値は約 4.3 倍である(弱スケーリング、SPE あたり 5 かける 5 かける 400 の部分格子、MK=20、角度数 6)。 実測がモデル最良値の半分程度にとどまる原因は、納入前の初期ソフトウェア、とくに DaCS と PCIe のドライバの未成熟にある (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])。 > [!warning] Roadrunner 論文の数値には内部不整合がある > 結論部の「小規模で 10 倍、大規模で 5 倍」という記述は、図 14 の最良値(1 ノード約 7.4 倍、3,060 ノード約 4.3 倍)と一致しない。 > 序盤の「PowerXCell 8i は Cell BE の倍精度ピークの 7 倍」も、SPE 集計(102.4 対 14.6)では成り立つがチップ全体(108.8 対 21.0)では約 5 倍にとどまる。 > この論文から数値を引くときは、どの集計単位の値かを確認する必要がある (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])。 ### 6.3 Titan と移植性という要件 2012 年、Oak Ridge National Laboratory の Bland らは、稼働中の本番機 Jaguar を Gemini インターコネクトと GPU を持つ XK6 へ 2 段階で換装した経験を報告した。 SeaStar と Gemini は同じケーブルとバックプレーンを使うが電気的に互換性がないため、Jaguar を 104 キャビネットと 96 キャビネットの 2 区画に分け、X 次元のケーブルを外して片側ずつ換装した。 分散配置されたサービスノードと入出力ノード、DDR InfiniBand 網により、区画を分けてもファイルシステム帯域がノード数に比例して保たれる設計を利用している (Source: [[@2012__CUG__Titan - Early experience with the Cray XK6 at Oak Ridge National Laboratory]])。 換装で得られた通信性能の差は大きい。 MPI 単方向帯域は XK6 が 5.87、3.47、6.09 GB/s(X、Y、Z 軸)に対し XT5 が 1.62 GB/s、隣接ノードの 0 バイト遅延は XK6 が 1.50 から 1.70 マイクロ秒に対し XT5 が 6.20 マイクロ秒である(XK6 は Jaguar 換装後、XT5 は 2009 年 10 月の Istanbul 換装時点の実測) (Source: [[@2012__CUG__Titan - Early experience with the Cray XK6 at Oak Ridge National Laboratory]])。 Titan がアクセラレータ路線に残した最大の貢献は、ハードウェアではなくプログラミングモデルである。 GPU ハイブリッドを活用するには従来の MPI による領域分割だけでは足りず、SMP 的な並列性(スレッドとローカル MPI コミュニケータ)と GPU のベクトル的並列性を重ねる階層化が必要になる。 著者らはポータビリティ、生産性、性能の 3 点からディレクティブ方式を推奨し、NVIDIA、Cray、CAPS-Enterprise、PGI と協力して OpenACC を事実上の標準として成立させた。 CUDA は当時すでに成熟していたが、段階的移植、迅速な試作、移植性を優先して到達目標という位置づけにとどめている (Source: [[@2012__CUG__Titan - Early experience with the Cray XK6 at Oak Ridge National Laboratory]])。 CAAR の 5 アプリケーションでの初期加速率は、GPU なしの同一 XK6 と CSCS の XE6 をそれぞれ対照として、S3D が 1.5 倍と 1.4 倍、DENOVO が 3.5 倍と 3.3 倍、LAMMPS が 6.5 倍と 3.2 倍、WL-LSMS が 3.1 倍と 1.6 倍、CAM-SE が 2.6 倍と 1.5 倍である。 注目すべきは、リファクタリング自体が CPU 専用の XT5 上でも S3D を 2 倍、DENOVO を 2 倍、CAM-SE を 1.7 倍高速化したことで、GPU とは独立の効果が含まれる (Source: [[@2012__CUG__Titan - Early experience with the Cray XK6 at Oak Ridge National Laboratory]])。 なおこの結果は第 1 段階の開発用パーティション(960 個の Fermi GPU)での初期値であり、Kepler 搭載後の Titan 全系の性能ではない。 表は比だけを示し絶対性能、問題サイズ、ノード数を示していない (Source: [[@2012__CUG__Titan - Early experience with the Cray XK6 at Oak Ridge National Laboratory]])。 ### 6.4 2 つの移植戦略 Roadrunner と Titan は同じアクセラレータ混在路線に属しながら、移植戦略が正反対を向いている。 Roadrunner の SPE 中心モデルは、コードの主体をアクセラレータ側へ書き直し、Opteron を通信の中継役へ格下げする。 Titan は MPI に OpenMP と OpenACC または CUDA を重ねる階層的並列性を採り、同じカーネルを CPU でも動かせる移植性を重視した (Source: [[ヘテロジニアスコンピューティング]])。 この差は 4 年間のソフトウェア環境の成熟度に対応する可能性がある。 2008 年の時点では標準的なディレクティブが存在せず、低水準 API に直接頼るしかなかった。 2012 年には OpenACC という新標準を自ら確立できた (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]], [[@2012__CUG__Titan - Early experience with the Cray XK6 at Oak Ridge National Laboratory]])。 専用ノード路線(Blue Gene/L、京)とアクセラレータ路線(Roadrunner、Titan)の文献には、もう 1 つ性格の差がある。 前者は仕様上の設計値を細かく提示する一方で実機実測を別文献に委ねており (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]], [[@2012__FUJITSU Sci Tech J__Tofu - Interconnect for the K computer]])、後者はソフトウェア層の未成熟という限界を自ら明記している (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]], [[@2012__CUG__Titan - Early experience with the Cray XK6 at Oak Ridge National Laboratory]])。 --- ## 第 II 部　設計空間 第 I 部が示した路線の分岐を、設計上の選択肢として整理し直す。 以降の 7 章は、演算、メモリ、結合網、通信ソフトウェア、ストレージ、電力、設計方法論の順に並ぶ。 --- ## 第 7 章　演算と並列性の供給源 ### 7.1 並列性の 3 つの階層 計算機アーキテクチャの標準的な整理では、性能向上の手段は命令レベル並列(ILP)、データレベル並列(DLP)、スレッドレベル並列(TLP)の 3 つに分かれる。 スーパーコンピュータの系譜は、この 3 つを順に掘り尽くしてきた歴史として読める。 ILP は 2005 年前後に構造的な限界へ達した。 David Wall の 1993 年の研究は、64 命令同時発行、完璧なメモリ曖昧性解消、大規模レジスタリネーミングという非現実的に積極的な構成を仮定し、命令ウィンドウを無限大にしても整数プログラムの ILP が 10 前後で頭打ちになることを示した。 著者ら自身がこの前提を「非現実的なほど積極的」と評している (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 3 Instruction-Level Parallelism and Its Exploitation]])。 投機実行の無駄も大きく、SPEC integer ベンチマーク群で平均 19 パーセントの命令が投機ミスによって無駄になる(Intel Core i7 上の実測、個別には perlbench が最大 39 パーセント程度、libquantum が約 1 パーセント) (Source: [[@2019__CACM__A New Golden Age for Computer Architecture]])。 マルチイシュー発行ロジックが 1 クロックで完結する必要があるため複雑さが発行幅の 2 乗でスケールするという制約も、ILP の頭打ちを説明する (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 3 Instruction-Level Parallelism and Its Exploitation]])。 世代比較がこれを裏づける。 IBM Power4(2001 年)から Power8(2014 年)へ 5 世代進む間に、発行幅は 5 から 8 へと微増したにすぎないのに対し、トランジスタ数は 10 倍以上、オンチップキャッシュは 1.5 MiB から 103 MiB、コア数は 2 から 12 へ増えている (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 3 Instruction-Level Parallelism and Its Exploitation]])。 資源は ILP ではなくキャッシュとコア数へ振り向けられた。 実務者向けの解説も同じ結論に達している。 アウトオブオーダー実行の実際の効果はインオーダーに対し約 20 パーセントから 40 パーセントの向上にとどまり、実アプリケーションの IPC は SPECint でも平均 2 未満である。 パイプライン段数の拡張は Pentium 4E Prescott の 31 段という形で電力の壁に当たって失敗した (Source: [[Modern-Microprocessors-A-90-Minute-Guide]])。 TLP も Amdahl の法則と電力制約の複合によって頭打ちになる。 22nm から 11nm への技術予測では、同一ダイ面積で 96 コアへ増やせるが全コア稼働時の消費電力が 1.79 倍になり、165 ワットの上限では 54 コアしか同時稼働できない。 逐次実行が 1 パーセント、50 コア並列が 9 パーセント、全コア並列が 90 パーセントという構成で Amdahl の法則を適用すると、96 コア世代の実効スピードアップは 35.5 倍、24 コア機は 19.5 倍であり、4 倍のコア数増に対して 2 倍未満の改善にとどまる (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 5 Thread-Level Parallelism]])。 この頭打ちの根は 1 つの物理現象にある。 Dennard スケーリング(トランジスタ縮小時に電力密度が一定に保たれる性質)が 2004 年頃に終焉し、Intel が単一プロセッサの高性能化を中止してマルチコアへ転換する直接の引き金になった。 動的電力は容量負荷かける電圧の 2 乗かける周波数に比例し、静的電力はリーク電流かける電圧に比例してトランジスタ数の増加とともに増える (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]])。 結果として性能成長率は段階的に落ちた。 VAX-11/780 を基準とする 40 年間の相対性能推移では、1986 年以前が年率 22 パーセント、1986 年から 2003 年が 52 パーセント、2003 年から 2011 年が 23 パーセント、2011 年から 2015 年が 12 パーセント、2015 年以降が 3.5 パーセントである (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]])。 同じ分解は Turing 賞講演版でも、CISC 時代 22 パーセント、RISC 時代 52 パーセント、マルチコア時代 23 パーセント、Amdahl の法則が支配する時期 12 パーセント、予測される終端 3 パーセントとして提示される (Source: [[@2019__CACM__A New Golden Age for Computer Architecture]])。 ### 7.2 データレベル並列という共通の系統 ベクトルアーキテクチャ、マルチメディア SIMD、GPU は同一の DLP 系統に属し、GPU は多数のレーンを持つ浅くマルチスレッド化されたベクトルプロセッサとして理解できる (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 4 Data-Level Parallelism in Vector, SIMD, and GPU Architectures]])。 第 2 章で見た CRAY-1 のベクトル機構と、第 6 章で見た GPU クラスタは、こう整理すると同じ軸の上の 2 点になる。 両者を分けるのは、機構を明示するのが誰かである。 ベクトル機はベクトル長レジスタとストリップマイニング、述語レジスタによる IF 変換、メモリバンクとストライドアクセス、gather-scatter による疎行列対応をコンパイル時に明示する。 GPU のアドレスコアレッシングは、これらを実行時のハードウェアが肩代わりする (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 4 Data-Level Parallelism in Vector, SIMD, and GPU Architectures]])。 GPU の効率が落ちる条件も明示されている。 分岐発散では、等長パスの単純な IF-THEN-ELSE で効率が 50 パーセント以下、二重ネストで 25 パーセント、三重ネストで 12.5 パーセントになる (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 4 Data-Level Parallelism in Vector, SIMD, and GPU Architectures]])。 ループレベル並列性の検出においても、一般の依存判定は NP 完全であり、ポインタや手続き呼び出しをまたぐ解析はとくに困難である (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 4 Data-Level Parallelism in Vector, SIMD, and GPU Architectures]])。 第 2 章で見た自動ベクトル化の苦闘は、理論的な難しさに裏打ちされていた。 ### 7.3 Roofline という共通言語 演算とメモリのどちらが律速かを判定する道具として、本書は Roofline モデルを繰り返し使う。 Lawrence Berkeley National Laboratory の Williams、UC Berkeley の Waterman と Patterson は、到達可能性能を「ピーク演算性能とピークメモリ帯域かける演算強度の小さいほう」として 1 枚の 2 次元グラフに表した。 演算強度は DRAM に出入りするバイトあたりの演算数と定義され、キャッシュ階層で濾過された後のトラフィックだけを数えるため、キャッシュ最適化が演算強度を押し上げる形でモデルに取り込まれる (Source: [[@2009__CACM__Roofline - An Insightful Visual Performance Model for Multicore Architectures]])。 ![[_attachments/Roofline--an-insightful-visual-performance-model-for-multicore-architectures/fig01-roofline-x2-x4.png]] **図7-1**:Roofline モデルの基本形。(a) では斜めの線がピークメモリ帯域、水平な線がピーク演算性能を表し、2 本が折れ合う点より左が帯域律速、右が演算律速になる。本文が述べた「到達可能性能はピーク演算性能とピーク帯域かける演算強度の小さいほう」という定義が、この上限線の形そのものである。(b) はリッジポイントの位置が機械によって動くことを示しており、本文が第 7.3 節で引いた SX-9 の 0.6 と Core i7 920 の 2.6 という対比は、この横方向の移動にあたる。 (Source: [[@2009__CACM__Roofline - An Insightful Visual Performance Model for Multicore Architectures]], 図 1) 屋根の下に天井を重ねることで、どの最適化をどの順序で試すべきかと各最適化の見込み効果が視覚的に読める。 3C モデルとの結びつきも明示されている。 強制ミスが最小トラフィックと最高演算強度を決め、競合ミスと容量ミスが演算強度を下げる (Source: [[@2009__CACM__Roofline - An Insightful Visual Performance Model for Multicore Architectures]])。 実測での検証は 4 機種かける 4 カーネルで行われた。 AMD Opteron X2(2.2GHz、デュアルソケット)はピーク倍精度 17.6 ギガフロップス毎秒、ピークメモリ帯域 15 GB/s。 Xeon(Clovertown)はピーク 75 ギガフロップス毎秒、STREAM 実測 5.9 GB/s、リッジポイント 6.7 フロップス毎バイト。 Opteron X4(Barcelona)はピーク 74 ギガフロップス毎秒、STREAM 実測 16.6 GB/s、リッジポイント 4.4。 Sun UltraSPARC T2+ はピーク 19 ギガフロップス毎秒、STREAM 実測 26.0 GB/s、リッジポイント 0.33 と 4 機中最低。 IBM Cell(QS20)はピーク 29 ギガフロップス毎秒、STREAM 実測 47.0 GB/s、リッジポイント 0.65 である。 カーネル側の演算強度は SpMV が 0.17 から 0.25、LBMHD が 0.70 から 1.07、Stencil が 0.33 から 0.50、3D FFT が 1.09 から 1.64 であり、16 通りすべてで実測性能が天井の間に収まった (Source: [[@2009__CACM__Roofline - An Insightful Visual Performance Model for Multicore Architectures]])。 リッジポイントの位置が機械の性格を表す。 NEC SX-9 のリッジポイントは 0.6、Intel Core i7 920 は 2.6 であり、演算強度 0.25 の同じカーネルを走らせると SX-9 が i7 の 10 倍速い(SX-9 はピーク演算性能 102.4 ギガフロップス毎秒、帯域 162 GB/s、i7 920 は帯域 16.4 GB/s) (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 4 Data-Level Parallelism in Vector, SIMD, and GPU Architectures]])。 ベクトル機がメモリ律速のカーネルで強いという第 2 章の主張は、この座標の上で説明できる。 著者ら自身は、モデルの限界も明示している。 天井の高さと順序はカーネルごとに変わりうる。 天井の測定には計算機ごとのマイクロベンチマーク実験が必要である。 屋根はカーネルの上限を示すが、達成性能そのものを予測するわけではない (Source: [[@2009__CACM__Roofline - An Insightful Visual Performance Model for Multicore Architectures]])。 ### 7.4 精度という自由度 演算の精度は、科学計算の側では長く固定の制約だったが、混合精度反復精密化によって設計の自由度へ変わった。 University of Tennessee の Haidar、Tomov、Dongarra と University of Manchester の Higham は、FP16 のテンソルコアで LU 分解を行い、残差計算と補正を FP64 で繰り返すことで、FP64 精度の解を最大 4 倍高速に得られることを示した (Source: [[@2018__SC__Harnessing GPU Tensor Cores for Fast FP16 Arithmetic to Speed up Mixed-Precision Iterative Refinement Solvers]])。 テンソルコアが単純な FP16 演算より数値的に優れる理由は、乗算を FP16 で行いながら蓄積を FP32 で行う混合精度 GEMM だからである。 さらに、反復精密化の条件数制約(κ∞(A) が 10 の 4 乗未満)を、補正方程式の求解を三角求解から FP16 の LU を前処理とした GMRES に切り替えることで 10 の 8 乗未満まで緩和できる。 マルチ精度 LU 分解では、数値的に感度の高いパネル分解と trsm を FP32 で、計算量の大部分を占める後続の行列更新を FP16 テンソルコアで実行する (Source: [[@2018__SC__Harnessing GPU Tensor Cores for Fast FP16 Arithmetic to Speed up Mixed-Precision Iterative Refinement Solvers]])。 V100 PCIe でのピーク性能は FP64 が 6.8 テラフロップス毎秒、FP32 が 14、FP16 が 28、FP16 テンソルコアが 85 であり、FP64 比で約 12 倍の開きがある(正方行列 GEMM 条件のベンダー公表値)。 実世界行列での実測は、レーダー設計の em192(サイズ 26,896、κ∞(A) が 10 の 6 乗)で 5.70 秒から 2.05 秒へ 2.8 倍、nd12k(36,000、κ∞(A) が 4.3 かける 10 の 2 乗)で 5.36 秒から 1.31 秒へ 4.1 倍である (Source: [[@2018__SC__Harnessing GPU Tensor Cores for Fast FP16 Arithmetic to Speed up Mixed-Precision Iterative Refinement Solvers]])。 ただし分散環境とマルチ GPU への外挿は期待にとどまり実測ではない (Source: [[@2018__SC__Harnessing GPU Tensor Cores for Fast FP16 Arithmetic to Speed up Mixed-Precision Iterative Refinement Solvers]])。 この技術は第 14 章以降の現代機で HPL-MxP という形で現れ、第 20 章で論じるエクサスケールの定義問題の火種にもなる。 ### 7.5 ドメイン固有アーキテクチャという答え Dennard スケーリングとムーアの法則の終焉に対する回答として、Hennessy(Stanford University、Alphabet)と Patterson(UC Berkeley、Google)はドメイン固有アーキテクチャ(DSA)を挙げた。 DSA が効率を得る根拠は 5 つの指針に整理される。 専用メモリでデータ移動距離を最小化する。 アウトオブオーダー実行などの高度なマイクロアーキテクチャ最適化を捨て、その資源を演算器とメモリへ再投資する。 ドメインに合った単純な並列性の形態を選ぶ。 データ幅と型を最小限にする。 ドメイン固有言語でポーティングの負担を下げる (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]])。 根拠となるエネルギーの非対称は繰り返し示される。 90nm プロセスで RISC 命令 1 回は 125 ピコジュール、8 ビット加算は 0.2 から 0.5 ピコジュールであり、数百倍の開きがある (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]])。 32 ビットの DRAM アクセスは 8 ビット加算の 20,000 倍のエネルギーを要し、SRAM は DRAM の 125 倍エネルギー効率が良い (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]])。 2-way セットアソシアティブキャッシュは同等のスクラッチパッドメモリの 2.5 倍のエネルギーを要する (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]])。 Google TPU は 65,536 個の 8 ビット積和演算器を 256 かける 256 のシストリックアレイに並べ、24 MiB の Unified Buffer を持つ。 6 種の DNN ベンチマークの加重平均で Haswell CPU 比 29.2 倍、K80 GPU 比 15.3 倍のスループット、電力あたり性能ではそれぞれ 34 倍と 16 倍である (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]])。 現行の AI アクセラレータも同じ原理の異なる実装として整理できる。 NVIDIA の Tensor Core は Volta の warp 同期発行から Hopper の warp-group 非同期発行、Blackwell の単一スレッド発行と専用 TMEM への着地へと、発行側の負担を減らし続けてきた。 Google TPU はプログラマブルな SM を持たず MXU というシストリックアレイの単一プリミティブに絞り、コンパイラが全サイクルと全バイトの配置を事前に決定する。 Cerebras と Groq はともに HBM を持たず SRAM だけという同一の制約から、前者は到着駆動のデータフロー、後者は時計駆動の決定論的スケジュールという正反対の実行モデルへ分岐した (Source: [[AI Chip Architectures]])。 > [!warning] 同じ数値が引用されるたびに評価条件が失われる > TPU v1 の性能は、教科書では「6 種の DNN ベンチマークの加重平均で Haswell 比 29.2 倍、K80 比 15.3 倍」と条件つきで書かれる (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]])。 > Turing 賞講演版では「汎用 CPU 比 29 倍、エネルギー効率 80 倍超」と加重条件が省略される (Source: [[@2019__CACM__A New Golden Age for Computer Architecture]])。 > さらに後続のウェブ記事では「CPU 比 29 倍のスループット、80 倍の電力効率」という要約値だけが再引用され、元の測定条件は残っていない (Source: [[AI Chip Architectures]])。 > 同一の一次データであっても、引用の連鎖を 1 段たどるごとに条件が減る。 > 本書の数値を他所へ引くときは、この付録的な注意を併せて運んでほしい。 著者自身が認める指標の限界もある。 IPS(毎秒命令数)という単一指標はワークロードの複雑さの逆数にすぎず誤解を招くため、標準化されたベンチマークスイートが必要だと明記されている。 実際 TPU 上で IPS は MLP1(4 層)と CNN1(89 層)の間で 75 倍ばらつく (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]])。 --- ## 第 8 章　メモリ階層とメモリウォール ### 8.1 1995 年の警告 1995 年、バージニア大学の Wulf と McKee は、マイクロプロセッサ速度と DRAM 速度の向上率の指数差が指数的に拡大するため、完全なキャッシュを仮定しても平均メモリアクセス時間が支配的になる壁が 10 年以内に来ると論じた (Source: [[@1995__SIGARCH CAN__Hitting the memory wall - implications of the obvious]])。 論証は単純なモデルによる。 平均メモリアクセス時間をヒット率かけるキャッシュ時間と、ミス率かけるメモリ時間の和とし、キャッシュ速度はプロセッサ速度に追従し、キャッシュは完全(競合ミスと容量ミスがなく強制ミスのみ)と仮定する。 命令の 20 パーセントから 40 パーセントがメモリを参照するため、下限の 20 パーセントを採れば平均 5 命令に 1 回参照する。 したがって平均メモリアクセス時間が 5 命令時間を超えたところが壁であり、そこでは性能がメモリ速度だけで決まる。 DRAM の向上率を年 7 パーセント、プロセッサ性能の向上率を年 80 パーセントと仮定すると、1 アクセスあたりの平均サイクル数は 2000 年に 1.52、2005 年に 8.25、2010 年に 98.8 になる(強制ミス率 1 パーセント以下、次階層の速度が現状でキャッシュの 4 倍遅いという仮定)。 キャッシュの拡大とプリフェッチは帯域かレイテンシを一回限り改善するだけで、壁の到来を遅らせるにとどまり根本は変わらない、というのが著者らの主張である。 その著者ら自身が「予測はおそらく誤りになる」とも明言しており、過去 30 年にわたり性能向上の停止予測がすべて外れたことを根拠に挙げている (Source: [[@1995__SIGARCH CAN__Hitting the memory wall - implications of the obvious]])。 ![[_attachments/Hitting-the-memory-wall/fig03-avg-access-cost.png]] **図8-1**:1 アクセスあたりの平均サイクル数の年次推移を、キャッシュヒット率 90.0 パーセント、99.0 パーセント、99.8 パーセントの 3 条件で外挿したもの。本文が挙げた 2000 年 1.52、2005 年 8.25、2010 年 98.8 という数値は、この指数的な立ち上がりの上を動く。ヒット率を上げても曲線が右へ平行移動するだけで形が変わらないことが、本文の「キャッシュの拡大は壁の到来を遅らせるにとどまる」という主張の根拠になっている。 (Source: [[@1995__SIGARCH CAN__Hitting the memory wall - implications of the obvious]], 図 3) 30 年後の評価としては、壁は到来したが、到来の仕方が予測と異なる。 2019 年の教科書は、メモリウォールが完全な解決策を得ておらず、多階層キャッシュと積極的なプリフェッチ、ILP と TLP によるレイテンシ隠蔽の組み合わせで先送りされているにすぎないと明記している (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 2 Memory Hierarchy Design]])。 ### 8.2 キャッシュ最適化の到達点と非対称 キャッシュ最適化の技法は、ヒット時間、帯域幅、ミスペナルティ、ミス率、消費電力という 5 指標で整理される。 高度な技法の大半は単一指標だけを改善するもので、複雑度が上がるほどこの単一指標集中の傾向が強まる (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 2 Memory Hierarchy Design]])。 HBM を L4 キャッシュとして使うときのタグ配置が、この非対称をよく表す。 alloy cache 方式はタグとデータを直接マップで融合しヒット時間を半分以下に短縮する一方、ミス率を悪化させる。 平均ヒットレイテンシは alloy cache が 43 クロック、SRAM タグが 67 クロック、L-H 方式が 107 クロックである (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 2 Memory Hierarchy Design]])。 プリフェッチの副作用も実測されている。 Intel Core i7 6700 では、L1 ミス率がプリフェッチ込みで最大 41 パーセント、デマンドアクセスのみで最大 11 パーセントであり、平均でプリフェッチ込みはデマンド専用の 2.8 倍である。 L2 ミスの 75 パーセントがプリフェッチ由来である (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 2 Memory Hierarchy Design]])。 レイテンシを隠すために帯域を先に消費するという交換が、数値として見える。 ### 8.3 DARPA 報告が見たメモリの壁 2008 年の DARPA ExaScale Computing Study は、メモリの壁を電力の壁と並ぶ 2 大停滞要因として位置づけ、CPU と主記憶のサイクル時間の乖離を約 1000 倍と見積もった (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 3 Background]])。 第 5 章はこれをフォンノイマンボトルネック(Backus の 1977 年チューリング賞講演に由来)と呼び、ムーアの法則が進むほど主記憶までの相対距離(サイクル数)が伸びる現象を赤方偏移と名づけた (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 5 Exascale Application Characteristics]])。 実機比較が壁の深刻さを示す。 当時最速の Blue Gene/L は演算が 4 フロップス毎サイクルで進む一方、主記憶からの取得に約 100 サイクルを要し、メモリ集約的なコードでは時間の 99 パーセントをデータ移動に費やしうる。 比較対象の Cray XMP は約 50 パーセントである (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 5 Exascale Application Characteristics]])。 ベクトル機からスカラー超並列機への移行が、データ移動比率を倍増させたことになる。 アプリケーション側の感度も測られた。 気象モデル WRF の Large 構成は 256 CPU の DataStar でほぼ均衡しており、演算クロックを 2 倍にしても、L1 と L2 と主記憶の遅延を半減しても、予測される速度向上はいずれも約 14 パーセントにとどまる(畳み込み法による予測、基準系は 2048 プロセッサの IBM Power4 機)。 フロップスとメモリを 1024 倍にしても WRF は約 180 倍にしかならず、AVUS はフロップスを 3 桁上げてもメモリ系が伴わなければ 50 倍未満である(通信オーバーヘッド一定と仮定した性能応答曲面モデル)。 HPL だけはピークで約 900 倍まで伸びるが、著者らはこれを「病的に無意味」と評している (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 5 Exascale Application Characteristics]])。 並列度と局所性の関係が、この章の核心である。 並列度を上げると局所性が下がり効果が相殺される (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 5 Exascale Application Characteristics]])。 局所性は 0 から 1 のスコアで測られ、HPL が時間局所性でほぼ最大、STREAM が空間局所性でほぼ最大かつ再利用なし、small RA が局所性ほぼなしという 3 点の間に実アプリが分布する (Source: [[局所性]])。 DRAM の電力を支配するのはセルではなくインタフェースである。 行全体を読み出すオーバーフェッチが効くため、1 EB/s の主記憶帯域は DDR3 の実績(600 ミリワット毎 GB/s)で外挿すると 600 メガワットを超える。 セルだけなら 200 キロワット(ビット線込みで 800 キロワット)だが、行 8K ビットという現行構成では 51 メガワットを超える (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]])。 積極設計ストローマンの電力配分でも、メモリがシステム電力の 31 パーセントを占めた (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]])。 ### 8.4 HBM という解と、そのコスト 現代機が採った解は HBM である。 複数の DRAM ダイを垂直に積層し、シリコンインターポーザ上で AI チップのロジックプロセッサの隣に配置する。 TSV がダイを貫く垂直チャネルとしてデータを運び、最下部のベースダイがメモリとプロセッサの間の転送を制御する。 インターフェースは 1024 ビット幅(HBM4 は 2048 ビット幅)であり、GDDR のような狭チャネル高速駆動ではなく、広チャネルを比較的低速で並列駆動することで高帯域幅と低消費電力を両立する (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 帯域の伸びは大きい。 2013 年登場の第 1 世代はスタックあたり 128 GB/s と 4GB、2025 年に標準化された HBM4 はスタックあたり最大 2 TB/s と 64GB であり、それぞれ約 16 倍である (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 コスト構造が制約になる。 192GB の HBM3E は推定 2900 ドルで、NVIDIA B200 の総製造費の約 45 パーセントに相当し、プロセッサ製造費の約 3 倍にあたる(業界推計)。 HBM の前工程と後工程は DDR5 より一般に 20 パーセントから 30 パーセント低い歩留まりであり、DRAM ダイは TSV の追加により従来 DRAM より大きく密度が低いため、DDR5 と同容量を作るのに約 3 倍のウェハが必要になる(いずれも業界推計) (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 供給の集中も設計の制約として無視できない。 2026 年時点で先進 HBM を世界的規模で生産できるのは SK Hynix、Samsung、Micron の 3 社に限られる。 2025 年第 4 四半期の売上高ベース市場シェアは SK Hynix 57 パーセント、Samsung 22 パーセント、Micron 21 パーセントであり、2026 年末の HBM ウェハ容量予測は韓国 78 パーセント、台湾 10 パーセント、日本 8 パーセント、中国 4 パーセントである (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 著者ら自身が、市場シェアと容量、製造コストの多くが企業発表や業界推計に依存し 2026 年値には予測が含まれること、HBM の代替となる DDR や SRAM、3D メモリとの性能と電力と総保有コストを同一条件で実測比較していないことを明記している (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 ### 8.5 壁はどちらにあるのか メモリと演算のどちらが先に飽和するかについて、2 本のソースが逆方向の観察を示している。 > [!contradiction] メモリの壁か、命令の壁か > UC Berkeley の Gholami らは、過去 20 年でサーバハードウェアのピーク FLOPS が 2 年ごとに 3.0 倍で伸びたのに対し、DRAM 帯域幅は 1.6 倍、インターコネクト帯域幅は 1.4 倍しか伸びていないことを回帰分析で示し、AI では計算よりメモリが主要なボトルネックになりつつあると論じる。 > 20 年でピーク FLOPS は 60,000 倍、DRAM 帯域幅は 100 倍、インターコネクト帯域幅は 30 倍である (Source: [[@2024__IEEE Micro__AI and Memory Wall]])。 ![[_attachments/Gholami-et-al.-2024---AI-and-Memory-Wall/fig01-scaling-bandwidth.png]] **図8-2**:1996 年から 2023 年までのピーク FLOPS、DRAM 帯域幅、インターコネクト帯域幅の正規化した伸び。3 本の回帰線の傾きが分かれており、上の黒が 20 年で 60,000 倍、中央の緑が 100 倍、下の青が 30 倍にあたる。本文が引いた 2 年ごと 3.0 倍、1.6 倍、1.4 倍という成長率はこの 3 本の傾きである。 (Source: [[@2024__IEEE Micro__AI and Memory Wall]], 図 1) > 一方 ETH Zürich の Hepkema らは、L4 から GH200 へメモリ帯域幅が 13.4 倍(300 GB/s から 4,022 GB/s)に増えても TPC-H の性能改善が 5.2 倍にとどまることを実測し、命令スループットの増加が 2.5 倍(413 から 1,037 G inst./s)しかないため、帯域幅を十分に上げると cuDF のカーネルがメモリバウンドから命令スループットバウンドへ転じると論じる。 > L4 ではカーネル時間の 74.1 パーセントがメモリバウンドだが、GH200 では 77.5 パーセントが演算バウンドになる (Source: [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]])。 > 両者は分析対象が異なる。 > 前者はハードウェア世代を横断する FLOPS 対 DRAM 帯域幅の長期トレンド、後者は同世代内 2 機種のメモリ帯域幅対命令スループットである。 > 単純な矛盾ではないが、「どちらの資源が先に律速するか」という同じ問いに逆の答えを与えている。 > 本書としては、律速の所在がハードウェア世代とワークロードの組み合わせで移動する量であり、単一の固定した答えを持たないと整理する。 Transformer の構造が演算強度を決めるという機構の説明は、メモリの壁の側から与えられている。 エンコーダ型(BERT)は行列と行列の演算を中心とし全トークンを並列処理するため演算強度が高い。 デコーダ型(GPT)は自己回帰的に 1 トークンずつ生成する行列とベクトルの演算を繰り返すためメモリ操作数が桁違いに多く演算強度が低い。 演算強度が低いとキャッシュに収まらない DRAM アクセスがレイテンシを支配し、演算器の速度によらず DRAM 帯域幅で処理時間が決まる (Source: [[@2024__IEEE Micro__AI and Memory Wall]])。 著者ら自身は、デコーダの大バッチや長文書要約など行列と行列の演算が支配的な条件では結論の一般化範囲が限られることを明記している (Source: [[@2024__IEEE Micro__AI and Memory Wall]])。 命令の壁の側からは、レイテンシが完全に隠蔽されピーク IPC が達成されても GH200 上ではカーネル時間の 53 パーセントが依然として命令スループットバウンドとして残るため、メモリアクセスあたりの命令数そのものを削減する必要があるという処方が示される (Source: [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]])。 こちらも、分析が cuDF という単一の演算子ライブラリと TPC-H という単一ベンチマークに限られ、他の GPU データベースシステムへの一般化は示されていない (Source: [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]])。 --- ## 第 9 章　結合網のトポロジ ### 9.1 トポロジの設計軸 相互接続網は、接続する装置の数と距離のスケールに応じて OCN、SAN、LAN、WAN の 4 領域に分類される。 どの領域でも、トポロジ、経路制御、調停、スイッチングの 4 機能が独立した設計軸として性能とデッドロック自由性を決める (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]])。 コストのスケーリング則が選択肢を絞る。 クロスバーは N の 2 乗個のクロスポイントを要するのに対し、Omega 網などの多段相互接続網は N/2 かける log2(N) 個のスイッチで済む。 Clos 網とファットツリーは非閉塞性を保ちながらクロスバーの N の 2 乗というコストを N log N 規模へ削減する間接網の主要解であり、Beneš 網は Clos の中間段スイッチを再帰的に 2 かける 2 まで分割した極限形である (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]])。 この Clos とファットツリーの系譜は、ウェアハウススケール計算機の網の階層でも実装として現れる (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 6 Warehouse-Scale Computers to Exploit Request-Level and Data-Level Parallelism]])。 デッドロックは有限資源への巡回待ちから生じるため、資源に全順序を課す仮想チャネルによって、経路の適応性を保ったまま回避できる。 実測では、4K ノードの 3 次元トーラスで適応経路制御と 4 仮想チャネルの効率因子が 86 パーセント、決定的経路制御と 2 仮想チャネルで 74 パーセントである (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]])。 なお二分帯域幅という指標については、教科書自身が注意を促している。 性能指標としては有用だが、チップやボード、バックプレーンのピン数といった実装制約を反映したコスト制約としては実務上あまり機能しない (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]])。 ### 9.2 Dragonfly という階層化 2008 年、Kim(Northwestern University)、Dally(Stanford University)、Scott(Cray Inc.)、Abts(Google)は、ルータのグループを 1 つの仮想ルータとして扱う階層ネットワーク Dragonfly を提案した。 3 層(ルータ層、グループ層、システム層)からなり、最小経路では各パケットが通過するグローバルチャネルを最大 1 本に抑えるのが核心である (Source: [[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]], [[Dragonflyトポロジ]])。 設計は能動光ケーブルの経済特性から導かれている。 グローバルチャネルを過剰に投資せず、ローカルチャネルと端末チャネルを過剰に投資する構成が推奨される。 ラジックス 64 のルータで直径 3 ホップのまま 256K ノード超に到達できる (Source: [[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]])。 コスト削減の効果は規模に強く依存する。 16K ノード以上でフラット化バタフライ比約 20 パーセント、折り畳み Clos 比約 52 パーセント、3 次元トーラス比では 1K ノードで約 62 パーセントだが 8K 超で再び拡大する (Source: [[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]])。 経路制御が伴わなければ利点は限定的である。 最小経路(MIN)、Valiant(無作為な中間グループ経由)、両者をキュー長とホップ数で切り替える UGAL の 3 種のうち、Valiant は最悪ケースのトラフィックを約 50 パーセントのスループットまで均衡化するが、均一ランダムでは帯域が 2 倍になるためスループットが半減する (Source: [[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]])。 UGAL には間接性の問題がある。 自グループ外のグローバルチャネルの状況を直接観測できないためである。 著者らは 2 つの解を示した。 同一出力ポートを共有するときのみ仮想チャネルを最小経路と非最小経路で分離する UGAL-LVCH(スループット問題の解消)と、クレジット往復レイテンシの偏差で上流へのクレジット返信を遅延させ輻輳検知を早める UGAL-LCR(遅延問題の解消)である。 UGAL-LCR は UGAL-L に比べ、バッファ 16 フリットで最大 35 パーセント、バッファ 256 フリットで 20 倍以上の遅延改善を示した(基準構成 1K ノード、サイクル精度シミュレータ) (Source: [[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]])。 評価はシミュレーションであり実機実測ではない (Source: [[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]])。 翌年の IEEE Micro 版は原典の 3 ページ短縮版であり、独自の評価実験を含まないことが本文で明記されている。 数式、シミュレーション設定、詳細な評価グラフは原典を参照するよう促している (Source: [[@2009__IEEE-Micro__Cost-Efficient Dragonfly Topology for Large-Scale Systems]])。 ### 9.3 Slingshot が示した輻輳制御の効き Dragonfly の理論が実機でどう働くかを、ETH Zurich の De Sensi と Di Girolamo、HPE の McMahon と Roweth、ETH Zurich の Hoefler が測定した。 HPE Slingshot の Rosetta スイッチは 64 ポートかける 200 Gb/s、32 タイル(4 行かける 8 列)からなり、行バスとタイル内クロスバーによってパケットは高々 2 ホップで抜ける。 仮想出力キューで経路を先に決め出力側の許可後に転送することでヘッドオブラインブロッキングを回避する。 トポロジは既定で Dragonfly(グループ内は銅で全結合、グループ間は光で全結合、直径 3 ホップ)である (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 ![[_attachments/An-In-Depth-Analysis-of-the-Slingshot-Interconnect/fig3-topology.png]] **図9-1**:Slingshot の Dragonfly の構成例。1 グループ内で 32 スイッチが 31 リンクずつで全結合し、各スイッチが 16 リンクでノードを、17 リンクでグローバル側を受け持つ。本文が第 9.2 節で述べた「グループを仮想ルータとして扱い、最小経路ではグローバルチャネルを最大 1 本しか通らない」という構造が、この 3 層の入れ子に対応する。 (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]], 図 3) 設計の核心は輻輳の分類にある。 エンドポイント輻輳は全経路に効くため適応経路制御では迂回できないのに対し、中間輻輳は迂回できる。 そこで全エンドポイント対の飛行中パケットをハードウェアで追跡し、加害側だけに背圧をかける (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 効果は桁で現れた。 線形配置 512 ノード、1 プロセス毎ノードという条件で、輻輳影響の最大値は前世代 Aries が 93 倍、Slingshot が 1.3 倍である。 加害側を 24 プロセス毎ノードに増やすと Aries のランダム配置が 424 倍、Slingshot が最大 2.6 倍となり、比は約 200 倍になる。 1,024 ノード全体では Slingshot の最悪値が 3.55 倍(LAMMPS、incast 75 パーセント)である (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 静穏時のスイッチ遅延は平均と中央値がともに 350 ナノ秒(300 から 400 ナノ秒の分布)、1,024 ノードの二分割帯域は理論ピーク 6.4 Tb/s で、MPI_Alltoall は理論 12.8 Tb/s の 90 パーセント超に達する (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 トラフィッククラスは輻輳制御と直交する資源として働く。 8 バイトの MPI_Allreduce と 256 KiB の MPI_Alltoall を同居させた実験で、トラフィッククラスの分離により輻輳影響が 2.85 から 1.15 へ下がった(64 ノード、16 プロセス毎ノード、インターリーブ配置) (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 著者らは比較の限界も明記している。 比較相手が Aries のみでシステム規模と CPU が異なる。 200 Gb/s の NIC がなく 100 Gb/s の ConnectX-5 で測定しているため Slingshot 固有の Ethernet 拡張の効果は測れていない。 全システムを専有しての測定であり、本番運用での他ジョブ混在状況の実測ではない。 中サイズメッセージのバーストでは輻輳制御の反応遅れにより影響が 1.21 まで出る (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 ### 9.4 実装差が生む性能安定性の開き 同じ Dragonfly 系でも、輻輳制御の実装次第で安定性が大きく変わる。 Sapienza University of Rome の De Sensi ら 14 名は、Alps、Leonardo、LUMI の 3 台で最大 4,096 GPU 規模の GPU 間通信を比較した。 Leonardo は InfiniBand HDR の Dragonfly+ を採るが、全トラフィックが既定で単一のサービスレベルに集中するためネットワークノイズが発生しやすく、異なる Dragonfly グループ間でレイテンシに最大 132 マイクロ秒の外れ値が出て goodput が平均 17 パーセント低下する(395 から 328 Gb/s)。 Slingshot を採る Alps と LUMI では変動が小さい(レイテンシ 30 パーセント、goodput 1 パーセント以下) (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 1,024 GPU 規模では、ネットワークノイズが alltoall を 20 パーセント、allreduce を 50 パーセント低下させた (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 もう 1 つの発見は、既定設定が最適から程遠いことである。 `NCCL_IGNORE_CPU_AFFINITY=1` で Alps と LUMI の alltoall が最大 1.6 倍、allreduce が最大 6 倍改善し、`NCCL_NET_GDR_LEVEL=3` で alltoall が 2 倍、allreduce が 3 倍改善した。 LUMI では `NCCL_NCHANNELS_PER_PEER=32` でノード内点対点が 3.5 倍改善する (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 著者らは、Alps が評価当時は早期アクセス段階であったこと、Leonardo の最大 1,024 GPU という制限がシステム側の制約であること、NCCL と RCCL の alltoall が 512 GPU 以上でスタックするバグが残存すること、サービスレベルの切り替えが「他ジョブが同じレベルを使わない」という仮定に依存する恒久的でない対策であることを明記している (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 ### 9.5 Ethernet は追いついたのか 専用インターコネクトに対する Ethernet の位置づけは、メッセージサイズによって変わる。 University of Trento の Pichetti、Sapienza University of Rome の De Sensi、Huawei の Sivalingam らは、100GE と 100Gbps EDR InfiniBand を同一クラスタで比較し、32 KiB 以上の大きなメッセージでは帯域差が 4 パーセント未満に収まる一方、512 バイト未満の小さなメッセージでは InfiniBand が最大 1.6 倍優位であることを示した。 差の原因はヘッダのオーバーヘッドである (Source: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])。 インキャストでは全メッセージサイズにわたり差が 20 パーセント以内、32 KiB 以上では 1 パーセント以内に収まり、全インスタンスで理論ピークの 96 パーセント以上を達成した。 AllToAll では 16 MiB メッセージまでで理論ピークの 66 パーセント、128 MiB では Ethernet が 58 パーセント、InfiniBand が 81 パーセントと論文内で最大の差が出る。 レイテンシは InfiniBand が Ethernet 比で約 1.4 倍良い (Source: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])。 Ethernet 側が必要とした機構も記録されている。 Priority-based Flow Control による RoCEv2 のパケットロス防止、PFC のデッドロック防止、トラフィック特性に基づくロスレスキューの ECN 閾値の動的調整、適応経路制御、VXLAN オーバーレイへの ECN 適用である (Source: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])。 専用網が最初から持っていた性質を、Ethernet は追加機構で獲得した。 著者らは、AllReduce で双方に現れた約 20 Gbit/s という予期しない上限の根本原因が特定できていないこと(スイッチレベルのカウンタに異常がなく、ホスト固有の問題と推定するにとどまる)、GPU 間通信のシナリオでの評価が今後の課題であることを明記している (Source: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])。 ### 9.6 メッセージサイズという共通の分水嶺 本章と次章を横断して、同じ構造が 3 つの独立した文脈で現れる。 Ethernet と InfiniBand の差は 32 KiB を境に収束し (Source: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])、SHArP のホストベース実装に対する優位は 2048 バイトまで拡大し続け (Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]])、帯域最適な全還元アルゴリズムは 256KB 超でバタフライ型を上回る (Source: [[@2009__JPDC__Bandwidth Optimal All-reduce Algorithms for Clusters of Workstations]])。 いずれも「小メッセージでは起動遅延とオーバーヘッドが支配的、大メッセージでは帯域とネットワーク構造が支配的」という同じ閾値構造を持つ。 ただし閾値の具体値(2KB、2048 バイト、32 KiB、256KB)はシステムとアルゴリズムとネットワーク世代によって大きく異なり、単純に比較したり一般化したりはできない。 --- ## 第 10 章　通信ソフトウェアと網内集約 ### 10.1 全還元の下界 集合通信の設計は、まず理論的な下界から出発できる。 Florida State University の Patarasuk と Yuan は、全還元の通信量には 1 要素あたり少なくとも 2 かける (N-1) 個の部分結果という下界があり、縮約散布と全収集を木上の競合のない論理リングで実行すれば、木接続だけで帯域最適(下界に一致しネットワーク競合なし)になることを示した (Source: [[@2009__JPDC__Bandwidth Optimal All-reduce Algorithms for Clusters of Workstations]])。 手法そのものは 3 つの既存部品の組み合わせであり、新規性は組み合わせが帯域最適になるという証明にある。 データを N 個のセグメントに分け、N-1 回の反復でリング上を巡回させながら縮約する。 SMP やマルチコアのクラスタでは、連続ランクを同一ノードへ割り当てる既定配置なら論理リングが競合なしになる。 作業メモリはバタフライ型より小さい (Source: [[@2009__JPDC__Bandwidth Optimal All-reduce Algorithms for Clusters of Workstations]])。 バタフライ型(再帰的半減の縮約散布と再帰的倍化の全収集)は遅延項と帯域項の双方で最適だが、SMP とマルチコアのクラスタではリンク競合を起こす。 実測での損益分岐点は、Teragrid(Myrinet、デュアル 1.5GHz Itanium 2、64 ノード 128 プロセッサ)で 256KB 超、Gigabit Ethernet の 32 ノードクラスタでも 256KB 超である。 前者を N=128 で割ると約 2KB、後者を N=32 で割ると 8KB になり、Gigabit Ethernet の起動遅延の大きさが閾値を押し上げている (Source: [[@2009__JPDC__Bandwidth Optimal All-reduce Algorithms for Clusters of Workstations]])。 著者らは限界も明示する。 提案手法は帯域項のみ最適で遅延項は最適でなく、通信ラウンド数が N のオーダーになる。 縮約結果は要素ごとに括弧づけが異なるため丸め誤差の再現性に問題が出うる。 1 ノード 1 ポートという仮定を置いている。 InfiniBand クラスタ Draco の 512KB と 1MB でわずかに遅くなる理由は、メモリ参照とネットワーク競合の相互作用という推測にとどまる (Source: [[@2009__JPDC__Bandwidth Optimal All-reduce Algorithms for Clusters of Workstations]])。 ### 10.2 経路上での縮約 Mellanox Technologies の Graham らは、縮約をホストではなくネットワーク経路上のスイッチで行う SHArP を、InfiniBand SwitchIB-2 の ASIC に実装した。 集約木に配置される論理構成要素が、データを葉から根へ縮約しながら伝搬させる。 木は物理トポロジと独立した論理木であり、ファットツリー、Dragonfly+、ハイパーキューブのいずれにも重畳できる (Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]])。 浮動小数点の非結合則に対しては、全オペランドの到着を待ってから固定順序で縮約することで決定的な演算順序を保証する (Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]])。 第 10.1 節で見た丸め誤差の再現性問題に対する、ハードウェア側からの答えになっている。 効果は 128 ホストの実測で示された。 ホストベース実装との比較(1 プロセス毎ホスト)では、0 バイトの Allreduce が SHArP ベースで 2.91 マイクロ秒、ホストベースで 5.25 マイクロ秒、MVAPICH-2 のホストベースで 11.47 マイクロ秒である。 パイプライン化により 2048 バイトでほぼ 4 倍、4096 バイトで 3.24 倍の高速化を得た。 実アプリケーションでは、OpenFOAM の icoFoam(100 万セル、Lid Driven Cavity Flow)が 1792 プロセスで 180 秒から 116 秒へ、最大 52.6 パーセント改善している (Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]])。 制約も明示されている。 スイッチがハードウェアで縮約できるペイロードは最大 256 バイトに限られ、それを超えるサイズはソフトウェアレベルの断片化とパイプライン化で対応する。 木のトポロジ割り当ての最適化、分散グループ生成の詳細アルゴリズム、資源割り当て手法は論文の対象外である。 デッドロック回避には端から端まで SHArP の資源可用性を確保する必要があり、確保されない場合は複数の縮約操作が同一の集約ノード資源を奪い合って誰も完了できない状況が生じうると論文自身が警告するが、具体的な保証機構は示されていない (Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]])。 処理を末端に集中させず経路上の中間ノードへ分散させるという原理は、第 9 章の Dragonfly がグループを仮想ルータとして扱う発想と同型である (Source: [[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]], [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]])。 この系譜は後に NVSHARP や Multimem へ引き継がれる (Source: [[集合通信]])。 ### 10.3 抽象化層の設計 Oak Ridge National Laboratory の Shamis、Mellanox の Gorentla Venkata らは、複数の並列プログラミングモデルと異種ハードウェアを対象に通信 API とプロトコルと実装を統合する枠組みとして UCX を提案した。 3 層からなる。 プラットフォーム抽象化とメモリプールを担う UCS、ハードウェアとドライバの差を抽象化する低水準 API の UCT、初期化とトランスポート選択とメッセージ分割とマルチレール通信を担う高水準プロトコル層の UCP である (Source: [[@2015__HOTI__UCX - An Open Source Framework for HPC Network APIs and Beyond]])。 設計判断は、単一の万能インタフェースを目指さないことにある。 複数の抽象度の部品を提供することで、異種メモリ階層やアクセラレータ、ハイブリッドなプログラミングモデルに対応しつつ、UCT が低水準ドライバへの直接に近いアクセスを保つ (Source: [[@2015__HOTI__UCX - An Open Source Framework for HPC Network APIs and Beyond]])。 実測では、1 バイトの short PUT のレイテンシが Accelerated Verbs で 0.89 マイクロ秒、通常 Verbs で 0.91 マイクロ秒である(2 台の HP ProLiant DL380p Gen8、Intel Xeon E5-2697 2.7GHz、Mellanox SX6036 スイッチ、単一ポート Connect-IB FDR HCA)。 zcopy の PUT と GET は 6,138.5 MB/s に達し、著者らによれば単一 FDR InfiniBand ポートで実用上到達できるピーク帯域である。 short と bcopy の PUT のメッセージレートは Accelerated Verbs で通常 Verbs の 2 倍超、単一 CPU コアで毎秒 1,400 万操作である (Source: [[@2015__HOTI__UCX - An Open Source Framework for HPC Network APIs and Beyond]])。 著者ら自身が、これは UCT 層の予備的な機能評価であり最終的なオーバーヘッドを完全には表していないこと、上位の MPI や OpenSHMEM の実装と実アプリケーションは未評価であることを明記している (Source: [[@2015__HOTI__UCX - An Open Source Framework for HPC Network APIs and Beyond]])。 ### 10.4 GPU 中心通信という新しい軸 Koç University の Unat らは、GPU 中心通信を、CPU の介在を減らし GPU に通信タスクのより大きな自律性を与える方向として体系化した。 ノード内通信は、API の呼び出し元がホストかデバイスかという軸と、データパスがホスト経由か直接かという軸で 4 型に分かれる。 ノード間通信はさらに、誰が NIC 上でパケットを構築するか、誰が NIC のドアベルを鳴らすかという 2 軸を加えた 4 軸で、ホスト主体から GPU 主体へ向かう 5 型に分かれる。 GPU 側へ構成要素が移るにつれてデータコピーの段数が減り、GPU の自律性が増す (Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]])。 この整理から、根本的な制約も 1 つ明らかになる。 GPUDirect RDMA はカーネル境界を越えた GPU と NIC のメモリ一貫性を保証しないため、パーシステントカーネルとの併用に原理的な限界がある (Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]])。 本稿はサーベイであり独自実験を行わない。 著者ら自身が、性能比較が既存文献の引用にとどまり比較条件が論文間で統一されていないこと、Intel 系の記述が公開情報への依存度が高いこと、マルチ GPU コンテキストでのレースハザード検知ツールの欠如を指摘する一方その解決の具体的設計方針は提示しないことを明記している (Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]])。 ### 10.5 通信ライブラリの優劣の逆転 通信ライブラリの優劣は、通信のスコープ(ノード内かノード間か)、操作の種別(点対点か集合通信か)、メッセージサイズの 3 軸に応じて系統的に逆転する。 Alps、Leonardo、LUMI の比較では、ノード間の点対点で MPI が *CCL 系を小転送で最大 1 桁、大転送で最大 3 倍上回る一方、ノード内の集合通信では *CCL が優位になる (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 MI300A ノード内の測定でも同じ非対称が出る。 128 バイト未満の ping-pong では MPI の CPU ステージングが 1.9 マイクロ秒、GPU 直接が 4.8 マイクロ秒、RCCL が最小 20 マイクロ秒と MPI の約 10 倍だが、8KB 超では RCCL の帯域が GPU 直接の MPI と同等の最大 88 GB/s に達し、4KB 超の集団通信では RCCL が MPI の 5 倍から 38 倍低遅延になる (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 UCX の実測が示すとおり、低水準の通信プリミティブ自体は基盤ドライバとほぼ同等の性能に達している (Source: [[@2015__HOTI__UCX - An Open Source Framework for HPC Network APIs and Beyond]])。 性能差が生じるのはその上に積まれた層、すなわち集合通信アルゴリズム、トポロジ認識、カーネル起動のオーバーヘッドである。 ### 10.6 マイクロベンチマークと実アプリケーションの乖離 本章と第 9 章を通じて、方法論上の注意が 2 つの独立した文脈から提起されている。 Pacific Northwest National Laboratory の Li らは、NVLink がマイクロベンチマークでは通信効率を大幅に改善するにもかかわらず、アプリケーション全体の速度向上にほとんど反映されないことを報告した。 理由は、評価候補とした 50 超のマルチ GPU アプリケーションの大半が CPU をマスター、GPU をスレーブとするプログラミングモデルに基づき、GPU 間通信を前提としていないことにある (Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]])。 Slingshot の測定では別の機構から同じ注意が出る。 Aries 上で通信マイクロベンチマークの輻輳影響が最大 93 倍に達する一方、実アプリケーション(LAMMPS)では 17 倍にとどまる。 計算フェーズが通信遅延の影響を希釈するためである (Source: [[@2020__SC__An In-Depth Analysis of the Slingshot Interconnect]])。 機構は異なるが、マイクロベンチマークの改善幅をそのままアプリケーション性能の改善幅として外挿してはならないという帰結は共通する。 なお GPU インターコネクトの評価からは、集合通信の帯域スケーリングの向きが下位トポロジの形にそのまま反転して現れるという観察も得られている。 PCIe の集団通信帯域は GPU 数の増加につれて低下する(木構造トポロジのバス競合)のに対し、NVLink の帯域は GPU 数の増加につれて増加する(ハイパーキューブメッシュでリンク数が増える) (Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]])。 著者らは、評価対象が NVIDIA 製に限られること、PCIe の anti-locality 効果の根本原因がベンダー非公開の内部実装のため推測にとどまることを明記している (Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]])。 --- ## 第 11 章　ストレージと入出力 ### 11.1 並列ファイルシステムの設計原則 並列ファイルシステムは、データとメタデータの分離、オブジェクトベースストレージ、分散ロック管理、ストライピングという共通設計原則を持つ (Source: [[並列ファイルシステム]])。 第 4 章で見た Lustre の初期設計が、この原則をほぼそのまま体現している。 注目すべきは、設計の構想と実装の到達に長い時間差があったことである。 2001 年から 2005 年の設計文書ではメタデータのライトバックキャッシュとクラスタ化 MDS が構想されていたが、回復プロトコルの複雑さから段階的導入が計画され、実装までに数十年を要した (Source: [[並列ファイルシステム]], [[@2019__arXiv__The Lustre Storage Architecture]])。 設計文書が 539 ページと長大であること、性能評価データを含まないため設計判断の定量的根拠が限定的であることは、著者側も認めている (Source: [[@2019__arXiv__The Lustre Storage Architecture]])。 ### 11.2 エクサスケールのファイルシステム Frontier のセンター全体ファイルシステム Orion は、初のエクサスケール Lustre として George らによって実測された。 10 PB の NVMe メタデータ層、11.5 PB の NVMe 性能層、679 PB の HDD 容量層という 3 層を、単一の POSIX 名前空間へ統合している (Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]])。 3 層構成の動機は、過去のワークロード分析にある。 OLCF の従来の並列ファイルシステムではファイルの約 88 パーセントが 8 MiB 未満だった。 ![[_attachments/survey-2025-lustre-unveiled/ch06-fig22-file-size-distribution.png]] **図11-1**:Orion 上のファイルをサイズ帯別に見た分布。(a) が件数の割合、(b) が総バイト数の割合である。件数では 4 KiB 以下が 29.7 パーセントを占め小さいファイルが大半なのに対し、バイト数では 16 GiB 帯が 73.2 パーセントを占める。この図は設計の動機となった従来システムの分析そのものではなく Orion 自身の 2024 年時点の分布だが、本文が述べた「小さいファイルが件数を支配する」という前提が運用後も保たれていることを示す。件数とバイト数で支配的な帯が逆転する構造が、本文の段階的レイアウトが 4 段を要した理由にあたる。 (Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]], 図 22) そこで既定のプログレッシブファイルレイアウトを、先頭 256 KiB をメタデータターゲット上に格納し、8 MiB までを性能プール、8 MiB から 128 GiB を容量プールの単一ターゲット、128 GiB 超を容量プールの 8 ターゲット分散という 4 段階にして、利用者がレイアウトを調整しなくても幅広い入出力パターンに対応することを狙った (Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]])。 実測性能は、ファイルシステムレベルで順次書き込み 4.6 TiB/s、読み出し 4.7 TiB/s である(IOR、1,060 ノードかける 16 プロセス、プロセスあたり 160 GiB のファイル、既定レイアウト)。 これは SSU レベルの性能を 225 SSU 分に線形スケーリングした期待値に対し、書き込みで 91.5 パーセント、読み出しで 68.7 パーセントにあたる (Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]])。 メタデータ側の非対称が、この章の要点である。 単一 MDT の lookup 操作は毎秒 20 万回超に達するが、ファイル削除と作成のレートは 16 スレッドで毎秒 5.73 万回、8 スレッドで 9.53 万回がピークである。 全 40 MDT 構成でも作成と削除が毎秒 10 万回超、stat 系が 50 万回超にとどまる (Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]])。 データ帯域がターゲット台数でほぼ線形に伸びるのに対し、メタデータは単一 MDT の処理能力が総量の構成要素として残る。 高水準の機能比較表は、この実測が示す非対称を映さない (Source: [[並列ファイルシステム]])。 運用の実像も記録されている。 2024 年 3 月時点でファイル約 29.7 億件、ディレクトリ約 1.02 億件、集計サイズ 193.65 PiB(総容量の 31.12 パーセント)、平均ファイルサイズ 69.95 MiB である(fprof によるプロファイル、完了に約 69 時間) (Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]])。 著者らは、ターゲット個別の性能測定が代表 4 基に限られること、ファイルシステムレベルの実測が線形スケーリング期待値を下回る乖離要因を本章で分析していないこと、Darshan による分析が 3 か月に限られ通年の季節変動や LLM 学習の増加といった変化は将来データでの検証が必要であることを明記している (Source: [[@2025__TOS__Lustre Unveiled - Chapter 6 Lustre in Practice - Frontier's Orion]])。 ### 11.3 本番環境の出力ボトルネック Oak Ridge National Laboratory の Xie らは、Titan の本番入出力を統計的にサンプリングし、短い時間スケールで大きく変動すること、同期並列入出力ではストラグラーが全体帯域を律速することを示した (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 律速の機構は階層的である。 単一クライアントと単一ターゲットのパイプラインは、飛行中 RPC を 8 個までとする保守的なフロー制御に律速され、2 GB 以上のバーストでターゲット飽和帯域のおよそ 70 パーセントが上限になる。 ストライピングはクライアント側の複数パイプラインを十分に満たせないため、最適点はストライプ幅 8 から 16 ターゲットにとどまる。 ファイル共有では 4 KiB ブロック粒度の範囲ロック競合により、保持者が返却範囲の保留書き込みをフラッシュしてからロックを解放するため、パイプラインに待ち時間の空洞が生じる (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 結合度を下げた入出力が有利になる。 独立ファイル構成(12 コアかける 12 ターゲット)は 1.4 GB/s 超のピークを出し、ピークの中央値はストライピングよりそれぞれ約 30 パーセントと 50 パーセント高い。 独立書き込みは共有書き込みに対し最大 2 倍の帯域を示す (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 実アプリケーションでの検証でも、HACC IO では独立書き込みが共有書き込みより 1.2 倍以上速い場合が 64.2 パーセントから 100 パーセントを占め、極端な場合は 372.4 倍に達した (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 ストラグラーの影響は反実仮想で定量化された。 60 パーセントの試行で最遅ストラグラーを除去すると 5.9 パーセント超、90 パーセントの試行で全ストラグラーを除去すると 47.75 パーセント超の改善が得られる (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 一方、履歴に基づく適応の利益は小さいと結論されている。 ターゲットの性能劣化は長期的な固定ホットスポットではなく一時的な条件に左右されるためである。 2017 年の実験(1,008 ターゲット対象)では、低性能ラベルのシーケンスの 70 パーセント以上が 1 分以内、82 パーセント以上が 2 分以内に正常復帰した (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 著者らは、結果が Titan の構成と運用負荷に依存し他システムへの定量的一般化は保証されないこと、書き込み共有を避ける設計がファイル数を増やし後処理とメタデータ処理へ別の負荷を移す可能性を明記している (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 ### 11.4 HPC とクラウドストレージの接近 深層学習ワークフローの流入により、HPC の並列ファイルシステムとクラウドのオブジェクトストレージを接続する要求が生じている。 Astsatryan らは、Lustre クラスタに変更を加えず、ステートレスな軽量ゲートウェイ層で S3 互換オブジェクトストレージを統合する構成を示した。 ゲートウェイは階層型名前空間の操作を S3 互換の要求へ変換し、適応的ストライピングとストリーミングパイプラインで Lustre 読み出しとアップロードを重ねる。 ゲートウェイがステートレスであり永続データは Lustre と MinIO 側に残るため、障害時もジョブの再試行で回復できる (Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]])。 実測では、同等構成の Ceph との比較でシーケンシャル読み出しが最大 33.3 パーセント向上(61.2 GB/s 対 45.9 GB/s)、書き込みが 21.9 パーセント向上(47.8 GB/s 対 39.2 GB/s)、メタデータ操作が 27.8 パーセント多く(14.7 Kops/s 対 11.5 Kops/s)、平均レイテンシが 40.7 パーセント低減した(MLPerf Storage、CloudLab c220g2 サーバ群)。 モデル別の感度も測られており、Transformer 系(BERT)は CNN(ResNet-50)に比べメタデータ性能への感度が 2.3 倍高く、最適なチェックポイント間隔は 173 秒(CNN は 215 秒)である (Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]])。 著者らは、ゲートウェイノードの追加ハードウェアコストと単体障害時のフェイルオーバーが今後の課題であることを明記している (Source: [[@2026__ACCESS__Convergence of HPC and Cloud Storage Systems for Deep Learning Workflows An Evaluation of LustreFS and S3-Compatible Object Storage]])。 --- ## 第 12 章　電力制約とエクサスケールの見積もり ### 12.1 4 つの課題 2008 年、Kogge を編者とする ExaScale Study Group は DARPA の委託で、主流の計算技術が 2015 年ごろまでに計算能力の 1,000 倍を許さないと結論し、新規研究を要する 4 つの主要課題を挙げた。 エネルギーと電力、メモリとストレージ、並行性と局所性、レジリエンスである (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 1 Executive Overview]])。 エネルギーと電力については、成熟技術のどの組み合わせでも所望の電力水準に届かないとされた。 さらに、基礎演算の電力よりも、データ移動(チップ内、パッケージ内のチップ間、ラック間)と階層メモリへの格納の電力のほうが解きにくい可能性があると述べている (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 1 Executive Overview]])。 並行性については、クロックの頭打ちと単一スレッド性能の終焉により、プログラマから見える並列性だけが性能向上の手段になる。 データセンター級ではアプリケーションが 10 億本超の別々のスレッドを支える必要が出うる (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 1 Executive Overview]])。 ### 12.2 エクサスケールの定義 報告書はエクサスケールを「2010 年のペタスケール系の 1 つ以上の重要属性が 1,000 倍」と定義し、機能性能と物理属性と応用性能の 3 次元で捉えた。 電力は機能指標を分子とする比の分母として見る (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 2 Defining an Exascale System]])。 2015 年のデータセンター系は計算部で最大 500 ラック、20 メガワットを上限とする。 汎用機として成立させるには主記憶が最低 10 PB(広い問題群には 10 の 17 乗バイト)、持続ストレージが 10 の 18 乗バイト、局所メモリ帯域が約 1 EB/s 必要とされた (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 2 Defining an Exascale System]])。 この多属性の定義が、第 20 章で論じるずれの起点になる。 著者ら自身が、必要メモリ容量はエクサ級への問題スケーリングの規則が未解明のため決まらないと明記している (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 2 Defining an Exascale System]])。 また本文が部門系の電力を 100 から 200 キロワットとする一方、表は「2010 年ペタ系の 1000 分の 1」とし、この食い違いは本文で解消されていない (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 2 Defining an Exascale System]])。 ### 12.3 当時の傾向線が示したもの 第 4 章は 2008 年時点の実績データを整理し、性能向上が力ずくの並列性に頼ってきたことを示した。 現代プロセッサが単純さと並列性へ移る要因は 3 つある。 ILP と深いパイプラインの掘り尽くし、定電界スケーリングの終焉(閾値電圧を下げられずリーク電流が増える)、メモリのレイテンシ増大と帯域低下である (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 4 Computing as We Know It]])。 実績値は次のとおりである。 トランジスタ密度の年成長率は ITRS 予測 1.28 に対し実績 1.5、キャッシュ容量の実績年成長率 1.82、ダイ面積 1.16、トランジスタ数 1.42。 クロックは実績年成長率 1.3 で伸びたのち 2004 年以降は約 3 GHz で停滞した(ダイ電力 100 ワット超で冷却限界に達したため)。 Top500 の Rpeak 年成長率は約 1.89、Rmax は約 1.97 であり、10 倍に 41 から 43 か月、1000 倍に 10 年から 11 年かかる (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 4 Computing as We Know It]])。 この傾向線から、明示的な予測が 1 つ立てられた。 2010 年に初のペタフロップスが出るなら、この傾向が続けば初のエクサフロップスは 2020 年になる (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 4 Computing as We Know It]])。 一方で研究の目標時期は 2015 年に置かれていた (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 3 Background]])。 5 年分の前倒しを新規研究で埋めるというのが、報告書の構図である。 データセンターの電力配分も測られている。 壁電力のうちロジックに届くのは約 48 パーセント(Intel 調査)から約 60 パーセント(Dell 白書)で、冷却は総電力の約 31 パーセント。 電子部品 1 ワットの散逸に対し変換で 0.7 から 1.06 ワット、冷却で 0.88 から 1.07 ワットが失われるため、40 メガワットのデータセンターの計算電力は約 13 から 15 メガワットになる (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 4 Computing as We Know It]])。 なお報告書自身が、ロジックに届く電力割合が出典により異なり両方を併記して統一していないと注記している (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 4 Computing as We Know It]])。 ### 12.4 技術ロードマップの限界 第 6 章は、ロジック、主記憶、ストレージ、相互接続、パッケージと冷却、耐障害性、運用環境、プログラミングモデルのいずれもが単独ではエクサスケールの要件を満たさないと結論した (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]])。 電圧を下げることが最大のレバーだが、下げるとクロックも下がり並列度で補う必要が生じる。 65nm の試験チップでは 1.2V から 320mV へ下げると電力が約 10 倍減る一方クロックは約 100 倍減り、同じ性能には約 100 倍の並列度が要る (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]])。 ITRS 2006 を従来型 CMOS で外挿すると、2013 年から 2014 年に 2005 年のコアを敷き詰めたダイの電力密度は 7 倍から 10 倍になり、冷却可能範囲(1 チップ約 100 ワット)を超える (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]])。 耐障害性はソケット数の指数的増加が押し下げる。 2015 年にソケットが 10 万個超、DRAM チップが 1000 万個超になる見込みで、ソケット 1 個あたり 0.1 件毎年の故障率を仮定すると 22 万ソケットで平均中断間隔は約 24 分、故障率が 10 倍改善しても約 4 時間である (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]])。 10 PB のディスク系が実効 30 パーセントの帯域だとチェックポイントに約 5 時間かかるという見積もりも示され、保存間隔が縮む一方で保存時間が伸びる悪循環が指摘された (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]], [[@2008__DARPA__ExaScale Computing Study - Chapter 8 Exascale Challenges and Key Research Areas]])。 ### 12.5 ストローマンが示した電力配分 第 7 章は、進化型の延長だけでは 20 メガワットに収まらないことを 2 種のモデルで示し、さらに白紙設計のストローマンを作った。 進化型の重いノード(Red Storm と Cray XT が基準)は、電力無制約でも 2020 年に単純モデルで 1.6 かける 10 の 8 乗ギガフロップス、完全比例モデルで 9.2 かける 10 の 6 乗ギガフロップスであり、20 メガワット制約では 2015 年以降それぞれ 2 かける 10 の 7 乗と 1 かける 10 の 6 乗にとどまり、エクサフロップスから 2 桁から 3 桁不足する。 軽いノード(Blue Gene/L と /P が基準)は 2015 年に目標から 1 桁から 2 桁差まで迫るが、到達は 2020 年より後になる (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]])。 積極設計のストローマン(32nm、2013 年想定)は 742 コアで 4.5 テラフロップス、チップ 214 ワット、583 ラックで 1 エクサフロップスを 67.7 メガワットと DRAM 3.6 PB で達成する構成になった。 20 メガワットへ引き直すと約 303 ペタフロップス、すなわち 1 エクサフロップスの約 30 パーセントにとどまる (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]])。 電力配分がこの報告書の最も引用に値する結果である。 FPU が 17 パーセント、メモリが 31 パーセント、インターコネクトが 27 パーセント、リークが 25 パーセントであり、演算器は最小の項目である。 第 7 章の総括は、真のエネルギーの課題が効率的な FPU ではなく低エネルギーのデータ輸送にあると述べ、FPU を面積とコストと電力の点で最も安い資源の 1 つと位置づけている (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]], [[データ移動エネルギー]])。 ![[_attachments/darpa-2008-exascale-computing-study/ch07-fig7.20-power-distribution-aggressive-strawman-system.png]] **図12-1**:積極設計ストローマンの電力配分。(a) のシステム全体では FPU が 17 パーセント、メモリが 31 パーセント、インターコネクトが 27 パーセント、リークが 25 パーセントを占める。(b) はメモリ内訳で L1 が 39 パーセント、レジスタファイルが 28 パーセントと、DRAM(3 パーセント)よりオンチップ側が支配的である。(c) はインターコネクト内訳で網が 60 パーセントを占める。本文が述べた「演算器は最小の項目であり、真の課題はデータ輸送にある」という結論は、この (a) の 4 分割そのものである。 (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]], 図 7.20) 階層ごとのエネルギーの数値もこの結論を支える。 FPU 単体は 1 演算 10.6 ピコジュールだが L1 まで含むコアでは 23.3 ピコジュールと 2 倍以上になる。 オンチップの配線は 110 フェムトジュール毎ビット毎ミリメートル、0.1V 振幅の低振幅方式で 18 フェムトジュール、オフチップは市販で 2 ピコジュール毎ビットから 30 ピコジュール毎ビットの幅がある。 第 8 章は 1 レベルあたり 1 ビットの移動を 1 から 3 ピコジュールとし、1 EB/s を要する経路 1 段で電力が 10 から 30 メガワットになると見積もった (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]], [[@2008__DARPA__ExaScale Computing Study - Chapter 8 Exascale Challenges and Key Research Areas]], [[データ移動エネルギー]])。 > [!warning] この報告書の数値を引くときの注意 > 報告書は各章に自己申告の不整合注記を多数抱えたまま出版されている。 > 第 2 章の部門系電力、第 5 章の類型対応と図番号の誤記、第 6 章の 10 箇所を超える不整合、第 7 章の主記憶容量(3.6 / 3.4 / 3.58 PB)とチップ電力と DRAM アクセスエネルギー(3 対 10 ピコジュール毎ビット)の多重不整合、第 8 章の推進項目数の食い違いがある (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]], [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]], [[@2008__DARPA__ExaScale Computing Study - Chapter 8 Exascale Challenges and Key Research Areas]])。 > 低振幅シグナリングの値も第 6 章と第 7 章が 18 フェムトジュール毎ビット毎ミリメートル、第 8 章が約 6 フェムトジュール毎ミリメートルと章により異なる (Source: [[データ移動エネルギー]])。 > 積極設計は ECC、タグ、クロック配信、冗長化、RAID を含まない最良ケースであることも明記されている (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]])。 > 個別の数値を単独で引くのではなく、どの前提の下で出た値かを併記する必要がある。 第 8 章は結論として、データセンター級で 20 メガワット以内に 1 エクサフロップスを収める道筋は示されないと明記した (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 8 Exascale Challenges and Key Research Areas]])。 この予測が実機とどれだけずれたかは、第 14 章と第 20 章で扱う。 --- ## 第 13 章　協調設計という方法論 協調設計は、科学アプリケーション、ソフトウェア、ハードウェアの各コミュニティが共同で将来の計算システムを設計する方法論であり、HPC ではエクサスケールに必要な電力予算を満たす戦略として注目された。 できるだけ多くのアプリケーションに利益が及ぶよう、電力とコストと性能のトレードオフを対象アプリケーションの特性に基づいて決める (Source: [[協調設計]])。 Fugaku はこの方法論を最も明示的に実践した事例である。 理化学研究所の Sato、Kodama、Tsuji と富士通の Odajima は、電力予算 30 から 40 メガワット内で実アプリケーション性能を最大化するという KPI のもとで設計を進めた。 探索には段階の異なる道具を使い分けている。 FX100 の実行プロファイルを入力とする性能推定ツール、富士通の社内シミュレータ、Gem5、解析モデルである (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 協調設計の結果として決まったパラメータは第 14 章で述べる。 ここでは方法論としての限界を記す。 性能推定ツールはアウトオブオーダー実行の資源の影響を扱えず、サイクル精度シミュレータは単一プロセッサに限られる。 対象アプリケーション群の選び方が、設計の数年後に現れる AI や混合精度のワークロードへどこまで汎化するかも開いたままである (Source: [[協調設計]])。 協調設計の対象そのものが、世代とともに変質している点も見ておきたい。 Fugaku はハードウェアとソフトウェアを、アプリケーション性能と電力予算という単一の目標のもとで協調設計する古典的な形を採った (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 これに対し TPUv4 は、チップのパラメータ決定よりも、稼働中のシステムを運用ソフトウェア(光回線交換の再構成、健全性監視、資源管理)で動的に最適化する方向へ重心を移している (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 同じ傾向は、電力平滑化と電力予算内の GPU 数最適化を製品機能として打ち出す現行の GPU アーキテクチャにも見える (Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。 協調設計の対象が設計時から運用時へ移りつつある。 --- ## 第 III 部　現代機の実像 ここからは個別の機械を扱う。 各章の構成は、ノード構成、メモリ、結合網、実測性能、限界の順に揃える。 章をまたぐ比較は第 18 章の表にまとめる。 --- ## 第 14 章　Fugaku ### 14.1 協調設計が決めたノード Fugaku のノードは A64FX チップ 1 個である。 Armv8 に SVE を加えた命令セット、512 ビット SIMD を 2 本、48 コアと 4 個のアシスタントコア(12 コアかける 4 CMG)を持つ。 キャッシュは L1 と L2 のみで L3 を持たない。 メモリは HBM2 を 32 GiB 積み、DDR を搭載しない。 TSMC 7nm FinFET の単一大型ダイで約 400 平方ミリメートルである (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]], [[A64FX]])。 DDR を積まない判断は、第 8 章で見たメモリ帯域の制約に対する直接の回答である。 標準クロックでの倍精度理論ピークは 3 テラフロップスで、実測では STREAM triad が 830 GB/s 超、dgemm が 2.7 テラフロップス超(効率 90 パーセント)に達する (Source: [[A64FX]], [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 電力制御は設計パラメータとして組み込まれている。 SIMD 幅、パイプライン数、メモリ帯域をパワーノブとし、演算器 1 本を停止するエコモードと電圧を上げるブーストモードを持つ。 エコモードは STREAM の評価で電力を 15 から 25 パーセント削減しつつ性能をほぼ同等に保ち、ブーストモードは dgemm の評価で性能を 10 パーセント上げる代わりに電力が 13.7 パーセント増え、電力効率は 3.3 パーセント下がる (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 結合網は Tofu-D で、第 5 章で見た 6 次元メッシュとトーラスの系譜を継ぐ。 注入帯域は 40.8 GB/s である。 1 MB の put 通信で帯域 6.35 GB/s が実測されている (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]], [[Fugaku]])。 ストレージは京と同じ 2 層構成を採る。 計算ノード 16 台ごとに 1 台の SSD 付きノードが第 1 層、Lustre ベースのグローバルファイルシステムが第 2 層である (Source: [[Fugaku]])。 ### 14.2 到達した性能 システム全体は 158,976 ノード、760 万コア、理論ピーク FP64 で 537 ペタフロップスである。 2020 年 6 月に TOP500 の HPL で 442 ペタフロップス、HPCG で 16 ペタフロップス、HPL-AI で 2 エクサフロップス(混合精度)、Graph500 で 102.95 テラ TEPS を記録し、4 部門同時 1 位を 2021 年 11 月まで維持した。 運用電力は 2021 年 3 月以降の一般利用時点で平均約 20 メガワット、最大 30 メガワット近くである (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]], [[Fugaku]])。 HPL 442 ペタフロップスは理論ピーク 537 ペタフロップスの約 82 パーセントにあたる。 第 20 章で扱う実効率の議論で、この値は比較の基準になる。 単一スレッド性能は汎用 CPU に劣る。 SPEC CPU2017 int base の総合値は Fugaku が 1.98、Xeon Platinum 8168(Skylake、2.7GHz、24 コアかける 2、ターボ有効)が 9.07 である。 SPEC OMP2012 では Fugaku が 7.77(48 スレッド)、Xeon Platinum 8280(Cascade Lake、28 コア、HT 有効 56 スレッド)が 12.0 である (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 単一スレッドで約 4 分の 1、並列で約 65 パーセントという位置づけになる (Source: [[A64FX]])。 汎用性能を犠牲にして電力あたりの並列性能を採るという設計判断が、数値として見える。 著者ら自身が、本稿が解説論文であり詳細な数値と評価条件を他の論文に譲ること、K computer 比 100 倍を達成したのが 2 本のアプリケーションのみであること、SPEC の比較が世代の異なる Xeon との単一設定であること、コンパイラが一部で未成熟でありプロセッサを効率的に使う経験が不足しているため最適化されていないアプリケーションが残ることを明記している (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 > [!contradiction] Fugaku はエクサスケール機か > Fugaku の FP64 の HPL は 442 ペタフロップス(理論ピーク 537)であり 1 エクサフロップスに届かない。 > 2 エクサフロップスという値は HPL-AI、すなわち混合精度の値である (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 > 倍精度の持続性能で 1 エクサフロップス以上を要件とする定義では、Aurora の HPL 1.012 エクサフロップス毎秒と並べて読むことはできない (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 > 本書では、精度を明記しない「エクサスケール」という言い方を避ける。 --- ## 第 15 章　米国のエクサスケール 3 機 ### 15.1 Frontier Oak Ridge National Laboratory の Atchley、Zimmer、Lange ら約 40 名は、米国初のエクサスケール機 Frontier を報告した。 9,472 ノードからなり、各ノードは AMD EPYC 7A53(Trento、64 コア、DDR4-3200 を 64 GiB かける 8、ピーク 205 GiB/s、NPS-4 で運用)を 1 基と AMD Instinct MI250X を 4 基(GCD としては 8 基)持つ (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 CPU と GPU の比は 1 対 4 であり、Titan の 1 対 1、Summit の 1 対 3 より太いノードになっている。 GPU の HBM 総帯域 13.08 TB/s は CPU メモリ帯域の 64 倍にのぼり、データを HBM に置き続ける利用を前提とした設計である。 CPU と GCD の間は xGMI 2.0(片方向 36 GB/s)、GCD 間は 1 本、2 本、4 本の xGMI 3.0(1 本 50 と 50 GB/s)で twisted ladder 状に結線される。 NIC を MI250X の OAM パッケージへ直結する構成が設計上の革新として挙げられている (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 ![[_attachments/Frontier--Exploring-Exascale/fig02-node-connectivity.png]] **図15-1**:Frontier ノードの内部接続。左下の CPU が 8 個の CCD を持ち、4 つの MI250X パッケージ(GCD 8 基)と PCIe ESM 50 GB/s で結ばれる。GCD 間は xGMI3 の 50 GB/s、CPU と GCD 間は xGMI2 の 36 GB/s である。各 MI250X パッケージの外側に NIC が直付けされている点が、本文が述べた設計上の革新にあたる。本文が挙げた GCD 間転送の 37.5、74.9、145.5 GB/s という実測値は、この図でリンクが 1 本、2 本、4 本と束になっている箇所に対応する。 (Source: [[@2023__SC__Frontier - Exploring Exascale]], 図 2) 結合網は Slingshot の 3 ホップ Dragonfly で 80 グループ(管理 1、入出力 5、計算 74)からなる。 Clos に比べポートとケーブルが約半分で済むが、グローバル帯域と注入帯域の比が 57 パーセントというテーパを持ち、直接網ゆえ非最小経路制御を使う (Source: [[@2023__SC__Frontier - Exploring Exascale]], [[ドラゴンフライトポロジ]])。 エネルギー効率が最大の成果である。 1.1 エクサフロップスを 21.1 メガワットで達成し、52 ギガフロップス毎ワットで目標の 50 を超えた。 TOP500 と Green500 の同時 1 位である (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 実測値をいくつか挙げる。 GCD 1 基の FP64 ピークは 23.95 テラフロップス毎秒、行列コア命令使用時は FP32 が 24.1、FP64 が 33.8、FP16 が 111.2 テラフロップス毎秒である。 CPU の STREAM は NPS-4 の非一時ストアで最大約 180 GB/s、NPS-1 で約 125 GB/s。 GPU の STREAM はピークの 79 から 84 パーセント。 GCD 間の転送は、SDMA がリンク数によらず約 50 GB/s で頭打ちになるのに対し、CU カーネルは 1 本、2 本、4 本のリンクで 37.5、74.9、145.5 GB/s と伸びる (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 ネットワークの性格は Summit との比較で見える。 mpiGraph では NIC あたりの帯域が 3 から 17.5 GB/s に分散する(Summit は約 8.5 GB/s に集中)。 最悪は約 3 GB/s で、全トラフィックがグローバルリンクを経由し非最小経路で帯域が半減する場合にあたる (Source: [[@2023__SC__Frontier - Exploring Exascale]], [[ドラゴンフライトポロジ]])。 輻輳耐性は GPCNeT で測られ、9,400 ノード(輻輳源 7,520、被害側 1,880)の 8 プロセス毎ノードで影響係数 1.0 倍、すなわち孤立時と輻輳時が同等である。 32 プロセス毎ノードでは平均 1.2 から 1.6 倍、99 パーセンタイルで 1.8 から 7.6 倍劣化するが、Summit の EDR より良好である (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 アプリケーションの到達も記録されている。 CAAR(Summit 比 4 倍が目標)では CoMet 5.2 倍、LSMS 7.5 倍、PIConGPU 4.7 倍、Cholla 20.0 倍、GESTS 5.9 倍、AthenaPK 4.6 倍。 ECP(約 20 ペタフロップス機比 50 倍が目標)では WarpX 500 倍、ExaSky 234 倍、EXAALT 398.5 倍、ExaSMR 70 倍、WDMApp 150 倍である。 CoMet は 9,074 ノードで混合精度 6.71 エクサフロップスを記録した (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 限界も明示されている。 HBM の価格は推測(DDR の 3 倍から 5 倍)でコスト比率も推定である。 レジリエンスは定量データがなく電源対策は計画段階にとどまる。 結果の多くは初期の数値で、比較のベースラインがアプリケーションごとに異なる(Summit、Titan、Cori、Mira、Theta)ため比較の厳密さが限られる。 レジリエンスは DARPA 報告の投影(平均中断間隔 24 分、故障率 10 倍改善で 4 時間)をあまり上回らず、原因はメモリと電源にある。 長期には 8 時間から 12 時間へ改善する見込みとするにとどまる (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 ### 15.2 Aurora Argonne National Laboratory と Intel と HPE の Allcock ら約 130 名は、シミュレーションとデータ科学と機械学習の 3 領域を同格に支える設計として Aurora を報告した (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 ノードは Xeon Max(Sapphire Rapids、52 コア)を 2 基、Ponte Vecchio を 6 基、Slingshot NIC を 8 基持つ。 CPU と GPU の比を 2 対 6 としたのは、ブレードの電力と寸法の制約内で性能と密度を最大化するためである。 Xeon の HBM2e 64GB は、データステージング用の高速バッファとしても DDR の透過キャッシュとしても構成できる。 Ponte Vecchio の FP64 倍速を行列ユニットではなくベクトルユニットに持たせた判断は、HPC アプリケーション全般が恩恵を受けるようにするためである (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 システム全体は 10,624 ノード、63,744 基の GPU、21,248 基の CPU である。 結合網は 1 次元 Dragonfly で 175 グループ(計算 166、DAOS 8、サービス 1)、計算グループは 1 キャビネットに対応し 32 スイッチが全結合、グループ間は各 2 本のグローバルリンクで結ばれる。 84,992 エンドポイントで注入帯域 2.12 PB/s、全体のバイセクション帯域 0.69 PB/s は注入帯域の約 3 割である (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]], [[ドラゴンフライトポロジ]])。 主ストレージ DAOS は 1,024 サーバ(NVMe 15.3TB を 16 本、Optane PM200 512GB を 16 本)で理論ピーク 31 TB/s 超、4 億 IOPS である (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 電力は設計持続 4 キロワット、約 5 から 20 ミリ秒の短時間ピークで 4.6 キロワット、通常負荷で 3.8 キロワット(CPU 約 350 ワット、GPU 500 ワット)である (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 単一 PVC の GEMM 実測は、FP64 が 29.2、FP32 が 44.0、TF32 が 212.8、BF16 が 420.3、FP16 が 421.6、INT8 が 854.3 テラフロップス毎秒である(その時点で稼働していた全 GPU と全 CPU の 1 ノード内スイープの最良値の中央値、FP64 は GPU のみ 512 ノードの実行)。 STREAM Triad は GPU が 2.1 TB/s、CPU が 0.63 TB/s(DDR5 は 0.24 TB/s)である (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 ベンチマークの到達は次のとおりである。 HPL は 9,234 ノード(約 87 パーセント)で 1.012 エクサフロップス毎秒(SC24 で 3 位、スケーリング効率 78.84 パーセント)。 HPL-MxP は 9,500 ノード(約 89 パーセント)で 11.64 エクサフロップス毎秒(SC24 で 1 位、LU 分解は FP16 と FP32、反復改善は FP64)。 HPCG は 4,096 ノードで 5.613 ペタフロップス毎秒、Graph500 は 8,192 ノードで 69,373 GTEPS、IO500 は 300 ノードで 32,165.90(SC23 で 1 位)である (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 参照アプリケーションは 20 ペタフロップスの基準機比 50 倍を目標とし、CANDLE Pilot Uno が 130.1 倍、CosmicTagger が 124.6 倍、ThunderSVM が 81.6 倍などで目標を超えた。 一方 ResNet-50 は 42.2 倍、Nekbone はメモリ帯域の制約により 22.2 倍で目標に届かなかった (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 限界としては、設計判断の代替案比較や感度分析がなく妥当性が結果からの推測にとどまること、単一 GPU の性能指標が匿名の図で示され値の表が本文にないこと、HPL のスケーリング効率 78.84 パーセントの序盤の性能低下の原因が特定されていないこと、GPU バッファの 4 NIC 帯域(35.9 GB/s)が CPU バッファ(94.7 GB/s)の半分以下にとどまる理由の説明がないことが挙げられる。 表のグローバル帯域(1.37 PB/s)と本文(1.38 PB/s)にも論文内の不一致がある (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 ### 15.3 El Capitan と APU への転換 El Capitan は 11,520 ノード、AMD Instinct MI300A を 46,080 基持ち、システムピークは倍精度 2,889.2 ペタフロップス毎秒、単精度 3,815.0、半精度 18,248.4 ペタフロップス毎秒、ピーク電力 36.0 メガワット、計算キャビネット 90 台である。 2024 年 11 月の TOP500 で 1 位となった。 姉妹機に Tuolumne(1,152 ノード)、El Dorado(384 ノード、Sandia 設置)、rzAdams(128 ノード)がある (Source: [[@2026__LLNL HPC__El Capitan Hardware Overview]], [[El Capitan]])。 Frontier との最大の差は、CPU と GPU が同一パッケージ内で HBM3 を共有する APU 構成である。 MI300A は CPU チップレット(CCD 3 基、Zen4 24 コア)と GPU チップレット(XCD 6 基、各 38 CU で計 228 CU)、メモリ側キャッシュの Infinity Cache、HBM3 8 スタックを Infinity Fabric で 1 パッケージに統合し、コピーなしで CPU と GPU のどちらからも直接ロードとストアができ、全 CPU と全 GPU とハードウェアコヒーレントである (Source: [[@2026__LLNL HPC__El Capitan Hardware Overview]])。 なぜこの構成に辿り着いたのかを、AMD の Smith、Loh、Schulte、Ignatowski、Naffziger ら 13 名が明かしている。 Frontier ノードは当時の異種集積技術が未成熟だったため、Exascale Heterogeneous Processor の構想を APU ではなく別パッケージの EPYC CPU と MI250X 4 基として実現したものだった。 構想の第 3 版は能動インターポーザ上の 3D 積層だったが、GPU チップレット 4 個を 400 平方ミリメートル超のインターポーザに載せさらに HBM を積む構造は、工程の追加と多数ダイの個別扱いと過大な放熱のため不採用になった。 第 4 版は EPYC サーバ用の IOD を流用したため、ダイ間インターフェースの制約で 2 つの GPU が遠く離れ、反対側の HBM アクセスで帯域が低下し電力が増え、CPU と HBM の間に 2 回のダイ間ホップが必要になり、DDR 級の帯域を想定した 2D リンクに限られたため不採用になった (Source: [[@2024__ISCA__Realizing the AMD Exascale Heterogeneous Processor Vision]])。 MI300A はこれらを IOD の 4 分割で解いた。 XCD と CCD を 3D ハイブリッドボンディング(ピッチ 9 マイクロメートル、金属パッドの直接接合)で IOD へ垂直に接続し、IOD 同士は面積帯域密度が従来 SerDes 比で 10 倍超かつ消費電力 0.4 ミリワット毎 Gbps の USR PHY で結び、IOD 群と HBM 8 スタックを 2.5D シリコンインターポーザに載せる。 約 1,460 億トランジスタ(HBM 除く)に達する (Source: [[@2024__ISCA__Realizing the AMD Exascale Heterogeneous Processor Vision]])。 キャッシュ階層の設計にも工夫がある。 Infinity Cache はダーティデータを保持せずコヒーレンシに参加しないためスヌープ処理が不要になり、効率が上がりレイテンシが下がる。 容量 256 MB(8 スタックかける 16 チャネルの 128 チャネル、各 2MB スライス)、ピーク帯域 17.2 TB/s である。 HBM3 は 5.2 Gbps バスでソケットあたり 128GB、理論ピーク帯域 5.3 TB/s。 GPU の理論ピークは FP64 ベクトルが 61.3 テラフロップス、FP32 ベクトルと FP64 行列と FP32 行列がいずれも 122.6 テラフロップスである (Source: [[@2026__LLNL HPC__El Capitan Hardware Overview]])。 世代間の比較は AMD 自身の測定による。 MI250X 比で HBM 帯域が 70 パーセント増、I/O 帯域が 2 倍、OpenFOAM が 2.75 倍高速化した(ブリングアップ用リファレンスプラットフォーム、128GB HBM3、TDP 550 ワット、ROCm 6.0。基準の MI250X は 128GB HBM2e、TBP 560 ワット、ROCm 5.4.3)。 ただし ROCm の版が異なるためソフトウェアの差が混ざること、評価が少数のワークロードに限られ独立検証がないことを著者らが認めている (Source: [[@2024__ISCA__Realizing the AMD Exascale Heterogeneous Processor Vision]])。 ### 15.4 APU 内部の通信 KTH Royal Institute of Technology の Schieffer、Wahlgren、Shi と LLNL の Leon、Pearce、Gokhale、KTH の Peng は、MI300A の 4 APU ノードにおける APU 間通信を実測した。 全 APU 対が同一帯域の Infinity Fabric 2 本で直結され、MI250X のような不均衡な帯域や最大 2 ホップの経路がない (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 カーネルによる直接アクセス(STREAM Copy を APU0 で実行し APU1 から 3 のデータへコピー)は 103 から 104 GB/s で、理論値の片方向 128 GB/s の約 81 パーセントにあたり、配置先によらず一定である。 比較として MI250X では GCD0 と GCD2 の間が 50 GB/s、GCD0 と GCD6 の間が 100 GB/s であり、それぞれ理論値の 82 パーセントと 81 パーセントである (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 MI250X 世代で不十分だった SDMA エンジンの帯域制約が MI300A では解消されている (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 同じ制約は AMD 自身も別の文脈で認めており、第 4 版の構想が GPU チップレット間の帯域が低く 1 つのカーネルを両方で実行するのに向かなかったこと、MI250X が GCD を別々のアクセラレータとして見せたのも同じ理由であることを述べている (Source: [[@2024__ISCA__Realizing the AMD Exascale Heterogeneous Processor Vision]])。 > [!warning] Infinity Fabric のリンク帯域は文献ごとに表記が揃っていない > 実測を持つ MemSys 論文は「1 本 16 ビット幅、32 GT/s で片方向 64 GB/s、APU 対ごとに 2 本で片方向 128 GB/s、実測 103 から 104 GB/s」と記す (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 > LLNL の公式文書は「帯域 256 GB/s のリンク 2 本で全結合」と記す (Source: [[@2026__LLNL HPC__El Capitan Hardware Overview]])。 > AMD の ISCA 論文は「x16 は双方向 128 GB/s、1 ソケット 8 本で計 1,024 GB/s、4 基の MI300A ノードは 6 本で完全結合」と記す (Source: [[@2024__ISCA__Realizing the AMD Exascale Heterogeneous Processor Vision]])。 > 片方向か双方向かの明示がないため、素朴には突き合わせられない。 > 本書では実測を持つ MemSys の表記(片方向 128 GB/s が理論値)を採る。 > この機械の帯域を引用するときは、必ず方向の定義を確認してほしい。 メモリ割り当ての選び方が性能を左右する点も実測されている。 RCCL はアロケータに依らず最大帯域を出す一方、MPI はアロケータの組み合わせに敏感で、送受信の双方が `hipMalloc` なら 82 GB/s、送信側が `malloc` だと 11.7 GB/s まで落ちる。 著者らは原因を、GPU 専用と system の 2 系統のページテーブルが絡むことによる負荷という仮説として提示している。 実アプリケーションの CloverLeaf では、元の MPI 版の通信時間がアロケータにより 1.01 秒から 1.55 秒まで開くのに対し、RCCL 版では 0.69 秒から 0.83 秒へ収束し、通信最適化版は全体でアロケータに応じて 1.5 倍から 2.2 倍高速化した (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 著者らは、評価が単一ノード内の 4 APU に限ること、Cray MPICH が非公開のため原因が推測にとどまること、アプリケーションが 2 本のみで集団通信中心の負荷を評価していないこと、本文の記述に遠隔と局所のレイテンシの対応が入れ替わって読める箇所があることを明記している (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 ### 15.5 パーティショニングと電力の相互作用 Tennessee Technological University の Abouelmagd と Skjellum、LLNL の Boehme、Brink、Burmark、McKinsey、Pearce は、MI300A の論理 GPU パーティショニングが性能に与える影響を LLNL Tuolumne で実測した (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]])。 パーティショニングは 3 モードある。 SPX は全 6 XCD と 128GB HBM を単一の論理 GPU として公開しスレッドブロックを XCD へラウンドロビン分散する。 TPX は 3 分割で各 76 CU、CPX は 6 分割で各 38 CU である (Source: [[AMD Instinct MI300A]], [[GPUパーティショニング]])。 ![[_attachments/GPU-Partitioning-Power-and-Performance-of-the-AMD-MI300A/fig02-partitioning-modes.png]] **図15-2**:MI300A の 3 つのパーティショニングモード。SPX は 6 個の XCD 全体を単一デバイスとして見せ、TPX は 2 個ずつ 3 分割、CPX は XCD ごとに 6 分割する。破線が論理デバイスの境界である。本文が述べた「CPX では各プロセスが単一ダイのプライベート L2 内に閉じて実行できる」という性質は、CPX の破線が XCD 1 個ずつを囲っていることに対応する。 (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]], 図 2) 局所性依存のカーネルで差が出る。 2 次元ステンシル(Polybench_JACOBI_2D、3 行参照)では、ラウンドロビン配置により隣接ブロックが異なる XCD のプライベート L2 に散らばり、キャッシュラインが再利用前に追い出される。 実行時間は SPX が 4.86 秒に対し TPX が 4.52 秒、CPX が 3.55 秒であり、CPX が約 27 から 30 パーセント速い。 L2 ミス数は SPX の 1.134 かける 10 の 11 乗から CPX の 0.672 かける 10 の 11 乗へ半減し、HBM 読み取り要求数も 6.404 かける 10 の 10 乗から 3.361 かける 10 の 10 乗へ半減する (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]])。 1 次元ステンシルでは 3 モードの差がほとんどない(SPX 2.60 秒、TPX 2.71 秒、CPX 2.66 秒)ことから、差の原因が局所性にあることが切り分けられる。 著者らは、SPX のままスレッドブロック ID の計算を変更して CPX と同様の XCD マッピングを行う最適化を考案し、実行時間 3.59 秒、L2 ミス数 0.6719 かける 10 の 11 乗と CPX 相当を再現した (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]])。 ダイ間ラウンドロビンとプライベート L2 の不一致が差の本質であり、ブロック ID をダイ境界に合わせて再配置すれば SPX のままでも回復できる (Source: [[GPUパーティショニング]])。 電力側では、動的電力共有が性能を押し下げる。 550 ワットの TDP 制約下で複数 XCD が高負荷カーネル(ZGEMM)を同時実行すると、3 プロセス(6 ダイ中 3 ダイ)の時点で TDP 上限に到達し、ファームウェアの DVFS がグラフィックスクロックを定格 2,100 MHz から 1,600 から 1,500 MHz 程度へ引き下げる。 メモリクロックは 1,300 MHz で変動しない (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]], [[動的電力共有]])。 影響はカーネルの性格で分かれる。 メモリ制約のカーネルは単一 XCD あたり約 700 GB/s のピークメモリ帯域で頭打ちのため周波数低下の影響をほとんど受けない。 計算制約のカーネル(単一 XCD あたり最大約 750 ギガフロップス)は 1 から 2 プロセスの競合でも影響を受け始め、5 プロセス時に最大 20 パーセントの速度低下を示す (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]])。 著者らは、電力監視ツールの計測周期が 1Hz に制限されミリ秒単位の過渡的な電力と周波数のスパイクを完全には追えないこと、現行の監視が CPU と GPU とメモリとアンコアの電力を合算した APU 全体値しか取得できないため CPU と GPU の間の電力シフト量を定量的に切り分けられないこと、評価が単一ノード内に集中し大規模実行時の相互作用が今後の課題であることを明記している (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]], [[動的電力共有]])。 --- ## 第 16 章　NVIDIA 系の汎用機 ### 16.1 Perlmutter NERSC の Perlmutter は HPE Cray EX のヘテロジニアスシステムで、CPU 専用 3,072 ノードと GPU 搭載 1,792 ノードからなる。 GPU ノードは EPYC 7763 を 1 基と A100 を 4 基持ち、GPU 間は第 3 世代 NVLink(4 本かける片方向 25 GB/s)、外部へは Slingshot 11 の NIC を 4 基(各 200G すなわち 25 GB/s)持つ。 CPU 専用ノードは EPYC 7763 を 2 基と NIC を 1 基持つ (Source: [[@2026__NERSC__Perlmutter Architecture]])。 結合網は Slingshot 11 の 3 ホップ Dragonfly で、計算と入出力とサービスの 3 サブシステムがそれぞれ独自の Dragonfly を持つ。 グループ内は電気的な全対全(銅ケーブル)、グループ間とサブシステム間は光ケーブルである。 16 スイッチのグループ内が全対全で、ノード間の経路は 3 ホップになる (Source: [[@2026__NERSC__Perlmutter Architecture]], [[ドラゴンフライトポロジ]])。 公開仕様では、A100 40GB を積む 1,536 ノードの GPU パーティションがピーク FP64 で CPU 側 4.5 ペタフロップス、GPU 側 69.5 ペタフロップス(テンソル 140 ペタフロップス)、総メモリ 328 TB である。 CPU 専用パーティション(3,072 ノード)はピーク FP64 15.4 ペタフロップス、総メモリ 1,536 TB。 GPU ノードの CPU メモリ帯域は 204.8 GB/s、GPU メモリ帯域は 40GB HBM2 で 1,555 GB/s、80GB HBM2e で 2,039 GB/s である。 スクラッチストレージは 44 PB のオールフラッシュで、集約帯域は読み出し 7.8 TB/s、書き込み 6.6 TB/s、4 KiB ランダムで 400 万 IOPS である (Source: [[@2026__NERSC__Perlmutter Architecture]])。 本ページはアーキテクチャ仕様文書であり、性能評価や限界の議論を含まない (Source: [[@2026__NERSC__Perlmutter Architecture]])。 一方で、この機械は他の研究の評価テストベッドとして繰り返し使われている。 512 台の A100 を用いた GEMM 性能変動の実測では、Tensor Cores で 5.0 から 8.8 パーセント、CUDA Cores で 0.1 から 8.2 パーセントの変動が観測された (Source: [[Perlmutter]])。 ### 16.2 JUPITER 欧州初のエクサスケール機 JUPITER は、ユーリッヒ総合研究機構に設置され、約 6,000 ノード、各ノード 4 基の NVIDIA GH200(システム全体で約 24,000 基)からなる。 2025 年 11 月の TOP500 で一部稼働段階ながら世界 4 位を記録した (Source: [[JUPITER (スーパーコンピュータ)]])。 各 GH200 は Grace ARM CPU(72 コア、120GB LPDDR5X、帯域 500 GB/s)と Hopper GPU(96GB HBM3、帯域 4,000 GB/s)を NVLink-C2C(双方向 450 と 450 GB/s)で結合する。 ノード内の GPU 間は 150 GB/s 双方向、Grace CPU 間は双方向 100 と 100 GB/s。 ノード間は InfiniBand NDR(200 Gb/s すなわち 25 と 25 GB/s)による 25 グループの Dragonfly+ である (Source: [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]], [[JUPITER (スーパーコンピュータ)]])。 ミュンヘン工科大学の Tsai、ユーリッヒ・スーパーコンピューティング・センターの Bode、ミュンヘン工科大学の Anzt は、疎行列線形代数ライブラリをこの構成へ適合させる最適化を報告した。 Roofline 分析では、HBM3 へアクセスする場合の分岐点は演算強度 56 未満がメモリバウンド、CPU 側の LPDDR5X へアクセスする場合は演算強度 1,000 未満までメモリバウンドになる (Source: [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]])。 CPU 側メモリを使うと演算強度の要求が 18 倍近く厳しくなる。 性能上の障害は 2 つあった。 1 つは混合精度の自動変換と複数ベクトル対応のインデックス境界チェックによる命令レイテンシで、ベンダー製ライブラリに対して劣位になる。 もう 1 つは分散 SpMV における GPU-aware MPI のストリーム非対応に起因する CPU 同期のギャップで、SpMV 全体 224 マイクロ秒のうち 54 マイクロ秒(約 24 パーセント)を占めていた。 CUDA イベントで局所 SpMV を先行投入することでギャップは 18 マイクロ秒まで縮み、全体は 186 マイクロ秒(1.2 倍)になった (Source: [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]])。 スケーリングは最大 2,048 ノード(8,192 GH200)まで測定された。 27 点ステンシルでは 2,048 GPU まで並列化効率が約 80 パーセントを保ち、8,192 GPU で約 60 パーセントになる。 局所サイズ 10 の 7 乗、8,192 GPU でのスループットは 27 点が 1.9 ペタフロップス、9 点が 1.4、5 点が 1.2、7 点が 1.0 ペタフロップスである。 世代比較では、局所サイズ 10 の 6 乗の 27 点ステンシルで、ハードウェアのみによる改善が A100 比 1.2 から 1.45 倍、アルゴリズムを含めて 2.4 から 2.7 倍である (Source: [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]])。 著者らは、評価対象が行ごとの非ゼロ要素数が均一な有限差分ステンシル行列に限られ不規則グラフ行列や適応格子行列への汎用性が未検証であること、ソフトウェア環境が未完成の事前製品段階での計測であり最終環境では性能と通信プロトコルの挙動が変わりうること、GMRES が直交化通信の制約で 8 倍の資源増でスケーリングが飽和することを明記している (Source: [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]])。 ### 16.3 次世代 GPU が向かう先 NVIDIA は Rubin GPU を、エージェント型 AI 推論(長い推論ステップ列、低レイテンシ、高デコードスループット、長コンテキストのアテンション、大容量の KV キャッシュ、GPU 間の密結合)へ向けた設計として説明している。 レチクル限界のダイ 2 枚を高速ダイ間リンクで単一パッケージに統合し、3360 億トランジスタ、224 SM、896 テンソルコアを持つ。 HBM4 を最大 288GB 積み、NVLink 6 でスケールアップ帯域 3,600 GB/s、NVLink-C2C でコヒーレント通信 1,800 GB/s、PCIe Gen6 x16 で最大 256 GB/s である (Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。 主張される性能は Blackwell 比でエージェント推論のスループット毎電力が最大 10 倍、第 3 世代の Transformer Engine が NVFP4 で最大 50 ペタフロップスである (Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。 > [!warning] この節の数値はベンダー公表値である > 10 倍という値は内部の 2T MoE ワークロードの計測とされるが、ベンチマーク名と詳細な測定条件は記事に記載がない。 > 50 ペタフロップスという値も条件の記載がない。 > 記事自体が NVIDIA 公式ブログであり第三者検証を経ていない (Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。 > 本書ではこの節の数値を他章の実測値と同じ表に並べない。 なお HBM4 の容量表記には粒度の混同が起きやすい。 Rubin の 288GB はマルチスタック構成の集計値であり、HBM4 の仕様はスタックあたり最大 2 TB/s と 64GB である (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 既存製品の NVIDIA B300 が HBM3E 8 スタックで合計 288GB、帯域 8 TB/s であるため、同じ 288GB という数字が別世代の別構成で現れる (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 --- ## 第 17 章　AI 専用機 ### 17.1 TPUv4 と光回線交換 Google の Zu ら 15 名は、TPUv4 を 4096 チップの 3 次元トーラス型スーパーコンピュータとして報告した。 1 キューブは 4 かける 4 かける 4 の 3 次元メッシュに配置された 64 チップ(16 台の TPU マシンかける 4 チップの 2 かける 2 かける 1 メッシュ)で、1 データセンターラックが 1 キューブに対応する。 1 pod は 64 キューブ、合計 4096 TPU である (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 設計の核心は光回線交換による動的再構成である。 各キューブは X、Y、Z の各次元 6 面に 16 本の光インターコネクトを露出し、キューブあたり 96 リンク、pod 全体で 6,144 本が 48 台の独立した光回線交換機(MEMS ミラー、128 ポート)に接続される。 リンクは片方向 50 GB/s である (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 障害時の経路制御も独自である。 正常時は次元順経路制御、障害時は wild-first routing に切り替える。 オフラインの経路最適化は最大同時流量問題として整数計画に定式化されている (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 効果は規模に対する可用性の形で現れる。 TPUv3 は 1024 チップ手前で可用性が急落するのに対し、TPUv4 は約 3200 チップ(約 50 キューブ、94 パーセント)まで高可用性を維持する。 ![[_attachments/nsdi24-zu/fig01-availability-vs-scale.png]] **図17-1**:チップ数に対する可用性。青の TPUv3 は 1000 チップ手前で 0 まで落ちるのに対し、赤の TPUv4 は耐障害経路制御なしでも約 3200 チップまで 94 パーセント前後を保ち、黄の耐障害経路制御ありでは 100 パーセント近くを維持する。本文が述べた規模と可用性の関係、および耐障害経路制御が効く区間が、3 本の曲線の分離として現れている。 (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]], 図 1) システム可用性は 99.98 パーセントで、訓練ジョブの約 1 パーセントがハードウェア停止の影響を受ける。 2 年間の本番運用データによる日次故障率は、TPU マシンが 0.08 パーセント、インターコネクトケーブルが 0.005 パーセント、光回線交換機が 0.04 パーセントである (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 コストが安いことも重要な主張である。 光回線交換機と光ファイバのコストは pod 総資本コストの 5 パーセント未満、稼働電力も pod 総電力の 3 パーセント未満である (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 耐障害経路制御の性能への影響は小さい。 All-to-all スループットは、4 かける 4 かける 4 構成で正常時 75.9 GB/s が単一の光回線交換機の故障時に 70.0 GB/s(92.2 パーセント)へ下がるが、4 かける 4 かける 8 の twisted 構成では 62.1 から 63.2 GB/s(101.7 パーセント)へ逆に改善する。 代表ワークロードのステップタイム低下率は 0.5 から 8.6 パーセントの範囲である (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 著者らは限界を明記している。 現行の経路制御は静的に事前計算されたフォワーディングテーブルに基づき、ジョブ起動後の動的な負荷分散はできない。 障害発生時はジョブを中断しチェックポイントから再開する設計であり、待機キューブへの直接の移送は将来課題である。 評価は Google 社内の非公開データセットに限られ、外部で再現可能な公開ベンチマークではない (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 ### 17.2 ウェーハスケールとデータフロー ウェーハスケールエンジンは、半導体製造用のシリコンウェーハ全体を個別ダイに切断せず、単一の超巨大プロセッサとして製造し集積する方式である。 スクライブライン上の配線接続によりチップ間境界のボトルネックを解消し、各処理要素は局所 SRAM と 5 方向ルータを持ち、隣接コア間は 2 ナノ秒未満で結ばれる (Source: [[ウェーハスケールエンジン]])。 製造上の工夫が規模を可能にしている。 レチクル限界(約 850 平方ミリメートル)を通常のダイと同じ工程で 84 回(12 かける 7 のグリッド)露光し、900,000 個のデータフローコアと 46,225 平方ミリメートルを 1 枚のシリコンとして機能させる。 欠陥への耐性も高く、H100 では欠陥が約 6 平方ミリメートルの SM 全体を無効化するのに対し、WSE では約 0.05 平方ミリメートルのコア 1 個のみを無効化し、約 7 パーセントの予備コアプールで再マッピングする (Source: [[Cerebras]])。 メモリの扱いが他機と根本的に異なる。 CS-3 はオンチップ SRAM を 44GB 持ち、外部メモリへのアクセスそのものを排除する。 バイト毎フロップス比は約 1.3 で、B200 の約 0.002 と 3 桁近い開きがある (Source: [[Cerebras]], [[AI Chip Architectures]])。 ただし SRAM 密度は WSE-2 から WSE-3 で 10 パーセントしか向上していない(トランジスタ数は 54 パーセント増)ため、微細化による伸びが鈍っている (Source: [[AI Chip Architectures]])。 この構造が科学計算でどう効くかを、Oppelstrup らが 64 台の CS-3 クラスタで示した。 従来の静的な領域分割では、境界の格子点が毎タイムステップごとにノード間遅延の影響を受け、反復速度が遅延の逆数に律速される。 ゴーストセルによる重複法では利用率が多項式で悪化する。 提案手法は、反復ごとに格子点からプロセッサへの写像をステンシル幅だけ平行移動させ、双方向の通信を移動方向への単方向トラフィックに変換して逆方向の転送を消滅させる。 ![[_attachments/arxiv-2511.11542/fig01-stencil-domain-translation-concept.png]] **図17-2**:領域平行移動の概念。横軸が格子点、縦軸が時間ステップで、各升の数字は完了時刻である。(a) の単一ノードでは 1 ステップごとに 1 進むが、(b) の固定分割では境界(青線)をまたぐたびにノード間遅延 10 が加算され、境界付近の完了時刻が 44 まで膨らむ。(c) では分割線を斜めに傾けることで、境界付近でも完了時刻が 14 にとどまる。本文が述べた「遅延を計算で隠蔽する」という機構が、この升目の数字の差として読める。 (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]], 図 1) 隠蔽できる遅延の量はノードが保持する格子点数の 2 乗に比例する (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])。 実行モデルも特殊である。 WSE はフラットな処理要素のグリッドでグローバル同期なしに自律的なデータフローで駆動し、計算平面を時空上で 45 度傾斜させることで全データ移動を時間方向 2 ホップ、空間方向 1 ホップ以内に収める (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]], [[データフローアーキテクチャ]])。 結果として、約 10 マイクロ秒のノード間ネットワーク遅延を完全に隠蔽し、5 点の熱伝導方程式で弱スケーリング 99.9998 パーセント(n=64)、漸近利用率と実測利用率がともに 67 パーセント、9 点では漸近 91 パーセントに対し実測 88 パーセントを得た。 浅水方程式では漸近 56 パーセントに対し実測 53 パーセントである。 電力最適化版(1.2GHz 動作、64 ノード 1,920 億格子点)で 84.7 ペタフロップス、電力効率 57 ギガフロップス毎ジュール、電力制約を外した特別仕様では 112 ペタフロップス相当(ピーク比 88 パーセント)に達する (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])。 著者らは、典型的な地球システムモデルの実効性能がピーク比 5 パーセント未満であり、ペタ級からエクサ級の機械でも実効 1.2 から 8 ペタフロップス毎秒(最高でも 25.96)にとどまるという先行研究の値を比較対象に置いている (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])。 ただし評価対象アプリケーションが異なるため、本書の他章の数値と直接比較することはできない。 未解決の課題も記録されている。 1 ノード約 23 キロワットの電力供給と冷却の制約下で 1.2GHz 超の最大クロックを維持するための動的電力管理と局所的なスロットリング回避の自動化には限界があり、単一ウェーハ内の高効率なデータフロー実行からマルチウェーハクラスタへの自動コンパイルとパーティショニングのツールチェーンの汎用性も開いている (Source: [[ウェーハスケールエンジン]])。 非構造格子や不規則な疎行列計算へ領域平行移動を一般化できるか、ウェーハ規模を超える超大規模クラスタでの局所的な自己修復と耐障害性のデータフローモデルをどう設計するかも未解決である (Source: [[データフローアーキテクチャ]])。 ### 17.3 オープン Ethernet という選択 SAKURA internet Research Center の Konishi、Tsubouchi、Tsuruta は、ISC 2025 の TOP500 上位 100 位で唯一フルオープンなネットワーキングスタック(800GbE と SONiC)を採用したシステムとして SAKURAONE を報告した (Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 構成は計算ノード 100 台、各ノードに Intel Xeon Platinum 8580+ を 2 基(計 12,000 コア)、DDR5 1.5TB、NVIDIA H100 SXM 80GB を 8 基(計 800 GPU)、ローカル NVMe 7.68TB を 4 本持つ。 インターコネクトは rail-optimized な leaf-spine で、800GbE(2 かける 400GbE)、RoCEv2、Broadcom Tomahawk 5(51.2 Tb/s)を積むスイッチ上で SONiC を運用する。 共有ストレージはオールフラッシュの Lustre 2PB である (Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[SAKURAONE]])。 設計上の判断として、NIC と GPU のアフィニティをプロファイルし、一部の NIC を集団通信、残りをストレージ専用に分離している。 輻輳制御は ECN と PFC をベンダー検証値に調整した (Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 ベンチマークの実測は次のとおりである。 HPL は 784 GPU で 33.95 ペタフロップス毎秒(GPU あたり 43.31 テラフロップス毎秒)、単一 GPU のピーク GEMM 55.34 テラフロップス毎秒に対し GPU あたり効率は約 78.3 パーセント。 HPCG は 784 プロセスで 396,295 ギガフロップス毎秒、観測ピークメモリ帯域 3.316 TB/s。 HPL-MxP は 768 GPU の Sloppy FP8 で 339.86 ペタフロップス毎秒である (Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 運用観測も本書にとって価値が高い。 単一テナント運用(2024 年 12 月から 2025 年 3 月)の観測では、CANCELLED になったジョブが GPU 時間の 73.5 パーセントを占め、FAILED は件数で 16.9 パーセントだが GPU 時間では 0.3 パーセントにとどまる。 全ジョブの 76.9 パーセントが単一ノード、86.4 パーセントが 4 ノード以下だが、それらが消費する GPU 時間は 1.8 パーセントと 4.6 パーセントにすぎない。 17 ノード以上のジョブは件数で 3.3 パーセントながら GPU 時間の 73.3 パーセントを消費する。 GPU 利用率の中央値は 17 から 32 ノードのジョブで 98.4 パーセント、1 ノードと 2 ノードのジョブで 23.4 パーセントと 17.7 パーセントである。 3 か月で障害は 21 件、GPU 関連が 42.9 パーセントで最多である (Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 著者らは、単一テナントかつ単一プロジェクトのためスケジューリングとキューイングの観測をマルチテナントへ一般化することが限定的であること、MLPerf の結果が非公式かつ未検証であること、ECN と PFC の計測が 60 秒解像度のため秒未満の集団通信バーストを平滑化しピークを過小評価しうること、ECN のマーキング率と PFC の pause カウンタが観測期間中に未収集で帯域の輻輳への帰属ができないこと、平均故障間隔と平均復旧時間がタイムスタンプの不正確さのため非報告であることを明記している (Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 --- ## 第 18 章　現代機の横断比較 第 14 章から第 17 章で扱った機械を、第 1 章の座標系に配置する。 ### 18.1 ノード構成 | 機械 | ノード数 | ノードあたりの計算 | メモリ | 結合網 | |---|---|---|---|---| | Fugaku | 158,976 | A64FX 1 基(48+4 コア、SVE 512 ビットかける 2) | HBM2 32 GiB、DDR なし | Tofu-D、6 次元メッシュとトーラス、注入 40.8 GB/s | | Frontier | 9,472 | EPYC 7A53 1 基 + MI250X 4 基(GCD 8) | DDR4 512 GiB + HBM2e(GPU 総帯域 13.08 TB/s) | Slingshot、3 ホップ Dragonfly、80 グループ | | Aurora | 10,624 | Xeon Max 2 基 + Ponte Vecchio 6 基 | CPU 側 HBM2e 64GB + DDR5、GPU 側 HBM | Slingshot、1 次元 Dragonfly、175 グループ、NIC 8 基 | | El Capitan | 11,520 | MI300A 4 基(APU、各 24 コア + 228 CU) | HBM3 512 GiB(CPU と GPU で共有) | Slingshot、Dragonfly、200GbE かける 4、注入 100 GB/s | | Perlmutter(GPU) | 1,792 | EPYC 7763 1 基 + A100 4 基 | DDR4 256GB + HBM2 か HBM2e | Slingshot 11、3 ホップ Dragonfly、NIC 4 基 | | JUPITER | 約 6,000 | GH200 4 基(Grace 72 コア + Hopper) | LPDDR5X 120GB + HBM3 96GB(GH200 あたり) | InfiniBand NDR、25 グループ Dragonfly+ | | TPUv4 | 4,096 チップ | TPU チップ(64 チップで 1 キューブ) | 記載なし | 3 次元トーラス、光回線交換、リンク片方向 50 GB/s | | SAKURAONE | 100 | Xeon Platinum 8580+ 2 基 + H100 SXM 8 基 | DDR5 1.5TB + HBM | 800GbE、RoCEv2、rail-optimized leaf-spine | | Cerebras CS-3 クラスタ | 64 | WSE-3(90 万コア) | オンチップ SRAM 44GB | 100Gbps ポート 12 本、Ethernet スイッチ群で全結合 | 出典は各章に記したとおりである (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]], [[@2023__SC__Frontier - Exploring Exascale]], [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]], [[@2026__LLNL HPC__El Capitan Hardware Overview]], [[@2026__NERSC__Perlmutter Architecture]], [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]], [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])。 ### 18.2 座標系への配置 | 機械 | 軸 A 並列性 | 軸 B メモリ | 軸 C 結合網 | 軸 D 目標関数 | 軸 E 用途 | |---|---|---|---|---|---| | Fugaku | ベクトルと超並列の融合 | HBM のみ | トーラス | 電力予算内の実効性能 | 科学計算中心、混合精度も | | Frontier | アクセラレータ混在 | 分離メモリ、GPU 側 HBM | Dragonfly | 電力あたり性能 | 科学計算 | | Aurora | アクセラレータ混在 | CPU 側にも HBM | Dragonfly | 3 領域の同格支援 | 科学計算と AI の両方 | | El Capitan | アクセラレータ統合(APU) | 統合 HBM | Dragonfly | ピーク性能と密度 | 科学計算 | | Perlmutter | アクセラレータ混在 | 分離メモリ | Dragonfly | 汎用性 | 科学計算と AI の混在 | | JUPITER | アクセラレータ混在(密結合) | LPDDR5X と HBM3 の階層 | Dragonfly+ | 実効性能 | 科学計算 | | TPUv4 | ドメイン固有 | 記載なし | 光回線交換トーラス | 規模に対する可用性 | AI | | SAKURAONE | アクセラレータ混在 | 分離メモリ | Ethernet | 調達の開放性 | AI | | Cerebras CS-3 | データフローとウェーハスケール | SRAM 常駐 | Ethernet 全結合 | 実効利用率 | 科学計算と AI の両方 | ### 18.3 数値を並べるときの制約 > [!warning] 本章の表に性能値を並べていない理由 > 各機械の性能値は評価条件が揃っていない。 > Fugaku の 442 ペタフロップスは FP64 の HPL、2 エクサフロップスは HPL-AI の混合精度である (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 > Aurora の 1.012 エクサフロップス毎秒は 9,234 ノード(約 87 パーセント)での HPL、11.64 エクサフロップス毎秒は 9,500 ノードでの HPL-MxP である (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 > El Capitan の 2,889.2 ペタフロップス毎秒は理論ピークであり実測ではない (Source: [[@2026__LLNL HPC__El Capitan Hardware Overview]])。 > Cerebras の 84.7 ペタフロップスはステンシル計算の実測である (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])。 > ベンチマークの種類、精度、使用ノード比率、ピークか実測かが異なる値を同じ列に並べると、順位が意味を持つかのように読めてしまう。 > 比較が必要なときは、同一ベンチマークかつ同一精度の値どうしに限る。 ### 18.4 世代をまたぐ 3 つの収斂 第 III 部の 9 台を並べると、設計の収斂が 3 つ見える。 第 1 に、メモリ帯域を中心に据える設計である。 A64FX が DDR を積まず HBM2 で 1,024 GB/s を確保し (Source: [[A64FX]])、GH200 が HBM3 で 4,000 GB/s を持ち (Source: [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]])、次世代 GPU が HBM4 で 22 TB/s を主張し (Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])、Cerebras は外部メモリアクセスそのものを排除する (Source: [[ウェーハスケールエンジン]])。 手段は異なるが、演算器を飽和させる帯域の確保という目的は共通する。 この追求が HBM を AI チップ製造費の約 45 パーセントを占める高コスト要素にしているという緊張も、同時に記録しておく必要がある (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 第 2 に、CPU と GPU の距離を縮める方向である。 Frontier は別パッケージの CPU と GPU を xGMI で結んだ (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 El Capitan は同一パッケージ内で HBM3 を共有しゼロコピーでロードとストアができる (Source: [[@2026__LLNL HPC__El Capitan Hardware Overview]])。 JUPITER は NVLink-C2C で CPU と GPU をコヒーレントに結合する (Source: [[@2026__HPCAsia__What Will the Grace Hopper-Powered Jupiter Supercomputer Bring for Sparse Linear Algebra?]])。 第 6 章で見た、アクセラレータとホストを結ぶノード内の接続が繰り返し律速になるという問題への、3 世代にわたる回答である。 第 3 に、ネットワーク遅延と障害を実効性能の支配要因とみなす設計である。 TPUv4 は光回線交換の動的再構成と耐障害経路制御でリンク障害という空間的な問題に対処し (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])、Cerebras の領域平行移動はネットワーク遅延という時間的な問題に対処する (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])。 機構は全く異なるが、大規模分散システムでは通信の遅延と障害が実効性能を支配するという問題意識は共通している。 --- ## 第 IV 部　展望 --- ## 第 19 章　HPC と AI の収束と分岐 ### 19.1 同じ機械の上で走る 2 種類の仕事 HPC センターの実運用ワークロードは、すでに汎用計算と機械学習の混在になっている。 VU Amsterdam の Chu と TU Wien の Hofstätter らは、国家規模の本番 HPC データセンターの 10 か月分のジョブデータと 5 か月分のノードデータを結合した約 9,400 万行を解析し、非対称な消費構造を示した。 機械学習のジョブはクラスタ全体のノード数の 15 パーセント、投入件数の 9.28 パーセントにすぎないが、エネルギー消費の 38.68 パーセントを占める (Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]])。 ![[_attachments/arxiv-2409.08949/fig01-generic-vs-ml-summary.png]] **図19-1**:汎用ジョブと機械学習ジョブの、ラック数、ノード数、投入件数、失敗件数、実行時間、消費エネルギーにおける割合。上から下へ見ると、機械学習(赤)の占める幅が投入件数と実行時間では小さいのに、最下段のエネルギーでは大きく広がる。本文が述べた「件数 9.28 パーセントに対しエネルギー 38.68 パーセント」という非対称が、この最下段と上段の幅の差にあたる。 (Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]], 図 1) ジョブの性質も異なる。 機械学習ジョブの中央値ランタイムは 6.48 分で、汎用の 24 秒の約 16 倍である。 平均ランタイムは 2.71 時間と 0.83 時間、平均待機時間は 1.84 時間と 4.21 時間である。 キャンセル率は汎用 4 パーセントに対し機械学習 13 パーセントと高い (Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]])。 設備側の不整合も観測されている。 GPU ノードのラック合計 TDP(CPU 1,050 ワットと GPU 5,600 ワットで 6,650 ワット)が冷却設計容量 5,500 ワットを恒常的に超過しており、GPU 温度が 17.4 パーセントの時間で 90 パーセント超になる熱スロットリングのリスクがある。 スケジューラが 24 コアの GPU ノードから機械学習ジョブへ平均 6.81 コアしか割り当てない構成のため、GPU の高い電力消費に対し CPU 資源が過小に配分される非対称が生じている (Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]])。 もう 1 つ、エネルギーの行き先として見逃せない事実がある。 クラスタ全体のエネルギーの約 50 パーセントが、失敗、タイムアウト、メモリ不足、ノード障害といった未完了のジョブに消費されている (Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]])。 SAKURAONE の観測でも、CANCELLED になったジョブが GPU 時間の 73.5 パーセントを占めている (Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 2 つの独立した本番環境が、完了しない仕事に資源の大半が流れる構造を示している。 著者らは、単一データセンターからの知見であり他システムへの適用には注意が必要なこと、相関は認められるが因果の確定には追加分析が必要なこと、プライバシー制約により同一利用者による同時投入という仮説を検証できなかったこと、GPU 世代が新しい世代ではないため追試が必要なことを明記している (Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]])。 ### 19.2 ワークロードを分類するという試み University of Wisconsin-Madison の Jain、Jiang、Sinclair、Venkataraman は、GPU ワークロードを電力スパイク分布の階層的クラスタリングと利用率の K-Means で分類し、未見のワークロードの周波数キャッピング挙動を予測する手法を示した。 瞬間電力が TDP の半分以上のサンプルをスパイクとし、相対振幅をビン分割した正規化ヒストグラムをコサイン距離でクラスタリングする。 カーネルの DRAM と SM のスループットを実行時間で重み付き平均した 2 次元点を K-Means で計算密集、メモリ密集、ハイブリッドの 3 つに分ける (Source: [[@2026__POMACS__Minos - Systematically Classifying Performance and Power Characteristics of GPU Workloads on HPC Clusters]])。 未見ワークロードは既定クロックで 1 回だけプロファイリングし、電力の最近傍と性能の最近傍の周波数スケーリング曲線を転用することでスイープを回避する。 18 ワークロードの hold-one-out 評価で、p90 電力の予測誤差は平均 4 パーセント、性能の予測誤差は平均 3 パーセントであり、平均電力ベースの先行手法の平均誤差 14 パーセントから約 10 ポイント改善した。 未見ワークロードのプロファイリング時間はそれぞれ 90 パーセントと 89 パーセント削減される (Source: [[@2026__POMACS__Minos - Systematically Classifying Performance and Power Characteristics of GPU Workloads on HPC Clusters]])。 方法論上の注意も示されている。 同一アプリケーションでも入力サイズや実装の差でクラスが変わりうるため、クラス内の任意メンバーではなく最近傍を使う必要がある (Source: [[@2026__POMACS__Minos - Systematically Classifying Performance and Power Characteristics of GPU Workloads on HPC Clusters]])。 この観察は、第 11 章で見た Titan の知見、すなわち過去の性能や監視情報からファイルシステム内の良い場所を予測するのは難しいという結論と、同じ方向を向いている (Source: [[@2020__TOS__Characterizing Output Bottlenecks of a Production Supercomputer Analysis and Implications]])。 静的な事前分類と履歴予測には限界があり、実行時の直近のシグナルに頼らざるをえない。 著者らは、周波数キャップの定量評価が AMD MI300A に限られること(NVIDIA 側は管理者権限が不足)、参照集合の被覆が薄い領域では最近傍距離が伸び誤差が増えること、利用率定義のベンダー差により AMD と NVIDIA を横断する直接比較を実施していないこと、予測が近傍のスケーリング曲線への転用であって物理モデルではないことを明記している (Source: [[@2026__POMACS__Minos - Systematically Classifying Performance and Power Characteristics of GPU Workloads on HPC Clusters]])。 ### 19.3 ワークロードによるアクセラレータ選択の逆転 UIC の Brunetta、Argonne National Laboratory の Sastry、Wu、Taylor、Papka、UIC の Lan は、6 基の GPU と 2 基のデータフローアクセラレータを 14 種の LLM で比較した (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 データフローアクセラレータは小バッチで圧倒的に速い。 Llama 3.1 8B のバッチサイズ 1、bfloat16 で、Cerebras CS-3 が毎秒 3,609 トークン(A100 比 16.8 倍)、SambaNova SN40L が 2,024 トークン(9.41 倍)、A100 が 215 トークンである。 CS-3 のトークン間レイテンシは A100 比 18.8 倍短い (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 ところがエネルギー効率では順位が逆転する。 1 ジュールあたりのトークン数は CS-3 が 0.15、SN40L が 0.38、A100 が 0.73、H100 が 0.91 である。 消費電力は CS-3 が 24,200 ワット、SN40L が 5,230 ワット、A100 が約 337 ワットである (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 機構は説明されている。 データフローは全データを SRAM のスクラッチパッドに収めることで HBM 帯域のボトルネックを回避し、メモリバウンドであるデコードフェーズに強い。 一方、計算バウンドであるプリフィルフェーズの改善は限定的で、最初のトークンまでの時間の改善は CS-3 で 35 パーセント、SN40L で 20 パーセントにとどまる (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 並列化の選び方でも結果が変わる。 3 ノードの比較では、データ並列がほぼ線形にスケールするのに対し、テンソル並列は all-gather の通信オーバーヘッドで最大 60 パーセントの効率にとどまる。 Mixtral 8x22B ではテンソル並列がエキスパート並列の 1.61 倍から 2.7 倍のスループットを示した (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 著者らは、データフロー機のバッチサイズ制約により GPU との公平な比較が困難な部分があること、電力測定の粒度がハードウェア間で異なること(NVIDIA と AMD が 0.5 秒、Intel が 1.9 秒平均、Cerebras が系統レベル、SambaNova が RDU レベル)、量子化の精度損失評価が未実施であることを明記している (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 同じ Cerebras CS-3 が、科学技術シミュレーションのステンシル計算では電力効率 57 ギガフロップス毎ジュールという高い値を示し (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])、LLM 推論では 1 ジュールあたり 0.15 トークンで GPU を下回る (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 単位が異なるため直接比較はできないが、「このアクセラレータのエネルギー効率」という言明が指す対象が文脈依存であることは、2 本を並べて初めて見える。 ### 19.4 巨大な機械はまだ要るのか AI 側から、大規模スーパーコンピュータの必要性そのものを疑う議論が出ている。 VAST Data の Lockwood は、フロンティア級 AI モデルの前進にもはや超大規模スーパーコンピュータは必須ではなく、業界が「大きくする」から「賢くする」へ転換したと論じる。 根拠として、超大規模クラスタで訓練されたモデルが、新品のハードウェアを本番規模のテスト不足のまま投入したため前例のない障害モードに悩まされ専門家の 24 時間体制の監視を要したこと、競合の推論モデルが小規模な旧式のスーパーコンピュータで比較可能な成果を出したことを挙げる (Source: [[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]])。 著者は超大規模システムに残る価値を 3 点に絞る。 速度(1 万 GPU で 1 か月かかる訓練が 10 万 GPU では 3 日)、リスクの低減、運用負担の軽減である (Source: [[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]])。 この記事は個人の見解であり実証論文ではないこと、数値の多くに評価条件と出典の記載がないことを、記事自身とページのメタデータが明記している (Source: [[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]])。 本書としては、この主張が LLM のフロンティアモデル開発における必須性という限られた論点を扱っており、科学計算や中規模運用の事例と同じ層の議論ではないと整理する。 同じ著者による別の報告は、逆方向の可能性も示している。 中国の全 CPU(Arm)スパコンが Top500 で首位を獲得し、GPU なしでも HPC の先頭に立てることを示した。 その LX2 プロセッサはデュアルダイ構成で、各ダイが I/O チップレット、コアクラスタチップレット、HBM コントローラ、DDR コントローラ、800G NIC を個別に持つ。 ARMv9 の行列拡張は各スレッドに専用のタイルレジスタを持たせるため小さい行列でも効率が落ちにくいが、GPU の行列コアほど FLOPS あたりのエネルギー効率は高くないと著者は推測している。 各 CPU に HBM と DDR を接続し、専用 DMA エンジンで HBM を DDR 用の大容量キャッシュとして機能させる設計である (Source: [[@2026__Glenn K. Lockwood Blog__ISC26 Recap]])。 ただし著者自身が、製造プロセスと HBM 規格と DDR 規格が揃って公表されていないこと、この機械が非商用の一点ものであり経済性を度外視できたからこそ可能になったため CPU の経済的将来性の指標としては不適切であることを結論している (Source: [[@2026__Glenn K. Lockwood Blog__ISC26 Recap]])。 同じ著者が示す論点として、もう 1 つ重要なものがある。 AI の推論におけるメモリ帯域幅の問題は、ハードウェアの新設計を待つよりも早く、ソフトウェアとアルゴリズムの進歩によって解決されたという指摘である。 HBM 搭載 CPU が発表から出荷まで 7 四半期を要した同じ期間に、4 つの根本的な推論アルゴリズムの進歩が生まれたことを対比している (Source: [[@2026__Glenn K. Lockwood Blog__ISC26 Recap]])。 ハードウェア主導の将来設計が的外れになりうるという警告として読める。 --- ## 第 20 章　批判と限界 ### 20.1 2008 年の予測はどれだけ外れたか 本書で最も明確な検証可能な予測は、DARPA ExaScale Computing Study が 2008 年に出した電力の見積もりである。 第 7 章と第 8 章は、積極設計のストローマンでも 1 エクサフロップスに 67.7 メガワットを要し、20 メガワットの枠ではシリコンの最良で約 303 ペタフロップス(1 エクサフロップスの約 30 パーセント)にとどまるとし、20 メガワット未満は不可能と結論した (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]], [[@2008__DARPA__ExaScale Computing Study - Chapter 8 Exascale Challenges and Key Research Areas]])。 実機は Frontier が HPL 1.1 エクサフロップスを 21.1 メガワットで達成した (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 予測は電力を約 3 倍過大に見積もったことになる (Source: [[エクサスケール]])。 ただしこの比較には留保が要る。 報告書は積極設計を ECC、クロック配信、冗長化を含まない最良ケースとして位置づけており、目標もメモリとストレージの容量の 1,000 倍を含む資源面の定義だった (Source: [[エクサスケール]], [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]])。 HPL の電力効率だけで単純に比較すべきではない。 予測が当たった側面もある。 並行性については、報告書が 10 億並列を必須とし、ストローマンが傾向線より約 5 年早くそれを要求すると述べた (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 8 Exascale Challenges and Key Research Areas]])。 第 1 章がデータセンター級で 10 億本超の別々のスレッドを支える必要が出うるとした予測とも符合する (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 1 Executive Overview]])。 局所性とハードウェアの傾向の乖離という指摘は、第 8 章で見た現代のメモリバウンドな AI ワークロードの構造と同じ形をしている。 耐障害性の予測は、むしろ悲観が的中している。 報告書は 22 万ソケットで平均中断間隔が約 24 分、故障率が 10 倍改善しても約 4 時間と見積もった (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 6 Technology Roadmaps]])。 Frontier の論文はレジリエンスがこの投影をあまり上回らず、原因がメモリと電源にあり、長期には 8 時間から 12 時間へ改善する見込みとするにとどめている (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 ### 20.2 エクサスケールの定義の変遷 2008 年の定義は、HPL の 1 エクサフロップスだけでなく、主記憶 10 PB 以上、持続ストレージ 10 の 18 乗バイト、局所メモリ帯域約 1 EB/s を含む多属性の 1,000 倍だった (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 2 Defining an Exascale System]])。 2020 年代の実機評価は、HPL の FLOPS 基準か、DOE の実アプリケーション高速化 50 倍という基準へ読み替えられている (Source: [[エクサスケール]])。 多属性の基準が、狭義の FLOPS 基準へ収斂したことになる。 この収斂が生む混乱が、精度の扱いである。 Fugaku の 2 エクサフロップスは HPL-AI すなわち混合精度の値であり、FP64 の HPL は 442 ペタフロップスにとどまる (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 Aurora の HPL-MxP 11.64 エクサフロップス毎秒も、LU 分解が FP16 と FP32、反復改善が FP64 という混合精度である (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 第 7 章で見た混合精度反復精密化が、性能指標の側でも定義を揺らしている (Source: [[@2018__SC__Harnessing GPU Tensor Cores for Fast FP16 Arithmetic to Speed up Mixed-Precision Iterative Refinement Solvers]])。 ### 20.3 HPL という指標への批判 HPL が実アプリケーションを代表しないという批判は、DARPA 報告の内部からすでに出ていた。 第 5 章は、フロップスとメモリを 1024 倍にすると WRF が約 180 倍、AVUS が 50 倍未満にとどまるのに対し、HPL だけはピークで約 900 倍まで伸びることを示し、これを「病的に無意味」と評している (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 5 Exascale Application Characteristics]])。 実効率の実測もこの批判を裏づける。 典型的な地球システムモデルの実効性能はピーク比 5 パーセント未満であり、ペタ級からエクサ級の機械でも実効 1.2 から 8 ペタフロップス毎秒にとどまる (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]])。 一方 Fugaku の HPL 442 ペタフロップスは理論ピーク 537 の約 82 パーセントである (Source: [[@2022__IEEE Micro__Co-Design and System for the Supercomputer Fugaku]])。 同じ機械が、ベンチマークによって桁の違う実効率を示す。 各施設が HPL とは別の基準を併用しているのは、この批判への実務的な対応である。 Frontier は CAAR で Summit 比 4 倍、ECP で約 20 ペタフロップス機比 50 倍を目標とし (Source: [[@2023__SC__Frontier - Exploring Exascale]])、Aurora も 20 ペタフロップスに正規化した基準機に対する 50 倍を目標とした (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 2 つの施設が共通の 50 倍という目標値を用いていることは、エクサスケール調達プログラムが複数施設で共通の基準を課していたことを示す。 ただし基準機の性能値の表現が両者で微妙に異なるため、厳密な同一性は確認できない。 ### 20.4 数値の信頼性という横断的な問題 本書を通じて、引用する数値の信頼性に 3 種類の劣化が見られた。 第 1 に、一次文献の内部不整合である。 DARPA 報告は各章に自己申告の不整合注記を多数抱えており (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]])、Roadrunner 論文は結論部の倍率が図の最良値と一致せず (Source: [[@2008__SC__Entering the Petaflop Era - The Architecture and Performance of Roadrunner]])、Aurora 論文は表と本文でバイセクション帯域の値が異なる (Source: [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])。 CRAY-1 論文でも入出力チャネル数が本文と表で食い違っている (Source: [[@1978__CACM__The CRAY-1 Computer System]])。 第 2 に、文献間での表記粒度の不一致である。 Blue Gene/L のリンク帯域は一次記述と教科書で粒度が異なり (Source: [[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]], [[IBM Blue Gene／L]])、Infinity Fabric の帯域は 3 つの文献で片方向か双方向かの明示がないまま異なる値が並ぶ (Source: [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]], [[@2026__LLNL HPC__El Capitan Hardware Overview]], [[@2024__ISCA__Realizing the AMD Exascale Heterogeneous Processor Vision]])。 第 3 に、引用の連鎖による評価条件の逸失である。 第 7 章で述べたとおり、TPU v1 の性能は教科書、Turing 賞講演版、ウェブ記事と引用されるたびに加重条件が削られていった (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]], [[@2019__CACM__A New Golden Age for Computer Architecture]], [[AI Chip Architectures]])。 ベンダー公表値の扱いにも注意が要る。 AMD の産業論文は評価が少数のワークロードに限られ独立検証がないことを著者自身が認め (Source: [[@2024__ISCA__Realizing the AMD Exascale Heterogeneous Processor Vision]])、次世代 GPU の記事は主要な数値のベンチマーク名と測定条件を欠く (Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。 AI チップの比較表についても、記事自身が推定値と未公表値のマーカーの多さを認めている (Source: [[AI Chip Architectures]])。 ### 20.5 批判への再批判 ここまでの批判に対しては、2 つの反論も成り立つ。 第 1 に、HPL が無意味なのではなく、HPL だけを見ることが無意味である。 HPL は時間局所性がほぼ最大の点として、STREAM や small RA とともにアプリケーションの分布の端を定義する参照点になっている (Source: [[局所性]])。 参照点としての価値と、単独指標としての限界は別の話である。 第 2 に、2008 年の予測が電力を 3 倍過大に見積もったことは、予測の方法が誤っていたことを必ずしも意味しない。 報告書自身が、DRAM の再設計は技術的に可能でもコスト重視の商用市場が自発的には起こさないと述べていた (Source: [[@2008__DARPA__ExaScale Computing Study - Chapter 7 Strawmen - Where Evolution Is and Is Not Enough]])。 実際に起きたのは、AI 需要という外部要因が HBM の市場を作り、第 8 章で見たような投資が正当化されたことである (Source: [[@2026__RAND__High Bandwidth Memory - What It Is and Why It Matters]])。 外挿は技術的に正しくとも、需要の構造変化を織り込めない。 この点は、ハードウェア主導の将来設計が的外れになりうるという第 19 章の指摘と同じ構造をしている (Source: [[@2026__Glenn K. Lockwood Blog__ISC26 Recap]])。 そもそも教科書自身が、あらゆる指数則はいつか終わるという一般則を、Dennard スケーリング、磁気ディスクの面密度、ムーアの法則の 3 つの実例で自己批判的に示している。 業界ロードマップの 2013 年版予測(2028 年に 5nm)が 2015 年の最終版で 2021 年に 10nm 頭打ちへ下方修正されたことも、予測の限界の具体例として挙げられている (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 1 Fundamentals of Quantitative Design and Analysis]])。 --- ## 第 21 章　未解決の問い 本書を書き終えて、wiki のソースからは答えが出なかった問いを列挙する。 次の ingest の対象を選ぶための作業リストである。 - **メモリと演算のどちらが先に律速するかの一般則。** 世代横断のトレンドではメモリが律速に向かうと示され (Source: [[@2024__IEEE Micro__AI and Memory Wall]])、同世代の 2 機種比較では帯域を上げると命令スループットが律速になると示された (Source: [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]])。 両者は分析の対象が異なるため直接は矛盾しないが、どの条件でどちらが先に飽和するかを統一的に述べる枠組みは、wiki のソースからは確認できない。 - **データフローとウェーハスケールの一般性。** 本書で軸 A のこの値を支えるのは Cerebras に関する 2 本のみである (Source: [[@2026__HPCAsia__Beyond Exascale - Dataflow Domain Translation on a Cerebras Cluster]], [[Cerebras]])。 SambaNova を扱うソースはあるが LLM 推論の比較にとどまる (Source: [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。 領域平行移動を非構造格子や不規則な疎行列へ一般化できるか、単一ベンダー以外の実装で同じ利用率が出るかは検証されていない (Source: [[データフローアーキテクチャ]])。 - **Fugaku 級の機械における実運用ワークロードの実測。** 本書が引けた実運用ワークロードの解析は、中規模の欧州センターと 800 GPU 規模の AI クラスタである (Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 10 万ノード級の機械で、汎用と機械学習のエネルギー配分や未完了ジョブの比率が同じ構造を示すかは wiki のソースからは確認できない。 - **エクサスケール機のレジリエンスの定量データ。** Frontier の論文はレジリエンスに定量データがなく電源対策が計画段階であると明記している (Source: [[@2023__SC__Frontier - Exploring Exascale]])。 TPUv4 は 2 年間の本番故障率を公開しているが、評価が社内の非公開データセットに限られる (Source: [[@2024__NSDI__Resiliency at Scale - Managing Google's TPUv4 Machine Learning Supercomputer]])。 公開されたエクサスケール機の故障率と平均中断間隔の実測は、本書の母集団には無い。 - **CPU と GPU の間の電力配分の切り分け。** MI300A の測定では、監視が APU 全体の合算値しか取得できないため、CPU と GPU の間の電力シフト量を定量的に切り分けられない (Source: [[@2026__HPCA__GPU Partitioning, Power, and Performance of the AMD MI300A]], [[動的電力共有]])。 統合メモリ型の APU が主流になるとき、この観測の死角は設計判断の根拠を弱める。 - **通信ライブラリの選択を自動化できるか。** 最適なライブラリがスコープと操作種別とメッセージサイズで系統的に逆転することは実測されている (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]], [[@2025__MemSys__Inter-APU Communication on AMD MI300A Systems via Infinity Fabric - A Deep Dive]])。 既定設定が最適から程遠く手動チューニングで最大 1 桁の差が出ることも示された (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 この選択を実行時に自動化する仕組みが実運用で機能するかは、wiki のソースからは確認できない。 - **Ethernet が大規模集団通信で専用網に追いつくか。** 32 KiB 以上の点対点では差が 4 パーセント未満に収まるが、128 MiB の AllToAll では Ethernet が 58 パーセント、InfiniBand が 81 パーセントと開く (Source: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])。 この差の原因は著者らも特定できていない。 - **協調設計の対象が運用時へ移ったことの評価。** 設計時の協調設計(Fugaku)と運用時の動的最適化(TPUv4、現行 GPU)を同じ方法論として比較評価した文献は、本書の母集団には無い (Source: [[協調設計]])。 - **HPL 以外の共通指標。** 施設ごとに実アプリケーションの高速化目標が設定されているが (Source: [[@2023__SC__Frontier - Exploring Exascale]], [[@2025__arXiv__Aurora - Architecting Argonne's First Exascale Supercomputer for Accelerated Scientific Discovery]])、基準機の定義が揃っておらず、施設をまたいで比較できる形にはなっていない。 標準化されたベンチマークスイートの必要性は指摘されているが (Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Chapter 7 Domain-Specific Architectures]])、本書の母集団にはその成果物が無い。 --- ## 関連 - 概念: [[スーパーコンピュータ]] / [[エクサスケール]] / [[ベクトルプロセッサ]] / [[クラスタコンピューティング]] / [[ヘテロジニアスコンピューティング]] / [[メモリウォール]] / [[データ移動エネルギー]] / [[協調設計]] / [[ドラゴンフライトポロジ]] / [[集合通信]] / [[並列ファイルシステム]] / [[ウェーハスケールエンジン]] / [[データフローアーキテクチャ]] - 姉妹ページ: [[ホストネットワークとインターコネクトの教科書]](ノード内部の PCIe、NVLink、CXL の詳細を担う) / [[AIデータセンターファシリティの教科書]](電力と冷却の設備工学を担う) / [[LLM学習インフラ実運用の教科書]](LLM 学習の並列化と障害対応の運用を担う) / [[RDMAネットワークモニタリングの教科書]](RDMA の計装点と監視手法を担う) - MOC: [[structures/000 Index.md]]