Resolved 90%だがQ6_Kが最下位: Qwimi-3.6-27B-Coder-MTPの量子化4種を60タスクで検証(Q4/Q5/Q6 5runs)
こんにちは、くーるぜろです。
今回の相手は `trjxter/Qwimi-3.6-27B-Coder-MTP-GGUF`。個人開発者のtrjxter氏(Rishi)が、Qwen3.6-27BをQLoRAでコーダー向けにSFTし、MTP(Multi-Token Prediction=投機的デコード)を冠して配布しているモデルだ。モデルカードは「コーディングでbase比+4pt」「処理時間はほぼ半減」と景気のいい数字を並べるが、作者の自作ベンチ・独自採点の値で、第三者のSWE-Bench風検証はほぼ見当たらない。ならば筆者のllmbenchで叩こう、というわけだ。
先に結論を言う。主力はQ5_K_M(19.5GB)、Resolved 91.7%で総合チャンピオン確定。 そしてこの記事の本題は量子化の序列そのものより、1runスクリーニングの序列が5runsで裏返ったことにある。1runで最下位だったQ6_Kは5runsで2位に浮上し、中位に見えたQ4_K_Mが最下位に落ちた。「1回の結果で語らない」——この連載で繰り返してきた原則の、これ以上ない実証になった。
このモデルの素性

GGUFサイズ(HF実測バイトからの10進GB):

素性で先に断っておきたい点が3つある。
1つ目、公称値の性格。 モデルカードは「自作ベンチでcoding +4.00pt、HumanEval 80.00%→94.29%」と主張するが、これは作者の独自ベンチ・独自採点の値だ(モデルカード掲載値、SWE-Bench・LiveCodeBenchは含まない)。しかもカード自身が正直で、エージェント系タスクではbase比-4.00ptと悪化を認めている。これらの公称値は素性の話に留め、実測表には一切混ぜない。
2つ目、コンテキスト長。 Qwimiのファインチューンは16,384トークンまでしか学習・検証されていない(ベースは26万トークン対応)。GGUFカードも「`--ctx-size`は最大16384に。それ以上は未検証」と明記する。長文で使うなら要注意だ。
3つ目、第三者検証の薄さ。 HF DiscussionsはGGUF版・BF16版ともに0件、ダウンロードは約3,000。RedditやXでの言及もない。第三者の検証は、確認できた範囲ではこの記事がほぼ初手だ。だからこそ数字は慎重に扱う。
検証環境
実行環境: llama.cpp(CUDAビルド)
ハードウェア: EVO-X2 + RTX5090 32GB
タスク数: 60問(easy 5 / medium 5 / hard 10 / expert 12 / frontier 8 / architect 20)
実行回数: 第1段=各タスク1回(スクリーニング) / 第2段=各タスク5回(pass@k・成功率を測定)
内容: Pythonのバグ修正・実装タスク(関数レベル、決定論的テスト付き)
サンプリング: (確認中)
評価軸: Resolved率 / 成功率(5回平均) / pass@k / Quality / Combined / usability
llmbenchはSWE-Bench風の自作ベンチだ。バグレポートとソースを渡し、patch適用→隠しpytest(モデルには非公開)でresolved判定する。Combinedは `success_rate ×(0.5 + 0.5 × quality/100)× 100`、動かないコードは0点。GitHubは `zephel01/swe-bench`(MIT)。
今回は2段階検証デザインをとった。4量子化を1runで回して全景をつかみ、そのうえでQ4_K_M/Q5_K_M/Q6_Kの3量子化を各60タスク×5runsで本検証した(Q8_0は5runs未実施。速度が他の半分で、29GBのVRAM占有がKVキャッシュを圧迫するため、筆者の判断で外した)。
第1段: 4量子化×1runスクリーニング

結論: 1run時点の序列はQ5(90.0%)> Q8(88.3%)> Q4(86.7%)> Q6(85.0%)。Q6_Kが最下位で、しかもmedium帯で唯一の失敗(t007)まで出していた。
この時点で筆者は「Q6_Kが最下位という怪。ビットを積んだのにQ4より低い逆転現象だ」と書きかけていた。だが1runは±3pt級の揺れが普通に起きる。だから第2段に進んだ——そして進んで正解だった。
第2段: Q4/Q5/Q6を60タスク×5runsで本検証

結論: Q5_K_MがResolved 91.7%・成功率87.7%・Combined 80.0の総合チャンピオン。2位は1runで最下位だったQ6_K。1runで中位だったQ4_K_Mが最下位に転落した。
この記事の目玉: 1runの序列は5runsでひっくり返った
並べてみると鮮やかだ。
1runの序列: Q5 > Q8 > Q4 > Q6(最下位)
5runsの序列: Q5 > Q6(2位に浮上) > Q4(最下位に転落)
Q6_Kは1runで「medium帯唯一の失敗(t007)」までやらかして最下位だった。ところが5runsでは成功率87.0%と、Q5(87.7%)に0.7pt差まで肉薄する。t007も5runsでは3/5で通っており、あの失敗はただの下振れだった。逆にQ4_K_Mは1runでは中位に見えたのに、5runsでは成功率でQ5/Q6に約5pt離され、🔴不可も11タスクと最多。
白状すると、筆者は第1段の時点で「Q6を選ぶ理由はない」「Q4で実用十分」という結論を書きかけていた。どちらも1runの見え方で、5runsで両方裏返った。単発スクリーニングは脱落候補を決める道具にはなるが、序列を確定する道具にはならない。 「1回の結果で語らない」を標榜する連載自身が危うく1runで語りかけた、という自戒込みの実証だ。
Q5 vs Q6: チャンピオンと名誉回復組の距離
Resolvedは91.7% vs 88.3%で3.4pt差だが、平均成功率は87.7% vs 87.0%の0.7pt差。±3pt圏内なので「成功率ではほぼ並ぶ」が正直な読みだ。Combinedも80.0 vs 79.8でほぼ同じ。QualityはむしろQ6が83.5で3量子化中最高だった(差は小さい)。
それでもQ5を主力に推すのは、細部が一貫してQ5に振れているからだ。pass@kは96.7% vs 95.0%、🔴不可は5 vs 7でQ5が最少。難易度別ではexpertでQ5 12/12 vs Q6 11/12、frontierでQ5 8/8 vs Q6 7/8。どれも僅差だが、全部Q5が上か同点。Q6は汚名を返上して精度ではほぼ並んだものの、+3GBのVRAMと速度低下に見合う上積みがない。
usability(🟢自律/🟡補助/🔴不可)の5runs内訳:

🟢の数だけならQ4/Q6が35で最多だが、Q4は🔴も11で最多。Q5は🟢32と控えめな代わりに「まったく任せられない」タスクが5つしかない。手に負えないタスクの少なさを取るなら、やはりQ5だ。
鬼門の更新: t020に風穴、完全な壁はt059だけ
5runsやり直し3本の共通失敗はt044(プラグインのロード順・循環検出)・t046(DIコンテナのライフタイム)・t047(失敗したマイグレーションの後続扱い)・t059(浮動小数点和の補償加算)。ただし中身を見ると濃淡がある。
全量子化で0/5、完全な壁はt059ただ1問。
t046はQ4だけ1/5で通した回があり、t047はQ4/Q5が1/5。たまに通るが安定しない。
t044は旧計測では通ったり落ちたりだったが、今回は3量子化とも1〜2/5で失敗扱い。
そしてニュースがひとつ。シリーズ常連の鬼門t020(電卓の演算子優先順位・括弧処理)に、Q6_Kが3/5で風穴を開けた。 歴代のローカルLLM検証で落ち続けてきたタスクが、初めて(部分的に)破られた。Q5は1/5、Q4は0/5なので量子化を選ぶし、3/5はflakyの域を出ないが、「絶対に通らない壁」ではなくなった。
前回の見立ての訂正: 「t021の怪」は再現しなかった
旧計測では、expert帯のt021(バンカーズ丸め)をQ5_K_Mだけが落とし続けるという不思議な現象があり、筆者は「量子化ノイズの当たりどころ」仮説(自信度LOW〜MODERATE)を立てていた。
やり直しの結果、この説は消えた。Q5は3/5で通るようになり、逆にQ4が2/5で落とし、Q6は4/5で通過。「Q5だけがt021に弱い」は再現せず、前回の見立ては取り下げる。
得られた教訓はこうだ。量子化×タスクの相性は、量子化間だけでなく同じ量子化のrun間でも揺れる。 特定の量子化が特定のタスクに弱い、と言うには5runsでも足りないことがある。1タスク単位の因果話は、この連載でも今後いっそう慎重に扱う。
tok/s: やり直しでは安定した
初回計測ではtok/sの中央値が計測回によって大きく振れ、速度序列を確定できなかった。やり直しの5runs 3本では素直に安定している。
Q4_K_M ~138.0 / Q5_K_M ~133.5 / Q6_K ~123.6 tok/s(中央値、3本とも120〜140帯で一貫)
サイズ順の順当な序列だ。注意書きを添えると、MTP(投機的デコード)搭載モデルは構造的に速い数字が出るのであって、賢さの証明ではない。そのうえで参考比較すると、筆者の過去実測(非MTPのQwen3.6-27B素モデル、同一ハード、llama-bench tg256)はQ4 ~75 / Q5 ~68 / Q6 ~60 tok/sだった。MTP版はおよそ2倍出ている。 測定方法が違うので参考値だが、MTPの加速は効いていると言っていい。Q8_0は第1段で~48.8と一貫して遅かった(5runs未実施)。これらは単発の1ストリームtok/sで、並列で回せばもっと下がる。
まとめ
Qwimi-3.6-27B-Coder-MTPの量子化を60タスク×5runs(Q4/Q5/Q6)で叩いた結論を、量子化ごとに1行ずつ言い切る。
Q5_K_M(19.54GB)= 主力確定。 Resolved 91.7%・成功率・Combined・🔴最少の総合トップ。迷ったらこれ。
Q6_K(22.43GB)= 名誉回復したが出番は薄い。 成功率はQ5と0.7pt差まで並んだが、+3GBと速度低下に見合う上積みがない。
Q4_K_M(16.81GB)= 今回は見劣り。 成功率82.7%・🔴11と離された。VRAMが本当に厳しいときの妥協枠(pass@k 96.7%はQ5と同着なので、リトライ前提なら届く)。
Q8_0(29.05GB)= 5runs未実施。 1runでは88.3%だったが速度~49 tok/sで他の約1/3。今回も選ぶ理由は見つからず。
今回の一番の学びは、量子化の優劣そのものより検証設計の話だった。1runの序列は5runsでひっくり返る。 Q6の最下位もQ4の実用十分も、1runが見せた幻だった。スクリーニングはあくまで入口で、序列は回数を重ねてから語る——連載の原則を、自分の書きかけ原稿ごとひっくり返される形で確認した。
t059を全量子化が落とし続ける件は、引き続き宿題にしておく。
検証で生成したコード・テスト結果はアーカイブ済みです。「特定タスクの詳細が見たい」「自分の環境でも試したい」はコメントへどうぞ。
モデル情報
HuggingFace: huggingface.co/trjxter/Qwimi-3.6-27B-Coder-MTP-GGUF
ベース: Qwen/Qwen3.6-27B(dense, 27.8B)。作者trjxter氏によるQLoRA SFT + MTP版(Qwen公式ではない)
ライセンス: Apache 2.0
推奨サンプリング: ベースモデルQwen3.6公式のコーディング推奨値 temp 0.6 / top_p 0.95(top_k 20 / min_p 0.0)。Qwimi側のカードに独自の推奨表はないため、ベースモデル公式推奨を採用
注意: ファインチューンは16Kコンテキストまでしか検証されていない(`--ctx-size`は最大16384推奨)
関連記事
【RTX 5090 実測】Qwen 9B・27B・35B MoE を全量子化で比較|ローカルLLM速度ガイド 2026 (note記事リンク)
#ローカルLLM #llamacpp #ベンチマーク #量子化 #GGUF #Qwimi #Qwen3 .6 #27B #MTP #RTX5090
いいなと思ったら応援しよう!
サーバー代とコーヒー代になります☕ 役に立ったら応援よろしくお願いします!