Fable 5 × Composer 2.5 蒸留ローカルモデル「gemma-4-12B-coder」を40タスクで叩いた[RTX5090]

こんにちは、くーるぜろです。

HuggingFaceで週間DL数が14万を超えているモデルがあります。yuxinlu1/gemma-4-12B-coder-fable5-composer2.5-v1-GGUF。Fable 5とComposer 2.5というふたつのモデルのCoT（連鎖思考）を使って蒸留したコーディング特化ファインチューンです。

「ファインチューンで本当にコーディング精度が上がるのか」「量子化でどれだけ落ちるのか」を自分の環境で確かめたくなったので、Q4_K_M・Q6_K・Q8_0の3量子化を40タスク通しで回しました。

このモデルの素性

ベースは`google/gemma-4-12B-it`（Apache 2.0）。作者の説明によると学習データはふたつのソースから構成されています。

メインセット：Composer 2.5のリアルCoT

モデルが実際に問題を解き、生成コードがテストを通過した場合のみ学習データに採用。「パスしたCoTだけ使う」という品質ゲートが特徴です。

補助セット：Fable 5のCoT

Composer 2.5が解けなかった問題を、今度はFable 5に解かせて再蒸留。こちらはテスト通過済みの合成CoTとしてラベル付けされています。苦手な問題を別モデルで補完する発想が面白い。

コンテキスト長は256K（以前のバージョンは131Kと誤記されていたが修正済み）。オープンウェイトでv2も開発中とのこと。

検証環境

• 実行環境: llama.cpp（CUDAビルド）

• ハードウェア: EVO-X2 + RTX5090 32GB

• タスク数: 40問（easy 5 / medium 5 / hard 10 / expert 12 / frontier 8）

• 内容: Pythonのバグ修正・実装タスク（関数レベル、決定論的テスト付き）

• 評価軸:

  • Resolved率（pytestが全パスしたか）

  • Quality（コード品質: ruff・cyclomatic complexity）

  • Combined（上記の総合スコア）

  • usability（🟢自律 / 🟡補助 / 🔴不可）

量子化ごとに完全に同一のプロンプトと同一タスクで回しています。

結果サマリ

結論から言います: Q6_Kが最もバランスが良い。

Resolved率はQ6とQ8が並んで92.5%。しかしCombinedスコアはQ6が85.5でQ8の84.7を上回り、速度はQ6の方が111 tok/s対94 tok/sで約18%速い。9GB収まるVRAMがあるなら、Q8より先にQ6を選ぶ理由が揃っています。

usability（実際どれくらい任せられるか）

Q4は「不可」が15%（6タスク）あります。ローカルコーディングアシスタントとして使うには少し不安な数字。Q6・Q8は8%（3タスク）まで下がります。ただし自律率はどの量子化もほぼ70〜72%で横並びという点が興味深い。「質の高いコードを出す確率」より「そもそも解けるかどうか」に量子化の影響が出ている印象です。

難易度別の崩れ方

easy・hardの正答率は3量子化で同じ。Q8はmediumを全問解いた（Q4・Q6はCSVパースで落ちた）一方、hardの品質はQ6が87と最高。量子化が高いほど単純に良いわけでもないのが面白いところです。

タスク別の"勝敗"が興味深い

同じモデルでも量子化によって解けたり解けなかったりするタスクがいくつかありました。

t010：CSVクォートフィールドのパース

Q4・Q6は失敗、Q8のみ成功。Q4の生成コードはクォートのネスト処理でバグを抱えており、`parse_csv_line('a,"b,c",d')`が`['a', 'b,c,d']`を返してしまいました（正解は`['a', 'b,c', 'd']`）。Q8は`while`ループで先読みを行うより堅牢な実装を生成しています。

t017：slugify（URLスラッグ生成）

Q6のみ成功（Q4・Q8は失敗）。スラッグ生成の仕様解釈が難しいタスクで、Q6だけが全6テストを通しました。

t021：銀行家の丸め（Banker's Rounding）

Q6のみ成功。Python標準の`round()`は銀行家の丸め（偶数丸め）ですが、Q4・Q8はカスタム実装で半端な動作になりました。数値処理の微妙な仕様にQ6が一番追いついていた、という結果です。

t030：JSONパーサーの`\uXXXX`エスケープ

Q4・Q6は失敗、Q8のみ成功。手書きJSONパーサーでUnicodeエスケープシーケンスを正しく処理するという、地味に難しいタスク。Q8がここで粘り勝ちしています。

このように「量子化が上がれば一様に改善」とはならず、苦手タスクが変わります。用途によってQ6とQ8を使い分ける選択肢もあります。

expertからfrontierタスクの状況

全量子化で共通して苦しかったのは仕様が微妙に曖昧なタスクと実装複雑度が高いタスクでした。

Q6はexpert帯のt021（銀行家の丸め）、t032（インタプリタの演算子結合）を補助レベルで解いており、frontier帯も7/8をResolved（うち5つは自律）。12Bクラスのローカルモデルとしては十分な水準です。

Q4はt030（JSONパーサー）、t032（インタプリタ）、t035（HTMLエスケープ）でfrontierの複数タスクが不可。コーディングを全面的に任せるには量子化の限界が見える場面がありました。

速度と実用性

平均生成速度（RTX環境での実測）：

• Q4_K_M: 約133 tok/s

• Q6_K: 約111 tok/s

• Q8_0: 約94 tok/s

Q4は最速ですが精度の犠牲が大きい。コードアシスタントとして使うなら、少し待っても精度を取るQ6が現実的な選択です。

VRAMとのトレードオフは単純で、Q4が約7GB、Q6が約9GB、Q8が約12GB。24GB以上なら全量子化でコンテキストも十分確保できます。

まとめ

• Q4_K_M：速度優先なら選択肢に入るが、不可タスクが15%あるため業務用途には注意

• Q6_K：速度・精度・サイズのバランスが最良。9GB収まるならここが最初の選択

• Q8_0：精度重視ならQ8。ただしCombinedはQ6より低く、速度も遅い

Fable 5 × Composer 2.5の蒸留という発想は面白く、easy〜hard帯の品質は実用水準に達しています。expert帯以降は量子化依存の揺らぎが出てくるので、用途に応じた使い分けが必要です。

DL数14万というのは伊達じゃなく、12Bクラスのコーディングモデルとして試す価値は十分あります。

検証で使ったスクリプトや各タスクの生成コード・テスト結果はアーカイブしてあります。「このタスクの詳細が見たい」「自分の環境でも追試したい」という方はコメントへ。

モデル情報

• yuxinlu1/gemma-4-12B-coder-fable5-composer2.5-v1-GGUF（HuggingFace）

• ベース: google/gemma-4-12B-it

• ライセンス: Apache 2.0

• コンテキスト長: 256K

• 推奨サンプリング: temp 1.0 / top_p 0.95 / top_k 64（thinkingモード有効）

ベンチマーク
・https://github.com/zephel01/swe-bench　

#ローカルLLM #Gemma4 #コーディングモデル #量子化 #llamacpp #ベンチマーク #Fable5 #GGUF