この記事は、自社ブログの LYR Performance Note #011 に掲載したものの転載です。

量子化が、コストとレイテンシを同時に下げる仕組み

AIの生成が遅いのは、計算が重いからではない。モデルの重みを読み出すメモリ帯域が律速だからだ。

だから重みを4分の1に詰め直す（量子化する）と、レイテンシとコストが同時に下がる。実測で生成 168→95ms、さばける量は4倍、品質は −1pt。速さを決めているのはパラメータ数ではなくバイト数だった。

ただし条件がある。速度はデプロイと同じ経路で測らないと差が消え、量子化は微調整の効果を削る。測り方を揃えないと、この勝ちは幻になる。

第5回で、自前のGPUに「量子化」をかけると、生成が168ms→95msに速くなり、さばける量が4倍になった、と書いた。安価なGPUが、高価なデータセンター級GPUに匹敵する性能を出す。しかも品質はほぼ落ちない。

なぜ、そんな都合のいいことが起きるのか。ここを分解しておく。

本当のボトルネックは「計算」ではなく「メモリ」

まず、LLMが文章を作る仕組みを押さえておく。LLMは、答えを一気に吐き出すのではない。単語（トークン）を、1つずつ順番に生成する。毎回、「ここまでの文脈から、次に最もありそうな単語は何か」を確率的に予測して、1語を選ぶ。それを何十回も繰り返して、文ができあがる。

そして、AIモデルの正体は、巨大な数字の山だ（"重み"と呼ぶ）。1語を生成するそのたびに、GPUはこの山を丸ごと1回、メモリから読み出す必要がある。100語の文なら、山を100回読み直すことになる。

意外なことに、律速しているのは掛け算の速さ（計算）ではない。その山をメモリから読み出す速さ（メモリ帯域）だ。数字の山が大きいほど、1単語ごとの読み出しに時間がかかり、生成が遅くなる。GPUの計算ユニットは、たいてい、データが届くのを待っている。

つまり、生成を速くしたければ——山を小さくすればいい。

量子化＝数字を、粗く詰め直す

量子化は、その山の一つひとつの数字を、より少ないビット数で保存し直す技術だ。たとえば 3.14159… を 3.14 に丸めるように、32ビットや16ビットで持っていた数字を、4ビットで持つ。

すると、数字の山は4分の1〜8分の1に縮む。

図1：量子化が効く仕組み。重みの山を4分の1に縮めると、1語ごとの読み出しが速くなり、同時にさばける量が増える。律速がメモリ帯域だから、レイテンシとコストが同時に下がる。

効果は連鎖する。

	量子化前	量子化後（INT4）
生成の速さ（compute）	168 ms	95 ms
さばける量	2,200 req/分	9,600 req/分（約4倍）
品質（合格率）	基準	−1pt（ほぼ無劣化）

レイテンシが下がる: 山が小さいので、1単語ごとの読み出しが速い。
コストが下がる: 1台のGPUで4倍の量をさばけるので、リクエスト1件あたりの固定費が4分の1になる。
精度はほぼ落ちない: 数字を粗くしても、モデルの答えはほとんど変わらない（合格率で−1ポイント）。

「レイテンシとコストは、たいていトレードオフだ」と思われがちだが、量子化は両方を同時に下げる。山を小さくすることが、速さと安さの共通の原因だからだ。

（正確には、生成の"速さ"が4倍でなく1.8倍にとどまるのは、バイト数に比例するのは重みを読む時間だけで、計算そのものや固定のオーバーヘッドは残るからだ。一方、1台で"さばける総量"＝スループットは、山が1/4になった分ほぼ4倍に伸びる。だから、速さ1.8倍・量とコスト4倍、と効きどころが分かれる。）

（余談だが、これは「レイテンシは重みのバイト数で決まる」という原則の裏返しでもある。だから、たとえば"大きめのモデルを強く量子化する"のと"小さめのモデルを軽く量子化する"が、同じバイト数ならほぼ同じ速さになる。パラメータ数ではなく、バイト数で考える。）

なぜ、粗くしても賢さが落ちないのか

直感に反するが、数字を粗くしても答えがほとんど変わらないのには理由がある。モデルの判断の大半は、余裕を持って下されている（どの単語を選ぶか、確信度に大きな差がある）。数字を少し丸めても、その大勢は動かない。

劣化が出るのは、もともと僅差だった一部の判断だけ——全体の1割弱の"きわどい"ケースに集中する。しかも、その1割弱は"影響を受けうる"というだけで、実際に答えが変わるのはさらにその一部だ。だから平均品質は−1ポイントで済む。（この"きわどい"部分の崩れ＝最悪ケースを抑えるための追加の工夫もあるが、それは別の話だ。）

そもそも、この小さなモデルが特定のタスクで発揮する"賢さ"そのものは、次回の微調整（SFT・CPO）で作り込むものだ。量子化は、その作り込んだ賢さを、ほぼ削らずに、速く・安くするための技術——だから両者はセットで効く。

正しくやらないと、効果が消える

ただし、量子化は「かければ得」という単純な話ではない。実務では、2つの落とし穴があった。

測定は、必ずデプロイする仕組みで。 量子化の速度メリットは、専用の高速な実行経路（カーネル）を通したときだけ出る。素の環境で測ると「速くならない」と誤結論する。
微調整（次回）と、量子化の噛み合わせに注意。 後述する専門特化の微調整（fine-tune）は、モデルに"薄く広く"効く。強い量子化は、それを最初に削ってしまうことがある。だから、微調整と量子化は、同じ条件で揃える必要がある。評価も、必ず本番の量子化で行う。

まとめ

律速は計算ではなく、メモリ帯域だ。 生成のレイテンシを決めているのは、重みの山を読み出す速さ。だから速さは「パラメータ数」でなくバイト数で決まる。
量子化は、レイテンシとコストを同時に下げる。 山を4分の1に縮めても精度はほぼ落ちない。損失は"きわどい"判断に局在し、訳の骨格は保たれる。
測り方を揃えないと、この勝ちは幻になる。 速度はデプロイと同じ経路でのみ発現し、量子化は微調整の効果を削る。学習と評価を、本番と同じ量子化で揃える。

これで、自前の小さなモデルは速く・安くなった。だが、それだけでは片手落ちだ。小さいモデルは、そのままでは上位モデルに品質で負ける。残る半分——そのモデルを賢くする話は、次回へ。

付録：生データ

項目	実測	条件・留保
INT4（GPTQ-Marlin, RTX 4090）	生成 compute 168→95ms、decode 91→166 tok/s、さばける量 2,200→9,600 req/分（4倍）	品質 −1pt（base-INT4 vs FP16, n=100）
重みバイト律速	4B-INT8 ≈ 8B-INT4（ほぼ同バイト＝ほぼ同速）	decode latency ∝ 重みバイト数（batch1・帯域律速）
劣化の局在	損失は低マージンの"きわどい"判断（≈1割弱）に集中	高確信の大勢（訳の骨格・語調）は保持
落とし穴	速度はデプロイkernelでのみ発現／量子化は微調整効果を削る	素のtransformersでは差が消える。quant-aware学習＋deploy量子化で評価する

シリーズ「モデル — 小さく、速く、賢く」第1回の記事です。原文と続きは LYR Performance Note #011 / 記事一覧にあります。