Ollama モデル量子化実践：GGUF フォーマットと精度損失の完全解説

RTX 3060、VRAM 12GB で Llama 3 70B を動かしたい？ CUDA out of memory——14B すら動きません。量子化は 70B モデルを 140GB から 40GB に圧縮しますが、精度損失はどれほどなのでしょうか。

Red Hat の 50 万件の評価がその答えを示しています。8-bit 量子化は精度 >99% を回復し、4-bit 量子化は 98.9% を回復します。日常利用ではほとんど差を感じず、極端な学術ベンチマークでようやく微細な差が測れる程度です。

この記事では、GGUF 量子化の仕組み、量子化レベルごとの精度比較、コンシューマー向け GPU の選定指針を詳しく解説します。VRAM 不足に悩んでいる方や、量子化後のモデル品質に不安がある方に、必要な答えをお届けします。

一、量子化とは：大規模モデルを「スリム化」する技術

まず身近な話を。高画質の写真は十数 MB ありますが、メッセージアプリで送ると数百 KB に圧縮されますよね。画質に損失はあるか？ あります。でもちゃんと見えるか？ 見えます。

モデルの量子化も、だいたい同じ理屈です。

1.1 量子化の本質

大規模モデルの重みパラメータは、保存時に FP16（16 ビット浮動小数点）を使います。7B パラメータのモデルなら、FP16 形式で約 14GB のメモリが必要です。パラメータ 1 つあたり 2 バイトを占めるからです。

量子化がやることはシンプルです。これらの高精度な数値を、低精度フォーマットに変換します。たとえば INT4（4 ビット整数）なら、パラメータ 1 つあたり 0.5 バイトだけ。こうして 14GB のモデルが 3.5GB 程度に圧縮できます。

たとえるなら、FP16 は「非常に正確な小数」で各パラメータを記録するようなものです。たとえば 0.12345678。量子化後の INT4 は「おおよその整数」だけを記録します。たとえば 3。精度は失われますが、情報は残ります。

1.2 圧縮効果はどれほど顕著か？

あるデータをまとめました（出典：Will It Run AI の実測）。7B モデルが異なる量子化レベルでどれだけメモリを消費するか見てみましょう：

量子化レベル	VRAM 要件	メモリ削減	品質評価
F16（オリジナル）	14.0 GB	基準	最良
Q8_0	7.4 GB	47%	Excellent
Q5_K_M	4.8 GB	65%	Good
Q4_K_M	3.9 GB	72%	Acceptable
Q3_K_M	3.1 GB	78%	Poor
Q2_K	2.6 GB	81%	Very Poor

ご覧の通り、Q4_K_M はメモリ消費を 72% 削減できます。これは何を意味するか。本来 14GB の VRAM が必要だったモデルが、4GB の VRAM を持つ GPU でも動くということです。

RTX 3060 で初めて 7B モデルを動かせたとき、その感覚は——古いポンコツ車にターボを積んだような気分でした。以前は 3B の小型モデルしか動かせなかったのが、7B の中型モデルを動かせるようになったのです。

1.3 量子化の代償は何か？

圧縮には代償があります。これは写真の圧縮でも同様に顕著です。過度に圧縮された写真はぼやけたり、ノイズが出たりします。モデルの量子化も同じです：

• 精度損失：低精度の数値は元の値を正確に表現できず、誤差が入ります
• 連続性の喪失：INT4 は離散的な整数で、FP16 は連続的な小数なので、一部の微細な変化が失われることがあります

しかし核心的な問いはこうです。この損失はどれほど大きいのか。それに見合う価値はあるのか。

これこそが後で重点的に論じる内容です——50 万件の評価データを使って答えをお伝えします。慌てて心配せず、このまま読み進めてください。

二、GGUF フォーマット：なぜ量子化モデルの定番なのか

量子化モデルをダウンロードするとき、ファイルの拡張子がすべて .gguf になっていることに気づいたかもしれません。このフォーマットには何か特別な点があるのでしょうか。

2.1 GGUF とは？

GGUF の正式名称は GPT-Generated Unified Format です。名前はやや回りくどいですが、要するに推論のために専用設計されたモデルのパッケージフォーマットです。

llama.cpp チームが作り出したものです。彼らの発想は実務的でした。学習済みのモデルを動かすには、扱いやすいフォーマットが必要だ、と。そうして生まれたのが GGUF です。

このフォーマットの核心的な利点は 3 つあります。

単一ファイルへのパッケージング。以前はモデルをダウンロードするとき、Hugging Face から複数のファイルを取得する必要がありました——重みファイル、tokenizer、config.json……。GGUF はすべてを 1 つのファイルにまとめます。.gguf ファイルを 1 つダウンロードすれば十分で、何が足りないか気にする必要はありません。

メモリマップによる読み込み（mmap）。この技術は高度に聞こえますが、原理はシンプルです。ファイルをメモリアドレスに直接マッピングし、システムが必要に応じて読み込みます。利点は何か。モデル全体を先にメモリへ読み込まず、使う部分だけを読み込めることです。大規模モデルにとって、この特性はとても重要です——70B モデルを全部読み込むと数十秒かかりますが、mmap なら数秒で推論を開始できる可能性があります。

クロスプラットフォーム対応。同じ GGUF ファイルが、Ollama、LM Studio、llama.cpp、KoboldCPP など複数のツールで動きます。乗り換えてもモデルを再ダウンロードする必要がなく、手間が省けます。

2.2 GGUF と他フォーマットの比較

モデルのフォーマットはいくつかあり、混同しやすいものです。簡単な比較を描いてみます：

フォーマット	用途	特徴	ツール対応
GGUF	推論	単一ファイル、量子化向き	Ollama、LM Studio、llama.cpp
Safetensors	学習／ファインチューニング	安全、pickle のリスクなし	PyTorch、Hugging Face
GGML	推論（旧）	廃止済み	llama.cpp（旧バージョン）
PyTorch (.pt/.bin)	学習	柔軟だが安全でない	PyTorch

簡単に言うと、GGML は GGUF の前身で、すでに廃止されています。Safetensors は学習用のフォーマットで、推論時には変換が必要です。GGUF は推論専用に最適化されたフォーマットで、Ollama はデフォルトでこれを使います。

モデルを動かして推論するだけなら、どれを選ぶか悩む必要はありません——GGUF が正解です。

2.3 Ollama と GGUF の関係

Ollama はバックグラウンドで llama.cpp を使ってモデルを実行します。llama.cpp は GGUF フォーマットしか認識しません。したがって Ollama のすべてのモデルは、本質的に GGUF フォーマットです。

ollama pull llama3 を実行すると、Ollama は実際にはモデルリポジトリから GGUF ファイルをダウンロードしています。公式モデルライブラリのモデルは、あらかじめ量子化済みです——デフォルトは Q4_K_M です。

後ほど Hugging Face から他の量子化レベルのモデルを取得する方法を説明します。まずフォーマットのことを理解しておけば、後の操作もより深く理解できます。

三、量子化レベル詳解：Q2 から Q8 まで、どれが自分に合うか

この部分が重要です。量子化レベルはどう選ぶのか。Q4_K_M か、それとも Q5_K_M か。S、M、L サフィックスにはどんな違いがあるのか。一つずつ整理します。

3.1 量子化レベル比較表

まずこの表を見てください（データ出典：Will It Run AI、Llama 3 8B モデルの実測）：

量子化レベル	VRAM 要件	品質評価	適した用途
Q8_0	約 8.5 GB	Excellent	VRAM に余裕があり、最高品質を求める
Q6_K	約 6.1 GB	Very Good	バランス重視、品質はオリジナルに近い
Q5_K_M	約 5.3 GB	Good	スイートスポット、最優先のおすすめ
Q5_K_S	約 5.0 GB	Good	Q5_K_M よりやや積極的、メモリ節約
Q4_K_M	約 4.4 GB	Acceptable	主流の選択、コスパが高い
Q4_K_S	約 4.1 GB	Acceptable	より積極的、品質はやや低下
Q3_K_M	約 3.5 GB	Poor	最後の手段、明確な品質損失
Q3_K_S	約 3.2 GB	Poor	VRAM が本当に足りない場合を除き非推奨
Q2_K	約 2.7 GB	Very Poor	基本的に非推奨、品質損失が明確

太字の 2 つのレベルが、私が重点的におすすめするものです。Q5_K_M と Q4_K_M です。理由は後で説明します。

3.2 K-quant とは？ S/M/L サフィックスはどう選ぶ？

量子化レベルに K という文字が含まれていることに気づいたかもしれません。K は k-quant を表し、混合精度の量子化戦略の一種です。

原理はやや複雑に聞こえますが、核心的な考え方はシンプルです。すべてのパラメータを同じ精度で量子化するわけではありません。精度に敏感な層（たとえば attention 層）にはやや高い精度を、敏感でない層（たとえば FFN 層）には低い精度で圧縮を施します。

サフィックスの S、M、L は 3 つの異なる積極性の度合いを表します：

• S（Small）：最も積極的で、圧縮が最大、品質損失も最大
• M（Medium）：バランス型で、おすすめ
• L（Large）：保守的で、品質は最良だがファイルは大きい

つまり Q5_K_M と Q5_K_S はどちらも Q5 レベルですが、Q5_K_M のほうが品質が高くファイルが大きいということです。

どう選ぶか。私のおすすめは：

ほとんどの場合は M サフィックスを使う。S は積極的すぎて問題が起きやすく、L は保守的すぎてメモリを無駄にします。M はバランスの取れた点で、品質も十分、メモリもさほど食いません。

3.3 タスクごとの量子化への敏感度

もう一つ考慮すべき要素があります。モデルで何のタスクをするのか、です。

タスクによってモデル精度への敏感度は異なります。Will It Run AI が順位付けをしています（最も敏感なものから最も敏感でないものへ）：

1. Coding（コーディング）：最も敏感。コードを書くには論理の厳密さが求められ、パラメータ 1 つのエラーがコード全体を動かなくする可能性があります。Q5_K_M 以上を推奨します。
2. Reasoning/Math（推論／数学）：とても敏感。論理推論や数学計算は精度要求が高いです。Q5_K_M 以上を推奨します。
3. Creative writing（創作）：中程度の敏感さ。創作には一定の許容幅があり、Q4_K_M でも許容できます。
4. Chat（チャット対話）：最も敏感でない。日常会話は精度要求が最も低く、Q4_K_M で全く問題ありません。
5. Summarization（要約）：最も敏感でない。要約タスクは主に理解力が中心で、精度に敏感でないため、Q4_K_M が使えます。

簡単に言うと、コードを書く・数学的推論をするなら高精度（Q5+）を、チャット・要約なら低精度（Q4）でも問題ありません。

私自身の経験では、Q4_K_M のモデルでコードを書くと、たまに妙なエラーが出ます——たとえば関数名のスペルミスや、論理の混乱など。Q5_K_M に切り替えると、こうした問題が明確に減りました。ただしチャットなら、Q4 と Q5 で大きな違いは感じません。

四、精度損失の真相：50 万件超の評価データが答える

この部分では硬派なデータを出します。多くの人は量子化でモデルが「バカ」になることを心配しますし、私も以前はその懸念がありました。しかし Red Hat の評価レポートを見て、その懸念はほぼ解消されました。

4.1 Red Hat は何をしたのか？

Red Hat は 2024 年 10 月に「We ran over half a million evaluations on quantized LLMs」というレポートを発表しました。50 万件を超える評価を使い、量子化モデルとオリジナルモデルのパフォーマンスを比較しました。

"We ran over half a million evaluations on quantized LLMs to determine the impact of quantization on model quality across multiple benchmarks and real-world tasks."

これはいくつかのテストを適当に走らせて結論を出したのではなく、体系的な大規模評価です。複数の評価フレームワークを使いました：

• 学術ベンチマーク：OpenLLM Leaderboard v1/v2（MMLU、HellaSwag、ARC など）
• 実タスク：Arena-Hard（実際のユーザー対話を模擬）、HumanEval（コード生成）、HumanEval+（コードテスト）
• テキスト類似度：ROUGE、BERTScore、STS（意味的類似度）

テストしたモデルは小型から大型まで網羅しています。Llama 2 7B、13B、70B、Mixtral 8x7B MoE、Qwen シリーズ……。

4.2 核心的な発見：精度回復率

結論は非常に明快です。この数字を見てください（llama.cpp の量子化手法に対するもの）：

量子化レベル	平均精度回復	評価の信頼度
8-bit	>99%	95% CI が BF16 と重なる
4-bit	98.9%	基準をわずかに下回るが差は非常に小さい
3-bit	約 96%	明確に低下するが、なお実用性はある

核心的な結論は、8-bit 量子化はほぼ無損失で、4-bit 量子化は平均で 98.9% の精度を回復するということです。

「95% CI が BF16 と重なる」とはどういう意味か。つまり、統計的な意味で、8-bit 量子化モデルのパフォーマンスはオリジナルの BF16 モデルと有意な差がないということです。何度もテストを走らせても、結果の分布はほぼ同じになります。

4.3 大型モデル vs 小型モデル：量子化の影響は異なる

レポートには興味深い発見があります。モデルが大きいほど、量子化が精度に与える影響は小さくなる、というものです。

70B パラメータの大型モデルは、4-bit 量子化後のパフォーマンスがオリジナルとほぼ同等です。しかし 7B モデルでは、4-bit 量子化で体感できる低下があります。

理由はシンプルです。大型モデルはパラメータが多く、冗長性が高いのです。一部の精度を圧縮しても、その損失を「補う」だけの十分なパラメータがあります。小型モデルはもともとパラメータが少なく、圧縮後に問題が起きやすくなります。

ここから得られる示唆は：

• 大型モデルを動かすなら Q4 で問題なし：70B の Q4_K_M はオリジナルとの差が非常に小さい
• 小型モデルを動かすなら Q5+ を推奨：7B モデルは VRAM に余裕があれば Q5_K_M か Q6_K を選ぶほうが安定

4.4 コミュニティの誤解：なぜ多くの人は量子化で「バカ」になると言うのか？

ネット上では量子化後にモデル品質が明確に低下すると言う人が少なくありません。Red Hat のレポートはこの現象を分析しており、結論は、問題は量子化そのものではなく、評価方法にあるというものです。

多くの人が単一の学術ベンチマーク（たとえば MMLU）でテストし、「量子化後に MMLU のスコアが 5% 下がった、モデルがバカになった」と言います。しかし単一のベンチマークは実際の利用シーンを代表しません。

Red Hat は複数の評価フレームワーク、実タスク（Arena-Hard、HumanEval）を含めて使いました。これらの実タスクでは、量子化モデルのパフォーマンスはオリジナルとほぼ同等でした。

言い換えれば、日常利用（チャット、コーディング、要約）では、量子化による品質損失はほとんど感じません。一部の極端な学術ベンチマークでようやく差が測れる程度です。

私個人のテストの感覚も同様です。Q4_K_M のモデルはチャットも要約も滑らかで、たまにコードを書くと少し問題が出ます。ただし「バカ」になるような問題ではなく、より細かい論理エラーです。Q5_K_M に切り替えるとずっと良くなりました。

五、Ollama 実践：量子化モデルの選び方と動かし方

理論は終わりました。ここからは実践です。Ollama で異なる量子化レベルのモデルをどう選ぶのか。

5.1 Ollama のデフォルト動作

ollama pull や ollama run で公式モデルを直接取得すると、デフォルトは Q4_K_M 量子化です。

たとえば：

ollama pull llama3

このコマンドでダウンロードされるのは Llama 3 8B の Q4_K_M バージョンです。Ollama 公式は Q4_K_M がコストパフォーマンスの最も高い選択だと考えています——メモリ消費が妥当で、品質も許容できるからです。

デフォルトの Q4_K_M に満足できず、他の量子化レベルに変えたい場合はどうするか。

5.2 Hugging Face から指定の量子化モデルを取得する

Ollama は Hugging Face から GGUF フォーマットのモデルを直接取得できます。構文は：

ollama run hf.co/{ユーザー名}/{リポジトリ}:{量子化レベル}

例として、Q8_0 バージョンの Llama 3.2 3B を取得したい場合：

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0

このコマンドは bartowski の Hugging Face リポジトリから Q8_0 量子化バージョンをダウンロードします。bartowski は Hugging Face 上でとても活発な量子化モデルの公開者で、彼のリポジトリにはさまざまなモデルとさまざまな量子化レベルがあります。

Hugging Face で GGUF モデルを探すときのキーワードは GGUF です。たとえば Llama-3 GGUF で検索すると、多くの量子化バージョンが見つかります。

よく使う量子化モデルのリポジトリ：

• bartowski：更新が速く、モデルが多い
• MaziyarPanahi：大型モデルが多い（70B+）
• TheBloke：老舗の量子化公開者（一部のモデルは更新停止）

5.3 ハードウェア構成のおすすめ

VRAM の大きさが量子化レベルを決める核心的な要素です。VRAM 容量ごとに参考を示します（NVIDIA GPU 向け）：

VRAM 容量	推奨モデル	推奨量子化	備考
4 GB	3B モデル	Q4_K_M	小型モデルの低量子化、ぎりぎり足りる
6 GB	7B モデル	Q4_K_M（厳しい）	3B なら Q5_K_M がより安定
8 GB	7B モデル	Q5_K_M	8B は Q4_K_M で余裕を残す
12 GB	7B モデル	Q6_K / Q8_0	14B は Q5_K_M
16 GB	14B モデル	Q6_K	7B は Q8_0、30B MoE は Q4_K_M
24 GB	30B+ モデル	Q5_K_M	70B は Q4_K_M（量子化が必要）

いくつかの注意点：

• VRAM は上下に変動する：推論時はモデル本体だけでなく、KV cache やコンテキスト buffer もあります。10〜20% の余裕を残すと安定します。
• コンテキスト長がメモリに影響する：長いコンテキストはより多くの KV cache を必要とします。長いコンテキストをよく使うなら、VRAM 予算は大きめに見積もりましょう。
• MoE モデルは特殊：Mixtral 8x7B のような MoE モデルは、パラメータ総量が 47B でも、推論ごとに一部のパラメータしか使わないため、同等パラメータの密なモデルよりメモリ消費が小さくなります。

5.4 核心原則：小型モデルの高量子化は大型モデルの低量子化に勝る

この原則は重要です。例を挙げます。

VRAM が 8GB あるとします。動かせる構成には：

• 7B モデルの Q5_K_M（約 5.3 GB）
• 13B モデルの Q2_K（約 5.0 GB）

どちらがパフォーマンスが高いか。

答えは 7B Q5_K_M > 13B Q2_K です。

理由：13B Q2_K は量子化が積極的すぎて、精度損失が明確です。パラメータは多くても、品質はすでに圧縮で「台無し」になっています。7B Q5_K_M はパラメータが少なくても、精度がよく保たれているため、総合的なパフォーマンスはむしろ上回ります。

そこで私のおすすめは、まず量子化レベルを確保し、その後でモデルサイズを検討することです。Q5 が動かせるなら Q3 まで落とさない、7B Q5 が動かせるなら 13B Q2 を試さない、ということです。

5.5 実測：私の RTX 3060 構成

私自身の GPU は RTX 3060 12GB です。よく使う構成：

• 日常チャット：Llama 3.2 3B Q8_0（メモリに余裕があり、品質重視）
• コーディング：Llama 3 8B Q5_K_M（品質優先）
• 大型モデルのテスト：Mixtral 8x7B Q4_K_M（MoE アーキテクチャ、12GB でちょうど足りる）

この構成は実測でなかなか快適です。Q8_0 の 3B モデルはチャットの滑らかさが Q4_K_M の 8B より少し良いです（小型モデルの高量子化の優位性かもしれません）。コーディングは Q5_K_M を使うと、エラー率が Q4 より明確に低くなります。

結論

ここまで色々と述べてきましたが、核心的な要点をまとめます。

量子化の本質は、大規模モデルをコンシューマー向けハードウェアで動かせるようにすることです。70B モデルは本来 140GB の VRAM が必要ですが、量子化後は 40GB 程度に圧縮できます——これが普通のユーザーでも大規模モデルを使えるようにする核心技術です。

精度損失への不安は置いて大丈夫です。Red Hat の 50 万件の評価が教えてくれるのは、8-bit はほぼ無損失（精度回復 >99%）、4-bit は損失が抑えられる（98.9%）ということです。日常の利用シーンでは、ほとんど差を感じません。

量子化レベルを選ぶ際の核心原則：

• VRAM 予算内では高量子化を優先：Q5 が動かせるなら Q3 まで落とさない
• タスクの敏感度に応じて調整：コードを書くなら Q5+、チャットなら Q4 でも可
• 大型モデルはより低い量子化でも可：70B の Q4 は 7B の Q4 よりずっと安定

私のおすすめは、まず Q5_K_M を試すことです。これはスイートスポットです——メモリは Q4 より約 20% 多いだけで、品質は明確に良くなります。量子化の効果を体験してから、自分の実際のニーズに応じて調整しましょう。

さらに深く学びたい方は、このシリーズの他の記事もどうぞ：Ollama 入門ガイドと Modelfile パラメータ詳解。Modelfile でも量子化レベルをカスタマイズでき、この記事の知識と組み合わせれば、より柔軟にモデルを構成できます。

量子化は黒魔術などではなく、バランスの技術です——メモリと品質のあいだで最適解を見つけるのです。この技術を習得すれば、あなたの GPU でより大きなモデルを動かし、より多くのことができるようになります。