見出し画像

DeepSeek-V4-Pro-Qwen3.5 の 9B と 4B を 40タスク×5回×4量子化で殴り合わせた パラメータ2倍の差は、Combined 3.1pt しかなかった

zephel01

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

8月1日に Jackrong が DeepSeek-V4-Pro からの蒸留モデルを2本まとめて公開しました。9B と 4B、どちらも MTP 版の GGUF です。パラメータ数がちょうど倍違う同一パイプラインの兄弟モデルが同じ日に出てくるのは珍しいので、「9B を落として 4B で済ませられるのか」を確かめる絶好の素材だと思いました。

先に結論を書きます。筆者の実測では、ベスト構成同士の比較で 9B-Q4_K_M が Combined 71.5、4B-Q5_K_M が 68.4。差はわずか 3.1pt でした。 Resolved 率にいたっては 4B-Q8_0 が 80.0%(32/40) で 9B のベストと完全に並びます。ただし「5回中何回通るか」の平均成功率では 9B-Q4_K_M の 78.0% に対し 4B のベストは 74.5% で、安定性では 9B が上でした。

そして今回もまた、量子化ビットを上げれば良くなるという話にはなりませんでした。 9B は Q6_K で Resolved 65.0% まで崩れ、4B は逆に Q4_K_M で 62.5% まで落ちる。同じ学習フローの兄弟なのに、量子化カーブの形が正反対でした。

このモデルの素性

公称ベンチ値は以下です。すべてモデルカード掲載値で、筆者の実測ではありません。 後で出てくる実測の表とは分けて読んでください。

9B のカードには「Qwen3.5-9B 比で正答あたりトークン数 -36.1%、精度 +0.93pt」という主張もあります。この省トークン主張は今回の実測でどうなったか、後で速度の章で突き合わせます。

GGUF のファイルサイズ(HF 掲載値)。

なお両リポジトリとも `mmproj-F32.gguf`(マルチモーダル projector)を同梱していますが、4B だけ pipeline_tag が `image-text-to-text` で、9B は `text-generation`。ビジョン対応の扱いがリポジトリ間で揃っていません。今回は純粋なコード生成タスクなので projector は使っていません。

MTP について、カードには何も書かれていない

「MTP-GGUF」と名乗っているのに、両カードとも MTP の実行方法・draft ファイルの有無・推奨 draft 数の説明が一切ありません。 4B カードに「MTP-enabled Q8 GGUF build using two draft tokens under llama.cpp speculative decoding」という評価条件の記述があるだけです。

ファイル一覧を見るかぎり `mtp-*.gguf` のような独立した draft ファイルは両リポジトリに存在せず、MTP レイヤはメインの GGUF に同梱されている構成だと読めます(カードによる裏付けはなし・自信度 MODERATE)。今回は `--spec-type draft-mtp` を付けて起動し、正常に動作しました。

検証環境

  • 実行環境: llama.cpp(CUDAビルド、b10157-c6292cfb8)

  • ハードウェア: EVO-X2(AMD RYZEN AI MAX+ 395)+ RTX5090 32GB

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

  • 実行回数: 各タスク5回(pass@k・成功率を測定)

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

  • サンプリング: モデルカードに推奨値の記載がないため、llmbench の既定値を使用(複数試行時の sample_temp 0.8 / max_tokens 24576)。top_p・top_k は指定せず llama-server の既定

  • コンテキスト長: 16,384 tok / 並列スロット 1 / `-ngl 99` / batch 512 / threads 8

  • 投機デコード: `--spec-type draft-mtp`

  • 評価軸: Resolved率 / 成功率(5回平均) / pass@5 / 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 密度と保守性指標の重み付き合成です。GitHub: `zephel01/swe-bench`(MIT)、stdlib-only で再現可能。

先に土俵違いを割り引いておく

両モデルとも学習データにコーディングを含まないとカードに明記されています。 数学・STEM 推論に振ったモデルを、Python のバグ修正ベンチに投げているわけです。コーディング特化モデルより低く出るのは設計の差であって、モデルの優劣ではありません。この記事の数字は「数学蒸留モデルがコード修正をどこまでこなせるか」の実測であって、モデルカードの GSM8K/MMLU-Pro を否定するものではない、と先に書いておきます。

結果サマリ

8構成すべて 40タスク×5回、合計 1,600 試行の実測です。

tok/s は中央値。VRAM は llama-server プロセスの実測値です。

【図1: 8構成スコア比較】

結論: 総合チャンピオンは 9B-Q4_K_M(Combined 71.5)。だが 4B-Q5_K_M が 68.4 と 3.1pt 差まで迫り、VRAM は 4.4GB で済む。9B を積めないなら 4B-Q5_K_M で実用上ほとんど困らない。

Quality の列だけ見ると 4B-Q4_K_M が 85.2 で最高ですが、これは resolved したタスクだけの平均です。25問しか通っていないうちの平均なので、難しいタスクが母数から抜けた分だけ高く出ています。Quality 単体でモデルを比べてはいけません。

9B vs 4B:パラメータ2倍が効いたのはどこか

サマリだけ見ると「4B で十分」に見えますが、タスク単位で並べると差の出どころがはっきりします。9B の4量子化(計20試行)と 4B の4量子化(計20試行)で、通過数の差が4以上あったタスクだけ抜き出します。

9B が明確に勝っているのは、「仕様書を正確に読んで、書かれていない例外まで拾う」タイプのタスクです。RFC4180 のエスケープ規則(t025)、semver のプレリリース順序(t023)、べき乗の右結合(t032)、境界を含むか含まないか(t039)。どれも「知識としての仕様」を持っていないと解けません。パラメータ2倍分は、ここに効いていました(因果の推測・自信度 MODERATE)。

逆に 4B が勝っているタスクは、素直な実装ミスの修正が並びます。返り値の取り違え(t012)、状態の共有バグ(t003)、貪欲法の反例(t027)。ここでは 9B の優位が消えます。

t007 の逆転:9Bが 3/20、4Bが 13/20

いちばん奇妙なのが t007 です。「word_frequencies が Word と word を別の語として数えてしまう」という medium 帯のタスク。これを 9B は20試行中3回しか通せず、4B は13回通しています。9B の Q6_K と Q8_0 にいたっては 0/5、一度も通っていません。

ところが生成物を開くと、9B-Q6_K と 9B-Q8_0 の t007 はロジック以前の理由で落ちていました。インデントが1スペースに潰れ、`for` 直下のブロックが字下げされないまま出力されて IndentationError。 pytest が collect 段階で止まっています。書かれているロジック自体は `re.findall(r'\b\w+\b', text)` で語を拾って小文字化するという妥当なもので、字下げさえ正しければ通っていた可能性が高い(自信度 MODERATE)。

9B-Q4_K_M / Q5_K_M と 4B の4構成は、いずれも句読点を落として小文字化する妥当な実装で、保存分はすべて4テスト通過でした。t007 の 9B 側の低さは、少なくとも保存されている試行を見るかぎり「賢さ」の問題ではありません。

9B-Q6_Kが崩れた正体:インデントが1スペースに潰れる

t007 で見つけた現象は、t007 だけの話ではありませんでした。llmbench は各タスク1試行分の生成コードを artifacts に保存します。8構成それぞれ41ファイルを静的にチェックした結果がこれです。

Combined 最下位の 9B-Q6_K が8件で最多。Combined の上位にいる 9B-Q5_K_M と 4B-Q8_0 はゼロ。 順位と綺麗に対応しています。

9B-Q4_K_M が t024(TTLエントリが一瞬長く生きる)を 0/5 で落としているのも同じ理由でした。他の3量子化が 3〜5/5 で通しているタスクを Q4_K_M だけ全落ちしていたので不思議だったのですが、保存物は構文エラーでした。

「難しくて解けなかった」のではなく「書けたコードを正しい形で出せなかった」ぶんが、スコアに混ざっている。 llmbench は patch を適用して pytest を回すので、字下げが崩れれば内容がどれだけ正しくても0点です。

留保を3つ。artifacts は各タスク1試行分しか保存されないので、5試行すべての原因を代表するとは言えません。 また、この崩れが量子化そのものに由来するのか、サンプリング温度0.8のもとで起きた偶発なのかは、今回のデータでは分離できません。そして 9B-Q6_K の失敗は14問あるので、構文エラー5件だけで最下位を説明しきれるわけでもありません。ここは温度を変えた追試の宿題にします。

逆転現象:9BはQ6_Kで崩れ、4BはQ4_K_Mで崩れる

この記事のもうひとつの目玉です。量子化カーブの形が、9B と 4B で正反対でした。

9B は Q4_K_M が最高で、ビットを上げるほど下がり、Q6_K で底を打ってから Q8_0 で少し戻る。4B は Q4_K_M が最低で、Q5_K_M で跳ね上がり、あとは高止まりする。

【図2: 量子化カーブ】

9B-Q6_K の落ち込みは小さくありません。Resolved 65.0%(26/40)、成功率 65.0%、Combined 59.5 で、8構成中の最下位です。Q4_K_M より6問多く落としています。Q6_K だけが新たに落としたのは t003(easy)・t010・t021・t022・t027・t030・t035・t036 の8問で、帯域を問わず散っています(かわりに t024・t029 は回復)。easy 帯の t003 が 4/5 → 2/5 に落ちているのは象徴的です。

4B 側の Q4_K_M も同様に全帯域で崩れます。medium が 2/5、expert が 8/12、frontier が 3/8。しかも総生成トークン数が 136,073 と8構成中で最多(9B-Q4_K_M は 82,684)。1.6倍のトークンを吐いて成績は最下位という、いちばん割に合わない構成でした。

5runs 平均なので、9B の Q4 と Q6 の差(平均成功率で 13.0pt)は単発の運では説明できません。原因の一端は次章で見つかりましたが、それだけで全部は説明できませんでした。

言えるのは運用上の結論です。このモデルファミリーで「とりあえず高いビットを選んでおく」は損をする。 9B なら Q4_K_M、4B なら Q5_K_M。それぞれ最小サイズに近いほうが最良でした。

量子化ごとの失敗タスク

過半数(3/5以上)通らなかったタスクを resolved=False として列挙します。

8構成すべてで落ちたのは t020・t033・t037 の3問。 t034 も resolved を取れたのは 4B-Q8_0(3/5)だけで、残り7構成は resolved=False。40試行のうち通ったのは 9B-Q4_K_M と 4B-Q5_K_M の各1回を足しても5回です。

失敗の内訳を見ておくと、1,600試行のうち「テスト不合格」が 443、「patch のパースに失敗」が 21(内訳はファイルブロック未検出が20、不正パスが1)、タイムアウトが 2 でした。空出力で死んでいるわけではありません。 先日検証した Agents-A1 の 4B バリアントは出力上限 24576 トークンに達して空振りする現象で 14〜18問を落としていましたが、今回の 4B にはそれがなく、素直にテストを落としています。同じ「4B が低い」でも、中身がまったく違います。

鬼門の系譜:t020 は 40試行中 2回しか通らなかった

t020「電卓が演算子の優先順位とカッコを無視する」は、この連載を通しての鬼門です。過去記事では「9/10モデルで失敗、このシリーズ全体の鬼門」と書きました。今回もその評価は動きません。

8構成×5回=40試行のうち、t020 が通ったのは 2回だけ(4B-Q6_K と 4B-Q8_0 で各1回)。9B は4量子化20試行すべて全滅です。

同様に長く落ち続けているタスクを並べます。

【図4: 鬼門タスク】

一方で、t019(trie が接頭辞を登録語として扱う)は過去記事で「全モデル 10/10 通過」の安定タスクだったのに、今回は 9B が 20試行中7回、4B が10回しか通していません。 鬼門が増えたのか、このモデルファミリー固有の穴なのかは、他モデルの追試を待つ必要があります(自信度 LOW)。

逆に、8構成×5回=40試行すべてで通ったタスクは t001・t009・t028 の3問だけでした。

難易度別の分解

resolved(過半数通過)の件数です。

平均成功率(%)で見ると分解がもう少しはっきりします。

【図3: 難易度別 平均成功率】

easy 帯は 4B のほうが強いです(Q5_K_M と Q6_K は 100%)。天井効果で easy はもう情報を持っていません。 差がつくのは expert と frontier で、そこでは 9B-Q4_K_M が 77 / 65 と最良。9B のパラメータ分は、素直に上位帯に出ています。

easy 5問を回す意味が薄いので、このファミリーの追試は easy を削って architect 20問を足した60問版で回します。 上位帯の序列がもう少しはっきりするはずです。

hard 帯で 4B-Q6_K が 88% と全構成中トップに出ているのは意外でした。ただし同じ Q6_K が frontier では 38% と最下位タイなので、hard の 88% は帯域内の得意タスク配置に助けられた可能性が高いと見ています(自信度 MODERATE)。

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

「5回のうち1回でも通ったか」= pass@5(≥1成功)の列を見ると、8構成の幅は 87.5%〜95.0% しかありません。再試行を許すなら、どの構成もだいたい同じところまで到達できる。 差が出るのは「1回で通る確率」のほうです。

この「差」の列が、そのまま再試行への依存度です。4B-Q4_K_M は 27.5pt。1回投げただけでは6割しか当たらないのに、5回投げれば9割に届く。運用としては「必ず回して確かめる」前提でしか使えません。9B-Q4_K_M の 17.0pt が最小で、いちばん一発勝負に耐えます。

なお サンプリング温度 0.8 で5回回しているので、この揺れの大部分は温度由来です。温度を下げれば成功率と pass@5 は近づきますが、代わりに「5回のうち1回だけ当たる」ような当たりも消えます。一発勝負で投げる用途なら、温度を下げて成功率側を上げる価値があります。

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

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

Combined の順位とほぼ揃いますが、ひとつだけ読み方が違うのが 4B-Q8_0 です。🔴不可は 8/40 で 9B-Q4_K_M と同数、つまり**「まったく任せられない領域」は 9B のベストと同じ広さ**。ただし 🟢自律が 13 しかなく、🟡補助が 19 と最多。レビューさえ回すなら守備範囲は広いが、放っておける仕事は少ない構成です。

実務的には、上位4構成に共通する「40問中 8〜9問が 🔴不可」というのが「常用枠に置くならレビュー前提」のラインです。9B-Q4_K_M の 🟢自律 42% でも、半分以上は人間が見る必要があります。

速度:4Bは9Bの約1.3倍。ただしMTPの下駄を割り引く

tok/s は中央値、単発実行(並列スロット1)の値です。並列実行時の1ストリーム tok/s は桁が変わるので、この数字を並列環境の見積もりに使わないでください。

読み方の注意を3点。

  1. この8構成はすべて MTP(投機的デコード)有効です。 MTP 搭載モデルは構造的に速い数字が出ます。tok/s 400超は「賢さ」ではなく実装の差です。

  2. MoE ではなく Qwen3.5 系のハイブリッド構成なので、MoE の「活性化パラメータが小さいから速い」バイアスとはまた別種の下駄です。

  3. dense の標準版を同条件で測っていないので、MTP がどれだけ稼いでいるかは今回のデータでは分離できません。 標準版 GGUF が公開されたら追試します。

そして、tok/s が速いことと仕事が早く終わることは別です。4B-Q4_K_M は tok/s が 420 と 9B-Q4_K_M の 1.28倍ですが、平均レイテンシは 9.6秒 対 8.3秒で4Bのほうが遅い。1.6倍のトークンを吐いているからです。

ここでモデルカードの主張に戻ります。9B カードには「Qwen3.5-9B 比で正答あたりトークン数 -36.1%」という省トークン主張がありました。**今回の実測では、少なくとも兄弟の 4B に対しては 9B のほうが明確に省トークンです。**9B-Q4_K_M は 4B-Q4_K_M の 61% のトークンで、より多く解いています。省トークン主張の比較対象は Qwen3.5-9B であって 4B ではないので直接の検証にはなりませんが、方向としてはカードの主張と矛盾しません。

まとめ:結局どれを選ぶか

  • 9B Q4_K_M: Resolved 80.0%(32/40)、成功率 78.0%、Combined 71.5、VRAM 6.4GB、~327 tok/s。全指標でトップかトップ同着。このファミリーを使うなら第一候補。 8GB VRAM に載るのも効く

  • 4B Q5_K_M: Resolved 77.5%、成功率 74.5%、Combined 68.4、VRAM 4.4GB、~425 tok/s。9Bとの差は Combined で 3.1pt。VRAM は 2GB 少なく、速度は 1.3倍。 6GB クラスのGPUや、常駐させたい用途ならこちら

  • 4B Q8_0: Resolved は 80.0% で 9B のベストと同着だが、成功率 71.0% と再現性で劣る。🟡補助が 19/40 と最多。レビュー前提の運用なら選ぶ理由があるが、VRAM 5.8GB を払うなら 4B-Q5_K_M で足りる

  • 9B Q6_K: Combined 59.5 で 8構成中の最下位。選ぶ理由が見当たらない

  • 4B Q4_K_M: Combined 57.8、トークン消費は最多。速度も 4B 内で最速ではない。積極的に選ぶ場面がない

今回の教訓を3つ書いておきます。

ひとつ。同じ学習フローの兄弟モデルでも、量子化の最適点は継承されない。 9B は Q4_K_M、4B は Q5_K_M。「このシリーズは Q5 が鉄板」のようなモデルファミリー単位の一般化は、少なくともこのファミリーでは成立しませんでした。サイズごとに測り直すしかありません。

ふたつ。パラメータ2倍は上位帯にしか効かない。 easy 帯は 4B のほうが上(100% 対 92%)で、差がつくのは expert と frontier。しかも RFC4180 のエスケープ規則や semver のプレリリース順序のような「知識としての仕様」を要求するタスクに集中していました。モデル選定は、パラメータ数ではなくタスクの性格から逆算するほうが早いです。

みっつ。スコアの一部は「賢さ」ではなく出力フォーマットの崩れだった。 9B-Q6_K は保存された41ファイル中8件でインデントが1スペースに潰れ、5件が構文エラーで0点になっていました。中身が正しくても字下げが崩れれば pytest は通りません。ベンチのスコアを見るときは「解けなかった」と「出せなかった」を分けて数えないと、モデルの実力を見誤ります。

最後にもう一度。9B が載る環境なら Q4_K_M(Combined 71.5)を選び、載らないなら 4B-Q5_K_M(68.4、VRAM 4.4GB)で十分戦えます。高いビットを選ぶ理由は、このファミリーには見当たりませんでした。

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

モデル情報

関連記事

  • Agents-A1:無印Q4_K_Mは2回とも92.5%、4Bバリアントは40問中14〜18問が「空出力」で死ぬ(2026-07-28)

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

  • 2026年7月ローカルLLMベンチまとめ(2026-07-25)

  • くーるぜろの記事一覧: https://note.com/zephel01

#ローカルLLM #llamacpp #ベンチマーク #量子化 #GGUF #DeepSeekV4Pro #Qwen35 #MTP #9B #4B #passk #コーディングモデル

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

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