見出し画像

unsloth版Ornith-1.0を10量子化で再検証: 35B UD-Q5_K_Mの40/40満点は、同じ日の60問追試で崩れた

zephel01

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

前回（6/26）、DeepReinforce AIの自己改善型コーディングモデルOrnith-1.0を9Bと35Bでまとめて検証しました。あの記事は公式（deepreinforce-ai）のGGUFです。そこへ7/17〜18、unslothがUD（Unsloth Dynamic）量子化版のGGUFを出してきた。しかも公式でtool-callingを壊すと報告されていたチャットテンプレートのバグ修正まで入っている。同じモデルでも「誰の量子化か」で結果は変わるのか——これを確かめたくて、前回とまったく同じ40タスク・同じ環境で9Bを8量子化・35Bを2量子化、合計10パターンを回し直しました。

結論を先に置きます。35B UD-Q5_K_Mが、この連載でOrnithとして初の40/40満点。 シリーズの二大鬼門であるt020（電卓）とt021（バンカーズ丸め）を同時にクリアした最初のモデルです。一方で9Bは、前回ピークだったQ5/Q6が今回は谷に落ち、Q8系が山になる「中位落ち込み」の逆転が出ました。ただし今回も全部が単発1runです。1〜3問（2.5〜7.5pt）の差は運の範囲に収まりうるので、そこは断定しません。

そして——ここが今回の見どころです。この40/40満点は、同じ日のうちに崩れました。 満点の裏取りを兼ねてarchitect帯20問を足した60問×1runの再走をかけたところ、35B UD-Q5_K_Mはt021（バンカーズ丸め）を今度は落としました（40問共通部39/40、全体54/60=90.0%）。史上初めて通した「最後の1問」が、同じ量子化・同じ設定の再走であっさり戻った。「1回成功」と「安定して解ける」はまったく別物——連載で何度も書いてきたこの原則が、満点の賞味期限という形で同日に自前で実演された格好です。だからこの記事は、40/40を記録すると同時に、その40/40が一日で崩れた事実まで含めて残します。

このモデルの素性と、unsloth版で変わったこと

Ornith-1.0の素性は前回記事で詳しく書いたので、ここは要点だけ。agentic coding（エージェント型コーディング）に振った自己改善型RLモデルで、9BはDense、35BはMoE、ライセンスはMIT・地域制限なし。詳細は前回記事（末尾の関連記事）を見てください。

ひとつ、前回の記述を直します。前回「ベースはGemma 4とQwen 3.5」と書きました。今回config.jsonを確認したところ、9Bも35Bも`model_type`はQwen 3.5系（9Bが`qwen3_5`/Dense/32層、35Bが`qwen3_5_moe`/MoE・256エキスパート中8活性/40層）でした。「Gemma 4とQwen 3.5」はファミリー全体（9B/31B/35B/397B）の説明で、どのサイズがどちらをベースにしたかは公式に明示がありません。少なくとも今回の9B/35Bに関しては「Gemma 4ベース」は当てはまらなさそうです。訂正しておきます。

unsloth版で変わる点は2つ。

ひとつめはUD（Unsloth Dynamic 2.0）量子化。標準のllama.cpp量子化は全レイヤーに一律のビット幅を当てますが、UDはテンソルごとに量子化タイプを動的に選ぶ。重要なテンソルだけ精度を上げる「XL」系が代表で、キャリブレーションに独自の150万トークン超のimatrixデータセットを使うそうです（unsloth公式docs）。unslothの中の人はXL系を推奨しています。

ふたつめはチャットテンプレートの修正。公式テンプレートにはsystemメッセージ順序を強制する`raise_exception`があり、llama.cpp/LM Studio/Ollamaでtool-callingが壊れると報告されていました（公式discussion #10 ）。unsloth版はこれを直したコミットが7/18に入っています。ただし——本ベンチはpatch生成型で、tool-callingは使いません。この修正がスコア差の原因だとは断定しません。「そういう修正が入った版だ」という事実の共有にとどめます。

ファイルサイズ（HFのtree実測値）:

35BはUD-Q4_K_M / UD-Q5_K_Mという名前で実在します（無印量子化はほぼなく、UD系中心のラインナップ）。目を引くのは9BのUD-Q8_K_XLが13GBで、同じ8bitのQ8_0（9.53GB）より約36%も大きいこと。ここは後で速度の話と絡めます。

検証環境

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

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

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

  • 実行回数: 各タスク1回（単発） ※pass@k・5回平均は今回とっていません

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

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

  • 評価軸: Resolved率 / Quality / Combined / usability

前回とタスク・環境・サンプリングはすべて揃えました。違うのは「公式GGUF→unsloth版GGUF」だけ。差分をほぼ量子化の作り手に帰せられる設計です（単発なので運のブレは残る）。

加えて今回は、35Bの2量子化だけ60問追試を回しました。 40問満点の裏を取るため、60問 = 40問 + architect 20問（t041〜t060） に帯を1つ足した構成で、各1回・同日に再走したものです（2026-07-19計測）。9Bは対象外。この60問版はpass@kも5回平均もない単発で、40問版とは別枠のデータとして扱います。

結果サマリ

9B（Dense・8量子化）

35B（MoE・2量子化）

結論: 精度最優先かつVRAM 26GB以上あるなら35B UD-Q5_K_M（40問で40/40・Combined 91.5・235 tok/s）で決まり。9Bで完結させるならQ8_0（92.5%・144 tok/s）かQ4_K_M（90.0%・最速198 tok/s）。今回に限っては中位のQ5/Q6を選ぶ理由がない。ただしこの40/40は単発の一発であり、後述の60問追試では崩れます（それでも35B推奨は揺らぎません）。

前回（公式GGUF）との比較: 中位が谷、Q8系が山

ここが今回いちばん面白かったところ。前回の公式GGUFと、今回のunsloth版を単発同士で並べます。

9B（Resolved、前回公式→今回unsloth）:

前回の公式GGUFはQ6_Kがピーク（90%）で、この連載でよく見る「中位（Q5/Q6）が山」の教科書どおりでした。ところが今回のunsloth版はQ5/Q6が82.5%で最下位タイに沈み、Q8_0が92.5%、UD-Q8_K_XLが95.0%と上位を占める。中位が谷、高bitが山という、いつもと逆の形です。

ここで留保を効かせておきます。これは単発1run同士の比較です。 Q6の-7.5ptは3問、Q5の-5.0ptは2問。単発だと2〜3問くらいは平気でブレます（このシリーズの原則として、単発は+10pt級の上振れも普通に起きる）。だから「unsloth版のQ5/Q6が公式より劣化した」と言い切るのは早い。5runsで均せば谷が浅くなる可能性は十分あります。

それでも「中位が谷・Q8系が山」というパターン自体は目を引きます。UDのimatrixキャリブレーションが高bit側でうまく効いているのかもしれませんが（自信度: MODERATE）、単発データで因果は断言できません。頭の隅に置いておく、くらいの温度感です。

35B UD-Q5_K_M、この連載でOrnith初の40/40満点

35B UD-Q5_K_Mが40問すべて正解しました。前回の35B Q5（97.5%・t021の1問だけ失敗）から、その最後の1問を含めて全部通した形です。

これがなぜ大きいか。t020（電卓の演算子優先順位・括弧）とt021（バンカーズ丸め）は、このシリーズを通した二大鬼門です。仕様の細部を正確に詰める系で、サイズを上げても最後まで残ってきた壁。前回は35BですらQ4がt020を、Q4/Q5がt021を落としていました。今回のUD-Q5_K_MはOrnithとして初めて、この二大鬼門を同時にクリアしています（シリーズ全体では満点を出したQwopus3.6-27B-Coderに次ぐ2例目）。

連載でOrnithが満点を出したのはこれが初めて。過去に40/40を出したのはQwopus3.6-27B-Coder（Q6）だけなので、Ornithは満点勢2番手に並んだことになります。

ただし冷静に。前回の97.5%との差は1問（+2.5pt）で、単発です。 上振れで最後の1問がたまたまハマった可能性は消せません。「満点を出せるポテンシャルがある」までは言えても、「安定して40/40」は5runsを回さないと言えない——と、ここまでは前置きでした。実際、次の60問追試でその通りになりました。

60問追試: 満点は一日で崩れた

40/40満点の裏を取ろうと、architect帯20問（t041〜t060）を足して60問×1runを同日に再走しました。対象は35Bの2量子化だけ。結果がこれです。

難易度別:

40問と共通の範囲でいちばん効いたのはexpert帯です。両量子化とも11/12で、落とした1問はt021（バンカーズ丸め）。 40問版で史上初めて通したあの「最後の1問」を、UD-Q5_K_Mは同じ量子化・同じ設定の再走で落とした。40問共通部で見ると39/40。40/40満点は、同日の再走で崩れました。単発の上振れだったことが、外部データを待つまでもなくrev2で自前実証された形です。「1回成功」と「安定して解ける」は別物——連載の原則がそのまま出ました。

面白いのは、ブレは両方向に出たことです。逆にUD-Q4_K_Mは、40問版で落としていたt007・t017を今回は通し、代わりにt021だけ落として39/40。片方が新たに落とし、片方が前回落としたものを拾う。単発とはそういうものだ、という見本です。

そして新設のarchitect帯（20問）は両量子化とも15/20。ここで差がつくかと思いきや、Resolvedは横並びでした。失敗の中身を並べます。

  • 共通の失敗（3問）: t045（キャッシュ期限切れが稀に返る）・t046（DIのsingleton/requestライフタイムが守られない）・t059（浮動小数点和が真値からドリフト）

  • UD-Q4_K_Mのみ追加（2問）: t047（失敗したマイグレーションが後続をappliedにしてしまう）・t054（ネスト条件を値埋め込みしてパラメータ化しない）

  • UD-Q5_K_Mのみ追加（2問）: t043（スナップショット後のリプレイでイベント二重計上）・t057（CSVパーサがカンマ前提でクオートを無視）

中身を見ると、DIライフタイム・マイグレーション整合・浮動小数点和・キャッシュ期限という、仕様の裏側まで詰めないと通らない「設計系」の壁が並びます。帯を上げると最後まで残るタイプのタスクで、Ornithもそこは抜けきれませんでした。

もうひとつ、実務目線で効く事実を。40問版でUD-Q5_K_Mは🔴不可がゼロでした。ところがarchitectを足すと🔴不可は6問に増えます（Q4も6問、いずれもarchitect帯中心）。「レビュー前提なら全部任せられる」という40問版の見え方は、上位帯を足すと崩れる。天井は40問という土俵の高さに規定されていた、というだけの話です。

最後にQ4とQ5の差について。60問ではほぼ消えました。 Resolvedは同率90.0%、Qualityが82.3 vs 81.1、🟢自律が39 vs 37でいずれもQ5がわずかに上、という程度です。40問版でQ5が見せた「40/40・Combined 91.5」ほどの差は残っていません。ただしこれも単発なので、この僅差で優劣を断定はしません。60問という広い土俵で見ると、両者は事実上並んだ、というのが正直なところです。

念のため。90.0%（54/60）はarchitect込みの数字としては十分高水準です。満点が崩れたからといって35Bの推奨が揺らぐわけではありません。崩れたのは「40/40という一発の記録」であって、35Bの地力ではない——このバランスで読んでください。

UD-Q8_K_XLの珍現象: 精度は出るが速度を捨てる

9Bの最高精度はUD-Q8_K_XL（95.0%・38/40）。Combinedも87.9で9B最高でした。ところがこの量子化、tok/sが~66しか出ません。同じ8bitのQ8_0（~144）の半分以下、9Bなのに35B（~235〜243）よりはるかに遅い。

原因はおそらくファイルサイズです。UD-Q8_K_XLは13GBで、Q8_0の9.53GBより約36%大きい。重要テンソルを高精度に持ち上げる設計のぶん膨らんでいるのだと思いますが、なぜここまで速度が落ちるかの公式説明は見つかりませんでした。他モデル（Qwen3.5-35B）でも「Q8_K_XLで生成速度が大幅低下」というユーザー報告があります（未検証・二次情報）。

位置づけは「精度は出るが速度を捨てる」ポジション。9Bで最も正確に解いてほしいバッチ処理向きで、対話用途には向きません。速度も欲しいなら素直にQ8_0（92.5%・~144）で十分。差は1問（2.5pt）しかない。

難易度別と失敗タスク

難易度別の正解数（9B）:

難易度別（35B・40問版）:

失敗タスクの内訳（40問版）:

鬼門の系譜を追います。t020（電卓）は9Bの8量子化すべてが失敗しました。前回の「9B全滅」がそのまま継続。9Bにとってt020は量子化を変えても抜けない壁です。一方35Bは2量子化とも通過（前回はQ4が落としていたので改善）。

t021（バンカーズ丸め）は9Bで3つ（UD-Q4_K_XL / UD-Q5_K_XL / Q6_K）が失敗、35Bは40問版ではUD-Q4_K_Mが失敗、UD-Q5_K_Mは通過でした。ただし前述のとおり、60問追試ではUD-Q5_K_Mもt021を落としています。二大鬼門を同時にクリアした「40/40の一発」は記録に残しますが、t021は依然としてこのシリーズの鬼門であり続ける、という結論のほうが実態に近い。

9B特有の取りこぼしはt010（CSVクオート処理）とt017（slugify整形）で、前回同様に「地味だが仕様が細かい」タスクで9Bがブレる傾向は変わっていません。

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

「🔴不可（レビューしても任せられない）」の少なさが実用度の物差しです。まず40問版から。

40問版では35B UD-Q5_K_Mの🔴不可がゼロでした。40問すべて、少なくともレビュー前提なら任せられる水準にある——と、ここまでは40問の話。ただしこの「不可0」はarchitectを足すと崩れます。前述の60問追試では、Q5もQ4も🔴不可が6問（いずれもarchitect帯中心）に増えました。「不可0」は40問という土俵に規定された見え方であって、上位帯まで含めた実運用では6問前後の不可が残る、と読むのが正確です。

9B側だとUD-Q8_K_XLが🔴2問（5%）で最良ですが、速度~66の代償つき。40〜60問のどちらで見ても、実務でレビューコストを最小にしたいなら35B系が頭ひとつ抜けているのは変わりません。

tok/sの読み方（毎回の注意）

今回もtok/sを載せていますが、数字をそのまま「賢さ」と読まないでください。35B（~235〜243）が9B（~144〜198）より速いのは構造要因です。35BはMoEで、トークンごとに使うエキスパートが一部だけ（256中8活性）。毎ステップ実際に計算する重みはDense 9Bより少ないので速く出る。前回と同じ傾向です。60問追試でも35Bは~243（Q4）/~237（Q5）と、40問版と同水準を保っています。

もうひとつ、UD-Q8_K_XLの~66は例外的に遅い。これは量子化ファイルの作りに由来する速度低下で（前述）、他の9B量子化（~144〜198）とは別枠で見るべき数字です。tok/sは中央値・単発実行時の値で、並列で回せば1ストリームあたりはさらに落ちます。

まとめ: どれを選ぶか

用途別に1行ずつ言い切ります。すべて単発1runの結果に基づくので、±1〜3問の差は運の範囲という前提つきで。

  • VRAM 26GB以上あって精度最優先なら35B系一択。 40問で40/40（UD-Q5_K_M）、60問でも90.0%・235 tok/s。満点は一発だったが、地力の高さは40問・60問のどちらでも変わらない。

  • 35Bの2量子化のどちらを取るか。 40問版はUD-Q5_K_Mが頭ひとつ抜けて見えたが、60問ではUD-Q4_K_MとほぼタイになりResolvedは同率90.0%。それでもQuality（82.3 vs 81.1）と🟢自律（39 vs 37）でUD-Q5_K_Mがわずかに上なので、迷うならUD-Q5_K_Mを薄く推す。VRAM・速度を詰めたいならUD-Q4_K_M（22.1GB・243 tok/s）で実用上まったく問題ない。

  • 9Bで精度を狙うならQ8_0。 92.5%・144 tok/s。UD-Q8_K_XLは95%だが~66と遅すぎるので、対話用途では選ばない。

  • 9Bで速度重視ならQ4_K_M。 90.0%・最速198 tok/s・5.7GB。ゲーミングGPU1枚の堅実な入口。

  • 9Bの中位（Q5/Q6・UD-Q5/Q6）を今回あえて選ぶ理由はない。 unsloth版では谷になった（単発なので5runsで変わる余地は残す）。

教訓を2つ。

ひとつ。同じモデルでも、量子化の作り手が変われば序列が変わる。 前回の公式GGUFはQ6がピークでしたが、今回のunsloth版はQ5/Q6が谷でQ8系が山。GGUFを選ぶときは「どの量子化か」だけでなく「誰の量子化か」まで見ないと序列を読み違える。少なくともOrnithは、公式とunslothを別物として扱うのが安全です。

ふたつ。「1回成功」と「安定して解ける」はまったく別物。 今回いちばんの成果は35B UD-Q5_K_Mの40/40でしたが、その満点は同じ日の60問追試でt021を落として崩れました。史上初めて通した最後の1問が、同じ設定の再走で戻る。単発で見えた天井は、しばしば天井ではなく上振れです。この連載が5runsとpass@kにこだわる理由が、満点の賞味期限という形で今回きれいに実演されました。

35B UD-Q5_K_Mの40/40という一発を記録できたこと自体は連載の節目です。が、それを「安定して40/40」と読み替えないこと。5runsでの再検証は、引き続き宿題にします。

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

モデル情報

関連記事

#ローカルLLM #llamacpp #ベンチマーク #量子化 #GGUF #Ornith #unsloth #MoE #コーディングモデル #AI

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

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