第1章 — トークン生成のメカニズム

LLM Primer VI: AIシステムのスケーリング を章ごとに紹介していくウォークスルー、第1回。LLMサービングの難問はほぼ全て一つの事実から派生する — トークンを生み出すループはメモリ帯域律速で、購入した高価な演算能力は99.7パーセントの時間を遊んで過ごす、という章です。

なぜこの章があるのか

LLMは稼働中、次トークン予測器をループで包んだものです。トークンが入り、次トークンに対する確率分布が出て、1つを選び、末尾に追加し、ループが再び回る。推論スタックのあらゆる興味深い性質 — バッチング、量子化、KVキャッシュ、投機的デコード、分離型サービング — はこのループを近くから見つめることから派生します。ループはコードパスを共有しながらハードウェアに正反対の負荷をかける2つのワークロードを隠しています。一方は演算律速。もう一方は帯域律速。同じH100の上で。同じ順伝播の中で。この分裂に正確な名前をつけるのが本書の第一手で、以降どの章もこのフレームを参照します。

ひとことで言うと: 自己回帰ループが逐次的なのは数学のせいであってソフトウェアのせいではない。そしてデコード局面は最先端アクセラレータの演算ユニットをほぼ完全に遊ばせる — 本書のあらゆる技法は、その遊休時間への応答である。

1.1 自己回帰ループは力ずくで逐次的である

トークン t+1 は、t までの全トークンの関数です。モデルは t+1 がサンプルされるまで t+2 を予測できません。t+2 の予測には t+1 が入力に含まれている必要があるからです。1つの系列について連続する2トークンの生成を並列化する巧妙なカーネルは存在しません。逐次的な性格は、計算の依存構造そのものによって強制されます。N トークンの補完にかかる実時間はしたがって1ステップの N 倍プラス固定オーバーヘッドです。本書で以降登場する最適化 — より大きなバッチ、軌道の先を読む投機、1ステップあたりの安価な算術 — は全て、「ループが1トークンずつ歩くしかないなら、どうやって各ステップを速く、または各バッチを大きくするか」という問いへの部分的な答えです。モデルには外部のスクラッチパッドもなく、思考するにはトークンを出力するしかありません。ループはモデルがより長く考えるための唯一の機構であり、それゆえチェーンオブソートも投機的デコードも同じ会計の内側に生きます。

1.2 プリフィルとデコードは正反対の形でチップに負荷をかける

ループは2つの局面を隠しています。プリフィルは最初の順伝播で、ユーザーのプロンプトを [batch, sequence_length, hidden_dim] の形で消費します。あらゆる行列積が系列位置の全てにまたがって同時に演算し、算術は系列長にスケールします。重みはHBMから1回だけ読まれ、多くの行に対して適用される。算術強度は高い。プリフィルは演算律速で、H100の989 BF16 TFLOP/sを使い切ります。デコードはそれ以降の順伝播全てです。入力形状は [batch, 1, hidden_dim] に潰れます。各層の重みは依然HBMから流し込まれますが、それに対して演算されるのは1行だけ。算術強度は3桁下がる。デコードはメモリ帯域律速です。70BモデルをBF16で回すと、2,000トークンのプロンプトへのプリフィルはチップの演算天井付近で走り、その直後の順伝播 — 最初のデコードステップ — は同じ140 GBの重みを読み出して1トークンを生み出します。チップは変わっていない。ワークロードが変わったのです。

1.3 1人のユーザーはH100の99.7パーセントを遊ばせる

帰結として、1人のユーザーによるリアルタイム生成は最先端アクセラレータにとって最悪ケースです。1台のH100 SXM上の70B BF16モデルはおよそ毎秒24トークンでデコードします — ユーザーには軽快な読み速度で、チップのHBM3帯域3.35 TB/sはトークンごとに140 GBの重みを流すために完全に飽和します。しかしその速度で演算ユニットが行うのは能力989 TFLOP/sのうちわずか3.36 TFLOP/sほど。演算利用率は0.34パーセント。物理チップの設定は間違っていません。全SMは全速で読んで掛け算していますが、テンソルコアは1枚の重みタイルに対して多くの行のタイルを消費するよう設計されていて、単一トークンの順伝播は1行しか与えない。演算能力の単位(ロードされたバイトあたりの演算)を、ワークロードが供給していないのです。誰かは依然としてチップ丸ごとに1時間4〜8ドルを払う。したがってLLMサービングの経済とは、駐車中の演算に仕事を見つけることの経済 — バッチングを通して、トークンごとの安価な帯域を通して、投機を通して、ワークロードとバランス点が一致するハードウェアを通して。

覚えておきたいこと: スペックシートに載るFLOP/sの値は、デコード中はほとんど無関係。スループットを決めるのはHBM容量(どれだけ大きなモデルが入るか)とHBM帯域(重みがどれだけ速くチップを流れるか)。ピークFLOP/sでカードを買うことは、間違った数字で買うということ。

第1章が敷いたもの

本書の残りは、ここで名指しした非対称性への応答です。第2章はKVキャッシュ — デコードが二次的な再計算を避けることを可能にし、その過程でサービングクラスタのVRAMを最も食う単一のデータ構造 — を分解します。第3章と第4章はそのハードウェア基盤を、帯域対演算のレンズで歩きます。第5章と第6章は重みを縮めることでトークンあたりの帯域負担を縮める。第7章はバッチングを、帯域律速の無駄をスループットに変えるシステムレベルのレバーとして歩きます。第8章と第9章はページ化KV管理と投機的デコードで仕事の形を変える。どの手も、この章で測ったばかりの遊休演算を埋めようとする試みとして読めます。

次回 — 第2章: KVキャッシュという課題。 デコードを経済的に成り立たせるワークスペース、そしてサービングクラスタが演算より先にVRAMを使い切る理由を説明するメモリ算式。

全体像を押さえたい方へ: 書籍版には貪欲生成ループの動くPython擬似コード、稼働システム上で数字を体感させる decode_regime と measure_decode_utilization ユーティリティ、そしてこの記事では要約に留めた「In Plain English」サイドバーが収録されています。Amazonで『LLM Primer VI』を見る →