GPUはなぜ行列積が得意なのか。算術強度 I＝FLOPs÷バイト と、ルーフライン（性能 ≈ min(ピーク, I×帯域)）のグラフの上で赤い点を動かしながら、大きな行列積・decode・バッチ・タイリングの違いを見ていきます。『GPUとLLM』第3章。
『GPUとLLM』の第3章です。第1章ではGPUの中身を、第2章ではLLMの計算のほとんどが行列積であることを見ました。この章ではその2つをつなぎます。GPUはなぜ行列積が得意なのか。そして同じ行列積なのに、なぜ速く動く場面と、ほとんど力を出せない場面があるのか、という問いです。
鍵になるのは「算術強度」という1つの比と、それを描いた「ルーフライン」というグラフです。図の青い坂とオレンジの平らな天井、その上の赤い点が、この章の主役です。点がグラフのどこにいるかで、GPUが計算で忙しいのか、データを待っているのかが分かります。
行列積 C ＝ A × B では、出力 C の1マス C[i][j] は、A の i 行目と B の j 列目を端から順に掛けて、足し合わせたものです。図の青い行と紫の列から、オレンジのマス1つが決まります。1マスあたり掛け算と足し算が N 回ずつなので 2N FLOPs、N² マス全体では 2N³ FLOPs になります（第2章の 2mnk で m＝n＝k＝N としたものです）。
大事なのは、どのマスも、ほかのマスの答えを待たずに計算できることです。右上のマスを先に計算しても、左下を先にしても、結果は変わりません。順番に縛られない仕事が大量にあること。これが、GPUが行列積に向いている第一の理由です。
そこで、出力のマス1つを1本のスレッドに任せます。図の黒い点が1本1本のスレッド、色の区切りは、まとめて1つのSMに渡す「ブロック」です。第1章で見たように、SMはブロックをワープ（32スレッド）単位で動かします。
どれくらいの数になるでしょうか。N＝4,096 の正方行列なら、マスは 4,096² ≈ 1,678万個あります。代表例として H100（SXM）では SM が132個あり、1つの SM は最大2,048スレッドを同時に抱えられるので、合わせて約27万スレッドが同時に動ける状態になります。1,678万マスも、GPUにとっては次々に流し込める量です。なお実際のカーネルでは、1本のスレッドが複数のマスを受け持つことがよくあります。
ただし、演算器はデータがなければ何もできません。A と B は、GPUのメモリである HBM（図の左の青い箱）に置かれていて、計算の前に右の演算器まで運ぶ必要があります。代表例の H100 SXM では、HBM から運べる速さが約 3.35 TB/s、演算器の速さは BF16 の行列演算で約 989 TFLOPS です。
そこで、1つの計算が「どれだけ計算して、どれだけ運ぶか」の比を考えます。これを算術強度 I と呼び、I ＝ 計算量（FLOPs）÷ 運ぶデータ量（バイト）と書きます。言い換えると、1バイト運ぶあいだに何回計算するかです。たとえば長さ n のベクトル2本の内積なら、2n FLOPs に対して BF16 で 4n バイトを運ぶので、I ＝ 0.5 です。
左の図がルーフラインと呼ばれるグラフです。横軸が算術強度 I、縦軸が実際に出せる性能で、どちらも1目盛りで10倍になる対数目盛りです。前のページで左右にあったHBMと演算器の箱が、青い領域とオレンジの領域に変わりました。
性能の上限は2つあります。1つは演算器の速さで決まる平らな天井（オレンジ、約989 TFLOPS）。もう1つはデータを運ぶ速さで決まる坂（青）で、高さは I × 帯域です。1バイトあたり I 回計算する仕事なら、毎秒3.35兆バイト運べば毎秒 I × 3.35兆回まで計算できる、という意味です。実際に出せる性能は2本のうち低いほうで、式にすると 性能 ≈ min(ピーク, I × 帯域) です。前のページの内積（I＝0.5）は赤い点の位置で、ピークの約0.2%しか出せません。
坂と天井が交わる点を尾根点と呼び、その横軸の値を I と書きます。I × 帯域 ＝ ピーク となる I なので、I ＝ ピーク ÷ 帯域 です。H100 SXM の公称値で計算すると、989 TFLOPS ÷ 3.35 TB/s ≈ 295 FLOP/バイト。グラフに現れた灰色の縦線がその位置です。
つまりこのGPUで演算器を使い切るには、HBMから1バイト運ぶあいだに約300回の計算が必要です。縦線より左の仕事は、演算器がいくらあってもデータ待ちになり（メモリ律速）、右の仕事だけが演算器の速さで動けます（計算律速）。なお、ここで使った989 TFLOPSは、疎行列向けの機能を使わない BF16 の公称ピークです。実際の計算で出せる性能は、これより低くなるのが普通です。
では、LLMの中心にある行列積はグラフのどこにいるのでしょうか。N×N の行列どうしの積で考えます。計算量は2ページ目で見たとおり 2N³ FLOPs です。運ぶデータは、A と B を読んで C を書く3枚ぶんで 3N² 個、BF16 なら1個2バイトなので 6N² バイトです。割り算すると I ≈ 2N³ ÷ 6N² ＝ N/3 になります。
ここで効いてくるのがオーダーの違いです。N が2倍になると、計算は N³ なので8倍、運ぶ量は N² なので4倍にしかなりません。行列が大きいほど、1バイトあたりの計算が増えるのです。N＝64 なら I ≈ 21 で、赤い点は坂を登りましたが、まだ尾根点の左です（約72 TFLOPS、ピークの約7%）。なお、これは各行列を HBM から1回ずつだけ運べた理想の場合の値です。
N を 4,096 まで大きくしてみます。I ≈ 4,096 ÷ 3 ≈ 1,365 FLOP/バイトで、尾根点の約295を大きく越えました。赤い点は青い坂を登り切って、オレンジの天井の上に移っています。ここではデータを運ぶ速さはもう問題ではなく、演算器の速さそのものが上限です。これを計算律速と呼びます。
LLMの学習や、プロンプトをまとめて読む prefill（第2章）では、何千ものトークンをまとめて大きな行列積にできるので、この天井の側で動かせます。GPUが「行列積が得意」と言われるのは、まさにこの状態のことです。数千の演算器が休まず働けるだけの計算が、運んだデータ1バイトごとに用意されているわけです。ただし実際に天井近くまで届くかどうかは、データの運び方の工夫しだいで、その話は後半のタイリングで扱います。
一方、文章を1トークンずつ生成する decode（第2章）はどうでしょうか。1人分だけを生成しているとき（batch 1）、各層でやっているのは、重みの行列 W にベクトル x を掛ける計算です。右の図のように、紫の大きな行列に対して、青い入力は細い縦1列しかありません。
このとき重みは1個ずつ、たった1回の積和にしか使われません。重み1個（BF16 で2バイト）を運んで、掛け算と足し算の2 FLOPs。つまり I ≈ 1 FLOP/バイトです。赤い点は天井から滑り落ちて、尾根点（約295）のはるか左、坂の下のほうに来ました。出せる性能は約3.35 TFLOPS、ピークの約0.3%です。GPUの演算器のほとんどは、重みが届くのを待っています。
メモリ律速だと分かると、decode の速さの上限が簡単に見積もれます。1トークン作るたびに、全部の層の重みを HBM から一通り読む必要があるので、上限はおよそ メモリ帯域 ÷ 重みのバイト数 回/秒 です。右の紫の行列が、重み全体の大きさを表すバーに変わりました。
たとえばパラメータ80億（8B）のモデルを BF16 で持つと、重みは 8×10⁹ × 2バイト ≈ 16 GB です。これを 3.35 TB/s で読むと約4.8ミリ秒、1秒に約210回です。つまり batch 1 のとき、H100 1枚でも約200トークン/秒が上限の目安で、演算器をいくら速くしてもこの数字は変わりません。実際には KVキャッシュも読むことや、帯域を公称値どおりには使い切れないことから、これより遅くなります。
そこでサーバーは、たくさんの人のリクエストをまとめて（バッチにして）同時に decode します。B人分のトークンを並べると、HBM から一度読んだ重み1個を B人分の積和に使い回せます。右の紫のバーの下で、オレンジのバーが B＝64 人分に伸びたのがその様子です。
重み1個（2バイト）に対して計算は 2B FLOPs なので、I ≈ B です。B＝64 なら赤い点は坂を右上へ登り、約214 TFLOPS まで上がります。まだメモリ律速の側なので、1ステップの時間は重みを読む時間とほぼ同じ。ほぼ同じ時間で64人分のトークンが出てくるわけで、これが推論サーバーがリクエストをまとめる一番の理由です。ただし人数分の KVキャッシュも読むので、実際の I はこれより下がります（第5章で扱います）。
ここまでの I ≈ N/3 は、行列を HBM から1回ずつだけ運べたときの理想の値でした。素直に1マスずつ計算すると、各スレッドが自分の行と列を毎回 HBM から読むので、積和1回（2 FLOPs）に2つの値（4バイト）が必要になり、I は 0.5 まで落ちてしまいます。
そこで使うのがタイリングです。出力を T×T のタイル（左のオレンジの区画）に分け、その計算に必要な A の帯と B の帯を少しずつ、SM の中にある小さくて速い共有メモリに運びます。第1章のメモリ階層を思い出してください。右の図で、前のページの青とオレンジの領域が、HBM と共有メモリの箱に戻りました。共有メモリに載せた値は、タイルの中の T 個のマスが共通で使えるので、HBM から運ぶ回数が約 T 分の1になり、I はおよそ T/2 まで上がります。
ルーフラインに戻って、タイリングの効果を見ます。タイルを使わない素直な実装は、白い丸の I ≈ 0.5 にいます。同じ行列積なのに、内積と同じくらいメモリ律速です。タイルの1辺を T＝128 にすると I ≈ 64 となり、赤い点は坂を大きく登ります。計算の中身は変えていないのに、運び方だけで性能が約100倍変わるわけです。
この T/2 は、共有メモリへの運び込みだけを数えた値です。実際には HBM と SM のあいだに L2 キャッシュもあり、複数の SM が同じタイルを共有できるので、HBM から見た I はさらに上がり、灰色の曲線の先にある理想の N/3 に近づいていきます。行列積ライブラリの cuBLAS や、Attention 用の FlashAttention は、この運び方を究めたカーネルです。
代表例として、サーバー向けCPUの AMD EPYC 9654（96コア）と H100 SXM を並べました。前のページのグラフの青と橙の領域が、GPUの2本のバーに変わっています。メモリ帯域はCPUが 460.8 GB/s、GPUが約3.35 TB/s で約7倍。同時に抱えられるスレッド数は、CPUの192に対してGPUは約27万で、約1,400倍です。
この差は、どちらの律速かで効き方が変わります。メモリ律速の decode では帯域の差がそのまま速さの差になり、8Bモデル（16 GB）を読む上限はCPUで約29回/秒、GPUで約210回/秒です。計算律速の大きな行列積では、Tensor Core を持つGPUの演算性能が効いて差はさらに広がります（倍率は数値形式や世代で大きく変わるので、ここでは向きだけ）。CPUは分岐の多い複雑な仕事に強く、GPUは同じ計算を大量に流す仕事に振り切った作りです。
この章では、行列積が互いに独立な積和の塊で、何十万ものスレッドに分けられること、そして速さを決めるのは算術強度 I（計算量 ÷ 運ぶデータ量）だということを見ました。ルーフラインの上で、大きな行列積は橙の天井に、batch 1 の decode は青い坂の下のほうにいます。バッチとタイリングは、どちらも「一度運んだデータを何度も使う」ことで点を右へ動かす工夫でした。
GPUが得意なのは、同じ重みを大量のデータに使い回せる行列積です。逆に、使い回しが少ないとメモリが壁になります。次の第4章では、重みのバイト数そのものを減らす量子化と、複数のGPUに分けて載せる並列化を扱います。この章の「帯域 ÷ 重みのバイト数」を覚えておくと、なぜそれが効くのかがすぐに見えてきます。
