What this post covers

In the previous post, I showed how to estimate the performance ceiling of a whole system, and in the post before that, how to compare the performance of a single kernel against catalog specs. This time I’ll cover two smaller topics that didn’t fit into those posts.

1. Amdahl’s law and Gustafson’s law, which describe how much faster a program gets when you parallelize it, and the matching notions of strong scaling and weak scaling
2. How to compute peak performance yourself from the hardware configuration, instead of just taking the catalog spec value as I’ve done so far

Hardware specs

Amdahl’s law and Gustafson’s law

If you go from 1 GPU to 8, does your program get 8 times faster? Usually not, because every program has parts that can’t be parallelized. Amdahl’s law and Gustafson’s law describe how much those parts hold you back. The two are often presented as opposing views, but they really just fix different things when measuring speedup, so they answer different questions [1] [2].

Amdahl’s law: fix the problem size

Amdahl’s law [3] considers the speedup when you keep the problem size (the total amount of work) fixed and increase the number of processors $N$. Let the execution time on 1 processor be 1, the fraction that can be parallelized be $p$, and the fraction that can’t be $1 - p$. On $N$ processors only the parallel part shrinks to $1/N$, so the execution time is $(1-p) + p/N$ and the speedup is

Even as $N \to \infty$, it levels off at

Image from Wikimedia Commons [7] (Daniels220, CC BY-SA 3.0)

The figure plots speedup against the number of processors for several parallel fractions $p$. Note that the x-axis is logarithmic. Even with $p = 0.95$ (95% parallelizable), the speedup is at most 20x. With $N = 8$ it’s $1 / (0.05 + 0.95/8) \approx 5.9$x, a parallel efficiency $S/N$ of 74%. Because the total work is fixed, the parallel part keeps shrinking as $N$ grows, while the serial part doesn’t, so the serial part takes up a larger and larger share. That’s the heart of this law.

Gustafson’s law: fix the execution time

Gustafson’s law [4], on the other hand, fixes the execution time and grows the problem size along with the number of processors $N$. In practice, when you get more processors, you usually want to solve a bigger problem (a finer mesh, a bigger model, more requests) in the same time, rather than solve the same problem faster.

This time, let the execution time on $N$ processors be 1, with a serial fraction $s$ and a parallel fraction $1 - s$. Doing that parallel work on 1 processor would take $N$ times as long, so the same amount of work would take $s + (1 - s)N$ on 1 processor. The speedup is therefore

and it keeps growing in proportion to $N$. With $s = 0.05$ and $N = 8$, it’s $8 - 0.05 \times 7 = 7.65$x.

Image from Wikimedia Commons [8] (Peahihawaii, CC BY-SA 3.0)

The $a$ in the figure is the serial fraction $s$. Unlike the Amdahl figure, the x-axis here is linear, and for every $s$ the speedup grows in a straight line without leveling off.

What is held fixed?

The difference between the two formulas comes down to where you measure the serial fraction.

In Gustafson’s setting the problem size grows with $N$, so if you imagine running it on 1 processor, the serial fraction keeps getting smaller. You can also put it this way: the $p$ you plug into Amdahl’s formula approaches 1 as $N$ grows. Neither law is “the right one”. Which formula you use depends on whether you want to solve the same problem faster, or a bigger problem in the same time.

Strong scaling and weak scaling

The ways of measuring that correspond to these two laws are strong scaling and weak scaling. Whenever a paper or benchmark claims scalability, always check which one it measured.

Strong scaling fixes the total problem size and increases the number of processors. This is Amdahl’s world. Ideally the execution time drops to $1/N$, and the parallel efficiency is

In LLM serving terms, it’s the situation where you take decode for the same batch, split it from 1 GPU across 8 with tensor parallelism, and want each step to take less time. In the previous post, when I estimated that running a 1T-parameter dense model on 21 machines gives 21x the bandwidth, I was assuming ideal strong scaling.

Weak scaling fixes the problem size per processor and increases the number of processors. This is Gustafson’s world. Ideally the execution time stays constant, and the parallel efficiency is

Here $T(N)$ is the time to solve an $N$-times-larger problem on $N$ processors. Training with data parallelism at a fixed per-GPU batch size, or serving requests with an independent replica on each GPU, falls into this category.

In general, weak scaling gives better-looking numbers, and strong scaling is harder. In strong scaling, the work per processor shrinks as $N$ grows, so fixed costs like the ones we saw in the post before last (kernel launches and so on) and the communication discussed next take up a larger share.

A finer model that includes communication

Amdahl’s law only considers a serial part and a parallel part, but real parallel programs also pay for communication, and that cost changes with $N$. So let’s write the execution time as

For example, tensor-parallel decode needs an all-reduce in every layer. With a ring all-reduce, each GPU transfers $2D(N-1)/N$ for data of size $D$, which barely goes down as $N$ grows. On top of that comes latency proportional to the number of all-reduce steps. So while $T_{\text{parallel}}/N$ shrinks as $N$ grows, $T_{\text{comm}}(N)$ stays flat or grows, which means $T(N)$ hits a minimum somewhere, and adding more GPUs beyond that point actually makes things slower. For batch-size-1 decode, each layer only takes a few tens of µs of compute, so even an all-reduce of a few µs to a dozen or so µs quickly becomes significant.

Bounding things with Amdahl’s law and then adding terms for communication and fixed costs is the same style of modeling as the per-kernel build-up from the previous post.

Computing peak performance yourself

In the earlier posts, I used peak performance numbers like 7.1 TFLOPS and 494 TFLOPS straight from the catalog specs. But where do those numbers come from? Instead of taking catalog numbers on faith, being able to compute them from the hardware configuration helps in situations like these:

• When you want the performance for a precision (FP64, INT8, etc.) or an arithmetic unit that the catalog doesn’t list
• When you want the ceiling for a program that only uses 1 core or 1 SM (comparing the naive implementation against the 99.2 GFLOPS single-core peak in the post before last was exactly this)
• When the actual operating frequency differs from the catalog value
• When the catalog doesn’t list CPU peak performance at all, which is common (that’s what “calculated” meant in the tables in previous posts)

The derivation below follows the slides of the University of Tokyo course “Parallel and Distributed Programming” [5].

CPU

CPU peak performance is

In words: an instruction processes SIMD-width elements at once, a core can issue some number of these per cycle, there are some number of cycles per second, and there are some number of cores. Multiply them together. For FLOPS, the instruction that does the most arithmetic is the FMA (Fused Multiply Add), $d = a \times b + c$, which is 2 FLOP per element (a multiply and an add). So

GH200’s Grace uses Arm Neoverse V2 cores, each with four 128-bit SIMD pipelines, and each pipeline can issue an FMA every cycle. In FP32, 4 elements fit in 128 bits, so the SIMD width is 4. The frequencies are listed in the GH200 datasheet [6]: base frequency 3.1 GHz, all-core SIMD frequency 3.0 GHz. Using the 3.1 GHz base frequency,

and that’s where the 7.1 TFLOPS I’ve been using comes from. However, the frequency when all 72 cores keep running SIMD instructions is given as 3.0 GHz, so for a computation like matmul that saturates FMA on every core, the more accurate ceiling is

That said, the difference is only about 3%, so the arguments in the earlier posts still hold. For a naive implementation using only 1 core, the ceiling of 99.2 GFLOPS at 3.1 GHz is fine as is. For FP64 the SIMD width is 2, so the numbers halve to 3.6 TFLOPS and 3.5 TFLOPS respectively.

The formula also tells you something. Code that only uses scalar FMA without SIMD instructions can reach at most $1/4$ of peak (in FP32). Code that issues multiplies and adds separately instead of using FMA can reach at most half. The naive implementation in the post before last reached only about 4% of single-core peak, and on top of the memory problem, factors like these stack up.

GPU (CUDA Core)

The same idea applies to GPUs. Instead of SIMD instructions, a GPU has a warp of 32 threads execute the same instruction together. So the warp width (32) plays the role of the SIMD width, and an SM plays the role of a core. (Really, this is no surprise, since SIMT (Single Instruction, Multiple Threads), the GPU’s execution model, is an extension of SIMD that lets you write each SIMD lane as a thread [10].)

An H100 SM is split into 4 sub-partitions, and each can execute one warp’s worth (32 lanes) of FP32 FMA per cycle (this is why people say an SM has 128 FP32 cores). So warps/cycle/SM = 4, and there are 132 SMs.

Unlike the CPU’s, the GPU frequency isn’t in the GH200 datasheet [6], but the max boost clock of the GH200’s GPU is 1980 MHz [9]. I checked on my own GH200 and got 1980 MHz as well.

$ nvidia-smi --query-gpu=clocks.max.sm --format=csv
clocks.max.sm [MHz]
1980 MHz

Using this,

which gives the 67 TFLOPS in the spec table.

GPU (Tensor Core)

A Tensor Core is an arithmetic unit that computes a small matrix multiply in a single instruction. Each H100 Tensor Core can compute $C = A \times B + C$ once per cycle, with TF32 inputs $A$ ($4 \times 8$) and $B$ ($8 \times 8$) and FP32 $C$ [5]. Each of the $4 \times 8$ outputs is a length-8 dot product (8 FMAs), so the work per cycle is

Each H100 SM has 4 Tensor Cores, so 132 SMs give $4 \times 132 = 528$ Tensor Cores. At the same 1.98 GHz,

Per SM, CUDA Cores do 256 FLOP/cycle while Tensor Cores do $512 \times 4 = 2048$ FLOP/cycle, 8 times as much. That’s why using Tensor Cores is fast.

Going to lower precision, the number of elements processed per cycle grows in inverse proportion to the precision, giving 1070.5 TFLOPS for FP16/BF16 and 2141.1 TFLOPS for FP8 (all dense). Every value computed here is for dense matmul. Catalogs sometimes list values using 2:4 structured sparsity alongside, and those are twice the dense values, so watch out.

The formula predicts quite accurately

Let’s put these results next to the values in the datasheet [6].

For CUDA Cores, the formula gives exactly the datasheet value. For Tensor Cores, the datasheet is about 8% lower, but the thing to notice is that the ratio is 0.92 for TF32, BF16 and FP8 alike. The only term in the formula that changes with precision is the work per cycle, so a constant ratio means the gap doesn’t come from there. It comes from a term shared by all precisions: the frequency. NVIDIA doesn’t state the reason, but presumably it’s because high-power workloads that saturate the Tensor Cores can’t sustain the max boost clock, so the Tensor Core numbers are quoted at a lower frequency.

So peak performance can be predicted quite accurately as the product of a few factors: SIMD width, instructions per cycle, frequency, and core count. And when a prediction is off, you can narrow down which factor is off.

This is useful because when measured performance falls short of the theoretical FLOPS, you can break it down and analyze which factor is missing. If all you have is the catalog number of 494 TFLOPS, you can’t say anything beyond “I’m only getting 80%”. But once you break it into the formula, you can split the problem into hypotheses you can check one at a time:

• Frequency: is the clock dropping during the measurement?
• SIMD width: are SIMD or Tensor Core instructions actually being used (or has it fallen back to scalar instructions or CUDA Cores)?
• Instructions per cycle: is it using FMA, and is it issuing an instruction every cycle?
• Core count: is work being assigned to every core or SM?

In the next section, I’ll go into frequency, which is the easiest of these to overlook.

Frequency isn’t constant

Just as the Tensor Core datasheet values were lower than the values computed at the max boost clock, on the CPU side the Grace datasheet lists an all-core SIMD frequency (3.0 GHz) separately from the base frequency (3.1 GHz). That’s because keeping the SIMD units busy on every core makes the frequency drop due to power limits.

Both GPUs and CPUs change their operating frequency dynamically depending on power and temperature. There’s no guarantee they actually run at the frequency in the datasheet or spec table.

In other words, frequency is the most uncertain term in the theoretical peak formula. When you run experiments, it’s worth checking the actual frequency.

# GPU: current clock and max clock
nvidia-smi --query-gpu=clocks.sm,clocks.max.sm --format=csv
# Watch how the clock changes during a measurement
nvidia-smi dmon -s pc
# CPU
lscpu | grep -i mhz

If the clock drops to 1.6 GHz during a measurement, the Tensor Core TF32 ceiling is $512 \times 1.6\,\text{G} \times 528 \approx 433$ TFLOPS. In the post before last, PyTorch’s TF32 matmul reached 399 TFLOPS (81% of 494 TFLOPS), but compared against a ceiling recomputed at the actual frequency, the achieved fraction might be even higher. Conversely, if you don’t notice that the frequency has dropped, you may blame your implementation and keep hunting for headroom that doesn’t exist.

The catalog number of 494 TFLOPS alone can’t tell you “it was because the frequency dropped”. Estimating peak performance from the formula lets you dig into factors like frequency when you’re not reaching theoretical FLOPS, and that’s the main reason not to stop at the spec values.

Summary

• Amdahl’s law is the speedup when the problem size is fixed. It levels off at $1/(1-p)$ because of the serial fraction $1-p$. It corresponds to strong scaling.
• Gustafson’s law is the speedup when the execution time (work per processor) is fixed. It grows in proportion to $N$. It corresponds to weak scaling.
• In real parallel programs, terms for communication and fixed costs change with $N$. Adding them to the model lets you estimate the point where adding GPUs stops helping.
• Peak performance can be computed as $(2 \times \text{SIMD width}) \times \text{FMA insts/cycle/core} \times \text{freq} \times \text{cores}$. For GPUs you swap in the warp width and SM count, and for Tensor Cores the matmul size per cycle. This formula reproduces the datasheet values quite accurately.
• Once you break it into the formula, you can analyze whether frequency, SIMD, FMA or core count is the cause when you’re not reaching theoretical FLOPS.
• Frequency is the term that varies the most. The H100 Tensor Core datasheet values are computed at a frequency below the max boost clock, and Grace has a separate frequency for SIMD. Check the actual clock during your measurements and compare against a ceiling based on it.

Reference

[1] Wikipedia, “Amdahl’s law”, https://en.wikipedia.org/wiki/Amdahl%27s_law

[2] Wikipedia, “Gustafson’s law”, https://en.wikipedia.org/wiki/Gustafson%27s_law

[3] G. M. Amdahl, “Validity of the single processor approach to achieving large scale computing capabilities”, AFIPS Spring Joint Computer Conference, 1967, https://doi.org/10.1145/1465482.1465560

[4] J. L. Gustafson, “Reevaluating Amdahl’s law”, Communications of the ACM, 1988, https://doi.org/10.1145/42411.42415

[5] K. Taura, Parallel and Distributed Programming, lecture slides “Introduction”, https://taura.github.io/parallel-distributed-programming/slides/intro.pdf

[6] NVIDIA, “NVIDIA GH200 Grace Hopper Superchip Datasheet”, 2024, https://www.nvidia.com/en-us/data-center/grace-hopper-superchip/

[7] Daniels220, “AmdahlsLaw.svg”, Wikimedia Commons, CC BY-SA 3.0, https://commons.wikimedia.org/wiki/File:AmdahlsLaw.svg

[8] Peahihawaii, “Gustafson.png”, Wikimedia Commons, CC BY-SA 3.0, https://commons.wikimedia.org/wiki/File:Gustafson.png

[9] Wikipedia, “Grace Hopper GH200”, https://en.wikipedia.org/wiki/Grace_Hopper_GH200

[10] NVIDIA, “CUDA C++ Programming Guide (v12.4), 4.1 SIMT Architecture”, https://docs.nvidia.com/cuda/archive/12.4.0/cuda-c-programming-guide/index.html#simt-architecture

このブログで話すこと

前回の記事ではモデル全体の性能の上限を見積もる方法を, 前々回の記事では単一のカーネルの性能をカタログスペックと比べる方法を紹介しました。今回はその2回で紹介しきれなかった細かい話を2つ書きます。

1. 並列化したときにどこまで速くなるかを表すアムダールの法則とグスタフソンの法則, そしてそれぞれに対応する強スケーリングと弱スケーリング
2. これまでカタログスペックの値をそのまま使っていたピーク性能を, ハードウェアの構成から自分で計算する方法

ハードウェアのスペック

アムダールの法則とグスタフソンの法則

GPUを1枚から8枚に増やしたら8倍速くなるでしょうか?多くの場合なりません。プログラムには並列化できない部分があるからです。この「並列化できない部分がどれだけ足を引っ張るか」を表すのがアムダールの法則とグスタフソンの法則です。この2つはよく対立するものとして紹介されますが, 実際には何を固定して速度向上を測るかが違うだけで, 別の問いに答えています [1] [2]。

アムダールの法則: 問題サイズを固定する

アムダールの法則 [3] は, 問題サイズ(全体の仕事量)を固定したまま, プロセッサ数 $N$ を増やしたときの速度向上を考えます。1プロセッサでの実行時間を1とし, そのうち並列化できる部分の割合を $p$, できない部分を $1 - p$ とします。$N$ プロセッサでは並列化できる部分だけが $1/N$ になるので, 実行時間は $(1-p) + p/N$ となり, 速度向上は

です。$N \to \infty$ としても

で頭打ちになります。

画像はWikimedia Commons [7]より取得 (Daniels220, CC BY-SA 3.0)

図は並列化可能な割合 $p$ ごとに, プロセッサ数と速度向上の関係を描いたものです。横軸が対数であることに注意してください。$p = 0.95$ (95%が並列化可能)でも, 速度向上は最大20倍です。$N = 8$ なら $1 / (0.05 + 0.95/8) \approx 5.9$ 倍で, 並列化効率 $S/N$ は74%です。仕事量が固定されているので, $N$ を増やすほど並列部分は縮んでいき, 縮まない逐次部分の割合が相対的に大きくなっていく, というのがこの法則の本質です。

グスタフソンの法則: 実行時間を固定する

一方でグスタフソンの法則 [4] は, 実行時間を固定して, プロセッサ数 $N$ が増えた分だけ問題サイズを大きくすることを考えます。実際, プロセッサが増えたら同じ問題を速く解くよりも, より大きな問題(より細かいメッシュ, より大きなモデル, より多くのリクエスト)を同じ時間で解きたいことの方が多いはずです。

今度は $N$ プロセッサでの実行時間を1とし, そのうち逐次部分の割合を $s$, 並列部分の割合を $1 - s$ とします。この並列部分の仕事を1プロセッサでやろうとすると $N$ 倍の時間がかかるので, 同じ仕事量を1プロセッサで処理した場合の時間は $s + (1 - s)N$ です。したがって速度向上は

となり, $N$ に比例して伸び続けます。$s = 0.05$, $N = 8$ なら $8 - 0.05 \times 7 = 7.65$ 倍です。

画像はWikimedia Commons [8]より取得 (Peahihawaii, CC BY-SA 3.0)

図の $a$ が逐次部分の割合 $s$ です。アムダールの法則の図と違って横軸は線形ですが, どの $s$ でも速度向上は直線的に伸びていき, 頭打ちになりません。

何が固定されているのか

2つの式の違いは, 逐次部分の割合をどこで測っているかにあります。

グスタフソンの設定では問題サイズが $N$ に比例して大きくなるので, 1プロセッサで実行したと考えると逐次部分の割合はどんどん小さくなっていきます。アムダールの式に入れる $p$ が $N$ とともに1に近づいていくと言ってもよいです。どちらが正しいということではなく, 同じ問題を速く解きたいのか, 大きな問題を同じ時間で解きたいのかで使う式が変わります。

強スケーリングと弱スケーリング

この2つの法則に対応する計測の仕方が強スケーリング(strong scaling)と弱スケーリング(weak scaling)です。論文やベンチマークでスケーラビリティを主張しているときは, どちらの計測なのかを必ず確認してください。

強スケーリングは, 全体の問題サイズを固定してプロセッサ数を増やします。アムダールの法則の世界です。理想的には実行時間が $1/N$ になり, 並列化効率は

です。LLM servingで言えば, 同じbatchのdecodeを1枚のGPUからtensor parallelで8枚に分けて1 stepの時間を短くしたい, という状況です。前回の記事で1T parameterのDense modelを21台で動かしたら帯域が21倍になる, と見積もったのは理想的な強スケーリングを仮定していたことになります。

弱スケーリングは, 1プロセッサあたりの問題サイズを固定してプロセッサ数を増やします。グスタフソンの法則の世界です。理想的には実行時間が一定のままで, 並列化効率は

です。ここで $T(N)$ は $N$ 倍の大きさの問題を $N$ プロセッサで解いた時間です。GPUあたりのbatch sizeを固定してdata parallelで学習する場合や, GPUごとに独立したレプリカを立ててリクエストを捌く場合がこれに当たります。

一般に弱スケーリングの方が良い数字が出やすく, 強スケーリングは難しいです。強スケーリングでは $N$ を増やすほど1プロセッサあたりの仕事が小さくなり, 前々回の記事で見たような固定コスト(カーネル起動など)や, 次に述べる通信の割合が大きくなるからです。

通信を入れたもう少し細かいモデル

アムダールの法則は逐次部分と並列部分の2つしか考えていませんが, 実際の並列プログラムでは通信のコストがかかり, しかもそれは $N$ とともに変化します。そこで実行時間を

と書いてみます。例えばtensor parallelのdecodeでは, 各layerでall-reduceが必要になります。ring all-reduceならGPUあたりの転送量はデータサイズ $D$ に対して $2D(N-1)/N$ で, $N$ を増やしてもほとんど減りません。さらにall-reduceの段数に比例するレイテンシも乗ります。つまり $T_{\text{parallel}}/N$ は $N$ とともに減っていくのに $T_{\text{comm}}(N)$ は減らないか増えていくので, どこかで $T(N)$ は最小になり, それ以上GPUを増やすと逆に遅くなります。batch size 1のdecodeでは1 layerあたりの計算が数十µsしかないので, 数µs〜十数µsのall-reduceでもすぐに無視できなくなります。

このように, アムダールの法則で上限を押さえ, そこに通信や固定コストの項を足していくのが, 前回の記事で紹介したカーネル単位の積み上げと同じ発想のモデリングです。

ピーク性能を自分で計算する

これまでの記事では, 7.1 TFLOPSや494 TFLOPSといったピーク性能をカタログスペックの値として使ってきました。しかしこの値はどこから来ているのでしょうか?カタログの数字をそのまま信じるのではなく, ハードウェアの構成から計算できるようにしておくと, 以下のような場面で役に立ちます。

• カタログに載っていない精度(FP64, INT8など)や, 載っていない演算器の性能を知りたいとき
• 1コアや1 SMだけを使うプログラムの上限を知りたいとき(前々回の記事でNaive実装を1コアの理論FLOPS 99.2 GFLOPSと比べたのがこれです)
• 実際の動作周波数がカタログの値と違うとき
• そもそもCPUのピーク性能はカタログに載っていないことが多いとき(前回までの表の「計算値」はこれです)

以下の導出は, 東京大学の講義「並列分散プログラミング」の資料 [5] を参考にしています。

CPU

CPUのピーク性能は

です。1命令で SIMD width 個の要素を処理する命令を, 1コアで1サイクルあたり何本発行できるか, それが1秒あたり何サイクルあり, コアが何個あるか, という掛け算です。FLOPSで考える場合, 最も演算量の多い命令は FMA (Fused Multiply Add), つまり $d = a \times b + c$ で, 1要素あたり乗算と加算の2 FLOPになります。したがって

です。

GH200のGraceはArm Neoverse V2コアで, 128 bitのSIMDパイプラインを4本持ち, それぞれが毎サイクルFMAを発行できます。FP32なら128 bitに4要素入るのでSIMD widthは4です。周波数はGH200のデータシート [6] に載っていて, Base frequency 3.1 GHz, all-core SIMD frequency 3.0 GHz です。Base frequencyの3.1 GHzを使うと

となり, これがこれまで使ってきた7.1 TFLOPSの正体です。ただし, 72コア全てでSIMD命令を回し続けたときの周波数は3.0 GHzとされているので, 行列積のように全コアでFMAを使い切る計算の上限としては

の方が正確です。とはいえ差は3%程度なので, これまでの記事の議論はそのまま成り立ちます。1コアだけを使うNaive実装の上限(99.2 GFLOPS)は3.1 GHzのままで構いません。FP64ならSIMD widthが2になるので, それぞれ半分の3.6 TFLOPS, 3.5 TFLOPSです。

この式からわかることもあります。SIMD命令を使わずにスカラーのFMAしか使わないコードは, 最大でも $1/4$ (FP32)しか性能が出ません。FMAを使わず乗算と加算を別々に発行するコードも最大で半分です。前々回の記事のNaive実装が1コアのピーク性能の4%程度しか出ていなかったのは, メモリの問題に加えてこういった要因も積み重なっています。

GPU (CUDA Core)

GPUでも考え方は同じです。GPUではSIMD命令の代わりに, 32 threadからなる warp が同じ命令を一斉に実行します。つまりwarp width (32) がSIMD widthに, SMがコアに相当します。(というか, GPUの実行方式であるSIMT (Single Instruction, Multiple Threads) は, SIMDの各レーンをスレッドとして書けるようにした発展形なので当たり前ではあります [10]。)

H100のSMは4つのサブパーティションに分かれていて, それぞれが毎サイクル1 warp分(32 lane)のFP32 FMAを実行できます(SMあたりFP32コアが128個と言われるのはこれです)。したがって warps/cycle/SM = 4 で, 132 SMsです。

GPUの周波数は, CPUと違ってGH200のデータシート [6] には載っていませんが, GH200のGPUの最大ブーストクロックは1980 MHzです [9]。実際に手元のGH200で確認しても1980 MHzでした。

$ nvidia-smi --query-gpu=clocks.max.sm --format=csv
clocks.max.sm [MHz]
1980 MHz

これを使うと

となり, スペック表の67 TFLOPSが出てきます。

GPU (Tensor Core)

Tensor Coreは1命令で小さな行列積をまとめて計算する演算器です。H100のTensor Coreは, TF32の入力 $A$ ($4 \times 8$), $B$ ($8 \times 8$) とFP32の $C$ に対して $C = A \times B + C$ を毎サイクル1回計算できます [5]。$4 \times 8$ の出力の各要素について長さ8の内積(FMA 8回)を行うので, 1サイクルあたりの演算量は

です。H100の各SMにはTensor Coreが4つあるので, 132 SMsで $4 \times 132 = 528$ 個のTensor Coreがあり, 同じく1.98 GHzとすると

となります。CUDA Coreの1 SMあたり256 FLOP/cycleに対してTensor Coreは $512 \times 4 = 2048$ FLOP/cycleと8倍で, これがTensor Coreを使うと速い理由です。

さらに精度を下げると, 1サイクルで処理できる要素数が精度に反比例して増えるので, FP16/BF16で1070.5 TFLOPS, FP8で2141.1 TFLOPS (いずれもdense)になります。ここで計算した値は全てdenseな行列積の値です。カタログには2:4 structured sparsityを使った値が並記されていることがあり, そちらはdenseの2倍になっているので注意してください。

式でかなり正確に予測できる

ここまでの計算結果をデータシート [6] の値と並べてみます。

CUDA Coreは式の値がそのままデータシートの値になっています。Tensor Coreはデータシートの方が8%ほど低いですが, 注目してほしいのはその比がTF32, BF16, FP8で全て0.92で一定なことです。式の中で精度によって変わるのは1サイクルあたりの演算量だけなので, 比が一定ということは, ずれの原因はそこではなく全精度に共通する項, つまり周波数だということになります。NVIDIAは理由を明記していませんが, Tensor Coreをフルに使うような消費電力の大きい処理では最大ブーストクロックを維持できないことを見込んで, 低めの周波数でTensor Coreの性能を出していると考えられます。

このように, ピーク性能は SIMD width, 1サイクルあたりの命令数, 周波数, コア数という数個の要素の掛け算で, かなり高い精度で予測できます。そして, 予測とずれたときも, どの要素がずれているのかまで絞り込めます。

これが嬉しいのは, 計測した性能が理論FLOPSに届かないときに, どの要素が足りていないのかを分解して分析できるからです。カタログの494 TFLOPSという数字だけを持っていても「8割しか出ていない」以上のことは言えません。しかし式に分解しておけば

• 周波数: 計測中にクロックが下がっていないか
• SIMD width: SIMD命令やTensor Coreの命令が使われているか(スカラー命令やCUDA Coreに落ちていないか)
• 1サイクルあたりの命令数: FMAを使っているか, 毎サイクル命令を発行できているか
• コア数: 全てのコアやSMに仕事が割り振られているか

のように, 1つずつ確認できる仮説に分けて考えることができます。次の節では, この中でも特に見落としやすい周波数について説明します。

周波数は一定ではない

Tensor Coreのデータシートの値が最大ブーストクロックで計算した値より低かったのと同じく, CPU側でもGraceのデータシートはbase frequency (3.1 GHz) とは別にall-core SIMD frequency (3.0 GHz) を載せています。全コアでSIMD演算器を動かし続けると, 電力の制約で周波数が下がるからです。

GPUもCPUも, 消費電力や温度に応じて動作周波数を動的に変えます。データシートやスペック表に載っている周波数で実際に動いている保証はありません。

つまり, 理論ピーク性能の式の中で最も不確かなのは周波数です。実験の際は, 実際の周波数を確認しておくとよいでしょう。

# GPU: 現在のクロックと最大クロック
nvidia-smi --query-gpu=clocks.sm,clocks.max.sm --format=csv
# 計測中のクロックの推移を見る
nvidia-smi dmon -s pc
# CPU
lscpu | grep -i mhz

計測中のクロックが1.6 GHzに落ちていれば, Tensor Core TF32の上限は $512 \times 1.6\,\text{G} \times 528 \approx 433$ TFLOPSです。前々回の記事でPyTorch TF32の行列積が399 TFLOPS (494 TFLOPSの81%)出ていましたが, 実際の周波数で計算し直した上限と比べると, 達成率はもっと高いかもしれません。逆に, 周波数が落ちているのに気づかないと, 実装が悪いと勘違いして存在しない伸びしろを探し続けることになります。

カタログの494 TFLOPSという数字だけでは, この「周波数が下がっていたから」という分析はできません。式からピーク性能を見積もっておくと, 理論FLOPSが出ていないときに周波数のような要因まで踏み込んで分析できる, というのがスペック値だけで終わらせない一番の理由です。

まとめ

• アムダールの法則は問題サイズを固定したときの速度向上で, 逐次部分の割合 $1-p$ によって $1/(1-p)$ で頭打ちになります。これは強スケーリングに対応します。
• グスタフソンの法則は実行時間(1プロセッサあたりの仕事量)を固定したときの速度向上で, $N$ に比例して伸びます。これは弱スケーリングに対応します。
• 実際の並列化では通信や固定コストの項が $N$ とともに変わるので, それをモデルに足していくと, GPUを増やしても速くならなくなる点を見積もれます。
• ピーク性能は $(2 \times \text{SIMD width}) \times \text{FMA insts/cycle/core} \times \text{freq} \times \text{cores}$ で計算でき, GPUではwarp widthとSM数, Tensor Coreでは1サイクルあたりの行列積のサイズに置き換えるだけです。この式でデータシートの値をかなり正確に再現できます。
• 式に分解しておくと, 理論FLOPSが出ていないときに周波数, SIMD, FMA, コア数のどれが原因なのかを分析できます。
• 式の中で最も変わりやすいのは周波数です。H100のTensor Coreのデータシートの値が最大ブーストクロックより低い周波数で計算されていたり, GraceにSIMD用の周波数が別に定められていたりします。計測中の実際のクロックを確認し, それに基づいた上限と比べましょう。

Reference

[1] Wikipedia, “Amdahl’s law”, https://en.wikipedia.org/wiki/Amdahl%27s_law

[2] Wikipedia, “Gustafson’s law”, https://en.wikipedia.org/wiki/Gustafson%27s_law

[3] G. M. Amdahl, “Validity of the single processor approach to achieving large scale computing capabilities”, AFIPS Spring Joint Computer Conference, 1967, https://doi.org/10.1145/1465482.1465560

[4] J. L. Gustafson, “Reevaluating Amdahl’s law”, Communications of the ACM, 1988, https://doi.org/10.1145/42411.42415

[5] 田浦健次朗, 並列分散プログラミング 講義資料 “Introduction”, https://taura.github.io/parallel-distributed-programming/slides/intro.pdf

[6] NVIDIA, “NVIDIA GH200 Grace Hopper Superchip Datasheet”, 2024, https://www.nvidia.com/en-us/data-center/grace-hopper-superchip/

[7] Daniels220, “AmdahlsLaw.svg”, Wikimedia Commons, CC BY-SA 3.0, https://commons.wikimedia.org/wiki/File:AmdahlsLaw.svg

[8] Peahihawaii, “Gustafson.png”, Wikimedia Commons, CC BY-SA 3.0, https://commons.wikimedia.org/wiki/File:Gustafson.png

[9] Wikipedia, “Grace Hopper GH200”, https://en.wikipedia.org/wiki/Grace_Hopper_GH200

[10] NVIDIA, “CUDA C++ Programming Guide (v12.4), 4.1 SIMT Architecture”, https://docs.nvidia.com/cuda/archive/12.4.0/cuda-c-programming-guide/index.html#simt-architecture

What this post covers

In the previous post, I showed how to find the theoretical performance of a single function or GPU kernel. In practice, though, most people are optimizing a whole system, not one kernel. So this time I’ll show how to estimate the performance ceiling of a whole system. Once you can do this, you can use it to guide your analysis and to work out what hardware you need.

Hardware specs

Why estimation matters

This probably belonged in the previous post, but I think there are two main reasons.

1. To know the maximum performance

Anyone who talks about speeding things up will think of this one first: you need to know the maximum performance. In the previous post, I showed how to find the theoretical performance of a single function or GPU kernel. You need this because you can’t justify a result unless you can say what percentage of the maximum you reached. Last time I compared speeds measured on the CPU and the GPU. But if you don’t know how many TFLOPS you got and what percentage of the theoretical value that is, you’re left wondering whether it could go faster still. Keep in mind, though, that you won’t always reach the estimated maximum. Something may be missing from your model, the algorithm may be hard to improve any further, or there may be overhead between the CPU and GPU that you can’t get rid of.

2. To catch measurement mistakes

This one is really important. When you measure things, something unexpected happens now and then, and you get a speed above the theoretical value. If that happens, there’s a 99.9999999% chance your measurement is wrong. For example, I once compiled with -O3 and measured a scan over an array of 1e9 elements, and it finished on the order of 1e-9 seconds. That means it scanned a billion elements in a few CPU clock cycles, which no existing hardware can do. What should you do first when you see a result like that? Estimate, of course. 1e9 ints is 4GB. Reading that from 512GB/s memory should take at least 8ms even at perfect efficiency. That estimate makes it obvious something is wrong, right?!?! What had actually happened was the compiler’s dead-code elimination, and I confirmed it by reading the assembly. This is why estimation matters so much!!

A disclaimer before we start

The estimation methods below aren’t a textbook system. They’re what I’ve found helpful, from experience, while running experiments and optimizing code. Read them as practical steps, not rigorous theory. Also, every number here is an upper bound. On real hardware, clock changes, cache behavior, kernel launch overhead and many other things keep you from reaching the theoretical value. What matters is always asking “how close am I to the theoretical value?” and “am I above it?”

Method 1: Add up the time of every kernel

The first method is to compute the theoretical time of each kernel in the workload and add them up to get the time of the whole system. Throughout this post, I’ll use the decode phase of LLM serving (generating one token at a time) as the example. This isn’t specific to LLM serving: to optimize a whole system, you need the basic model of knowing, as exactly as you can, what computation runs in the thing you measure, and of seeing the total time as the sum of those pieces.

A model for one kernel

Using the same idea as the previous post, let kernel $k$ do $F_k$ [FLOP] of compute and move $B_k$ [bytes] of memory, and let $P$ be the peak compute and $W$ the memory bandwidth. The kernel’s time is bounded below by

and the time of one decode step is

Estimating decode for Qwen3-30B-A3B

As a concrete example, take the MoE model Qwen3-30B-A3B-Thinking (hidden 2048, 48 layers, Q 32 heads / KV 4 heads, head_dim 128, 8 of 128 experts used per token, expert intermediate 768, vocab 151936), decoding in BF16 with batch size 1 and context length 4096. In batch size 1 decode, every matmul becomes a matrix-vector product, so there are only 2 FLOP per weight element (2 bytes). The arithmetic intensity is about 1 FLOP/byte, far below GH200’s ridge point ($989\,\text{TFLOPS} / 4.0\,\text{TB/s} \approx 247$ FLOP/byte). It is completely memory bound, so looking at $B_k / W$ is enough.

Also, since this is MoE, batch size 1 only reads the weights of the 8 experts (out of 128) that the router picked. The main kernels in one layer are:

Stacking this over 48 layers and adding the final LM head ($2048 \times 151936$, 622 MB, 156 µs) gives

so at batch size 1 the ceiling is about 617 tokens/s. MoE, however, tends to have many small kernels, such as the router’s top-k and routing tokens to each expert. If there are 8 small kernels per layer and each takes 3 µs, they add $48 \times 8 \times 3\,\mu\text{s} \approx 1.15\,\text{ms}$, which is about as long as reading the weights. This is also why kernel fusion and CUDA Graphs help.

Checking against Nsight Systems

Once you have an estimate, check how many µs each kernel actually takes with Nsight Systems.

# Example
nsys profile -t cuda,nvtx --cuda-graph-trace=node -o decode python bench_decode.py
nsys stats --report cuda_gpu_kern_sum decode.nsys-rep

Below is an example of an nsys profile opened in the Nsight Systems GUI. The timeline at the top shows which kernel runs on which stream and when, and the Events View at the bottom shows how long each kernel took.

For serving engines that use CUDA Graphs, note that without --cuda-graph-trace=node the whole graph shows up as one item, and you can’t see the time of each kernel. Once you have measured times per kernel, put them next to the theoretical times in the table above and look at the measured / theoretical ratio. Kernels with a very bad ratio, and kernels that take time but aren’t in the table, are what you should optimize. If instead the whole step takes much longer than the sum of the kernel times, the problem is CPU-side scheduling or gaps between kernel launches (GPU idle time). Inference without CUDA Graphs often pays this kind of overhead.

This method takes effort, but its strength is that it tells you, kernel by kernel, where there is room to improve and how much.

Method 2: A rough estimate from “every weight is loaded at least once”

Method 1 is accurate, but listing every kernel is a lot of work when you’re just evaluating a new model or new hardware. Here a rough estimate helps: in decode, every step has to read every weight from memory at least once. The weights are far too big for the L2 cache (tens of MB), so they’re read from HBM again every step. So

For MoE at batch size 1, you only read the active weights. Qwen3-30B-A3B has about 3.3B active parameters, so $6.6\,\text{GB} / 4.0\,\text{TB/s} \approx 1.65\,\text{ms}$, almost the same as the 1.62 ms from Method 1, from a single line of arithmetic. As the batch size grows, different tokens pick different experts, so you read more and more experts, and the time approaches $61\,\text{GB} / 4.0\,\text{TB/s} \approx 15\,\text{ms}$ for reading all parameters (about 30.5B, 61 GB). In prefill, too, many tokens are spread across all experts, so the amount of weights read is close to this number. Prefill, however, processes many tokens at once, so its arithmetic intensity is high and it can become compute bound.

A 1T-parameter dense model is heavy

Let’s apply this estimate to a 1T-parameter dense model. In BF16, the weights alone are 2 TB.

• They don’t fit in a GH200’s HBM (96 GB) in the first place. You need at least 21 of them just to hold the weights.
• Even if one GPU could read all the weights, $2\,\text{TB} / 4.0\,\text{TB/s} = 0.5\,\text{s}$, so each token takes 0.5 seconds.
• Even if you use tensor parallelism on 21 GPUs and roughly assume the bandwidth scales 21 times, $2\,\text{TB} / 84\,\text{TB/s} \approx 24\,\text{ms}$, so the ceiling is about 40 tokens/s even ignoring communication.

FP8 only halves this, so you can tell that running a 1T-class dense model locally is pretty much out of reach, without knowing anything about the kernels.

On the other hand, an MoE model like Kimi K2 has about 1T total parameters but only about 32B active per token. A token only needs to read the active weights, so the numerator of the estimate drops to under 1/30. This is one reason MoE has become the norm for huge models, and also why expert offload, which keeps unused experts in CPU memory, works.

A real example: improving FreeToken

Finally, here’s an example where an estimate actually led to a contribution: when I improved FreeToken. FreeToken is a serving engine for running huge models on your own machine. It offloads some of an MoE model’s experts to CPU memory and keeps only the frequently used experts cached on the GPU with LRU. When a needed expert isn’t in the cache (a cache miss), its weights are transferred from CPU memory to the GPU. Depending on the interconnect bandwidth, it can also run some of the work on the CPU.

Noticing the gap between estimate and measurement

While measuring FreeToken on GH200, I took the number of cache misses during decode, multiplied it by the size of the expert weights transferred per miss (for BF16 Qwen3-30B-A3B, $3 \times 2048 \times 768 \times 2\,\text{B} \approx 9.4\,\text{MB}$ per expert), and divided by the time spent on the transfers. The effective bandwidth came out to only about 220 GB/s. GH200’s CPU-GPU link is NVLink-C2C at 450 GB/s per direction, and I had measured about 418 GB/s for a plain H2D copy with the copy engine. So the expert transfers were using only about half of the theoretical bandwidth.

Instead of stopping at “I guess CPU-GPU transfers are just like this”, putting the number next to the theoretical value made it clear there was room to improve.

Cause: not enough requests in flight

The expert transfer was done by fast_index_copy_multi, a zero-copy gather kernel. Each thread loads 16 bytes from mapped host memory, stores them, and only then issues its next load. So the amount of data in flight per bank is about

and by Little’s law the bandwidth is set by

The default blocks_per_bank=8 (8192 threads per bank) had been tuned on PCIe (about 31 GB/s). PCIe has low bandwidth, so that much in flight is enough to hide the latency and saturate the link. NVLink-C2C has much higher bandwidth, so hiding the same latency needs proportionally more requests in flight at once.

The fix and the results

So I changed blocks_per_bank to 32 on hosts with NVLink-C2C (GH200 / GB200 / GB300) (PR #610). At first, detecting the device by name initialized CUDA, which broke the engine’s assumption that it owns CUDA initialization, so I switched to an environment variable. In review, I got the suggestion to detect the device after the engine has bound its GPU (inside _build_fused_copy_plan). In the end it was merged with both automatic detection and an override via the FREETOKEN_H2D_BLOCKS_PER_BANK environment variable.

That brought it almost up to the copy engine’s H2D ceiling (about 418 GB/s). The change itself is only a few lines, but I only noticed “this number is slow” because I computed the effective bandwidth from the cache miss count and transfer size and put it next to the theoretical value.

Summary

• Estimation matters both for knowing what percentage of the ceiling your implementation reaches and for catching measurement mistakes.
• Adding up $\max(F_k/P, B_k/W)$ over kernels gives a precise estimate that tells you where the room for improvement is, and you can check it with Nsight Systems.
• Even the one-line estimate “every weight is loaded at least once” shows that a 1T-class dense model is too heavy, and why MoE + offload works.
• The habit of computing effective bandwidth and comparing it with the theoretical value actually led to a performance improvement in an OSS project.

このブログで話すこと

前回の記事では単一の計算関数, GPUカーネルにおいて理論性能を見る方法を紹介しました。しかし実際にはシステム全体の最適化をするような人が多いかと思います。そこで今回はシステム全体の性能の上限を見積もる方法を紹介します。この記事を読むことで高速計算における性能の上限を見積もることができるようになり, 分析の手助けや必要ハードウェアの見積もりに使うことができます。

ハードウェアのスペック

何故見積もりが重要か

この話は本来前回の記事ですべきだった気もしますが, 主に2つほど理由があると思います。

1. 最大性能を見積もるため

1つ目の理由は高速化という話をするなら誰でもこの理由が真っ先に思い浮かぶ気がしますが, 最大性能を見積もるためです。前回の記事では単一の計算関数, GPUカーネルにおいて理論性能を見る方法を紹介しました。何故これをする必要があるかというと, 最大性能のうち何%を出せたのかを言えないと正当な説明ができないためです。前回はCPUとGPUで計測した速度を比較しましたが, 何TFLOPS出たのか, それは理論値の何%なのかを知らないともしかしたらこれ以上高速化が可能かもしれないという懸念が残ってしまいます。ただし, 注意して欲しいのは見積もった最大性能が常に出るとは限らないことです。モデルの何かしらの見積もり漏れだったり, どうやってもアルゴリズム的に改善が難しい, CPUとGPUの間で消せないオーバーヘッドがあるなどで最大性能がでないこともあります。

2. 計測ミスを防ぐため

これは非常に重要なことです。計測をしていると計測中思わぬ出来事が起き, 「理論数値以上の速度」がでます。もしこれが起きたらあなたの測定が間違っている可能性が99.9999999%あります。例えば私は昔-O3オプションをつけて測定した1e9要素を持つ配列走査が1e-9秒のオーダーで終わりましたが, これはCPUの数クロック分の時間で10億要素の走査が終わったことになり, 現存するハードウェアではありえない速度です。このような結果を見た時にまず考えるべきことはなんでしょうか?もちろん見積もりです。1e9要素のintなら4GBでしょう。それを512GB/sのメモリから読み出したら最高効率でも8msはかかるはずです。この見積もりから明らかにおかしいことはわかりますよね？？？？この時はコンパイラによるデッドコード削除最適化が起こっており, このような結果となりました。アセンブリを確認することでも確かめられたミスです。このように, 見積もりは非常に大切です‼

はじめに断っておくこと

ここから先で紹介する見積もり方は, 教科書的に体系立てられたものというより, 私が実際に実験と最適化を繰り返す中で「これをやっておくと助かる」と経験的に感じてきたものです。なので厳密な理論というよりは実践的な手順だと思って読んでください。また, ここで出てくる数値はあくまで上限の見積もりです。実際のハードウェアではクロックの変動, キャッシュの挙動, カーネル起動のオーバーヘッドなど様々な要因で理論値には届きません。大事なのは「理論値にどのくらい近いか」と「理論値を超えていないか」を常に意識することです。

方法1: カーネルの実行時間を積み上げて厳密に見積もる

1つ目は, 処理を構成するカーネル1つ1つについて理論時間を計算し, それを足し合わせることでシステム全体の時間を見積もる方法です。この記事全体ではLLM servingのdecode(1トークンずつ生成するフェーズ)を例にします。LLM Servingに限らずですが計測対象でどういった計算が走っているかをできるだけ厳密に把握し, その積み重ねで全体の時間が決まっていると考える基本的なモデリングがシステム全体の最適化には必要です。

1カーネルあたりのモデル

前回の記事と同じ考え方で, カーネル $k$ の計算量を $F_k$ [FLOP], メモリ転送量を $B_k$ [byte], ピーク演算性能を $P$, メモリ帯域を $W$ とすると, カーネルの実行時間は

で下から抑えられます。そしてdecode 1 stepの時間は

となります。

Qwen3-30B-A3Bのdecodeを見積もる

具体例として, MoE modelであるQwen3-30B-A3B-Thinking(hidden 2048, 48 layers, Q 32 heads / KV 4 heads, head_dim 128, expert数128のうち1 tokenあたり8個を使用, expertのintermediate 768, vocab 151936)をBF16, batch size 1, context長4096でdecodeする場合を考えます。batch size 1のdecodeでは行列積は行列ベクトル積になり, 計算量は重み1要素(2 byte)あたり2 FLOPしかありません。算術強度は約1 FLOP/byteで, GH200のridge point($989\,\text{TFLOPS} / 4.0\,\text{TB/s} \approx 247$ FLOP/byte)よりはるかに小さいため, 完全にmemory boundです。したがって $B_k / W$ だけ見れば十分です。

また, MoEなのでbatch size 1では128個のexpertのうちrouterが選んだ8個の重みしか読みません。1 layerあたりの主要なカーネルは以下のようになります。

これを48 layer分積み上げ, 最後のLM head($2048 \times 151936$, 622 MB, 156 µs)を足すと

となり, batch size 1では約617 tokens/sが上限ということがわかります。ただしMoEはrouterのtop-kやexpertごとのtokenの振り分けなど小さなカーネルが多くなりがちです。小カーネルが1 layerあたり8個あり, 仮にそれぞれ3 µsかかるとすると, $48 \times 8 \times 3\,\mu\text{s} \approx 1.15\,\text{ms}$ と, 重みを読む時間に匹敵するほど上乗せされます。これがkernel fusionやCUDA Graphが効く理由でもあります。

Nsight Systemsで答え合わせをする

見積もりを作ったら, 実際にどのカーネルが何µsかかっているのかをNsight Systemsで確認します。

# 実行例
nsys profile -t cuda,nvtx --cuda-graph-trace=node -o decode python bench_decode.py
nsys stats --report cuda_gpu_kern_sum decode.nsys-rep

以下はnsysで測定した結果をNsight SystemsのGUIで開いた時の例です。上部のタイムラインでどのstreamでいつどのカーネルが走っているかを, 下部のEvents Viewで各カーネルの実行時間を確認できます。

CUDA Graphを使っているservingエンジンでは, --cuda-graph-trace=node をつけないとグラフ全体が1つにまとめられてしまい, カーネルごとの時間が見えないので注意してください。カーネルごとの実測時間が取れたら, 上の表の理論時間と並べて「実測 / 理論」の比を見ます。比が極端に悪いカーネルや, 表に載っていないのに時間を食っているカーネルが最適化の対象になります。逆にstep全体の時間がカーネル時間の合計より大きく離れていれば, CPU側のスケジューリングやカーネル起動の隙間(GPUのアイドル)が問題だとわかります。CUDAGraphなどを使っていない推論ではこの手のオーバーヘッドがよくかかります。

この方法は手間がかかりますが, どこにどれだけ伸びしろがあるのかをカーネル単位で言えるのが強みです。

方法2: 「重みは最低1回はloadされる」から大雑把に見積もる

方法1は正確ですが, 新しいモデルやハードウェアを検討する段階でいちいちカーネルを列挙するのは大変です。そこで使えるのが, decodeでは1 stepごとに全ての重みを最低1回はメモリから読まなければならないという観点からの大雑把な見積もりです。重みはL2キャッシュ(数十MB)には到底乗らないので, 毎step HBMから読み直すことになります。したがって

が成り立ちます。ここでMoEの場合, batch size 1なら読むのはactiveな重みだけです。Qwen3-30B-A3Bのactive parameterは約3.3Bなので $6.6\,\text{GB} / 4.0\,\text{TB/s} \approx 1.65\,\text{ms}$ となり, 方法1の1.62 msとほぼ同じ値がたった1行の計算で出てきます。一方でbatch sizeが大きくなるとtokenごとに違うexpertが選ばれるため, 読むexpertの数は増えていき, 最終的には全parameter(約30.5B, 61 GB)を読む $61\,\text{GB} / 4.0\,\text{TB/s} \approx 15\,\text{ms}$ に近づいていきます。Prefillでも多くのtokenが全expertに振り分けられるため, 読む重みの量としてはこちらに近くなります。ただしprefillは1度に多くのtokenを処理するので算術強度が高く, 計算律速になりえます。

1T parameter級のDense modelは重い

この見積もりを1T parameterのDense modelに当てはめてみます。BF16なら重みだけで2 TBです。

• そもそもGH200のHBM(96 GB)には乗りません。重みを置くだけでも最低21台が必要です。
• 仮に1台で全ての重みを読めたとしても, $2\,\text{TB} / 4.0\,\text{TB/s} = 0.5\,\text{s}$ で, 1 tokenに0.5秒かかります。
• 21台でtensor parallelにして帯域を束ねて21倍になったとして大雑把に見積もっても $2\,\text{TB} / 84\,\text{TB/s} \approx 24\,\text{ms}$ で, 通信を無視しても40 tokens/s程度が上限です。

FP8にしても半分になるだけなので, 1T級のDense modelを手元で動かすのはかなり無理があるということが, カーネルの詳細を一切知らなくてもわかります。

一方, Kimi K2のようなMoE modelは総パラメータが1T級でも, 1 tokenあたりに使われる(active)パラメータは32B程度です。1 tokenで読む必要がある重みはactiveな分だけなので, 見積もりの分子が30分の1以下になります。これが巨大モデルでMoEが主流になっている理由の1つであり, 使わないexpertをCPUメモリに逃がしておく expert offload という手法が成り立つ理由でもあります。

実例: FreeTokenの改善

最後に, 実際に見積もりがコントリビュートに繋がった例として, 私がFreeTokenを改善した時の話をします。FreeTokenは巨大なモデルを手元のマシンで動かすためのServing Engineで, MoE modelの一部expertをCPUメモリにoffloadし, GPU上にはよく使われるexpertだけをLRUでcacheしておく仕組みを持っています。cacheにないexpertが必要になると(cache miss), CPUメモリからGPUへexpertの重みを転送します。Interconnectの帯域幅によっては一部をCPUで実行したりもします。

見積もりと実測のズレに気づく

GH200でFreeTokenを使って計測していた時, decode中のcache missの回数と, 1回のmissで転送されるexpertの重みのサイズ(例えばBF16のQwen3-30B-A3Bなら1 expertあたり $3 \times 2048 \times 768 \times 2\,\text{B} \approx 9.4\,\text{MB}$)を掛けて転送量を計算し, それを転送にかかっている時間で割ってみました。すると実効帯域は約220 GB/sにしかなっていませんでした。GH200のCPU-GPU間はNVLink-C2Cで片方向450 GB/s, copy engineで単純にH2Dコピーした場合でも約418 GB/s出ることが計測できていたので, expertの転送は理論帯域の半分程度しか使えていないことになります。

ここで「GPU-CPU間の転送ってこんなものか」で終わらせず, 理論値と並べて見たことで, 明らかに改善の余地があるとわかりました。

原因: in-flightなリクエストが足りない

expertの転送は fast_index_copy_multi というzero-copyのgather kernelで行われていました。各threadはmapされたhostメモリから16 byteをloadして書き込み, それが終わってから次のloadを発行します。このため同時に飛んでいる(in-flightな)データ量は1 bankあたり

程度になり, 帯域はLittle’s lawによって

で決まります。デフォルトの blocks_per_bank=8 (1 bankあたり8192 threads)はPCIe(約31 GB/s)の環境でチューニングされた値でした。PCIeは帯域が小さいので, この程度のin-flight量でもレイテンシを隠して帯域を使い切れます。しかしNVLink-C2Cは帯域がずっと大きいので, 同じレイテンシを隠すにはそれに比例してより多くのリクエストを同時に飛ばす必要があります。

修正と結果

そこでNVLink-C2Cを持つホスト(GH200 / GB200 / GB300)では blocks_per_bank を32にするよう変更しました(PR #610)。最初はデバイス名の判定でCUDAが初期化されてしまい, CUDAの初期化をengine側が管理するという前提を壊してしまったため環境変数での指定に切り替えたのですが, レビューでengineがGPUを確保した後(_build_fused_copy_planの中)でデバイスを判定すればよいと提案をもらい, 最終的には自動判定と環境変数 FREETOKEN_H2D_BLOCKS_PER_BANK による上書きの両方に対応する形でマージされました。

copy engineによるH2Dコピーの上限(約418 GB/s)にほぼ並ぶところまで改善できました。変更自体は数行ですが, そもそも「この数字は遅い」と気づけたのは, cache miss回数と転送量から実効帯域を計算し, 理論値と並べて見たからです。

まとめ

• 見積もりは, 自分の実装が上限の何%を出せているかを知るためと, 計測ミスに気づくための両方で重要です。
• カーネルごとに $\max(F_k/P, B_k/W)$ を積み上げると, どこに伸びしろがあるかまで言える精密な見積もりができ, Nsight Systemsで答え合わせができます。
• 「重みは最低1回loadされる」という1行の見積もりだけでも, 1T級のDense modelが重すぎることや, MoE + offloadが有効な理由がわかります。
• 実効帯域を計算して理論値と比べる習慣が, 実際にOSSへの性能改善に繋がりました。

What this post covers

This post is mainly about what you should think about when you look at experimental data. You need this to judge whether a measurement is valid. I’ll go through how to check whether a measured number is really what it should be by comparing it with the catalog specs on the datasheet.

Hardware specs

Reasoning from the hardware specs

To keep things simple, the discussion below uses matrix multiplication. Given square matrices $A, B, C \in \mathbb{R}^{N \times N}$, consider the product

For $N = 512$, here are the results for a naive matmul, NumPy’s matmul, PyTorch’s matmul, and PyTorch’s matmul using Tensor Cores. Everything is FP32, and the code is in Materials (run it with run_all.sh).

So what can we tell from these results? First, the naive CPU code is the slowest. It’s simple code that even a freshman who just started programming could write; it looks like the code below. I won’t cover it in this post, but the other methods get their speed from techniques like loop unrolling, tiling, SIMD, shared memory and Tensor Cores.

void matmul(int n, const float *A, const float *B, float *C) {
    for (int i = 0; i < n; i++)
        for (int j = 0; j < n; j++) {
            float sum = 0.0f;
            for (int k = 0; k < n; k++) sum += A[i * n + k] * B[k * n + j];
            C[i * n + j] = sum;
        }
}

Now for the main topic. CPU (Numpy) certainly looks faster than the naive CPU matmul. But is this result optimal? In other words, does it get enough performance out of the hardware?

One yardstick is to compare against the theoretical FLOPS. A matmul takes $2N^3$ FLOPs, so the achieved FLOPS are

The naive CPU matmul reaches only 0.040% of the CPU’s theoretical 7.1 TFLOPS, so it’s fair to say it isn’t using the hardware. What about the others? Are they getting the performance out of the hardware? At this point most people would probably say no: CPU (Numpy) reaches 24% of 7.1 TFLOPS, GPU (Non Tensor Core) 23% of 67 TFLOPS, and GPU (Tensor Core) only 4.2% of 494 TFLOPS. Why is that? Are NumPy and PyTorch actually poorly optimized?

Roofline

Image from NERSC Documentation [2]

The tool for answering that question is the Roofline model. The “theoretical FLOPS” in a catalog spec is what you get when the arithmetic units run nonstop. A real program, however, has to bring the data for those units in from memory, and if the data supply can’t keep up, the units sit waiting. The Roofline model [1] shows in a single figure whether performance is limited by how fast you compute or by how fast you move data.

The Roofline equations

First, define the following quantities.

• $W$ [FLOP]: the number of floating-point operations the program performs
• $Q$ [Byte]: the amount of data the program moves to and from memory (here, RAM)
• $P_{\mathrm{peak}}$ [FLOP/s]: the hardware’s theoretical FLOPS
• $B$ [Byte/s]: the hardware’s memory bandwidth

Computation takes at least $W / P_{\mathrm{peak}}$, and data transfer takes at least $Q / B$. Even if computation and transfer overlap perfectly, the run time $T$ can’t be shorter than the slower of the two.

Rewriting this in terms of achieved FLOPS $P = W / T$ gives

where

is called the arithmetic intensity: how many operations you perform per byte of data you bring in. That’s all there is to the Roofline model. If you plot $I$ on the horizontal axis and $P$ on the vertical axis, both log-scale, the upper bound is a diagonal line of slope 1 ($I \cdot B$) joined to a horizontal line ($P_{\mathrm{peak}}$), which looks like a roof. That’s where the name Roofline comes from.

The point where the two lines meet,

is called the ridge point.

• A program with $I < I^{*}$ is memory bound. Faster arithmetic units won’t help; the bound is set by $I \cdot B$.
• A program with $I > I^{*}$ is compute bound. The bound is set by $P_{\mathrm{peak}}$.

So a measurement should be judged not against the theoretical FLOPS, but against the Roofline bound $\min(P_{\mathrm{peak}}, I \cdot B)$. Even if a memory-bound program reaches only 5% of the theoretical FLOPS, it’s getting the most out of the hardware if it’s close to $I \cdot B$.

The ridge point of GH200

Let’s compute the ridge points from the spec table at the top.

To be compute bound on Tensor Cores, you need 123.5 operations for every byte you read, or about 500 operations per FP32 value (4 bytes). Memory is very slow relative to the arithmetic units. This also explains why each new GPU generation puts so much weight on HBM bandwidth. And since algorithms that reuse each loaded value 100+ times are almost all matmul-like, you can see that most algorithms are memory bound.

Arithmetic intensity of matmul

Now let’s find the arithmetic intensity of $C = AB$. Each element of $C$ is a dot product of length $N$, with $N$ multiplies and $N$ adds, so

The data transfer $Q$, unlike $W$, depends on the implementation and the cache size, so it isn’t uniquely determined. So when evaluating hardware performance, we consider a lower bound $Q_{\min}$ that no implementation can go below. Since $Q \geq Q_{\min}$, the arithmetic intensity has an upper bound $I \leq I_{\max} = W / Q_{\min}$, and the Roofline bound becomes $P \leq \min(P_{\mathrm{peak}}, I_{\max} \cdot B)$.

The simplest lower bound is that you must read $A$ and $B$ at least once and write $C$ at least once (compulsory traffic). In FP32 (4 bytes) that is

and using only this bound,

From this alone, it looks as if the arithmetic intensity of matmul grows without limit as $N$ grows.

A lower bound from the red-blue pebble game

However, the $12N^2$ bound is achievable only when all three matrices fit in cache. When they don’t, data that was evicted from the cache has to be read back from DRAM. The question “how much data must move, at minimum, between a fast memory of capacity $M$ and an unlimited slow memory?” was formalized by Hong and Kung as the red-blue pebble game [3]. Red pebbles represent data in fast memory (cache), blue pebbles represent data in slow memory (DRAM), and at most $M$ red pebbles can be on the board at once. Under these rules, you ask for the minimum number of red↔blue swaps needed to finish computing the whole computation graph.

Hong and Kung showed that the data transfer of standard $O(N^3)$ matmul (excluding Strassen-like algorithms) is $\Omega(N^3 / \sqrt{M})$. Later, Smith et al. [4] gave a tight bound including constants: with $S$ words of fast memory, the transfer is asymptotically at least $2N^3 / \sqrt{S}$ words. Converting to bytes with $M$ [Byte] $= 4S$,

and the upper bound on arithmetic intensity is

So the correct conclusion is that the arithmetic intensity of matmul does not grow without limit with $N$; it is capped by the cache size, $\sqrt{M}$. $N/6$ is only valid under the condition that all three matrices fit in cache. Optimizations such as tiling are about bringing the actual $Q$ close to this lower bound.

Estimating this for GH200: the GPU side (H100) has a 50 MB L2 cache, giving $\sqrt{M}/8 \approx 880$ FLOP/Byte, and the CPU side (Grace) has a 117 MB L3 cache, giving $\sqrt{M}/8 \approx 1350$ FLOP/Byte. Both are well above the ridge points (123.5 at most), so as far as DRAM traffic is concerned, GH200 can make large matmuls compute bound if the cache is used well. The same argument, however, applies at each level of the hierarchy, “L2 ↔ shared memory” and “shared memory ↔ registers”. Smaller levels have a smaller $\sqrt{M}$, so the bandwidth at each level can also become the bottleneck.

Now, when $N$ is small enough that all three matrices fit in cache, $I_{\max} = N/6$ applies as is. The matrix size that crosses the ridge point, $N^{*} = 6I^{*}$, is

Revisiting the $N = 512$ results with Roofline

At $N = 512$, the three matrices total 3.1 MB, which fits easily in both the GPU’s L2 cache (50 MB) and Grace’s L3 cache (117 MB), so $I_{\max} = 512 / 6 \approx 85.3$ FLOP/Byte. The Roofline bounds are

• CPU: $\min(7.1\,\mathrm{T}, 85.3 \times 512\,\mathrm{G}) = 7.1$ TFLOPS (compute bound)
• GPU (Non Tensor Core): $\min(67\,\mathrm{T}, 85.3 \times 4.0\,\mathrm{T}) = 67$ TFLOPS (compute bound)
• GPU (Tensor Core): $\min(494\,\mathrm{T}, 85.3 \times 4.0\,\mathrm{T}) = 341$ TFLOPS (memory bound)

and the fraction of the Roofline bound achieved is shown below. I’ve been explaining all this with a lot of confidence, but it turns out NumPy and PyTorch’s regular FP32 kernel reach only 23–24%. I ran these experiments for the first time while writing this post, so this was a bit of a surprise.

Since $N = 512$ is smaller than $N^{*} = 741$, the Tensor Core case is memory bound and its bound drops to about 70% of the theoretical FLOPS (341 TFLOPS), yet it still reaches only about 6%. CPU (Numpy) and GPU (Non Tensor Core) also stay in the 20% range of their compute-bound limits. Roofline alone still doesn’t explain it.

Poor Tensor Core performance on small matmuls has also been raised as a problem in research. KAMI [5], presented at SC25, points out that while large GEMMs already run close to GPU peak performance, small and batched GEMMs still leave a lot of room for optimization. For small matrices, data exchange within a single thread block, that is, communication between registers and shared memory, limits performance. KAMI addresses this by bringing communication-avoiding (CA) matmul algorithms (1D/2D/3D), developed for distributed memory, inside a single GPU. It treats Tensor Cores as compute nodes, registers as local memory and shared memory as the communication channel, applying the transfer lower-bound argument above to each level of the memory hierarchy. You can see it as a concrete example of “the red-blue pebble game bound applies at every level of the hierarchy”.

What Roofline doesn’t show: fixed costs

Another factor Roofline doesn’t capture is fixed costs that don’t depend on problem size. On the GPU these include kernel launch (around 1–2 µs), PyTorch dispatch and synchronization; on the CPU, library call overhead and thread startup and synchronization (fork/join). Here I’ll just estimate the orders of magnitude.

At $N = 512$, putting the compute time $W / P_{\mathrm{peak}}$ and transfer time $Q_{\min} / B$ next to the measurements gives

On the GPU, compute and transfer take a few µs or less, yet the run takes over 10 µs. Moreover, the difference $T_0$ is about 12–13 µs for both FP32 and Tensor Cores, which shows a roughly constant cost that doesn’t depend on the arithmetic unit. The CPU likewise seems to carry a fixed cost on the order of 100 µs.

So consider a simple model with a fixed cost $T_0$:

To reach 80% of the theoretical FLOPS in the compute-bound regime, you need $W / P_{\mathrm{peak}} \geq 4T_0$, that is,

Plugging in the $T_0$ values above gives $N \approx 1200$ for CPU (Numpy), $N \approx 1200$ for GPU (Non Tensor Core) and $N \approx 2300$ for GPU (Tensor Core). The higher the theoretical FLOPS, the more work could have been done during the fixed cost, so hiding it takes a larger problem. $T_0$ isn’t really constant, so this is only an order-of-magnitude estimate, but it does show that “$N = 512$ is still too small to compare against the theoretical FLOPS”.

Achieved FLOPS across matrix sizes

Next, let’s look at measurements with varying $N$. The horizontal axis is the matrix size $N$, the vertical axis is achieved FLOPS, and the dotted lines are the theoretical FLOPS. You can see that the plots take a Roofline-like shape. During the experiments, the Claude Code I was using started optimizing the CPU matmul on its own, so I’ve included that result too: it’s CPU (NEON+OpenMP, 72 threads).

Every implementation gets faster as $N$ grows and eventually saturates. Comparing the saturated values with the theoretical FLOPS:

A few things stand out.

The GPU reaches about 80% of the theoretical FLOPS. GPU performance saturates around $N = 2^{11}$ for TF32 and around $N = 2^{10} \sim 2^{11}$ for FP32, which matches the order of the fixed-cost estimates above (about 2300 and 1200, respectively). For large enough $N$, the arithmetic intensity $N/6 \gg I^{*}$, so the workload is compute bound and the bound is the theoretical FLOPS. Even highly optimized libraries like cuBLAS almost never reach 100% of the theoretical FLOPS; 70–90% is a reasonable practical ceiling.

The naive implementation gets even slower at large $N$. The naive implementation reaches only about 4% of a single core’s theoretical 99.2 GFLOPS, and drops to 1.4 GFLOPS at $N = 2^{10}$. The innermost B[k * n + j] reads $B$ down a column with a stride of $4N$ bytes, so once the matrices no longer fit in cache, each 4-byte element costs a whole 64-byte cache line from memory. The actual $Q$ is then far larger than the lower bound $Q_{\min}$, and the actual arithmetic intensity is not $N/6$ but well below 1 FLOP/Byte. The naive implementation is a textbook memory-bound program, stuck on the diagonal line of the Roofline.

Summary

To judge whether a measurement gets the most out of the hardware, the following steps are a good way to think about it.

1. From the operation count $W$ and the lower bound on data transfer $Q_{\min}$, find the upper bound on arithmetic intensity $I_{\max} = W / Q_{\min}$. If the data doesn’t fit in cache, also take the red-blue pebble game bound into account.
2. From the catalog specs, find $I^{*} = P_{\mathrm{peak}} / B$ and decide whether the workload is memory bound or compute bound.
3. Compare the measurement not with the theoretical FLOPS but with the Roofline bound $\min(P_{\mathrm{peak}}, I_{\max} \cdot B)$.
4. If it’s far from the bound, check the implementation and improve it (though, of course, other factors may make further improvement impossible).

I hope this helps you reason about whether a single function you call every day is reaching its theoretical performance.

After reading this post, you should be able to answer questions like why memory bandwidth matters and how to estimate peak performance accurately!

Reference

[1] S. Williams, A. Waterman, D. Patterson, “Roofline: An Insightful Visual Performance Model for Multicore Architectures”, Communications of the ACM, 2009, https://doi.org/10.1145/1498765.1498785

[2] NERSC Documentation, Roofline Performance Model, https://docs.nersc.gov/tools/performance/roofline/

[3] J.-W. Hong, H. T. Kung, “I/O Complexity: The Red-Blue Pebble Game”, STOC, 1981, https://doi.org/10.1145/800076.802486

[4] T. M. Smith, B. Lowery, J. Langou, R. A. van de Geijn, “A Tight I/O Lower Bound for Matrix Multiplication”, arXiv:1702.02017, 2017, https://arxiv.org/abs/1702.02017

[5] H. Wang, Y. Du, S. Li, X. Tian, Q. Sun, W. Liu, “KAMI: Communication-Avoiding General Matrix Multiplication within a Single GPU”, SC ‘25, https://sc25.conference-program.com/presentation/?id=pap926&sess=sess285

このブログで話すこと

このブログは主に実験データを見たときに何を考えるべきかを書きます。これは実験データの計測結果の妥当性を考えるために必要です。計測結果が本当にこの計測値で良いのかをデータシートのカタログスペックと照らし合わせながら検証する方法を扱います。

ハードウェアのスペック

ハードウェアのスペック値から考察する

以下の議論では簡単のため, 行列積を扱うことにしましょう。正方行列$A, B, C \in \mathbb{R}^{N \times N}$が与えられた時に行列積を考えます。

$N = 512$の時にNaiveな行列積, Numpyの行列積, PyTorchの行列積, PyTorchの行列積でTensor Coreを使ったものの結果は以下の通りとなりました。精度は全てFP32のもので, 使用したコードはMaterialsにあります(run_all.shで実行)

さて結果からわかることはなんでしょうか?まずNaiveなCPUコードは最も遅いです。これはプログラミングを学びたてのFreshmenでも書けるような簡単なコードです。これは以下のようなコードとなっています。この記事では扱いませんがここから改善するためにloop unrolling, tiling, SIMD, shared memory, tensor coreというような手法で他の手法は高速化されています。

void matmul(int n, const float *A, const float *B, float *C) {
    for (int i = 0; i < n; i++)
        for (int j = 0; j < n; j++) {
            float sum = 0.0f;
            for (int k = 0; k < n; k++) sum += A[i * n + k] * B[k * n + j];
            C[i * n + j] = sum;
        }
}

さて本題です。確かにNaiveなCPU MatmulよりもCPU (Numpy)は早く見えます。しかしながらこの結果は最適なのでしょうか?要するに, この結果はハードウェアの性能を十分に引き出していますか?

1つの指標としては理論FLOPSを計算してみることでしょう, 行列積のFLOPsは$2N^3$ですから, それに基づいて計算すると

となります。確かにNaiveなCPU MatmulはCPUの理論FLOPS 7.1TFLOPSに対して0.040%の性能しか達成できていませんこれはハードウェアの性能を達成できていないと言ってよさそうです。それに対して他の結果はどうでしょうか?ハードウェアの性能を引き出せているでしょうか?この時点では答えはNoと答える方が多数派でしょう, CPU (Numpy)は理論FLOPS 7.1TFLOPSに対して24%, GPU (Non Tensor Core)は67 TFLOPSに対して23%, GPU (Tensor Core)は494 TFLOPSに対して4.2%しか達成できていません。これは何故でしょうか?実はNumpyもPyTorchも不十分な最適化が行われているのでしょうか?

Roofline

画像はNERSC Documentation [2]より取得

先ほどの疑問に答えるための道具がRooflineモデルです。カタログスペックに載っている「理論FLOPS」は, 演算器が休みなく動き続けた場合の値です。しかし実際のプログラムでは演算器に渡すデータをメモリから運んでこなければならず, そのデータ供給が間に合わなければ演算器は待たされてしまいます。Rooflineモデル [1] は, 計算の速さとデータを運ぶ速さのどちらが性能を律速するのかを1枚の図で示すモデルです。

Rooflineモデルの数式

まず以下の量を定義します。

• $W$ [FLOP]: プログラムが行う浮動小数点演算の回数
• $Q$ [Byte]: プログラムがメモリ(ここではRAM)との間で転送するデータ量
• $P_{\mathrm{peak}}$ [FLOP/s]: ハードウェアの理論FLOPS
• $B$ [Byte/s]: ハードウェアのメモリバンド幅

演算に必要な時間は少なくとも$W / P_{\mathrm{peak}}$, データ転送に必要な時間は少なくとも$Q / B$です。演算とデータ転送が理想的にオーバーラップしたとしても, 実行時間$T$はこの2つのうち遅い方を下回ることはできません。

達成FLOPS $P = W / T$に書き直すと

となります。ここで

は演算強度 (Arithmetic Intensity) と呼ばれ, 1 Byteのデータを運んでくる間に何回演算するかを表します。これがRooflineモデルの全てです。横軸に$I$, 縦軸に$P$を両対数でとると, 上限は傾き1の斜めの直線($I \cdot B$)と水平な直線($P_{\mathrm{peak}}$)を繋いだ屋根のような形になります。これがRoofline(屋根の線)という名前の由来です。

2本の線が交わる点

をRidge Pointと呼びます。

• $I < I^{*}$ のプログラムはMemory Boundです。演算器をいくら速くしても性能は上がらず, 上限は$I \cdot B$で決まります。
• $I > I^{*}$ のプログラムはCompute Boundです。上限は$P_{\mathrm{peak}}$で決まります。

つまり, 計測結果の良し悪しは理論FLOPSと比べるのではなく, Rooflineが与える上限$\min(P_{\mathrm{peak}}, I \cdot B)$と比べるべきです。Memory Boundなプログラムの達成FLOPSが理論FLOPSの5%しかなくても, $I \cdot B$に近ければそれはハードウェアの性能を引き出せていると言えます。

GH200のRidge Point

冒頭のスペック表からRidge Pointを計算してみます。

Tensor Coreを使う場合, Compute Boundになるには1 Byte読み込むごとに123.5回, FP32の値1つ(4 Byte)あたりに換算すると約500回もの演算が必要です。演算器の速さに対してメモリが相対的にとても遅いことがわかります。 このことから, GPUが世代を変わるごとにHBMの帯域幅を重視していることがわかると思います。また, 1つの値を読み込んで100回以上も同じ値を使い回すような演算というのは行列積のようなアルゴリズムがほとんどを占めているため, ほとんどのアルゴリズムはMemory boundであることがわかるでしょう。

行列積の演算強度

では行列積$C = AB$の演算強度を求めます。$C$の各要素は長さ$N$の内積で, 積と和がそれぞれ$N$回なので

です。一方でデータ転送量$Q$は$W$と違って実装とキャッシュの大きさに依存するので, 一意には決まりません。そこでハードウェアの性能を評価するときは, どんな実装でもこれより少なくはできない転送量の下限$Q_{\min}$ を考えます。$Q \geq Q_{\min}$なので演算強度には上限$I \leq I_{\max} = W / Q_{\min}$があり, Rooflineの上限も$P \leq \min(P_{\mathrm{peak}}, I_{\max} \cdot B)$と書けます。

最も素朴な下限は, $A, B$をそれぞれ少なくとも1回は読み込み, $C$を少なくとも1回は書き込まなければならないというものです (compulsory traffic)。FP32 (4 Byte) なので

となり, これだけを使うと

です。これだけを見ると, 行列積は$N$を大きくすればいくらでも演算強度が上がるように見えます。

Red-Blue Pebble Gameによる下限

しかし$12N^2$という下限は, 3つの行列が全てキャッシュに収まる場合にしか達成できません。キャッシュに収まらない場合, 一度キャッシュから追い出したデータをもう一度DRAMから読み直す必要が出てきます。この「容量$M$の高速なメモリと無限の低速なメモリの間で, 最低どれだけ転送が必要か」を定式化したのが, Hong と Kung によるRed-Blue Pebble Game [3] です。赤い石が高速メモリ(キャッシュ)にあるデータ, 青い石が低速メモリ(DRAM)にあるデータを表し, 赤い石は同時に$M$個までしか置けないというルールの下で, 計算グラフ全体を計算し終えるまでに必要な赤↔青の入れ替え回数の最小値を考えます。

Hong と Kungは, 通常の$O(N^3)$の行列積(Strassenなどは除く)の転送量が$\Omega(N^3 / \sqrt{M})$になることを示しました。その後Smithら [4] によって定数まで含めたタイトな下限が示されていて, 高速メモリに$S$ワード置けるとき転送量は漸近的に$2N^3 / \sqrt{S}$ワード以上になります。$M$ [Byte] $= 4S$ としてByteに直すと

となり, 演算強度の上限は

になります。つまり行列積の演算強度は$N$とともに際限なく増えるのではなく, キャッシュサイズ$\sqrt{M}$で頭打ちになるというのが正しい結論です。$N/6$は「3つの行列がキャッシュに乗る」という条件付きの値に過ぎません。tilingなどの最適化は, 実際の$Q$をこの下限に近づけるための工夫です。

GH200で見積もってみると, GPU側 (H100) のL2キャッシュは50 MBなので$\sqrt{M}/8 \approx 880$ FLOP/Byte, CPU側 (Grace) のL3キャッシュは117 MBなので$\sqrt{M}/8 \approx 1350$ FLOP/Byteです。どちらもRidge Point (最大でも123.5) を十分上回るので, GH200ではDRAMとの間の転送に関してはキャッシュを上手く使えば大きな行列積をCompute Boundにできます。ただし同じ議論は「L2 ↔ Shared Memory」「Shared Memory ↔ レジスタ」の各階層にも当てはまり, 容量の小さい階層ほど$\sqrt{M}$が小さくなるので, 階層ごとのバンド幅も律速要因になりえます。

さて, $N$が小さく3つの行列が全てキャッシュに収まる範囲では$I_{\max} = N/6$がそのまま使えます。Ridge Pointを超える行列サイズ$N^{*} = 6I^{*}$を計算すると

となります。

$N = 512$の結果をRooflineで見直す

$N = 512$のとき3つの行列の合計は3.1 MBで, GPUのL2キャッシュ (50 MB) にもGraceのL3キャッシュ (117 MB) にも十分収まるので$I_{\max} = 512 / 6 \approx 85.3$ FLOP/Byteです。Rooflineの上限を計算すると

• CPU: $\min(7.1\,\mathrm{T}, 85.3 \times 512\,\mathrm{G}) = 7.1$ TFLOPS (Compute Bound)
• GPU (Non Tensor Core): $\min(67\,\mathrm{T}, 85.3 \times 4.0\,\mathrm{T}) = 67$ TFLOPS (Compute Bound)
• GPU (Tensor Core): $\min(494\,\mathrm{T}, 85.3 \times 4.0\,\mathrm{T}) = 341$ TFLOPS (Memory Bound)

となり, Rooflineの上限に対する達成率は以下のようになります。ここまで自信ありげに解説してきたのですが, 意外とNumpyと普通のPyTorchのFP32 kernelが23~24%の性能しかでていないことがわかりました。これはブログを書くために今回初めて実験したのでちょっと驚きです。

ただ, $N = 512$は$N^{*} = 741$より小さいので, Tensor Coreの場合はMemory Boundとなり上限が理論FLOPSの約7割 (341 TFLOPS) に下がりますが, それでも達成率は6%程度です。CPU (Numpy) とGPU (Non Tensor Core) もCompute Boundの上限に対して2割台にとどまっています。Rooflineで考えてもまだ説明がつかないわけです。

小さい行列積でTensor Coreの性能が出ないことは研究でも問題として取り上げられています。SC25で発表されたKAMI [5] は, 大きなGEMMはすでにGPUのピーク性能近くに達している一方で, 小さな行列積やbatched GEMMにはまだ大きな最適化の余地があることを指摘しています。小さな行列では1つのthread block内でのデータのやり取り, すなわちレジスタとShared Memoryの間の通信が性能を律速します。KAMIはこれに対し, 分散メモリ向けに発展してきたcommunication-avoiding (CA) な行列積アルゴリズム(1D/2D/3D)を1つのGPUの中に持ち込みました。Tensor Coreを計算ノード, レジスタをローカルメモリ, Shared Memoryを通信路とみなして, 先ほどの転送量下限の議論を各メモリ階層に適用する発想です。先ほど述べた「階層ごとにRed-Blue Pebble Gameの下限が効く」ことの具体例とも言えます。

Rooflineに載らないもの: 固定コスト

もう1つ, Rooflineには載らない要因として問題サイズによらずかかる固定コストがあります。GPUであればカーネル起動(1~2μs程度)やPyTorchのディスパッチ, 同期, CPUであればライブラリ呼び出しやスレッドの起動・同期 (fork/join) などです。ここではオーダーだけ見積もってみます。

$N = 512$で, 演算時間$W / P_{\mathrm{peak}}$とデータ転送時間$Q_{\min} / B$を計測値と並べると以下のようになります。

GPUでは演算と転送にかかる時間は数µsかそれ以下なのに, 実行時間は10 µs以上かかっています。しかもFP32とTensor Coreで差$T_0$がどちらも約12〜13 µsとほぼ同じで, 演算器によらない一定のコストが乗っていることがわかります。CPUも同様に, 100 µsのオーダーの固定コストが乗っていそうです。

そこで固定コスト$T_0$を加えた簡単なモデル

を考えます。Compute Boundな領域で理論FLOPSに対して80%の効率を得るには$W / P_{\mathrm{peak}} \geq 4T_0$, すなわち

が必要です。上の$T_0$を代入すると, CPU (Numpy) で$N \approx 1200$, GPU (Non Tensor Core) で$N \approx 1200$, GPU (Tensor Core) で$N \approx 2300$となります。理論FLOPSが高いほど固定コストの間にこなせたはずの演算量が多くなるので, 固定コストを隠すにはより大きな問題が必要になるわけです。$T_0$は実際には一定ではないのであくまでオーダーの見積もりですが, 「$N = 512$は理論FLOPSと比べるにはまだ小さい」ことはわかります。

行列サイズを変えて達成FLOPSを見る

次に, 実際に$N$を変えて計測した結果を見てみましょう。横軸は行列サイズ$N$, 縦軸は達成FLOPS, 点線は理論FLOPSです。Rooflineのような図ができることがわかるかと思います。実験中, 私が使っているClaude Codeが勝手にCPUの行列積の最適化も始めたため, その結果も追加してあります。CPU (NEON+OpenMP, 72 threads)がそうです。

どの実装も$N$が大きくなるにつれて性能が上がり, やがて飽和します。飽和した値を理論FLOPSと比べると以下の通りです。

ここからいくつかのことが読み取れます。

GPUは理論FLOPSの約8割に達している。 GPUの性能はTF32で$N = 2^{11}$付近, FP32で$N = 2^{10} \sim 2^{11}$付近で飽和しており, 先ほどの固定コストの見積もり (それぞれ約2300, 約1200) とオーダーが合っています。また十分大きな$N$での演算強度は$N/6 \gg I^{*}$なのでCompute Boundで, 上限は理論FLOPSです。cuBLASのような高度に最適化されたライブラリでも理論FLOPSの100%に到達することはほぼなく, 70〜90%程度が実用上の上限と考えてよいでしょう。

Naiveな実装は大きな$N$で性能がさらに落ちる。 Naive実装は1コアの理論FLOPS 99.2 GFLOPSに対しても4%程度しか出ておらず, $N = 2^{10}$では1.4 GFLOPSまで落ちます。最内ループのB[k * n + j]は$B$を列方向に$4N$ Byteの間隔で飛び飛びに読むため, 行列がキャッシュに収まらなくなると1要素(4 Byte)を使うためにキャッシュライン(64 Byte)全体をメモリから読むことになります。このとき実際の$Q$は下限$Q_{\min}$よりはるかに大きく, 実際の演算強度は$N/6$どころか1 FLOP/Byteを大きく下回ります。Naive実装はRooflineの斜めの線に張り付いた, 典型的なMemory Boundのプログラムなのです。

まとめ

計測結果がハードウェアの性能を引き出しているかを判断するには, 以下の手順で考えるとよいでしょう。

1. 計算の演算量$W$とデータ転送量の下限$Q_{\min}$から演算強度の上限$I_{\max} = W / Q_{\min}$を求める。キャッシュに収まらない場合はRed-Blue Pebble Gameによる下限も考慮する。
2. カタログスペックから$I^{*} = P_{\mathrm{peak}} / B$を求め, Memory BoundかCompute Boundかを判定する。
3. 計測値を理論FLOPSではなくRooflineの上限$\min(P_{\mathrm{peak}}, I_{\max} \cdot B)$と比較する。
4. 上限から大きく離れている場合は, 実装を確認し, 改善を行う(もちろん, 別の要因によりこれ以上の改善が不可能なこともあります。)

普段呼び出している関数1つが理論的な性能を引き出せているのかを考察する助けになれば幸いです。

この記事を読んだ皆様は何故メモリ帯域幅が必要なのか, ピーク性能の正確な見積もりはどうするかなどを答えることができるようになっていることでしょう！

Reference

[1] S. Williams, A. Waterman, D. Patterson, “Roofline: An Insightful Visual Performance Model for Multicore Architectures”, Communications of the ACM, 2009, https://doi.org/10.1145/1498765.1498785

[2] NERSC Documentation, Roofline Performance Model, https://docs.nersc.gov/tools/performance/roofline/

[3] J.-W. Hong, H. T. Kung, “I/O Complexity: The Red-Blue Pebble Game”, STOC, 1981, https://doi.org/10.1145/800076.802486

[4] T. M. Smith, B. Lowery, J. Langou, R. A. van de Geijn, “A Tight I/O Lower Bound for Matrix Multiplication”, arXiv:1702.02017, 2017, https://arxiv.org/abs/1702.02017

[5] H. Wang, Y. Du, S. Li, X. Tian, Q. Sun, W. Liu, “KAMI: Communication-Avoiding General Matrix Multiplication within a Single GPU”, SC ‘25, https://sc25.conference-program.com/presentation/?id=pap926&sess=sess285

Whether it lasts depends entirely on my motivation, but for a while I’m going to write about the fundamentals of High Performance Computing, aiming for roughly one post a week. (That’s exactly why I picked Jekyll, so I could keep the blog going just by writing Markdown.)

By “fundamentals” I don’t mean “easy”; I mean the fundamental, basic stuff. The idea is to write, based on my own experience, about the walls I hit from joining a lab as a fourth-year undergrad through the second year of my master’s, and the mistakes I made because I was missing some basic way of thinking.

Why do this? Compared to web performance tuning like ISUCON, High Performance Computing doesn’t have many books or articles that cover it systematically. It feels like much of it is built on tacit knowledge shared among people in Japan who already know it, so I thought I’d try to write some of it down. That said, this is just the blog of a master’s student, so I’ll possibly write wrong things.

Another reason is that I want to write about CUDA Extended GPU Memory on this blog, and I want to first provide the background knowledge readers should have for that. Also, every time a new device or model comes out, I see a lot of people who just say “it’s so fast, it’s amazing,” so I’m hoping to see more discussion in Japan about why new devices enables the program much faster.

I’m assuming readers have the background of someone who has studied for four years in a computer science department. If you’ve taken courses on programming languages, operating systems, and basic algorithms, you should be fine.

Contents

I’ll list topics in the order they occur to me while writing. So far I’ve come up with two.

1. How to read experimental data and spec sheets

Next week I’ll mainly write about what you should think about when looking at experimental data. This is necessary for judging whether your measurements are actually valid. Using matrix multiplication as the example, the post will cover how to check whether a measured value really makes sense by comparing it against the catalog specs in the datasheet. After reading it, you’ll no longer be fooled by hype like “new-generation architecture” or “next-generation processor.”

Keywords: Bandwidth, FLOPS, and Roofline.

2. Modeling, hypotheses, and estimation

In “1. How to read experimental data and spec sheets,” we checked the validity of measurements for a single operation. In practice, though, unless you’re a CUDA kernel or SIMD tuning specialist, you rarely look at just one kernel; you’re trying to speed up the whole system. I’ll use concrete examples to explain how to approach that situation. I’ll also explain how to estimate lower and upper bounds for measured values.

Keywords: Profile, modeling.

After covering these two topics, I’ll move on to explaining CUDA Extended GPU Memory and LLM Serving.

長く続くかは本当に私のモチベーション次第なんですがしばらくの間は週一回を目安にHigh Performance Computingに関する基本的なことを書いていきます。(長く続けるためにMarkdownでBlogが更新できるJekyllにしたのだが)

基本的なことというのはEasyってことではなくて, Fundamental, もしくはBasicなことです。研究室に配属された4年生から修士の2年までにぶつかった壁とか基礎的な考えが抜けていたのでミスしてしまったことなどを実体験を踏まえながら書いていこう的なことです。

なんでこんなことをするのかというと, High Performance Computingに関することはISUCONなどのWebの高速化に比べて体系的なまとめられ方をされた本や記事がなく, 国内の既にわかってる人々の間で共有されている暗黙知のようなもので構築されていることが多いと感じているため, ちょっとまとめてみようと思ったためです。とはいいつつ所詮修士号(予定)の学生のブログなので間違ったことを書きうる可能性はあると思います。

あとはブログでCUDA Extended GPU Memoryについての発信をしていきたいのですが, そのために読者が頭に入れておいたほうが良い知識の提供をするためです。また, 新しいデバイスやモデルが出るたびにとにかく速い, すごいと言うだけの人を多く見かけるため, 何故早くなっているのかなどの議論が日本で増えてくれることを望んでいます。

前提知識はコンピューターサイエンス系の学科で4年間学んできた人を対象とします。プログラミング言語, Operating System, 基本的なアルゴリズムについての授業を受けたことがあればおそらく大丈夫かと思います。

コンテンツ

コンテンツは今ブログ書きながら思いついた順に並べていきます。今の所は2つテーマが思いつきました。

1. 実験データとカタログスペックの見方

来週は主に実験データを見たときに何を考えるべきかを書きます。これは実験データの計測結果の妥当性を考えるために必要です。記事中では行列積を題材に計測結果が本当にこの計測値で良いのかをデータシートのカタログスペックと照らし合わせながら検証する方法を扱います。この記事を読むことであなたは新世代アーキテクチャや次世代プロセッサーといったHypeに惑わされなくなります。キーワードとしてはBandwidth, FLOPS, Rooflineぐらいでしょうか

2. モデリングと仮説, 見積もり

1. 実験データとカタログスペックの見方では単一の演算についての計測結果の妥当性を検証しました。しかし実際にはCUDA KernelやSIMDチューニング屋さん以外は単一のカーネルのみを見ることはなく, システム全体の高速化をするはずです。このようなときにどう取り組むのかを具体例を使って説明していきます。また, 計測値の下限と上限を見積もる方法を説明します。キーワードとしてはProfile, モデリング

とりあえずこの2つに関してを解説してCUDA Extended GPU MemoryやLLM Servingについて説明していこうと思います。

Why I made it

• It started to feel like not having a proper portfolio site was getting a bit embarrassing.
• I wanted to write up my master’s research not only on arXiv but also on a personal blog.
• Until now I’d been posting on Note and Qiita, but blogging platforms these days are flooded with AI-generated content, so I decided to go back to a personal blog. Everything on this site is definitely checked by a human.
  • I do use AI to help with writing, but my policy is that any results or code are actually run and verified by me (as long as my motivation hasn’t run out).
• As of 2026 (who knows whether it’ll still be used in the future), there isn’t a single article, in Japan or elsewhere, that properly explains Unified Memory over NVLink-C2C, which is also slated for NVIDIA Vera Rubin, and I felt I had to get something written down.
• In particular, by some twist of fate I ended up working with CUDA Extended GPU Memory through both my undergrad and master’s, so I believe I have a thing or two to say about it.

Choosing the tech

• This portfolio site is built with Jekyll.
• There was a time when I was stuck on the idea that a portfolio site ought to be built with a modern framework like Next.js, got fed up, and never made one. But thinking about it calmly, my portfolio site needs no server-side rendering, no database, and no backend. What matters more is that my motivation doesn’t evaporate whenever I go to update it, so I went with Jekyll, which my former lab also uses. Now I can update the site just by writing Markdown. Thanks to the senior members of my lab!
• The design is based on the site of Lei Mao, which helped me enormously back when I was learning CUDA. Thank you! I’ve never met Lei Mao in person or interacted with them at all, but it’s no exaggeration to say that the experience of writing a GEMM from scratch that matches cuBLAS performance shaped my current research, my career path, and my engineering skills in high-performance computing.
• People who love programming contests like AtCoder probably only care about big-O notation for algorithms like matrix multiplication, but in real HPC, the hardware you use, memory bandwidth and the memory hierarchy, and even things like page size matter more than computational complexity. Speeding up GEMM on a GPU is a great subject for learning all of that.

作るに至った経緯

• まともなポートフォリオサイトがないと流石にまずい気がしてきた
• 修士時代の研究内容をArxivだけではなく個人Blogという形でまとめたくなった
• これまではNoteとかQiitaに記録していたが, 世の中のブログサイトはAI生成のもので埋め尽くされているために個人ブログへの回帰を試みた。このサイトは人間の手で内容のチェックが確実に加えられています
  • 執筆の助けでAIは使いますが, 実行結果やコードに関しては僕のやる気が消えてない限り実際に実行して確認するまでをポリシーとします
• 2026年現在のものなので, 将来使われるともわからないが, NVIDIA Vera Rubinでも採用予定のNVLink-C2CのUnified Memoryについてまともに解説された記事は日本と海外合わせてもなく, どうにかして書き残さねばならないと感じた
• 特に, CUDA Extended GPU Memoryに関しては何の因果か学部, 修士と関わることになったため, 一家言あると信じています。

技術選定

• このポートフォリオサイトはJekyllを使って作成されています。
• 過去ポートフォリオサイトはNext.jsとかのモダンなフレームワークを使って作成すべきだみたいな思想に囚われてめんどくさくなって作っていなかった時期もあったが, 冷静に考えて僕のポートフォリオサイトにサーバーサイドレンダリングもデータベースもバックエンドも必要ないのである。それよりも更新するときに自分のやる気が消えないほうが大事だと感じ, 出身研究室でも使われているJekyllを使って作成した。これによりマークダウンを書くだけでウェブサイトの更新ができるようになった。ありがとう弊研究室の先輩方
• デザインはかつてCUDAを学んでいたときに非常にお世話になったLei maoさんのサイトを参考にした。ありがとうございます。Lei maoさんと直接の対面はなく, 絡んだ経験もないのですがcuBLAS並みの性能を出すGEMMを1から書く経験が今の研究と進路や高速計算のエンジニアリング力を鍛えたと言っても過言ではありません。
• 行列積のようなアルゴリズムはAtCoderのようなプログラミングコンテストが好きな人間はビックオー記法しか気にしないと思うのですが, 本当のHPCには計算量以上に使うハードウェア, メモリ帯域幅/メモリ階層, はたまたページサイズなどが絡んできます。それを学ぶのに非常にいい題材がGPUでGEMMを高速化することです。