ローカルでAIエージェントを動かす最大の壁は、VRAM不足です。TurboQuantのKVキャッシュ圧縮が、この壁を大きく下げました。

この記事では、8GB GPUで12B denseモデルを120Kコンテキスト・prefill 1000トークン/秒超で動かす構成と、Hermes Agentへの接続手順を整理します。

この記事でわかること

  • TurboQuantがHermes Agentのローカル運用に効く理由
  • 8GB GPUで120Kコンテキストを確保する仕組み
  • llama.cppとHermes Agentをつなぐ具体的な設定
  • 導入前に押さえるべき制約と注意点

何が変わったのか

2026年6月、実践者のNO1ennn氏がXで報告した数値は、ローカルエージェント運用の前提を書き換える水準です。12Bのdenseモデルでprefillが1000トークン/秒超、コンテキスト12万トークン、GPUは8GB（参考）。価格帯は$300級のGPUで足りる、と同氏は述べています。

従来、Hermes Agentをローカルで動かすには「とりあえず動く」程度のGPUでは足りない、という認識が強かった。公式クイックスタートでも、エージェントのマルチステップ・ツール呼び出しには最低64,000トークンのコンテキストが必要と明記されています（Hermes Agent Quickstart）。8GB GPUに12Bモデルを載せただけでは、長い会話履歴やシステムプロンプトを抱えたエージェント運用は現実的ではありませんでした。

TurboQuantは、Google ResearchがICLR 2026で発表したKVキャッシュ圧縮アルゴリズムです。PolarQuantとQJLを組み合わせ、KVキャッシュを3〜4ビットに圧縮し、メモリを4〜6倍削減します。学習やファインチューニングは不要で、推論時にそのまま適用できます（Google Research公式ブログ）。

なぜエージェント運用で効くのか

エージェントのボトルネックは、モデル重みよりKVキャッシュです。会話が長くなるほど、過去トークンのKey/ValueがVRAMを食います。Hermes Agentはツール呼び出し・スキル読み込み・会話履歴を抱えるため、コンテキスト消費が大きい。

実測ベンチマークでは、Hermes Agent v0.13.0のシステムプロンプトだけで約13,500トークンを消費します。同じハードウェアでも、軽量なコーディングエージェント（約1,900トークン）と比べ、実質的に使えるコンテキストが1万トークン以上減ります（witcheer/rtx-4060ti-8gb-turboquant-bench-2026-05）。

TurboQuantはこのKVキャッシュを圧縮するため、同じ8GB GPUでも長いコンテキストを確保しやすくなります。denseモデル（Gemma 4 12Bなど標準的なTransformer）ほど効果が大きく、ハイブリッドアーキテクチャのMoEより恩恵が出やすい、という報告もあります（konradishのGist）。

推奨構成と起動手順

1. TurboQuant対応のllama.cppを用意する

TurboQuantは本家llama.cppには未マージです。TheTom/turboquant_plusなどのフォークを使います。起動例は次のとおりです。

llama-server \
  -m model-Q4_K_M.gguf \
  -ctk q8_0 -ctv turbo4 \
  -c 122880 \
  -ngl 99 -fa on \
  --host 0.0.0.0 --port 8080

-ctkはKeyキャッシュ、-ctvはValueキャッシュの量子化方式です。非対称設定（Kをq8_0、Vをturbo3/turbo4）が品質面で推奨されています。Q4_K_Mの低ビットモデルで対称turbo3を使うと品質が崩れるケースが報告されています（turboquant_plus benchmarks）。

2. Hermes Agentをインストールして接続する

GitHub - NousResearch/hermes-agent: The agent that grows with you
The agent that grows with you. Contribute to NousResearch/hermes-agent development by creating an account on GitHub.
GitHub
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes model

hermes modelでCustom Endpointを選び、llama-serverのURL（例: http://localhost:8080/v1）とモデル名を設定します。コンテキスト長は64,000トークン以上に設定してください。

3. 動作確認

hermes

ディスク使用量の確認など、ツール呼び出しを含むタスクを1回実行し、応答速度とコンテキスト維持を確認します。prefillが遅いと、長いシステムプロンプトの読み込みで待ち時間が目立ちます。TurboQuant適用後は、この待ち時間が短縮されるのが実用上のメリットです。

数値の読み方

NO1ennn氏の報告では、prefill 1000トークン/秒超という数値が出ています。別の検証では、TurboQuant適用前後でprefillが数十倍に伸びる例もあります。RTX 4080 16GBでQwen3.5-9Bを動かしたケースでは、stock llama.cppの48.9トークン/秒からTurboQuant適用後の4,176トークン/秒に跳ね上がっています（konradishのGist）。

一方、decode（応答生成）は圧縮・復号のオーバーヘッドで遅くなる傾向があります。同じGistでは44.5トークン/秒から18.2トークン/秒に低下しています。エージェント運用ではツール呼び出しのたびにprefillが走るため、prefill高速化の恩恵は大きい。ただし、最終的な応答生成速度はdecode側のボトルネックも意識する必要があります。

RTX 4060 Ti 8GBでの実測では、turbo3設定でdecode 28〜34トークン/秒、64Kコンテキストで速度の急落なし、という結果も報告されています（witcheer/rtx-4060ti-8gb-turboquant-bench-2026-05）。

注意点

フォーク依存が残る。 TurboQuantはllama.cpp本流へのマージが進行中です（PR #21089）。現時点では専用フォークのビルドが必要です。

モデルと量子化の組み合わせを選ぶ。 対称turbo3は低ビットGGUFで品質が崩れる例があります。まずはq8_0（K）+ turbo4（V）から試すのが安全です。

コンテキストチェックポイントを無効化する。 llama.cppはprefill中にコンテキストチェックポイントを作成し、VRAMを追加消費します。8GB GPUでは--checkpoint-every-n-tokens -1で無効化すると、急激な速度低下を防げる報告があります（witcheer/rtx-4060ti-8gb-turboquant-bench-2026-05）。

Hermes Agentのコンテキスト要件を満たす。 公式要件の64Kトークンは下限です。スキルや長い会話を使うなら、120Kまで確保できる構成が実用的です。

ローカルエージェントの選択肢として

Hermes AgentはNous Researchが開発する自己改善型エージェントで、TelegramやDiscordからの操作、スキル自動生成、クロスセッション記憶を備えています（GitHub README）。クラウドAPIに依存せず常時稼働させたい場合、推論コストはゼロですが、GPUと電気代がかかります。

TurboQuant以前は、8GB GPUでHermes Agentを「実用レベル」で回すのは難しかった。12Bクラスの品質と12万トークンのコンテキストを両立する構成が、$300級のGPUで現実味を持ち始めています。クラウド課金を避けたい開発者や、プライバシーを重視するチームにとって、導入判断の材料として十分な情報です。