LLM量子化の4bit・8bit比較｜メモリ・速度・品質で選ぶ

LLM量子化は、4bitか8bitかを先に選ぶ作業ではありません。同じ元モデル、同じリビジョン、同じ推論エンジン、同じ入力を固定し、メモリ上限を守った候補だけについて速度と業務品質を比較する作業です。容量が半分になっても、重要項目を誤る、対応カーネルがなく遅くなる、長文で停止するなら採用できません。本稿ではBF16を基準、8bitと4bitを候補とし、採用、限定採用、見送りを再現可能な記録で決めます。

4bitと8bitを選ぶ結論

最初の候補は、必要な同時実行数と最大入力長を含めて8bitがメモリ上限に収まるなら8bitです。8bitで重要品質がBF16基準を維持し、応答時間も合格するなら、4bitへ下げる理由はありません。8bitが起動しない、ピーク使用量が運用上限を超える、必要な同時数を処理できない場合に4bitを測ります。

4bitは容量面で有利になりやすい一方、誤差、尺度情報、未量子化層、復号計算、対応カーネルの影響を受けるため、半分のビット数がそのまま二倍の速度を意味するわけではありません。

4bitを優先できるのは、端末内推論のように搭載メモリが固定され、出力を人が確認でき、候補が業務テストの重大エラー上限を守った場合です。8bitを残すのは、数値・否定・固有名詞の取り違えが損失へ直結する処理、量子化誤差を補う後工程がない処理、または4bit用カーネルが対象GPUで十分に最適化されていない場合です。

どちらも合格しなければ、量子化方式の変更、より小さい元モデル、入力分割、クラウド推論を再検討します。「どうしてもローカルへ収める」は品質条件を下げる理由になりません。

判断順序は、実行可能性、重大品質、待ち時間、運用費の順です。平均速度が高くても、起動失敗や重大誤答を含む候補は比較表から外します。

比較前に固定する元モデルと実行環境

量子化比較で最も多い失敗は、4bitと8bitで別の配布者、異なるチャットテンプレート、違うトークナイザーを使うことです。これではビット数以外の差が混ざります。評価台帳には元モデルの配布元、モデルID、コミットSHA、ライセンス、重み形式、トークナイザーのファイルハッシュを記録します。

推論エンジンも製品名だけでなく版とビルド番号を固定し、GPUドライバー、CUDA、CPU命令、RAM、VRAM、OSを残します。モデル配布ページの既定ブランチだけを記録すると、再評価時に内容が更新され、結果を再現できません。

数値は記事上の推奨スペックではなく、比較票の書き方を示す架空例です。実務では本番のp50入力長、p95入力長、許容最大長をログから決めます。生成条件はtemperature、top_p、seed、stop、最大出力トークン数まで揃え、同じ要求順で実行します。

GPUの温度制限や他プロセスの使用量も結果へ影響するため、専用評価機を使うか、開始前後の空きVRAMとクロックを記録してください。これらを固定できない測定は探索用途に留め、採否の根拠には使いません。

重み容量と実行時メモリを分ける

ビット数から直接計算できるのは、主として重み本体の理論量です。70億パラメーターを単純計算すると、BF16は約13.04GiB、8bitは約6.52GiB、4bitは約3.26GiBになります。

しかし、実際のファイルには尺度、ゼロ点、グループ情報、メタデータが加わり、実行時にはKVキャッシュ、活性値、一時バッファ、CUDA Graph、推論エンジンの予約領域が必要です。量子化から除外された層が高精度のまま残る方式もあります。したがって「7Bの4bitなら4GBで動く」と容量計算だけで断言してはいけません。

重み理論量（GiB）＝パラメーター数 × ビット数 ÷ 8 ÷ 1,073,741,824。これは上限保証ではなく、量子化メタデータやランタイム領域を除く比較用の概算です。

70億パラメーターを同じ式へ入れた想定計算は次のとおりです。結果は重み本体の理論量であり、必要VRAMの実測値ではありません。

前提: パラメーター数 = 7,000,000,000
8bit: 7,000,000,000 × 8 ÷ 8 ÷ 1,073,741,824 = 約6.52GiB
4bit: 7,000,000,000 × 4 ÷ 8 ÷ 1,073,741,824 = 約3.26GiB
実機確認: 上記にKVキャッシュ、活性値、一時領域を加えたピークVRAMを測る

測定では、モデルファイル総容量、プロセス起動前の使用量、ロード完了時、最初の要求後、p95入力を最大同時数で流したときのピークを分けます。NVIDIA GPUなら一定間隔で使用VRAMを記録し、CPUへオフロードする構成ではRAMとページフォールトも採取します。運用上限は物理容量の100%ではなく、監視や断片化、突発的な長文を考慮した余白を引いた値にします。たとえば24GB機で20.4GBを採用上限とする85%ルールは設定例であり、実機の連続負荷と復旧試験で調整する値です。

vLLM 0.23.0のメモリ節も、精度を下げた重みの利用に加えて、max_model_lenやmax_num_seqsがメモリへ影響することを示しています^[8]。つまり、量子化形式だけを替えても、入力上限と同時処理設定が異なれば比較になりません。OOMが消えたかだけでなく、同じサービス条件で余白を確保できたかを合格判定に含めます。

量子化方式とモデル形式の違い

4bitと8bitは方式名ではありません。同じ4bitでも、どの単位で尺度を持つか、外れ値や一部層を高精度で扱うか、重みだけを量子化するか、実行時にどの型へ復号するかで挙動が変わります。LLM.int8()の原論文は、外れ値を16bit側で扱い、その他を8bitで処理する混合精度の経路を提案しています^[3]。

QLoRAは学習用途の文脈でNF4、二重量子化、ページ化オプティマイザーを組み合わせています^[4]。名称だけを見て、推論用4bit形式がすべて同じ手法だと解釈しないでください。

bitsandbytesのLinear4bitにはFP4とNF4があり、モジュールを置き換えた後、デバイスへ移す時点で量子化される仕組みが公式資料に記載されています^[2]。GPTQは近似二次情報を用いた事後量子化を扱い^[5]、AWQは少数の重要な重みを守る考え方を示しています^[6]。

これらは「4bit」という一列へまとめず、方式、実装、設定、変換元を別々の候補IDで管理します。

llama.cppはGGUFを要求し、複数の整数量子化とベンチマークツールを提供しています^[7]。一方、Safetensorsを読み込む実装の結果とGGUFの結果には、変換方法とエンジンの差も含まれます。純粋な4bit対8bit比較を行うなら同じエンジン内で方式を揃えます。

配備方式を選ぶ比較なら、差が複合的であると明記したうえで、サービス全体の候補として採点します。

速度と安定性を測る手順

速度は「一秒当たり何トークン」だけでは判断できません。利用者が待つ最初の一文字までの時間はTTFT、生成中の間隔はTPOTまたはITL、要求全体はE2E latencyで確認します。バッチ処理では総スループットが重要ですが、対話用途ではp95のTTFTが長いと操作感を損ないます。

候補ごとにプロセスを再起動し、モデルロード後に同一のウォームアップ要求を流し、同時数1・4・8を別々に測ります。順番によるキャッシュ差を避けるため、候補の実行順を入れ替えた二巡目も行います。

1. 起動を記録する：ロード時間、ファイル容量、ロード直後のRAM・VRAM、警告ログを保存します。
2. 単発性能を取る：短い入力とp95長の入力を各30回流し、TTFTと生成速度の中央値・p95を計算します。
3. 同時負荷を増やす：本番想定の到着率で200件を送り、待ち行列、失敗率、ピークメモリを採取します。
4. 長時間運転する：最低60分の連続試験で、メモリ増加、温度低下制御、応答停止、再起動の有無を見ます。
5. 再現性を確かめる：同じ設定で再実行し、主要値の差が事前に決めた許容幅へ収まるか確認します。

速度合格値は、本番要件から逆算します。例として「同時4でp95 TTFT 1.5秒以下、p95 TPOT 45ミリ秒以下、要求失敗率0.5%未満」を置くなら、これは編集上の例であり、製品の性能保証ではありません。

また、bitsandbytes 0.50.0の公式リリースは特定条件向けのfused 4-bit GEMMと性能改善を案内していますが、対象バッチサイズやハードウェア条件があります^[1]。リリースノートの最大改善率を自社GPUへ転用せず、使用する組み合わせで測ります。

CPU系のGGUF候補ではllama-benchでprompt processingとtoken generationを分け、スレッド数、コンテキスト長、GPU offload層数を記録します。サービス経由の候補ではクライアントからのネットワーク時間も含む測定と、サーバー内部指標を併記します。

平均だけを掲載せず、p50、p95、p99、最悪値、失敗件数を残すと、量子化による外れ値の増加を見落としにくくなります。

業務品質を測るテストセット

品質評価には公開ベンチマークだけでなく、自社で正解と禁止事項を定義できる代表案件を使います。例として150件を、項目抽出40件、分類30件、短い要約25件、数値計算20件、否定・例外理解20件、長文参照15件へ分けます。各件には入力、期待出力、許容表記、根拠箇所、重大度、採点者を持たせます。

個人情報や契約文書を含む場合は評価データの保管権限と削除期限も決めます。元のBF16が不正解の設問は量子化劣化の判定から外し、別途モデル能力の問題として記録します。

temperatureを0にしても、実装や並列計算によって完全一致しない場合があるため、重要設問は複数回実行します。自動指標は表記揺れを正規化した後に計算し、要約や説明文は二名で独立採点します。採点が割れた設問は正解条件を修正してから全候補を再評価し、特定候補だけを再採点しません。

perplexityは量子化による分布変化を追う補助値にできますが、業務上の重大誤りを直接表さないため、最終判断を置き換えません。

合格例は「重大エラー0件、BF16に対する完全一致率の低下1.5ポイント以内、人手品質4点満点中3.5以上」です。これも汎用基準ではなく、誤りの費用に合わせて決める提案例です。医療、法務、与信、設備制御など、誤りが安全や権利へ影響する用途では、量子化候補が高得点でも人の確認と専門的な妥当性評価を外せません。

設問と結果の版を保存し、モデル更新時に同じ回帰試験を実行します。

4bit・8bit比較表と評価票

比較表には実測値だけを記入し、未測定を0点や推定値で埋めません。下表の傾向は一般的な選択の方向を整理したもので、個別モデルの結果ではありません。8bitは4bitより重みの理論量が大きい一方、品質余裕を取りやすい候補です。

4bitは搭載可能性や同時数で有利になる可能性がありますが、方式とハードウェアによっては復号やカーネルの制約で速度が逆転します。BF16は品質差を測る基準として残し、運用候補から外す場合もテスト結果を削除しません。

総合80点以上を「採用候補」、65～79点を「入力範囲を限定して再評価」、64点以下を「見送り」とする区切りは社内案の一例です。ハードゲートは総合点で相殺しません。結果票には候補ID、元SHA、量子化ツール版、設定、測定日時、評価者、未解決事項を添えます。

4bitが84点、8bitが90点で双方合格なら、容量が必要条件を満たす限り8bitを採るという選択も妥当です。点数は4bitを勝たせるためではなく、制約と損失を可視化するために使います。

量子化で起きるエラーの切り分け

量子化エラーは、重み破損、形式不一致、カーネル非対応、メモリ不足、トークナイザー差、品質劣化に分けると追いやすくなります。まずエラーログを省略せず保存し、モデルID、ファイルハッシュ、変換コマンド、推論エンジン版、GPU名を一組にします。

起動しないときに別の量子化ファイルを次々試すと原因が増えるため、BF16基準が同じ環境で読めるか、対応表に候補方式があるか、最小入力が通るかの順で切り分けます。

4bit変換後に品質が崩れた場合、量子化済みファイルをさらに変換してはいけません。保存したBF16またはFP16の正本へ戻り、校正データ、方式、グループサイズ、除外層を一項目ずつ変えます。原因が特定できないまま「別の配布者の同名モデル」で直ったように見えても、比較の連続性は失われています。その候補は新規IDで評価し直します。

エラーを解消した設定は成功ログだけでなく、失敗した設定と理由も台帳へ残すと、将来の更新で同じ問題を繰り返しません。

用途別の採用候補と向かないケース

4bitが候補になりやすいのは、短い分類、検索候補の生成、定型抽出の補助、端末内の草案作成など、入力範囲を絞れ、出力を確認できる用途です。8bitは、4bitより多くのメモリを使っても数値・固有名詞の保持に余裕を持たせたい業務や、品質テストで4bitだけが重要項目を落とした場合の候補です。

BF16は運用に載せなくても、量子化による差を見分ける基準として必要です。いずれも、元モデルが業務そのものを解けなければ量子化で能力が増えるわけではありません。

量子化が向かないケース

正解データを用意できない、出力を確認する責任者がいない、モデルとライセンスの出所を追えない、量子化前の基準モデルを保存できない環境には向きません。安全や権利に関わる判断をモデル出力だけで確定する運用、最大入力長と同時数が未定のまま容量だけを削る計画、品質低下を「利用者が気づかなければよい」と扱う計画も中止対象です。

まず業務範囲、正解、承認、監査ログを整えてください。

また、GPU料金を下げることが目的でも、量子化の変換・検証・保守工数が削減額を上回る場合があります。月間要求数が少なく機密制約も弱いなら、従量課金APIや小型の非量子化モデルの方が総費用を抑えられる可能性があります。モデル更新が頻繁な業務では、そのたびに変換と150件の回帰試験が必要です。

年間の更新回数、担当者時間、障害復旧時間を含むTCOで比較し、ファイル容量だけを投資根拠にしないことが大切です。

採用・停止・ロールバック条件

採用候補が決まったら、量子化ファイルだけでなく、元モデルの識別子、変換ツールと版、完全なコマンド、設定JSON、校正データID、トークナイザー、評価票を一つのリリース単位にします。公開配布された量子化済みモデルを使う場合も、作成条件が確認できなければ本番候補へ昇格させません。

llama.cppのように更新頻度の高い実装では、リポジトリ名だけでなく検証したbuildやコミットを固定し、更新を自動追随させず回帰試験を挟みます。

採用条件の例は、ハードゲート全通過、総合80点以上、最大負荷で20%以上のメモリ余白、連続試験中の要求失敗率0.5%未満、旧版へ15分以内に復旧できることです。限定採用では、許可する入力種別、最大文字数、利用部門、確認者、期限を設定します。

停止条件は、重大誤答1件、OOM再発、p95 TTFTが上限を二回連続で超過、ファイルハッシュ不一致、ライセンス条件の変更、監視不能のいずれかとします。しきい値は例なので、自社の損失許容度で承認してください。

1. 正本を保管する：量子化前重みとトークナイザーを読み取り専用領域へ保存し、ハッシュを台帳へ登録します。
2. 成果物を版管理する：4bitと8bitを別IDにし、作成者、作成日時、使用ツール、設定を添付します。
3. 段階公開する：評価環境、社内限定、低リスク業務、本番範囲の順で利用者を増やします。
4. 監視する：失敗率、TTFT、ピークメモリ、保留率、品質サンプルを版別に可視化します。
5. 戻す練習をする：旧版の起動、ルーティング切替、キャッシュ消去、利用者通知まで所要時間を測ります。

停止後は同じ4bitへ無条件に再起動せず、直前の合格版へ戻して影響範囲を確定します。入力、出力、モデル版、発生時刻、担当者の操作を保存し、品質事故なら同種設問をテストセットへ追加します。再開には原因、修正差分、回帰結果、承認者を必要とします。こうした停止設計がない量子化は、省メモリ化ではあっても運用可能なリリースではありません。

次に取る行動：同一条件で4bit・8bitを比較する

まず本番ログから入力長、出力長、同時数、許容待ち時間を抽出し、BF16の元モデルを一つ固定します。次に8bitを測り、実行条件を満たさない場合だけ4bit候補を追加してください。測定結果は評価票へ転記し、未測定欄を残したまま判定会へ持ち込まないようにします。

採用候補がハードゲートを通過したら、低リスクの入力だけで二週間の限定運用を行い、実データから選んだ品質サンプルを毎日確認します。停止条件に触れた時点で旧版へ戻し、原因を解消してから同じ試験をやり直します。

判定会に必要な成果物

固定条件表、候補ごとのファイルハッシュ、メモリ時系列、速度のp50・p95・p99、150件の品質結果、重大エラー一覧、100点評価票、ライセンス記録、ロールバック試験結果を一式にします。これらが揃えば、4bitと8bitの選択を印象ではなく、再確認できる根拠で説明できます。

参考文献・出典

1. bitsandbytes contributors「bitsandbytes Releases」（公式リリース一覧、確認版：0.50.0、公開日：2026年7月25日、参照日：2026年7月30日）
2. Hugging Face「4-bit quantization」（bitsandbytes公式ドキュメント main、安定版表示：v0.50.0、参照日：2026年7月30日）
3. Dettmersほか「LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale」（原論文v2、更新日：2022年11月10日、参照日：2026年7月30日）
4. Dettmersほか「QLoRA: Efficient Finetuning of Quantized LLMs」（原論文v1、公開日：2023年5月23日、参照日：2026年7月30日）
5. Frantarほか「GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers」（原論文v2、更新日：2023年3月22日、参照日：2026年7月30日）
6. Linほか「AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration」（原論文v6、更新日：2026年4月25日、参照日：2026年7月30日）
7. ggml-org「llama.cpp」（公式README、GGUF・量子化・ベンチマーク機能を確認、リリースbuild b10184：2026年7月30日、参照日：2026年7月30日）
8. vLLM Project「Conserving Memory」（公式文書v0.23.0、ページ更新日：2026年4月28日、参照日：2026年7月30日）

製品版、モデル版、ドライバー、ハードウェアが変わると結果も変化します。本稿中の容量計算と合格しきい値は比較設計の例であり、各環境で再測定してください。