GBNF文法の微調整でQwen3.6 35B-A3BとQwen3.6 27Bを高速化

みなさんこんにちは、

コーディングと汎用用途向けに最適化した Qwen3.6 35B-A3B と Qwen3.6 27B をどうぞ。さらに、パズルもより正しく解けるようになっています。

当初の狙いは、私の 5090 環境で最も効率的な 35B-A3B の推論トレースを最適化することでした。私の本番では、prod で llama.cpp による並列ジョブを実行できるためです。

27B の一貫性は大好きです。ただ、長いホライズンの作業ではプリフィルの“ぐちゃぐちゃ”がつらい。

GBNF を調整して、改善があるか確認するために、私のカスタム Rust/Next.js ベンチで基本プロンプトをテストしました。その結果、35B-A3B の向上幅がいちばん良かったです：

「Hi」という単純なプロンプト、パズル、そして自作の Rust/Next.js ベンチ（60 task-suite）をテスト

皮肉なことに、コミュニティが 35B-A3B のシンプルな話題に対する推論の“引きずり”を正当に不満として挙げていたので、「Hi」プロンプトを使いました

テストした仕様
- RTX 5090
- Fedora 43
- llama.cpp mainline（4月24日）
- Qwen3.6-35B-A3B-APEX-I-Balanced.gguf（-c 216k）
- Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-Q6_K_P.gguf（-c 114k）
- kv f16
- -b & -ub 256
- 推論＋コーディングのための qwen のサンプリング

モデル	テスト	グラマーなし	グラマーあり	改善
Qwen3.6 27B	Hi トークン	248	42	83.1% 減, 5.90x 減
Qwen3.6 27B	パズルトークン	40,101	7,376	81.6% 減, 5.44x 減
Qwen3.6 27B	パズル時間	13m36s	2m27s	82.0% 速く, 5.55x スピードアップ
Qwen3.6 27B	ベンチスコア	4620	4620	同じスコア
Qwen3.6 27B	ベンチ時間	29m54s	22m20s	25.3% 速く, 1.34x スピードアップ
Qwen3.6 27B	ベンチスループット	1067 t/s	1193 t/s	+11.8%, +126 t/s
Qwen3.6 35B-A3B	Hi トークン	200	12	94.0% 減, 16.67x 減
Qwen3.6 35B-A3B	パズルトークン	30,096	2,592	91.4% 減, 11.61x 減
Qwen3.6 35B-A3B	パズル時間	2m32s	12s	92.1% 速く, 12.67x スピードアップ
Qwen3.6 35B-A3B	ベンチスコア	4620	4740	+2.6%, +120 スコア
Qwen3.6 35B-A3B	ベンチ時間	33m52s	11m04s	67.3% 速く, 3.06x スピードアップ
Qwen3.6 35B-A3B	ベンチスループット	1844 t/s	2195 t/s	+19.0%, +351 t/s

チャートの鍵は「Total Score（合計スコア）」と「Finish Time（完了時間）」です――メモリあたりの精度は個人的な参照値

Qwen3.6 35B-A3B は、リーダー（チャートの先頭）として X6 -> X1 へ。大幅な時間削減とスコアの上乗せによりです。

Qwen3.6 27B は、より良いフィニッシュ時間のため X4 -> X3 へ移動しました――スコアは維持されています。

ベンチマーク全体で記録された総スループット

Qwen3.6 35B-A3B APEX I-Balanced: 1844 -> 2195 t/s

Qwen3.6 27B Uncensored HauHauCS Aggressive Q6_K_P: 1067 -> 1193 t/s

Rust/Next.js のベンチは OpenCode と一緒に“スクリプトで注入”する形で順番に実行していて、金融アプリケーションの本番リポジトリで動かしています。そのため公開はしていません。

パズルのプロンプト

念のため言うと、このパズルに対して 35B-A3B は非常に苦戦しました。ときどき CoT の終盤に向けてループしたり、誤った答えを返したりします。12秒かかるのに対して +2分だったので、試し直して正しい答えを得るのは簡単でした。

あなたに制約のある計画問題が与えられます。注意深く考え、各条件を検証し、不可能性チェックを飛ばさないでください。問題：配達員は点 S から開始し、地点 A、B、C、D、E をそれぞれちょうど 1 回ずつ訪れて、その後 T で終了しなければなりません。移動時間（分）は対称です：S-A 4, S-B 6, S-C 8, S-D 7, S-E 9 A-B 5, A-C 7, A-D 3, A-E 8 B-C 4, B-D 6, B-E 5 C-D 5, C-E 3 D-E 6 A-T 8, B-T 6, C-T 5, D-T 7, E-T 4 制約：1. C は B の前には訪れてはいけません。2. D は A の直後に訪れなければなりません。3. T の直前の最後の地点として E を選んではいけません。4. 総移動時間は 28 分未満でなければなりません。5. 次のうちちょうど 1 つが真でなければなりません：- B が 2 番目に訪問される - C が 4 番目に訪問される 6. もし A が最初に訪問されるなら、B は 3 番目に訪問されなければなりません。7. 経路には、移動時間がちょうど 3 分である少なくとも 1 ステップを含める必要があります。課題：有効な経路が存在するかどうかを判断してください。 - 存在する場合は、有効な経路を 1 つとその総時間を提示してください。 - 存在しない場合は、すべての制約を満たすことができない理由を証明してください。 - 推論を明確に示し、各制約を明示的にチェックしてください。 - 推測しないでください。複数の経路があり得るように見える場合は、結論に至る前にすべての規則に照らして試してください。出力形式：1. 結論：有効な経路は存在する / 有効な経路は存在しない 2. 経路：... 3. 総時間：... 4. 制約チェック：... 5. 簡潔な証明：... 

答えは「有効な経路は存在しない」であるべきです。モデルがこの問題でごりごりと回ってしまいます。

GBNF Grammar

root ::= think out think ::= "<think>
" "Q=" q "
" "M=" m "
" "K=" toks "
" "R=" toks "
" "V=" v "
" "</think>

" q ::= "solve" | "prove" | "route" | "debug" | "patch" | "code" | "calc" | "compare" | "explain" m ::= "case" | "enum" | "check" | "derive" | "edit" | "test" | "trace" | "rank" v ::= "ok" | "fail" | "done" | "blocked" | "candidate" | "verify" toks ::= tok | tok "," tok | tok "," tok "," tok | tok "," tok "," tok "," tok "," tok tok ::= [A-Za-z][A-Za-z0-9_.!<>=/-]{0,18} out ::= [\x09\x0A\x0D\x20-\x7E]+ 

Open WebUI 上で CoT の外側にあるいくつかの think タグにだけ気づきました。

それ以外では、Hermes、llama.cpp の WebUI、OpenCode では問題なく動作します。

本番環境で（前回の睡眠時間までに）それ以上試す時間がなかったので、これがあなたの環境で少しでも役立てばと思います。