量子化とは何か

「重み」とは、学習で決まった数値の集まり

言語モデルが文章を書く処理は、突き詰めると掛け算と足し算の繰り返しです。入力された文字列は数値の列に変換され、その列に対して巨大な行列の掛け算を何十層も通していきます。そのとき掛ける側の定数が 重み（weight）、別名 パラメータです。

重みは学習（事前学習・ファインチューニング）のあいだに決まり、推論中は一切変化しません。だからこそファイルとして配布でき、ダウンロードして手元で動かせます。あなたが Hugging Face からダウンロードしている数 GB のファイルは、この「決まりきった数値の集まり」そのものです。

重みはバラバラに保存されるのではなく、テンソル（tensor、= 多次元の数値配列）という単位でまとまっています。ある層で行列積に使う重みなら「入力 4096 × 出力 4096 の 2 次元テンソル」といった形です。GGUF や safetensors といったモデルファイルは、名前の付いたテンソルを何百個も並べた入れ物にすぎません。

モデル名の 7B / 8B / 70B の B は billion（10 億）で、この重みの個数を表します。Llama 3.1 8B は正確には 8,030,261,248 個（約 80.3 億個）です。「8B」は大まかに丸めた呼び名で、サイズ計算のときは実際の数値を使います。どのテンソルがどの役割を担い、なぜ層によって量子化への強さが違うのかは第 4 章で扱います。

サイズは「個数 × 1 個あたりのバイト数」で決まる

重みの個数が分かれば、ファイルサイズは掛け算だけで計算できます。必要なのは「1 個の数値を何ビットで表すか」という情報だけです。

重みのサイズ（バイト） = パラメータ数 × 1 個あたりのビット数 ÷ 8

コンピュータが小数を扱う既定の形式は FP32（32 ビット浮動小数点 = 4 バイト）ですが、言語モデルの世界では 16 ビットの FP16 / BF16（2 バイト）で配布されるのが標準です。この 16 ビットをどう符号・指数・仮数に配分しているかは第 2 章で詳しく解説します。

Llama 3.1 8B を FP16 で置いた場合の計算例です。

8,030,261,248 × 16 ÷ 8 = 16,060,522,496 バイト ≒ 16.1 GB

この計算が正しいことは実物で確認できます。llama.cpp 公式リポジトリが公開している Llama-3.1-8B の実測値では、F16 の GGUF は 14.96 GiB です。GiB（2 進、1024 の 3 乗）を GB（10 進、1000 の 3 乗）に直すと 14.96 × 1.0737 = 16.06 GB で、上の計算例とぴったり一致します。ここは初心者が確実につまずく所なので先に注意しておくと、GB と GiB は 7% 以上ずれます。そして GPU の「16GB」という表示は事実上 GiB のことです。

この掛け算は 70B でも同じです。Llama 3.1 70B のパラメータ数は 70,553,706,496 個なので、FP16 なら 141.1 GB（計算例）。この数字を覚えておくと、次の節の話がより実感できるようになります。

手元のメモリはどれくらいあるのか

推論を GPU で行うには、重みが VRAM（GPU 専用メモリ）に載っている必要があります。Mac の Apple Silicon はユニファイドメモリなので CPU と GPU が同じメモリプールを共有しますが、いずれにせよ「載る容量」に上限があります。ベンダーの公式スペックからまとめると次のとおりです。

並べてみると事情がはっきりします。比べるときは単位を GiB に揃えます（GPU の「16GB」表示は実質 16 GiB）。8B の FP16 は重みだけで 14.96 GiB あり、16 GB の GPU に置くと残りは 1 GiB ほどしかありません。重み以外に KV キャッシュ（会話履歴を覚えておく領域）と作業領域が必要なので、この 1 GiB では足りず、まともには動きません。24 GB の RTX 4090 でようやく余裕が生まれ、70B の FP16（141.1 GB = 131.4 GiB）は個人が買えるどの GPU にも載りません。必要メモリの見積りは第 8 章で計算式としてまとめます。LM Studio 公式のシステム要件が「16 GB 以上の RAM を推奨」「専用 VRAM は少なくとも 4 GB を推奨」と記載しているのも、この計算から導かれる結論です。

入らなかったときは、単に動かなくなるのではなく激しく遅くなります。llama.cpp の公式ドキュメントは、GPU に載りきらない層は「comparatively slower system RAM」で動くことになり、最後の手段として GPU 層数を減らせば「inference will be much slower」になると明記しています。つまり「入るか入らないか」は 1 割の性能差ではなく、体験が別物になる境界です。

量子化とは、1 個あたりのビット数を減らして書き直すこと

ここまでの整理から、削れる余地は 1 か所しかないことが分かります。パラメータの個数は決まっています。それなら「1 個あたりのビット数」を減らすしかありません。それが量子化です。

量子化（quantization）とは、学習済みの重みを、元より少ないビット数で表せる値の集合へ写し取って保存し直す、不可逆な圧縮のことです。

Hugging Face Transformers 公式の量子化ドキュメントも同じことを述べています。「量子化は、精度をできるだけ保ちながら重みを低精度で保存することで、モデルのロードと使用に必要なメモリを削減する」。ポイントは不可逆だという点です。16 ビットで書き分けられる値は最大 65,536 通り（= 2 の 16 乗）ですが、4 ビットで書けるのは 16 通りしかありません。65,536 通りを 16 通りに押し込むことになるため、元の値には二度と戻せません。この「元の値と、書き直したあとの値の差」を 量子化誤差（quantization noise） と呼びます。HF 公式はトレードオフの本質をこう書いています。「量子化の主要なトレードオフは効率 vs 精度である。精度を落とせばリソースは節約できるが、必然的に小さな誤差、すなわち量子化ノイズが混入する」。

65,536 通りを 16 通りに削っても文章が書けてしまう理由は第 4 章、どんな計算で写し取るのか（スケールと丸め）は第 3 章で扱います。この章では、その前提となる「何が起きているのか」をしっかり押さえておきます。

もう一つ、最初に押さえておくべき事実があります。ローカル LLM で主流なのは 重みだけを量子化する方式（weight-only 量子化）で、計算そのものは 16 ビットに戻してから行います。4 ビットで保存されているのは「メモリの上での姿」であって、行列積の最中の姿ではありません。

この図は 2 つのことを同時に説明しています。精度が思ったより落ちないのは、計算が 16 ビットで行われるからです。そして速くなるとは限らないのは、真ん中の逆量子化という手間が毎回増えるからです。活性化（層の途中を流れる数値）まで 8 ビットにする方式は別物で、第 5 章と第 7 章で扱います。

何が変わるか — ファイルサイズ、必要メモリ、速度の上限

実物の数字を先に見てしまいましょう。llama.cpp 公式リポジトリが公開している Llama-3.1-8B の実測値です。Q8_0 や Q4_K_M という名前の読み方は第 6 章で一文字ずつ解説しますが、ここでは「8 ビット級」「4 ビット級」と考えて問題ありません。

ここで名前と実効ビット数の違いに注目してください。Q4_K_M の実効は 4.0 ではなく 4.8944 bits/weight です。差の約 0.9 ビットは、量子化に必要な補助情報（スケール）や、テンソルごとに異なるビット幅を組み合わせていることによるものです。図 1-1 の「理論値 4.0 GB」に対して実物が 4.58 GiB（= 4.92 GB）になるのはこのためです。名前の数字で見積もると、Q4_K_M なら約 2 割、Q2_K なら 4 割近くも容量が不足することになります（上の実効 bits/weight から計算）。この 0.9 ビットの正体は第 3 章と第 6 章で詳しく解説します。

この表と図から、変わるものは 3 つに整理できます。

• ファイルサイズ — ダウンロード量とディスク使用量がそのまま減る。8B なら 14.96 GiB が 4.58 GiB に
• 必要メモリ — 重みが占める VRAM が減り、空いた分を KV キャッシュ（= 扱えるコンテキスト長）に回せる
• 速度の上限 — 1 トークン生成するたびに全部の重みを読むので、読む量が減れば上限が上がる

3 つ目には一次情報の裏付けがあります。NVIDIA の技術文書は、トークンを 1 つずつ生成する decode フェーズについて「データ（重み・キー・バリュー・活性化）がメモリから GPU へ転送される速度がレイテンシを支配する。計算がどれだけ速いかではない。言い換えれば、これはメモリ律速の処理である」と述べ、さらに「量子化は同じ帯域でより多くのパラメータを転送できることを意味し、帯域律速なモデルの加速に役立つ」と続けます。

ここから上限の目安を導出できます（この式そのものを書いた公式文書は無いので、あくまで上界です）。

1 秒あたりの生成トークン数の上限 ≒ メモリ帯域（GB/s） ÷ 重みのサイズ（GB）

計算例: Apple 公式スペックによる M4 のメモリ帯域は 120 GB/s。8B の Q4_K_M は 4.92 GB（4.58 GiB）なので、120 ÷ 4.92 = 約 24 トークン/秒が上限となります。同じマシンで F16（16.06 GB）を動かせたとしても 120 ÷ 16.06 = 約 7 トークン/秒です。実際にはサンプリングや KV キャッシュの読み出し、カーネル起動のオーバーヘッドがあるためこの上限には届きませんが、大体の目安はつかめます。この見積りを重み以外の要素まで含めてより精密に計算するのが第 8 章です。

何が変わらないか — プルーニングと蒸留との違い

量子化は圧縮ですが、「モデルを小さくする」という言い方は誤解を招きます。変わらないものを列挙します。

• パラメータの個数 — 80.3 億個は 80.3 億個のまま。1 個あたりの書き方が変わるだけ
• ネットワークの構造 — 層数、アテンションヘッド数、隠れ層の次元、行列の形
• 語彙（トークナイザ） — 扱えるトークンの種類も ID も同一
• 推論の手順 — 同じ推論エンジンにそのまま読み込める。Hugging Face なら読み込み時に量子化の設定を渡すだけで、モデルのクラスは変わらない

この点は、しばしば一緒に語られる 2 つの手法と比べるとはっきりします。

プルーニング（pruning、枝刈り）は、量子化サーベイの定義では「重要度（saliency）の小さいニューロンを取り除き、疎な計算グラフを得る」手法です。どこにあるものでも消す unstructured pruning は「疎行列演算になり、加速が難しいことが知られている」。フィルタ単位でまとめて消す structured pruning は「層と重み行列の入出力の形を変える効果を持つ」。つまりプルーニングは重みの個数そのものに手を付けます。

蒸留（distillation）は同サーベイの定義で「大きなモデルを学習し、それを教師として、より小さくコンパクトなモデルを学習する」手法です。元のモデルを圧縮するのではなく、別のモデルを新しく学習する点が根本的に違います。サーベイは「量子化とプルーニングが 4 倍以上の圧縮で性能を維持できるのに対し、蒸留だけで積極的な圧縮を狙うと精度低下が無視できなくなる」とも書いています。

率直に補足すると、「量子化はモデル構造を変えない」と明言した一文は、公式ドキュメントや原論文の中には見当たりませんでした。ただし量子化の定義は一貫して「重み（や活性化）を低精度のデータ型で表現する」であってパラメータの個数や形に触れておらず、一方で structured pruning と蒸留には上記のとおり形が変わる／別モデルになると明記されています。この対比から、実務上は安全に断定できます。

「量子化すれば速くなる」は半分だけ正しい

ここが最も誤解される点なので、公式ドキュメントの記述をもとに確認します。Hugging Face Transformers 公式の量子化手法選択ガイドは、bitsandbytes の欠点欄に一行こう書いています。「Inference speedup isn't guaranteed.（推論の高速化は保証されない）」。同じ公式ドキュメントの概念ガイドでも、高速化については「対応ハードウェア上で大幅に速くなり得る（can be significantly faster）」という助動詞付きの言い方を崩していません。

理由は図 1-2 のとおりです。得（読む量が減る）と損（毎回逆量子化する）が同時に発生し、どちらが勝つかは状況で変わります。実際の測定結果を 3 つ挙げます。

Hugging Face 公式ブログが公開した 11B モデルの計測では、fp16 で T4（15 GB）2 枚に分散した場合が 11.7 ミリ秒/トークン、int8 で T4 1 枚に載せた場合が 43.5 ミリ秒/トークン。約 3.7 倍遅くなっています。それでも価値があるのは、GPU 2 枚が 1 枚で済むからです。量子化の本来の強みはここにあります。

逆に、はっきり速くなる実測もあります。この章でサイズを引用した llama.cpp 公式の同じ表には生成速度の列もあり、Llama 3.1 8B のトークン生成は F16 が 29.17 tok/s、Q4_K_M が 71.93 tok/s。同じ表なので同一条件の比較で、約 2.5 倍高速です。llama.cpp のように量子化形式ごとの専用カーネルを持つ実装で、かつ 1 リクエストずつ処理する使い方なら、高速化の恩恵を受けやすくなります。ただし同じ表のプロンプト処理（入力をまとめて読む段階）は F16 の 923.49 tok/s に対し Q4_K_M が 821.81 tok/s で、そちらは F16 のほうが高速です。まとめて計算する場面では帯域が効かなくなるからです。

3 つ目として、NVIDIA の量子化手法選択ガイドは、4 ビット重みのみの量子化（INT4 weight-only）の性能を「小バッチでは High、大バッチでは Low」と表にしています。同ガイドは、バッチサイズ 4 以下の推論は帯域律速なので weight-only 量子化が効き、バッチサイズ 16 以上では計算密度も効くので重みと活性化の両方を量子化すべきだと分けています。ローカルで自分ひとりが使う用途は前者、つまり量子化が速度面でも効きやすい側です。

整理すると、量子化の第一の目的は「メモリに載せる」ことです。速度が上がるのは、帯域律速で、かつその量子化形式に対応した専用カーネルが動いているときです。量子化形式とハードウェアの組み合わせについては第 7 章、速度の見積りは第 8 章で扱います。

つまずきポイント

理解度チェック

まとめ

• モデルの重みは、学習で決まって推論中は変わらない数値の集まりで、テンソル単位で保存されている。個数はモデル名の 8B などが示す
• サイズは「パラメータ数 × 1 個あたりのビット数 ÷ 8」で決まる。Llama 3.1 8B を FP16 で置けば 16.1 GB（= 14.96 GiB）で、16 GB の GPU では KV キャッシュの置き場が残らない
• 削れるのは「1 個あたりのビット数」だけ。それを減らして書き直す不可逆な圧縮が量子化で、必然的に量子化誤差が生じる
• 変わるのはファイルサイズ・必要メモリ・帯域律速な生成速度の上限。変わらないのはパラメータの個数・層数・語彙・推論手順
• 「必ず速くなる」は誤り。HF 公式が「Inference speedup isn't guaranteed.」と明記している。第一の目的は載せることで、速度は条件付きの副産物
• 名前の数字（Q4_K_M の 4）は実効ビット数ではない。実効 4.8944 bits/weight を使う

次章へ: 「1 個あたり 16 ビット」の中身、つまり符号・指数・仮数へのビット配分を詳しく確認し、FP32 から FP4 までが実際にどんな値を表せるのかを見ます。

参考リンク

• Hugging Face Transformers — Quantization concepts
• Hugging Face Transformers — Selecting a quantization method
• Hugging Face Transformers — Quantization overview（量子化の定義）
• llama.cpp — tools/quantize/README.md（実効 bits/weight とファイルサイズの実測）
• llama.cpp — docs/multi-gpu.md（VRAM に収まらないときの挙動）
• Hugging Face Blog — A Gentle Introduction to 8-bit Matrix Multiplication
• NVIDIA — Mastering LLM Techniques: Inference Optimization
• NVIDIA TensorRT Model Optimizer — Best practices to choose the right quantization methods
• Gholami et al. — A Survey of Quantization Methods for Efficient Neural Network Inference
• LM Studio — System Requirements
• NVIDIA GeForce — Graphics Cards Compare（VRAM 容量）
• Apple Newsroom — Apple introduces M4 Pro and M4 Max（ユニファイドメモリと帯域）