パックマン・ベンチマーク：Qwen 3.6 27Bでついに実用的なローカルのエージェント型コーディングエージェントが可能に

新しいモデルをテストするのに、私が好きなやり方の1つは、（良いプロンプトで）古典的なアーケードゲームであるパックマンの「1つのWebページクローン」をワンショットで生成させることです。通常は3回試して、その中で一番良いものを採用します。これまでのところ、これらのうち（anthropic、chatgpt、googleの各モデルを含めて）はすべて失敗しており、多くはひどいレベルでの失敗でした。今までで最良だったのはGLM 5.1です。

それがQwen 3.6 27b F16で試すまでは。3回の試行のうち2回は圧倒的にベストで、トップ結果にも軽微な誤りがある程度でした！しかし、8bit量子化に落とした途端、5回以上試しても同じ良い結果を再現できませんでした。これは、私がこれまで長い間経験に基づいて言ってきたことを裏付けています：16bitと8bit量子化には、想像以上の大きな違いがあるのです。たとえ多くの人が、（損失がない、あるいは）ほぼ損失がないと主張していても。

結果があまりに良かったので、ちょうどそのとき私は llama.cpp の MTP speculative decoding PR（当時はまだマージされていません）を、自分自身の量子化版でテストしていて、さらに Qwen 3.5/3.6 用の自作の固定jinjaチャットテンプレートを開発していたこともあり、では Qwen 3.6 27b F16 をきちんとしたエージェント型のコーディングワークフローで押し切ってみればどうなるのだろう、と思いました。結果は素晴らしく、見れば分かります。ここで完全な1ページゲームを試せます：

https://guigand.com/pacman

学んだこと／観察：

* 良いチャットテンプレートは極めて重要です。公式のチャットテンプレートは、vLLMのみに向けた設計だったため、他のツールでは使い物になりませんでした。その結果、他のツールではエラーだらけです。最初はコミュニティのテンプレートから始めましたが、改善されてはいるものの、まだ多くの癖がありました。だからこそ、公式テンプレートのバグを1つずつ直し、ゆっくりと改善を進めました。エージェントセッションの初期は、癖やエラーが多くてつらいものでした。しかし徐々に良くなり、テンプレートがうまく調整できたところで、モデルの中に新しいレベルの知能を「解放」できたように感じました。

* MTP speculative decoding は、すべてのタスクを同じようには加速しない。基本的には、コードのような決定的タスクでは最も効率的で、ブレインストーミングのような創造的タスクでは最も効きにくいです。これについてはここでも書きました：https://www.reddit.com/r/LocalLLaMA/comments/1t9gcar/mtp_benchmark_results_the_nature_of_the/。このパックマン開発では、生成トークン/秒（generative tok/s）はタスクによって8 tok/sから18 tok/sの範囲で変動しました。参考として、MTPなしだと同じモデルと量子化設定で6.6 tok/sです。

* ハーネスはコード品質だけでなく、速度への影響という点でも同等ではない。私たちの多くは、コーディング用ハーネスが品質に大きな影響を与えることはすでに知っていると思います。特にClaude Codeはゴールドスタンダードと見なされており、私は普段の通常のデイリーコーディングにはそれを使っています。このケースでは、チャットテンプレートの問題があったためQwen CLIから始めました。理由は単純で、Qwen LLMの細部をよりうまく扱える可能性が高いハーネスがあるとすれば、それは（おそらく）自分たちのハーネスだろう、という考えでした。実際、いい意味で期待を裏切られました。そしてQwen CLIは、私が予想していたはるか以上の成果を出しました！その後の段階では、最終的なチャットテンプレートがClaude Code側でも正しく動いているかを確認するため、主にClaude Codeに戻しました。そこで改善されたプロセスやコード品質は特に見つかりませんでした。ですが私が気づいたのは、Claude Codeでの開発はQwen CLIよりかなり遅いということです！これはClaude Codeの中に組み込まれている追加のプロンプトが多いためです。tok/sが非常に遅いローカルモデルでは、この差が「実用になるかどうか」と、「ギリギリで髪を引っ張りたくなる領域かどうか」を分けることがあります…

* このモデルではコンテキスト管理とキャッシュが非常に効率的です。それを邪魔しないでください。うまく動きます。自分の仕事をさせておけばいい。キャッシュやコンテキストを操作するスキル、プラグイン等は使わないでください。これをすると、モデルが混乱し、より愚かになり、エラーが起きやすくなります。

* ツール呼び出し、コンテキストのコンパクション、シェルの使用、サブエージェント、並列サブエージェントが完璧に動く。ただ最初から完璧だったわけではなく、チャットテンプレートの修正と改善を通して正しく動かすのに、かなり時間がかかり、多くの作業を要しました。実際、context compactionはテスト目的でのみ使いましたが、Claude Codeでいつも通り問題なく使えました。

* 高いコンテキストでも、過度な劣化なしに使える。最大コンテキストサイズは256kトークンだと思います。大半の時間はタスクが100k未満に収まるように計画していましたが、150kをわずかに超えることが数回ありました。能力がわずかに落ちるのは気づきましたが、大きな問題ではありません。コンテキストを低く保とうとした主な理由は、他のすべてのモデルと同様に、最高の推論能力を得るためです。しかし、コンテキスト使用量が増えるにつれて速度も低下し始めました。

* Geminiを除けば、音声の知識で私を感心させた最初のモデルです。作曲家、ミュージシャン、心理音響の科学者、音響エンジニアとして、私は良い音声にかなり注意を払います。今回のケースでは、いくつかの高度な音声操作と生成をさせました。ゲーム内の音声はすべて、Qwenが高度で複雑な方法でWeb Audioシンセサイザーをプログラムしていることによるものです。これはmidiではありませんし、単純なウェーブテーブルでもなく、サンプルでもありません。調和成分（harmonics）、ディストーション（distorsion）、レイヤー、さまざまなエフェクトの利用によって、人間の聴覚に合わせてチューニングされた心理音響的な特性を考慮しています。まさに素晴らしい仕事です。唯一の例外はワカワカ音（waka-waka sound）で、これはサンプルを使うようにする必要がありました（同じ方法が元のアーケードゲームでも使われています）。

* トークン生成速度が遅くても私は問題ないです。以前は、実用的な開発のためには最低でも70〜80 tok/sが必要だと思っていました。しかしこれは実際に使えました。並行して他のことをする時間ができ、さらにエージェント的タスクについてよりよく考えられるようにもなりました。現状の私のハードウェアでは、大規模プロジェクトに使うかは微妙ですが、小〜中規模のプロジェクトなら確実に許容範囲です。

ここまで読んでくれたなら、あなたの考えを教えてください。そして、このゲームを楽しんでもらえれば嬉しいです。

開発環境：macOS、apple silicon M2 max、96GB RAM、llama.cppサーバーでOpenAIおよびAnthropic APIエンドポイント。