Skip to content
Volver a la lista de artículos
AI Infrastructure12分

llama.cpp 量子化選定 2026: K-quants vs IQ-quants 実用比較と importance matrix

llama.cpp Quantization Tuning 2026: K-quants vs IQ-quants and Importance Matrix

山田 直樹ML Systems Engineer
2026-04-2412分
llama.cppGGUFローカルLLMセルフホスト中小企業 AI

Este artículo está publicado en japonés. Resumen en español a continuación:

llama.cpp Quantization Tuning 2026: K-quants vs IQ-quants and Importance MatrixGGUF の K-quants と IQ-quants は何が違うのか。importance matrix(imatrix)の役割と、CPU/GPU 構成・モデル規模ごとに失敗しない量子化選定の指針を、公開情報ベースで整理する。

GGUF と量子化が再注目される理由

llama.cpp が定義した GGUF は、ウェイト・トークナイザ・メタデータを単一ファイルに梱包する形式として、CPU・ハイブリッド推論のデファクトとなっている。2026 年現在、量子化の選択肢は K-quants と IQ-quants の2系統に大別される。それぞれの特性を理解しないままモデルを選ぶと、同じハードでも体感速度と出力品質が大きくぶれる。本稿では公開情報の範囲で、量子化方式の使い分けと importance matrix の意義を整理する。

K-quants:実用域の主軸

Q4_K_M、Q5_K_M、Q6_K といった「K」付きの量子化は、ブロックごとに異なるビット幅を割り当てるスマートな量子化戦略だ。llama.cpp のドキュメントや解説記事で繰り返し言及されている通り、Q4_K_M は「迷ったらこれ」と言える信頼できる既定値で、品質と速度のバランスが良く、特にコンシューマ GPU 上のトークン/秒で IQ 系より優位になる場面が多い。

実装的には、各ウェイトブロックに対して2レベルのスケールと最小値を持たせ、低ビット側はより細かいスケーリングで誤差を抑える。Q4_K_M はその「ミドルサイズ」を意味し、サブブロック単位でビット幅を変える設計だ。CPU 推論を含む幅広い環境で安定するため、社内のローカル LLM 標準としてはまず Q4_K_M を採用するのが安全である。

IQ-quants:低ビット域の品質を救う設計

IQ2_XXS、IQ3_XXS、IQ4_XS、IQ4_NL といった IQ 系は、より低ビット域での品質低下を抑えるために設計された量子化方式だ。コードブック(look-up table)と非一様量子化を組み合わせ、importance matrix によるキャリブレーションを前提としている。同じビット幅であれば一般に IQ 系のほうが品質を保ちやすい一方、CPU でのデコードが K-quants より重く、トークン/秒では K-quants が勝るケースも多いと報告されている(公開情報による)。

判断基準は単純化すると次の通りだ。

  • VRAM がモデルに対して厳しく、3bit 以下まで圧縮したい → IQ 系(IQ3_M、IQ3_XS)
  • VRAM に余裕があり、4-5bit で速度優先 → K-quants(Q4_K_M、Q5_K_M)
  • ロングコンテキスト用途で KV キャッシュも詰めたい → ウェイトは Q4_K_M、KV は別途量子化

Importance Matrix(imatrix)の正体

imatrix は、キャリブレーション用の入力テキスト集合に対する勾配・活性化情報から、各ウェイトの「壊しにくさ/壊してはいけなさ」を行列として推定するものだ。llama.cpp の `imatrix` ツールでキャリブレーションデータを流し、出力された行列を `quantize` に渡すことで、低ビット量子化での品質劣化を抑えられる。特に IQ2_XXS など 3bit を割り込む領域では imatrix の有無で出力品質が大きく変わると一般に解説されている。

```bash # importance matrix を生成して IQ3_M を作る最小手順(公開ドキュメント準拠) ./llama-imatrix \ -m ./models/qwen3-32b-f16.gguf \ -f ./calib/calibration_ja_en_code.txt \ -o ./qwen3-32b.imatrix

./llama-quantize \ --imatrix ./qwen3-32b.imatrix \ ./models/qwen3-32b-f16.gguf \ ./models/qwen3-32b-IQ3_M.gguf IQ3_M ```

キャリブレーションデータの選定は重要で、日本語業務利用なら日本語コーパス(社内議事録の匿名化サンプルや wikipedia ja の抜粋)に英語コードを混ぜたものを使うと、特定言語への偏りを回避しやすい。

CUDA Graphs と速度の話

NVIDIA Technical Blog によれば、llama.cpp は CUDA Graphs を統合済みで、GPU 側の起動オーバーヘッドを削減する。同ブログでは Llama 7B の H100 上で最大 1.2x 程度の高速化が言及されており、サンプリングや GGML グラフ準備の CPU 側オーバヘッド削減もさらなる改善余地として記述されている。投機的デコーディングも n-gram やドラフトモデル、自己投機など複数戦略がサポートされている(公開ドキュメント記載)。RTX 4090 級のコンシューマ環境でも速度差は体感できるレベルだ。

モデル規模別の推奨マトリクス(実務的指針)

中小企業の業務 PC・小規模サーバを想定した場合、次の指針が現実的だ(公開情報ベースの一般論)。

  • 7B-8B クラス(社内チャット): Q5_K_M または Q4_K_M、imatrix なしでも十分
  • 14B-32B クラス(コード補助・議事要約): Q4_K_M を基本、VRAM 厳しい場合は IQ4_XS + imatrix
  • 70B クラス(業務支援エージェント): Q4_K_M はおおむね 40GB 級、24GB 1枚なら IQ3_M + imatrix を検討
  • 100B+ MoE: 共有 RAM 大きいワークステーションなら IQ2 系 + imatrix で動く可能性あり

運用観点:再量子化の自動化

モデル更新は四半期に一度起きると考え、imatrix 生成と quantize は CI/CD パイプライン化したい。KGA IT では、社内 GitLab CI で「キャリブレーション・データセット → imatrix → 複数量子化バリアント → 評価セットでの perplexity と日本語 MT-Bench → モデル登録」までを自動化するテンプレートを案件ベースで提供している(公開情報ベースの一般的構成)。

技術的な課題を一緒に解決しませんか?

KGA IT Solutionsは、AI・クラウド・DevOpsの専門チームがお客様の課題に最適なソリューションを提供します。

お問い合わせ