- GPU は現代の 機械学習 において中核的な役割を担っており、高速な行列積演算に特化した多数の Streaming Multiprocessors(SMs) と HBM（高帯域幅メモリ） が組み合わさった構造である
- GPU の SM は Tensor Core（行列積）と CUDA Core（ベクトル演算）に分かれており、大規模な並列演算と柔軟なプログラミングを支える
- GPU と TPU は内部構造やネットワーク構成の面で違いがあり、GPU は 汎用性 と 拡張性 が高い一方、最適な性能を引き出すにはより多くの考慮が必要である
- ノード（Node）内では NVLink および NVSwitch により GPU 間の超高速通信が可能であり、ノード間は InfiniBand などのネットワークで接続され、大規模な分散学習に対応する
- GPU における 集団演算（Collectives）（例: AllReduce、AllGather など）は、ハードウェア構造やネットワーク階層によって性能が大きく変わり、理論上の帯域幅より実効値は低くなる傾向がある
GPUとは何か？
- 最新の ML（機械学習）GPU（例: H100、B200）は、行列積演算に特化した数十〜数百個の Streaming Multiprocessor(SM) と高速な HBM メモリ を組み合わせた構成である
- 各 SM には Tensor Core（行列積）、Warp Scheduler（ベクトル演算）、SMEM（オンチップキャッシュ）がある
- TPU と異なり、GPU は 100 個以上の SM によって、より柔軟で大規模な並列処理が可能である
SM の詳細構造
- SM は 4 つの サブパーティション に分かれ、各サブパーティションにはそれぞれ Tensor Core、CUDA Core（ベクトル演算）、Warp Scheduler、レジスタファイル などが存在する
- CUDA Core はベクトル算術演算（SIMD/SIMT）を担当し、Tensor Core は行列積に特化している
- Tensor Core の FLOPs は圧倒的に大きく、低精度演算では処理速度がさらに向上する
- 最新 GPU（例: B200）では大型の TMEM が追加され、大容量の Tensor Core 入力をサポートする
CUDA Core の柔軟性
- GPU の CUDA Core は SIMT（Single Instruction Multiple Threads）モデルを用い、1 つの命令を複数のスレッドに並列実行する
- 各スレッドは独立した命令ポインタ（プログラムカウンタ）を持ち、条件分岐などの柔軟性を提供するが、ワープ内の命令分岐（divergence）が多いと性能低下が生じる
- 各 CUDA Core は個別の状態とメモリアクセスの自由度を持つ（TPU は連続したメモリしか扱えない）
スケジューリング/並列性
- SM は多数の ワープ（最大 64 個）をスケジューリングして同時実行し、各ワープスケジューラは一度に 1 つのプログラムを実行する
- この構造により、GPU はかなり柔軟でありながら高い同時処理能力を実現する
GPU メモリ構造
- GPU では HBM が最も大きく、そのほかにも L2/L1（SMEM）/TMEM/レジスタ などのメモリ階層構造を持つ
最新 GPU 仕様の要約
- SM（Streaming Multiprocessor）数、クロック、メモリ、FLOPs、帯域幅（BW）などはモデルごとに異なる
- メモリ容量（HBM）や帯域幅、FLOPs（浮動小数/整数/低精度）は世代を重ねるごとに増加している
- 表（省略）における主な特徴: Blackwell（B200）は HBM 192GB、HBM BW 8.0TB/s、FP8 FLOPs 4.5e15 など
- 世代ごとにレジスタやオンチップキャッシュ（SMEM）容量、TMEM の追加など、ハードウェアの進化が明確である
GPU/TPU 比較
- GPU は汎用的で、多数の小型 SM（並列ユニット）としてモジュール化されており、ハードウェア制御が多いため理解や最適化が難しい
- TPU は少数の大型 Tensor Core と多数のベクトル ALU（VPU）で構成され、単一スレッド制御方式のためハードウェアを単純化し、コスト削減が可能である
- その結果、TPU ではコンパイラ最適化が必須 であり、GPU は複数カーネルを独立実行できる ため使いやすさが高い
- 性能/価格 の面では、最近の H200 GPU は TPU v5p と比べて FLOPs/s が 2 倍、HBM が 1.5 倍、価格は約 2.5 倍である
- TPU は VMEM（オンチップキャッシュ）が多く高速 であり、LLM モデル推論などで大きな利点を持つ可能性がある
GPU ハードウェアクイズ Q&A の要点
- H100 の fp32 CUDA コアは合計 16,896 個（132 SM x 4 x 32）、B200 は 18,944 個
- ベクトル演算 FLOPs は H100 で最大 33.5TFLOPs/s 程度で、Tensor Core の行列積 FLOPs（990TFLOPs/s）に比べて 30 倍低い
- H100 の L1/SMEM とレジスタの合計容量は 66MB、TPU の VMEM は 120MB
- Bandwidth（帯域幅）と FLOPs の比率（理論上の演算集約度）は H100/B200 ともに 280〜300 程度で TPU と近い
GPU ネットワーキング（通信構造）
ノード/クラスター構造
- GPU ノード は通常 8 個の GPU で構成され、NVLink（超高速）および NVSwitch（スイッチ）によって Full Bandwidth の直接接続が行われる
- ノード間 は InfiniBand（Ethernet など）を用いてスケールアウト可能である
- 最新の（Blackwell）GPU は Node 72 個まで拡張可能な構造である
ネットワーク階層ごとの特徴
- ノード内部（NVLink 領域）: GPU あたり egress 450GB/s（H100）、900GB/s（B200）、NVSwitch あたり最大 1.6TB/s
- ノード上位（InfiniBand Leaf/Spine）: Leaf Switch（8 台）〜Spine Switch（16 台）構成で、GPU〜GPU 間は理論上 400GB/s の Full Bandwidth を維持
- SuperPod のような大規模アーキテクチャでは 1024 個の GPU（128 ノード）、GB200（72GPU Node）は 9 倍に増幅された帯域幅（3600GB/s）
ネットワーク性能の要点
- 理論上、ネットワーク構造（Full Fat Tree）はノード〜ノード間でも最大帯域幅を提供するよう設計されている
- ハードウェアポート制約などにより、1024〜4096GPU へ拡張する際には Spine/Core Switch をさらに追加する階層化方式が使われる
- Node 内帯域幅（450GB/s） → Node 間帯域幅（400GB/s） への切り替えは、集団演算で性能差につながる
集団演算（Collectives）構造
- AllGather、AllReduce（集約）、AllToAll（分散）などの高水準な集団演算をサポートする
- Node 内では NVLink による直接接続で最適性能が可能（理論上の B/W）であり、Node〜Node 間は InfiniBand を経由する
- NVIDIA の NCCL、NVSHMEM ライブラリを活用する
集団演算の性能分析
- AllGather/ReduceScatter: B/W（H100 基準で 450GB/s）でリング（Ring）方式として実装され、小さなメッセージではツリー（Tree）方式も可能
- AllToAll: 各 GPU が直接相手 GPU に送信し、B/W を N で割る方式のため、Node 内では理論上 2 倍高速である
- 実測では AllReduce は 370GB/s 程度で、ハードウェア最大値には届かない
- TPU と比べると、大容量（数十 MB 〜 GB）になって初めてハードウェアの Peak Bandwidth に近づく
総合まとめとインサイト
- GPU は汎用性と拡張性が強み だが、ハードウェア/ネットワーク構造に応じて性能最適化の難易度と可観測性は TPU より高い
- ネットワーキング（Intra-Node/NVLink/InfiniBand/Leaf/Spine など）は大規模学習性能の中核であり、実効帯域幅と理論帯域幅の差に注意が必要である
- 集団演算とネットワーク構造への理解は 超大規模分散モデルの学習/サービング において必須要素である
- 実践的なベンチマークとハードウェア詳細構造の理解に基づき、性能ボトルネック区間と最適条件を把握するプロセスが求められる
1件のコメント
Hacker Newsのコメント
私はこの記事と関連ドキュメントの多くがやや不明瞭だと感じた。特にGPUの説明で用語が曖昧に使われることが多い。たとえば最初の画像では「Warp Scheduler」をTPUのVPUに似たSIMDベクトルユニットだと説明しつつ、32個の「CUDA Core」があるとしているが、ここで「CUDA core」が何なのかを明確に説明していないため、説明の核心となる対象がきちんと伝わっていない。こうした複合的な問題のせいで、初心者や概念を学ぼうとしている読者には依然として理解しづらく、一方ですでにある程度わかっている人にとっては既知の内容になってしまっている。草稿段階の内容であっても公開するなら、用語は一つひとつ外科手術のように正確に扱い、混同したり混ぜて使ったりしてはいけない。アナロジーを使うときは慎重であるべきだし、MXU（行列演算ユニット）のような用語は補足説明やハイパーリンクで簡単に辿れるようにすべきだと思う。今どきはAIにその役割をさせることもできるが、それは少し悲しいことでもある
著者として直接返答する。指摘にはおおむね同意する。説明の正確性を確保しようとするほど、「道徳的真実」とのバランスにはいつも悩まされる。たとえば「NVIDIAがCUDA Coreと呼ぶ、SIMD（単一命令・複数データ）ベクトルユニット32個（ALU）で構成されたTPUのVPUに似たユニット」と書くこともできるが、そうすると文が長くなり、ベクトルユニットなどの用語定義もまた抜け落ちかねない。脚注は多めに入れるよう努めているが、読者がいちいちクリックしてくれるとは期待しづらいし、サイドノートはHTMLで実装するのが難しい。MXUのような用語は前章ですでに定義していたが、読者がすべての章を必ず読むと想定するのも無理があると思う。「Warp Scheduler」も実際には複数の役割（スケジューラ、ディスパッチユニット、SIMD ALU）を含意しているなど、用語自体に曖昧さがあるが、これはNVIDIAが複合ユニットに別の名称を付けていないことから生じている。今後さらに改善していきたい。簡単ではない妥協の連続だ
LLMはこうした用語のつながりに関する難しさを解くのにかなり良い道具だ。1つの用語を調べても次々に知らない用語が出てくるとき、どこから学び始めればよいかをうまく案内してくれる
Google TPUシステムアーキテクチャ文書にほとんど全部載っている
真面目に聞きたいのだが、コンピュータアーキテクチャについてどの程度の背景知識を前提にするのが適切なのか気になる。SIMDという概念自体はすでに50年以上前からある。この資料の冒頭ではLLMとTransformerアーキテクチャの理解は前提としている一方で、コンピュータの動作原理の理解は不要だとしているが、CPUの基本動作原理くらいは知っている前提にすべきではないかとも思う
このコンテンツは機械学習分野で働く人を対象に書かれた本の1章だ
私は、オープンソースでない、あるいは複数ベンダーで相互利用できる技術でないものに時間を投資するのは、正当化が非常に難しいと感じる。Nvidiaチップをうまく活用する仕事は、昔のSAP ABAPコンサルタントのようなものだと思っている。もちろんこの分野ではかなり稼げるが、歴史的に見れば、こうした専門性はそれほど得にならなかったと思う
私も10年前、大学でCUDAの授業をわざと取らずに同じことを考えていた
CUDAには、ハードウェアアーキテクチャと、それ向けのソフトウェアスタックという2つの側面がある。ソフトウェアスタックはクローズドなので、自分で低レベル最適化をするつもりがないなら、そこまで気にする必要はない。しかしハードウェア構造は学ぶ価値が十分にある。すべてのGPUは基本的に似たような仕組みで動作するし（CUDAアーキテクチャは2007年以降、基本思想は変わっていない）、こうしたアーキテクチャはシェーダー言語やGPUの抽象化の仕方に大きな影響を与えている。スレッドスケジューリング、ワープ、プライベート／共有メモリ構造などの詳細な特性を理解すれば、アルゴリズムをハードウェアの実行モデルにより適合させ、膨大な計算性能を活用できる
並列コンピューティングの原理や、ハードウェア・ドライバレベルでの動作には、かなり一般化できる部分があることを強調したい。特定プラットフォームに特化した内容もあるが、かなりの部分は広く応用可能だ。一般性だけを過信すると、かえって損をすることもある。オープンソースかどうかと、汎用か特化かは別軸でも見られるので、より広い探究が必要だ
移行はそれほど難しくない。すでにOpenMPやMPIのコードを書いていた人なら、CUDAの入門自体は容易だった。CUDAで性能最適化の方法を学べばCPUの並列コードも速くなるので、本質的には既存のコンピューティングモデルの進化形だ
私も子どもの頃にIBM PC/MS-DOSでプログラミングを学んだが、どちらもオープンソースではなかった。それでも今なお大いに役立っている
「Quiz 2: GPU nodes」部分の計算は不正確だと思う。実際にはGPUやスイッチごとにポート数の制限があるので、理論上可能な450GB/sが確実に提供されるわけではなく、そのため主要クラウドやリファレンスシステムでは3.2TB/sが提供されている。もし3.6TB/sが可能なら、分散リングワークロードでボトルネックが発生する。一方で求職中だ
このシリーズ全体は本当に素晴らしかった。現代のAIワークロードの理論的限界を説明しつつ、アーキテクチャや並列化などの技術的原理をわかりやすく解きほぐしている。TPU中心ではあるが、概ね他の分野にも適用できるため実用性が高い
型がしっかりした言語で数値集約的なコードをできるだけ最適化し、それでもなお速さが必要ならGPUオプションを検討する、という順番だ。私の経験ではGPUでおよそ8倍は速くなる。Web応答を4秒から0.5秒に縮められれば、とてつもない変化だ。ただ実際には、WebSocketで待機表示（スピナー）を出したり、バックグラウンドキャッシュを使ったりするほうが簡単なことも多い。そしてクラウドでGPUを回すのはコストが高い点も考慮すべきだ
nvshmemがML分野でこれほど注目されているのは興味深い。一方で、同等機能のMPIは昔の科学シミュレーションの世界ではそれほど満足のいくものではなかった。参考までに、私は複数ノードにまたがる長距離力計算のような難度の高い作業を主にしていた
なぜNvidiaはTPUを自社開発しなかったのだろうか
その必要がない。すでにハードウェアとプログラミングモデルの市場で支配的な地位にあり、TPUのほうがむしろプログラミング難易度は高い
実際には、この記事で説明されているように、Nvidia GPUの性能の90%は行列演算ユニットから出ているので、ほとんどTPUに近い構造だ。多少の性能は犠牲にするが、はるかに柔軟なコンパイラエコシステムを確保している
いまだにNvidiaがこのレベルのリソースを公式に提供していないのは驚きだ。結局、サードパーティがハードウェアをリバースエンジニアリングして、実際に使える概念図にまで整理している状況になっている。Nvidiaの本当の動機が気になる。もし単なるマーケティングしか考えていないのだとしたら成功しているが、私はエンジニアリング文化には疑問が残る
リアルタイムレンダリングのエンジニアの立場からすると、昔からずっとそうだった。NVは世代間の変化を競合に把握されないよう、ほとんどの情報を厳重に隠している。他のベンダーも大差ない。ゲーム分野ではNDAを結んでより詳細なアーキテクチャ情報を提供することはあるが、それ以外で完全公開の例はIntel以外ほとんど見たことがない
Nvidiaは実際、他社と比べても本当に優れた公式ドキュメントを多数出している
なぜそう感じたのか気になる。実際のところ、この記事の内容の大半はNvidia公式ドキュメントをほぼそのまま持ってきたものに見える。たとえばH100の図も、実際には H100 whitepaper から出典表記なしでコピーされたものだ。演算量や帯域幅の情報もすべて公式whitepaperと CUDA C++ガイド の5章、6章、7章ですでに扱われている。外部でより簡潔に整理し、解釈を加えることには価値があるが、Nvidiaの公式資料がなければそもそもこうした記事自体が成り立たなかったはずで、根拠のない推測や疑念は少し行き過ぎだと思う
Nvidiaは必要最低限の文書しか公開しないことで、cuBLASやcuDNNのようなクローズドライブラリだけが速くなり、その結果ベンダーロックインが強まる構造になっている。おかげで他社がリバースエンジニアリングで追いつくのも難しくしている
さまざまな状況証拠を見ると、NvidiaはNDA署名者やVIPにだけカスタム資料を提供し、一般向けの公式マニュアル公開は意図的に手薄にしている傾向がある。それが商業的に自社に有利だからそうしているのだと思う。APIの公式文書でさえ障壁を設ければ普通の開発者はアクセスしづらいが、AI、GPUそのもの、ソフトウェア、VIP向け文書などエコシステム全体の販売に注力しているため、一般開発者にはあまり気を配っていないとも言える
私たちが構造図を見るとき、それが実際のハードウェアを完全に反映したものではない点を必ず念頭に置くべきだ。Nvidiaは図中のブロックや構成要素が実在することを保証しておらず、あくまでGPUやSMの構造を考える際の参考用メンタルモデルとして提供しているにすぎない。たとえば、実際のSMに機能ユニットがいくつあるのか、「tensor core」自体が独立したハードウェアなのか、それとも複数ユニットの組み合わせの結果なのか、ワープ未満の単位での詳細動作も公式にはわからない
本当に素晴らしいリソースで、良い内容を得られた