『GPUとLLM』第1章。画面のピクセルを塗る装置だったGPUが、なぜ大量の計算をさばけるのか。CPUとの設計の違い、SM・ワープ・スレッドの入れ子、Tensor Core、レジスタからHBMまでのメモリの階層を、NVIDIA H100 SXM の数値で見積もりながら、図が動く形で開いていきます。
グラフィックボードの心臓部であるGPUは、いまや大規模言語モデル（LLM）の学習や推論を支える計算装置になっています。この章では、GPUの中に何がどれだけ並んでいるのかを、外側から順に開いていきます。
図の左は小さな演算器がびっしり並んだチップ、右は大きさの違うメモリが積み重なった階層のイメージです。「とても多くの演算器」と「速さと容量の違うメモリの段々」の2つが、この章の主役です。具体的な数値は、データセンター向けの代表的なGPUである NVIDIA H100 SXM を例に使います。
GPUはもともと、画面の絵を描くための装置でした。画面は小さな点（ピクセル）の集まりで、フルHDなら 1920 × 1080 ＝ 約207万個あります。1秒に60回描き直すなら、毎秒およそ1.2億個の点の色を計算しなければなりません。
図の赤い枠のマスも、その隣のマスも、使う式は同じ「色 ＝ f(x, y)」で、違うのは入力の座標だけです。しかも、どのマスの計算もほかのマスの結果を待つ必要がありません。このように、同じ処理を大量のデータに一斉に当てはめる形をデータ並列と呼びます。GPUの設計は、この形を速くすることから始まっています。
同じ大きさのシリコンでも、CPUとGPUでは面積の使い道が大きく違います。CPUは少数の高機能なコアに、命令を先読みしたり分岐の行き先を予測したりする制御回路（紫）と、大きなキャッシュ（青）を組み合わせます。1つの仕事をできるだけ早く終わらせるための作りです。
GPUは逆に、緑の小さな演算器を大量に並べ、制御とキャッシュは何個もの演算器でまとめて共有します。前のページのピクセルのマスが、そのまま右のGPUの演算器のマスに移ったように、データ1つ1つに演算器を割り当てるイメージです。サーバー向けCPUでもコアは数十〜数百個ですが、GPUの演算器は1万を超えます。
この違いは、何を速くしたいかの違いです。図は横軸を時間にして、各コアが仕事（緑の箱）をこなす様子を描いた例です。CPUは1件を時間1で終えますが、同時に進められるのは4件だけ。GPUは1件に時間4かかる代わりに、32件を同時に進めます。
一定時間に終わる量は「処理量 ＝ 同時に進む数 ÷ 1件の時間」で決まり、この例ではCPUが 4 ÷ 1 ＝ 4件、GPUが 32 ÷ 4 ＝ 8件です。1件をすぐ返したい処理はCPUが、大量にさばく処理はGPUが得意になります。数字は説明用の例ですが、本物のGPUでは同時に進む数が数十万に達します（あとで計算します）。
では、本物のGPUを開いてみます。NVIDIA H100 SXM のチップには、SM（ストリーミング・マルチプロセッサ）という処理の単位が132個並んでいます。図の緑のマス1つがSM1個です。SMはそれぞれが独立に命令を読んで動ける、小さなプロセッサのようなものです。
チップの中央には全SMが共有するL2キャッシュ（50MB）があり、チップの外、同じパッケージの上には HBM と呼ばれる積み重ね型のメモリ（合計80GB）が載っています。前のページの小さなGPUの図が、この全体図に広がりました。次のページでは、紫で囲んだSMを1つ拡大します。
紫のSMを拡大すると、中は4つの区画に分かれています。各区画には、次にどの命令を出すかを決めるワープ・スケジューラ（紫）、計算途中の値を置くレジスタ（青、64KB）、32個のFP32演算器（緑のマス。CUDAコアとも呼ばれます）、そして行列計算専用のTensor Core（橙）が1つずつあります。
SM全体では FP32演算器が128個、Tensor Core が4個、レジスタが合計256KBです。下の共有メモリ／L1キャッシュは、同じSMの区画どうしで共有されます。H100全体の FP32演算器は 132 × 128 ＝ 16,896個で、章の題名の「数千のコア」は実際には1万を超えています。
GPUのプログラムは、たくさんのスレッド（1つの計算の流れ）として書きます。SMはスレッドを32本ずつ束ねたワープ単位で扱い、1つの命令をワープの32スレッドが一斉に実行します。前のページの緑の32マスが1列に並んだのが、ワープの姿です。
命令は同じでも、各スレッドは自分の番号 i に応じて別のデータ a[i]、b[i] を使います。これを SIMT（Single Instruction, Multiple Threads）と呼びます。下の段が GPU → SM → ワープ → スレッド の入れ子で、1つのSMは最大64ワープ（64 × 32 ＝ 2,048スレッド）、H100全体では 132 × 2,048 ＝ 270,336スレッドを同時に抱えられます。
ワープの32スレッドは同じ命令を実行するので、if 文で行き先が分かれると困ったことが起きます。図では x[i] > 0 のスレッドが処理A（橙）、それ以外が処理B（紫）に進みます。ワープはまず橙のスレッドだけを動かして A を実行し、そのあいだ紫のスレッドは待ちます。次に紫のスレッドで B を実行し、今度は橙が待ちます。
下の2段のマスが、それぞれの番で動いているスレッドです。かかる時間は A と B の合計になり、どちらの番でも半分ほどの演算器が遊んでいます。32スレッドがそろって同じ道を通るときが、いちばん効率がよいということです。
32スレッドの束は、ここからは小さな箱「W0」として描きます。ワープがHBMのデータを読むと、届くまでに数百サイクルかかります。図は計算1に対して待ち3の長さで描いた例で、W0 は計算（緑）とメモリ待ち（灰）をくり返しています。
下の「演算器」の段を見ると、W0 が待っているあいだは赤い空きになっています。動いている割合は 計算 ÷（計算 ＋ 待ち）＝ 1 ÷ 4 ＝ 25% です。CPUなら大きなキャッシュで待ち時間そのものを縮めますが、GPUは別の方法でこの空きを埋めます。
GPUのスケジューラは、待っているワープを脇に置き、すぐ実行できる別のワープの命令を出します。各ワープの値はもともとレジスタに置いたままなので、切り替えに保存や復元の手間はほとんどかかりません。図ではワープが4本に増え、W0 が待つあいだに W1・W2・W3 が順に計算して、下の段の赤い空きがすべて埋まりました。
必要なワープの数は、およそ 1 ＋ 待ち ÷ 計算 で見積もれます。この例では 1 ＋ 3 ÷ 1 ＝ 4本です。SMが最大64ワープも抱えられるのは、数百サイクルの待ちでも切り替えで隠せるようにするためです。
FP32演算器は1サイクルに「積和」（掛けて足す c ← a × b ＋ c）を1回行います。左の緑の四角が、これまで緑のマスで描いてきた演算器1個です。一方 Tensor Core は、小さな行列どうしの D ＝ A × B ＋ C をまとめて計算する専用回路です。図の青い行と紫の列を掛け合わせて足すと、D の橙のマスが1つ決まります。4×4の行列なら 4 × 4 × 4 ＝ 64回の積和を命令1つでこなします。
H100 の Tensor Core は1個で1サイクルに約512回の積和（FP16、公表値からの逆算）をこなし、SM1個で比べると FP32演算器の16倍です（精度は違います）。わざわざ行列積専用の回路を積むのは、LLMの計算のほとんどが行列積だからです（第2章）。
演算器が計算するには、データを手元まで持ってこなければなりません。GPUのメモリは大きく4つの段に分かれていて、上の段ほど演算器の近くにあって速い代わりに小さく、下の段ほど大きい代わりに遠くて遅くなります。
いちばん上のレジスタは各スレッド専用の置き場で、1スレッドが使えるのは約1KBまで。共有メモリ/L1は同じSMのスレッドどうしで使う256KB、L2キャッシュは全SMで共有する50MBです。いちばん下のHBMはチップの外にある80GBのメモリで、LLMの重みはふだんここに置かれています。図の右側が、それぞれの段を誰と使うかと、その容量です。
ピラミッドの段が、そのまま横向きのバーになりました。左の青いバーは容量で、長さは対数（同じだけ伸びるごとに10倍）です。レジスタの約1KBからHBMの80GBまで、1段下りるごとに100〜1,000倍ほど大きくなります。
右に伸びた橙のバーは、データを頼んでから届くまでの待ち時間（サイクル数）です。レジスタはほぼ待たず、共有メモリも約30サイクルですが、L2やHBMは数百サイクルかかります。そこでGPUのプログラムは、HBMから読んだデータを共有メモリやレジスタに置き、何度も使い回すように書かれます。待ち時間は同じHopper世代のGPUで測った例です。
GPUが1秒に何回計算できるかは「ピーク演算性能 ≈ SM数 × 1SMが1サイクルにできる演算数 × クロック周波数」で見積もれます。
H100 SXM で FP16 の Tensor Core を使うと、1SMは1サイクルに 4個 × 512 ＝ 2,048回の積和、掛け算と足し算を別に数えて4,096回の演算をします。図の上の段のとおり 132 × 4,096 × 1.83×10⁹ ≈ 9.89×10¹⁴ で、1秒に約989兆回（989 TFLOPS）。NVIDIAの公表値と一致します。FP32演算器だけなら約67 TFLOPSで、Tensor Core が性能のほとんどを担っています。
下の灰色の帯は、前のページのHBMのバーが移ってきたものです。HBMが運べるのは1秒に3.35兆バイトです。
2つの速さを割り算すると、989兆回/秒 ÷ 3.35兆バイト/秒 ≈ 295回/バイト です。HBMから1バイト届くあいだに、Tensor Core は約295回の演算をこなせます。左の青い1マスが届いた1バイト、右の橙のマス295個がそのあいだにできる演算です。
FP16の数は1個2バイトなので、読み込んだ数1個につき約590回計算しないと、演算器はHBMを待って遊んでしまいます。待つワープを切り替える工夫も、計算する仕事そのものが足りなければ隠しきれません。GPUは「計算は速いが、データを運ぶのが遅い」装置なのです。この比を算術強度として式にするのが第3章です。
この章では、GPUの中を外側から順に開いてきました。要点は次の4つです。
次の第2章では、LLMが実際に何を計算しているのかを見ます。答えは「ほとんどが行列積」です。
