LLMの量子化とは？GGUF・AWQ・GPTQ・FP8の違いと選び方

想定する処理がメモリに収まり、独自の品質チェックにも合格する範囲で、できるだけ高い精度を選びましょう。 ダウンロードするファイルが小さくても、回答の正しさを保ち、会話に使うメモリを十分に残せなければ意味がありません。

ドキュメントの記載と互換性に関する情報は、2026年10月20日時点の各プロジェクトの公開ページで確認しています。メモリ容量の数値は、Qwen2.5-7B-Instructの公式パラメータ数から計算したものです。GPUの実測使用量やベンチマーク結果ではありません。

LLMの量子化とは？モデルの構造を変えずに数値の精度を下げる仕組み

量子化は、モデルが学習した数値を、より少ないビット数で保存する技術です。 大規模言語モデル（LLM）は、「重み」と呼ばれる学習済みの数値パラメータを使って文章を生成します。その精度を下げると、保存や転送の負担を減らせる一方で、近似による誤差が生じます。このメモリと精度のトレードオフは、Hugging Faceの量子化の概要でも説明されています。

細かい桁まで寸法を記した建築図面を思い浮かべてください。寸法を丸めれば記録はコンパクトになりますが、一部の寸法はわずかに変わります。それでも、建物の部屋の構成は同じです。通常の重み量子化も同様で、大きなモデルの層や学習済みパラメータを減らすわけではありません。変わるのは、重みをどれだけ細かく表現するかです。

ただし、このたとえで説明できる範囲には限りがあります。量子化は、単に小数点以下を切り捨てる処理よりも緻密です。値をグループにまとめ、スケールを割り当て、表現可能な値の集合を小さくする、といった処理を行えます。ランタイムは計算時に、そのスケールを使って近似値を復元します。重要な部分だけ高い精度を残すこともできます。IBMの量子化の解説では、こうした対応付けと、それによって生じる誤差を説明しています。

ダウンロードするモデルを選ぶ前に、次の項目を区別しておきましょう。

• 重み： モデルに保存されている学習済みの値です。
• 活性値： 入力を処理する過程で生まれる中間的な値です。
• KVキャッシュ： 処理済みのコンテキストに対応するアテンションのデータです。会話が長くなるほど、追加のメモリを使います。

重みだけを量子化する方式で小さくなるのは、最初の項目だけです。活性値やKVキャッシュまで自動的に小さくなるわけではありません。そのため、モデルを読み込めても、長いリクエストでメモリ不足になることがあります。Ollamaのメモリとキャッシュに関するドキュメントでも、コンテキスト容量とキャッシュの精度は別々に扱われています。

学習後量子化と量子化を考慮した学習はどう違う？

モデルをダウンロードして使う開発者なら、通常は学習後量子化から考えるとよいでしょう。 学習後量子化（PTQ）は、学習済みのチェックポイントを変換する方法です。一部の手法では、代表的な入力であるキャリブレーションデータを使い、重みの近似方法を調整します。一方、量子化を考慮した学習（QAT）は、学習やファインチューニングの段階で低精度化の影響を織り込みます。IBMは両方のアプローチを説明しています。

公開済みの量子化チェックポイントを使うために、自分でモデルを学習する必要はありません。ただし、元になったモデル、量子化の方法や設定、読み込みに対応するランタイムは把握しておく必要があります。ファイル名だけでは、こうした情報を十分に確認できません。

GGUF・AWQ・GPTQ・FP8は、どの実行環境で使う？

これらの名前はシステムの異なる要素を指しており、同じ分類の選択肢ではありません。 GGUFはコンテナ、AWQとGPTQは量子化手法、FP8は数値形式です。チェックポイントとは、重みと、その読み込みに必要な情報をまとめたモデルの保存データを指します。

モデルのホスティング基盤を提供し、Transformersを開発するHugging Faceは、ファイル形式と読み込み方法の両方を文書化しています。以下の表は、その資料と各ランタイムの公式ガイドをまとめたものです。方式を選ぶための実用的な目安であり、掲載したすべての経路で、あらゆるモデルアーキテクチャが動くという意味ではありません。

拡張子が.safetensorsでも、それだけでは精度はわかりません。 この拡張子が示すのは、テンソルの保存形式です。テンソルの表現方法と想定するローダーは、チェックポイントの量子化設定とモデルカードで確認してください。Hugging FaceのGGUFドキュメントはコンテナのメタデータとテンソルデータを区別しており、AWQガイドでは関連するquantization_configのフィールドを確認できます。

Q4_K_Mという名前は何を意味する？

Q4_K_Mは混合精度のプリセットです。すべてのパラメータが正確に4ビットで保存されるという意味ではありません。 Q4は公称4ビットの系列、KはK-quantのブロック方式、Mはmediumプリセットを表します。モデルアーキテクチャや量子化ツールの規則に応じて、一部のテンソルには高い精度が割り当てられます。llama.cppの量子化実装には、その選択方法が明示されています。

基本的なQ4_Kブロックにも、管理用の情報が含まれます。プロジェクトのテンソル符号化方式の一覧では、スケールと最小値の情報を含めると、重みあたり4.5ビットとされています。これはブロック単位の値であり、すべてのQ4_K_Mモデルの平均値ではありません。

メモリが限られるローカルマシンでは、Q4_K_Mは評価を始める候補として妥当です。想定するコンテキストを含めても高精度版が収まるなら、そちらも比較しましょう。小さいファイルがあるという理由だけで、回答の品質を犠牲にする必要はありません。

Qwen2.5-7B-Instructで必要メモリを計算する

まず総パラメータ数から重みの容量を求め、そこに実行用のメモリを加えます。 ここでは、Qwenの指示チューニング済みモデル、Qwen2.5-7B-Instructを例にします。このモデルの総パラメータ数は7.61Bです。モデルカードには、別に埋め込みを除くパラメータ数6.53Bも記載されています。小さいほうの値を使うと、保存されるモデルの一部を計算から落としてしまいます。Qwenのモデルカードを参照してください。

理想化した計算式は次のとおりです。

重みのバイト数 ≈ パラメータ数 × パラメータあたりのビット数 ÷ 8

16ビットなら、7,610,000,000 × 16 ÷ 8 = 15,220,000,000 bytesとなります。ほかの精度も同じように計算します。

これは、すべてのパラメータが表のビット幅で保存されると仮定し、モデルカードに記載された丸め済みのパラメータ数から本記事で計算した値です。GBはバイト数を1,000,000,000で、GiBは1,073,741,824で割ります。単位によって表示する数値は変わりますが、メモリそのものの量は変わりません。

この表には、量子化スケール、高精度のテンソル、ファイルのメタデータ、キャッシュ、活性値、一時作業バッファ、ランタイムによるメモリ予約を含めていません。Q4_K_Mのダウンロード容量は、理想化した4ビットの行とは一致しません。また、4ビットの行を見ただけで、仮に4 GBのGPUがあればこのモデルが動く、と判断することもできません。

このため、ローカルのコーディングアシスタントを短いチャットだけで試しても、容量の検証としては不十分です。実際に使うソースファイル、指示、想定する応答の長さまで含めてテストしましょう。サーバーなら、同時リクエストも加えます。Ollamaは、並列リクエストとコンテキストの割り当てがメモリに及ぼす影響を明記しています。

コンテキスト用メモリの計算は、KVキャッシュのガイドを参照してください。重みの量子化とキャッシュの量子化は、別々の設定です。vLLMも、KVキャッシュの量子化を独立した機能として説明しています。

実行環境に合わせて形式を選ぶ

精度のラベルより先に、どう実行するかを決めましょう。 互換性は必須条件です。その条件を満たしたうえで、利用できるメモリ、回答の品質、実際の処理で測ったレイテンシをもとに選びます。

llama.cpp：対応するGGUFを選ぶところから始める

ローカル推論エンジンのllama.cppは、モデルファイルやデバイスへの配置を自分で管理しながら、GGUFを直接扱いたい場合の選択肢です。 公式ドキュメントには、CPUでの実行、Apple siliconへの対応、CPUとGPUを併用した実行が記載されています。そのため、重みのすべてを単体GPUに載せられない場合にも役立ちます。llama.cppの公式ドキュメントを参照してください。

ただし、読み込みに成功しても、実用的な速度が出るとは限りません。CPUとGPUに分けて配置すると実行条件が変わるため、実際に使うプロンプトと応答で測定する必要があります。まずモデルアーキテクチャ、次に対応するGGUF、最後に量子化プリセットを選びましょう。

ベースモデルの候補を絞る際は、本サイトのおすすめローカルLLMガイドを活用してください。高精度の状態でも苦手なタスクを、量子化によって理解できるようになるわけではありません。

Ollama：使いたい精度に量子化したファイルをインポートする

ローカルでモデルを実行するOllamaは、用意済みのGGUFをインポートできます。ただし、インポート自体は量子化を行いません。 現在のインポートガイドは、量子化済みのファイルを先に用意するよう案内しています。インポートコマンドを実行すれば高精度モデルが自動的にQ4_K_Mになる、と考えている場合は注意が必要です。Ollamaのインポートドキュメントで確認できます。

Ollamaをインストールし、互換性のある量子化済みファイルをカレントディレクトリにmodel.ggufとして保存した場合、公式の手順は次のようになります。

printf 'FROM ./model.gguf\n' > Modelfile
ollama create quant-check
ollama run quant-check

別のターミナルでollama psを実行すると、読み込んだモデルがCPUとGPUにどう配置されているかを確認できます。これは読み込み状態の確認であり、品質のベンチマークではありません。Ollama FAQを参照してください。

Ollamaでも、実際の処理に必要なメモリは制約として残ります。モデルを手軽なコマンドで実行できても、コンテキストや同時実行用のメモリは必要です。モデルファイルやランタイムをどこまで自分で制御するかは、Ollamaとllama.cppの比較で詳しく説明しています。

vLLM：チェックポイント・カーネル・GPUの組み合わせを確認する

推論とモデル配信のエンジンであるvLLMでは、対応する実行方式に合った量子化チェックポイントが必要です。 まず、モデルの公開元が対応を示すAWQ・GPTQ・FP8のファイルを選び、次にvLLMのハードウェア対応表で手元のGPUを確認します。カーネルとは、そのハードウェアで形式を効率よく処理するための低レベルの演算実装です。

新たにAWQ量子化を行う場合、現在のドキュメントはLLM Compressorを案内しています。AutoAWQは非推奨ですが、AWQという手法やチェックポイントの系列がなくなったわけではありません。TransformersでGPTQを使う際、保守されているバックエンドはGPTQModelです。互換性はチェックポイントの設定にも左右されます。vLLMのAWQガイドとHugging FaceのGPTQガイドを確認してください。

FP8では、さらに区別が必要です。W8A8は重みと活性値がともに8ビット、W8A16は重みが8ビットで活性値が16ビットであることを示します。vLLMのドキュメントでは、NVIDIA Ada、Hopper、BlackwellでネイティブFP8のW8A8に対応し、TuringとAmpereではMarlinを使った重みのみのW8A16方式を利用できるとされています。したがって、「FP8対応」という表示だけでは、実際にどの演算方式を使えるかはわかりません。vLLMのFP8ドキュメントを参照してください。

ローカルで動いたという理由だけで、vLLMへのデプロイでもGGUFを標準の形式にするのは避けましょう。 現在のドキュメントでは、GGUFをvllm-gguf-plugin経由で扱います。依然として実験的で最適化が不十分とされており、一部の機能と互換性がない可能性もあります。これは移行時の制約であって、GGUF自体が劣っていることを示すものではありません。vLLMのGGUFドキュメントで確認してください。

ホステッドAPI：エンドポイントが公開している選択肢を使う

ホステッドAPIに精度の設定がなければ、利用者側で量子化方式を選ぶ余地はありません。 エンドポイントの仕様を確認しましょう。精度別のバリアントが用意されていれば、選択したバリアントを評価します。そうした選択肢がなければ、内部の数値表現を推測せず、サービスの出力とレイテンシを評価します。

モデル名が同じでも、プロバイダーが違えば、量子化方式、ランタイム、結果まで同じとは限りません。アプリケーションに必要な場合に限り、チェックポイントや精度について文書化された保証を求めましょう。自分の重みをアップロードして配信する場合は、別のデプロイ判断になります。その際は再び、ランタイムとハードウェアの互換性を確認する必要があります。

量子化でメモリ・速度・品質はどう変わる？

数値表現を小さくすればメモリを節約できますが、速度と品質は別々に評価する必要があります。 メモリに保持するデータが減ると、重みの転送に伴う処理を減らせる可能性があります。一方、ランタイムによっては、演算前に値の展開や変換も行います。Hugging FaceのGPTQドキュメントでは、融合カーネルによって、モデル全体をGPUのグローバルメモリに展開せずに低ビットの重みを演算用に復元する仕組みを説明しています。

ここに、量子化の可能性と限界の両方があります。対応するカーネルがあれば、コンパクトな重みを有効に使えます。実行方式が適切でなければ、その利点が失われることもあります。ファイルサイズを速度の指標にせず、最初のトークンが返るまでの時間、生成速度、想定する同時実行数でのスループットを測定しましょう。

品質も、用途に即して確認します。コーディングアシスタントなら、提案された変更が必要なテストに合格するかを比較します。文書からの情報抽出なら、必須フィールドが揃い、構造化された出力が妥当かを確認します。多言語アシスタントなら、提供する言語を評価に含めます。文章が流暢に見えるだけでは、量子化後もタスクに必要な振る舞いが保たれた証拠にはなりません。

比較するのは、同じ元のチェックポイントの高精度版と、候補となる量子化版です。プロンプト、チャットテンプレート、生成設定も揃えます。同時に別のモデル同士を比べてしまうと、量子化によって何が変わったのかを切り分けられません。

量子化を見送るべき場面と、過大評価されがちな主張

高精度のままでメモリに収まり、量子化しても測定できる運用上の利点がなければ、高精度を維持しましょう。 圧縮を進めるほど、管理するモデルファイルと検証する振る舞いが増えます。量子化は、実際に抱えている問題を解決するために使うものです。

重要なタスクのチェックに落ちる場合、実行方式のサポートが不十分な場合、長いコンテキストを扱う処理が依然としてメモリに収まらない場合は、低精度版を採用しないでください。最後のケースでは、重みを繰り返し小さくする前に、コンテキストと同時実行数を見直しましょう。

推論用の量子化モデルを、あらゆる学習に使えるチェックポイントと考えるのも適切ではありません。bitsandbytesが説明している低ビット学習のサポートは、アダプターの重みなどの追加パラメータが対象です。これは特定のファインチューニング手順を指します。ダウンロードした量子化モデルなら、どれでも通常の全重み学習に使えるという意味ではありません。Hugging Faceのbitsandbytesドキュメントを参照してください。

次のような主張は、効果を過大に見せています。

• 「4ビットなら、アプリケーション全体のメモリ使用量が4分の1になる」。これは16ビットに対する、理想化した重みのビット幅の比率です。実行時のメモリには、ほかの要素もあります。
• 「8ビットはひとつの形式だ」。FP8、INT8、Q8_0は、数値表現も実行方式も異なります。
• 「ビット数が少ないほど、必ず速くなる」。メモリの削減がレイテンシやスループットの改善につながるかは、チェックポイント、カーネル、ハードウェア、処理内容によって決まります。
• 「大きな量子化モデルは、小さな高精度モデルより必ず優れている」。パラメータ数とビット幅だけでは、タスクの品質は判断できません。両方がメモリに収まるなら、両方を評価しましょう。

コーディング向けの候補を探す場合は、コーディングにおすすめのローカルAIモデルガイドを使い、選んだチェックポイントの量子化バリアントを、実際に任せたい作業で比較してください。

LLM量子化を実際に試すための手順

まずは対応が確認できるモデルファイルを選び、小さくても繰り返せる評価から始めましょう。 精度の影響を把握するまでは、元のモデルを変えずに比較します。

よくある質問

AIシステムを動かし、提供するための実践的なガイドは、ニュースレターに登録して受け取れます。