同じフライトシムのプロンプトでローカルLLM 9モデルを検証:Q8でも量子化プロバイダや実装差がゲームを左右する

Reddit r/LocalLLaMA / 2026/4/22

💬 オピニオンTools & Practical UsageModels & Research

要点

  • 著者は、M3 Max環境(MLX/Claude Code)で、同一で再現可能なフライトコンバット用プロンプトを9種類のローカルLLMに与え、「最終までのプロンプト数」と実際にゲームとして成立しているかを基準に評価した。
  • 量子化は“ビット数”よりも“量子化プロバイダ/実装方式”の影響が大きいことが示され、同じQwen3.6 35Bの8-bit量子化でも提供元が異なるとゲームの挙動やデバッグの難易度がはっきり変わった。
  • 出力の行数(コード量)と品質の相関は弱く、最良は少ないプロンプト数・少ない行数で出てきた一方、最悪は最も多いコード量にもかかわらず成立しにくい結果になった。
  • Qwopus 3.5 27Bのみが実際の飛行物理に近い要素(推力/抗力、速度減衰、機体ごとの定数差)や手続き的オーディオまで実装し、蒸留や学習の違いがパラメータ規模以上に効く可能性を示唆した。
  • 全体として、「8-bitなら十分」や「大きいほど自動的に良い」といった前提が揺らぎ、量子化パイプラインやツールの実装差が実用結果を左右することが浮き彫りになった。

同じフライト戦闘シムのプロンプトを、ローカルモデル9個に対して与えました。結果は、量子化プロバイダとパラメータ数についてのいくつかの前提をいくつか壊してくれました。

すべて8-bit MLX、M3 Max 128GB、omlx経由で提供。Claude Codeを通してプロンプト。毎回同じプロンプト――単一ファイルのHTML、3つ選べる機体(ジェット、プロペラ、モデルの選択によるワイルドカード)、動的な敵、トレーサー、ダメージ、そして損失時のクラッシュスパイラル。プロンプト数から最終結果までを数え、「実際に遊べるか」で採点しました。

https://alextzk.github.io/flight-combat-llm-comp/ <- ここでゲームを遊べます

ラインナップ:

  • Gemma 31B dense unsloth
  • Gemma 4 26B a4b unsloth
  • Qwen3.5 27B dense
  • Qwen3.5 35B A3B MoE
  • Qwen3.6 35B A3Bを3種類の量子化で(oMLX、Unsloth、MLX Community)
  • Qwen3 Coder Next 80B
  • Qwopus 3.5 27B

意外な発見:

1. 量子化プロバイダは、ビット幅よりも重要。 同一のQwen3.6 35Bに対して、8-bit量子化を3種類適用したところ、意味のあるほど異なる3つのゲームが生成されました。Unslothは3プロンプトで完璧でした(1,304行、動作するミニマップ、丸い惑星、そして私がEnterを押す前にモデル自身がコードのバグを見直していた)。MLX Communityは4プロンプトで問題なしでした。oMLXは5プロンプトのデバッグ地獄――操作がラバーバンドのようにニュートラルへ戻り、3回試してもモデルは理由を特定できませんでした。同じベースモデル。同じ8-bitですが、UXが違う。「8-bitだから」は量子化の説明として不十分です。

2. 行数は、品質とはほぼ無相関。 勝者(Qwopus 3.5 27B)は、1,049行で2プロンプト提出されました。敗者(Qwen Coder Next 80B)は、1,635行で3プロンプト提出――誰よりも多くコードを書きつつ、カメラが過敏、敵なし、そして機体が180°回転していました。80Bの兄弟モデルはGemma 31B denseの3倍のコードを生成し、さらに悪いゲームを仕上げました。

3. Qwopusだけが、実際の飛行物理を実装していた。 誰もそれを求めていません。にもかかわらず、ただやり遂げました――推力/抗力を機体ごとの空力定数で統合し、フレームごとの速度減衰も入れています。F-16は定数が違うからMustangとは加速が異なる、という具合です。さらに、唯一手続き型オーディオも実装していました(エンジン周波数を対気速度比で変調)。2プロンプト。これはOpusの蒸留がちゃんと仕事をしていると仮定せざるを得ません。なぜなら、ベースが同じ vanilla のQwen3.5 27B denseは、このラインナップで最悪のゲームを出したからです(同一フレーム内でクォータニオン回転の混在と、直接のEuler書き込みをしてしまい、その結果、落下しながら空中でブレンダーのように回転していました)。操作性は完璧ではないものの、実装の仕方と、そこに追加で作り込まれている他の機能の出来は群を抜いています。

Webオーディオエンジン:ピッチは対気速度比で変調

function updateEngineSound(speedRatio) {
engineOsc.frequency.setValueAtTime(80 + speedRatio * 120, audioCtx.currentTime);
}

// F-16の設定から、速度、推力、抗力
speed: 1200, turnRate: 0.015, climbRate: 0.008, thrust: 0.02, drag: 0.001,

// 更新ループ内
this.velocity.add(forward.multiplyScalar(this.stats.thrust * 1000 * delta));
this.velocity.multiplyScalar(1 - this.stats.drag);

触れておく価値のあるその他のメモ:

- 生成速度:Gemma 4 26B a4bが58.3 tok/sで王者で、QwenのA3B系バリアントのほぼ2倍、denseモデルの約7倍でした。Qwopusは11 tok/s未満で生成しているのに、それでも勝ちました。1トークンあたりの速度は、「動く成果物までの時間」の悪い代理指標です。

- Qwen3.6は3.5に対する明確な前進です。+0.1の差分は、いつも以上に詰まっています――モデルが自分の出力を見直し、生成されたHTMLをあなたのためにブラウザで開こうとします。些細なことですが、積み重なります。

- 「3つ目の機体を選べ」というワイルドカードは、意外なほど良い創造性のテストでした。Qwen3.6 oMLXはAH-64 Apacheを選びました(技術的には機体というより、技術的には最も面白い答え)。ラインナップで最大のモデルであるQwen Coder Next 80Bは、「あなたの選ぶ選択肢」に対して、3機目の戦闘機を出してきました。

- Qwen特有のバグ:機体が180°回転した状態で描画される。ほとんどのQwenバリアントで見られました。

私個人の順位:

  1. Qwopus 3.5 27b dense
  2. Qwen3.6 35b unsloth
  3. Gemma 4 26b unsloth
  4. Gemma 4 31b unsloth
  5. Qwen3.6 35B mlx-community
  6. Qwen3.5 35b mlx-community
  7. Qwen3.6 35b oMLX oQ量子
  8. Qwen3Coder-Next 80B mlx-community
  9. Qwen3.5 27b mlx-community

モデルごとの内訳や、各モデル固有のバグ/癖まで含めた、より詳しくて洒落た(punny)書き直しを見たいという人がいれば、ペイウォールなしの私のMediumページにあります。

各HTMLファイルの先頭には、github上で、Claude Codeに投入した各プロンプトと、ノート(メモ)を提供するコメントがあります。

コメント欄で、特定の結果について掘り下げるのも歓迎です。追試の予定は2つ――10個のバグコードレビューで同じ9モデルを試すこと、そして創造的なタスクは未定です。

追記:ゲームへのリンクを先頭に追加しました。

submitted by /u/StudentDifficult8240
[link] [comments]