Qwen3.8-27Bを6量子化で回したら、モデルより先に「自分のベンチのバグ」と「temperature設定」を測っていた

2026年8月16日 12:44

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

8月上旬に Qwen3.8-27B が出ました。モデルカードに SWE-bench Pro 61.7、Opus4.6 Max の 53.4 超えと書いてあるのを見て、正直こう思いました。「27Bのローカルモデルがそこまで出るなら、うちの60問はどうなるんだ」と。

結論から言うと、Resolved 87.5%（14/16）。7月に測った Claude Opus 5（Claude Code CLI経由）と同じ数字が、ローカルの27Bから出ました。

ただし、そこに至るまでに2回やり直しています。

最初に16ラン回した数字は、公開できるものではありませんでした。原因はモデルではなく、自作ベンチの抽出器のバグと、thinkingモデルに temperature 0.2 を使っていた筆者の設定ミスです。せっかくなので、その過程ごと書きます。ベンチを自作している人には、量子化比較より役に立つ話だと思います。

先に結論を4行で。

**抽出器のバグで、モデルが出した完全な実装が捨てられていました。**実測564タスクに修正版を流し直したところ、14件が「非コード → 実コード」に救済され、うち 9件が実際に隠しテストを通過。退行はゼロ。テストは 218 passed → 285 passed
**temperature 0.2 は thinking モデルには毒でした。**公式推奨の temp 1.0 に戻したところ、L7 の打ち切りは 15.3%（22/144）→ 2.1%（2/96）。同一ファイル・同一ハーネスで UD-Q6_K_XL が 68.8% → 87.5%（+18.7pt）
**L7 16問のうち 11問は6量子化すべてが通過、1問（t105）は6量子化すべてが失敗。**順位を決めていたのは残る4問だけでした。この規模では、量子化の差はほとんど測れていません
総合トップは UD-Q6_K_XL（Resolved 87.5% / Quality 85.3 / Combined 81.1）。ただし ctx 64k で VRAM 29.4GB。実務で選ぶなら UD-Q4_K_XL（同 87.5% / 22.3GB / ~108 tok/s）

このモデルの素性

ハイブリッド注意は Qwen3.6系から続く構成ですが、`full_attention_interval: 4`、つまり4層に1回しかフルAttentionを使いません。1Mトークンを名乗れるのはこの構造のおかげです。

そして**この表の一番下の行が、この記事の主役になります。**筆者はここを見ずに、Gemma系で使っていた temp 0.2 のまま16ラン回しました。

モデルカード掲載値（参考値・筆者の実測ではありません）

出典：Qwen/Qwen3.8-27B モデルカード。これらは公称値であり、この記事の実測表とは別物です。

注目すべきは GPQA Diamond が 87.8 → 89.2 とほぼ横ばいなのに対し、DeepSWE が 13.3 → 42.2、QwenSWEBench が 49.3 → 79.0 と、エージェント／コーディング系だけが跳ねている点です。素の知識量ではなく「タスクを最後まで完遂する」方向に振った世代だと読めます（自信度: MODERATE）。

GGUFサイズと実測VRAM

GGUFサイズは results.json に記録した実ファイルのバイト数、VRAM は `llama-server` 起動直後の `vram_total − vram_free` 実測です。

**ctx を 64k にすると、24GB機に載るのは Q4_K_M（21.6GB）と UD-Q4_K_XL（22.3GB）の2つだけになります。**Q5_K_M は 24.0GB でぎりぎり踏み、UD-Q6_K_XL の 29.4GB は 32GB の5090でも残り 2.0GB しかありません。thinking モデルで長い思考を許すなら、実質的にビットを上げる余地はほとんどないというのが、今回いちばん実務的な発見かもしれません。

なお画像・動画を使うなら `mmproj-F16.gguf`（約0.93GB）が別途必要です。今回のベンチはテキストのみなので使っていません。

Unsloth Dynamic（UD-*_K_XL）とは

unsloth のカードには「Unsloth Dynamic V3.0 (preview)」とあります。Dynamic 2.0 のドキュメントによれば、標準K-quantが全層に一律のフォーマットを当てるのに対し、UDは層ごとに量子化タイプを変え、モデルごとに別のレシピを使う方式。キャリブレーションにチャットテンプレート込みの独自データセット（150万トークン超）を使い、劣化の評価を perplexity ではなく KLダイバージェンスで見るのが売りです（確度: HIGH、公式ドキュメント記載）。

ただしV3.0で何が変わったかは公開ドキュメントに見当たりません（2.0のページしか公開されていない）。ここは「preview版で詳細不明」と正直に書いておきます。

サイズ面では説明と整合しています。UD-Q4_K_XL は Q4_K_M より約0.8GB大きく、UD-Q6_K_XL は Q6_K より約3.0GB大きい。重要な層に多くのビットを割いた分だけ太っている、という理解でよさそうです。

**この記事では自作量子化を一切使いません。**全ラン unsloth 版（`/mnt/data/models/Qwen3.8-27B-GGUF/`）で、モデルファイルの指紋（size / mtime / sha256 の head+tail）を results.json に記録しています。

検証環境と2段階のデザイン

実行環境: llama.cpp（CUDAビルド、`b10431-1692f9e50`）
ハードウェア: EVO-X2（AMD RYZEN AI MAX+ 395）+ RTX5090 32GB。RTX3090 24GB は速度比較の参考値としてのみ使用
第1段のタスク数: 60問（easy 5 / medium 5 / hard 10 / expert 12 / frontier 8 / architect 20）
第2段（本題）のタスク数: 16問（L7 = grandmaster 帯のみ。タスクIDは t063〜t107 の飛び番）
実行回数: 各タスク 1回（5runsではありません。後述の留保を必ず読んでください）
内容: Pythonのバグ修正・実装タスク（決定論的テスト付き）。L7は複数ファイルにまたがる移行・多重バグ・並行制御を含む
サンプリング: 公式推奨 temp 1.0 / top_p 0.95 / top_k 20 / min_p 0.0 / seed 42（payload に実送信し、`environment.sampling` に実効値を記録）
起動オプション: `-ngl 99 --ctx-size 65536 --parallel 1 --batch-size 2048 --ubatch-size 512 -fa on --threads 8 --spec-type draft-mtp`
出力トークン上限: 49,152 tok
評価軸: Resolved率 / Quality / Combined / usability / tok/s

llmbench の説明を毎回どおり再掲します。SWE-Bench風の自作ベンチで、バグレポートとソースをLLMに渡し、patchを適用してから隠しpytest（LLMには非公開）で解決判定します。pytestは `-x` 付きなので、最初の1本が落ちた時点で打ち切られます。

Combined = 成功率 ×（0.5 + 0.5 × Quality/100）× 100（動かないコードは0点）
Quality = ruff（重み0.4）+ 保守性指標 radon（0.3）を再正規化した合成点。実質 ruff が約57%、complexity が約43%
usability: 🟢自律 = 成功率≧0.9かつQuality≧80 / 🟡補助 = 成功率≧0.6 / 🔴不可 = それ以外
GitHub: `zephel01/swe-bench`（MIT）。stdlib-only で再現可能

今回の実行内訳

**太字の6ランが、この記事のメインデータです。**その上の9ランと4ランは「やり直す前の記録」として、比較のためだけに使います。

MTPについて補足。`--spec-type draft-mtp` は llama.cpp に2026年5月にマージ済みの機能ですが、unslothのMTP対応表にQwen3.8はまだ載っていません（Qwen3.6までの掲載）。ただし Qwen3.8-27B-GGUF の各ファイルは、Qwen3.6の「MTP版」リポジトリとバイト単位でほぼ一致するサイズになっており、MTP重みを本体に同梱していると推定されます（自信度: MODERATE、テンソル名の直接確認はしていません）。実測の tok/s を見るかぎり効いているように見えますが、MTPをオフにした対照実験はしていません。

第1段：60問では、もう何も測れない

結果サマリ（60問・各1run・RTX5090）

**結論: この表で量子化の優劣を語ってはいけません。**6ランの幅は 95.0〜100.0%、差は最大でも 3タスク。しかも上4行と下2行で ctx・サンプリング・ハーネスのバージョンが全部違います。Quality列を落としたのも、旧4ランは再抽出後のQualityを再計算していないためです（混ぜて並べるほうが害が大きい）。

この連載の60問版で Resolved 100%（60/60）が出たのは初めてです。それ自体はニュースですが、同時に「この難易度帯は終わった」という宣告でもあります。

難易度別：easy〜frontier は完全な天井

（すべて再抽出後の値です）

**40問（easy〜frontier）だけなら、6量子化中4つが満点、残る2つも1問落としただけです。**差がつく余地があるのは architect 20問だけで、そこも最大2タスク差。**これでは量子化の比較になりません。**なので第2段として L7（grandmaster）16問を足しました。

60問で落ちたタスク（7ラン集計・再抽出後）

**t046 がこのモデルの60問側の鬼門です。**7ラン中5ランで落ちており、通したのは UD-Q5_K_XL と UD-Q6_K_XL の2つだけ。t020・t021 はこの連載を通しての常連（電卓・バンカーズ丸め）なので、系譜どおりの顔ぶれです。

第2段（本題）：L7 grandmaster 16問 × 6量子化

ここからが**全ラン同一条件（unsloth版 / ctx 64k / 公式推奨サンプリング / 修正版ハーネス / seed 42）**のメインデータです。

結果サマリ（L7 16問・各1run・RTX5090）

結論: Resolved は3量子化が 87.5% で同率トップ。Quality と usability まで見ると UD-Q6_K_XL が単独トップだが、ctx 64k で 29.4GB を要求するので、実務で選ぶのは UD-Q4_K_XL（同率トップ・22.3GB・最速）。

Combined 順に並べると UD-Q6_K_XL 81.1 → UD-Q4_K_XL 80.0 → Q4_K_M 78.2 → Q6_K 75.0 → Q5_K_M 66.8 → UD-Q5_K_XL 66.7。5bit帯が谷になる形は標準・UDの両方で共通です。「ビットを上げれば精度が上がる」は今回も成立していません。

ただし**各1runなので、1タスク＝6.25pt です。**87.5%と81.2%の差はタスク1本、つまり運の範囲に十分収まります。±6pt程度の差では優劣を断定しません。

つまずき①：抽出器が、モデルの正解を捨てていた

最初の16ランを見ていて「失敗の中身が変だ」と気づき、ベンチ本体を監査しました。決定的な例がこれです。

`t057` のラン（Q4_K_M・60問）の `llm_output.txt` には `--- FILE: sniff.py ---` が2回出現していました。

`patch.py` が同一パスを後勝ちで上書きしていたため、保存された `generated/sniff.py` は4バイトの `...` になり、pytest は `ImportError: cannot import name 'parse'`、結果は「モデルの失敗」として記録されていました。

主な修正は3つです。

同一パスの後勝ち上書きを廃止（`setdefault` による先勝ち）＋ `ast.parse` ベースのゲートを追加し、`...` / `pass` / `<placeholder>` / 構文エラーを弾く
コードブロックの正規表現を行頭アンカー付き・言語タグ一般化に変更。旧正規表現は ` ```python ` にしか一致せず、` ```json ` の開きフェンスを取り逃してフェンス対応が1つずれ、思考の散文をコードとして拾っていた
`seed` / `top_p` / `top_k` / `min_p` を payload に送信（従来は一度も送信されておらず、llama-server 既定の `seed=-1`＝毎回ランダムが効いていた）

修正の効果（実測564タスクへ再適用、GPU時間ゼロ）：

**5件が救済されても通らなかったことが、修正が偽の合格を作っていない証拠です。**テストは 218 passed → 285 passed（既存テストは1行も書き換えずに全通過、新規67件）。

この修正だけで L7 のスコアは 6.2〜12.5pt 動きました。**「同じ量子化を2回走らせたら 6.2pt ずれる」と見えていた揺れの正体も、これでした。**修正後は Q6_K の再走ペアが 87.5% / 87.5% と完全一致します。

つまずき②：thinking モデルに temperature 0.2 は毒だった

ハーネスを直しても、L7の失敗の質がおかしいままでした。**16問中20件近くが「出力上限に到達して終わっている」**のです。

最初は「思考の予算が足りない」と考えて、上限を 24,576 → 49,152 に倍増し、ctx も 32k → 64k に上げました。**結果は Resolved 75.0% のまま。**それどころか、t101 は 11,026トークンで通っていたものが 49,152トークンを使い切って失敗に転じました。予算を倍にすると、その分だけ長くループするだけだったわけです。

そこでモデルカードを読み直して、ようやく気づきました。**Qwen3.8 の thinking モードの公式推奨は temp 1.0。**筆者は Gemma系で使っていた 0.2 をそのまま流用していました。「コード生成だから温度は低く」という、非thinkingモデルの常識のままだったのです。

打ち切りが7分の1に

**ここは条件が2つ同時に動いていることを明記します。**旧ランは上限 24,576 / ctx 32k、新ランは上限 49,152 / ctx 64k です。上限を倍にしただけでも打ち切り率は下がります。

ただし前述のとおり、上限だけを倍にした対照ラン（temp 0.2 のまま）は 75.0% のままでした。同じ ctx・同じ上限でサンプリングだけ公式推奨に戻したランは 87.5%。主因はサンプリング側と判断します（自信度: HIGH）。

縮退ループが実際に消えている

`llm_output.txt` の中で「同一行が何回繰り返されたか」「最長1行が何文字か」を機械的に数えました。

temp 0.2 のとき

公式推奨のとき

反復12回・1行15,434文字という縮退が、ほぼ全域で消えました。

ただし根絶はできていない

公式推奨サンプリングでも、60問側の Q6_K で1件、露骨な縮退が残りました。t053（属性値のエスケープ）の出力を見てください。

data: dangerous for script, but not necessarily XSS? Could be. ...
Need think about URL scheme detection with escaped entities:
If href contains "javascript&#00000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
（以下、"0" が 7,930文字続いて出力終了）

HTMLの数値文字参照 `&#0` を書き出そうとして、ゼロを打ち続けたまま帰ってこなくなっています。20,053バイトの出力に FILE マーカーは0個。結果は `patch parse failed: no file blocks found in output` です。

QwenLM の Issue #145 に「公式推奨サンプリングでもループに落ちる報告がある」とありますが（確度: MODERATE、筆者が読んだ範囲での要約）、実測でも「大幅に減らせるが根絶はできない」が正しい結論でした。

L7側で上限に達した2件も、中身は同じ症状です。

**上限に達した2件が、どちらも RESOLVED です。**修正版の抽出器が、思考の途中に書き上がっていた完成ドラフトを拾えたためです。修正前ならどちらも「モデルの失敗」として記録されていました。

逆転現象：「Unsloth Dynamic は全ビット帯で標準に負ける」が、温度を戻したら消えた

やり直す前のデータで、筆者は「UDが標準を上回るビット帯は、L7には一つもない」と結論づけていました。同じモデルファイル・同じハーネスで、サンプリングだけ変えた結果がこれです。

6bit帯だけで25pt動いています。「UD-Q6_K_XL は6bit帯で標準に大差で負ける」という見立ては、UD-Q6_K_XL のほうが低温での縮退ループに落ちやすかったというだけの話だった可能性が高い（自信度: MODERATE。1run同士の比較なので断定はしません）。

量子化ごとの前後比較はこうなります。

Q6_K だけが下がっていますが、これは1タスク分（6.25pt）で、再走差の範囲です。**平均 +5.7pt は、この連載で見てきたどの量子化間の差よりも大きい。**モデルも量子化も変えず、設定ファイルの1行を直しただけでこれです。

いちばん大事な発見：順位を決めていたのは16問中4問だけ

L7 16問 × 6量子化のタスク別通過表です。

読み方はこうです。

11問（69%）は6量子化すべてが通過しています。ここでは量子化の差がまったく出ていない
1問（t105）は6量子化すべてが失敗。ここも差が出ない
残る4問（t069・t095・t102・t103）だけが順位を作っています

つまり 87.5% と 75.0% の差は、実質「4問のうち何問取れたか」だけの話です。しかも t102 と t103 の通過パターンには量子化との相関がまるでない（t103 は UD-Q4 と Q6_K が通り、UD-Q6 が落ちている）。

**この規模では、量子化の優劣は測れていません。**測れているのは「16問中11問は安定して解ける」「1問はどうやっても解けない」「4問はコイントスに近い」という、モデルの実力の分布そのものです。これはベンチの設計が悪いのではなく、1runで量子化を比較するという行為の限界です。

7月の横断検証と並べる：t101 が落ちた

7月25日に、同じ L7 16問で Claude Opus 5 ほか4モデル（計9実行）を測っています。その結果と並べます。

出典：筆者の2026-07-25の実測。**土俵は違います。**Claude Opus 5 は Claude Code CLI 経由なので、CLIが内部でツール往復や自己修正をしうる「エージェント製品」を測っています。temperature も制御できていません。素のモデル同士の比較ではないので、「27BがOpus 5に並んだ」とは書きません。

それでも意味のある比較はできます。7月の9実行で全滅していた t101（ログローテータ 3多重oracle）を、Qwen3.8-27B は6量子化すべてで通しました。

**ただしこの差を素直に「モデルが強くなった」と読むのは危険です。**7月の9実行は temperature 0.2 固定で、しかもこの記事で直した抽出器のバグを踏んだままです。t101 の 0/9 のうち何件が「解けなかった」で何件が「抽出で捨てられた/思考が終わらなかった」なのかは、いま分離できません（自信度: MODERATE）。

言えるのはここまでです。「同一条件で測り直すべき対象が、いま9実行分ある」——これは宿題です。

3つの壁のその後：本物は t105 だけだった

temp 0.2 の9ランで全滅していた t095 / t103 / t105 の追跡です。

**t103 の判定ミスは書き残しておきます。**筆者は「自信度: HIGH」まで付けて「上限を上げても通らないタイプ」と書きました。実際には上限とは無関係で、温度を戻したら通りました。因果の推測に高い自信度を付けるときは、対照実験を1本走らせてからにすべきでした。

t105 は本物の壁です。隠しテストが「空レコードを渡したら `KeyError` を投げること」を要求しているのに、issue文にはその要求が書かれていない。実際、L7全15ランの出力を検索して `KeyError` という文字列は0回しか出てきません。モデルが読み取れない情報を要求している、タスク側の欠陥です（自信度: HIGH）。7月の9実行と合わせて 24実行が全滅しているので、次のタスク台帳更新で差し替えます。

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

Resolved が同じ 87.5% でも、Q4_K_M は 8/16、UD-Q6_K_XL は 11/16 が🟢自律です。差は Quality（78.8 vs 85.3）から来ています。「通るコードを書く」と「レビューなしで通せるコードを書く」の間には、ビット数がまだ効く余地がある（自信度: MODERATE）。

60問側（architect込み）だと 🟢が 37〜42/60 なので、L7ではっきり落ちます。grandmaster帯は「動くけどレビューは要る」コードの割合が増える、というのが素直な読みです。

速度：RTX5090 vs RTX3090、そして ctx 64k の代償

**同一GGUF・同一起動オプションで 2.71倍。**3090 は 18.9GB を積んで動いてはいますが、実用感はかなり違います。

コンテキスト長の代償も見えました。

**ctx を倍にすると、速度は約1割落ち、VRAMは約2.2GB増えます。**thinking モデルで思考の予算を確保しようとすると、この両方を払うことになります。

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

**MTP（投機的デコード）搭載モデルは構造的に速い数字が出ます。**今回は全ラン `--spec-type draft-mtp` 付き。賢さの証明ではありません
**MoEは活性化パラメータが小さいので速い。**Qwen3.8-27B は dense なので、この下駄はありません
**dense標準版は素直に遅い。**遅い＝劣っている、ではありません

上の数字はすべて 単発実行（`--parallel 1`） のものです。並列実行時の1ストリームtok/sは桁が変わるので、混ぜて比較しないでください。

結局どれを選ぶか

**VRAM 24GB なら UD-Q4_K_XL 一択。**ctx 64k で 22.3GB に収まり、L7 87.5%（同率トップ）、~108 tok/s で最速。Q4_K_M でもスコアは同じですが、Quality が 78.8 vs 82.9 で🟢自律が1問少ない
**VRAM 32GB で品質最優先なら UD-Q6_K_XL。**Quality 85.3・🟢自律 11/16 は明確に頭一つ抜けています。ただし ctx 64k で 29.4GB、残り 2.0GB。ctx を 32k に落とせば 27.3GB で余裕が出ます
**5bit（Q5_K_M / UD-Q5_K_XL）を選ぶ理由は、今回のデータでは見つかりませんでした。**標準・UDとも 75.0% で、4bitより遅く、4bitより重い
**Q6_K（標準）は微妙な位置。**Quality 84.5 は良いのに Resolved が 81.2%、しかも 26.7GB。同じVRAM帯なら UD-Q6_K_XL を ctx 32k で回すほうが素直です

**そして全量子化に共通する必須設定: `temperature 1.0 / top_p 0.95 / top_k 20 / min_p 0.0`。**ここを 0.2 にしていると、どの量子化を選んでも 5〜19pt 損をします。

この検証から持ち帰れる4つの教訓

thinking モデルに低温を使ってはいけない。「コード生成だから温度は低く」は非thinkingモデルの常識で、thinking モデルには逆効果です。思考が収束せず、同じ行を12回・15,000文字書き続けて上限に達します。公式推奨サンプリングは、まず疑わずに従うべき初期値です
予算を増やしても、壊れた設定は直らない。出力上限を倍にしたら、その分だけ長くループしただけでした（t101 は 11,026トークンで通っていたものが 49,152トークン使い切って失敗に転落）。「もっと考えさせれば解ける」の前に「無駄に考えていないか」を疑う
**ベンチのスコアは、モデルの実力より先に自分のハーネスを測っている。**抽出器のバグ1つで L7 が 6.2〜12.5pt 動きました。自作ベンチを持っているなら、モデルを増やす前に自分のコードを監査したほうがリターンが大きい
16問1runでは、量子化は比較できない。11問は全通過、1問は全滅、順位を決めたのは4問だけ。「87.5% が 75.0% に勝った」ではなく「4問のうち3問取れたか2問取れたか」が実態です

次の宿題

①をやるときは `sample_temp: 0.35` の罠に注意してください。`runs > 1` にすると temperature が実行時に 0.35 へ差し替えられ、せっかくの公式推奨 1.0 が消えます。`--sample-temp 1.0` を渡すか config の `sample_temp` を 1.0 にすること。あわせて `seed` はコメントアウトしてください（5回とも同じ seed になってしまいます）。

正直に書くと、この記事はモデルのレビューというより自分のベンチの反省文になりました。ただ、「60問で Resolved 100%」で終わらせずに、「16問中4問でしか差が測れていない」まで降りてこられたのは収穫だと思っています。数字が良く見えたときこそ、測り方を疑う価値があります。

検証で生成したコード・テスト結果はアーカイブ済みです。「特定タスクの詳細が見たい」「自分の環境でも試したい」はコメントへどうぞ。ベンチ側の修正は `zephel01/swe-bench` の `fix/extraction-truncation-seed` ブランチにあります。

モデル情報

HuggingFace: https://huggingface.co/Qwen/Qwen3.8-27B
GGUF: https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
ベース: dense 27.3B（ハイブリッド注意 / Vision encoder同梱 / MTP学習済み）
ライセンス: Apache 2.0
推奨サンプリング: thinking: temp 1.0 / top_p 0.95 / top_k 20 / min_p 0.0

Claude Opus 5 ほか5モデルの L7 grandmaster 16問横断ベンチ検証（2026-07-25）
llmbench 解説：機能とスコアの読み方
使用ベンチ: https://github.com/zephel01/swe-bench （MIT）

#ローカルLLM #llamacpp #ベンチマーク #量子化 #GGUF #Qwen3 #27B #Unsloth #thinking #サンプリング #RTX5090

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

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