ローカルLLMの量子化設定ガイド：Q4_K_Mの意味と、4bit/8bitの選び分け
結論:
- 迷ったら Q4_K_M。社内チャット・議事録要約・一般的な文書作成なら、まずここから始めて問題ありません
- コード補助が主用途なら Q5_K_M〜Q6_K、専門用語や固有名詞の正確さが効く文書なら Q6_K〜Q8_0 を検討します
- ただし用途より VRAM が先。載らない量子化を選ぶと、品質の話をする前に実用速度が出ません
- Ollama の
ollama create -qで自分で作れるのは q8_0 / q4_K_S / q4_K_M の3つだけ。Q5・Q6 が必要なら別の手順が要ります
qwen3:14b-q4_K_M
qwen3:14b-q8_0
qwen3:14b-q4_K_Sモデルの配布ページを開くと、こういう並びに出くわします。モデル名は同じで、後ろの記号だけが違うファイルが何種類も置いてある。どれを落とせばいいのかは、その画面には書いてありません。
記号を検索すれば「4bit量子化のK-quant中サイズ」といった説明までは出てきます。ただ、それを読んだあとも「では自社の環境ではどれを選ぶのか」には辿り着かないまま、ダウンロードボタンの手前で止まっている——そんな時間の使い方をしていませんか。
この記事は、量子化の仕組みを理解してもらうためではなく、選ぶための道具として書いています。記号の読み方を分解したうえで、VRAM・用途・許容できる品質低下の3点から1つに絞るところまで進みます。
そもそも「どのモデルを使うか」がまだ決まっていない場合は、Qwen3-14B vs Gemma 3 27B vs Llama 3.1 70B：社内業務LLMの実用性比較を先に読んだほうが早く着地します。
量子化とは、モデルを「粗い数字」で置き直す処理
LLM の中身は、膨大な数の重み（パラメータ）と呼ばれる数値の集まりです。元のモデルはこの数値を1つあたり16bit（F16）などの精度で持っています。
量子化は、この数値をもっと少ないビット数で表現し直して、ファイルとメモリ消費を小さくする処理です。 16bit を 4bit に落とせば、単純計算では4分の1になります。
効果は実測でも大きく出ます。Gemma 3 27B の場合、Bored Consultant の実測記事では fp16（16bit）で 63GB を計測しているのに対し、Q4_K_M では 21GB でした。3分の1以下です。24GB の GPU に載るか載らないかは、この差で決まります。
一方で、粗い数字に置き直している以上、出力は元のモデルと完全に同じにはなりません。この記事で扱う選択は、全部「どこまで粗くしてよいか」の判断です。
なお「単純計算では4分の1」と書きましたが、実際にきれいな4分の1にはなりません。理由は次の節で分解します。
GGUF という言葉が併記される理由
量子化されたモデルは GGUF という形式のファイルで配布されていることがほとんどです。GGUF は llama.cpp が定めたモデルファイルの形式で、Ollama もこの形式のファイルを取り込めます（Ollama 公式の import ドキュメントに手順があります）。
「GGUF版」「Q4_K_M」と並んで書かれていたら、前者がファイル形式、後者がその中の量子化の強さだと読んでおけば実務上は足ります。
Q4_K_M を3つに分解して読む
記号は3つのパーツでできています。ここを分けて読めるようになると、初めて見る記号でもだいたい位置がわかります。
| パーツ | 例 | 意味 |
|---|---|---|
| 数字 | 4_K_M | 何ビットに落としたか。数字が大きいほど元のモデルに近く、ファイルは大きい |
| K | Q4_K_M | K-quant。すべての重みを同じビット数に落とすのではなく、重要な部分の精度を高めに残す混合精度方式 |
| 末尾 | Q4_K_M | 同じビット数の中の大中小。S（Small）・M（Medium）・L（Large）の順に大きく、元に近くなる |
つまり Q4_K_M は「4bit・混合精度・中サイズ」 と読みます。Q5_K_M なら5bit の中サイズ、Q6_K なら6bit です。Q8_0 は8bitで、量子化されたものの中では最も元のモデルに近い側に位置します。その上には量子化しない F16 / F32 があります。
K が入る形式では、注意機構（Attention）側の重みを高めの精度で保ち、フィードフォワード側をより強く圧縮する、という配分が行われます（Hugging Face の skills リポジトリにある量子化リファレンス・2026年8月27日時点のコミット）。4bit と言いながら全部が4bit ではない——これが、ファイルサイズが理論値どおり4分の1にならない理由です。
だから「Q4_K_M で 21GB なら Q8_0 は倍の 42GB」といった暗算は当てになりません。実装方式によっても差が出ます。同じ Gemma 3 27B でも、biton.co.jp の 2026年5月版比較は int4 量子化で 14.1GB という数値を出していて、先ほどの 21GB とは 7GB 近く開きがあります。サイズは換算式で見積もらず、配布元のファイル一覧で実数を見る。 これが安全側の作法です。
覚えるべきは順序だけ
量子化形式の一覧表は、llama.cpp 公式リポジトリの Discussion #2094 が原典で、日本語ブログの多くはここの表を引き写しています。
ただし、この表に載っているファイルサイズや品質低下の数値は、現在主流のモデル世代より前の 7B モデルを基準に測られたものです。 Qwen3-14B や Gemma 3 27B の数値としてそのまま使うと外れます。この表から持ち帰るべきなのは、次の順序だけです。
Q2_K ＜ Q3_K ＜ Q4_K_S ＜ Q4_K_M ＜ Q5_K_M ＜ Q6_K ＜ Q8_0 ＜ F16 （右にいくほど元のモデルに近く、ファイルは大きい）
「軽くしたい」と「精度を落としたくない」は、両方持ったままでいい
ここから選ぶ段階に入ります。
小さいファイルのほうが確実に動くし、ダウンロードも早く終わる。でも精度が落ちて「AIの回答がおかしい」と社内で言われるのは避けたい。逆に大きいほうを選べば安心感はあるけれど、自分の環境で本当に動くかは自信が持てない——この2つの気持ちを同時に抱えたまま、決めきれずにいませんか。
この2つは、どちらかを捨てて解決するものではありません。 順番に処理すれば両方とも残ります。やることは2つです。
- 用途から下限を決める（これ以上粗くすると業務で困る、というライン）
- VRAM から上限を決める（これ以上大きいと載らない、というライン）
その重なった範囲の中で、いちばん大きいものを取る。これで終わりです。
手順1：用途から下限を決める
先ほどの Hugging Face の skills リポジトリにある量子化リファレンスは、用途ごとの推奨をこう整理しています。
| 用途 | 推奨される量子化 |
|---|---|
| 一般的なチャット・文書作成・要約 | Q4_K_M / Q5_K_M |
| コード生成・コード補助 | Q5_K_M / Q6_K |
| 技術文書・医療など、正確さが強く要求される領域 | Q6_K / Q8_0 |
| ラズパイ等の小型・エッジ機器 | Q2_K / Q3_K_S |
社内利用で多い「議事録の要約」「社内問い合わせチャット」「メール文面のドラフト」は、いちばん上の行に入ります。Q4_K_M で始めて構いません。
一方、コードレビューの補助や、型番・数値・固有名詞が大量に出てくる技術文書の処理を主用途にするなら、1〜2段階上げる価値があります。この表がコードと技術文書だけを別行に切り出しているのは、文章として自然に読めるかどうかより、記号や数値が1文字ずれずに出てくるかどうかのほうが、量子化の強さに影響を受けやすいためだと読み取れます。
いちばん下の行（Q2_K / Q3_K_S）は小型機器向けの選択肢です。社内業務用途で最初からここを選ぶ理由は、ほぼありません。
手順2：VRAM から上限を決める
用途がいくら Q6_K を要求していても、GPU に載らなければ話が終わります。容量が先、品質は後という順序は、社内LLMサーバーのGPU選定ガイドで扱った原則がそのまま当てはまります。VRAM に載らないモデルは、遅くなるのではなく実用にならない速度まで落ちます。
すでに一次ソースで確認できている数値を並べます（いずれも Q4_K_M でのモデル重み分です）。
| モデル | Q4_K_M での VRAM | 24GB GPU での余裕 |
|---|---|---|
| Qwen3-14B | 約9〜12GB | 余裕あり |
| Gemma 3 27B | 約21〜22.5GB | かなりタイト |
| Llama 3.1 70B | 約42GB | 載らない |
出典と幅の理由はモデル比較記事にまとめてあります。ここで重要なのは、この数字がまだ「重みだけ」だという点です。
実運用では KV キャッシュ（会話の文脈を保持するためのメモリ）が上乗せされます。GPU選定ガイドで整理したとおり、コンテキスト長8Kで重みの+25%、32Kで最大+100% を見込む必要があります。
つまり Gemma 3 27B の Q4_K_M（21〜22.5GB）を RTX 4090（24GB）で動かす構成は、長い議事録を投げた瞬間にメモリ不足で止まる可能性がある、ということです。この場合、量子化を上げる余地はもうありません。 24GB という上限が、Q4_K_M の位置で既に埋まっています。
上限と下限がぶつかったときの2択
用途が要求する下限より、VRAM が許す上限のほうが低い。このときの選択肢は2つです。
- モデルはそのままで、量子化を下げる — 品質を諦めて、そのモデルの持つ能力を優先する
- 1つ小さいモデルにして、量子化を上げる — モデルの規模を諦めて、出力の安定を優先する
どちらが正しいかは用途で変わります。日本語の要約なら後者が効きやすく、モデル固有の機能（画像入力など）が要件なら前者しかありません。判断材料はモデル比較記事の用途別マトリクスにあります。
そもそも GPU をこれから買う段階なら、量子化の前に容量の意思決定です。GPU選定ガイドと、月額に直したときの運用コスト試算を先に見てください。
Ollama で指定するときの3つの実務ポイント
選んだあと、実際の操作で詰まりやすいところを3つ挙げます。
① タグを省略したとき何が来るかは、モデル次第
ollama pull qwen3 のようにタグを省略すると、そのモデルの配布側が指定したものが降ってきます。「Ollama のデフォルトは Q4_K_M」と書いている記事がありますが、Ollama の公式ドキュメントに一律のデフォルトを定めた記述は見当たりません。 モデルごとのメタデータで決まります。
明示するなら、qwen3:14b-q4_K_M のようにタグまで書きます。ただしタグの命名はモデルによって違うので、実在するタグは配布ページで確認してください。
② 手元のモデルが何なのかは ollama show で確認できる
Ollama はモデルのメタデータに quantization_level という項目を持っており、Q4_K_M のような値が入っています（Ollama API リファレンス）。
「前任者が入れたモデルが何の量子化なのか分からない」という状態は、ollama show <モデル名> で解消できます。推測で話を進める必要はありません。
③ Ollama 自身が作れる量子化は3種類だけ
ここが実際に事故になるところです。
Ollama には元のモデルから量子化版を作る ollama create -q（--quantize）というコマンドがありますが、公式の import ドキュメントが対応形式として挙げているのは q8_0 / q4_K_S / q4_K_M の3つだけです。
つまり、この記事の表を見て「コード補助だから Q6_K にしよう」と決めても、ollama create -q q6_K は通りません。 llama.cpp や Hugging Face 側には8種類以上のフォーマットが存在するので、混同したまま試すと「自分のコマンドの打ち間違いなのか、環境の問題なのか」が切り分けられず、原因不明のまま時間を溶かすことになります。
Q5・Q6 が必要な場合のルートは2つです。
- すでに量子化済みの GGUF を配布元から取ってくる（最も簡単。Q5_K_M や Q6_K は多くのモデルで配布されています）
- llama.cpp の
llama-quantizeを使う — 公式リポジトリの quantize README（2026年8月30日時点のコミット）に手順があります。GGUF への変換 → 量子化、の2段階です
なお、Q2_K や Q3_K のような低いビット数に落とすときの品質低下を抑える仕組みとして、llama.cpp には --imatrix（importance matrix、重要度行列）というオプションがあります。同 README に記載がありますが、社内業務用途で Q4_K_M 以上を選ぶ限り、意識する場面はまずありません。
選び方の落とし穴
「一度決めたら変えられない」ではない
やり直しのコストは、もう一度ダウンロードする時間だけです。設定を作り込むわけでも、既存の資産が壊れるわけでもありません。
それでも最初の1回で正解を当てたくなるのは、選び直すこと自体が「最初に間違えた」という報告に見えるからかもしれません。ただ、量子化は社内の誰かに見せる前に、自分の環境で比べて決められる性質のものです。同じモデルの Q4_K_M と Q5_K_M を実際の業務文書で試して、違いが体感できなければ軽いほうを残す。それで十分に説明のつく決め方になります。
「大は小を兼ねる」が成立しない
VRAM を超えた瞬間、品質の議論は無意味になります。Q8_0 を選んで動かなかった構成より、Q4_K_M で確実に動く構成のほうが、社内評価は間違いなく高くなります。
モデルが変われば、適正も変わる
ここに書いた記号の読み方は、モデルが変わっても変わりません。しかしモデルごとのファイルサイズと VRAM 消費は、モデルが変われば全部変わります。 新しいモデルを検討するときは、その都度モデルカードで確認してください。この記事の数値も、Qwen3-14B / Gemma 3 27B / Llama 3.1 70B の 2026年6月時点で確認できたものです。
まとめ：判断の順序
上から順に答えると、1つに絞れます。
- 使える VRAM は何GBか → 動かすモデルの上限が決まる
- 主用途は何か → 一般文書なら Q4_K_M、コードなら Q5_K_M〜Q6_K、正確さ重視なら Q6_K〜Q8_0 が下限
- 上限と下限は重なるか → 重なるなら、その範囲でいちばん大きいものを取る
- 重ならないなら → 量子化を下げるか、1つ小さいモデルに替えて量子化を上げるか
- Q5・Q6 を選んだか → 量子化済み GGUF を取ってくる（Ollama 単体では作れない）
- 入れたあと →
ollama showでquantization_levelを確認して記録する
最後の「記録する」は地味ですが効きます。半年後に「なぜこの設定なのか」と聞かれたとき、VRAM がこれだけで、用途がこれだったから、この量子化を選んだと一文で答えられる状態になります。記号を暗記していることより、この一文が言えることのほうが実務では価値があります。
環境と用途を書いて送ってもらえれば、構成案を返します
量子化の記号の意味が分からないまま、他の記事の設定をそのまま真似していた——という状態は珍しくありません。ここは資料が「意味」までしか書いておらず、「選び方」まで書いていない領域だからです。
自社の VRAM 容量・使いたいモデル・主用途の3点が決まっていれば、量子化の選定はほぼ機械的に終わります。逆に、その3点のどこかが決まっていない段階で調べ続けても、答えは出てきません。
モデル選定から環境構築（Ollama / LM Studio）、RAG 連携まで、ローカルLLM の実装相談を受け付けています。VRAM 量・OS・やりたいことの概要を書いて送ってもらえれば、構成案と費用感を返します。