LocalLLaMAがこの投稿に強く反応したのは、みんなが普段から抱えている痛点を正面から突いたからだ。ベース性能には満足しているのに、ローカルモデルが無駄に長く考え、時間とトークンを食う現象である。投稿者はllama.cpp上でQwen3.6 35B-A3Bと27B向けのGBNF grammarを調整し、prefill churnを減らしたと述べた。コミュニティにとってこの悩みは見慣れたものだが、スレッドが動いたのは改善幅がかなり大きく見えたからだ。

テスト条件もそれなりに具体的だった。RTX 5090、Fedora 43、4月24日版のllama.cpp mainline環境で、簡単な挨拶プロンプト、制約パズル、そして非公開のRust/Next.jsベンチ60 task-suiteを回したという。Qwen3.6 27Bでは、パズルトークンが40,101から7,376へ、パズル時間が13m36sから2m27sへ、ベンチ時間が29m54sから22m20sへ減り、スコアは4620のままだと書かれている。Qwen3.6 35B-A3Bはさらに派手で、パズル時間2m32sから12s、ベンチ時間33m52sから11m04s、ベンチスコアは4620から4740になったという。

話の中心は新モデル公開ではなくgrammar制約の調整である
最大の売りはreasoning token浪費の削減だ
結果はself-reportedで、Rust/Next.jsベンチは公開されていない
コメント欄では、これは本当の品質向上か、それとも不要なchain-of-thoughtだけを抑えた効果かがすぐ論点になった

その疑いこそがスレッドを面白くした。最初期のコメントの一つは、要するに「これはthinkingをうまく殺しているだけではないか」という質問だった。ほかの利用者は、適用手順や実運用でのdownsideをもっと噛み砕いて説明してほしいと求めた。逆に好意的な反応では、GBNFはstructured output全盛期にはよく使われたのに、なぜ今のローカルLLM調整では目立たなくなったのかと問い返していた。つまり、このスレッドは単なるスコア自慢ではない。古い制御面が現代のreasoningモデルにもまだ効くのか、そこをみんな試したかったのである。

魅力が大きい理由ははっきりしている。ローカルモデル利用者がいつも欲しいのは、より巨大なモデルだけではない。今使っているモデルが儀式のような長考でトークンを燃やすのをやめてほしいのだ。このGBNF調整が他の環境でも再現するなら、魔法だからではなく、安く、ローカルで、すぐ試せるから価値がある。 出典リンク: r/LocalLLaMAスレッド.

#gbnf

Qwen3.6のトークン浪費を削るGBNF細工、LocalLLaMAが沸いた理由