LLM を軽量化するための量子化とプルーニング手法の解説

あるチームがモデルを3週間かけて微調整し、期待通りの評価結果を得た後に本番環境への展開を試みます。しかし、保存されたチェックポイントのサイズだけで140GBに達してしまいます。この数字は、一般的な企業がラック内に保有するほぼすべてのGPUの利用を不可能にし、デプロイ計画の書き直しを強いることになります。本来であれば1週間で完了すべきリリースが、予算化されていなかった4枚のA100 GPUを確保するための慌ただしい駆け込みになるのです。

この状況は、実際よりも遥かに頻繁に起こっており、ほとんどは未然に防げます。モデルは全精度で全てのパラメータを保ったまま出荷する必要はありませんでした。必要なことは、タスクを完遂できる範囲で最も軽量なバージョンとして提供することです。そのために役立つのが量子化（Quantization）とプルーニング（Pruning）の2つの手法ですが、これらは特殊なものでも新しいものでもありません。むしろ、「小さくする＝性能が落ちる」と思い込んでいるチームによって、あまり活用されていないのが実情です。

この記事では、各手法が実際に何を行うのかを解説し、それらを省略することがいかにコストとレイテンシの増大につながるかを説明します。さらに、現在本番環境で運用されている5つの具体的な手法について、今日からすぐに適用可能なコード付きで詳しく取り上げます。

量子化とプルーニングの本質

これら2つはしばしば混同されがちですが、さらに踏み込む前に明確に区別しておく必要があります。なぜなら、それぞれが異なる問題に対して、異なるアプローチで解決策を提供しているからです。

量子化は、モデルを構成する数値の精度を下げる手法です。16 ビット浮動小数点数（例：0.0023847）で保存されていた重みが、少数ビット（8 ビット整数や 4 ビット整数など）を用いて丸められ、再表現されます。モデルのパラメータ数は全く変わりません。以前存在したすべての重みはそのまま残ります。重要なのは、それがより少ない容量で済むようになり、計算速度が向上する点です。高解像度の写真をビット深度を落として保存してもフレーム内の物体はすべて表示されるのと同じように、量子化されたモデルも精度は落ちますが、必要な情報は保持したまま効率的に動作します。

プルーニング（剪定）は、重みや構造そのものを削除する手法です。2 つのニューロン間の結合やアテンションヘッド、場合によっては層全体が不要と判断されれば削除されます。これにより、パラメータ数自体が減ります。これは、長い文書で意味のない文章を切り取るように編集する行為に近く、単に文字サイズを小さくするのとは根本的に異なります。

両方の手法はモデルを小型化しますが、縮小させる軸が異なります。後ほど詳しく説明するように、これらは互いに競合するものではなく、重ね合わせて組み合わせることで相乗効果を発揮します。

なぜ今これが重要なのか

この問題の根底にあるスケーリングの課題は、実際の数値を目にすると軽視されがちです。FP16 で保存された 700 億パラメータモデルをロードするには、VRAM が約 140GB 必要になります。これはつまり、リクエストが処理される前に A100 GPU を 4 基用意する必要があることを意味します。Pristren の LLM 圧縮コストに関する分析（LLM compression costs breakdown）によると、これはモデルが有用な処理を行う前に約 8 万ドルから 10 万ドルのハードウェアがアイドル状態になることを示しています。

量子化はこの計算を直接的に変えます。AWQ や GPTQ を使用して同じ 70B モデルを 4 ビットに圧縮すると、必要な VRAM は約 35GB から 40GB に減少します。これは小規模なクラスターではなく、単一の高性能ワークステーション用カードに収まるサイズです。Fungies の 2026 年版量子化ガイド（LLM quantization GGUF AWQ GPTQ guide）が示す通り、これは単なる微細な最適化ではありません。データセンターを必要とするモデルと、エンジニアの机の下に置けるハードウェアで動作するモデルとの決定的な違いなのです。

これは、ローカルでモデルを実行しようとする愛好家に限られたニッチな問題ではありません。2026 年に大手ラボがどのようにモデルをリリースするかを形作る重要な要素となっています。

Google の Gemma 3 は、27B モデルのサイズを 54GB から 4-bit で約 14GB に削減し、単純なポストトレーニング量子化と比較して品質低下をほぼ半分に抑えました。その次世代モデルである Gemma 4 ではさらに一歩進み、最小の 2B バリアントを約 1GB にまで圧縮する量子化対応チェックポイントをリリースしています。これはスマートフォン上で完全に動作させるのに十分なサイズです（TensorFoundry の 2026 年量子化フィールドガイド 参照）。

現在の iPhone に搭載されている Apple のオンデバイスモデルも、事後にスケールを推測するのではなく、量子化対応トレーニングを通じて重みを 2 ビットまで圧縮するという同じ手法を採用しています。

実務的なメリットは明白です。購入またはレンタルする GPU の数を減らせますし、メモリを通過するデータ量が少なくなるため、1 リクエストあたりのレイテンシも短縮されます。さらに、本来フルサイズのモデルを収容できないハードウェアでも、実際に機能する能力を搭載することが可能になります。

これをスキップするか、誤った方法で行うとどうなるか

両方の失敗パターンが現場で頻繁に発生しているため、そのリスクについても正直に解説する必要があります。

圧縮を全く行わなければ、失敗は通常シンプルで、かつ高価なものになります。具体的には、実際に持っているハードウェア上で展開するにはモデルが大きすぎる、推論コストが高すぎて製品としての商業的実現性がなくなる、あるいは応答速度が必要なライブチャットインターフェースや音声アシスタント、自動補完ツールなどのユースケースを破綻させるほど遅延が生じる、といった問題です。これらは架空の話ではありません。大規模モデルを訓練し、その展開は後で誰かが解決する問題だと考えているチームにとって、これがデフォルトの結果となるのです。

失敗の別の形態は、より静かで危険です。メモリ不足エラーのように目立って現れないからです。適切なキャリブレーションデータセットなしに過剰な量子化を行ったり、モデルの実質的な能力を担う少数のアウトライヤー重みを無視したりすると、精度が低下します。この低下は、簡単なスモークテストでは必ずしも検出されない形で起こります。

Red Hat 自身の調査（50 万件を超える量子化モデルの評価を対象）によると、品質の低下はモデル、タスク、手法によって大きく異なります。一部のモデルは過剰な圧縮に耐えられますが、他のモデルはすぐに崩壊します。どのアプローチが有効かを知る唯一の方法は、実際の使用タスクに近い環境で圧縮版をベンチマークすることであり、単に文法的に正しい文章を生成できるかどうかを確認するだけでは不十分です。

同様に、安易なプルーニングも同じ問題を引き起こします。最も単純な手法である単純なマグニチュードプルーニングに関する研究では、大規模言語モデル（LLM）において、比較的緩やかなスパースティレベルでも劇的な失敗が確認されています。これは、Wanda プルーニング手法を開発したチームが直接文書化している事実です。LLM は、マグニチュードプルーニングが元々設計された小規模なネットワークに比べて、安全にプルーニングするのがはるかに困難であることが判明しています。

本記事で紹介する 5 つの手法は、2 つの失敗モードの間に位置するように設計されています。つまり、数週間にわたって構築したモデルを静かに壊すことなく、真に意味のある圧縮を実現するための慎重なアプローチです。

5 つの手法を一覧で

各手法の詳細に入る前に、全体像を確認しましょう。3 つは量子化（quantization）手法、2 つはプルーニング（pruning）手法です。これらは必要なセットアップの手間や、実際に最適化されている対象において明確な違いがあります。

Method 1: bitsandbytes (NF4 4-Bit Quantization)

この手法は、多くのチームがまず検討すべき最初の選択肢です。そのシンプルさゆえに、多くのガイドで過小評価されている傾向がありますが、実際には単一の関数呼び出しで利用可能です。

この手法の中心にあるのは「NF4（NormalFloat4）」と呼ばれるデータ型です。これは、ニューラルネットワークの重みが数直線上に均等に分布するのではなく、おおよそ正規分布に従うという事実に基づいて設計されています。そのため、利用可能な 4 ビット値は均一に並べるのではなく、実際の重みが密集している領域に配置されます。

また、このリストにある手法の中で唯一、QLoRA をサポートしています。つまり、モデルを 4 ビットで読み込んだまま、凍結された 4 ビットのベース重みを直接触ることなく、その上に小さな低ランクアダプター（low-rank adapter）の重みを学習させることでファインチューニングが可能です。ファインチューニングを検討しているなら、これが自然な出発点となります。

from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
import torch

model_id = "meta-llama/Llama-3.1-8B-Instruct"

# Configure 4-bit NF4 quantization with double quantization enabled
bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,                      # load weights in 4-bit instead of 16-bit
    bnb_4bit_quant_type="nf4",              # NormalFloat4: a data type tuned for
                                             # the normal-ish distribution of NN weights
    bnb_4bit_compute_dtype=torch.bfloat16,  # matmuls are upcast to bfloat16 at
                                             # compute time, weights stay stored at 4-bit
    bnb_4bit_use_double_quant=True,         # quantizes the quantization constants
                                             # themselves, saving roughly another
                                             # 0.4 bits per parameter on top
)

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    quantization_config=bnb_config,
    device_map="auto",                       # spreads layers across available
                                              # GPU(s), offloading to CPU if needed
)

inputs = tokenizer("Explain quantization in one sentence.", return_tensors="pt").to(model.device)
output = model.generate(**inputs, max_new_tokens=40)
print(tokenizer.decode(output[0], skip_special_tokens=True))

実際に重要となるポイントを整理しましょう。load_in_4bit=True は処理全体を起動するスイッチです。これにより、オフラインでの量子化工程を経る必要なく、読み込み時にすべての線形層の重みを 4 ビットに変換します。これがこの手法が最も高速に動作する理由です。

また、bnb_4bit_quant_type="nf4" を指定することで、単純な 4 ビット整数ではなく、分布を考慮した形式を選択できます。これにより、モデルの品質を元の状態に近づけつつ、盲目的な丸め処理を防ぐことが可能になります。

bnb_4bit_compute_dtype=torch.bfloat16 という設定が重要な理由は、重みがメモリ上では 4 ビットで保存されているものの、実際の行列計算時には GPU がネイティブの 4 ビット演算カーネルを持っていないため、一時的に bfloat16 にアップキャストされるからです。この行は、その中間精度を制御する役割を果たします。また、bnb_4bit_use_double_quant=True を設定することは、実質的にコストをかけずにメモリ使用量を削減できる小さなメリットがあります。これは、重みを量子化する際に用いるスケーリング定数自体も再度量子化することで、精度への影響を最小限に抑えつつ、さらにわずかながらメモリを節約する仕組みです。

Method 2: GPTQ (Calibrated Post-Training Quantization)

GPTQ は 2022 年に Frantar らによって発表されたオリジナルの GPTQ 論文で導入された、大規模モデルにおいても十分に機能することが実証された最初の 4 ビット手法の一つです。この手法が単純な丸め処理と異なる点は、モデルを層ごとに量子化し、各層内でヘッセ行列の近似である二次情報を用いて、ある重みを丸めた際に周囲の理想値にどのような影響を与えるかを計算し、その誤差を補正するために層内の未量子化の重みを調整する点にあります。これは、すべての重みを独立して量子化して誤差が蓄積しないことを期待するのではなく、量子化プロセス自体に誤差修正を組み込んだアプローチです。

このメカニズムを正確に機能させるには、ヘッセ統計量を推定するためのキャリブレーションデータセットが必要です。通常は、代表的なテキストから選ばれた数百サンプルを用います。

from transformers import AutoModelForCausalLM, AutoTokenizer, GPTQConfig
import torch

model_id = "meta-llama/Llama-3.1-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_id)

# GPTQConfig drives both calibration and quantization in a single pass
gptq_config = GPTQConfig(
    bits=4,                      # target bit-width per weight
    dataset="c4",                 # calibration text used to estimate the
                                  # Hessian-based error compensation
    tokenizer=tokenizer,
    group_size=128,               # weights are quantized in groups of 128,
                                  # balancing accuracy against compression ratio
    desc_act=False,               # skips activation-order permutation for
                                  # faster inference, at a small accuracy cost
)

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    quantization_config=gptq_config,
    device_map="auto",
    torch_dtype=torch.float16,
)

model.save_pretrained("./llama-3.1-8b-gptq-int4")
tokenizer.save_pretrained("./llama-3.1-8b-gptq-int4")

このスニペットの中で最も重要な役割を果たしているのが dataset="c4" の行です。これは、GPTQ が層ごとの誤差補正を計算するために必要な活性化統計値 G を収集する際にモデルが前向きパスを実行する対象データセットであり、実際のトラフィックに近いデータセットを使用することで、汎用的なデータセットよりも実世界での結果が向上します。

group_size=128 は量子化の粒度を制御しています。グループサイズを小さくすると、より多くのスケーリング定数が保存されるためメモリ使用量がわずかに増加しますが、その分精度が高まります。128 という値は、コミュニティで標準的な中間点として採用されています。

desc_act=False は、最も影響の大きい重み列を先に処理する並べ替えステップを無効にします。このステップは精度をわずかに向上させますが、量子化プロセス自体と、一部のサービング環境では推論速度も低下させるため、GPU サービングを優先し、量子化が一度きりのコストで推論速度がすべてのリクエストで重要となる設定では、通常はこのオプションは無効にされます。

GPTQ の真の限界を、単なる賛辞ではなく率直に指摘しておく価値があります。Jarvis Labs が 2026 年 1 月に実施したベンチマークでは、同じハードウェア上で主要な 4 ビットフォーマット 4 つを並列実行しましたが、その結果、コード生成タスクにおいて GPTQ は AWQ や GGUF に後れをとることが明らかになりました。具体的には、HumanEval のスコアで GPTQ が約 46% だったのに対し、AWQ と GGUF はいずれも 51.8% 前後を記録しています（詳細は The AI Engineer's format comparison で報告されています）。

その主な原因として、GPTQ は列ごとの誤差伝播が長い行列全体で蓄積しやすく、単純な次トークン予測よりも、正しいコードを書くような多段階推論が必要なタスクにおいて性能低下が顕著になることが挙げられます。それでも GPTQ は堅牢で成熟した選択肢であり、すでに GPTQ チェックポイントが良好に動作している環境では依然として有力です。ただし 2026 年の新しいセットアップにおいては、もはや自動的に最初に選ばれる選択肢ではなくなっています。

Method 3: AWQ (Activation-Aware Weight Quantization)

AWQ は、Lin らの 2023 年論文で提案された手法ですが、同じ根本的な課題に対して異なるアプローチを採用しています。GPTQ が事後に誤差を補正するのとは異なり、AWQ は「どの重みが実際に重要か」という観察から始めます。短いキャリブレーションパス中に活性化値を観測することで、モデルの出力に大きな影響を与える少数の「重要な」重みチャネルを特定します。具体的には、一貫して最大の活性化値を生み出すチャネルがこれに該当します。

AWQ は、これらの重要な重みをスケーリングというトリックで保護し、実質的な精度を維持します。一方、それ以外の重みは積極的に量子化されます。

この標的を絞った保護機能が、2026 年の生産環境における GPU サービングのデファクトスタンダードとして AWQ が選ばれる大きな理由です。特に指令微調整済みモデルでは、少数の重みが持つ意味的な重要性が出力品質に決定的な影響を与えるため、この手法は極めて有効です。

from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "meta-llama/Llama-3.1-8B-Instruct"
quant_path = "llama-3.1-8b-awq"

quant_config = {
    "zero_point": True,       # asymmetric quantization: shifts the zero point
                               # instead of forcing weights to center on zero
    "q_group_size": 128,      # same grouping idea as GPTQ, 128 weights per group
    "w_bit": 4,                # 4-bit weights
    "version": "GEMM",         # kernel variant tuned for batched GPU inference
}

model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)

# quantize() runs the calibration pass, identifies the salient weight
# channels by observing activation magnitudes, and protects them while
# aggressively quantizing everything else
model.quantize(tokenizer, quant_config=quant_config)

model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)

zero_point=True を指定すると、量子化された範囲がゼロを中心に固定されるのではなくシフトできるようになります。これは、実際の重み分布が完全にゼロ中心であることは稀であり、非対称な量子化によってその形状をより忠実に捉えられるためです。また、q_group_size=128 は GPTQ と同じ役割を果たし、グループレベルでの精度とメモリのトレードオフを制御します。

目標とする精度は w_bit=4 です。また、version="GEMM" を指定することで、推論時に AWQ がコンパイルするカーネルを選択できます。GEMM は、サーバーが複数の並行リクエストを処理する際に発生するバッチ化された行列乗算に特化したバリアントであり、これが実際のプロダクション環境でのサービングの典型的なシナリオです。

この数字が、なぜこれがデファクトスタンダードとなったかの根拠となっています。Marlin推論カーネルを使用すれば、AWQは元のFP16モデルと比較して約1.6倍高速に動作し、コード生成の精度も約92%を維持します（Premaiの2026年量子化比較 [https://www.premai.io/blog/llm-quantization-guide-gguf-vs-awq-vs-gptq-vs-bitsandbytes-compared-2026/] による）。正直に付け加えるなら、背後に最適化されたカーネルがない場合、AWQは単なるFP16よりも遅くなる可能性があります。そのため、フォーマットとそれを動作させるサービングスタックは別々に選ぶのではなく、セットで選択する必要があります。

メソッド4：SparseGPT（ワンショット構造化プルーニング）

ここからは数値を圧縮する段階から、重みそのものを削除する段階へと話題が移ります。2023 年に Frantar と Alistarh が発表した論文 SparseGPT で提案された手法は、大規模言語モデル（LLM）を再学習なしで大胆に剪定できることを初めて実証したものです。当時、単純な大きさに基づく剪定法がこれほど大きなモデルには適用できないというのが定説でした。

この手法は、層ごとの再構成問題として剪定を捉えています。各層においてどの重みを削除するかを決定し、その一連の処理の中で、削除された重みの影響を補償するために、残った重みも同時に更新します。これには GPTQ のアプローチと同様の精神で、2 次導関数（ヘッセ行列）の情報を利用しています。

ここで最も重要なのは、スパース性のパターンです。個々の重みの値が低いものを何らかのパターンなしにゼロ化する「非構造化スパース性」は、ディスク上のメモリを節約できますが、標準的な GPU ハードウェア上では実際の速度向上にはつながりません。なぜなら、その重みがゼロであってもハードウェア側はメモリのすべての重みをロードする必要があるからです。

これを変えるのが、NVIDIA が採用している「2:4 構造化スパース性」です。これは連続する 4 つの重みごとに必ず 2 つがゼロになるという規則的なパターンを指します。Ampere、Hopper、Blackwell GPU に搭載された Sparse Tensor Cores は、行列乗算の際にこれらのゼロ化された重みを完全にスキップできるため、単にファイルサイズが小さくなるだけでなく、実際に測定可能な速度向上を実現します。

この仕組みの詳細については、Spheron の SparseGPT と Wanda を GPU クラウド上で実行するためのガイド をご参照ください。

# Clone the official SparseGPT repository
git clone https://github.com/IST-DASLab/sparsegpt
cd sparsegpt

# Run one-shot pruning with structured 2:4 sparsity
python llama.py meta-llama/Llama-3.1-8B-Instruct c4 \
    --sparsity 0.5 \        # target: 50% of weights removed overall
    --prunen 2 --prunem 4 \ # enforce a 2:4 pattern, 2 zeros in every group of 4,
                             # required for real Sparse Tensor Core speedups
    --save llama-3.1-8b-sparsegpt-2-4

2 つの位置引数、すなわちモデル識別子と c4 は、スクリプトに対してどのモデルを剪定するか、および Hessian 統計量を推定するために順方向パスを実行するキャリブレーションデータセットを指定します。この役割は、GPTQ におけるキャリブレーションデータの機能と実質的に同じです。

--sparsity 0.5 で全体の目標スパースティを設定し、剪定対象の層にある重みの半分が削除されます。また、--prunen 2 --prunem 4 というフラグペアを指定することで、非構造化された剪定ではなく、2:4 の構造的パターンを強制します。これは、単にディスク上のチェックポイントサイズを小さくするだけでなく、実際の推論速度向上を目指す場合に、このコマンドで最も重要な設定です。

70B モデルの場合、1 つの H100 GPU で実行するには約 1 時間かかる見込みですが、7B から 8B の範囲であればそれよりも considerably less（はるかに短時間）で完了します。

Method 5: Wanda (Pruning by Weights and Activations)

Sun と同僚たちの 2023 年の論文[1] に掲載された「Wanda」は、Weights and Activations を用いた剪定手法の略称です。この手法は SparseGPT の核心的な洞察を引き継ぎつつも、それをよりシンプルなものに再構築しました。

Hessian 逆行列を用いて層ごとの完全な再構成問題を解くのではなく、Wanda は各重みのスコアを「重みの大きさ」と「対応する入力活性化の L2 ノルム」の積によって算出します。この指標は、モデル全体を一度順方向パスさせるだけで計算可能です。

その後、重み更新ステップは一切行われません。生き残った重みは、もともとあった値のまま維持されます。

[1]: https://arxiv.org/abs/2306.11695

このシンプルさが、そのまま速度の向上につながります。ヘッセ行列の逆行列計算や、列ごとの反復解法が不要なため、Wanda の論文によると、SparseGPT と比較して計算速度は約 300 倍高速です。また、70B クラスのモデルでの独立したベンチマークでは、実測時間（wall-clock time）で 5〜10 倍速く動作し、ピークメモリ使用量は約半分であることが確認されています（詳細は Spheron の実践的比較 を参照）。品質面では、どちらの方法が優れているか一概には言えません。SparseGPT は 2:4 の構造化スパース性において 7B 前後の小型モデルでわずかに上回る傾向がありますが、Wanda は LLaMA-30B などの大型モデルにおいてより高い性能を維持します（これは元論文の結果に基づくものです）。

# Clone the official Wanda repository
git clone https://github.com/locuslab/wanda
cd wanda

# Run one-shot pruning: a single forward pass, no Hessian, no weight update
python main.py \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --prune_method wanda \      # selects the magnitude-times-activation metric
    --sparsity_ratio 0.5 \      # remove 50% of weights overall
    --sparsity_type 2:4 \       # structured pattern for real GPU speedups
    --save out/llama-3.1-8b-wanda-2-4

--prune_method wanda は、この特定のスコアリング手法を選択するためのフラグです。これにより、単純な重み値ベースのプルーニングや SparseGPT 自体など、スクリプトがサポートする他の手法の中から Wanda が選ばれます。これらはいずれも同じツール内で並列に実装されており、直接比較が可能です。--sparsity_ratio と --sparsity_type は SparseGPT のフラグとほぼ同じ仕様で、重みの半分を削除し、ハードウェアが実際に活用できる 2:4 パターンに構造化します。Wanda を SparseGPT に代えて採用する実用的な理由は、モデルが十分に大型である場合や、キャリブレーションセットの規模が大きい場合に発生します。その場合、SparseGPT の逆ヘッセ行列計算がボトルネックとなり、プルーニング自体の決定よりも計算コストの方が問題になるからです。

組み合わせる：プルーニングと量子化を同時に活用する

これら5つの手法は、1つだけを選ぶメニューのようなものではありません。プルーニング（剪定）と量子化は、同じ課題の異なる側面に対処するものであり、両方を組み合わせることで単独で使う場合よりも大きな効果が得られます。

例えば、70BパラメータのモデルをまずSparseGPTやWandaを使って構造的なスパース性を50%までプルーニングし、残りをAWQやGPTQで量子化すると、元々FP16形式では140GB必要だったモデルが、わずか17〜18GBに圧縮できます。これなら、Spheronの組み合わせベンチマーク こちら で示されているように、高性能なコンシューマー向けGPU 1台でも快適に動作させることが可能です。

順序も重要で、これは単なる好みではありません。最初にプルーニングを行い、その後に量子化を行うのが正しい手順です。なぜなら、量子化のステップでは、すでにプルーニングによって生じたギャップも含めたモデルの実際の最終的な重み分布に対してキャリブレーション（較正）が行われるからです。

逆に、先に量子化してその後でプルーニングを行うと、プルーニングの段階で重みを削除する判断を下す際に、すでに丸められて歪んだ重みが基準になってしまいます。これにより、2つの誤差要因が互いに悪影響を及ぼし合い、最初のステップの変更を2番目のステップがきれいに補正できなくなるのです。

状況に合った適切な手法の選び方

5 つの選択肢が提示された場合、実際の判断は「何を最適化したいか」に帰着します。前述の比較表は、現実世界の選択とほぼ直結しています。

ファインチューニング（推論だけでなく）を計画の一部に含めるなら、bitsandbytes と QLoRA がこのリストの中で唯一、ゼロからその目的のために設計された手法です。

vLLM などの大規模サービスで提供し、純粋なスループットが最優先される場合、AWQ に Marlin カーネルを組み合わせたものが、正当な理由から現在のデファクトスタンダードとなっています。

すでに GPTQ チェックポイントが生産環境で安定して動作しているなら、それ自体のために移行する強い理由はめったにありません。ただし、新しいプロジェクトを始めるのであれば、今日からは AWQ を採用するのがより適切です。

ラップトップやエッジデバイスへのデプロイ、あるいは Ollama や LM Studio 経由での利用を考える場合、その世界は上記の 3 つの量子化手法ではなく GGUF フォーマットを基盤としています。GGUF は効率的な CPU 推論のために特別に設計されたフォーマットであり、最終的な展開（ラストマイル）では圧縮モデルのほとんどがこれに変換されることを知っておく価値があります。

For pruning specifically, the choice usually comes down to model size and how much compute you're willing to spend on the pruning pass itself. SparseGPT's extra weight-update step tends to edge out Wanda's quality on smaller models in the 7B range. Wanda's dramatically lower compute cost makes it the more practical choice as models get larger, when SparseGPT's Hessian computation starts to become a real bottleneck rather than a rounding error in your timeline.

まとめ

None of these five methods make a model worse in any meaningful sense, done properly. They make it honest. Most large models ship with more precision and more parameters than the task in front of them actually requires, carried over from training runs optimized for a different goal than the one deployment cares about. Quantization and pruning are how you find out what a model genuinely needs to keep doing its job well, and cut the rest.

Start with whichever of these five fits the constraint you're actually up against right now — memory, latency, hardware you don't have, or a fine-tuning step you still need to run — rather than chasing the method with the best benchmark number on a task that isn't yours. Benchmark the result on something that resembles your real traffic before you trust it. That's the whole discipline here, and it's a lot more approachable than the size of these models makes it feel.

ソフトウェアエンジニアであり技術ライターであるShittu Olumide氏は、最先端の技術を駆使して説得力のある物語を紡ぐことに情熱を注いでいます。細部への鋭い眼差しと、複雑な概念をわかりやすく解説する能力に長けており、その成果はTwitterでも確認できます。