ローカル LLM や GPU 推論速度テストを見始めると、すぐに FA、pp512、tg128、Q4_0 といった略称に出会います。どれも性能指標のように見えますが、文脈がないとかなりわかりにくいです。
たとえば、次のような行を見かけることがあります。
|
|
さらにその下には、
|
|
のような表示が並びます。
これらを分解して理解しないままだと、この種の速度テストが何を測っているのか、また異なる GPU の結果をどう比較すべきかが見えてきません。
この記事では、どの GPU を買うべきかではなく、GPU 推論速度テストでよく出てくる指標そのものを整理します。
まずタイトル行全体が何を言っているのか
CUDA Scoreboard for Llama 2 7B, Q4_0 (no FA) のような一行には、すでにかなり多くの前提が含まれています。
少なくとも次の四つの情報があります。
CUDA: NVIDIA GPU の CUDA 経路で測っているLlama 2 7B: テスト対象はLlama 2の7BモデルQ4_0: モデルは 4-bit 量子化形式no FA:Flash Attentionを有効にしていない
つまりこれは要するに、
「NVIDIA GPU 上で、ある量子化済み LLM を、特定の推論経路で動かしたときの速度テスト」
という意味になります。
FA とは何か: Flash Attention
ここでいう FA は Flash Attention の略です。
これは大規模モデルの学習や推論で非常に重要な最適化のひとつで、主に Attention 計算の実装を高速化するための技術です。Transformer 系モデルでは、Attention 部分が最も重い処理のひとつだからです。
従来の Attention 実装には次のような問題があります。
- グローバルメモリの読み書きが多い
- 中間結果が増えやすい
- メモリと演算コアの間でデータ移動が多い
- コンテキストが長いほど負担が重くなる
Flash Attention は計算順序を工夫し、より多くの処理を高速なメモリ階層の中で完結させることで、この負担を減らします。
その典型的な効果は次の三つです。
- 速くなる
- メモリ使用量が減る
- 数学的には通常の Attention と等価で、精度を落とす近道ではない
そのため、現在の推論・学習系フレームワークでは重要な最適化として扱われています。
no FA とは何か
FA が Flash Attention なら、no FA は単純に Flash Attention を使っていないという意味です。
つまり、そのベンチマークはより伝統的な Attention 実装で測られています。
なぜわざわざ no FA と書くのかというと、主に次の理由があります。
- 比較用の基準として残したい
- ハードウェアやソフトウェアの都合で
FAを使えないケースがある - 条件の違うスコアを混ぜて読まれないようにしたい
したがって no FA は「GPU が弱い」という意味ではありません。より正確には、
「このスコアは Flash Attention を使わない条件で測られた」
という意味です。
Q4_0 とは何か: 量子化形式
Q4_0 は 4-bit 量子化形式のひとつです。
LLM の元の重みは通常、こんな低精度では保存されていません。そのままではサイズが大きすぎるため、量子化によって重みをより少ない bit 数で表現し、一般的な GPU でも動かしやすくします。
ざっくり言えば、
Q: Quantization4: 4-bit_0: 具体的な量子化方式の識別
という理解で十分です。
重要なのは、量子化によって
- モデルサイズが縮む
- VRAM 要求が下がる
- そのままでは載らないモデルも動かしやすくなる
という点です。
つまり Llama 2 7B, Q4_0 は、「7B モデル」ではあるものの、「4-bit 量子化された 7B モデル」を意味しています。
pp512 t/s とは何か
pp512 は通常、
Prompt Processing 512 tokens
を意味します。
これは入力プロンプトを処理する速度の指標で、単位は t/s、つまり tokens per second です。
ここでの 512 は、テスト時の入力長が 512 token だったことを表しています。
この指標が測っているのは「しゃべる速さ」ではなく、モデルが回答を始める前に、入力内容を読み込んで計算する速さです。言い換えると、「まずこちらの入力を読む段階」のスループットです。
この段階の大きな特徴は、並列性が高いことです。
入力系列はまとめて処理しやすいので、GPU はこの場面では高い並列度を活かせます。そのため pp512 の値は非常に大きくなることが多く、初めて見ると少し不自然に感じるほどです。
たとえば
|
|
のような値が出ても不思議ではありません。これは「入力処理の吞吐量」を測っているのであって、逐次生成の速さを測っているわけではないからです。
tg128 t/s とは何か
tg128 は通常、
Text Generation 128 tokens
を意味します。
これは 128 token を連続生成したときの平均生成速度で、同じく単位は t/s です。
この指標は、私たちが普段感じる「モデルの返答速度」により近いです。実際に出力フェーズを測っているからです。
ただし pp512 との最大の違いは、テキスト生成が一般に自己回帰的であることです。
つまり、
- まず 1 個目の token を出す
- それが決まってから 2 個目を出す
- さらにその後に 3 個目を出す
という順番になります。
そのため、入力処理のような大規模並列はかけにくく、速度はずっと低くなります。
だからこそ、
pp512は数万t/stg128は数百t/s
といった差が普通に起こります。
これは測定ミスではなく、そもそも別の性質の処理を測っているためです。
なぜ pp512 と tg128 の差がこんなに大きいのか
ここは多くの人が最初に引っかかるポイントです。
一言で言えば、
pp512 は並列吞吐、tg128 は逐次生成性能を見ているからです。
もう少し丁寧に言うと、
- 入力処理は並列化しやすい
- 出力生成はトークンごとの逐次性が強い
- 生成側はメモリ帯域やキャッシュ効率の影響を受けやすい
- そのため生成速度は入力処理よりかなり低くなりやすい
これにより、GPU 間比較でも面白い現象が起きます。
pp512では一方が勝つtg128では別の GPU が少し速い
ということがあり得るのです。
これは矛盾ではなく、一方がピーク算力寄り、他方が実際の生成経路での帯域・遅延特性に左右されているからです。
t/s はどう読むべきか
t/s は tokens per second の略です。
つまり、モデルが 1 秒あたりに何 token を処理または生成できるかを表しています。
ただし注意したいのは、token は「文字」でも「単語」でもなく、モデルのトークナイザが切る単位だということです。モデルや言語によって、1 token が表すテキスト量はかなり変わります。
そのため t/s は主に次の用途に向いています。
- 同一モデル内で GPU を比べる
- 同じ環境で設定違いを比べる
- 同一フレームワークで最適化の有無を比べる
逆に、モデルもフレームワークもトークナイザも違う条件をまたいで、絶対値だけで単純比較するのにはあまり向いていません。
Scoreboard を読むときにまず押さえるべき点
毎回略称に埋もれたくないなら、まず次のポイントから見れば十分です。
1. テスト対象モデルは何か
たとえば Llama 2 7B なのか、量子化形式は Q4_0 なのか。同じモデル・同じ量子化でなければ、結果の横比較はあまり意味を持ちません。
2. 重要な最適化が有効かどうか
もっとも典型的なのが FA です。一方は Flash Attention を有効にしていて、もう一方は無効なら、そのスコアは単純には比較できません。
3. 入力速度を見ているのか、出力速度を見ているのか
pp512 と tg128 は別物です。前者は「読み込みの速さ」、後者は「しゃべる速さ」に近いです。
4. 吞吐を見たいのか、体感を見たいのか
長いプロンプトの立ち上がりを重視するなら pp512 が参考になります。実際の返答の滑らかさを気にするなら、tg128 の方が体感に近いことが多いです。
もっとも実用的な覚え方
これらを一番短く覚えるなら、次のように整理すると実用的です。
Q4_0: モデルは 4-bit 量子化されているFA: Flash Attention を使っているかどうかpp512: 512 token の入力処理速度tg128: 128 token の出力生成速度t/s: 1 秒あたり何 token か
この五つだけ分かっていれば、似たような CUDA Scoreboard を見たときに、単に「どちらの数字が大きいか」ではなく、「その数字は何を測っているのか」を理解しやすくなります。
結び
GPU ベンチマーク表が難しく見えるのは、指標そのものが神秘的だからではありません。モデル名、量子化、最適化の有無、入力処理と出力生成という別々の吞吐が、短い略称に圧縮されているからです。
FA、Q4_0、pp512、tg128 を順に解きほぐしていけば、こうした Scoreboard は実はそれほど難しくありません。
本当に大事なのは、GPU 名だけを見て終わらないことです。つまり、
- どのモデル条件で測ったのか
- 最適化は有効か無効か
- 入力を測っているのか、出力を測っているのか
- 算力寄りなのか、実際の生成体感に近いのか
を一緒に見ることです。
そうすれば、似たようなベンチマーク表を見ても、その結果がどんな条件と意味を持っているのかを判断しやすくなります。