著者 Ollamaの量子化比較：q4_K_M/q8_0/fp16の選び方
Ollamaでモデルを実行する際の量子化（q4_K_M, q8_0, fp16）の選び方を解説します。メモリ使用量と推論速度、精度のトレードオフを数値で比較し、環境に最適なモデルサイズの判断基準を具体的に紹介します。
Ollama の量子化による変更点
Ollama の量子化は、モデルの各重みを学習時よりも少ないビット数で保存する技術です。q4_K_M で終わるタグは重みあたり約 4 ビットを保持し、fp16 は 16 ビットを保持します。そのため、ダウンロードサイズは約 4 分の 1 になり、各トークンを生成するために読み込むバイト数も 4 分の 1 に削減されます。重みは破棄されるのではなく粗いグリッド上に丸められるため、4 ビットであってもほとんどのモデルはフル精度に近い回答を維持します。
これがトレードオフのすべてです。メモリ使用量が大幅に削減され、1 秒あたりのトークン生成数が増加する代わりに、わずかな精度の低下が生じます。以下では、ファイルサイズが大きすぎてメモリに収まらないといった事態を避けるため、特定のモデルを特定の環境で実行する際の予測方法を解説します。
Ollama がまだ実行されていない場合は、VPS への Ollama のインストール から始めてください。このページでは、ollama ls がすでに動作していることを前提としています。
Ollama の量子化タグ q4_K_M の読み方
ローカルモデルは GGUF ファイルとしてリリースされます。これは llama.cpp が重みをディスクに保存するための形式です。Ollama は llama.cpp を基盤としているため、Ollama のタグには llama.cpp の量子化名がそのまま使用されています。
数値はターゲットとなるビット幅です。 q4 は、ほとんどの重みテンソルが 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 行は、数ヶ月前にプルして選択したことを忘れてしまったモデルの正確な情報源となります。
重みあたりのビット数がファイルサイズを決定する
ファイルサイズの推定は、すべて1つの数値から始まります。それは、ファイル全体で平均した、重みあたり何ビットをフォーマットが消費するかという値です。llama.cppは、Llama 3.1 8Bの測定値をquantizeのドキュメントで公開しており、これらは同様の形状を持つあらゆる密なモデルに適用可能です。
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は重みあたり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 タグを公開しています。一部の新しいファミリーはこのパターンから外れており、ライブラリ上ではクラウド専用タグとして表示され、どのサイズでもプルできるデータが存在しません。これが VPSでGLM 5.2を実行しようとした際 に直面する壁です。以下は2026年8月時点でのQwen3のサイズであり、モデルページのタグリストから読み取ったものです。以下の数値はすべてディスク容量であり、RAM使用量ではありません。これらを2つか3つ合わせると小規模なVPSのルートボリュームを埋め尽くすため、タグを収集し始める前に Ollamaがダウンロードしたモデルをどこに保存するか を把握しておくことが重要です。
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倍のサイズになります。32B モデルの q4_K_M は 20 GB のウェイトであり、これは16 GBのサーバーではコンテキストウィンドウを確保する余地が全くないサイズです。どのマシンに何が収まるかというより広い視点については、セルフホスト可能なモデル を参照してください。
KV キャッシュがコンテキストに依存する第 2 のコストである理由
重みは固定コストですが、KV キャッシュ（キー・バリューキャッシュ）は変動コストです。コンテキストウィンドウ内のすべてのトークンは、各レイヤーのキーベクトルとバリューベクトルを保持するため、キャッシュは許可したウィンドウサイズに応じて直線的に増加します。これは会話が進むにつれて確保されるのではなく、モデルの読み込み時にウィンドウ全体分が確保されます。そのため、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 レイヤー、8 個のキー/バリューヘッド、ヘッド次元 128 など）から導かれます。ollama show でアーキテクチャとパラメータ数を確認でき、Hugging Face 上のモデルの config.json で残りの詳細を確認できます。トークンあたりのコストにウィンドウサイズを掛けると、キャッシュは無視できないサイズになります。
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 のデフォルトウィンドウである 4096 トークンの場合、キャッシュは重みに加えて 0.6 GB を消費します。ウィンドウを 32k に引き上げると、キャッシュだけで 4.83 GB に達します。これは量子化された重みとほぼ同等のメモリ量であり、モデル全体の最低メモリ消費量は 10 GB となります。これを「最低ライン」と呼ぶのは、その上に計算用バッファやオペレーティングシステムが乗るためです。実際の数値は、モデル読み込み後に ollama ps の SIZE カラムで確認してください。
Ollama をサービスとして実行する場合、ウィンドウサイズはリクエストごとではなくサーバー側で設定します。
OLLAMA_CONTEXT_LENGTH=8192 ollama servesystemd でインストールしている場合は、ドロップインファイルに設定を記述します。
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 に抑えます。これはグローバルオプションであるため、サーバー上のすべてのモデルに同じ設定が適用されます。ウィンドウサイズが大きい小規模な環境では、キャッシュを半分にすることが、他のどの変更よりも多くのメモリを解放します。num_ctx の設定とそのコスト でウィンドウサイズについて詳しく解説しています。キャッシュはサーバー単位ではなく、同時リクエストスロットごとに確保されます。そのため、Ollama で 2 つのプロンプトを同時に処理できるようにすると、先ほど計算した数値が倍になります。これが 並列スロット数とキュー制限の選択 における計算の根拠です。
8 GB、16 GB、32 GB の VPS で利用可能なモデル
モデルの重み、KV キャッシュ、そしてオペレーティングシステムやその他の実行プロセスに必要なメモリ容量を考慮します。小規模な 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 つのモデルを自身のプロンプトで比較することは、この分野を理解する上で最も有意義な時間となるでしょう。
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 の間の差は小さく、公開されているパープレキシティの表だけでは、自身のワークロードに適しているかを判断できません。表に頼るのではなく、自身のプロンプトを 30 個ほど実行し、その出力を確認してください。
q8_0 または fp16 が RAM を消費する価値がある場合
メモリに余裕があり、かつ小さな誤差が許されないタスク（構造化データの抽出、ツール呼び出し、コンパイルが必要なコード生成など）を行う場合は、q8_0 をプルしてください。これはモデルが目に見えて賢くなるわけではなく、保険を購入するようなものです。
fp16 をプルする理由は2つだけです。モデルを自身で量子化するためにソースファイルが必要な場合か、4bit ビルドでどれだけの精度が失われたかを測定するためのベースラインが必要な場合です。fp16 でのサービングは、ほとんどの人がブラインドテストで判別できない違いのために q4_K_M の3倍のメモリを消費します。CPU のみの環境では、トークン生成速度も3分の1に低下します。
メモリ予算が固定されている場合、より強力なルールとして「q4_K_M の大型モデルは、q8_0 の小型モデルに勝る」というものがあります。9.3 GB の 14B モデルと 8.9 GB の 8B モデルは、ほぼ同じ RAM（ランダムアクセスメモリ）消費量ですが、大型モデルの方がより多くの知識を持っています。これを鵜呑みにせず、自身のプロンプトでテストしてください。
CPUのみの推論はメモリ帯域幅に制限される
ほとんどのVPSプランにはGPUが搭載されていないため、モデルはホストCPU上のシステムメモリで実行されます。生成処理は演算能力ではなくメモリ帯域幅に依存します。これは、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 fp1650 GB/sは、デュアルチャネルのDDR4-3200ホストにおける理論上の数値です。VPSではこのバスをマシン上の他のすべてのテナントと共有するため、実際に利用可能な帯域はその数値よりも小さくなります。したがって、これらの数値は誰も到達できない上限値として扱ってください。重要なのは傾向です。CPU環境では、重みあたりのビット数を半分にすると、トークン生成速度がほぼ2倍になります。量子化は、GPUのない環境において最も大きな速度向上手段です。最終的な生成速度が許容範囲内かどうかはモデルに依存します。VPS上でのNemotron 3.5 Lightningでは、特定のビルド、タグ、RAM容量に基づいた計算例を紹介しています。待ち時間のもう半分は、モデルがどれだけ書き出すかによって決まります。秒間10トークンの場合、600トークンの回答には丸1分かかるため、num_predictで回答を制限する方が、精度を一段階下げるよりも待ち時間を短縮できることがよくあります。
プロンプト処理の挙動は異なります。長いプロンプトの読み込みは帯域幅よりも演算能力に依存するため、コア数を増やすことで速度が向上します。ただし、生成速度にはほとんど影響しません。4kのプロンプトを高速に読み込み、その後の生成が遅いという挙動は、この環境では正常です。
計算結果を鵜呑みにしないでください。自身の環境でトークン毎秒を測定し、各量子化レベルで同じプロンプトを使用して、自身の測定結果を優先してください。
モデルの独自量子化
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 への GGUF ファイルのインポートで詳しく解説しています。ollama show からの quantization 行は、ビルドが意図通りに行われたかを確認する方法です。
問題発生時に確認すべきこと
GPUを使用する想定が、すべてCPUで動作している場合。 PROCESSOR カラムを確認してください。
ollama psここには 100% GPU、100% CPU、あるいは 48%/52% CPU/GPU のような分割状態が表示されます。分割とは、重みとKVキャッシュがVRAM（グラフィックスカード上のメモリ）に収まりきらず、モデルの一部がシステムメモリに配置されたことを意味します。すべてのトークンが低速なメモリ側の処理を待つことになるため、速度はCPUのみで動作する場合に近い値まで低下します。コンテキストウィンドウを小さくする、キャッシュを量子化する、あるいはより小さなビルドを選択してください。CPUコアを増やしても解決しません。
モデルの読み込み中にプロセスが強制終了される場合。 カーネルログとサービスログを確認してください。
sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50Out of memory: Killed process を含む行がある場合、重み、KVキャッシュ、バッファの合計がサーバーのメモリ容量を超えています。スワップが設定されていないVPSでは、その行が表示される前にマシン全体が数秒間停止することがあります。
設定を変更していないのに回答の精度が低下した場合。 同じモデルの異なるビルドが、異なるタグで ollama ls 内に共存している可能性があります。サフィックスのない名前を指定するスクリプトは、ライブラリが現在指し示している最新のものを取得します。設定ファイルの名前を信頼するのではなく、クライアントが要求する正確なタグに対して ollama show を実行し、quantization 行を確認してください。
FAQ
どの Ollama 量子化モデルをプルすべきですか？
まずは q4_K_M から始めてください。これは Ollama ライブラリがほとんどのモデルでデフォルトタグとして提供しているものであり、ollama pull qwen3:8b と ollama pull qwen3:8b-q4_K_M は同じファイルをフェッチします。q8_0 への移行は、メモリに余裕があり、ツール呼び出しや構造化された JSON 出力など、小さな誤差が許容されないタスクを行う場合に限定してください。メモリ予算が固定されている場合、通常は小さなモデルの 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 キャッシュ、およびヘッドルームの合計を考慮してください。Qwen3 8B の q4_K_M では、重みだけで 5.2 GB です。デフォルトの 4096 トークンウィンドウではキャッシュが 0.6 GB 追加され、計算バッファとオペレーティングシステムを除いた最低ラインは 5.8 GB 付近となります。32k ウィンドウの場合、キャッシュだけで 4.83 GB を消費します。短いウィンドウなら 8 GB、長いウィンドウを希望するなら 16 GB を計画してください。
GPU を搭載しているのに、なぜモデルが 100% CPU を使用するのですか？
ollama ps を実行し、PROCESSOR 列を確認してください。100% CPU、あるいは 48%/52% CPU/GPU のような分割が表示されている場合、重みと KV キャッシュが VRAM に収まりきらず、Ollama がモデルの一部または全部をシステムメモリに配置したことを意味します。一般的な原因は、カードの容量を超えるコンテキストウィンドウです。モデルのロード時にウィンドウ全体分のキャッシュが確保されるためです。OLLAMA_CONTEXT_LENGTH でウィンドウを小さくするか、OLLAMA_KV_CACHE_TYPE=q8_0 を設定してキャッシュを半分にするか、より小さな量子化モデルをプルしてください。