見出し画像

1runのチャンピオンは5runsのチャンピオンではなかった:Qwythos-9B-v2の新王者はMTP版Q6_K

zephel01

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

前回（v1）、Empero AIの前作「Qwythos-9B-Claude-Mythos-5-1M」を40タスクで検証したとき、筆者はMTP版Q8_0をチャンピオンに認定しました。ただしあの記事はすべて単発（1run）の計測です。このシリーズの背骨のひとつに「1回の結果で語らない」があるのに、そこだけ守れていなかった。

今回はその後継、Qwythos-9B-v2です。そして今回は反省を込めて、MTP版に5runs本検証を導入しました。結果、v1でチャンピオンだった構成（Q8_0）は、単発で87.5%を叩き出しておきながら5回平均では75.0%まで落ちました。+12.5ptの単発上振れです。代わりに新しい王者になったのはMTP版Q6_K——平均成功率81.0%、pass@5は5量子化で唯一の100.0%、そして5回とも全滅したタスクがゼロ。

「単発で語るな」という自分への教訓が、そっくりそのまま実証された回になりました。

このモデルの素性

GGUFサイズ（HF公称値。実測ではない）:

MTP版は各量子化とも上記に**+160〜500MB程度**（MTPヘッド分）。

FTPOによる「ループ0%」やGGUFサイズはあくまでモデルカード掲載値です。今回の実測（Resolved・成功率・tok/s）とは別物として扱い、後述のスコア表には混ぜていません。9Bクラスなのでq4系ならVRAM 8GB前後で動作します。

検証環境

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

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

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

  • 実行回数: MTP版=「1runスクリーニング → 5runs本検証」の2段階／標準版=1runのみ（時間の都合。参考値扱い）

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

  • サンプリング: 公式推奨 temp 0.6 / top_p 0.95（top_k 20 / repeat_penalty 1.05）

  • 評価軸: Resolved率 / 成功率（5回平均） / pass@k / Quality / Combined / usability

使っているのは自作のSWE-Bench風ベンチ（llmbench）です。バグレポート＋ソースをLLMに渡し、patch適用→LLMには非公開の隠しpytestでresolved判定します。難易度tierは easy / medium / hard / expert / frontier、タスクIDは t001〜t040。

  • Combined = success_rate ×（0.5 + 0.5 × quality/100）× 100（動かないコードは0点）

  • Qualityはlint密度＋保守性指標＋別LLMレビューの重み付き合成

  • GitHub: `zephel01/swe-bench`（MIT）。stdlib-onlyで再現可能

結果サマリ（MTP版 5runs本検証）

信頼性の主データはこちらです。tok/sは後述の理由から1run時の中央値を速度指標として併記します。

結論: MTP版Q6_Kが新チャンピオン。平均成功率81.0%・pass@5 100.0%・Combined 74.9で3冠、しかも5回全滅タスクがゼロ。v1で王者だったQ8_0は5runs平均75.0%まで失速した。

Qualityだけを見るとQ8_0（86.0）が僅かに上ですが、Combinedは「動かないコードは0点」で成功率を主軸に効かせる指標です。書けたコードの綺麗さより、そもそも通るかどうか——その物差しでQ6_KがQ8_0を5.4pt引き離しました。

目玉：v1チャンピオンQ8_0が5runsで失速した

ここがこの記事の本題です。まず、MTP版の各量子化について「1runスクリーニングの数字」と「5runs平均」を並べます。

もし今回も単発で終わっていたら、Q8_0（1run 87.5%）を「今回もチャンピオン」と書いていたはずです。しかし5回回すと75.0%まで沈む。逆にQ6_Kは1runでは75.0%と目立たなかったのに、5回平均では81.0%へ伸びる。単発の順位（Q8_0 > Q6_K）が、本検証で完全に逆転しました。

差分の大きさに注目してください。Q8_0の+12.5ptは、明らかに「たまたま良い5回に1回を引いた」上振れです。逆にQ6_KやBF16は単発でむしろ運が悪く、本来の力が5runsで見えてきた。±3pt程度なら運の範囲として断定を避けますが、+12.5ptはもう別物です。これがv1で筆者がやってしまった「単発チャンピオン認定」の落とし穴でした。

考察としてはっきり言えるのは、このモデルは単発の振れ幅が大きく、1runでの序列づけがそのまま信用できないということ。教訓はシンプルです——1runのチャンピオンは、5runsのチャンピオンではない。

pass@5 で見る「再現性」の差

平均成功率とは別の物差しとして pass@5（5回のうち1回でも通ればカウント）を見ます。ここでQ6_Kの強さがもう一段はっきりします。

Q6_Kだけがpass@5 100.0%、つまり40タスクのどれも、5回のうち最低1回は解けている。全滅タスクがゼロなのはQ6_Kだけです。他の量子化はどこかに「5回やっても一度も通らない壁」を抱えています（Q4_K_Mは3タスクも）。

ただしここは冷静に読む必要があります。pass@5 100%と平均成功率81.0%は別の物差しです。前者は「運が良ければどのタスクも解ける」、後者は「実際に任せて何割が通るか」。実運用で効くのは平均成功率のほうで、pass@5は「地力の広さ」を示すおまけ指標だと捉えてください。とはいえ「一発も通らない鬼門を持たない」というのは、9Bとしては地味に効く長所です。

鬼門t020を、Q6_Kは5回に1回だけ通した

このシリーズの常連の鬼門、t020[hard]「calculator ignores precedence and parentheses（電卓の演算子優先順位・括弧）」。前作でも大半のモデルが落としてきたタスクです。

今回のMTP版5runsでの t020 の内訳:

Q6_Kは5回中1回、t020を通しました。これがpass@5 100%への地味な貢献になっています。ただし1/5はあくまでflaky（run割れ）であって、「Q6_Kはt020を解ける」と言い切れる再現性ではありません。誇張はしません。むしろQ6_Kですら5回に4回は落とすのがt020の鬼門たるゆえんで、シリーズの系譜どおり今回も健在でした。

flakyタスクが多すぎる：temp 0.6でこの振れ幅

このモデルの一番の性格は「flaky（5回中で通ったり通らなかったりするタスク）が異様に多い」ことです。

Q8_0に至っては40タスク中21タスク、実に半分以上がrun割れしています。参考までにQ6_KとQ8_0のrun割れ内訳を挙げると:

  • Q6_K（18タスク）: t004(3/5), t007(4/5), t010(2/5), t014(4/5), t015(4/5), t017(2/5), t019(4/5), t020(1/5), t021(3/5), t022(4/5), t029(3/5), t030(2/5), t033(2/5), t034(2/5), t035(4/5), t037(1/5), t038(4/5), t039(3/5)

  • Q8_0（21タスク）: t004(4/5), t007(4/5), t008(4/5), t015(4/5), t017(3/5), t020(1/5), t021(1/5), t022(4/5), t023(4/5), t025(3/5), t028(4/5), t029(1/5), t030(1/5), t032(2/5), t033(1/5), t034(4/5), t035(3/5), t036(3/5), t038(3/5), t039(4/5), t037(2/5)

注目してほしいのは、これがtemp 0.6という比較的低めの温度での結果だということです。公式推奨に忠実に回してこの振れ幅。モデルカードは「FTPOで低温度デコード時のループを0%に改善した」と主張していますが（モデルカード掲載値）、ループが消えたことと出力が安定することは別問題で、解けるタスクの再現性はまだ揺れているというのが実測での率直な感触です（因果の断定は避けます。自信度: MODERATE）。

そしてこの「flakyの多さ」こそ、単発計測が危険な直接の理由です。半分のタスクが運次第で結果が変わるモデルを1回だけ回して順位をつければ、そりゃ+12.5ptの上振れも起きます。Q8_0がv1でチャンピオンに見えたのは、この振れの上側をたまたま引いていたから、という説明が一番しっくりきます。

難易度別の成功数（MTP版 5runs、resolvedベース）

どの帯で差がついたかを分解します。

easy〜mediumは全量子化で横並び（天井効果）、差はほぼfrontier帯で決まっています。Q4_K_Mはfrontier 2/8と沈み、Q6_K/BF16が5/8、Q8_0が6/8。ここだけ見るとQ8_0が良く見えますが、Q8_0はexpert帯で8/12と崩れており（Q6_Kは11/12）、帯ごとの得意不得意が噛み合っているのがQ6_K、という読み方になります。Q8_0はfrontierで稼いだぶんをexpertで吐き出している格好です。

標準版（MTPなし）は1runのみ：断定禁止の参考値

標準版は時間の都合で1runしか回せていません。なので以下は参考値で、順位の断定はしません。

一見するとQ5_K_Mが85.0%で最高に見えます。が、ここで思い出してほしいのがv1（前作）では標準版Q5がむしろ最低（72.5%）だったという事実です。同じQ5が、単発計測というだけで最低にも最高にもなりうる——これは「単発の振れの範囲」の格好の実例です。MTP版で+12.5ptの上振れを見た直後にこれを見れば、標準版1runの順位を真に受けてはいけないのは明らかでしょう。標準版の本当の序列は、5runsを回すまで宿題です。

tok/s の読み方（重要な注意つき）

まずtok/sは速度の物差しであって、賢さの物差しではありません。とくにこのモデルはMTP（投機的デコード）搭載版があり、MTPは構造的に速い数字が出ます（先読みが当たるぶん速いだけで、精度が上がるわけではない）。denseの標準版が遅いのは素直な挙動で、遅い＝劣っている、ではありません。

（すべて中央値。`~`は概算）

ここで正直に書きます。 MTP版の「1run時 ~177〜194」と「5runs時 ~62〜85」は桁が違いすぎます。5runs時に大きく落ちているのは並列実行など測定条件の差が原因の可能性がありますが、ログからは断定できません（自信度: LOW）。したがって本記事では1run時の値を速度指標として採用し、5runs時の数字は「条件差の可能性あり」として速度比較には使いません。数字を横並びにして「MTPで速い！」と煽ることはしません。

その前提で読むと、MTP版は標準版に対しておおむね上乗せが効いており（Q8_0で ~177 vs ~103）、v1で見た「精度が高い量子化ほどMTPの倍率が大きい」傾向とも整合します。BF16だけはMTP版でも~111と伸びが鈍い点も前作と同じ癖です。

usability（実際に任せられるか）

🟢 自律＝レビューほぼ不要 / 🟡 補助＝レビュー前提なら任せられる / 🔴 不可＝任せられない。

MTP版（5runs）:

不可率が最も低いのはQ6_KとBF16（ともに17%）。Q6_Kは自律率こそQ4_K_M（50%）に譲りますが、「任せられない」タスクが最も少なく、Combined・pass@5の結果とも一致しています。

標準版（1run・参考値）:

標準版の自律率が軒並みMTP版より高く見えますが、これは1run（好調な1回）と5runs（振れを均した平均）を並べているだけで、公平な比較ではありません。同じ土俵で比べられるのは5runsを揃えてから、というのをもう一度断っておきます。

v1（前作モデル）との比較

続編なので前作の数字と並べます。ただし前作v1はすべて単発計測なので、直接の横並びには限界があることを先に断っておきます。

v1のMTP-Q8_0は「Resolved 85% / 253 tok/s」でした。数字だけ見ればv2のQ6_K（82.5% / ~188）より速くて高精度に見えます。が、これは典型的な罠です。v1の85%は今回のQ8_0がやったのと同じ単発の上振れを含みうる数字で、5runs平均という土俵には乗っていません。tok/sも253 vs ~188という差はありますが、そもそも別モデル・別計測回で、条件を揃えた比較ではありません。

なので「v2はv1より遅くなった／精度が落ちた」とは書きません。言えるのは「v1は単発なので直接比較できない。v2は初めて5runsで裏を取った」という測定設計の進歩のほうです。数字の優劣より、ようやく信用できる物差しで測れたことが今回の収穫です。

まとめ：どの量子化を選ぶか

  • 精度・安定性を最優先するなら → MTP版 Q6_K。 平均成功率81.0%、pass@5 100.0%、Combined 74.9、5回全滅タスクなし。今回の総合王者。迷ったらこれ。

  • とにかく速く動かしたい／VRAMを節約したいなら → MTP版 Q4_K_M。 1run ~194 tok/sで最速、成功率も75.5%と実用圏。ただし全滅タスクが3つある点は許容できるなら。

  • Q8_0を選ぶ理由は、今回はない。 1runでは輝くが5runs平均75.0%、flaky 21タスクと最も不安定。v1のチャンピオンは退位した。

  • BF16は悪くないが、Q6_Kの下位互換。 80.5%と健闘するがサイズは17.92GB（公称）とQ6_Kの倍以上。速度も~111と鈍い。積極的に選ぶ理由は薄い。

  • 標準版は現状ノーコメント。 1runのみなので順位は付けない。Q5_K_Mが85.0%に見えるが、v1では同じQ5が最低だった前例があり、単発の振れとして扱う。5runsは宿題。

最後に、この回で持ち帰る教訓を2つ。

  1. 1runのチャンピオンは、5runsのチャンピオンではない。 v1でQ8_0を王者にした筆者が、v2で同じQ8_0の+12.5pt上振れを目の当たりにした。単発は嘘をつく。

  2. pass@5 100%と平均成功率は別の物差し。 「どのタスクも5回に1回は解ける」の広さと、「任せて何割通るか」の実力は違う。Q6_Kは両方で勝ったから王者だが、片方だけなら王者とは言えなかった。

9Bクラスとしてはソリッドで、しかも扱いやすいサイズです。VRAMに余裕があるならMTP版Q6_K、節約したいならMTP版Q4_K_Mを入口にどうぞ。

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

モデル情報

  • HuggingFace: https://huggingface.co/empero-ai/Qwythos-9B-v2-GGUF

  • ベース: `Qwen/Qwen3.5-9B`（dense 9B）／前作 Qwythos-9B-Claude-Mythos-5-1M の後継

  • ライセンス: Apache-2.0

  • 推奨サンプリング: temp 0.6 / top_p 0.95 / top_k 20 / repeat_penalty 1.05

  • MTP: 対応（`nextn_predict_layers=1`）。標準版／MTP版の両GGUFあり

関連記事

  • 前回（v1）: 「Qwen3.5ベースの9B推論モデル『Qwythos-9B-Claude-Mythos-5-1M』を40タスクで検証した（MTP比較あり）」

#ローカルLLM #llamacpp #ベンチマーク #量子化 #GGUF #Qwythos #9B #MTP #passk #Qwen3

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

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