著者 Ollama量子化の比較：q4_K_M、q8_0、fp16の違い
Ollamaのq4_K_M、q8_0、fp16をRAM容量と品質低下で比較します。各量子化のファイルサイズ、速度、4ビットで精度がどこまで変わるかを計算で確認できます。
Ollama の量子化で変わること
Ollama の量子化では、モデルの各重みを、学習時のファイルより少ないビット数で格納します。q4_K_M で終わるタグは重みあたり約 4 ビットを保持しますが、fp16 では 16 ビットを保持します。そのため、ダウンロードするファイルはおよそ 4 分の 1 のサイズになり、マシンが各トークンの生成時に読み取るバイト数も 4 分の 1 になります。重みは粗いグリッドに丸められますが、破棄されるわけではありません。多くのモデルでは、4 ビットでも完全精度の場合とほぼ同じように応答します。
トレードオフはこれだけです。メモリ使用量が大幅に減り、1 秒あたりに生成できるトークン数が増える一方で、精度がわずかに低下します。ここからは、20 分かけてダウンロードしたファイルが収まらない事態を避けるため、特定のモデルを特定のマシンで実行した場合に、この両面を事前に予測する方法を説明します。
Ollama がまだ起動していない場合は、VPS への Ollama のインストールを参照してください。このページでは、ollama ls がすでに動作していることを前提とします。
q4_K_M のような Ollama の量子化タグの読み方
ローカルモデルは、重みをディスクに保存するために llama.cpp が使用する形式である GGUF ファイルとして配布されます。Ollama は llama.cpp を基盤としているため、Ollama のタグには llama.cpp の量子化名がそのまま使用されます。
数値は対象のビット幅を示します。 q4 は、ほとんどの重みテンソルが 1 つあたり 4 ビットで格納されることを示します。q8 は 8 ビットを示します。fp16 は量子化されていません。モデルを 16 ビット浮動小数点で格納したもので、多くのモデルが公開時に使用する精度です。
K は K-quant を示します。 重みは小さなブロックに分けられ、各ブロックには、量子化された値とともに独自のスケールが格納されます。重みがすべて 0.01 付近に収まるブロックには、細かいスケールが適用されます。大きな外れ値を含むブロックには、粗いスケールが適用されます。このブロック単位のスケールにより、4 ビットのファイルでも実用的な品質を保てます。同時に、4 ビットのファイルが重み 1 つあたり正確に 4 ビットになるわけではない理由でもあります。
末尾の文字は混合方式を示します。 S、M、L は、対象のビット幅より広く格納するテンソルの数を決めます。q4_K_M では、丸めによる影響が大きいテンソルをより広いビット幅で格納し、それ以外の大部分は 4 ビットのままにします。そのため、q4_K_M は、ほぼ同じファイルサイズで従来の q4_0 より良い出力を生成します。
入力した名前から推測せず、ディスク上の内容を Ollama に確認します。
ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_Mollama show は architecture、parameters、quantization、context length、embedding length を表示します。数か月前に取得し、どのモデルを選んだか覚えていない場合でも、quantization の行がモデルの実際の状態を示します。
ビット数/weight がファイルサイズを決めます
すべてのサイズ見積もりは、1 つの数値から始まります。ファイル全体で平均した、フォーマットが weight あたりに使用するビット数です。llama.cpp は quantize のドキュメントで Llama 3.1 8B の実測値を公開しており、同様の構成を持つ dense model にも十分適用できます。
The data behind this chart
[
{
"label": "F16",
"bits_per_weight": 16,
"file_gib": 14.96
},
{
"label": "Q8_0",
"bits_per_weight": 8.5,
"file_gib": 7.95
},
{
"label": "Q6_K",
"bits_per_weight": 6.56,
"file_gib": 6.14
},
{
"label": "Q5_K_M",
"bits_per_weight": 5.7,
"file_gib": 5.33
},
{
"label": "Q4_K_M",
"bits_per_weight": 4.89,
"file_gib": 4.58
},
{
"label": "Q3_K_M",
"bits_per_weight": 3.99,
"file_gib": 3.74
}
]この表で意外なのは 2 列目です。Q4_K_M は weight あたり 4 ビットではありません。block scale と昇格された tensor も実際に容量を使用するため、4.89 ビットです。同じ理由で、Q8_0 も 8 ビットではなく 8.5 ビットです。実測値を使用すれば、計算結果は実際のファイルサイズと数パーセント以内で一致します。
weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiBこれは、2 つの数値から算出した 4.58 GiB の Q4_K_M ファイルです。ロード後に weight が占有するメモリ量としても、ほぼ同じ値になります。Ollama はロード時に何も展開しません。quantized weight は同じ packed form のままメモリに配置され、各 block は使用時に変換されます。
Ollama が各モデルサイズ向けに実際に提供するもの
ライブラリは、ほとんどのファミリーで q4_K_M、q8_0、fp16 のタグを公開しています。以下は、2026 年 8 月時点の Qwen3 のサイズです。モデルページのタグ一覧から読み取ったものです。
The data behind this chart
[
{
"label": "Qwen3 4B",
"q4_K_M_gb": 2.6,
"q8_0_gb": 4.4,
"fp16_gb": 8.1
},
{
"label": "Qwen3 8B",
"q4_K_M_gb": 5.2,
"q8_0_gb": 8.9,
"fp16_gb": 16
},
{
"label": "Qwen3 14B",
"q4_K_M_gb": 9.3,
"q8_0_gb": 16,
"fp16_gb": 30
},
{
"label": "Qwen3 32B",
"q4_K_M_gb": 20,
"q8_0_gb": 35,
"fp16_gb": 66
}
]ここではデフォルトタグが重要です。ollama pull qwen3:8b は ollama pull qwen3:8b-q4_K_M とまったく同じ 5.2 GB をダウンロードします。接尾辞のないタグ自体が q4_K_M ビルドだからです。Q4_K_M は、ライブラリが妥協して提供している形式ではありません。上流プロジェクトが選択したデフォルトであるため、自分でテストしていないモデルでは、まずこれに合わせるのが妥当です。同じ考え方が、VPS で Qwen 3 を実行する場合のタグ選択にも当てはまります。
この比率はすべての行でほぼ同じです。q4_K_M から q8_0 に移行すると、容量はちょうど 2 倍ではなく約 70% 増加します。埋め込みテンソルと出力テンソルは、他のテンソルと同じ比率では増加しないためです。fp16 は q4_K_M の約 3 倍です。q4_K_M の 32B モデルは、重みだけで 20 GB あります。これは、コンテキストウィンドウをまったく確保しない場合でも、16 GB のマシンに収まる容量をすでに超えています。どのマシンにどのモデルが収まるかを詳しく確認するには、セルフホストできるモデルを参照してください。
KV cache が第 2 のコストになる理由と、コンテキストに依存する仕組み
Weights は固定コストです。KV cache（key と value の cache）は可変コストです。コンテキストウィンドウ内の各 token は、すべての layer について key vector と value vector を保持するため、cache は許可するウィンドウに比例して増加します。cache は会話が埋まるにつれて割り当てられるのではなく、model の読み込み時にウィンドウ全体の分が割り当てられます。そのため、1 word の prompt でも、長いウィンドウを設定すると memory を消費します。
KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16: 2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per tokenこれらの model number は、model 自身の configuration に基づいています。36 layers、8 key/value heads、head dimension 128 です。ollama show で architecture と parameter count を確認でき、Hugging Face の model にある config.json で残りの情報を確認できます。token あたりのコストに window size を掛けると、cache は無視できない容量になります。
The data behind this chart
[
{
"label": "4k",
"kv_cache_gb": 0.6,
"floor_ram_gb": 5.8
},
{
"label": "8k",
"kv_cache_gb": 1.21,
"floor_ram_gb": 6.4
},
{
"label": "16k",
"kv_cache_gb": 2.42,
"floor_ram_gb": 7.6
},
{
"label": "32k",
"kv_cache_gb": 4.83,
"floor_ram_gb": 10
}
]Ollama の default window である 4096 tokens では、cache により weights に加えて 0.6 GB が必要です。window を 32k に増やすと、cache だけで 4.83 GB に達します。これは quantized weights とほぼ同じ memory 量であり、model 全体に必要な memory の下限は 10 GB になります。ここで下限と呼ぶのは、その上に compute buffer と operating system の使用分が加わるためです。model の読み込み後に、ollama ps の SIZE column から実際の値を確認してください。
Ollama を service として実行する場合、window は request ごとではなく server で設定します。
OLLAMA_CONTEXT_LENGTH=8192 ollama servesystemd で install している場合は、代わりに drop-in に設定します。
sudo systemctl edit ollama[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"sudo systemctl restart ollama で restart し、ollama ps の CONTEXT column を確認して、実行中の model が実際に読み込まれた window を確認します。OLLAMA_KV_CACHE_TYPE は cache 自体を quantize します。f16 が default で、q8_0 は f16 の約半分の memory を使用し、q4_0 は約 4 分の 1 を使用します。これは global option であるため、その server 上のすべての model に同じ設定が適用されます。小容量の box で長い window を使用する場合、cache を半分にすると、ほかの単一の変更よりも多くの memory を解放できます。num_ctx の設定と必要なコストでは、window 自体について詳しく説明しています。
8、16、32 GB の VPS に適する構成
予算内で確保できる容量に加え、KV キャッシュ、OS やその他の実行中プロセス用の余裕も必要です。小規模な VPS では、2 GB の余裕があれば安心です。
8 GB。 q4_K_M の 4B モデルは 2.6 GB で、長いコンテキストウィンドウ用の容量も残ります。q4_K_M の 8B モデルはデフォルトの 4k ウィンドウなら収まりますが、余裕はほとんどありません。ここで 32k ウィンドウの 8B モデルを計画しないでください。10 GB の下限だけで、すでに VPS の容量を超えているためです。
16 GB。 q4_K_M の 8B モデルなら、16k または 32k ウィンドウでも余裕があります。q4_K_M の 14B モデルは重みだけで 9.3 GB あり、適度なウィンドウサイズなら収まります。q8_0 の 8B モデルは 8.9 GB なので、こちらも収まります。この2つを自分のプロンプトで比較することが、このテーマに費やす時間として最も有用です。
32 GB。 q8_0 の 14B モデル（16 GB）と q4_K_M の 32B モデル（20 GB）は、どちらもロードできます。大きなウィンドウを設定した 32B ビルドは容量の上限に近づくため、思い込みで判断せず ollama ps を監視してください。
最初に劣化する量子化の特性
量子化誤差は、モデルの処理全体に均等に広がるわけではありません。流暢さは最後まで維持されます。そのため、劣化を見逃しやすくなります。量子化が不適切なモデルでも、きれいな文章は生成できるためです。最初に失われるのは精度です。バージョン番号、API シグネチャ、日付などの正確な再現性が低下します。長い推論も劣化します。2 番目のステップで生じた小さな誤りが、8 番目のステップで誤答になるためです。厳密な出力形式も影響を受けます。括弧が 1 つ間違うだけで、ツール呼び出しが失敗することがあります。
最後の点が、実用上のテストになります。モデルが、コードで解析する JSON を返す必要がある場合、量子化による劣化は、曖昧に品質が低下した文章ではなく、解析エラーとして現れます。そのため、同じ日に確認できます。コーディングエージェントは、このテストとして最も厳しいものです。ツール呼び出しを何度も連続して実行させるためです。そのため、エージェントを Ollama サーバーに接続すると、過度な量子化があれば午後のうちに明らかになります。
4 bit 未満では、損失が急激に大きくなります。q3 と 2 bit のタイプは、大規模モデルを小さなハードウェアに収めるためのものです。モデルをまったく実行できない場合の代替手段としては、現実的な選択肢です。ただし、デフォルトには適していません。q4_K_M と q8_0 の差は十分に小さいため、公開された perplexity の表だけでは、使用するワークロードに適した方を判断できません。その方法で決めようとしないでください。自分で用意した 30 個のプロンプトに対して両方を実行し、出力を確認してください。
q8_0 または fp16 が RAM に見合う場合
メモリに十分な余裕があり、小さな誤りが大きな問題になるタスクでは q8_0 を選びます。構造化抽出、ツール呼び出し、コンパイルが必要なコードなどが該当します。ここで得られるのは、明らかに賢いモデルではなく、保険です。
fp16 を選ぶ理由は 2 つだけです。自分でモデルを量子化するため元ファイルが必要な場合、またはベースラインを測定し、4 bit ビルドでどの程度性能を失ったか確認する場合です。fp16 で提供すると q4_K_M の 3 倍のメモリを消費しますが、ほとんどの人はブラインドテストで違いを判別できません。CPU のみのマシンでは、トークン生成速度も 3 分の 1 になります。
メモリ容量を固定した場合の、より重要な原則は次のとおりです。通常、q4_K_M の大きなモデルは、q8_0 の小さなモデルを上回ります。14B の重みである 9.3 GB と、8B の重みである 8.9 GB は、RAM（random access memory）の容量がほぼ同じです。そのうえ、大きなモデルのほうが多くの知識を持ちます。この点はそのまま信じず、自分のプロンプトで検証してください。
CPU のみの推論はメモリ帯域幅によって制限されます
ほとんどの VPS プランには GPU がないため、モデルはホストの CPU 上にあるシステムメモリで実行されます。この場合、生成速度は演算性能ではなくメモリ帯域幅によって決まります。1 トークンを生成するには、すべての重みを 1 回読み込む必要があるためです。そのため、購入した CPU コア数とは無関係の上限が生じます。
tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB = 9.6 tokens/s qwen3 8B q4_K_M
50 GB/s / 8.9 GB = 5.6 tokens/s qwen3 8B q8_0
50 GB/s / 16 GB = 3.1 tokens/s qwen3 8B fp16デュアルチャネル DDR4-3200 のホストでは、50 GB/s が理論上のおおよその値です。VPS では、同じマシン上の他のテナントもこのメモリバスを共有するため、実際に利用できる帯域幅はさらに小さくなります。したがって、これらの数値は誰も到達できない上限として扱ってください。重要なのは傾向です。CPU では、重み 1 個あたりのビット数を半分にすると、トークン生成速度はおおむね 2 倍になります。GPU のないマシンでは、量子化が利用できる最大の速度向上手段です。
プロンプトの処理は異なります。長いプロンプトの読み込みは、メモリ帯域幅よりも演算性能に依存するため、追加の CPU コアが有効です。ただし、トークン生成速度にはほとんど影響しません。4k のプロンプトをすばやく取り込んだ後、ゆっくり生成するマシンは、正常に動作しています。
計算結果をそのまま信じないでください。各量子化で同じプロンプトを使い、自分のマシンで 1 秒あたりのトークン数を測定してください。判断には、ここに示した数値ではなく、実測値を使用してください。
モデルを自分で量子化する
Ollama は、fp16 または fp32 のソースから量子化モデルを作成できます。ファインチューニングしたモデルで、対応するライブラリタグが存在しない場合に役立ちます。量子化されていない重みを Modelfile で指定します。
FROM /path/to/my/model/f16次に、ビルドして確認します。
ollama create --quantize q4_K_M mymodel
ollama show mymodel--quantize は q8_0、q4_K_S、q4_K_M を受け付けます。ここには q6_K や q5_K_M のオプションはありません。そのため、それらを使う場合は llama.cpp 独自のツールで量子化し、完成した GGUF ファイルをインポートします。ollama show の quantization 行で、指定どおりにビルドされたことを確認できます。
問題が発生した場合に確認できる内容
GPU を想定していたのに、すべて CPU で実行される。 PROCESSOR 列を確認します。
ollama ps100% GPU、100% CPU、または 48%/52% CPU/GPU のような分割表示が出力されます。分割表示は、重みと KV キャッシュが VRAM（ビデオ RAM、グラフィックカード上のメモリ）に収まらず、モデルの一部がシステムメモリに配置されたことを示します。その場合、各トークンが低速な側の処理を待つため、速度は CPU のみで実行した場合に近い水準まで低下します。コンテキストウィンドウを小さくする、キャッシュを量子化する、またはより小さいビルドを取得します。CPU コアを追加しても改善しません。
モデルのロード中に強制終了される。 カーネルとサービスのログを確認します。
sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50Out of memory: Killed process を含む行は、重み、KV キャッシュ、バッファの合計がホストのメモリ容量を超えたことを示します。swap が設定されていない VPS では、その行が表示される前にマシン全体が数秒間停止することがあります。
何も変更していないのに回答の品質が低下した。 同じモデルの 2 つのビルドが、異なるタグで ollama ls 内に並存することがあります。サフィックスなしの名前を取得するスクリプトは、ライブラリが現在その名前に割り当てているビルドを使用します。クライアントが要求する正確なタグに対して ollama show を実行し、設定ファイル内の名前をそのまま信頼せずに quantization 行を確認します。
FAQ
どの Ollama 量子化モデルを取得すべきですか？
まずは q4_K_M を使用してください。これは Ollama ライブラリが多くのモデルでデフォルトタグとして提供しているものです。そのため、ollama pull qwen3:8b と ollama pull qwen3:8b-q4_K_M は同じファイルを取得します。メモリに余裕があり、ツール呼び出しや構造化 JSON 出力など、小さな誤りが結果に大きく影響するタスクの場合に限り、q8_0 に切り替えてください。メモリ容量が固定されている場合は、通常、q8_0 の小さいモデルより q4_K_M の大きいモデルのほうが優れています。精度のために RAM を追加で消費する前に、この組み合わせをテストしてください。
q4_K_M は本当に重みあたり 4 ビットという意味ですか？
いいえ。Llama 3.1 8B で測定すると、重みあたり 4.89 ビットです。各重みブロックが独自のスケール値を保持し、特に影響を受けやすいテンソルがより広い型に昇格されるためです。同じ理由で、Q8_0 は 8 ビットではなく 8.5 ビットです。容量を見積もる際は測定値を使用してください。パラメータ数に重みあたりのビット数を掛け、8 で割ると、バイト単位のファイルサイズになります。
CPU のみの VPS で 8B モデルを実行するには、どの程度の RAM が必要ですか？
重み、KV cache、余裕容量を合計してください。q4_K_M の Qwen3 8B では、重みに 5.2 GB 必要です。デフォルトの 4096 トークンのコンテキストウィンドウでは、キャッシュに 0.6 GB が追加で必要です。そのため、計算バッファーとオペレーティングシステムを考慮する前でも、最低 5.8 GB 程度必要です。32k ウィンドウでは、キャッシュだけで 4.83 GB 必要です。短いウィンドウには 8 GB、長いウィンドウには 16 GB を見込んでください。
サーバーに GPU があるのに、モデルが CPU を 100% 使用するのはなぜですか？
ollama ps を実行し、PROCESSOR 列を確認してください。100% CPU または 48%/52% CPU/GPU のような分割表示は、重みと KV cache が VRAM に収まらなかったことを示します。そのため、Ollama はモデルの一部または全部をシステムメモリに配置しています。通常の原因は、カードに収まる容量を超えるコンテキストウィンドウです。モデルの読み込み時に、ウィンドウ全体のキャッシュが割り当てられるためです。OLLAMA_CONTEXT_LENGTH でウィンドウを小さくし、OLLAMA_KV_CACHE_TYPE=q8_0 を設定してキャッシュを半分にするか、より小さい量子化モデルを取得してください。