Qwen 3.6 27B F16がパックマンコーディングテストに合格、しかし8ビット量子化では失敗——テンプレートとMTP投機的復号化に関する重要な教訓

r/LocalLLaMAの開発者が実用的なコーディングベンチマークを共有した。良いプロンプトからシングルページのPacmanクローンを一発生成し、3回試行して最良のものを採用するというものだ。Qwen 3.6 27B F16は2回の試行でほぼ完璧なゲームを生成——ローカルモデルとしては初の成功例だ。しかし、8ビット量子化に落とすと、5回試行しても良い結果は再現できず、複雑な生成タスクにおいて8ビット量子化はロスレスではないという主張が裏付けられた。

投稿から得られた主要な技術的知見：

• チャットテンプレートが極めて重要： 公式のQwenチャットテンプレートはvLLM向けに調整されており、llama.cppやその他のランナーでエラーが含まれている。著者が反復的にバグを修正したところ、微調整後、モデルが「新たなレベルの知能」を感じさせるものになった。
• MTP投機的デコードの速度向上はタスクによって異なる： コーディングのような決定論的タスクでは、生成トークン数/秒は8〜18 tok/s（MTPなしのベースライン：6.6 tok/s）。創造的タスクでは加速効果が少ない。
• ハーネスの選択はコード品質よりも速度に影響する： Qwen CLIは驚くほどうまく機能した——出力品質はClaude Codeに匹敵するが、Claude Codeの余分なプロンプトがローカルモデルを遅くするため、はるかに高速だった。Qwen 3.6 27Bのような低速モデル（約6 tok/s）では、余分なプロンプト毎に苦痛なレイテンシが追加される。
• コンテキスト管理に干渉しないこと： モデルのネイティブなコンテキストキャッシュとコンパクションはうまく機能する。キャッシュやコンテキストを操作するプラグインやツールはモデルを混乱させ、パフォーマンスを低下させる。
• ツール呼び出しとサブエージェントは 適切なチャットテンプレート修正後は完全に機能する。コンテキストコンパクション、シェル使用、並列サブエージェントもすべて期待通りに動作する。

著者は、ランナーの設定に大きく依存するため、F16ウェイト、修正済みチャットテンプレートを使い、高速推論ができない限り重いハーネスを避けるよう警告している。完全なプレイ可能なPacman結果はguigand.com/pacmanで入手可能。