16GBのGPUで動く2ビット版Qwen 27B、アプリとゲームは得意で3Dに課題

270億パラメータのモデルを2ビット精度まで縮めても、16GBのグラフィックスカード1枚で実際の開発作業をこなせます。Qwen3.8 27Bの2ビット版であるQwen3.8-27B-Escha-W2は、重みに約10GBしか必要としません。9項目のテストでは、256kトークンのコンテキストに隠したパスキーを15回の試行すべてで見つけ、コーディング問題100問のうち75問に合格し、ほとんど手助けなしで動くWebアプリやゲームを作りました。一方で、2ビット量子化の代償も見えました。3Dアセットの仕上がりと、特定のフレームワークに依存するゲームコードの正確さです。控えめなハードウェアで大きなモデルをローカル実行したい人にとって、この結果が何を意味するのかを整理します。

2ビット化した27Bモデルの中身

量子化とは、モデルの重みの数値精度を下げてメモリ使用量を減らす手法です。Qwen3.8-27B-Escha-W2はQwen3.8 27Bを2ビットに量子化したファインチューニング版で、元の重みは10.15GBです。16GBや24GBの一般向けGPUに載せても、モデルが作業中に参照するテキストであるコンテキストのための空きが十分に残ります。

このモデルはHugging Faceで、推論エンジンllama.cppが使うファイル形式GGUFとして、2種類のビルドが公開されています。

精度の差はごくわずかなため、テストにはQ8_0ビルドを使いました。オプションとして2.93GBのMTP（マルチトークン予測）ドラフトモデルもあり、補助モデルが数トークン先を推測する投機的デコードで生成を速められます。ただし、16GBのうちできるだけ多くをコンテキストに回すため、今回は使っていません。

テスト環境と9つの課題

モデルはUbuntu Server 24.04.4上のllama.cppで動かし、CPUはAMD Ryzen 5700X、メモリはDDR4 32GBです。対象GPUは16GBのVRAMを備えたNVIDIA RTX 2000 Adaです。もう1枚のRTX 5090は、テストの自動化を速めるためだけに搭載しました。

9つの課題は4つのグループに分かれます。

1. 性能：プロンプト処理と生成の素の速度
2. 記憶：非常に長いコンテキストからの情報検索
3. 問題解決：難易度別の推論問題とコーディング問題100問
4. 開発：かんばんボードのWebアプリ、落下する砂の物理サンドボックス、ダンジョン探索ゲーム、そしてMCP（Model Context Protocol、AIモデルが外部ツールを使うための標準規格）でBlenderとGodotを操作する2つのエージェント課題

▲ ローカルモデルの9つのテスト

速度を左右するのは主にカード

プリフィルはモデルがプロンプトを読み込む速さ、デコードは回答を書き出す速さです。

毎秒約11トークンというデコード速度は実用的ではあるものの速くはなく、主な原因はGPUにあるようです。RTX 2000 Adaは70ワットのワークステーション向けカードで、メモリ帯域幅は毎秒225〜250GBです。RTX 4080やRTX 4070 Ti SuperといったRTX 30、40、50シリーズの一般的な16GBデスクトップ向けカードは電力上限が高くメモリも速いため、同じモデルでもはるかに速くトークンを生成できるはずです。

長いコンテキストの記憶、推論、コーディングのスコア

記憶テストにはNeedle-in-a-Haystackの手法を使いました。コンテキストを256,608トークンまで広げ、テキストの0%、25%、50%、75%、100%の位置に秘密のパスキーを隠します。各位置で3回、合計15回の試行を56分36秒かけて行いました。モデルは毎回パスキーを見つけ、合格率は100%でした。回答には余分な思考過程やおしゃべりが付き、深い位置ほど少し長く雑然としましたが、抽出した答えは常に正確でした。

推論問題は論理、計画、確率を扱い、所要時間は16分50秒でした。HumanEval RemixはOpenAIのHumanEvalベンチマークを基にしたPythonの課題100問で、1時間8分かかり、平均応答時間は41,067ミリ秒でした。このサイズのモデルを2ビットまで圧縮したことを考えると、推論79%、コーディング75%は堅実な結果といえそうです。エキスパート難度で大きく落ち込む点は、難しい論理問題を任せる前に念頭に置いておく価値があります。

開発課題：アプリとゲームは得意、3Dはやや苦手

Webアプリとシミュレーション

かんばんボードは、To Do、In Progress、Doneの各列の間でのドラッグ・アンド・ドロップ、列の並べ替え、ダイアログでのカード編集、優先度ラベル、ダークテーマとライトテーマに対応しました。最初のビルドの唯一の欠陥は、Add Columnボタンにクリックリスナーが設定されていなかったことです。ボタンが反応しないと1回伝えると、モデルは漏れに気づいてJavaScriptファイルを修正しました。デフォルトの見た目は目を引くほどではないものの悪くなく、機能面のコードは高品質でした。

落下する砂のサンドボックスはセル・オートマトン、つまり各セルが単純な規則で更新されるグリッドです。砂が積もり、水が斜面を流れ落ち、酸が壁と砂の両方を溶かしました。ブラシサイズの変更、消しゴム、クリアボタンもすべて動作し、修正は不要でした。

手続き型生成のゲーム

ダンジョン探索ゲームではアルゴリズムの能力を試しました。モデルはマップを長方形に繰り返し分割するバイナリ空間分割を選び、つながった部屋と通路を配置しました。ブレゼンハムの直線アルゴリズムでプレイヤーから最大9マスまで視線を飛ばし、プレイヤーの移動に合わせてマップを明らかにしながら、未探索、探索済み、現在見えているマスをそれぞれ違う色で表示しました。スポーン地点を2回選んでしまう自らのバグにも気づいて修正しています。追加の指示は不要でした。

▲ ゲームのロジックと3Dアセットの品質

MCPによるエージェント課題

MCPの課題では、2ビット精度の限界がよりはっきり表れました。Blenderでは、六角形のフレーム、とがった屋根、吊り下げ用のリング、内部の光源を備えたランタンを作り、4方向からレンダリングしました。内部の光は明るすぎ、上部のフックは取り付け用の球を回り込まずに食い込んでいました。モデルはシーンの保存とBlenderのヘッドレス実行を何度も繰り返して行き詰まり、スクリーンショットを直接求められてからようやく先に進みました。

最も難しい課題であるGodotのプラットフォーマーでは、集める鍵、動く障害物、ゴールが求められました。最初の版は両方向の操作が反転しており、穴をふさぐ物体には衝突判定がありませんでした。さらにGodot 4に存在しない衝突プロパティを使ったため崩れる足場のスクリプトが壊れましたが、コライダーのdisabledフラグに切り替えて修正しました。3回の修正指示と2回のコンテキスト圧縮を経て、ゲームは完全に遊べる状態になりました。

16GBで大きなモデルを動かす前に押さえたいこと

今回の結果からは、2ビット版はシステムメモリにあふれることなく、16GBのGPU1枚で27Bモデルを動かす現実的な方法といえそうです。長い文書からの検索や日常的なWeb開発では、品質の低下はほとんど感じられません。見た目の完成度が求められる3D作業や、特定のフレームワークの文法に厳密に従う必要があるコードでは、ハードウェアが許すならQ4やQ5の量子化のほうが明らかに優れています。

このようなモデルをローカルで動かすなら、次の点を確認しましょう。

• 16GBのカードではF16よりQ8_0 embed・headビルドを選び、2GB以上のVRAMを節約する。
• メモリに余裕がないときはMTPドラフトモデルを使わず、その分をコンテキストに回す。
• 生成速度はカードのメモリ帯域幅でほぼ決まるため、まずそれを確認する。
• 生成されたアプリに小さなバグがあれば、どのボタンが反応しないかなど症状を具体的に伝える。
• MCPの作業中にモデルが同じコマンドを繰り返したら、中断して出力ファイルを直接求める。
• Godot 4のようにバージョンによって仕様が違うツールのコードは、存在しないプロパティを使っていないか確認する。