Qwen3.6-35B結果より大きかった論点、LocalLLaMAが見たscaffold問題

なぜこのReddit投稿が広がったのか

このスレッドが伸びた理由は、「Qwenがまた強い」という単純な話ではない。LocalLLaMAでは以前から、ローカルモデルの体感性能と公開ベンチマークの差に違和感を持つ人が多かった。今回の投稿はそこに数字を与えた。投稿者は、以前の実験で同じローカルQwen系モデルがscaffold変更だけで約 19.11% から 45.56% まで上がったとしたうえで、今回は Qwen3.6-35B-A3B と little-coder の組み合わせでAider Polyglot 225課題中 78.67% を記録したと共有した。クロール時点でスレッドは 689ポイント、167コメント。上位コメントの空気も明確で、「ここまで動くなら、scaffoldを固定しないベンチマーク比較はどこまで信用できるのか」という疑問だった。

リンク先のベンチマーク文書が示したこと

リンクされた文書は、数字だけでなく環境もかなり具体的に出している。Qwen3.6-35B-A3B は 35B total / 3B active のMoEとして記述され、Q4_K_M GGUFは約 22.1GB。実行は llama.cpp、ハードウェアは RTX 5070 Laptop 8GB VRAM、i9-14900HX、32GB RAM。結果は 177 / 225、つまり 78.67% で、文書ではAider Polyglot公開リーダーボードの上位10位帯に入る水準だとしている。言語別ではJavaScript 89.8%、Python 88.2%、C++ 84.6%、Java 76.6%、Go 74.4%、Rust 53.3%と報告された。

なぜモデルよりscaffoldが話題になったのか

重要なのは、改善の中身がretry頼みではないことだ。文書では大きな差分のほとんどが 初回試行での成功 から来ている。つまり、失敗後の立て直しより、最初からモデルがうまく動くようにしたscaffold側の設計変更が効いている可能性が高い。以前のlittle-coder説明では、whole-file overwriteを防ぐwrite guard、bounded thinking、workspace discoveryの明示、ローカルモデル向けに小さく絞った補助情報注入などが挙げられていた。コメント欄でもそこが主論点になった。「ツールと環境がモデルと同じくらい重要になってきた」「ローカルモデルはfrontier前提のharnessでは不利に測られていたのではないか」という反応が多かった。

なぜ重要か

この投稿の意味は、特定のQwen実装が一時的に勝ったことではない。もっと大きいのは、scaffoldが単なる実装詳細ではなく 一級の評価変数 として前面に出てきたことだ。ローカルモデルが比較的限られたハードウェアでここまで伸びるなら、従来の「小さいローカルモデル対クラウド最前線モデル」の比較にはwrapper mismatchがかなり混じっている可能性がある。LocalLLaMAが面白がったのもそこだった。スレッドの実際の熱量は「Qwenが強い」以上に、「今まで見ていたベンチマークはモデルだけを測っていなかったのではないか」に向いていた。

出典: little-coder benchmark doc · supporting write-up · Reddit議論