見出し画像

Qwen × Fable の35Bフルファインチューン「Qwable-3.6-35b」を40タスクで検証した[RTX5090]

zephel01

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

名前がユニークなモデルを見つけました。Qwable（クワブル）= Qwen + Fable。Qwen3.6-35BベースにFable 5スタイルの推論データでフルファインチューンしたモデルです。LoRAではなく、フル重みの更新という点がまず目を引きます。

35Bクラスのモデルが手元で動くのか、量子化でどう変わるのかを、いつものコーディングベンチで確かめました。Q4_K_M・Q5_K_M・Q6_Kの3量子化を40タスク通しで回した結果を報告します。

このモデルの素性

ベース: `unsloth/Qwen3.6-35b`（Qwen3.5アーキテクチャ、35BパラメータのMoE）
学習方式: フルファインチューン（LoRAなし）
学習データ: クリーニング済みのFable 5スタイル推論・インストラクションデータセット
ライセンス: MIT（ベースモデルの条項は別途確認）
作者: Mia-AiLab

MTP（Multi-Token Prediction）は無効化されており、通常のQwenスタイルの因果言語モデルとして動作します。「コード、構造化回答、技術アシスタント向けにより熟慮された応答を出せるモデルにしたい」というのが作者の目的です。

重要な点として、Qwen3.6-35BはMoE（Mixture of Experts）アーキテクチャです。 35Bと書いてあっても実際に推論で使う活性化パラメータはその一部。これが後述する「35Bにしては速い」速度の理由です。

GGUFサイズ（公称値）:

検証環境

  • 実行環境: 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が最もバランスが良い。 ただし全量子化で「補助つき運用が無難」という判定が出ました。

速度に注目してください。250 tok/s前後という数字は35Bクラスとしては異常に速い。 MoEアーキテクチャの恩恵で、12B密集モデルに匹敵する速度が出ています。gemma-4-12B-coderのQ4が133 tok/sだったのと比べると、35Bが2倍近く速いという逆転現象が起きています。

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

Q4の「不可」が18%（7タスク）というのは少し多い。Q6では10%まで下がりますが、gemma-4-12B-coderのQ6が8%だったことを考えると、35Bフルファインチューンとして期待より抑えめな数字です。

Q4特有の挙動：学習データのパスが漏れる

Q4で最も印象的だったのは、失敗タスクのうち**4つが「パース失敗」**という特殊な理由でした。

patch parse failed: unknown/unsafe paths:
  ['home/lane/AIArchives/archives/neonix/00000001/palindrome.py']
  ['home/lane/MythosMini/intervals.py']
  ['home/lane/AIArchives/archives/neon/claude/20260611_174400_454/0002/task_output.txt']
  ['home/lane/AIArchives/archives/neon/2026-06-11_10-00-00/.../vm.py']

モデルが学習データ内のファイルパスを出力に含めてしまっています。 本来はタスク対象ファイルへのdiff形式の修正を返すべきところを、`home/lane/AIArchives/...` などの実在しないパスを返してしまい、パーサーが安全と判断できずに弾いた形です。

これは量子化が低い（Q4）ほど学習データの記憶がより露骨に出やすい傾向があることを示している可能性があります。Q5・Q6では同じタスク（t004, t022, t026, t040）が正常に解決されており、量子化が上がるにつれてこの挙動が消えていきました。

フルファインチューンのリスクとして、学習データの個人的な環境情報が重みに刷り込まれているケースがあります。Qwableでは量子化を上げることで緩和されましたが、Q4で使う場合は念のため出力内のパス情報を確認することをすすめます。

難易度別の結果

Q4はeasyで1問落としたのに（t004：パース失敗）、mediumは全問正解という奇妙な分布になっています。これもパース失敗の特殊性によるもので、内容的には解けていても出力フォーマットで弾かれた結果です。

hardはQ6が9/10と最優秀。品質スコアも89と全量子化中最高です。

全量子化で共通して失敗したタスク

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

  • Q5❌（テスト失敗）・Q6❌（タイムアウト）は失敗、Q4✅は成功という珍しい結果

  • Q6がタイムアウトで落ちているのは実装が複雑すぎて処理が終わらなかった可能性

t020：四則演算の優先順位とカッコ処理

  • 3量子化すべてで失敗。演算子優先順位を正しく処理する電卓実装は Qwable の苦手タスク

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

  • 3量子化すべてで失敗。Python標準の偶数丸めの微妙な仕様を正しく実装できませんでした

t034：イベントバス（dispatch中のunsubscribe処理）

  • Q4✅は成功、Q5❌・Q6❌は失敗。dispatch中にハンドラーを解除した場合の挙動という、競合状態的なタスク

35B MoEの速度はどれくらいか

実測平均生成速度:

速度差は小さく、Q4→Q6でもわずか8%の低下。これはMoEの特性で「使われる重みが限られている」ため量子化ビット数の影響が密集モデルほど大きくないからと思われます。

比較として前回検証したgemma-4-12B-coder（MoEなし）は133〜94 tok/sでした。35BのQwableの方が2倍近く速いというのは直感に反しますが、アーキテクチャの違いが数字に出ています。

精度と速度のトレードオフ整理

速度はQwableが2倍以上速いのに、精度はgemma-4-12B-coderが上回っています。 これはFable 5のCoT蒸留で品質ゲートを厳密にかけたgemma-4-12B-coderの強みが出た形とも、Qwableのフルファインチューンがコーディング最適化よりも汎用推論寄りであることを示しているとも読めます。

「とにかく速くたくさん回したい」ならQwable、「コーディング精度を優先したい」ならgemma-4-12B-coderという棲み分けが見えてきます。

まとめ

  • Q4_K_M：パース失敗（学習データのパス漏れ）が特徴的。速度は最速だが精度コストが高い

  • Q5_K_M：Q4とQ6の中間。パース失敗は解消され、速度も十分

  • Q6_K：Resolved率90%、Combined83.2と最高。速度もQ4比8%減で実用的

35B MoEの速度メリットは本物で、ローカルで高速に動かしたいなら有力候補。ただしコーディング特化なら同スコア帯のより小型モデルも選択肢に入ります。パース失敗という独自の挙動はQ5以上で回避できるので、試すならQ5かQ6から始めることをすすめます。

検証で生成したコード・テスト結果はアーカイブ済みです。「特定タスクの詳細が見たい」「自分の環境でも試したい」はコメントへどうぞ。

モデル情報

  • Mia-AiLab/Qwable-3.6-35b（HuggingFace）

  • ベース: unsloth/Qwen3.6-35b（MoEアーキテクチャ）

  • ライセンス: MIT

  • 推奨サンプリング（バランス型）: temp 0.6 / top_p 0.95 / min_p 0.02

  • 推奨サンプリング（コーディング）: temp 0.2〜0.4 / top_p 0.9

#ローカルLLM #Qwen #Fable5 #量子化 #MoE #llamacpp #ベンチマーク #GGUF #35B

いいなと思ったら応援しよう！

zephel01 サーバー代とコーヒー代になります☕ 役に立ったら応援よろしくお願いします！