ハクソク

世界を動かす技術を、日本語で。

GPUについての考え方

280日前原文(jax-ml.github.io)

概要

  • GPU は主に 行列演算 を高速化するための計算コア群と高速メモリから構成
  • 最新の ML向けGPU （例：H100, B200）は 100個以上のSM （Streaming Multiprocessor）を搭載
  • 各SMは Tensor Core や CUDA Core、オンチップキャッシュを内蔵
  • メモリ階層 はHBM、L2/L1キャッシュ、レジスタなど多層構造
  • GPUとTPUの違い ・類似点も整理

GPUとは何か？ 〜H100/B200などML向けGPUの構造〜

  • GPU は大量の 計算コア （SM：Streaming Multiprocessor）と 高速メモリ （HBM）で構成
  • H100 は132個、 B200 は148個のSMを搭載
  • 各SMは独立性が高く、同時に多数のタスクを処理可能
  • SM内には Tensor Core （行列演算専用）、 Warp Scheduler （SIMD制御/命令スケジューラ）、 CUDA Core （ベクトル演算）、 SMEM （256kBのオンチップキャッシュ）を内蔵
  • B200 ではTensor Core用の TMEM （Tensor Memory）が追加され、大規模行列演算へ対応

SM（Streaming Multiprocessor）の詳細

  • 各SMは4つの サブパーティション （subpartition）に分割
    • 各サブパーティションに Tensor Core、 Warp Scheduler、 レジスタファイル、 CUDA Cores を搭載
  • CUDA Core
    • 主にSIMD/SIMTベクトル演算、ReLUや逐次演算、リダクションなどを担当
    • 32個のfp32コアを含む
    • 柔軟なSIMT（Single Instruction Multiple Threads）モデルを採用
  • Tensor Core
    • 行列積（matmul）専用の高スループットユニット
    • H100では1コアあたり1024 bf16 FLOPs/サイクル、B200では約2048 FLOPs/サイクル
    • 精度が低いほど（fp8等）スループットが向上
    • B200では計算規模拡大のためTMEMが追加

メモリ階層

  • レジスタファイル ：各サブパーティションに16,384個の32bitレジスタ（合計256kB/SM）
  • SMEM（L1キャッシュ） ：各SMごとに256kB、共有メモリやオンチップキャッシュとして機能
  • L2キャッシュ ：全SMで共有、H100で約50MB、B200で126MB、バンド幅は約5.5TB/s
    • SM間の協調動作が必要になる要因
  • HBM ：主記憶、モデル重みや中間データを格納
    • H100で80GB/3.35TB/s、B200で192GB/9TB/s
  • TMEM ：B200から導入、Tensor Core用の専用メモリ

GPUとTPUの比較

  • SM（GPU） ≒ Tensor Core（TPU）
    • GPUのSMは独立性・柔軟性が高いが、1コアあたりの性能はTPU Tensor Coreに劣る
  • Warp Scheduler（GPU） ≒ VPU（TPU）
    • 並列ベクトル演算ユニット
  • CUDA Core（GPU） ≒ VPU ALU（TPU）
    • SIMD型演算ユニット
  • SMEM（GPU） ≒ VMEM（TPU）
    • 高速オンチップキャッシュ
  • Tensor Core（GPU） ≒ MXU（TPU）
    • 行列演算専用ユニット
  • HBM（GPU） ≒ HBM（TPU）
    • 大容量・広帯域メモリ

GPU世代ごとの主なスペック比較

| GPU | 世代 | クロック | SM数 | SMEM/SM | L2容量 | HBM容量 | HBM帯域 | bf16/fp16 FLOPs | fp8/int8 FLOPs | fp4 FLOPs | |---|---|---|---|---|---|---|---|---|---|---| | V100 | Volta | 1.25/1.38GHz | 80 | 96kB | 6MB | 32GB | 0.9TB/s | — | — | — | | A100 | Ampere | 1.10/1.41GHz | 108 | 192kB | 40MB | 80GB | 2.0TB/s | 310TF | 620TF | — | | H100 | Hopper | 1.59/1.98GHz | 132 | 256kB | 50MB | 80GB | 3.4TB/s | 990TF | 2000TF | — | | H200 | Hopper | 1.59/1.98GHz | 132 | 256kB | 50MB | 141GB | 4.8TB/s | 990TF | 2000TF | — | | B200 | Blackwell | ? | 148 | 256kB | 126MB | 192GB | 8.0TB/s | 2250TF | 4500TF | 9000TF |

  • 各世代で SM数・メモリ容量・演算性能 が大幅に増加
  • Blackwell世代（B200）ではTMEM追加や行列演算規模の拡大が特徴

GPUの歴史的背景と汎用性

  • 元々は ビデオゲーム のためのグラフィック処理用プロセッサとして誕生
  • ゲームでは三角形のラスタライズやピクセルシェーディングなど多様な負荷
  • 2010年代以降、 ディープラーニング の普及で行列演算特化型へ進化
  • 汎用性 の高さから新しい用途への適応力が高い

まとめ

  • 最新GPU は100以上の独立SM、強力な行列演算ユニット、階層的なメモリ構造を持つ
  • TPUと比較 すると、柔軟性・適応性の高さがGPUの強み
  • ML/DL用途 では、低精度演算や大容量メモリによる高速処理が可能
  • 世代ごとに拡張 されるSM数・メモリ帯域・Tensor Core規模が性能向上のカギ

Hackerたちの意見

すごいリソースだね！ここに投稿してくれてありがとう。

「クイズ2: GPUノード」の計算は、私の知る限りでは間違ってると思う。各GPUやスイッチに十分なポートがないから、理論上可能な450GB/sを完全には実現できないんだ。だから、主要なクラウドプロバイダーやリファレンスシステムでは、3.2TB/sのノード間帯域幅が提供されてる。もし3.6TB/sだったら、分散リングワークロードではボトルネックが発生するよ。恥ずかしながら、誰か雇ってくれる人がいたら仕事を探してるよ。

└

これについて考えるのは久しぶりだけど、プロバイダーが3.2tbpsしか宣伝しない理由って、単一ノードのIBネットワークへの接続の限界だからじゃない？DGXは各H100をConnect-X 7 NICとペアにするように仕様されてて、それが400gbpsで上限なんだ。8 GPU * 400gbps / GPU = 3.2tbps。クイズ2はちょっとわかりにくい表現だけど、私の理解ではノード内のGPU接続について言ってるんだと思う。

なんでこのリソースがNVIDIAからまだ提供されてないのか、ほんとに不思議だよ。3rdパーティが逆アセンブルしてNVハードウェアをまとめるまでになって、実際に役立つメンタルモデルになってる。NVIDIAの実際のインセンティブは何なんだろう？もしマーケティングが全てなら、彼らはうまくやってるけど、エンジニアリング文化には疑問があるな。

└

平凡なドキュメントのせいで、NVIDIAのクローズドソースライブラリ、例えばcuBLASやcuDNNは、特定のタスクを実行する最速の方法のままで、ベンダーロックインを強化することになるよね。もちろん、他の会社が逆アセンブルするのも難しくなるし。

└

NVIDIAがサインした人や他の「VIP」に対して、半分カスタマイズされたドキュメントを配布するのを好む傾向があるという状況証拠はたくさんあるよ。彼らの製品を誰がどのように使うかをコントロールするために、公共のドキュメントを定期的に無視してる可能性もある。商業的に意味がある理由があるけど、一般には意味がないからね。インセンティブについては、確かに謎だよね。APIドキュメントを閉じ込めることで、自分たちの足を撃ってるように思えるけど、AIに全てを賭けてる今の時代、つまりGPUやソフトウェア、NDAにサインしたVIP向けのドキュメントを「パートナー」に売ることで、彼らはすでに満たされてるのかもしれないし、フラッグシップGPUの動作を知りたい開発者にはますます無関心になってるかもしれない。

└

Nvidiaは競合他社と比べて、これに関しては信じられないくらい良いドキュメントを持ってるよ。

└

なんでそう思うの？この資料のほとんどはNVIDIAのドキュメントからそのまま出てきたみたいだよ。何が足りないと思う？ちょっと確認したら、H100の図が例えばH100のホワイトペーパーからコピーされてる（正しく引用されてないけど）ってことが分かったよ。https://resources.nvidia.com/en-us-hopper-architecture/nvidi... 計算や帯域幅に関する情報の多くは、それや他のアーキテクチャのホワイトペーパー、さらにCUDA C++プログラミングガイドから来てるんだ。この記事が共有してる内容の多くは、特に第5章、第6章、第7章に書かれてるよ。https://docs.nvidia.com/cuda/cuda-c-programming-guide/ 第三者が要点をまとめたり、短いバージョンを作ったり、自分の意見を書くことには価値があるけど、この記事はNVIDIAのドキュメントがなければ成り立たなかったから、推測やFUD、陰口はちょっと不当かもしれないね。

nvshmemがMLで広がってるのは面白いね。MPIの同等品はシミュレーションの世界ではあまり満足できるものじゃなかったから。ちなみに、私は長距離力の処理をやってたけど、複数ノードで扱うのはいつでも難しいんだよね。

オープンソースでもなく、複数の互換ベンダーがないものを学ぶために時間を投資するのは、正当化するのがすごく難しい。NVIDIAのチップを使いこなすのは、ABAPコンサルタントになるのと似てる気がする。今はこの分野でお金がたくさん稼げるのはわかるけど、私の理解では歴史的にこういうのはあまり良い選択じゃなかった。

└

確かに、でもこの分野でお金を稼いで、関係なくなる前に早くリタイアすることもできるよ。参考までに、ここでのアイデアは新しいものでも非移転可能なものでもないんだ。ただ特定のデザインが独自のものなだけ。AllReduceのやり方を理解するのは、数十年にわたって理論的に興味があったし、これからもずっと価値があると思うよ。

└

他のGPUアーキテクチャと比べると、共通点の方が多いから、CUDAのコンサルタントなら他のプレイヤーがちゃんとやってるときにでも対応できるはず。具体的なことよりも、考え方が大事だよね。

└

それは確かに一つの見方だけど、共有する価値はあまり感じないな。いじってみるだけでも価値がある人はたくさんいるし、あなたもそれは分かってるでしょ。「使うべきじゃない」って感じに読めるよ。NvidiaのGPUについて学ぶと、他のGPUについてもたくさんのことが分かるし、Nvidiaのチュートリアルもたくさんあるから、興味があるなら使ってみればいいじゃん。

└

実際、ピボットするのはそんなに難しくないよ。もしすでにOpenMPやMPIのコードを書いてたなら、CUDAを学ぶのは特に難しくないし、よりパフォーマンスの良いCUDAコードを書くことを学べば、CPUバウンドのコードも速く書けるようになるよ。これは既存の計算モデルの進化であって、革命じゃないからね。

└

私は本物のIBM PCでMS-DOSを使ってプログラミングを学びながら育ったけど、どちらもFOSSじゃなかったけど、今でも何らかの形で頼りにしてることをたくさん教えてくれたよ。

└

俺はcupyとかJaxとかに慣れた方がいいかな。Blas/lapackのラッパーはいつの時代も色あせないよ。GPUでできることの一部だけど、機能とリワードのバランスが良さそうだし。

└

並列計算の原則や、ハードウェアやドライバーレベルでの動作はもっと広いよね。部分的には地域特有なところもあるけど（強い地域だけど…）、他はもっと一般的。地域性がないスキルを見つけるのは難しい。あんまりいい気分じゃないけど、前に進むしかないよ。個人的には、一般的な知識を過度に理想化するのは良くないと思う。オープンソースの部分と一般的/地域的な部分を切り分けることもできるし、探求する価値のある世界はもっと広がってるよ。

└

そうそう、大学の時にCUDAの授業をサボった時に自分に言い聞かせたことだよ。

└

これはJAXの記事で、ベンダー特有の詳細を抽象化するための並列計算ライブラリだよ。もちろん、最高のパフォーマンスを求めるならハードウェアの具体的な知識が必要だけど、GPUとTPUの動作の高レベルな理解は、どちらにしても役立つ知識だと思う。

└

NVIDIAは長い間、低い株価のままで、自分たちが信じているものを支援し続けてたよね。CUDAが注目されるようになったとき、他に有力な選択肢はあったのかな？

このドキュメント、他の多くのものと同じように「不正確」だと思う。こういう努力は、GPUが何かを説明されることで利益を得ることが期待される人たち向けに作られてるけど、用語を間違えてることが多い。例えば、最初の画像にあるテキスト：>「ワープスケジューラは、32レーンのSIMDベクターユニットで、"CUDAコア"と呼ばれる」 これだけだと「CUDAコア」（単数）が何なのか全然分からないよね。これは「説明しようとする際の典型的なミス」で、たいていは善意でやってるんだけど、もし私がその内容を知らなくて理解しようとしても、説明の対象が何かが明確じゃないから、結局全部読まされるだけで何も分からない。こういう「重なり合ったエラー」のせいで、ターゲットにされてる人たちは全然賢くなれないし、すでにその概念を理解してる人たちは、結局そのドキュメントが説明しようとしてることのほとんどを知ってるから意味がない。だから、最初にメモ書きのチートシートを作って、それを「人類のために」公開しようとする人には、用語を正確に使ってほしい。用語はあなたのトレーディングカードだから、その後に動詞とかが来るんだよ。これは基本的なライティングの話だけど、実際には珍しいことだよね。用語を混ぜたり、混同したりしないで。読者はあなたが不注意だと、何度も勝手にやってくれるから。比喩も丁寧に使ってほしい。明らかに、このドキュメントはTPUの用語に慣れてる人を助けるために書かれたかもしれないけど、「MXU」って何なのかは全然分からない。高い要求をしてるのは分かってるけど、ドキュメントは長いし、そこにかけた努力は、最低限のハイパーテキストで補完できたはずだよ。「MXU」みたいな注釈付きの略語を使うだけでもね。私はいつでも$AIに同じことをやらせることができるけど、それは悲劇だって言う人もいる。

└

上記から「CUDAコア」（単数）が何なのか全然分からない CUDAコアは、基本的にNVIDIAのGPUの実際のコア上のSIMDレーンだよ。もっと詳しい答えはこちら： https://stackoverflow.com/a/48130362/1593077

└

https://cloud.google.com/tpu/docs/system-architecture-tpu-vm これで大体のことはわかるはず。

これらの構造図は、NVIDIAが実際に持っているハードウェアとは必ずしも一致しないことを忘れないようにしよう。彼らは、図に見えるエンティティやブロックが実際に存在することを保証することを避けている。これは、NVIDIAが私たちに彼らのGPU、特にSMについて考えるためのメンタルモデルを提供しているだけで、単純化された回路レイアウトではないんだ。例えば、SMに実際にどれだけの機能ユニットがあるのかは分からないし、「テンソルコア」がハードウェアとして存在するのか、他の機能ユニットのオーケストレーションに過ぎないのかも分からない。確か、サブワープレベルでの発行などがどうなってるのかも分からないよね。

└

面白い視点だね。SMって、テンソルコアの操作中は基本的にブロックされてるんじゃない？それって、結局同じFPUが仕事してるってことを示唆してるかもね。

なんでNvidiaはまだTPUを開発してないの？

で、なんでNvidiaはまだTPUを開発してないの？