【2026年7月版】ローカルLLMベンチ総まとめ — 天井のベンチを16問に作り直した月。60問ではMoEが初めてdenseを抜き、選ぶ軸は「誰の量子化か」に移った

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

7月はベンチの天井側そのものを作り直した月でした（6月版v2の続きです）。結論を1行で。

7月はベンチの天井側（L7）を40問から16問に作り直した月。60問のはしごではMoE（gemma-4-26B-A4B）が初めてdense 31Bを抜き、9Bは「オーケストレータなら足りる」と実測で示され、モデル選びの軸はサイズより"用途と、誰の量子化か"に移った。

最初に約束：この記事は「3本のはしご」を混ぜません

llmbench には目的の違うタスクセットが3つあります。同じ表に混ぜません。

L7の数字は独立した章に隔離し、60問ランキングには入れません。「ローカル35BがClaude Opus 5に迫った」式の、はしごをまたぐ比較も作らない。各スコアには「40問」「60問」「L7 v2 16問」を必ず添えます。

ベンチを作り直した理由：「ベンチ側が仕事をしていない」

7/21、L7 v1（40問、t061〜t100）で上位クラウド勢を回したら**上位ライン2モデルが92〜97%に固まりました。**1問違いで序列が入れ替わる。難問の絶対数が足りていない。

そこで台帳を入れ替えました。現行 L7 v2 = 16問（v1残留9問 t063/t064/t068/t069/t076/t085/t092/t093/t095 ＋ 新規7問 t101〜t107、全問 grandmaster。旧40問は `tasks_l7_v1.jsonl` に歴史保存）。設計3原則は①3多重oracle（部分点なし＝t101/t102）、②暗黙契約test（signature・frozen・shallow copyをテストだけでロック＝t103/t105）、③runs=1の補償にQualityとCombinedを併記。結果、Resolved 75%で並んだ3モデルがCombinedでは68.4 / 66.2 / 62.9と段差を作りました。

**v1とv2の数字は直接比較できません。**接続できるのは「v1では92〜97%に張り付いていた」という定性的事実までです。

検証環境

• 実行環境: llama.cpp（CUDAビルド）。一部 vLLM（NVFP4）、Ollama（E2E）、OpenAI互換API＋Claude Code CLI（クラウド勢）

• ハードウェア: EVO-X2 + RTX5090 32GB。記載を取れていない検証は本文で明記

• タスク数: 40問（easy 5 / medium 5 / hard 10 / expert 12 / frontier 8）／ 60問（40問 ＋ architect 20）／ L7 v2 16問（全問 grandmaster）

• 実行回数: 1run または5runs。表ごとに明記。1runの表では±3pt程度（1〜2問）の差で優劣を断定しません

• 内容: Pythonのバグ修正・実装。patch適用 → 隠しpytest（LLMには非公開）で resolved 判定

• サンプリング: 公式推奨値（Ornith系 temp 0.6 / top_p 0.95 / top_k 20、クラウド勢 temperature 0.2 / max_tokens 24576）

• 評価軸: Resolved率 / 成功率（5回平均）/ pass@k / Quality / Combined = success_rate ×（0.5 + 0.5 × quality/100）× 100 / usability（🟢自律・🟡補助・🔴不可）

60問ランキング：MoEが初めてdenseを抜いた

architect帯20問込み、ローカル勢の本番です。

結論: 60問の首位は gemma-4-26B-A4B-it UD-Q5_K_M（98.3%・architect 19/20）で、今月ついにMoEがdense 31B（96.7%・18/20）を上回った。ただし1問差の1runなので「MoEの圧勝」とは書かない。5runsで裏取りできている本命は Qwimi-3.6-27B-Coder-MTP Q5_K_M（91.7%・pass@5 96.7%・Combined 80.0）のほう。

gemma-4-26B-A4Bは4量子化すべてでdense 31Bを上回り、速度も約3倍。6月版の「速いMoEは設計レベルでdenseに届かない」が反転しました。ただし**「毎回これくらい出る」と読めるのはQwimiの行だけ**で、上位の98.3%も96.7%も1runです。

満点の賞味期限が同日に切れた話も。 Ornith-1.0-35B（unsloth版）UD-Q5_K_Mは40問でOrnith初の40/40満点を出したのに、同じ日の60問追試でt021を落として崩れました（54/60＝90.0%）。**1回成功と、安定して解けるは別物。**40問で🔴不可0だった同じ構成も、architect帯を足すと🟢39/🟡15/🔴6。🔴不可ゼロは土俵の高さが決めていたわけです。

軽量勢は40問のはしご。**上の表と混ぜないでください。**到達点はOrnith-1.0-9B（unsloth版）UD-Q8_K_XLの95.0%（1run）。※Qwythos-9B-Claude-Mythos-5-1M v3（7/01、MTP-Q6_Kで40問82%）と Qwythos-9B-v2（7/11）は別モデルなので、毎回フルネームで書きます。

用途別の選び方：どのモデルの、どの量子化を、なぜ推すか

ここが今月の主軸です。自分の用途から引ける形にしました。

① メインのコーディング（精度最優先）

VRAM 24〜32GB級の第一推奨は gemma-4-26B-A4B-it UD-Q5_K_M（21.15GB）。dense 31B Q4_K_M（18.32GB・96.7%・~63.8 tok/s）をあえて選ぶ理由は、速度が3倍違う以上このベンチの範囲では見当たりません。

「毎回きちんと出てほしい」なら Qwimi-3.6-27B-Coder-MTP Q5_K_M（19.54GB）。 60問×5runsで成功率87.7%・pass@5 96.7%・🔴不可5/60。単発の98.3%より5runsの91.7%のほうが実務では信用できると思っています（`--ctx-size` は検証済みの16384まで）。

中間なら ThinkingCap-Qwen3.6-27B Q4_K_M（60問90.0%・architect 16/20・15.7GB・1run）。Q8_0（27.1GB）との品質差は誤差範囲で速度はQ4が約1.5倍、Q8_0を選ぶ理由は薄い。16GB機なら gemma-4-12B-coder-fable5 Q6（40問92.5%・9.11GB・111 tok/s、1run）。実効メモリ6〜8GBの報告（確度MODERATE-HIGH）に加え、7B・Q4は1kトークンあたり約0.5GBのKVキャッシュが要ります。

② オーケストレータ／ルーティング（判断・Task呼び出し・転記）

**9Bで足ります。**CodeRouterのmainを差し替えたE2Eテスト12項目の結果がこれ。

30Bより9Bのほうが速くて全通過。9Bが全19リクエスト（1件あたり入力3.4万〜3.7万トークン）を単独処理しました。仕事は判断とTask呼び出しと転記だけで、本体は外部エージェントが担うから足りたわけです。条件は2つ。`ollama show` の Capabilities に `tools` があるか確認（ベンチスコアとオーケストレータ適性は別物）と、実機E2E疎通（30B構成のFAILは「no agent named 'ext-codex' is reachable」というモデルの誤申告）。**「9Bで何でもできる」ではありません。**n=1で統計もまだない。

この9Bの地力は40問で公式GGUF Q4_K_Mが87.5%（35/40）・199.6 tok/s、unsloth版Q4_K_Mが90.0%（36/40）・~198 tok/s（どちらも1run）。よく見る「Ornith 87.5〜90%・約200 tok/s」はそのまま使えません。87.5%はQ4（199.6 tok/s）、90.0%はQ6（167.5 tok/s）かBF16（88.3 tok/s）で、2つを同時に満たす単一構成が一次表に存在しない。引くときはQ4かQ6を明示してください。

③ 超軽量・Tool Call枠／省メモリ

Tool Callの安定性最優先なら Qwen3-4B-Instruct-2507。 Q4で約3GB、262kコンテキスト、Apache 2.0。BFCL-v3 71.2% は**モデルカード掲載値（公称・一次確認済み・確度HIGH）**で、筆者のllmbenchでは未実測。実測表には混ぜません。

実測した4B枠の本命は Parable-Qwen3-4B-Claude-Fable-5 の Q4_K_M。 40問×5runsでResolved 65.0%（26/40）・成功率69.0%・pass@5 82.5%・Combined 63.7・2.5GB。pass@5（地力77.5〜90%）とResolved多数決（実務信頼性60〜65%）には約20ptの谷があるので混同しないこと。

④ ここぞの重い仕事（設計・難バグ・全体の判断）

外部エージェントbackend経由のClaudeに投げる。 7/10にCodeRouterへ `claude -p` を1プロバイダとして登録したのが今月の構造的な変化で、これが次章のClaude Opus 5実測につながりました。

• 日常編集・説明・軽いリファクタ → ローカル 7〜9B

• そこそこ頭を使うQ&A・中規模の実装 → `claude-agent` + `model: sonnet`

• 設計・難バグ・全体の判断 → `claude-agent` + `model: opus`（別 profile）

注意は2つ。サブスクOAuthなので従量課金はゼロですが、5時間窓のレート枠は確実に食います（`1+1は?` の4文字でも prompt_tokens 25,657）。「請求ゼロ」と「無料」は違う。そしてbackendはclaudeのみ実装済みです。

番外：極小・特化モデルの現在地

実用閾値に届いていないものは正直に書きます。すべて40問のはしごです。

この5本は汎用コーディングの主力になりません。ただし全部が「弱いモデル」ではない。 MiniCPM5-1Bは27Bの代替として作られていないエッジ向けの1B、Dolphin3-Cyber-8Bの本領はOWASP / MITRE / CVE系です。**同じGemma-4-12B派生でも「gemma-4-12B-coder」は同条件で85.0%**なので、Grug-12Bの45.0%は地力よりチューンの方向の差でしょう（自信度MODERATE）。

天井のはしご：L7 v2 16問（ここは60問と完全に別物）

この章の数字は上のランキングと土俵が違います。 L7 v2はgrandmaster単一帯の16問＝「天井を破るための帯」で、実務投入ラインのexpert帯とは目的が別。そして**今月ローカルGGUFモデルのL7スコアは1本も存在しません。**回したのはクラウドAPIとCLIエージェントだけで、「ローカル勢がL7でどこまで届くか」はこの記事では答えられません。

※ 全実行1run。Opus 5以外はOpenAI互換API。Qualityはresolvedしたタスクだけの平均で分母が違います（Opus 5=14問、preview=8問）。previewのt064/t093/t095は600秒timeoutで生成に到達しておらず、到達分だけなら 8/13 = 61.5%。

結論: L7 v2 16問の最高スコアは Claude Opus 5 の87.5%（14/16）。ただし1runで、しかもOpus 5だけがエージェント製品（Claude Code CLI）経由。「最高スコアだった」とは言えても「Opus 5のほうが強い」とは断定しない。

留保が3つ。①土俵が揃っていない — Opus 5は「エージェント製品（CLI＋モデル）」、他は素のモデルの1発生成。temperatureもOpus 5だけ制御不可。②87.5%も1run — 2位グループ（75.0%）との2問差（12.5pt）は、同種の実行で観測された振れ幅（約2問ぶん）と同じ大きさ。③「25pt差」の最下位50.0%はtimeout由来で、土俵違いとして割り引くべき数字です。

全員が落とした t101 と t105

• t101（Log rotator、3多重oracle）: 9実行すべて失敗。Opus 5は3つのバグを正しく診断しながら戻り値の型を変えて1問落とし、glm-5.2もgemini-3.6-flashも行番号まで同一のTypeError。「症状が直っている」と「契約が守られている」は別物です

• t105（schema migration、暗黙契約）: 同じく9実行すべて失敗。ただし2つの不変条件がissue.mdに書かれておらず、問題側の情報不足の色が濃い。次のv2改訂で改修します（ベンチは評価対象であると同時に改修対象）

• t103: 9実行中Opus 5のみ突破。他2実行は `tests/test_bug.py:56` の同一テスト・同一行で落ちており、差は「賢さ」より規律（自信度MODERATE）

おまけにOpus 5が落とした2問のコードのほうが保守性指数が高い（MI=80と95）。「品質が高い」と「正しい」は別の軸です。

データ自体の不確かさも。7/25の記事は `qwen-coding #1〜 #4` を「同一モデルを同一設定で4回」として扱っていますが、その4本の数値は7/21記事の別々の4モデルと完全に一致します。再実行と読める記録がある一方でモデル同定に疑いが残るため、「同一モデル4回で13.5pt振れた」は断定して引用しません。`gemini-3.1-pro-preview` の0.0%も全16問429で生成に到達しておらず除外。極端な数字を見たらartifactsを開くこと。

量子化の鉄則：今月から「誰の量子化か」まで見る話になった

定番は「ビットを上げれば精度が上がる、は成立しない。中位のQ5_K_M / Q6_Kが最良になりやすい」。ここに1行足すことになりました。40問・1run・同一ハードでの、同じ Ornith-1.0-9B です。

**公式GGUFはQ6_Kが山（連載定番の「中位が山」）。unsloth版はQ5/Q6が谷で、Q8系が山。**同じモデル・同じ40問・同じ環境で序列が反転しました。

結論: 「中位のQ5_K_M / Q6_Kが最良になりやすい」という経験則は維持する。ただし今月からは"どの量子化か"だけでなく"誰の量子化か"まで書かないと、他人が再現できない。Ornithは公式版とunsloth版を別物として扱うのが安全。

**ただし全部1runです。Q6の-7.5ptは3問、Q5の-5.0ptは2問ぶん。単発は+10pt級の上振れが起きるので、「unsloth版のQ5/Q6が公式より劣化した」とは言い切れません。**UDのimatrixやチャットテンプレート修正（7/18）が原因、とも断定しません（自信度MODERATE）。なお UD-Q8_K_XLは「精度は出るが速度を捨てる」ポジション（9B最高精度なのに ~66 tok/s）です。

逆に作り手の差が消えた例も。Parable-Qwen3-4Bを2つの作り手で40問×5runs比べたら同一量子化の差は最大2.5pt＝実質同等。「誰の量子化か」が効くかどうかも、5runsで測らないと分からない。

今月の他の逆転例

• gemma-4-26B-A4B（60問1run）: Q5（98.3%）→ Q6（95.0%↓） → Q8（98.3%）の中位谷。dense 31B側も最高ビットのQ6_Kが最下位（93.3%）

• Qwythos-9B-v2 MTP版（40問）: 1runチャンピオンのQ8_0（87.5%）が5runs平均75.0%まで失速し、Q6_Kが81.0%・pass@5 100%に伸びて序列が逆転

• Qwimi（60問）: 1run序列（Q5 > Q8 > Q4 > Q6が最下位）が5runsで裏返り、Q6_Kが2位・Q4が最下位へ

• Dolphin3-Cyber-8B（40問1run）: F16（35.0%）をQ8_0（40.0%）が上回る。意味のある差はQ4→Q3の崩落（35.0%→22.5%）だけ

**量子化を1行で。**60問の精度なら gemma-4-26B-A4B UD-Q5_K_M、再現性なら Qwimi Q5_K_M、9Bは速度なら Q4_K_M・バッチなら UD-Q8_K_XL、4B枠は Parable-Qwen3-4B Q4_K_M。選ぶ理由がないのは9Bの中位、ThinkingCapのQ8_0、Q3以下の低bit。

速度の読み方：tok/s は賢さの指標ではない

3点セットで読みます。
①MTP搭載モデルは投機的デコードで構造的に速い——Fable-Fusionは標準Q5_K_M ~58.6 → MTP Q5_K_M ~109.5 の1.7〜1.9倍ですが、精度差+3.3ptは1runでは運の範囲。
②MoEは活性化パラメータが小さいので速い——gemma-4-26B-A4B（~188.4）はdense 31B（~63.8）の約3倍、Ornith-1.0-35B MoE（~235〜243）は9B dense（~144〜198）より速い。
③dense標準版は素直に遅い（遅い＝劣っている、ではない）。

逆向きの実例も出ました。Dolphin3-Cyber-8Bは最速Q3_K_M（~260.6）がResolved最低（22.5%）、Ornith-1.0-9Bは最遅UD-Q8_K_XL（~66）が40問95.0%。単発と並列実行の1ストリームtok/sも桁違いです（Parable-Qwen3-4Bの ~113〜192 は5スロット同時実行時）。

DSpark：軽いドラフターのほうが速い

Ternary-Bonsai-27B-Q2_0（三値量子化、本体7.17GB）を固定し、ドラフターだけ3系統比べました（60問・1run）。

本体とほぼ同サイズのbf16より、軽いQ4_1（1.95GB）のほうが速い（HF公称「H100で1.34x」超えだが自信度MODERATE）。解決力はほぼ動かないので（47 / 50 / 47、+3件は運の範囲）、投機は速度のために入れる。解決力を上げたいなら本体を上げる。

ハードウェア差と、設定の罠

同一モデル（Qwopus3.6-27B-v2-Q4_K_M）・同一40問・各1runでGPUだけ変えると、RTX 3090（USB4 eGPU）が95.0%（38/40）・tok/s中央値38.75・合計latency 1,037.69秒、RTX 5090（OCuLink eGPU）が97.5%（39/40）・71.95・566.31秒。平均tok/s比 1.850倍、効くのは主に速度でスコア差は実質1タスク分（t021のみ）です。

**設定の罠もひとつ。**gemma-4を当初ctx4096で回したら空出力が多発してResolved 62.5%まで落ち、「gemma-4は弱い」と誤診しかけました。ctx32768で93.3%に回復。スコアが低いときはモデルより先に自分の設定を疑う。

鬼門タスク

L7 v2の天井は前章のt101・t105。60問の壁はarchitect帯（t041〜t060）に集中しています。

• t046（DIのライフタイム）: gemma-4 7量子化すべて全滅、Qwimi・Ternary-Bonsai・Ornith-35B unsloth・Fable-Fusionも全滅。パッチは書けるのに隠しテストを一度も通せない構造的な壁

• t059（浮動小数点合計のドリフト）: Qwimiで全量子化 0/5 の唯一の完全な壁。Fable-Fusion・Ternary-Bonsai・ThinkingCapでも全滅で、6月から続く「真の天井」

• t047・t044: 上記4モデルで共通失敗。Ornith-NVFP4はt047が5回とも0/5

• t057: dense 31Bが3量子化すべて全滅、MoE 26B-A4Bは4量子化すべて通過（系統差）

40問の最古参 t020（電卓：演算子優先順位・括弧）も現役。Ornith-1.0-9B unsloth版は8量子化すべて失敗、Parable-Qwen3-4Bは50回中0成功。一方 Ornith-1.0-35B unsloth版は2量子化とも通過、QwimiのQ6_Kが3/5で風穴を開けています。

t021（バンカーズ丸め）には今月2つの説明が付いたので、根拠を分けます。7/10の3090 vs 5090比較では同一設定で3090が失敗（completion_tokens 1,162）・5090が成功（1,715生成）し、非決定論的生成の影響と推測（この解釈のみ推測で、数値は実データ）。7/19のOrnith-1.0-35B unsloth版は40問で通過したのに同日の60問追試で同じ設定のまま失敗。別の要因なので、まとめて語らないほうが安全です。

**frontier帯は規模で綺麗に割れました。**ThinkingCap-Qwen3.6-27Bは全4runで8/8完答（シリーズ初）、Ornith-35B-AEON-NVFP4も60問5runsで8/8。一方Mythos-nano（3B）とMiniCPM5-1Bは全量子化0/8です。

まとめ：7月の地図

はしごごとに1行で。40問はOrnith-1.0-35B unsloth版が満点を出して同日に崩した月。60問はMoEが初めてdenseを抜いた月。L7 v2 16問は天井だけを測る別セットで、ローカル勢の測定は1本もなし、t101・t105が9実行全滅のまま残りました。

一枚に畳むと——**天井のベンチは16問に作り直され、そこではまだ2問が誰にも解けていない。60問ではMoEが初めてdenseを抜いたが1問差で、5runsまで踏んだ本命は91.7%。9Bは「役割を限れば足りる」と実測で示され、量子化は"どのビットか"より"誰が作ったか"で序列が変わった。**サイズでもビット数でもなく、用途と配布元が今月の選択軸でした。サイズでもビット数でもなく、用途と配布元が今月の選択軸でした。

来月の宿題。ローカル勢のL7測定はゼロなので同じ16問に通すこと。60問の5runs追試（首位のgemma-4-26B-A4Bも31BもOrnith-35B unsloth版も全部1run）。Opus 5の5runs再検証とcodex-sub / grok-subの追加、t105のissue見直し。そして日本語性能は完全に未実測——llmbenchは英語タスクのみなので、ここは正直に「未実測」と書き続けます。

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

検証環境: llama.cpp（CUDAビルド）／ EVO-X2 + RTX5090 32GB ／ 2026年7月（一部 vLLM・Ollama・OpenAI互換API・Claude Code CLI）

使用ベンチマーク（自作・MIT）: zephel01/swe-bench（llmbench） — clone & `pip install -e .` で追試できます。40問＝速度測定、`--with-l6` で60問＝実力測定、`--only-l7` で L7 v2 16問＝天井測定。

今月の個別検証記事: L7 v2ベンチ作り直し／25pt差検証、Claude Opus 5のL7 16問、gemma-4-26B-A4B vs 31B、Qwimi-3.6-27B-Coder-MTP、Ornith-1.0 unsloth版＋35B 60問追試、Ornith-35B-AEON NVFP4、Fable-Fusion-711-Heretic、Ternary-Bonsai DSpark、QUEST-35B-RL-A3B、ThinkingCap-27B、Parable-Qwen3-4B、Mythos-nano v3、Qwythos-9B v3 / v2、9B級まとめ、MaralGPT-Mythos-9B、MiniCPM5-1B、Dolphin3-Cyber-8B、Grug-12B、16GBランキングと続編、3090 vs 5090、オーケストレータ9B化 → https://note.com/zephel01

#ローカルLLM #llamacpp #ベンチマーク #量子化 #GGUF #MoE #MTP #passk #RTX5090 #コーディングモデル #ClaudeOpus5