8GB VRAMで26B級ローカルAIエージェントを動かす

8GB VRAMのノートPCで、26Bパラメータ級のAIエージェントを24時間稼働させる――そんな構成が、2026年6月に実証されました。

この記事では、ローカルAI開発者のAlok氏が公開した8GB VRAM環境での自律エージェント構築事例を整理します。Gemma 4 26B MoE、GoogleのQAT量子化、llama.cppの設定、Hermes Agentとの連携まで、再現に必要な情報をまとめています。

この記事でわかること

• 8GB VRAMでGemma 4 26B MoEを動かす仕組み
• Google QATとUnsloth UD-Q4_K_XLの役割
• llama.cppの-cmoeフラグが解決する課題
• Hermes Agentと組み合わせた自律エージェントの機能
• 再現時に押さえるべきハードウェア条件と注意点

なぜ8GB VRAMでは26Bモデルが動かないのか

Gemma 4 26B-A4Bは、Google DeepMindが2026年4月に公開したMixture-of-Experts（MoE）モデルです。MoEとは、トークンごとに一部の専門家ネットワークだけを起動する設計で、総パラメータ数と実際の計算量を切り離します。

活性パラメータは38億に抑えられますが、ルーターが8個のエキスパートを選ぶため、128個分の重みをメモリ上に保持する必要があります。標準的な4bit量子化（Q4_K_M）では重みだけで16〜18GBのVRAMを消費し、8GBのGPUには収まりません（参考）。

従来の回避策は、IQ3_XSなどの強い量子化か、GPUとCPUへのレイヤー分割オフロードでした。いずれも品質か速度のどちらかを犠牲にする方法です。

Google QATが変えたこと

2026年6月5日、GoogleはGemma 4ファミリー向けにQuantization-Aware Training（QAT）チェックポイントを公開しました（公式ブログ）。

QAT（量子化認識トレーニング）とは、学習の段階から量子化を想定してモデルを訓練する手法です。学習後に圧縮する従来のPost-Training Quantization（PTQ）と比べ、4bit化しても精度低下を抑えやすくなります。

26B-A4BのQAT版は、フル精度の約50.5GBから4bitで約15GBへと縮小します。Unslothが変換したUD-Q4_K_XL形式のGGUFファイルは13.2GBで、Alok氏の検証ではこのファイルを使用しています。

Unslothは、QATの重みをllama.cpp形式に変換する際の精度回復にも取り組んでいます。標準変換ではTop-1精度が70.20%まで落ちるケースに対し、動的量子化で85.63%まで回復したと報告されています（参考）。

8GB VRAMで動かす核心：-cmoeフラグ

Alok氏が公開したベンチマークでは、以下のハードウェア構成を使っています。

• GPU：NVIDIA GeForce RTX 4060 Laptop（8GB VRAM）
• CPU：Intel Core i7
• メモリ：16GB

モデルはgemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf（13.2GB）です。llama-serverの起動コマンドは次のとおりです。

llama-server.exe -m "gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf" -cmoe -c 248000 -v

ここで重要なのが-cmoe（CPU MoE）フラグです。このフラグはMoEのエキスパート重みをシステムメモリ（CPU/RAM）側に置き、GPUはアテンション層とKVキャッシュ（会話履歴の中間データ）の処理に集中させます。VRAMの溢れを防ぎ、デコード速度を安定させるための設定です。

Alok氏の計測結果は次のとおりです。

• デコード速度：毎秒20トークン（TPS）で安定
• 6万トークンのプロンプト投入後も20 TPSを維持
• プリフィル（初回応答までの処理）：毎秒200トークン
• コンテキスト上限：248,000トークン
• Multi-Token Prediction（MTP）は未使用

RTX 3060、3070、4060など8GB VRAMのGPUで同様の構成が可能だとAlok氏は述べています。

Hermes Agentでチャットから自律エージェントへ

モデル単体の動作確認にとどまらず、Alok氏はNous ResearchのHermes Agent Desktop Appと接続し、自律エージェントとして運用しています。ローカルのllama-serverへの接続は約2分で完了したと報告されています。

https://x.com/analogalok/status/2063620819880911357

Hermes Agentは、ツール実行を前提としたエージェントフレームワークです。Alok氏の投稿では、8GB構成で次のタスクが可能だと紹介されています。

自律的なソフトウェア開発

コードの生成だけでなく、ファイルの読み書き、ターミナルでの実行、エラーのデバッグ、GitHubリポジトリの管理、サブエージェントの並列起動まで行います。

Web操作とビジョン

ブラウザ操作、ボタンクリック、VisionによるUIレイアウトの解析、arXiv論文の取得などを実行します。

DevOpsと自動化

自然言語でのcronジョブ設定、コンテナ化されたバックグラウンドプロセスの管理、Python RPCスクリプトの実行に対応します。

ワークスペース連携

Notion、Google Workspace、Linear、Obsidianへの接続でタスク管理を行います。

「自己改善型」と銘打たれている点は、Hermes Agentが成功したワークフローをスキルとして蓄積する学習ループを持つためです。ローカルモデルであればAPI課金が発生しないため、学習ループを継続的に回しやすいという利点があります。

再現する際の注意点

Alok氏の事例は個人ベンチマークであり、全員が同じ数値を再現できるわけではありません。再現を試みる際は、次の点に注意してください。

システムメモリは16GBが下限

Alok氏の構成は16GB RAMです。-cmoeでエキスパート重みをRAMに載せるため、OSや他アプリとメモリを奪い合います。別の検証では32GB RAMを推奨する声もあります（参考）。

-cmoeはllama.cpp固有の機能

OllamaやLM StudioでもGPU/CPUオフロードは可能ですが、-cmoeと同等のMoE専用オフロードはllama.cppのフラグに依存します。利用する推論エンジンを先に確認してください。

QATモデルの入手

通常のGGUF変換版とQAT版では品質が異なります。GoogleのHugging FaceリポジトリかUnslothのUD-Q4_K_XL変換版を使います（Hugging Face）。

速度はタスク次第

コミュニティの8GB VRAM向け検証では、GPU/CPUオフロード時の生成速度は15〜22 TPS程度と報告されています。Alok氏の20 TPSはこの範囲内ですが、長いコンテキストやエージェントのツール呼び出しが重なると体感速度は落ちます。

ローカルAIエージェントのハードルは下がった

Gemma 4 26B-A4Bは、MMLU Proで82.6%、LiveCodeBench v6で77.1%と、31B Denseモデル（85.2%、80.0%）に近いスコアを記録しています（モデルカード）。活性パラメータは38億に抑えられ、推論コストは4Bクラスに近い設計です。

GoogleのQATがモデルサイズを実用域に押し下げ、llama.cppの-cmoeが8GB VRAMとの共存を可能にし、Hermes Agentがツール実行の枠組みを提供する。この3層が揃ったことで、「8GBのノートPCで26B級の自律エージェント」が現実の選択肢になりました。

クラウドAPIに依存せず、データを手元に置いたままエージェントを動かしたい開発者にとって、再現価値の高い構成です。