きっかけ：軽量モデルって結局どこまで使えるの？
うちの自動記事生成パイプラインでは、誤字脱字チェックみたいな「軽めだけど頻度の高いタスク」に、わざわざ20B超えの大きいモデルを使う場面があるんだよね。でも正直、そこまで賢さが要らないタスクなら、もっと軽量なモデルに任せて高速化したいよねって前々から思ってた。
というわけで、単体のB580（VRAM 12GB）に余裕で収まるサイズの軽量モデルを5つ集めて、日本語生成・翻訳・コーディングの3タスクでガチンコ比較してみた。今回は「なんとなく良さそう」で終わらせず、コーディング課題は実際にコードを実行して検証するところまでやってる。
対象モデルとテスト内容
| モデル | 実体 |
|---|---|
| Qwen3.8-4B-Distill | hf.co/empero-ai/Qwen3.8-4B-Distill-GGUF:Q4_K_M |
| Phi-4-mini-instruct | phi4-mini(Ollama公式) |
| Qwen3-4B | hf.co/Qwen/Qwen3-4B-GGUF:Q4_K_M(Thinking系) |
| Llama-3.2-3B-uncensored | hf.co/bartowski/Llama-3.2-3B-Instruct-uncensored-GGUF:Q4_K_M |
| Gemma4-E2B-Alignment-Study | hf.co/mradermacher/gemma-4-E2B-Alignment-Study-GGUF:Q4_K_M |
テスト項目は4つ。①「画像生成AIの問題点」について400字程度の日本語生成、②固定の日本語3文を英訳、③「テキストファイルから最頻出単語TOP5を表示するプログラム」を書かせて実際に実行、④生成速度とGPU/VRAM使用率の計測。
ちなみに候補に挙がっていたモデルのうち2つは、検証中に「そもそも実体が怪しい」ことが判明して除外してる。mondk/GGUF.chatgpt-gpt-gpt5.1-thinkingは名前と裏腹にOpenAIのGPT-5.1では全くなく、Qwen3-4B-Thinking-2507を「悪意のあるプロンプトも拒否せず説明する」方向にファインチューンした別物だった。名前だけで判断せずちゃんと中身を確認するの、大事だなと。
生成速度：Qwen3-4Bだけ突出して遅い理由
グラフにするとQwen3-4Bのコーディングタスクだけ突き抜けて時間がかかってるのが一目瞭然。これ、単純に生成が遅いわけじゃなくて「事故」なんだよね。
Qwen3-4Bは"Thinking"系のモデルで、Ollama呼び出し時にthink=Falseを指定したにもかかわらず、<think>...</think>形式の内部思考（しかも英語の長い独り言）がそのまま出力に漏れ続けた。日本語生成・翻訳・コーディングの全タスクで発生していて、特にコーディングタスクでは104秒のうち大半がこの可視化された思考過程で占められてる。コミュニティ配布のGGUF量子化モデルだと、OllamaのthinkAPIパラメータが必ずしも効かないケースがある、というのは地味に重要な学びだった。
それを除けば、Phi-4-miniとLlama-3.2-3B-uncensoredが速度的には優秀。ただし後述するけど、速いなりの理由があった。
VRAM使用量：ほぼモデルサイズに比例
初回計測では全モデルVRAM使用量が0と表示されて「あれ？」ってなったんだけど、これはWindowsの「GPU Process Memory」カウンターが、Ollama（Vulkanバックエンド）のプロセス単位の使用量を正しく報告できない制約が原因だった。プロセス非依存の「GPU Adapter Memory」カウンター（タスクマネージャーと同じ系統）に切り替えて再計測してる。
結果は見ての通り、ほぼモデルサイズに比例。最大のQwen3.8-4B-Distillで約8GB、最小のGemma4-E2Bで約2.5〜2.9GB。全モデルとも単体のB580（12GB）に十分収まるサイズで、この点は候補全モデルで問題なし。
コーディング課題：見た目は動きそうでも実行すると壊れるやつが2つ
ここが一番面白かったところ。テストデータ（51語、正解: the:10, quick:9, fox:5, is:5, dog:4）で全モデルのコードを実際に実行してみたら、5モデル中2モデルが実質的に破綻してた。
| モデル | 実行結果 | 問題点 |
|---|---|---|
| Qwen3.8-4B-Distill | 正解と完全一致 | なし |
| Phi-4-mini | 無出力(終了コード0) | 関数を定義しただけで呼び出し部分がコメントアウトされたまま |
| Qwen3-4B | 正解と完全一致 | 潜在バグあり(今回は顕在化せず) |
| Llama-3.2-3B-uncensored | FileNotFoundErrorで即クラッシュ | ファイルパスを引数で受け取らず'path_to_your_file.txt'とハードコード |
| Gemma4-E2B-Alignment-Study | 正解と完全一致 | 存在しないファイルでも適切にエラーメッセージを表示、最も堅牢 |
Phi-4-miniのコードは、パッと見ただけだと「関数もちゃんと定義されてるし動きそう」に見えるんだよね。でも実際に実行すると、呼び出し部分が丸ごとコメントアウトされたままで何も起きない。終了コードも0なので、自動テストで「エラーが出なかったからOK」みたいな雑な判定をしてたら見逃してたと思う。Llama-3.2-3Bの方はもっと直接的で、ファイルパスを引数で受け取る仕様のはずが決め打ちのパス文字列になっていて、渡したテストファイルが存在せず即クラッシュ。
有名な提供元（Microsoft/Phi、bartowski）のモデルだからといって、コード生成品質が保証されるわけじゃないんだな、というのが実行検証してみて初めてわかったこと。コードの目視確認だけだと、この手の「表面上はそれらしいけど実運用不可能」なバグは普通に見逃す。
言語混入は「たまたま」じゃなく構造的な弱点だった
日本語生成タスクは同じプロンプトで2回実施したんだけど、Qwen3.8-4B-DistillとLlama-3.2-3B-uncensoredは2回とも言語混入系のミスを起こした。1回目はQwen3.8-4B-Distillが「多起」という誤変換、2回目は同じ文の別の箇所に韓国語の単語（제시）が混入。Llama-3.2-3B-uncensoredの方は、1回目が翻訳での1文丸ごと脱落、2回目は簡体字・繁体字由来の漢字（「自杀」「剽竊」など）が日本語文中に混入していた。
サンプリングで出力が毎回変わるモデルで、違う種類のミスが2回とも出るってことは、単発の運の悪さじゃなくて、モデルや量子化の構造的な弱点だと考えた方が良さそう。日本語主体で使うなら、この2モデルは要注意。
結論
- 総合最良はGemma4-E2B-Alignment-Study — 内容の充実度・翻訳精度・コードの堅牢性のすべてでトップ。速度も45.7秒と許容範囲内
- Qwen3.8-4B-Distillが僅差で優秀 — 全項目で合格点、最速クラス。ただし言語混入のリスクは頭に入れておきたい
- Phi-4-mini・Llama-3.2-3B-uncensoredは要注意 — 速度は魅力的だけど、コーディングタスクで実質的に破綻。有名どころのモデルでも過信は禁物
- Qwen3-4B（Thinking系）は現状のOllama連携では扱いづらい — 内部思考の漏洩で速度が3〜10倍に膨張。専用のパース処理無しでは採用しにくい
- 「実際に実行して検証する」ことの重要性を再確認 — コードの目視確認だけでは見抜けない不具合が、5モデル中2モデルで見つかった
軽量モデルだからといって侮れない結果と、逆に「有名だから安心」でもない結果が両方出た検証だった。次はこのGemma4-E2Bを、うちのパイプラインの軽量タスク（誤字脱字チェックとか）に実際に組み込んで、体感速度がどれくらい変わるか試してみたい。