Gemma4 ローカルLLM DGX Spark llama.cpp 最適化 Qwen3.6 比較 LLM OOM 解決
🔍 結論から: 巨大モデルをすべて取り払いました
結論から言います。2ヶ月のあいだDGX SparkでGemma4 ローカルLLMの運用構成を取り替え続けた末に、私は巨大なコーダーモデル（Qwen）を丸ごと降ろし、小さくて速いGemma4 26B（アクティブ4BのMoE）ひとつだけを残しました。華やかな80B・35Bのコーダーたちをすべて見送り、14.25GBの量子化モデル1個に落ち着いたのです。
最初は私も「大きいほうが賢いから大きいものを使おう」という立場でした。ところが実測データは正反対を指していました。小さなGemma4のほうがデコード速度は3〜12倍速く、実務品質はほぼすべて互角以上だったのです。この記事は、その2ヶ月の試行錯誤とOOM、そして意外な結論までを運用者視点でそのまま綴った開発ログです。すべての数値は推定ではなく、私のDGX Sparkで直接計測した一次実測値です。
📋 なぜローカルLLM、そしてなぜDGX Sparkだったのか
私はコーディング補助と文書処理をローカルで回したいと思っていました。難しい推論はフロンティアモデル（Claude）に任せるとしても、細かくて量の多い作業まですべてAPIに送るとコストもレイテンシも負担になるからです。そこで選んだのがNVIDIA DGX Sparkでした。初期セットアップの過程が気になる方はDGX Spark セットアップ記録も参考にしてみてください。
DGX SparkはGB10 Grace Blackwell Superchipに128GBの統合メモリ（LPDDR5x、帯域幅273GB/s）を載せたデスクトップAIマシンです。2025年10月に$3,999で発売されましたが、その後メモリ（DRAM）価格が急騰したことで2026年2月に$4,699へ値上げされました（NVIDIA公式の引き上げ）。肝心なのはCPUとGPUが同じメモリプールを共有する点です。おかげで70B級のモデルもVRAMへのコピーオーバーヘッドなしに丸ごと載せられます。ただしOS予約分を除くと実利用は概ね121GiB程度なので、この「天井」が後で私の足を引っぱることになります。
Gemma4 26B-A4Bの「A4B」はアクティブ4Bを意味します。全体26Bのうちトークンごとに4Bだけが実際にオンになるMixture-of-Experts構造なので、26Bというサイズの割にずっと速く動きます。
🛠️ 2ヶ月の進化アーク: モデルを5回取り替えました
一度で落ち着いたわけではありません。ベースラインから現在まで5段階を経ました。各段階ごとに「なぜ乗り換えたのか」があるので、まず表でお見せします。
| 段階 | 時期 | 主力コーダー(Qwen) | 補助(Gemma) | 主要実測 | 乗り換えた理由 |
|---|---|---|---|---|---|
| Pre | ~04-04 | Qwen3.5-122B-A10B Q5_K_M | (なし) | 23.7 tok/s, ctx 200K | 最適化前のベースライン |
| S1 | 04-04~04-19 | Qwen3-Coder-Next 80B-A3B MXFP4 (~45GB) | gemma-4-26B-A4B MXFP4 を追加 | Qwen 50.98 tok/s | 122B→80B: 速度 +115%、サイズ 81→45GB |
| S2 | 04-19~05-19 | Qwen3.6-35B-A3B NVFP4 (~25GB) | (同一) | ctx 1M, SWE-bench Pro 44→49 | 半分のサイズ + オムニモーダル + 推論スコア上昇 |
| S3 | 05-19~06-10 | Qwen3.6-27B dense → MTP | (同一) | Qwen 28~40 / Gemma 55~56 | 35Bが1M ctxでOOM → ダウンサイズ |
| S4 (現在) | 06-10~ | 廃止 (~99GB 回収) | gemma-4-26B-A4B-it-qat-UD-Q4_K_XL (14.25GB) | デコード 109.3 tok/s | Gemmaが3~12倍速く実務互角以上 |
始まり: 122B単独は「使えない」でした
最初はQwen3.5-122Bを単独で載せました。ところが23.7 tok/s。一文字一文字落ちてくる速度がもどかしくて、とても実務には使えませんでした。そこでより小さく速いQwen3-Coder-Next 80Bに替え、横にGemma4 26Bを補助として付けたデュアル構成にしました。2つのモデルをそれぞれ8080・8081ポートのllama.cppインスタンスとして立ち上げたわけです。このときQwenの速度が23.7 → 50.98 tok/sへと+115%跳ね上がりました。サイズも81GBから45GBに減りました。
どちらも4ビット量子化フォーマットです。NVFP4は16個単位のブロック + 2段スケールで、MXFP4（32個ブロック）よりも細かく値の範囲を合わせるため量子化誤差がより小さくなります。
欲張りの段階: 「より賢いコーダー」を追い求めました
ここで欲が出ました。より賢いコーダーが欲しくてQwen3.6-35B-A3Bに乗り換えました。35Bですがアクティブは3BのMoEなので軽く、YaRNでコンテキストを1Mまで伸ばせて、オムニモーダルでSWE-bench Proスコアも44→49へ上がっていたからです。半分のサイズでより賢いのなら、乗り換えない理由はありませんでした。途中でvLLM（NVFP4）も少し挟んでから再びllama.cppに戻ったのですが、その理由は私の記録に残っていないので、ここでは断定しないでおきます。
試行錯誤: 1MコンテキストをオンにしたらOOMが起きました
問題は、欲張りが天井に出会ったときに起きました。35Bを1MコンテキストでKVキャッシュまで含めて立ち上げると、メモリ占有が~51GBまで跳ね上がり、Gemmaも一緒に載せたデュアル構成で統合メモリの天井（~124GiB）を叩いてOOMが起きました。賢いモデルを最も広いコンテキストで使いたいという欲が、物理メモリの前でそのまま折れたのです。
そこで一段下がってQwen3.6-27B（dense）に移りました。28~40 tok/s程度で安定はしたのですが、このとき横で黙々と回っていたGemma4が55~56 tok/sを記録しているのが目に入りました。「あれ、補助で付けておいた小さな子のほうが速いぞ？」ここから話がひっくり返ります。
📊 真っ向勝負の比較: いざ並べてみたらGemmaが勝ちました
そこで27B QwenとGemma4を同じ作業で真っ向から比較しました。結果は意外でした。デコード速度は比較にならず、実務品質はほぼすべて互角以上でした。Qwenが勝ったのはただ一つ、最難度のAIME級の数学だけでした。
| 項目 | Qwen3.6-27B | Gemma4 26B-A4B | 結果 |
|---|---|---|---|
| デコード速度 | 28~40 tok/s | 110~130 tok/s | Gemma 圧勝 (3~12倍) |
| ビジョンOCR | 6.3秒 | 1.4秒 | Gemma 圧勝 |
| 最難度の数学 | 738 ✓ | 657 ✗ | Qwen 唯一の優位 |
肝心なのはこれです。Qwenが唯一勝った領域（最難度の数学）は、どのみち私はローカルには任せません。そういうものはフロンティアモデル（Claude）がやるからです。だからローカルでわざわざ99GBものQwenを抱え込んでいる理由が消えたのです。補助に置いていたGemmaが本陣になれるということが、データで確認された瞬間でした。
そこで決断しました。Qwenサービスを降ろして無効化し、約99GBを回収しました。
systemctl stop llama-qwen
systemctl disable llama-qwen
# 統合メモリ ~99GB 回収 → すべてGemmaに投資⚡ クライマックス: Gemmaひとつを109 tok/sまで引き上げました
これでGemma単独になったので、回収したメモリの余裕をすべてGemmaの最適化に注ぎました。ここで2つの武器を使いました。QAT再量子化とMTP draftです。
学習段階で低精度演算をあらかじめシミュレートし、量子化後の品質低下を抑える手法です。GoogleがGemma4 QATチェックポイントを2026年6月初めにちょうど公開したのですが、私のタイミングとぴったり合いました。
まず基本のMXFP4量子化から、Googleが公開したQATチェックポイント（gemma-4-26B-A4B-it-qat-UD-Q4_K_XL）に切り替えました。重さが16.7GBから14.25GBへ減ったにもかかわらず、品質低下はほとんどありませんでした。この交換だけでデコードが57.6 → 80.8 tok/s（+40%）へ跳ね上がりました。
続いてMTP draft headを付けました。
別途のdraftモデルなしに、モデルへ補助予測ヘッドを付けて1回のforward passで次の2~4個のトークンを同時に推測するspeculative decodingの手法です。コードや構造的な出力では採択率が高くなります。
llama.cppでMTP draftをn=2（保守的・安定設定）でオンにしました。実行コマンドはおおよそこんな形です。
llama-server \
-m gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf \
--mmproj mmproj-gemma4-qat.gguf \
--spec-type mtp \
--spec-draft-n-max 2 \
-c 262144 \
--port 8080私の環境ではdraft採択率が約82%と出て、デコードは80.8 → 109.3 tok/sまで上がりました。出発点（57.6）比で+90%です。一段一段がすべて実測なので、表にまとめるとこうなります。
| 構成 | デコード速度 | 出発点比 |
|---|---|---|
| MXFP4 (基本) | 57.6 tok/s | — |
| QAT UD-Q4_K_XL | 80.8 tok/s | +40% |
| QAT + MTP draft n=2 | 109.3 tok/s | +90% |
✅ 教訓: ローカルは「速くて十分に賢い補助」が勝ちます
2ヶ月の結論を一行に縮めるとこうです。ローカルは巨大な万能モデルではなく、速くて十分に賢い補助モデルでいき、難しいものはフロンティアに任せる役割分担が実戦で勝ちます。
私は「大きいほうが良い」という直感に従って122B → 80B → 35B → 27Bまで欲を出した末に、OOMという物理的限界の前で一度折れて、ようやくデータをまっすぐに見ました。すると補助に置いていた小さなGemma4が速度3~12倍、実務互角以上で、Qwenが勝ったただ一つの領域（最難度の数学）は、そもそもローカルの役目ではありませんでした。だから99GBを回収してGemmaひとつに集中させ、QATとMTPで109 tok/sを作り上げました。
もしローカルLLMの構成を検討中なら、「最も大きいモデル」から探さずに「自分の作業の90%を速く処理できる十分に賢いモデル」から探してみることをおすすめします。残りの10%はフロンティアに任せればよいのです。それが私が試行錯誤で学んだ最も高くついた教訓です。
📚 References
- NVIDIA DGX Spark 製品ページ — nvidia.com (GB10、128GB統合メモリ、273GB/s)
- Google Gemma 4 QAT 発表 — blog.google (2026-06)
- Gemma 4 26B-A4B モデルカード — Hugging Face
- Qwen3.6-35B-A3B — qwen.ai (262K→1M コンテキスト)
- llama.cpp speculative decoding(MTP) ドキュメント — GitHub
- NVFP4 vs MXFP4 — NVIDIA Technical Blog
- 関連記事: DGX Spark 初期セットアップ記録 — ハードウェア構成とllama.cppの初回インストール過程を扱っています。
次の記事では、Gemma4単独構成でビジョンOCRとツール呼び出し（tool calling）をどう繋いだか、そしてmmproj設定で経験した試行錯誤を続けて綴ります。小さなモデルひとつで十分に楽しい運用、一緒にやってみましょう。