Research
LYR Performance Note #011 モデル

モデルを4分の1に圧縮しても、賢さはほぼ落ちない

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

2026-07-22 シリーズ第1回 7 min 量子化レイテンシコストGPU

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に縮む。

量子化前 重みの山(大) 4ビットに丸める INT4(4分の1) 重みの山(1/4) 1語を生成するたび、山を丸ごと1回読む。山が1/4 → 生成 1.8倍速・さばける量 4倍。
図1:量子化が効く仕組み。重みの山を4分の1に縮めると、1語ごとの読み出しが速くなり、同時にさばける量が増える。律速がメモリ帯域だから、レイテンシとコストが同時に下がる。

効果は連鎖する。

量子化前量子化後(INT4)
生成の速さ(compute)168 ms95 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つの落とし穴があった。

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

まとめ

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

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


付録:生データ

項目実測条件・留保
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量子化で評価する