70Bのモデルは16ビットで約140GB。GPU 1枚（例：80GB）に載らないモデルを、量子化（x ≈ s × q、ブロックごとのスケール）と、テンソル並列・パイプライン並列・データ並列でどう動かすのかを、図が動く形で一段ずつたどります。『GPUとLLM』第4章。
第3章では、文章を1トークンずつ作る速さが、重みをメモリから読む速さでほぼ決まることを見ました。この章ではその手前の問題、つまり重みがそもそもGPUのメモリに入らないときにどうするかを考えます。図のように、700億パラメータ（70B）のモデルを16ビットで持つと約140GB。青い箱で描いたGPU 1枚のメモリ（例として80GB）から、紫のバーが大きくはみ出します。
打つ手は大きく2つです。1つは、重み1つあたりのビット数を減らして全体を小さくする量子化。もう1つは、何枚ものGPUに分けて持つ並列化です。まず、メモリに何がどれだけ載るのかを足し算するところから始めます。
GPUのメモリに置くものは重みだけではありません。第2章で見たとおり、重みの容量は「パラメータ数 × 1個あたりのバイト数」で、70BモデルをBF16（1個16ビット＝2バイト）で持つと 700億 × 2 ＝ 140GB です。図の上の16個のマスが、重み1個ぶんのビットです。
これに、過去のトークンのK・Vを覚えておくKVキャッシュと、計算の途中で一時的に置く値（活性化など）が加わります。積み上げバーの紫が重み、橙がKVキャッシュ、緑が途中の値です。KVキャッシュは、たとえば1トークン約0.33MBのモデルで3.2万トークンぶん持つと約10GB。合計は約155GBで、青い箱を約75GBはみ出します。
量子化は、重み1個を表すビット数を減らすことです。16ビットを、8ビットの FP8（小さな浮動小数点数）や INT8（整数）にすると1個1バイトになり、重み全体は 700億 × 1 ＝ 70GB と半分になります。図の上のマスが16個から8個に減り、紫のバーも半分の長さに縮みました。
それでも、橙と緑を足した合計は約85GBで、箱の右端から約5GBはみ出しています。重みだけを見て「80GBに入る」と考えると、KVキャッシュや途中の値の分を忘れてしまいます。容量は、いつも足し算で考えるのが大事です。
さらに1個を4ビット（INT4 や FP4）まで減らすと、重みは 700億 × 0.5 ＝ 35GB、もとの4分の1です。紫のバーがさらに縮み、合計約50GBで青い箱の中に収まりました。赤かったはみ出しの線は、緑の「空き約30GB」に変わっています。この空きは、より長い会話や、同時にたくさんのリクエストを扱うためのKVキャッシュに回せます。
ただし、4ビットで表せる値は16通りしかありません。ビットを減らすほど元の値とのずれ（丸め誤差）が大きくなり、答えの質が落ちることがあります。どうやって16通りに押し込むのかは、速さへの効果を見たあとで確かめます。
第3章で見たように、1トークンずつ文章を作る decode はメモリ律速です。1トークンを作るたびに重みをほぼ全部メモリから読むので、速さの上限はおおよそ「メモリ帯域 ÷ 重みのバイト数」で決まります。
帯域 3.35TB/s（H100 の公表値）で計算すると、16ビットの140GBなら1トークンぶん読むのに約42ms、上限は毎秒約24トークンです。8ビットで読む量が半分になると上限は約2倍の約48トークン、4ビットなら約96トークン。図の3本のバーの長さが、そのまま1トークンぶんの読み込み時間です。実際には4ビットの値を計算用の形に戻す手間などがあるので、これは「これより速くはならない」という上限です。
では、16ビットの小数をどうやって4ビットに押し込むのでしょうか。基本の形は x ≈ s × q です。x がもとの重み、q が4ビットで表せる小さな整数（−8〜7 の16段階）、s はスケールと呼ぶ倍率で、いくつかの重みが1つの s を共有します。
s は、グループの中でいちばん大きな値が目盛りの端（7）に来るように決めます。図の8個の重みでは絶対値の最大が 0.42 なので、s ＝ 0.42 ÷ 7 ＝ 0.06。下の数直線の目盛りは0.06おきに並び、−8〜7 の16本が「4ビットで表せる値」のすべてです。上に並んだ紫の点が、もとの重みです。
各重みは、x ÷ s を四捨五入した整数 q に置き換えます。図では、上にあった紫の点が下の数直線に落ち、いちばん近い目盛りにぴたりと収まりました。上に残った白抜きの丸が、もとの値の場所です。
たとえば 0.10 は 0.10 ÷ 0.06 ≈ 1.67 なので q ＝ 2。戻すと 2 × 0.06 ＝ 0.12 で、0.02 だけずれます。これが丸め誤差です。目盛りの間隔が s なので、誤差はいつも s の半分（ここでは0.03）以内に収まります。保存するのは8個の q（各4ビット）と、s が1つだけです。
困るのは、飛び抜けて大きな値（外れ値）が混じっているときです。8個のうち1個が 2.1 だったとすると、s ＝ 2.1 ÷ 7 ＝ 0.30。目盛り1つぶんが表す幅が5倍に広がり、上の白抜きの丸は真ん中にぎゅっと寄りました。
その結果、残りの7個は −1・0・1 の3つの目盛りに押し込まれ、0.04 も 0.10 も −0.10 も同じ 0 になってしまいます。目盛りの上に縦に積み重なった点が、区別がつかなくなった値です。LLM の重みや計算途中の値には、こうした外れ値がときどき現れることが知られています。
そこで、重みを小さなブロックに区切り、ブロックごとに別々の s を持たせます。図では4個ずつ2つのブロックに分けました。外れ値のないブロック1は s ＝ 0.06 の細かい目盛りを使えて、粗くなるのは外れ値のいるブロック2だけです。実際には32個や128個ごとに区切ることが多く、外れ値の影響をそのブロックの中に閉じ込められます。
代わりに、s を保存する分だけ少し大きくなります。32個ごとに16ビットの s を1つ持つなら、1個あたり 16 ÷ 32 ＝ 0.5ビット増えて実質4.5ビット。70Bなら 35GB が約39GB になる程度で、守れる精度に比べれば小さな代償です。
量子化しても入らない大きなモデルや、品質のために16ビットのまま動かしたいモデルは、何枚ものGPUに分けて持ちます。分け方にはいくつか種類があり、最初に見るのは1つの行列を切り分けるテンソル並列です。
LLMの計算のほとんどは、入力 x に重み行列 W を掛ける y ＝ x × W でした（第2章）。図のように W を横向きの帯4本（行のまとまり）に分け、x も同じように4つに分けると、W1 は x1 とだけ、W2 は x2 とだけ掛け合わされます。つまり y は、4つの小さな掛け算 x1×W1 〜 x4×W4 を足したものです。
4本の帯がそれぞれ別のGPUへ移りました。各GPUは自分の担当分（GPU1なら x1 × W1）だけを計算すればよく、重みのメモリも計算も4分の1になります。ただし各GPUが作るのは、y と同じ長さの部分和 y1〜y4 です。本当の y を得るには、4つを足し合わせなければなりません。
全員の部分和を足して、その結果を全員に配る通信を all-reduce と呼びます。次の層もまた4枚で分けて計算するので、y は全員が持っている必要があるのです。なお W を縦（列）で分けると、各GPUは y の一部分を作るのでつなげるだけで済みます。実際の Transformer では両方を組み合わせて、通信の回数を減らしています。
all-reduce を、部分和をリング状に回して行うと、各GPUが送る量は約 2 × (p−1)/p × データ量 になります（p はGPUの数）。GPUを増やしても、データ量の2倍を超えません。たとえば4,096トークンぶんの y（約64MB）なら、4枚で1枚あたり96MBです。
問題は、それを運ぶ線の太さです。H100 どうしをつなぐ NVLink は片方向450GB/s（公表値は双方向で900GB/s）、一般的な PCIe Gen5 x16 は片方向約64GB/s。右の2本の線の太さの差が、その違いです。96MBなら約0.2msと約1.5msで、1層に2回、80層ぶん繰り返すと差は大きく開きます。だからテンソル並列は、太い線でつながった1台のサーバー（ノード）の中で使うのが普通です。
もう1つの分け方は、モデルを層の順に区切るパイプライン並列です。80層のモデルなら、GPU1が層1〜20、GPU2が層21〜40…と受け持ち、前のGPUの出力を次のGPUに渡します。渡すのは層と層のあいだの値だけなので通信は少なく、ノードをまたいで分けるのにも向いています。
ただし、そのままでは順番待ちが起きます。下の図は横が時間で、GPU2 は GPU1 が終わるまで何もできません。灰色の部分が待ち時間（バブル）で、4枚なら全体の4分の3がバブル。4枚あっても、同時に働いているのはいつも1枚だけです。
そこで、バッチを小さなマイクロバッチに分けて次々に流します。GPU1 は1つ目を渡したらすぐ2つ目に取りかかれるので、図のように色のマスが斜めにずれて重なり、灰色が減りました。全体の時間も、理想的には 4T から 1.75T に縮みます。
GPUの数を p、マイクロバッチの数を m とすると、バブルの割合は (p−1) ÷ (m＋p−1) です。p＝4 なら、m＝1 で 3/4、m＝4 で 3/7（約43%）、m＝16 で 3/19（約16%）。m を増やすほどバブルは小さくなります。推論では、別々のリクエストを次々に流して埋めることもできます。
データ並列は、同じモデルのコピーを何組も並べ、それぞれに別のデータを処理させる方法です。モデルが1枚（またはテンソル並列などで組んだ1組）に入るなら、組の数だけ多くのデータをさばけます。学習では、各組が計算した勾配を all-reduce で平均してから重みを更新します。MoE の専門家をGPUに振り分けるエキスパート並列もあり、第5章でも触れます。
学習はメモリの面でもずっと重くなります。Adam を混合精度で使うと、重みと勾配に加えて、FP32 の重みのコピーと2つの移動平均（m と v）を持つので、1パラメータ約16バイトが目安です。70Bなら約1.1TBで、16ビットの推論の8倍になります。
1枚のGPUに載らないモデルを動かすには、まず容量を足し算で見積もります。重みはパラメータ数 × バイト数で、そこにKVキャッシュと計算途中の値が加わります。
1つ目の手は量子化です。x ≈ s × q の形で重みを小さな整数に置き換え、ブロックごとのスケールで外れ値の影響を閉じ込めます。読むバイト数が減るので、メモリ律速の decode も速くなります。2つ目の手は並列化です。テンソル並列は行列を分けて all-reduce で足し合わせるので太い線のノード内で使い、パイプライン並列は層で分けてマイクロバッチでバブルを埋め、データ並列はコピーを並べて量をさばきます。
次の第5章では、最先端のモデルがメモリと待ち時間をさらに削るために使っている工夫を見ていきます。
