きっかけ：Qwen3.8-27Bをもっと速く動かしたい
うちのB580(VRAM 12GB)×2枚構成、単体だと厳しいけど2枚合わせれば27B級のモデルもギリギリ載る。実際Qwen3.8-27Bはチェック工程の候補として何度か試してきたんだけど、正直「速いとは言えない」感触があった。
じゃあ量子化レベルを変えたらどれくらい速度が変わるのか、逆に「アクティブパラメータが少ないMoE構成」なら速くなるんじゃないか——という2つの仮説を検証すべく、同じQwen3.8-27B系統で量子化違い4種+MoE版1種、計5モデルをガチンコ比較してみた。
対象モデルとテスト内容
| モデル | 実体 | サイズ |
|---|---|---|
| UD-Q4_K_M(基準) | hf.co/unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_M | 17.4GB |
| UD-IQ4_XS | hf.co/unsloth/Qwen3.8-27B-GGUF:UD-IQ4_XS | 15GB |
| UD-IQ3_XXS | hf.co/unsloth/Qwen3.8-27B-GGUF:UD-IQ3_XXS | 11GB |
| UD-Q5_K_M | hf.co/unsloth/Qwen3.8-27B-GGUF:UD-Q5_K_M | 20GB |
| Whittle-MoE-A17.8B | hf.co/logic65/Qwen3.8-Whittle-MoE-27B-A17.8B-GGUF:Q4_K_M | 18.3GB |
前半4つは同じunsloth配布の量子化違い(UD-IQ3_XXSは単体GPU(12GB)にほぼ収まるサイズ)。最後の1つだけ「アクティブパラメータ17.8B」を謳うMoE構成で、アーキテクチャそのものが違う。
テスト項目は3つ。①「ローカルLLMを自宅PCで動かすメリット」について400字程度の日本語生成、②固定の日本語3文を英訳、③「テキストファイルから最頻出単語TOP5を表示するプログラム」を書かせて実際に実行。加えて生成速度(tokens/秒)とVRAM使用量も計測してる。各モデルの切り替え時は、前回の記事で直した「Ollamaのアンロード完了をポーリング確認」の仕組みをそのまま使ってるので、GPU競合による事故は今回は起きてない。
生成速度：量子化を下げても思ったほど速くならない、上げると激遅になる
正直、一番意外だったのがこれ。「量子化を下げればVRAM消費が減って速くなるはず」という予想に反して、UD-Q4_K_M(11.6〜12.0 tok/s)→UD-IQ4_XS(10.5〜12.7 tok/s)→UD-IQ3_XXS(9.1〜12.7 tok/s)と、量子化を下げてもほぼ横ばい。VRAMは17.4GB→16.1GB→12.8GBときっちり減ってるのに、速度にはほぼ反映されない。
一方でUD-Q5_K_Mは3.6〜3.7 tok/sと、基準のUD-Q4_K_Mの約1/3以下まで速度が落ちた。VRAM使用量は19.4GBで、2枚合計24GBの範囲には収まっているはずなんだけど、体感速度はほぼ「壊れた」レベル。Whittle-MoE-A17.8Bも3.3 tok/sとほぼ同水準で遅く、しかも日本語生成タスクは600秒のタイムアウトまで応答が返ってこなかった。
「アクティブパラメータが少ないMoEなら速いはず」という仮説は、少なくとも今回のOllama+GGUF環境では見事に外れた格好。量子化サイズが大きい(=VRAM消費が大きい)モデルほど、B580×2枚のVulkanバックエンドでの層分割やメモリ確保のオーバーヘッドが顕在化して、速度が一気に落ち込むんだと思う。
VRAM使用量：狙い通りに減るが、速度とは別問題
VRAM使用量そのものは量子化レベルに素直に比例していて、UD-IQ3_XXSは12.8GBとGPU1枚分にほぼ収まるサイズまで削減できてる。ただし前述の通り、VRAMが減っても速度は改善しない。今回の環境では「速度」と「VRAM消費」は別軸の問題で、量子化を下げる主な効果は「省VRAM化」であって「高速化」ではない、というのが実測での結論。
品質チェック：量子化が進むと文章に論理矛盾が紛れ込む
日本語生成の内容を見比べると、地味に見過ごせない問題が見つかった。UD-IQ4_XSとUD-Q5_K_Mの出力に、どちらも同じパターンの論理矛盾が入っていた。
UD-IQ4_XS: 「入力した個人情報や機密資料が外部サーバーに送信されるため、情報漏洩のリスクをゼロに近づけられます」
これ、文脈的には「送信されないため」が正しいはず。「送信される」のに「リスクがゼロに近づく」という真逆の主張になってしまっている。UD-Q5_K_Mの出力にもほぼ同じ構造の矛盾があった。一方で基準のUD-Q4_K_MとUD-IQ3_XXSは、同じテーマで否定形を正しく使えていて、この手の破綻は見られなかった。
サンプル数は1回ずつなので断定はできないけど、「量子化を上げても下げても、基準のQ4_K_Mより品質が安定して良くなるわけではない」というのは実感として持てた。
コーディング課題：MoE版だけ存在しないメソッドを使ってクラッシュ
コード実行検証では、量子化違いの4モデルは全て正解(the:7, fox:7, quick:5, is:5, dog:4)を出力して問題なく動いた。ところがWhittle-MoE版だけ、生成したコードがこんな感じだった。
words = text.split()
count = Counter(words)
top5 = count.top_n(5) # ← Counterにこのメソッドは存在しない
Counterオブジェクトにtop_n()というメソッドは存在しない(正しくはmost_common(5))。実行するとAttributeErrorで即クラッシュ。パッと見はそれらしいコードに見えるだけに、実行して初めて気づけるタイプの不具合だった。日本語生成のタイムアウトと合わせて、この特定のMoE量子化ファイルには何かしら不安定さがありそう。
結論
- 実用上のベストはUD-Q4_K_MかUD-IQ4_XS — 速度・品質ともに横並びで良好。VRAMに余裕を持たせたいならIQ4_XS、実績重視ならQ4_K_M
- 量子化を下げても速度は上がらない — UD-IQ3_XXSはVRAMを12.8GBまで削減できるが、速度はQ4_K_Mとほぼ同じ。「速くしたい」が目的なら量子化ダウンは解決策にならない
- 量子化を上げると逆に大きく遅くなる — UD-Q5_K_Mは速度が基準の1/3以下(3.6 tok/s)まで低下。VRAM総量には収まっていても、この環境では明確に非効率
- MoE(アクティブパラメータ少)だから速いとは限らない — Whittle-MoE-A17.8Bは今回の環境では最も遅く、かつ不安定(タイムアウト・コード生成の破綻)だった
- 量子化違いでも文章の論理矛盾は発生する — UD-IQ4_XSとUD-Q5_K_Mで否定形の脱落による意味の逆転が見つかった。量子化レベルと品質の関係は単純な比例関係ではない
「27Bを速くしたい」という当初の目的に対する答えは、量子化レベルをいじることではなく、結局「基準のUD-Q4_K_M(かIQ4_XS)をそのまま使うのが一番現実的」という、拍子抜けするような結論に落ち着いた。次はプロンプト側の工夫(コンテキスト長の削減、出力トークン数の制限)で速度を稼ぐ方向を試してみたい。