Qwythos-9B v2でブラウザゲーム生成は改善した？v1 Q5/Q6/Q8・Claude Opus 4.8と比較

はじめに

以前、GTX 1660 Ti 6GB環境でQwythos-9B-Claude-Mythos-5-1MのQ4_K_M、Q5_K_M、Q6_Kを試しました。短い日本語文章やコード相談だけでなく、簡単な1ファイルHTMLゲームも生成し、長いコードではcontext設定が結果を左右することを確認しています。

今回はRTX 4070 12GB環境へ移し、まず旧版のQ5_K_M、Q6_K、Q8_0を全層GPUオフロードで比較しました。その検証後、反復抑制などを目的とした別モデルQwythos-9B v2が公開されたため、通常版v2 Q8_0も同じ記事へ追加しています。

題材は、プレイヤー移動、ショット、敵、当たり判定、HP、スコア、ウェーブ、一時停止、リスタートを含む2Dシューティングゲームです。

比較で重視したのは、コードが最後まで出たかだけではありません。生成HTMLを実ブラウザで開き、STARTをクリックし、矢印キーやWASD、Space、P、Rを操作して、ゲームとして進むかまで確認しました。

関連記事:

• Qwythos-9BをVRAM 6GB環境で試したQ4/Q5/Q6比較

先に結論

RTX 4070 12GBでは、旧版Q5/Q6/Q8とv2 Q8_0を通常版・全層GPUオフロードで起動できました。v2 Q8_0は初回から機体を描画し、移動まで動いたため、旧版Q8の「START直後に停止」より立ち上がりは改善しています。

ただし、初回はScore: NaN、修正後も敵・弾・得点が動かず、ゲームオーバーとクリアには到達できませんでした。v2になれば長いJavaScriptが自動的に完成品になる、という結果ではありません。

低温度の短い補助試験では、同一文の反復や不要な自己紹介は発生しませんでした。一方、「4見出し×各3項目」という形式には従えず、モデルカードの改善点と複雑な指示追従は分けて見る必要があります。

検証環境

OS: Windows 11 Pro 10.0.26200 64ビット
CPU: Intel Core i7-9700K @ 3.60GHz
RAM: 31.9 GiB
GPU: NVIDIA GeForce RTX 4070
VRAM: 12282 MiB
NVIDIA Driver: 610.62
CUDA表示: 13.3
llama.cpp: version 9789 (b3ce5cedf)
ngl: 999
reasoning: off
実行前VRAM: 914 MiB

旧版に使用したGGUFは、Empero AIが公開しているQwythos-9B-Claude-Mythos-5-1M GGUFです。追加検証には別リポジトリのQwythos-9B-v2-GGUFを使いました。

モデルファイルはQ5_K_Mが約6.47GB、Q6_Kが約7.36GB、Q8_0が約9.53GBでした。

v2 Q8_0は9,527,501,568 bytesで、取得後に公式SHA256SUMSとの一致を確認しています。

v2で何が変わったのか

公式モデルカードでは、Qwythos-9B v2の変更点として次が挙げられています。

• greedy・低温度で起きる反復の抑制
• 不要な自己紹介の整理
• 推論性能の維持
• MTPヘッドの復元

公式値では、対象評価での反復・退化が6.7%から0%になったと説明されています。ただし、これは公開元の評価値です。今回の検証では同じ大規模評価を再現せず、低温度の短い出力で反復と自己紹介が出るかだけを補助確認しました。

また、MTP版は通常版の上位版ではなく、speculative decoding用の別ファイルです。旧版との品質比較を混ぜないため、今回は通常版Q8_0だけを使用しています。

なぜMTP版とBF16を追加しなかったのか

公式配布では、v2 MTP-Q8_0が9.79GB、通常版BF16が17.92GBです。MTP版は生成速度を上げるための別枠で、通常版Q8より賢いモデルではありません。

BF16はRTX 4070の12GB VRAMへ全量を載せられず、CPUと32GB RAMへのオフロードが必要です。Q8_0は公式にもnear-losslessと位置づけられており、今回残った敵生成や状態管理の問題は量子化誤差よりコード設計にあります。そのため、BF16を追加しても記事の結論を変える可能性は低いと判断しました。

同じ2Dシューティングゲームを生成する

旧版3量子化とv2 Q8_0へ同じ条件を指定しました。主な要件は次の通りです。

• 矢印キーまたはWASDで移動
• Spaceでショット
• 敵は複数種類
• 敵・弾・当たり判定を実装
• スコア、HP、コンボ、ウェーブを表示
• Pで一時停止、Rでリスタート
• タイトル、ゲームオーバー、クリア画面を用意
• スマホ向けの画面内ボタンを用意
• 外部ライブラリ、CDN、画像ファイルは使わない
• HTML、CSS、JavaScriptを1つの完全なHTMLにまとめる

生成条件はtemperature 0.6、top-p 0.95、top-k 20、repeat penalty 1.05です。初回はctx 8192を基本とし、会話履歴や出力が収まらない場合はctx 16384へ広げました。

速度とVRAMの比較

VRAMはnvidia-smiの1秒間隔ログで確認しました。OS、ブラウザ、常駐アプリを含む値なので、環境や測定タイミングによって多少前後します。

旧版Q5_K_Mは約50t/s、Q6_Kは約41〜42t/s、Q8_0は約34t/sでした。量子化が重くなるにつれて速度は下がりますが、旧版Q8_0も今回の環境では生成中ピーク約10.4GBに収まりました。

v2 Q8_0は初回37.88t/s、改善35.68t/s、生成・改善会話を通したピークは10,719MiBです。旧版Q8より速い単発値ですが、出力長や会話履歴が違うため、v2が常に約1割高速だとは断定しません。

v2 Q8_0を16K contextで生成中の画面。モデル名、出力tokens、生成速度をブラウザUIで確認しました。

旧版Q5/Q6/Q8のゲーム結果

ここからは旧版3量子化の実ブラウザ結果を順にまとめます。速度表とは異なり、完成度は量子化順には上がりませんでした。

Q5_K_M: HTMLは完走したが、START後に停止

Q5_K_Mの初回出力は7562 tokens、2分22秒でした。保存したHTMLは25,756文字で、</html>まで出ています。改善版も26,407文字で完走しました。

見た目だけを見ると、タイトル画面とHUDは成立しています。しかしSTARTを押すと、Player.update内の未定義参照で更新ループが停止しました。Spaceを押すと、初回はfire is not a function、改善後は弾配列の参照エラーが発生します。

エラー内容と操作不能な項目を具体的に返して再生成しましたが、主要な参照関係は直りませんでした。長いHTMLを最後まで出せることと、そのコードが実際に動くことは別だと分かる結果です。

Q5_K_M改善版の実画面。タイトルとHUDは表示されましたが、更新ループの参照エラーが残り、ゲームは進みませんでした。

Q6_K: 8Kでは途中終了、16Kで部分動作へ

Q6_Kの初回出力は7779 tokens、3分04秒でした。ただしJavaScriptの途中で出力が終わり、HTMLの閉じタグもありません。実ブラウザではタイトル、GAME OVER、ALL CLEARなど複数の画面が重なり、STARTやキー入力で進行しませんでした。

ctxを16384へ広げて再生成すると、7131 tokens、2分48秒で完全HTMLになりました。STARTとP、TRY AGAINは動いたものの、タイマーが実時間より大幅に速く減り、HPが大きな負数になって短時間でGAME OVERになります。

そこでdelta time、同一フレームでの多重ダメージ、HP下限、機体・敵・弾の可視化、得点・ウェーブ、P/R維持を具体的に指定しました。

最終改善版では、タイマーとHPの異常値が解消し、PでPAUSED表示、再度Pで復帰、RでTIME 59 / WAVE 1への再開、GAME OVER表示まで確認できました。操作中のコンソールエラーもありません。

一方、機体は画面左上へ寄り、左右キーとSpaceを入力しても敵、弾、得点を明瞭に確認できませんでした。約10秒でスコア0のまま撃破され、射撃ゲームとして遊べる状態には届いていません。

Q6_K最終改善版のPAUSED画面。8K初回のHTML切れから16Kへ広げ、具体的な修正指示を返すとP/Rは動くようになりました。

Q6_K最終改善版のGAME OVER画面。画面遷移は改善しましたが、スコアは0のままでした。

Q8_0: 8Kでも完走、修正で描画は改善

Q8_0の初回は6591 tokens、3分09秒、21,842文字でした。Q6_Kと違い、ctx 8192のまま完全HTMLを出せています。

ただしSTART後は星空だけになりました。コンソールには、ゲームループでplayer.update()を呼んだ時点でplayerが未生成というエラーと、画面切り替え処理が存在しない要素のclassListを参照するエラーが出ています。PでPAUSED画面は出ましたが、Rでは正常にゲームを再開できませんでした。

Q8_0初回の実画面。HTMLは最後まで出ましたが、START後は星空だけになり、プレイヤー未生成のエラーで停止しました。

実測した2件のエラーに加え、player初期化、画面IDの整合、ゲームループ開始順、P/R、敵・弾・得点、requestAnimationFrameの重複防止を指定し、ctx 16384で改善版を生成しました。

改善版は6815 tokens、3分20秒、22,239文字で完走しました。START後にHUD、プレイヤー、HPバーが表示され、P一時停止と復帰、Rでタイトル画面への完全リセットが動きます。操作中のコンソールエラーもなくなりました。

Q8_0改善後の実画面。HUDとプレイヤーが表示され、P/Rも動くようになりました。

しかし、約15秒の実プレイと40回のSpace入力でも、敵、弾、得点は出ませんでした。画面はSCORE 0 / WAVE 1のままです。

コードを照合すると、最初のフレームで敵生成に失敗した場合にwaveCleared=falseとなり、以後spawnEnemy()が永久にreturnする状態遷移になっていました。実画面で敵が出なかった結果と一致します。

Q8_0改善後のPAUSED画面。致命的な参照エラーは解消しましたが、ゲーム進行ロジックには別のバグが残りました。

v2 Q8_0: 初回の立ち上がりは改善、ゲーム進行は未達

v2 Q8_0は、旧版の結果を残したまま別モデルとして追加しました。公平性を保つため通常版Q8_0、ctx 16384、同じゲーム生成プロンプト、同じsampling設定を使用しています。

初回は5,602 tokens、2分27秒、17,774文字で完全HTMLになりました。タイトルからSTARTを押すと、旧版Q8のように未定義playerで即停止せず、HUDとプレイヤー機体を表示し、矢印キーによる移動まで確認できました。

v2 Q8_0初回版。旧版Q8より先へ進み、機体とHUDを描画しましたが、スコアは開始直後からNaNでした。

一方、Spaceを20回入力しても、弾、敵、得点、ウェーブ進行は画面上で確認できません。HPも100%のままで、ゲームオーバーには進みませんでした。Pは進行停止だけでPAUSED表示がなく、Rもプレイ中には動きません。

実画面の結果とコードを照合すると、スコア初期化、敵の継続生成、弾と敵の当たり判定、敵衝突時のプレイヤーダメージが不足していました。コンソールエラーは0件ですが、エラーが出ないこととゲームロジックが成立することは別です。

これらを具体的に伝えて1回だけ修正を依頼すると、改善版は8,161 tokens、3分48秒、25,958文字で完走しました。Score 0、Time、Wave、残数、Combo、HPが表示され、PでPAUSED、再度Pで復帰、Rでタイトルへの完全リセットが動きました。

v2改善版ではPAUSED表示とRリスタートまで改善しました。

しかし、ページ読み込み直後に未定義playerのdraw()を呼ぶTypeErrorが1件発生します。START後は別のループで描画が再開するものの、敵生成関数がゲームループから呼ばれず、プレイヤー弾も画面下方向へ進む実装でした。Spaceを30回入力しても敵、弾、得点、HP変化は確認できず、クリアとゲームオーバーには到達できませんでした。

今回の単発結果では、v2は旧版Q8より「初回から画面が動く」ところまで改善しました。ただし、最終的な完成度は両方とも中未満です。

ここでの完成度は、指示反映、表示、移動、射撃、敵、当たり判定、スコア、HP、画面遷移、JavaScriptエラーを実ブラウザで確認した筆者の主観評価です。厳密なベンチマークや統計的なモデル評価ではありません。

低温度の反復・自己紹介も確認

v2の公式変更点に合わせ、temperature 0、repeat penalty 1.0で700〜900字の実務メモも生成しました。

464 tokens、10秒、42.93t/sで完走し、同一文・段落の反復、モデル名、開発元、不要な自己紹介はありませんでした。この1回の出力は公式の改善内容と整合します。

ただし、指定した「4見出し×各3項目」ではなく段落形式になり、903文字で上限もわずかに超えました。反復がないことと、細かな形式指定を守れることは別の評価軸です。

参照枠: Claude Opus 4.8最大では初回版が完走

クラウド上位モデルの完成度上限を見るため、Claude Opus 4.8を工数最大に設定し、同じプロンプトを入力しました。ローカル実行ではないため、tokens/sやVRAMは比較しません。

Opus 4.8最大は回答本文が始まるまで約14分かかり、HTML作成、自己テスト、会話圧縮まで含めると20分を超えました。Qwythosの2〜3分台より大幅に長い待ち時間です。

一方、Claudeは固定タイムステップ、状態機械、オブジェクトプーリング、入力抽象化などの設計方針を立て、HTMLからJS/CSSを抽出し、構文、DOM参照、jsdom実行時エラーを確認するテストまで自発的に行いました。

生成された「Orbital Lance」は81,877文字です。実ブラウザでは、NORMALの手動操作で敵、自弾、敵弾、当たり判定、スコア、HP、コンボ、パワーアップ、P一時停止、Rリスタートが動きました。

EASY＋オート連射ではWave 5の大型ボスを撃破し、2分15秒でMISSION COMPLETEへ到達しました。Total 22,414、Max Combo 15、Accuracy 16.1%です。HARD＋オート連射OFFでは36秒でHP 0となり、GAME OVER、RETRY、TITLEも正常に表示されました。操作中のJavaScriptエラーは0件でした。

Opus 4.8最大の初回版でWave 5ボスへ到達。PWR 5 MAXの多方向ショットと弾幕が正常に動きました。

改善指示なしでMISSION COMPLETEへ到達。ローカルQwythosとの速度比較ではなく、クラウド上位モデルの完成度上限として扱います。

比較で分かったこと: 量子化差とモデル更新は別

旧版の単発検証では、Q8_0は8Kでも完全HTMLを出し、修正指示に対してplayer初期化やnull参照、P/Rを改善できました。その意味では、Q6_Kより出力の収まりと修正反映がよい部分があります。

ただし、最終的なゲーム完成度が量子化順に上がったわけではありません。旧版Q5_K_M、Q6_K、Q8_0のいずれも、そのまま遊べる完成品には届きませんでした。

v2は量子化ではなくモデル更新です。旧版Q8より初回の描画と移動で改善しましたが、敵生成、弾、得点、当たり判定には別のバグが残りました。反復抑制を目的とした更新が、複雑なJavaScriptの正しさを自動的に保証するわけではありません。

これは、長いコード生成では1か所の参照ミスや状態遷移ミスがゲーム全体を止めるためです。見た目が整い、HTMLが最後まで出ていても、実際にSTARTを押し、移動、射撃、敵出現、当たり判定、スコア、ゲームオーバー、リスタートを順番に確認する必要があります。

ctxは出力の余白としても重要

Q5_K_Mでは、初回回答を含む改善プロンプトが8192 tokensを超えたため、ctx 16384へ変更しました。Q6_Kの初回は8Kの出力上限でHTMLが途中終了し、16K再生成では完走しています。

一方、Q8_0の初回は8Kでも完全HTMLになりました。ただし改善会話では、前の回答と修正指示を含めるため16Kへ広げています。

v2 Q8_0は最初から16Kに揃え、初回5,602 tokensと改善8,161 tokensをどちらも完走しました。16Kにしたことで出力切れは避けられましたが、ロジックの正しさまで改善するわけではありません。

1ファイルHTMLのような長い出力では、モデルの量子化だけでなく、入力履歴と出力余白を含めたctx設定が重要です。改善を何度か繰り返すなら、最初から16K以上を選ぶほうが扱いやすい場面があります。

今回の結果から考える使い分け

Claudeの結果はクラウド上位モデルの完成度上限を見る参照枠であり、VRAMやtokens/sをQwythosと直接比較するものではありません。待ち時間、ローカル処理、完成度のどれを優先するかで選択が変わります。

まとめ

RTX 4070 12GB環境では、Qwythos-9B旧版のQ5_K_M、Q6_K、Q8_0と、別モデルのv2 Q8_0を全層GPUオフロードで起動できました。旧版の生成中ピークはQ5が約7.7GB、Q6が約8.6GB、Q8が約10.4GBです。v2 Q8_0は生成・改善会話を通して最大10,719MiBでした。

旧版Q8_0は8Kでも完全HTMLを出し、v2 Q8_0は初回から機体表示と移動まで進みました。v2の短い低温度試験では反復と不要な自己紹介もありませんでした。

それでも、v2改善版には読み込み時エラーと敵生成・弾方向の問題が残り、射撃ゲームとしては進みません。今回の結果では、「上位量子化なら完成品に近づく」「v2なら長いゲームコードが完成する」と単純には言えませんでした。

それでも、タイトル、HUD、プレイヤー、画面遷移を含む2万文字規模のたたき台を数分で作れる点は魅力です。ローカルLLMをゲーム制作補助に使うなら、最初の構成とコードを作る相手として活用し、実ブラウザでの操作確認とデバッグは人間側で行う、という分担が現実的です。

より小さい1B級モデルで、日本語、コーディング、Tool Calling、長文、HTMLゲームまで比較した結果は、656 MiBのMiniCPM5-1BをOllamaで検証した記事にまとめています。

参考リンク

• Qwythos-9B v2 本体モデルカード
• Qwythos-9B v2 GGUF配布ページ
• Qwythos-9B旧版GGUF公式モデルカード
• VRAM 6GB環境でのQwythos Q4/Q5/Q6検証