著者 Matt Connor
Ollamaの量子化はQ4・Q8・fp16のどれが最適？
Ollamaのq4_K_M、q8_0、fp16を比較します。各形式に必要なRAMを計算し、4ビット化で品質が実際にどの程度低下するかを解説します。
Ollama の量子化で変わること
Ollama の量子化では、モデルの各重みを、学習時のファイルより少ないビット数で保存します。q4_K_M で終わるタグは重みあたり約 4 ビットを保持するのに対し、fp16 では 16 ビットを保持します。そのため、ダウンロードするファイルはおよそ 3 分の 1 のサイズになり、マシンが各トークンを生成するために読み込むバイト数もおよそ 3 分の 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 付近に収まるブロックには、細かいスケールが適用されます。大きな外れ値を 1 つ含むブロックには、粗いスケールが適用されます。ブロックごとのスケールによって、4 ビットファイルでも実用的な精度を維持できます。同時に、この仕組みにより、4 ビットファイルが重み 1 つあたり厳密に 4 ビットになることはありません。
末尾の文字は混合方式を示します。 S、M、L によって、対象のビット幅を超える精度で格納するテンソルの数が決まります。q4_K_M では、丸めによる影響が大きいテンソルをより高いビット幅で格納し、残りの大部分は 4 ビットにします。そのため、ほぼ同じファイルサイズで、古い q4_0 より q4_K_M のほうが高品質な出力になります。
入力した名前から推測するのではなく、Ollama にディスク上の内容を確認させます。
ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_Mollama show は architecture、parameters、quantization、context length、embedding length を表示します。数か月前に取得し、どのモデルを選んだか覚えていない場合、quantization の行がモデルの実際の状態を示します。
重みあたりのビット数からファイルサイズが決まる
サイズの見積もりは、ファイル全体で平均した、フォーマットが重みあたりに使用するビット数から始まります。llama.cpp は quantize のドキュメントで Llama 3.1 8B の実測値を公開しており、同様の構造を持つ密なモデルにも適用できます。
このグラフのデータ
[
{
"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 は重みあたり 4 ビットではありません。ブロックのスケールと高精度で格納されるテンソルにも実際の容量が必要なため、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 ファイルサイズです。読み込み後に重みが占めるメモリ量も、ほぼこの値です。Ollama は読み込み時に展開しません。量子化された重みは同じパック形式のままメモリ上に置かれ、各ブロックは使用時に変換されます。
各モデルサイズで Ollama が実際に提供するもの
ほとんどのファミリーでは、ライブラリに q4_K_M、q8_0、fp16 のタグがあります。一部の新しいファミリーはこのパターンに当てはまらず、どのサイズでも pull できない cloud only タグとしてライブラリに表示されます。これは、VPS で GLM 5.2 を実行しようとしたときに突き当たる制限です。以下は、2026年10月時点でモデルページのタグ一覧から確認した Qwen3 のサイズです。以下の数値はすべて、RAM に読み込まれる前のディスク使用量です。2つまたは3つを合わせるだけで小規模な VPS の root ボリュームを使い切るため、タグを集め始める前に Ollama がダウンロードしたモデルを保存する場所を把握しておく価値があります。
このグラフのデータ
[
{
"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 は、ライブラリが妥協して提供している形式ではありません。upstream が選択したデフォルトであるため、自分でテストしていないモデルでは、まずこれに合わせるのが合理的です。同じ考え方が、VPS で Qwen 3 を実行する方法でのタグ選択にも当てはまります。
この比率はすべての行でほぼ同じです。q4_K_M から q8_0 に移行すると、容量は正確に2倍ではなく約70%増加します。embedding tensor と output tensor は、それ以外のテンソルと同じ比率では増加しないためです。fp16 は q4_K_M のおよそ3倍です。q4_K_M の32Bモデルでは、重みだけで 20 GB になります。これは、コンテキストウィンドウを少しでも確保すると、16 GB のマシンにはすでに収まりません。どのマシンでどのモデルを動かせるかを詳しく確認するには、セルフホストできるモデルを参照してください。
KV キャッシュが第2の、コンテキスト依存のコストになる理由
重みは固定コストです。KV キャッシュ（key と value のキャッシュ）は変動コストです。コンテキストウィンドウ内の各トークンは、すべてのレイヤーについて key ベクトルと value ベクトルを保持するため、許可するウィンドウの大きさに比例してキャッシュが増加します。モデルのロード時にウィンドウ全体の容量が確保され、会話が埋まるにつれて段階的に確保されるわけではありません。そのため、1 語だけのプロンプトでも、長いウィンドウを指定するとメモリを消費します。
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これらのモデルの数値は、モデル自身の設定に基づいています。36 layers、8 key/value heads、head dimension 128 です。ollama show にはアーキテクチャとパラメータ数が記載されており、Hugging Face のモデルの config.json には残りの情報があります。1 トークンあたりのコストにウィンドウサイズを掛けると、キャッシュは無視できない容量になります。
このグラフのデータ
[
{
"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 が VRAM 24 GiB 未満の場合（CPU のみの VPS を含む）に選択するデフォルトの 4096 トークンでは、キャッシュによって重みに加えて 0.6 GB が必要になります。ウィンドウを 32k に増やすと、キャッシュだけで 4.83 GB に達します。これは量子化された重みとほぼ同じメモリ容量であり、モデル全体に必要な最小容量は 10 GB になります。ここでいう最小容量には、計算用バッファーとオペレーティングシステムの使用分が含まれないため、「下限」としています。モデルのロード後に SIZE の列を ollama ps で確認し、実際の値を読み取ってください。VRAM が 24 GiB から 48 GiB の GPU ではデフォルトのウィンドウは 32k、48 GiB 以上では 256k です。そのため、大容量のカードで 4k の値を前提にしないでください。
Ollama をサービスとして実行する場合、ウィンドウはリクエストごとではなくサーバー上で設定します。
OLLAMA_CONTEXT_LENGTH=8192 ollama servesystemd でインストールしている場合は、代わりに drop-in に設定します。
sudo systemctl edit ollama[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"sudo systemctl restart ollama で再起動し、ollama ps の CONTEXT 列を確認して、実行中のモデルが実際にロードされたウィンドウを確認します。OLLAMA_KV_CACHE_TYPE はキャッシュ自体を量子化します。f16 がデフォルトで、q8_0 は f16 の約半分のメモリを使用し、q4_0 は約4分の1を使用します。これはグローバルオプションであるため、そのサーバー上のすべてのモデルに適用されます。キャッシュの量子化は Flash Attention が有効な場合にのみ適用されます。Ollama は、バックエンドが対応している場合に Flash Attention を自動的に有効にします。OLLAMA_FLASH_ATTENTION=1 を指定すると強制的に有効化できます。小容量のマシンで長いウィンドウを使用する場合、キャッシュを半分にすると、他の単一の変更よりも多くのメモリを解放できます。ウィンドウ自体の詳細については、num_ctx の設定とそのコスト を参照してください。キャッシュはサーバー単位ではなく、同時実行するリクエストスロットごとに1回分の容量が確保されます。そのため、Ollama が一度に2つのプロンプトへ応答する設定にすると、ここで見積もった容量は2倍になります。これは、並列スロット数とキュー制限の選び方 で説明する計算の根拠です。
8、16、32 GB VPS に収まる構成
予算には、KV cache と、OS およびその他の実行中の処理に必要な余裕を加えて考えます。小規模な VPS では、2 GB の余裕があれば十分です。
8 GB。 q4_K_M の 4B モデルは 2.6 GB で、長いコンテキストウィンドウ用の余裕も残ります。q4_K_M の 8B モデルは、デフォルトの 4k ウィンドウなら収まりますが、余裕はほとんどありません。ここでは 32k ウィンドウの 8B を計画しないでください。10 GB という下限をすでに超えているためです。
16 GB。 q4_K_M の 8B なら、16k または 32k ウィンドウでも余裕があります。q4_K_M の 14B は重みだけで 9.3 GB あり、控えめなウィンドウ設定なら収まります。q8_0 の 8B は 8.9 GB なので、こちらも収まります。この2つを自分のプロンプトで比較することが、このテーマに費やせる最も有益な1時間です。
32 GB。 q8_0 の 14B（16 GB）と q4_K_M の 32B（20 GB）は、どちらもロードできます。大きなウィンドウで 32B を実行すると上限に近づくため、推測で判断せず ollama ps を確認してください。
量子化で最初に劣化するもの
量子化誤差は、モデルの処理全体に均等に広がるわけではありません。流暢さは最後まで維持されます。だからこそ、劣化を見逃しやすくなります。量子化が不適切なモデルでも、きれいな文章は生成できます。最初に失われるのは精度です。バージョン番号、API シグネチャ、日付を正確に想起する能力です。長い推論も影響を受けます。2 段階目の小さな誤りが、8 段階目には誤答になるためです。厳密な出力形式も影響を受けます。括弧が 1 つ間違うだけで、ツール呼び出しに失敗します。
最後の点が実用的なテストになります。モデルがコードで解析する JSON を返す必要がある場合、量子化による劣化は、単に文章が少し悪くなるのではなく、解析エラーとして現れます。そのため、同じ日に問題を確認できます。コーディングエージェントは、このテストとして最も厳しいものです。ツール呼び出しを次々に実行させるためです。そのため、エージェントから Ollama サーバーを利用すると、過度に積極的な量子化が午後のうちに明らかになります。
4 ビット未満では、損失が急激に大きくなります。q3 と 2 ビットのタイプは、大規模モデルを小さなハードウェアに収めるためのものです。モデルをまったく実行できない場合の代替手段としては、現実的な選択肢です。ただし、標準設定としては適していません。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 回読み取る必要があるためです。そのため、購入したコア数とは無関係の上限が生じます。
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 fp1650 GB/s は、デュアルチャネル DDR4-3200 ホストの理論値におおむね相当します。VPS では、同じマシン上の他のすべてのテナントとそのバスを共有するため、実際に使える帯域幅はさらに小さくなります。したがって、これらの数値は誰も到達しない上限として扱ってください。重要なのは傾向です。CPU では、重みあたりのビット数を半分にすると、トークン生成速度はおおむね 2 倍になります。GPU のないマシンでは、量子化が利用できる最大の速度向上手段です。残る速度を許容できるかどうかはモデルによって異なります。VPS 上の Nemotron 3.5 Lightning では、特定のビルドとタグを使い、RAM 容量も含めて、この計算を具体的に確認しています。待ち時間のもう 1 つの要因は、モデルがどれだけ出力するかです。毎秒 10 トークンの場合、600 トークンの回答には 1 分かかります。そのため、num_predict で応答を上限設定するほうが、精度をさらに下げるよりも待ち時間を短縮できることがよくあります。
プロンプトの処理は異なります。長いプロンプトの読み込みは、メモリ帯域幅よりも演算性能に制限されます。そのため、追加のコアはプロンプト処理には有効ですが、生成速度にはほとんど影響しません。4k のプロンプトをすばやく読み込み、その後の生成が遅いマシンは、正常に動作しています。
計算結果をそのまま信じないでください。各量子化で同じプロンプトを使い、自分のマシンで 1 秒あたりのトークン数を測定することで、実測値を確認してください。判断には、ここに示した数値ではなく、自分の測定結果を使ってください。
モデルを自分で量子化する
これは、ファインチューニングしたモデルに対応するライブラリタグがない場合に重要です。最終的に使用する形式によって手順が異なります。Ollama は、このページで測定対象としている GGUF K-quants を生成しなくなったためです。
q4_K_M などの K-quant を使用する場合は、Ollama にファイルを読み込ませる前に量子化します。 Ollama はインポート時に GGUF モデルを量子化せず、GGUF ソースに対する --quantize を拒否します。量子化されていない GGUF を llama.cpp の llama-quantize で量子化してから、完成したファイルをインポートします。このインポート方法には、独自の注意点があります。チャットテンプレートが一致しないと、モデルが意味不明な内容を返します。この問題については、GGUF ファイルを Ollama にインポートする方法で説明しています。ollama show の quantization 行を使うと、インポートしたファイルが意図したビルドであることを確認できます。
Ollama 独自の --quantize は、safetensors のインポートでのみ機能します。 量子化されていない safetensors の重みを格納したディレクトリを Modelfile で指定します。
FROM /path/to/safetensors/directory次にビルドします。
ollama create --quantize int4 mymodelOllama v0.40.2 の時点（2026-10-11 に確認）で、--quantize は int4、int8、nvfp4、mxfp4、mxfp8 を受け付けます。また、q4 と q8（および fp4 と fp8）は、int4 と int8 の別名として扱われます。q4_K_M、q4_K_S、q8_0、q6_K、q5_K_M などの GGUF 名は、unsupported quantize type エラーで拒否されます。これらの形式は、上の表にある GGUF K-quants ではありません。そのため、このページの bits per weight とファイルサイズの数値を、これらの形式の予測値として扱わないでください。
問題が発生した場合に確認すること
GPU を想定していたのに、すべて CPU で実行される。 PROCESSOR 列を確認します。
ollama ps100% GPU、100% CPU、または 48%/52% CPU/GPU のような分割表示になります。分割表示は、重みと KV キャッシュが VRAM（ビデオ RAM、グラフィックカード上のメモリ）に収まらず、モデルの一部がシステムメモリに配置されたことを示します。その場合、すべてのトークンが遅い側の処理を待つため、速度は CPU のみの場合に近い水準まで低下します。コンテキストウィンドウを小さくする、キャッシュを量子化する、またはより小さいビルドを取得します。コア数を増やしても改善しません。
モデルのロード中にプロセスが強制終了される。 kernel とサービスのログを確認します。
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 キャッシュ、余裕容量を合計してください。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 キャッシュが VRAM に収まらなかったことを示します。そのため、Ollama はモデルの一部または全体をシステムメモリに配置しています。一般的な原因は、カードの容量を超える大きさのコンテキストウィンドウです。モデルの読み込み時に、ウィンドウ全体のキャッシュが割り当てられるためです。OLLAMA_CONTEXT_LENGTH でウィンドウを小さくし、OLLAMA_KV_CACHE_TYPE=q8_0 を設定してキャッシュを半分にするか、より小さい量子化モデルを取得してください。