LLM量子化ガイド:7つの手法をベンチマーク数値つきで比較

LLM量子化ガイド:7つの手法をベンチマーク数値つきで比較

Llama 3.3 70BをFP16で動かすなら、重みだけで140 GB必要です。H100が2枚要ります。Q4_K_Mなら同じモデルが約42 GBに収まり、これはeBayで売っている中古RTX A6000 1枚で足りるサイズです。この差こそLLM量子化が存在する理由そのものです。そして手法を間違えると、目に見える品質低下か、持ち合わせていないVRAMの不足か、どちらかを払うことになります。

本LLM量子化ガイドでは、2026年に意味のある7つの手法を比較します。すべての数値は公開ソースまで遡って確認しています。

要点

• 量子化はメモリとバンド幅を、測定可能で通常は小さい品質低下と交換する技術です。
• GPTQとAWQはGPU前提。GGUFはCPUでも動くフォーマットです。
• Q4_K_Mは重みあたり約4.8 bitに落ち着き、4 bitではありません。命名規則がオーバーヘッドを隠しています。
• llama.cppのk-quants PRによれば、6bit量子化のパープレキシティはFP16との差が約0.1%以内です。

LLM量子化はモデルに実際何をするのか

LLM量子化はモデルの重みをより低い数値精度で保存し、丸め誤差と引き換えにメモリとバンド幅を圧縮します。70BパラメータのモデルはFP16の140 GBから、4bitなら約42 GBまで下がります。知能は残り、小数点以下の桁が消えるだけです。本ガイドのすべての手法は、このトレードオフの亜種にすぎません。

精度のはしごはFP32(32bit)から始まり、FP16とBF16(各16bit)を経て、INT8、そしてINT4へ下がっていきます。1段降りるごとにパラメータあたりのバイト数は半分になります。浮動小数点フォーマットはIEEE 754標準で定義されています。Mark Horowitzが2014年に発表した論文「Computing's Energy Problem」は、エネルギーコストの大部分を占めるのが演算そのものではなくデータの移動であることを示しました。量子化で推論が高速化する物理的な理由はそこにあります。

量子化を機能させるパラメータは2つあります。スケールファクター(整数の範囲を実数値へ逆写像する乗数)と、ゼロポイント(0.0を表す整数)です。対称量子化は範囲をゼロ中心に置き、ゼロポイントを省略します。非対称量子化は、重みがゼロからずれて分布している場合にオフセットを設け、整数の全範囲を使い切ります。

重みは静的で正規分布しているため、きれいに量子化できます。アクティベーションはそうはいきません。外れ値のアクティベーションは中央値の100倍に達することもあり、素朴に量子化すると丸め誤差が爆発します。この非対称性があるため、ここで扱う手法の多くは重みだけを量子化(W4A16)し、アクティベーションはFP16のまま残します。

学習後量子化(PTQ: Post-Training Quantization)は、学習が終わった完成済みモデルを変換します。量子化対応学習(QAT: Quantization-Aware Training)は学習中に丸めを疑似的に再現し、モデルを適応させます。本記事で扱うのはすべてPTQです。QATはより多くの計算資源と学習の実行を伴うため、別の判断になります。

INT4とNF4の行は、理論上の純粋な4bit、つまり重みあたり4bitだけで他は何もない場合の数値です。実際の4bitフォーマットはブロックごとのスケールと最小値を載せるため、これより大きくなります。70BモデルのQ4_K_Mは35 GBではなく約42 GBです。下のVRAM表では、代わりに実効レートを使っています。

量子化はモデルの知能を縮小するのではありません。その知能を格納する小数点以下の桁数を縮小するだけです。そしてAPI推論にトークン単位で課金しているなら、LLMのAPIコスト削減は、多くの場合、量子化モデルを自分で動かすことから始まります。

7つの量子化手法を一覧で比較

以下の7つの手法は、2026年にLLMを量子化するための本番運用ルートをすべて網羅しています。2つはGPU専用(GPTQ、AWQ)、1つはどこでも動きます(GGUF)、1つはロード時に量子化します(BitsandBytes)、2つは高スループットサービングを狙ったもの(SmoothQuant、FP8)、そして1つはPyTorchネイティブ(TorchAO)です。正しい選択はハードウェアで決まり、リーダーボードで最も高いスコアを出した手法で決まるわけではありません。

GPTQはレイヤーごとに量子化し、逆ヘッセ行列を使って丸め誤差を残りの重みに再配分します。キャリブレーションセットとGPUが必要です。GPTQの論文によれば、175Bモデルの3-4bit量子化が約4 GPU時間で完了します。

AWQは最も重要な重み(アクティベーションの大きさから見つかる、約1%の顕著な重み)を特定し、スケーリングして丸めから保護します。AWQの論文(MLSys 2024ベストペーパー)によれば、デスクトップとモバイルの両方のGPUで、HuggingFaceのFP16実装に対して3倍以上の高速化を報告しています。

GGUFはファイルフォーマットであり、アルゴリズムではありません。内部のアルゴリズムはllama.cpp PR #1684由来のk-quantブロック方式です。本ガイド中でCPUで動く唯一の手法であり、ローカル推論のデフォルトになっています。何を読み込ませるかは量子化する価値のあるオープンウェイトモデルを参照してください。

BitsandBytesは事前変換ではなくロード時に量子化します。NF4(4bit NormalFloat)がその象徴的なフォーマットで、QLoRAファインチューニングの屋台骨です。キャリブレーションセットは不要です。

SmoothQuantはアクティベーションの外れ値を重み側へ移し、両方をINT8で動かせるようにします。論文は最大1.56倍の高速化と2倍のメモリ削減を報告しており、W4A16手法では性能を取りこぼす大バッチサービングのスループットを狙い撃ちにします。

**FP8(W8A8)**はH100およびB200 GPUにおけるネイティブなルートです。8bitでほぼロスレス、キャリブレーションの頭痛もなく、vLLMが直接サポートしています。

TorchAOはPyTorch独自の量子化ライブラリで、torch.compileと組み合わせて動くよう作られています。パイプラインがすでにPyTorchなら、最も抵抗の少ないルートです。

実質的な問いは2つしかありません。そのハードウェアで動くのか、そして品質コストを許容できるのか、です。

公開ベンチマークは実際何を示しているのか

公開ベンチマークによれば、4bit量子化のコストは7Bモデルでパープレキシティ1-2%、6bitなら0.1%未満です。これらの数値はllama.cpp PR #1684(2023年)由来で、llama.cppのメンテナがRTX 4080上の単一7Bモデルで測定しました。量子化の分野で最も引用される数値であり、実在します。同時にn = 1でもあります。

出典:llama.cpp PR #1684(2023年)。7Bモデル、RTX 4080、llama.cppメンテナによる測定。n = 1モデル。

ビット/重みの列について補足します。これらは基礎となるk-quant型の公称レートであり、_Kの混合は実効レートを押し上げます。Q2_Kがまさにその例です。公称の2.5625と6.74Bパラメータのモデルに本記事の計算式を当てはめると約2.0 GBになりますが、この行は2.67 GBのファイルを報告しており、逆算すると重みあたり約3.4 bitになります。本記事の残りの部分では、これらのファイルサイズから導いた実効レートを使います。

GPU手法の数値は論文から直接取っています。GPTQはFP16に対するエンドツーエンドの推論高速化を、A100で約3.25倍、A6000で約4.5倍と報告しており、175Bモデルの3-4bit量子化が約4 GPU時間で完了します。AWQは「デスクトップとモバイルの両GPUでHuggingfaceのFP16実装に対し3倍以上の高速化」に加え、TinyChat経由でモバイルGPU上への70B Llama-2初のデプロイを報告しています。数値を偽の精度に言い換えるのではなく、論文の表現をそのまま引用しています。

ここでの独自の貢献は計算です。重みのメモリは次の式に従います。weights (GB) ≈ params (B) × bits per weight ÷ 8。落とし穴は、どのビット/重みの数値を代入するかです。PR #1684は基礎のk-quant型のレート(Q4_K = 4.5)を公開しており、_S/_M/_Lの混合は、アテンションとフィードフォワードのテンソルに追加ビットを割り当てるため、その基礎レートより上に位置します。そこで、PR自体が公開するファイルサイズから実効レートを導きました。対象は実際には6.74Bパラメータの7Bモデルです。Q2_Kは2.67 GBから逆算して約3.4 bpw、Q4_K_Sは3.56 GBで約4.5、Q6_Kは5.15 GBで約6.6。Q4_K_Mは約4.8に落ち着きます。

これは見出しの数値を変えます。70BモデルのQ4_K_Mなら70 × 4.8 ÷ 8 = 42 GBです。多くの記事は35 GBと言います。4.0 bpwを使い、ブロックスケールのオーバーヘッドを完全に無視しているからです。裏付けはワンクリックで取れます。Llama-3.3-70B-Instruct-Q4_K_M.ggufはHuggingFaceで42.5 GBで配布されており、bartowski、lmstudio-community、second-stateのいずれのリポジトリでも同じです。下のVRAM表のすべてのセルを、この基準で再計算しました。

これらの数値に対する私たちの読みはこうです。Q6_K(5.9110)とF16(5.9066)のパープレキシティ差は0.0044で、これは同じベースモデルの2つの異なるファインチューン間の差より小さい。だからこそ「とりあえずQ4_K_MかQ5_K_Mを使え」が、実際のハードウェアとの接触に耐えられる助言です。ms/トークンの列も、Q2_KがQ4_K_Sより高速化の恩恵がないことを示しています(両方とも15.5 ms/トークン)。それでいてパープレキシティを0.75犠牲にします。Q2_Kはこの表の中で最悪のトレードです。

数値が教えてくれないこともあります。wikitextのパープレキシティは、あなたのプロンプトに対する品質と同じではありません。1つのGPU上の1つのモデルはn = 1です。速度の数値はバッチサイズに依存します。これらは方向性の指標として扱い、普遍的なものとして扱わないでください。

6bit量子化は、全精度モデルのパープレキシティから約0.1%以内に収まります。この水準では圧縮はほぼ無料です。

GPTQ vs AWQ:2つのGPU手法の選び方

GPTQとAWQはどちらもキャリブレーションセットから4bitのGPUチェックポイントを生成し、どちらもvLLMで手厚くサポートされています。違いは丸め誤差の扱い方です。GPTQは逆ヘッセ行列を使って残りの重みに誤差を再配分します。AWQはアクティベーションが重要と示した1%の重みを保護します。どちらも機能します。選択はサービング形態次第です。

GPTQはレイヤーごとに処理します。各レイヤーで1つずつ重みを量子化し、その直後に行った丸めを補償するよう、同じレイヤーの残りの重みを調整します。この調整にはヘッセ行列の2次情報を使うため、計算にはキャリブレーションセットが必要です。結果として、トークンごとのレイテンシよりスループットが重要なバッチ推論で強い性能を発揮します。

AWQは別の角度から攻めます。キャリブレーションセット全体のアクティベーションの大きさを見て顕著な重みを特定します。おおよそ上位1%のチャネルです。これらの重みはチャネルごとのスケールファクターを得て、丸め中に高い精度の範囲に留まります。キャリブレーションセットはGPTQより小さくて済み、特定の入力にフィットするのではなく構造的な特徴を保護するため、オーバーフィットも少なくなります。論文はレイテンシ重視のサービングで強い結果を報告しています。

GPTQを選ぶ場面: GPUでバッチ推論をしていて、ドメインに合った質の良いキャリブレーションセットがあり、指標がスループットの場合。

AWQを選ぶ場面: 低レイテンシでシングルユーザーのリクエストをサービングしている場合、より小さいキャリブレーションセットで済ませたい場合、またはエッジ/モバイルGPUにデプロイする場合。

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

サービングエンジン自体の選択でも迷っているなら、vLLMとSGLangの比較がその判断を別途カバーしています。

GGUFとK-Quants:Q4_K_Mの本当の意味

GGUFはファイルフォーマットであり、量子化アルゴリズムではありません。GGUFの仕様は、モデルの重み、メタデータ、トークナイザーデータを格納するコンテナを定義しています。GGUFファイル内部の量子化アルゴリズムは、llama.cpp PR #1684由来のk-quant(またはi-quant)ブロック方式です。コンテナとアルゴリズムを取り違えるのはこの分野で最も多い間違いで、「GGUFとGPTQはどちらが良いのか」という、かみ合わない質問につながります。

命名規則は次のように解読できます。Qはk-quantブロック方式を意味し、IQは重要度行列を使うi-quant(同じビット深度でより高い品質を得る、新しい亜種)を意味します。数字は公称のビット深度です。_Kは、Q4_0のようなレガシーフォーマットに対するk-quantファミリーの印です。_S、_M、_Lは、どのテンソル群に追加ビットを割り当てるかを制御します。small、medium、largeです。サフィックスが大きいほど、最も重要なアテンションとフィードフォワードのテンソルにより多くのビットが割り当てられます。

実効レートは、PR #1684が公開する7B(6.74Bパラメータ)のファイルサイズから逆算したもので、基礎となる型の数値ではありません。レガシーの行は構造的に正確です。Q4_0ブロックは32個の重みを4bitで保持し、FP16スケールを1つ加えるため、重みあたり4.5bitです。Q8_0は32個の重みを8bitで保持し、FP16スケールを加えるため8.5bitです。PRもこれを裏付けており、7BのQ4_0とQ4_K_Sのファイルを同じ3.56 GBと記載しています。

Q4_K_Mは重みあたり4bitではありません。約4.8bitです。ブロックのスケールと最小値はどこかに格納する必要があり、_Mの混合はその上でアテンションとフィードフォワードのテンソルに追加ビットを使います。Q4_K_MがQ4_K_Sより上に位置し、Q3_K_MがQ3_K_Sと一致せず上にあるのは、まさにこのためです。

GGUFがGPTQの届かない場所で動く理由。CPU推論と、GPU VRAMとシステムRAM間のレイヤーオフロードをサポートしているからです。GPUに完全には収まらない32Bモデルでも、レイヤーの半分をオフロードすれば動かせます。遅くはなりますが、機能はします。GPTQにCPUルートはありません。

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

ローカルモデルは初めてですか。何かを量子化する前に、まず最初のローカルモデルを動かすから始めてください。ブラウザUIが欲しいなら、Ollamaの上でOpen WebUIが約10分で導入できます。HuggingFaceのGGUFドキュメントは、Hubが量子化型の命名をどう公開しているかを説明しています。

BitsandBytes、Marlin、SmoothQuant、TorchAO

これら4つは、残りの本番運用ルートをカバーします。いずれも「より良いGPTQ」ではありません。それぞれ別の問題を解決します。

BitsandBytesは事前変換ではなくロード時に量子化します。FP16チェックポイントを指定すれば、その場でNF4またはFP4へ変換します。キャリブレーションセットもオフラインの工程も不要です。主な売りはQLoRAです。4bitに固定したベースモデルの上にLoRAアダプターを学習する手法で、65BモデルのシングルGPUファインチューニングを48 GBのVRAMで可能にします。QLoRAは推論ではなく学習の技術ですが、多くの人がBitsandBytesと最初に出会うきっかけでもあります。

Marlinは量子化手法ではありません。INT4xFP16の混合精度GEMMカーネルで、中程度のバッチサイズにおいて既存の4bitチェックポイントを高速化します。Marlinの論文はA100とH100での高速化を報告しています。サービングスタックがサポートしているなら、すでに量子化済みのモデルに対して有効化します。「Marlinで量子化する」ということはありません。

SmoothQuantはチャネルごとのスケーリングファクターを介してアクティベーションの外れ値を重みへ移し、W8A8(重みとアクティベーションの両方をINT8に)を実用的にします。論文は、W4A16手法ではスループットを取りこぼす大バッチサービングを狙い撃ちにします。数百の同時リクエストをサービングしているなら、これが決め手です。

TorchAOはtorch.compileと組み合わせて動く、PyTorchネイティブの量子化です。外部依存もフォーマット変換もありません。推論パイプラインがすでにPyTorchなら、最も摩擦の少ない選択肢です。Embeddingモデルをローカルで動かす用途ではOllamaルートの方がたいていシンプルですが、TorchAOはカスタムのPyTorchスタックに合います。

量子化モデルにはどれだけのVRAMが必要か

計算式はweights (GB) ≈ params (B) × bits per weight ÷ 8です。70BモデルのQ4_K_Mなら70 × 4.8 ÷ 8 = 42.0 GB。下のレートは実効値で、llama.cpp PR #1684が公開するファイルサイズから逆算したものであり、基礎となる型の数値からではありません。_Mの混合は常に基礎のk-quantレートを上回るためです。よくある4.0-bpwの簡易計算を写すのではなく、再計算しました。

実効ビット/重みから計算:Q8_0 = 8.5、Q6_K = 6.56、Q5_K_M = 5.7、Q4_K_M = 4.8、Q3_K_M = 3.9。PR #1684の7B(6.74Bパラメータ)ファイルサイズから導出し、公開済みの70Bビルドと突合しました。Llama-3.3-70B-Instruct-Q4_K_M.ggufはHuggingFaceで42.5 GB、本記事の予測は42.0 GBです。

正直な注意点。これは重みだけの話です。KVキャッシュ、コンテキスト長、フレームワークのオーバーヘッドが上乗せされます。KVキャッシュはコンテキスト長とバッチサイズに比例して増えます。70Bモデルで32kコンテキストのセッションなら、数GBが加算され得ます。重みの表は下限であり、予算ではありません。コンテキストウィンドウもVRAMを間借りします。全体像はモデルごとのVRAM要件の詳細を参照してください。

どの量子化手法を使うべきか

好みより先に、ハードウェアが決めます。自分のGPUで動かない手法は選択肢ではなく、願望です。下の表は、上でカバーしたハードウェア制約と品質トレードオフに基づき、よくある環境を実際に機能する手法へ対応付けています。

コンシューマー向けハードウェアを使う大半の読者には、量子化済みのQ4_K_MまたはQ5_K_MのGGUFが正解です。HuggingFaceから取得し、Ollamaかllama.cppで動かし、最適化はそこでやめてください。Q4_K_MとQ5_K_Mの品質差は十分に小さいので、パープレキシティの表ではなく、ファイルが収まるかどうかで選ぶべきです。それ以上は最適化のための最適化であり、Q4でモデルが実際に問題を解決すると確認できてから初めて、取り組む価値が出ます。

実際にこれらのモデルをローカルで動かすツールガイドは、量子化レベルを決めた後のサービング側をカバーしています。

量子化で失敗する5つのパターン

量子化の失敗は、ほぼ常に手法の問題ではなく設定の問題です。次の5つは頻繁に起きます。

1. キャリブレーションセットがドメインに合っていない。 GPTQもAWQもキャリブレーションデータにフィットします。Wikipediaでキャリブレーションして医療の文字起こしにデプロイすれば、量子化モデルは一度も見なかったトークンで性能を落とします。対策:実際の入力分布から取ったキャリブレーションセットを使う。128サンプルでも効果があります。

2. グループサイズを大きく設定しすぎている。 GPTQのグループサイズは、何個の重みが1つのスケールファクターを共有するかを制御します。標準は128です。256や512は量子化中の計算を節約しますが、小さいモデルでは品質の崖にぶつかります。対策:自分のプロンプトで品質が保たれると確認できない限り、128に留める。

3. Q2_Kが実用的だと期待する。 PR #1684のデータによれば、Q2_KはF16に対してパープレキシティを約0.87犠牲にし、それでいてQ4_K_Sより高速化の恩恵がありません(7Bベンチマークで両方とも15.5 ms/トークン)。ファイルは小さくなりますが、レイテンシの利得なく出力は悪化します。対策:ファイルサイズが絶対制約でない限り、Q4_K_Sが下限です。

4. wikitextのパープレキシティでベンチマークし、自分のプロンプトで測らない。 パープレキシティは言語モデリングの指標です。モデルがシステムプロンプトに従うか、JSONを正しくフォーマットするか、ドメインの語彙を扱えるかは測りません。対策:実際のプロンプトを20-30個、量子化済みと未量子化の両モデルに通し、出力を比較する。

5. コンテナであるGGUFと、内部の量子化アルゴリズムを取り違える。 これは「GGUF vs GPTQ」を同じカテゴリであるかのように比較することにつながります。同じではありません。GGUFはファイルフォーマットです。内部のk-quant方式がアルゴリズムです。対策:ファイルフォーマットではなく、k-quantのレベル(Q4_K_M vs Q5_K_M)を比較する。

よくある質問

LLM量子化とは何ですか

LLM量子化はモデルの重みの数値精度を下げることで、通常は16bit浮動小数点から4bitまたは8bitの整数へ変換します。メモリ使用量を削減し、バンド幅を減らして推論を高速化します。70Bモデルは140 GBから4bitで約42 GBへ下がります。品質コストは通常、4bitでパープレキシティ1-2%、6bitならそれ以下です。

量子化はモデルの精度を下げますか

はい、しかし大半の人が予想するより小さいです。llama.cpp PR #1684のベンチマークによれば、7BモデルのQ4_K_SはF16に対してパープレキシティ約2%のコスト、Q6_Kは0.1%未満です。実際のプロンプトへの実用上の影響は、特にQ4_K_M以上では、パープレキシティの数値が示すより小さいことがよくあります。

GPTQとAWQはどちらが良いですか

どちらも普遍的に優れているわけではありません。GPTQは逆ヘッセ行列による誤差再配分を使い、バッチGPU推論に向きます。AWQはアクティベーションを考慮したスケーリングで顕著な重みを保護し、レイテンシ重視のサービングに向きます。AWQはより小さいキャリブレーションセットで済み、オーバーフィットも少なくなります。低レイテンシでシングルユーザーのリクエストをサービングしているなら、AWQから始めてください。

Q4_K_Mとはどういう意味ですか

Q4_K_Mはk-quantのGGUF量子化レベルです。「Q4」は公称4bitの深度、「K」はk-quantブロック方式(レガシーのQ4_0に対する)、「M」はmediumを意味し、アテンションとフィードフォワードのテンソルが追加ビットを得ます。実効の重みあたりビット数は4.0ではなく約4.8です。ブロックのスケールと最小値がオーバーヘッドを加え、mediumの混合がその上でさらに使うためです。

量子化モデルはCPUで動かせますか

はい、ただしGGUF経由のみです。GPTQとAWQはGPU専用のフォーマットです。GGUFのk-quantモデルはllama.cppやOllamaを通じてCPUで動き、GPU VRAMとシステムRAM間のレイヤーオフロードをサポートします。Q4_K_Mが標準的なCPU向け量子化です。トークン生成はGPUより遅くなりますが、推論は機能します。

GGUFとGGMLの違いは何ですか

GGMLは、llama.cppが当初使っていた古いテンソルライブラリ兼ファイルフォーマットです。GGUFは2023年8月に、より柔軟でメタデータサポートに優れたコンテナフォーマットとして置き換わりました。今日HuggingFaceからダウンロードするのはGGUFファイルです。GGMLファイルはレガシーで、今では配布されることはほぼありません。

自分で量子化すべきか、量子化済みをダウンロードすべきか

まずは量子化済みをダウンロードしてください。llama.cppとHuggingFaceのコミュニティは、人気モデルの大半をあらゆるレベルで量子化済みです。自分で量子化するのが意味を持つのは、ドメイン向けの特定のキャリブレーションセットが必要な場合か、対象モデルの量子化済みバージョンが存在しない場合だけです。

小さいモデルの代わりに量子化を使うべき時はいつですか

大きいモデルの能力が必要だがメモリに収まらない時に、量子化を使ってください。量子化した70Bモデルは、複雑な推論タスクでは一般に、未量子化の13Bモデルを上回ります。レイテンシが制約の場合は、代わりに小さいモデルを使ってください。小さいモデルは量子化の有無にかかわらず、トークン生成が高速です。

量子化と蒸留の違いは何ですか

量子化は既存モデルの重みの数値精度を下げるだけです。蒸留は小さいモデルに大きいモデルを模倣するよう学習させ、本質的に異なる(より小さい)アーキテクチャを生み出します。量子化は元のモデルのアーキテクチャを保ち、原理上は可逆です。蒸留は新しいモデルを作り、学習の実行を必要とします。

短いまとめ。量子化は、欲しいモデルを手元のハードウェアに収める方法です。コンシューマー向けGPUやApple Siliconを使う大半の人には、HuggingFaceから取得した量子化済みQ4_K_MのGGUFが解決策のすべてです。GPTQとAWQはGPUサービングの答え、FP8とSmoothQuantは本番スループットの答えです。それ以外はすべて、モデルが動くと確認した後の最適化です。

何をセルフホストするか決めていて、ハードウェアと手法の組み合わせにセカンドオピニオンが欲しいなら、お気軽にご相談ください。