この記事は、自社ブログの 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 / 記事一覧 にあります。