見出し画像

Resolved 93.3%:Qwythos-27B-v1はMTP版Q6_Kが頭一つ抜けた——同じQ6_Kの標準版は6パターン中最下位

zephel01

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

今回はempero-aiのQwythos-27B-v1です。これまでこの連載で2本書いてきたQwythos-9Bシリーズの、そのまま大きくなった上位サイズ版という位置づけのモデルです。

標準版とMTP版をそれぞれQ4_K_M / Q5_K_M / Q6_Kの3量子化、合計6パターンを60タスク（architect帯20問を含む）で回しました。

先に結論を出しておきます。最良はMTP版Q6_KでResolved 93.3%（56/60）・Combined 85.3。ところが同じQ6_Kでも標準版は83.3%（50/60）・Combined 76.9で、6パターン中の最下位です。ビット幅が同じでMTPヘッドの有無だけが違う2つに、Resolvedで10.0ptの差がついた。 しかもその差が開いたQ6_Kでは、MTPの売りであるはずの速度優位がきれいに消えています。

そしてもうひとつ、先に大きく断っておきます。今回の27Bデータは6パターンすべてがruns=1、つまり単発実行です。 このシリーズの背骨は「1回の結果で語らない」で、しかも前回のQwythos-9B-v2の記事は、まさに単発チャンピオンが5runsでひっくり返る話でした。今回はその教訓の当事者として、順位の断定を避けながら書きます。

このモデルの素性

公称ベンチ値はありません。 公式ページに「標準化された学術ベンチマークスイートは実施されていない」と明記されています。つまりこの記事に「モデルカードのMMLUは○○」といった比較表は作れませんし、作りません。この記事に出てくる性能数値は、すべて筆者の実測です。

なお「RL学習版のv2は開発中」というのはこの27BのHFページ上の記述で、9B側ですでにリリース済みの「Qwythos-9B-v2」とは別物（将来の27B-v2）です。今回のベンチ対象はあくまでv1です。

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

今回検証したのはQ4/Q5/Q6の3段だけです。Q8_0とBF16は回していないので、この記事は「27Bの全量子化を網羅した」記事ではありません。9B記事ではQ8_0・BF16まで含めていたので、そこは今回の穴です。

27BなのでQ4_K_Mで約16GB、Q6_Kで約21GB。32GB VRAM級なら余裕、24GBならQ6_Kがぎりぎり、16GBだとQ4_K_Mでもオフロード前提になります。

検証環境

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

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

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

  • 実行回数: 各タスク1回（全6パターンruns=1）。5runs本検証は未実施。

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

  • サンプリング: 今回のログに記載なし（不明）。 モデルカード掲載の推奨値は temp 0.6（エージェント用途）/ 1.0（推論・創作用途）、top_p 0.95 / top_k 20 / repeat_penalty 1.05 ですが、実際にこの値で回したかはログから確認できません。

  • 評価軸: Resolved率 / Quality / Combined / usability（成功率5回平均・pass@kは今回データなし）

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

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

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

Qualityについて1点だけ正直に。 通常このシリーズのQualityは「lint密度＋保守性指標＋別LLMレビュー」の重み付き合成ですが、今回の6パターンは全て `quality_components.llm_review` と `sonarqube` が `enabled: false` です。つまり今回のQualityはruff＋複雑度ベースのみ。過去記事のQuality値と厳密には同じ物差しではないので、Quality単体の他記事比較はしません。

結果サマリ（6パターン、すべて1run）

結論: 6パターン中の最良はMTP版Q6_K（Resolved 93.3% / Combined 85.3）。同じビット幅の標準版Q6_K（83.3% / 76.9）が最下位で、MTPヘッドの有無だけで10.0ptの差。ただし全データが単発実行なので、この序列が5runsで維持される保証はない。

表の空欄について。「成功率（5回平均）」と「pass@k」はシリーズ固定の列ですが、今回は1runしか回していないので埋められません。ここが埋まっていない表は信頼度が一段落ちる、というのが9B-v2で学んだことなので、列ごと消さずに空欄のまま残しておきます。

tok/sは今回のログの平均値です（シリーズ既定の中央値ではありません）。並列実行時の1ストリーム値は今回計測していないので、単発実行時の値のみです。読み方の注意は後述します。

Qualityを見るとMTP-Q6_Kは82.7で6パターン中最低です。それでもCombinedが最高になるのは、Combinedが「動かないコードは0点」で成功率を主軸に効かせる指標だから。書けたコードの綺麗さより、そもそも通るかどうか——9B-v2でも書いたこの読み方が、27Bでもそのまま当てはまりました。

そしてもうひとつ冷静な線引きを。MTP-Q6_K（93.3%）と標準Q5_K_M（90.0%）の差は3.3pt、Combinedでは2.5ptです。±3pt程度の差で優劣を断定しないというのがこの連載のルールなので、この2つは「単発では僅差、順位づけは保留」と書いておきます。一方、後述するMTP-Q6_Kと標準Q6_Kの10.0pt差は、その留保幅を明確に超えています。

目玉:同じQ6_Kで、MTPありが最高・MTPなしが最低

今回いちばん奇妙なのはここです。

同じQ6_K、同じ60タスク、違うのはMTPヘッドの有無だけ。それでResolvedが10.0pt、Combinedが8.4pt動いています。失敗タスク数は4と10で、2.5倍の開きです。

そしてこれとセットで見てほしいのが、MTPの速度優位がQ6_Kでだけ消えているという事実です。

Q4で+81%、Q5で+91%と、MTPの投機的デコードは明確に効いています。9B記事で見た「MTPは構造的に速い数字を出す」という傾向どおりです。ところがQ6_Kだけ+0.5%、実質同速。レイテンシに至ってはMTP版のほうがわずかに遅い（19.21秒 vs 18.61秒）。

つまりQ6_Kでは、MTP版は速さを1つも得ていないのに、解決力だけ10pt多く得ているという格好になります。

これをどう読むか。素直な解釈は「Q6_KのMTP版だけ投機的デコードのドラフト受理率が落ちて、先読みが効かず標準版と同じ速度域に落ちた」というものですが、それが同時にResolvedを10pt押し上げる理由にはなりません（投機的デコードは本来、受理判定によって最終出力を変えない建前の機構です）。となると、この10ptの正体としてありうるのは、(a) MTP版Q6_K固有の実際の実力差、(b) 単発実行の運の上振れ、(c) 測定条件の食い違い（バッチや並列度が他パターンと違った可能性）——このいずれか、あるいは混合です。

ログからは切り分けられません（自信度: LOW）。 速度がQ4/Q5系（~119〜125）から一気に~56へ落ちている不連続さは、正直に言えば(c)の測定条件差を疑わせる挙動です。だから見出しは立てますが、「MTP版Q6_Kは10pt賢い」とは書きません。書けるのは「単発では10pt差がついた。原因は未特定。5runsと条件統一が要る」までです。

とはいえ「MTPの効果は量子化ごとに一様ではない」という点は、9B-v1で「量子化が高精度になるほどMTPの速度倍率が大きくなる」（Q4 +47% → BF16 +88%）という逆向きの非一様性を観測しているのと符合します。方向は違えど、MTPは全量子化に均等に効く機構ではないというのがQwythosファミリー2サイズ通しての実感です。

全滅タスク t046:6パターン全部が落とした壁

今回のログで、6パターン全てが失敗したタスクが2つあります。まずその筆頭から。

  • t046 [architect]「singleton and request lifetimes are not honored」

  • 標準版Q4/Q5/Q6、MTP版Q4/Q5/Q6の全6パターンで失敗（fail_reason は全て `tests failed`、combined 0.0）

（もう1本の全滅タスクは t059 [architect]「floating-point sum drifts from the true value」 です。こちらも6/6で失敗しています。後述の失敗タスク節でまとめて扱います。）

DIコンテナのライフタイム管理——シングルトンとリクエストスコープの区別が守られない、という類のタスクです。空出力やパース失敗ではなく全パターンで「テストが落ちた」、つまりモデルはちゃんとコードを書いて、書いたコードが揃って間違っていた。これは量子化やMTPの問題ではなく、モデルの理解そのものが届いていないシグナルだと読みます。

ここで系譜に接続しておきます。9B-v1の記事では、全10モデル中8つで失敗した鬼門として t037 [frontier]「DI singleton not cached」（DIシングルトンがキャッシュされない）を挙げました。t046とt037は別タスクなので同一問題として扱うことはできませんが、依存性注入まわりの複雑な状態管理という性質はよく似ています。9Bで転んだ場所と近い場所で、27Bもまだ転んでいる（自信度: MODERATE、タスクが別である以上これ以上は言えません）。

ちなみに標準版Q6_Kは、今回t037も落としています（6パターン中これ1つだけ）。t037のタイトルは「DI singletons are not cached」——9B-v1記事のt037「DI singleton not cached」とほぼ同一の文言です。タスクIDも一致しているため、同一タスクである可能性が高いとみます（自信度: HIGH）。9Bで8/10モデルが落とした問題を、27Bでも標準Q6_Kが引き続き落としている格好です。

もうひとつのシリーズ常連、t020 [hard]「calculator ignores precedence and parentheses」（電卓の演算子優先順位・括弧）。9B-v1の記事では「9/10モデルで失敗。このシリーズ全体の鬼門」と書きました。27Bでの結果は——

6パターン中2つが通しました。9B時代の「9/10で失敗」から見れば前進ですが、まだ4つが落としている。鬼門は27Bでも健在です。しかも1runなので、この✅がflakyの上側を引いただけの可能性は当然あります（9B-v2では同じt020を、MTP版Q6_Kが5回中1回だけ通しました）。

難易度別:差はほぼ全部 architect 帯で決まった

見てのとおりです。easy・medium・expert・frontierはほぼ全パターンが天井（easyは6パターン全て満点、frontierも6パターン中5つが8/8）。hardも8〜10/10のレンジに収まっています。6パターンの差は、ほぼまるごとarchitect帯（20問）で作られている——12/20から17/20まで、5問＝25ptの幅で散っています。

27Bクラスになると、40タスク版の難易度設計（easy〜frontier）はもう天井効果でほとんど分解能を持たない、ということです。9B-v2の記事では「easy〜mediumは全量子化で横並び（天井効果）、差はほぼfrontier帯で決まる」という状態でした。27Bではその天井がfrontierまで上がってしまい、代わりにarchitect帯が唯一の分解能になっています。architect 20問を足していなければ、この記事は「6パターン全部が横並び、差なし」で終わっていたわけです。

逆に言えば、今回の順位はarchitect 20問という細い土俵の上でだけ決まっているということでもあります。20問で5問差、しかも1run。これが揺れないと考える根拠は、正直ありません。

ひとつ面白い（そして不気味な）のは、総合最良のMTP-Q6_Kが唯一medium帯を落としている点です（t007、4/5）。architectを17/20取るモデルが、medium帯の1問を落とす。これはもう実力の話ではなく単発の揺れとして読むのが自然でしょう。順位表の頂点に立っているモデル自身が、単発データの信頼できなさを自白しているようなものです。

量子化ごとの失敗タスク

6パターン中4つ以上が落とした「壁」タスクを拾うと:

  • t046 [architect]「singleton and request lifetimes are not honored」（6/6失敗）— 前述の全滅タスク。

  • t059 [architect]「floating-point sum drifts from the true value」（6/6失敗）— 浮動小数点の総和が真値からずれる。t046と並ぶもう1本の全滅タスクで、こちらは古典的な数値誤差（Kahan和のような補正が要る）問題です。6パターンとも一度も通っていません。

  • t044 [architect]「plugin load order is fragile and cycles are undetected」（5/6失敗、MTP-Q6_Kのみ通過）

  • t043 [architect]「replay after a snapshot double-counts events」（4/6失敗）

  • t047 [architect]「failed migration leaves later ones marked applied」（4/6失敗）— 失敗したマイグレーションの後続が「適用済み」のまま残る問題。

  • t058 [architect]「only exact version matches work」（4/6失敗）— バージョン一致判定が完全一致しか許容しない問題。

  • t020 [hard]（4/6失敗）— 前述のシリーズ常連の鬼門。

全滅タスクが2本ともarchitect帯にあり、しかも性質がまるで違う（設計上の不変条件 と 数値の精度）のが今回の特徴です。27Bにスケールしても、この2種類は片方も崩せていません。

architect帯の壁は、DIライフタイム（t046）・浮動小数点誤差（t059）・プラグイン依存グラフ（t044）・イベントリプレイの冪等性（t043） に集中しています。どれも「関数1個の中の話ではなく、システムの不変条件を理解して直す」タイプの問題です。27Bになってhard/expert/frontierは天井に届いたのに、この層だけは別物として残っている。

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

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

自律率は39〜41/60（65〜68%）で6パターンほぼ横並びです（最高は標準Q5_K_Mの41/60）。差がつくのは🔴不可のほうで、MTP-Q6_Kの4/60（7%）から標準Q6_Kの10/60（17%）まで開いています。

実務的にはこう読めます。「そこそこのタスクをそのまま任せられる割合」は量子化を変えてもほぼ動かない。動くのは「絶対に任せられない地雷が何個あるか」のほう。 MTP-Q6_Kを選ぶ意味は「自律率が高いこと」ではなく「地雷が最も少ないこと」です——最悪の標準Q6_K（10/60）の半分以下、標準Q5_K_M（6/60）と比べても2問少ない。60タスク中4問しか🔴がないという比率（7%）は、9Bシリーズでは一度も見なかった水準です（9B-v1の単発計測では最良がMTP-Q8_0の6/40＝15%、9B-v2のMTP版5runsでは最良でも7/40＝17%）。

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

数字を並べる前に3点。

  1. MTP（投機的デコード）搭載版は構造的に速い数字が出ます。 先読みが当たるぶん速いだけで、賢さの証明ではありません。

  2. 今回はdense 27BのみでMoEとの比較はありません。MoEは活性化パラメータが小さいぶん速い数字が出る一方、denseの標準版は素直に遅い。9Bとの比較で27Bが遅いのも当然で、遅い＝劣っている、ではありません。

  3. 今回の値は単発実行時のみです。並列実行時の1ストリームtok/sは桁が変わります。9B-v2では同じMTP版で「1run時 ~177〜194」に対し「5runs時 ~62〜85」まで落ちており、あの記事でも原因は測定条件差の可能性として断定を避けています（自信度: LOW）。いずれにせよ、今回の数字を並列環境の目安に使わないでください。

その上で、今回はさらに割り引きが要ります。ハードウェアがログから確認できていない（推定）ため、この tok/s は他記事の tok/s と厳密には横並びにできません。 同一ログ内の6パターン相互比較としてだけ使ってください。

出力トークン数は1047〜1140とどのパターンもほぼ同じレンジで、「特定の量子化だけ冗長に喋って時間を食っている」わけではありません。速度差は純粋にデコード速度の差です。

そして繰り返しますが、今回いちばん賢かったMTP-Q6_Kが、いちばん遅い部類（~56.3）です。 tok/sと解決力が別の物差しであることの、これ以上ないほど分かりやすい実例になりました。

過去モデル（9B）との比較

同じempero-aiのQwythosファミリーなので、これまでの2本と並べます。ただし先に断っておくと、9Bと27Bはモデルサイズもタスク数（40問 vs 60問）も難易度構成（architect 20問の有無）も違うので、Resolved率の直接比較は成立しません。architect帯を含む60問のほうが明確に厳しい土俵です。数字そのものではなく、傾向を並べます。

傾向1: MTP-Q6_Kという当たりくじが、また出た

9B-v2で5runsを回して判明した真の王者はMTP版Q6_Kでした（平均成功率81.0%、pass@5は5量子化で唯一の100.0%、5回全滅タスクゼロ）。そして今回の27Bで単発トップに立ったのもMTP版Q6_Kです。

これは面白い一致ですが、一致以上のことを言うつもりはありません。9B-v2のQ6_Kは5runsで裏を取った結果、27B-v1のQ6_Kは単発の1回。「9Bで正しかったから27Bでも正しい」は成り立ちません。 ただ、次に5runsを回すときの第一候補がどれかは、これではっきりしました。

傾向2: 量子化ビット数と精度は、やはり単調増加しない

標準版だけ抜き出すと、今回はこうなっています。

Q5がピークで、ビットを上げたQ6で落ちる。中位量子化がスイートスポットになるという、この連載で何度も見てきた形です。

ここで9B-v1を思い出してください。あのときの標準版は Q4_K_MとBF16が82.5%で最良（Combined 76.0 / 76.5）、Q5_K_M 72.5%が最低で、Q5だけが落ち込む逆転でした。同じQwythosファミリー、同じ標準版、同じQ5_K_Mが、9Bでは谷、27Bでは山。向きが真逆です。

そして9B-v2の記事でも、標準版1runでQ5_K_Mが85.0%と最高に見えた件について、**「同じQ5が、単発計測というだけで最低にも最高にもなりうる」**と書いています。今回27Bの標準Q5_K_M 90.0%も、まったく同じ立場の数字です。だから「27Bの標準版はQ5がスイートスポット」とは書きません。書けるのは「単発ではQ5が最高だった」までです。

傾向3: そして最大の留保——今回は全部1runである

9B-v1で筆者は、単発の数字だけを見てMTP-Q8_0を「チャンピオン」に認定しました（Resolved 85.0% / Combined 78.1）。9B-v2で5runsを導入した結果どうなったか。同じMTP-Q8_0という構成が、1runスクリーニングでは87.5%を出しながら、5回平均では75.0%まで落ちました（9B-v2記事の計測）。+12.5ptの単発上振れです。代わりに王座に就いたのがMTP-Q6_Kでした。

9B-v2の記事で、筆者はこう書いています。

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

今回の27B記事は、その教訓が生まれた直後に、まったく同じ形の単発データで書かれています。

だから今回、MTP-Q6_Kを「チャンピオン」とは呼びません。呼べません。今回言えるのは「単発6パターンの計測では、MTP-Q6_Kが最も良い数字を出した」までです。9Bで実際に起きたことを27Bに当てはめれば、次のどれが起きてもおかしくありません。

  • MTP-Q6_Kの93.3%が、5runs平均では85%前後に沈む

  • 標準Q5_K_M（90.0%）が5runsでMTP-Q6_Kを逆転する（差は3.3ptしかない）

  • 今回同点だったMTP-Q4とMTP-Q5（ともに86.7%）が、5runsではっきり分かれる

次の宿題は明確です。上位3つ（MTP-Q6_K / 標準Q5_K_M / MTP-Q5_K_M）に絞って60タスク×5runsを回し、平均成功率とpass@5、そして5回全滅タスクの有無を取る。 加えて今回未検証のQ8_0も、9B-v2でMTP-Q8_0が+12.5ptの単発上振れを見せた前例がある以上、単発ではなく5runsの土俵で確認する価値があります。今回の1run 6パターンは、その本検証のためのスクリーニングだと位置づけるのが一番正直な扱いです。

まとめ:どれを選ぶか（すべて単発データ上での話）

  • 精度優先なら → MTP版 Q6_K。 Resolved 93.3%（56/60）、Combined 85.3、🔴不可はわずか4/60（7%）。ただし遅い（~56.3 tok/s）。そして単発の数字であることを忘れずに。

  • 速度と精度のバランスなら → MTP版 Q4_K_M。 86.7%（52/60）で~125.4 tok/sと6パターン中最速、平均レイテンシもMTP-Q5_K_Mと並んで最短の8.99秒。「速く・そこそこ正確に」ならこれ一択です。MTP-Q5_K_Mとは実質同性能（86.7%同点、Combined 79.9 vs 79.8）なので、サイズが小さいQ4のほうが得。

  • MTPを使わない構成なら → 標準版 Q5_K_M。 90.0%（54/60）/ Combined 82.8で標準版内トップ。ただし9B-v1で同じQ5が最低だった前例があるので、この90.0%は真に受けないこと。

  • 標準版 Q6_Kを選ぶ理由は、今回のデータ上ではありません。 83.3%で最下位、🔴不可10/60（17%）も最多、速度も~56.0で最遅。同じサイズを積むならMTP版Q6_Kのほうが良い、というのが今回の唯一はっきりした示唆です。

  • Q8_0 / BF16は未検証。 50GB級のBF16は現実的でないにせよ、Q8_0（26.63GB）は32GB環境なら射程内です。これも宿題。

この回で持ち帰る教訓を3つ。

  1. 「同じビット幅」は「同じ性能」ではない。 量子化を選ぶ前に、MTP版か標準版かを選べ。今回のQ6_K同士は10.0pt差がついた。量子化表だけ見て決めると、この差を丸ごと見落とす。

  2. 速くなったMTPが賢いとは限らないし、賢いMTPが速いとも限らない。 Q4/Q5では+81〜91%速くなったMTPが、Q6_Kでは+0.5%しか速くならず、そのQ6_Kが最も高いResolvedを出した。速度と解決力は独立した物差しという連載の主張が、今回は同一モデル内で示された。

  3. そして、これは全部1runの話である。 9B-v1で単発チャンピオンを立て、9B-v2で同じMTP-Q8_0構成が+12.5ptの単発上振れだったと判明した——その同じ轍を、今回は先回りして避けておく。27Bの真の序列は、5runsを回すまで確定しない。

27Bクラスになると easy〜frontier はほぼ天井で、勝負はarchitect帯に移りました。ベンチのほうが先に限界に来ている、というのが今回いちばんの発見かもしれません。次はarchitect帯を軸に、上位3構成の5runsで裏を取ります。

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

モデル情報

  • HuggingFace: https://huggingface.co/empero-ai/Qwythos-27B-v1-GGUF

  • ベース: `Qwen/Qwen3.5-27B`（27B、qwen35ハイブリッド密結合型／Gated-DeltaNet線形注意層と完全注意層の交互配置）／Qwythos-9Bの大規模版

  • ライセンス: Apache-2.0

  • 推奨サンプリング（モデルカード掲載値）: temp 0.6（エージェント用途）/ 1.0（推論・創作用途）、top_p 0.95 / top_k 20 / repeat_penalty 1.05 / max_new_tokens 16384以上

  • MTP: ネイティブMTPヘッドあり（標準版／MTP版の両GGUFあり）

  • 公称ベンチ値: なし（公式ページに「標準化された学術ベンチマークスイートは実施されていない」と明記）

関連記事

  • 9Bシリーズ第1弾: 「Qwen3.5ベースの9B推論モデル『Qwythos-9B-Claude-Mythos-5-1M』を40タスクで検証した（MTP比較あり）」（2026-06-23）

  • 9Bシリーズ第2弾: 「1runのチャンピオンは5runsのチャンピオンではなかった:Qwythos-9B-v2の新王者はMTP版Q6_K」（2026-07-11）

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

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

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