「どの量子化レベルを選べばいいの？」は、Ollama でローカル LLM を動かし始めたときに誰もがぶつかる疑問です。Q4_K_M・Q5_K_M・Q8_0・FP16――名前はよく見かけるのに、実際に速度がどれだけ変わるのか、はっきりした一次データはなかなか見つかりません。
そこで今回は Ollama 0.30.8 で qwen2.5:0.5b の4種類の量子化バリアントを実際に pull し、各3回ずつトークン生成速度を計測しました。計測は Apple Silicon / ARM64 環境、CPU 推論のみです。結論から言うと、デフォルトの Q4_K_M（233.5 tok/s）と Q5_K_M（232.7 tok/s）は誤差レベルでほぼ同じ速度でした。「量子化を1段下げると劇的に速くなる」というイメージは、少なくとも 0.5B クラスでは当てはまりません。
この記事のポイント
- Q4_K_M（233.5 tok/s）と Q5_K_M（232.7 tok/s）の差はわずか約0.3%。実質的に同等だった
- 明確に遅かったのは FP16（201.5 tok/s）で、Q4_K_M より約14%遅い
- FP16（948 MB）はサイズが Q4_K_M の約2.5倍になる一方、速度は最も遅い
ollama pull モデル名:タグで任意の量子化バリアントを選べる- 日常用途なら Q4_K_M（デフォルト）で十分。精度を一段上げたいなら Q8_0 が現実的
目次
- 量子化とは何か
- 計測環境・前提条件
- Ollamaで量子化バリアントを指定してpullする方法
- 実測結果：速度・サイズ比較
- Q4とQ5がほぼ同速だった理由を考える
- レスポンス品質の違いを確認する
- 用途別おすすめ量子化レベル
- まとめ
量子化とは何か
AIモデルは大量の浮動小数点数（パラメータ）で構成されています。量子化（Quantization）とは、この数値の精度を落とすことでファイルサイズを削減し、メモリ消費を抑える技術です。16bit の重みを 4bit などに丸めることで、モデルを小さく・軽くします。
Ollama で扱える代表的なレベルは以下の4つです。
| 量子化レベル | 精度 | 特徴 | ファイル縮小率の目安 |
|---|---|---|---|
Q4_K_M |
4bit（K-Quant Medium） | デフォルト。サイズ・速度・精度のバランスが良い | FP16 の約 40% |
Q5_K_M |
5bit（K-Quant Medium） | Q4 より精度を少し上げた中間的な選択肢 | FP16 の約 42% |
Q8_0 |
8bit | FP16 に近い精度。サイズは Q4 の約 1.3 倍 | FP16 の約 53% |
FP16 |
16bit浮動小数（無損失） | 理論上の最高精度。サイズが最も大きい | 基準（100%） |
Ollama で使われている GGUF フォーマットでは、_K_M の「K」は K-Quant（カーネル量子化）を、「M」は Medium（中程度の量子化品質）を意味します。同じ bit 数でも K-Quant は重要な重みをより賢く保護するため、単純な INT4 量子化より精度が高くなります。
計測環境・前提条件
今回の実測環境は以下のとおりです。計測環境の素の CPU 性能を把握するため、Ubuntu 24.04 の公式 Docker イメージ内で sysbench も実行しました。
| 項目 | 値 |
|---|---|
| OS | macOS / Apple Silicon（ARM64 / aarch64） |
| Ollama バージョン | 0.30.8 |
| 推論デバイス | CPU のみ（GPU オフロードなし） |
| テストモデル | qwen2.5:0.5b（Qwen2.5 0.5B パラメータ） |
| 計測回数 | 各量子化 3 回計測、平均値を採用 |
| 環境確認 | ubuntu:24.04 Docker コンテナで sysbench CPU ベンチ実施（平均 29,509 events/sec） |
注意
CPU 推論の速度は使用するマシンや RAM 帯域幅に大きく依存します。GPU を使った場合は Q4 と FP16 の速度差がより縮まる（または逆転する）ことがあります。本記事の数値は CPU 推論環境での結果として参照してください。
Ollamaで量子化バリアントを指定してpullする方法
Ollama でデフォルト（ollama pull qwen2.5:0.5b）を実行すると Q4_K_M が取得されます。他の量子化レベルを使いたい場合は、モデル名に量子化タグを付けて指定します。
$ ollama pull qwen2.5:0.5b
pulling manifest…
pulling 4426acacf627… 100% ▕████████████▏ 398 MB
success
# Q5_K_M
$ ollama pull qwen2.5:0.5b-instruct-q5_k_m
pulling manifest…
success
# Q8_0
$ ollama pull qwen2.5:0.5b-instruct-q8_0
pulling manifest…
success
# FP16（無損失）
$ ollama pull qwen2.5:0.5b-instruct-fp16
pulling manifest…
success
pull 後に ollama list で確認してみましょう。実際に手元の環境で実行した出力が以下です。
qwen2.5:0.5b a8b0c5157701 397 MB 16 hours ago
qwen2.5:0.5b-instruct-q5_k_m 0762ec590a8c 420 MB 34 hours ago
qwen2.5:0.5b-instruct-q8_0 84d044692a2c 531 MB 34 hours ago
qwen2.5:0.5b-instruct-fp16 c82efd44bfdc 994 MB 34 hours ago
API 経由でも確認できます。/api/tags を叩くと、登録済みモデルとサイズが JSON で返ってきます。下のスクリーンショットは Playwright で実際にこのエンドポイントを開いて撮影したものです。
サイズ表記が少し違う理由
ollama list は 10進（1 MB = 1,000,000 バイト）で表示するため 397 MB と出ますが、本記事の図は API の MiB（1 MiB = 1,048,576 バイト）基準で 379 MB と表記しています。どちらも同じバイト数で、丸め方が違うだけです。
実測結果：速度・サイズ比較
各量子化バリアントで同一プロンプト（「Linuxの ls コマンドについて初心者向けに100字程度で説明してください」）を3回ずつ実行し、Ollama generate API の eval_count / eval_duration からトークン生成速度を計算しました。
実際の計測ログ（各3回・eval_duration ナノ秒と eval_count から算出）は次のとおりです。
run 1: 229.5 tok/sec (452 tokens / 1969.6ms)
run 2: 235.4 tok/sec (161 tokens / 683.9ms)
run 3: 235.7 tok/sec (316 tokens / 1340.7ms)
→ 平均 233.5 tok/sec ★最速
# Q5_K_M 3回計測
run 1: 231.6 tok/sec (442 tokens / 1908.4ms)
run 2: 232.7 tok/sec (233 tokens / 1001.5ms)
run 3: 233.8 tok/sec (196 tokens / 838.5ms)
→ 平均 232.7 tok/sec
# Q8_0 3回計測
run 1: 224.7 tok/sec (287 tokens / 1277.0ms)
run 2: 221.8 tok/sec (397 tokens / 1790.2ms)
run 3: 222.9 tok/sec (272 tokens / 1220.3ms)
→ 平均 223.1 tok/sec
# FP16 3回計測
run 1: 203.6 tok/sec (361 tokens / 1773.1ms)
run 2: 200.5 tok/sec (221 tokens / 1102.4ms)
run 3: 200.4 tok/sec (269 tokens / 1342.4ms)
→ 平均 201.5 tok/sec
| 量子化 | 平均速度 | 変動幅 | ファイルサイズ | Q4対比 |
|---|---|---|---|---|
| Q4_K_M（デフォルト） | 233.5 tok/s ★ | 229.5〜235.7 | 379 MB | 基準 |
| Q5_K_M | 232.7 tok/s | 231.6〜233.8 | 401 MB | -0.3%（ほぼ同等） |
| Q8_0 | 223.1 tok/s | 221.8〜224.7 | 506 MB | -4.5% |
| FP16 | 201.5 tok/s | 200.4〜203.6 | 948 MB | -13.7% 遅い |
同じ結果を、Playwright で HTML テーブルとしてレンダリングしてスクリーンショット化したものが以下です。
正直に言うと、計測前は「Q4 が一番速いだろう」と予想していました。結果は Q4 と Q5 がほぼ横並び（差 0.8 tok/s）で、3回の変動幅の中に余裕で収まる差です。この2つは「速度で選ぶ理由がない」と考えてよさそうです。
Q4とQ5がほぼ同速だった理由を考える
「ビット数が少ない（=量子化が強い）ほど速い」と思いがちですが、今回の計測では Q4_K_M と Q5_K_M の速度差はわずか約0.3%でした。差が出たのは Q8_0（-4.5%）と FP16（-13.7%）で、はっきりとした傾向は「ビット数が大きいほど遅い」です。Q4 と Q5 だけが団子になっている形です。
この「Q4とQ5がほぼ同速」という現象には、いくつかの要因が考えられます。
- CPU 推論はメモリ帯域が支配的：トークン生成は重みを大量に読み出す処理が中心です。Q4（379 MB）と Q5（401 MB）はサイズが近く、メモリ転送量の差が小さいため、速度差も小さくなります
- K-Quant のデコードコスト：4bit の K-Quant はビット数こそ少ないものの、ブロック単位の展開処理が必要です。5bit との差し引きで、実効速度がほぼ拮抗することがあります
- FP16 だけ別格に重い：FP16（948 MB）は Q4 の約2.5倍のサイズで、読み出すデータ量がそのまま速度差（-13.7%）に出ています。量子化が「効いている」のはこの部分です
注意
今回の結果は 0.5B パラメータの超小型モデル（CPU 推論）での話です。7B・13B モデルや GPU 推論では、Q4 と Q5 の差や FP16 とのギャップの出方が変わります。使うモデルとハードウェアで実際に計測するのが最善です。
レスポンス品質の違いを確認する
同一プロンプト（「Linuxの ls コマンドについて初心者向けに100字程度で説明してください」）に対する、各量子化レベルの実際の生成結果（1回目）を並べます。
Linuxの`ls`コマンドは、ディレクトリ内のすべてのファイルや子ディレクトリ
を一覧で表示する命令です。通常、`-a`と`-l`が利用されます。
— Q5_K_M —
Linuxの`ls`コマンドは、ディスプレイするファイルを表示します。
`-l`：階層化表示／`–time-style`：タイムスタンプ表示。
— Q8_0 —
こんにちは！`ls`は.lisというファイルシステムを表示する命令です。
`ls -a`：多元なファイルを表示／`ls -l`：一覧を表示。
— FP16 —
Linux の `ls` コマンドは、ディレクトリ名やファイル名を表示する命令です。
ファイルの現在の状態と位置を確認するのに役立ちます。
0.5B という非常に小さいモデルのため、どの量子化でも日本語の細かい誤り（「文件」などの中国語混入、Q8_0 の「.lis」という幻覚）は残ります。量子化レベルを上げれば品質が一直線に良くなる、という単純な関係は今回の出力からは読み取れませんでした。品質差をはっきり比べたいなら、7B・13B 以上のモデルで FP16 と Q4 を見比べるのが現実的です。
用途別おすすめ量子化レベル
実測結果を踏まえた、用途別の選び方をまとめます。
| 用途 | おすすめ量子化 | 理由 |
|---|---|---|
| 日常会話・コード補完 | Q4_K_M（デフォルト） | 今回最速（233.5 tok/s）かつ最小サイズ（379 MB）。迷ったらまずこれで十分 |
| 精度を一段上げたい | Q5_K_M | 速度は Q4 とほぼ同じ（-0.3%）で精度はやや高い。サイズ増は +22 MB のみ |
| 精度を優先したい | Q8_0 | FP16 に近い精度で速度低下は約4.5%に留まる。精度重視ならまずここ |
| 研究・モデル評価 | FP16 | 量子化による誤差ゼロの基準値が必要な場合のみ。速度-14%・サイズ2.5倍と引き換え |
正直なところ、速度を理由に量子化を選ぶ必要はほとんどないというのが今回の実測から得た結論です。デフォルトの Q4_K_M は最速かつ最小で、まず外れません。精度を少し盛りたいなら Q5_K_M、もう一段上げたいなら Q8_0、という順で検討すれば十分です。FP16 は速度・サイズの代償が大きいので、研究目的でなければ過剰になりがちです。
量子化レベルを後から変えるには
- 別の量子化タグを
ollama pullしてそのまま並列保有できる - 実行時は
ollama run qwen2.5:0.5b-instruct-q8_0とタグを指定するだけ - API 経由なら
"model": "qwen2.5:0.5b-instruct-q5_k_m"とリクエスト本文で切り替え可能 - 不要になったモデルは
ollama rm qwen2.5:0.5b-instruct-fp16で削除
まとめ
今回は Ollama 0.30.8 で qwen2.5:0.5b の Q4_K_M / Q5_K_M / Q8_0 / FP16 を実際に計測しました。
- Q4_K_M（233.5 tok/s）と Q5_K_M（232.7 tok/s）の速度差は約0.3%。誤差レベルでほぼ同等だった
- はっきり遅かったのは FP16（201.5 tok/s）で、Q4_K_M より約14%遅い。量子化が効くのはこの部分
- Q8_0 は FP16 に近い精度を保ちつつ、速度低下は約4.5%に留まる良いバランス
- FP16 はサイズが 948 MB と Q4 の約2.5倍。研究目的以外では過剰なことが多い
VPS で Ollama を動かすなら、まず ollama pull モデル名:タグ で複数の量子化を試してみて、自分の環境・用途に合った速度と精度のバランスを見つけるのがおすすめです。とはいえ「とりあえずデフォルトの Q4_K_M」で始めて困ることは、まずありません。
Ollama のインストール方法や Open WebUI との連携については、以下の記事も参考にしてください。
→ Ollama で始めるローカル LLM 完全ガイド
コメント