Qwen on 現役エンジニアのAI事情

12B〜14B級LLM5モデルガチ比較！同じサイズ帯でも速度は最大3.5倍差

Tue, 08 Sep 2026 22:10:27 +0900

きっかけ：同じ「12B〜14B」でも中身はバラバラなのでは

これまで軽量モデル(3〜4B級)と27B級の比較はやってきたけど、その中間の「12B〜14B」帯はまだちゃんと横並びで見たことがなかった。ちょうどB580(VRAM 12GB)1枚にほぼ収まるサイズ帯で、実用上いちばん出番が多くなりそうなクラスでもある。

というわけで、Qwen・Gemma・Phiという主要3系統から12B〜14B級を5モデル集めて、日本語生成・翻訳・コーディングの3タスクでガチンコ比較してみた。今回はコード実行含めて全モデルきれいに動いた、という珍しい回でもある。

対象モデルとテスト内容

モデル	実体
Qwen2.5-14B	`qwen2.5:14b`
Qwen3-14B	`qwen3:14b`
Gemma3-12B	`gemma3:12b`
Gemma4-12B-Heretic	`igorls/gemma-4-12B-it-heretic-GGUF:Q4_K_M`
Phi-4-14B	`phi4:latest`

テスト項目は3つ。①「ローカルLLMを自宅PCで動かすメリット」について400字程度の日本語生成、②固定の日本語3文を英訳、③「テキストファイルから最頻出単語TOP5を表示するプログラム」を書かせて実際に実行。加えて生成速度(tokens/秒)とVRAM使用量も計測してる。

生成速度：同じ12B〜14B級でも最大3.5倍の差

今回いちばん面白かったのがこれ。パラメータ数もVRAM使用量もほぼ横並びの5モデルなのに、生成速度には最大で3.5倍もの開きが出た。

最速はGemma4-12B-Heretic(33.0〜35.1 tok/s)。次点でQwen3-14B(25.7〜27.5 tok/s)、Gemma3-12B(20.5〜21.0 tok/s)と続き、Qwen2.5-14B(9.7〜10.1 tok/s)とPhi-4-14B(9.7〜10.0 tok/s)がほぼ同水準で最も遅い。

特に注目したいのがQwen2.5-14BとQwen3-14Bの差。同じQwenファミリーで、VRAM使用量もほぼ同じ(11.2GB vs 11.4GB)なのに、Qwen3世代になっただけで速度が約2.7倍に跳ね上がっている。パラメータ数やVRAM消費だけを見ていても速度は予測できない、というのがよく分かる結果だった。

VRAM使用量：Gemma4-12B-Hereticが頭一つ省メモリ

VRAM使用量は9.0GB(Gemma4-12B-Heretic)〜11.6GB(Phi-4-14B)の範囲で、5モデルとも単体のB580(12GB)に余裕を持って収まるサイズ。Gemma4-12B-Hereticは最速かつ最省メモリという、今回のテストでは文句なしの結果になった。

品質チェック：コードは全モデル一発成功、ただしPhi-4に気になる一言

コーディング課題は5モデル全てが正解(the:7, fox:7, quick:5, is:5, dog:4)を一発で出力し、実行エラーもゼロ。前回・前々回の比較記事では量子化違いやMoE版で実行時エラーが頻発していたので、今回の「素直に動く」結果はむしろ意外だった。コードの書き方自体も、正規表現での単語抽出+Counter.most_common(5)という王道パターンにほぼ揃っていて、実装力の差は感じられなかった。

翻訳も5モデルとも自然な英訳で、明確な誤訳は見当たらなかった。

一方、日本語生成の内容を読んでいて1つ気になったのがPhi-4-14Bの一節。

Phi-4-14B: 「ローカルLLM（ローカル・ランタイム・マシンラーニング）を自宅PCで動かすことには…」

LLMは"Large Language Model"の略で、「ローカル・ランタイム・マシンラーニング」ではない。文章全体の論理は破綻していないんだけど、律儀に略語の説明を加えようとして、その説明自体が誤っているという地味に厄介なパターン。読み流すと気づきにくいけど、事実確認という観点では明確な誤り。

結論

速度最優先ならGemma4-12B-Heretic — 全タスクで最速(33〜35 tok/s)、かつVRAM消費も最小(9.0GB)。今回の5モデルで総合トップ
同じ「Qwen」でも世代で速度が全然違う — Qwen2.5-14B→Qwen3-14Bで約2.7倍の高速化。「Qwenだから」で判断せず、世代までちゃんと見るべき
12B〜14B級は総じてコード生成が安定 — 5モデル全てが実行エラーなしで正解を出力。27B級のMoE版や過度な量子化で見られたクラッシュは、このクラスでは今回発生しなかった
パラメータ数・VRAM使用量から速度は予測できない — Qwen2.5-14BとQwen3-14Bはスペック上ほぼ同じなのに速度は約2.7倍差。世代・実装の最適化度合いが効いている
略語の自己解説には要注意 — Phi-4-14Bが「LLM」を誤った日本語で展開する場面があった。文章の流暢さと事実の正確さは別物

体感として、12B〜14B級は「重すぎず軽すぎず」の実用サイズであると同時に、モデル間の実装差がいちばん速度に出やすい帯域でもあるという発見があった。次はこのクラスの中で、コンテキスト長を伸ばした際の速度劣化度合いも比較してみたい。

Qwen3.8-27Bを速くしたい！量子化4種+MoE版をガチ比較したら意外な結果に

Tue, 08 Sep 2026 21:23:44 +0900

きっかけ：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)をそのまま使うのが一番現実的」という、拍子抜けするような結論に落ち着いた。次はプロンプト側の工夫(コンテキスト長の削減、出力トークン数の制限)で速度を稼ぐ方向を試してみたい。