Hermes AgentでローカルLLMを使う方法｜GGUF・必要VRAM・llama.cpp設定

ローカルLLMをエージェントに使おうとすると、モデルを選ぶだけでは終わらない。

GGUFの量子化を選び、llama.cppを用意し、GPU層やコンテキストを調整し、VRAMに収まらなければオフロードを考える。チャットだけなら触れる設定でも、長時間動くエージェントでは設定ミスが速度やコンテキスト不足へ直結する。

Hermes Agentは、Nous Researchが開発するオープンソースのAIエージェントだ。2026年9月時点の公式ローカルモデル機能では、llama.cpp実行環境の導入から、手元GPUに合うGGUFの選択、コンテキスト、メモリ配置までをHermes側で管理できる。

NVIDIAも2026年9月3日のIFA 2026発表で、Hermes AgentのWindows向けローカルモデル設定を取り上げた。RTX/DGX環境ではGPUを検出し、モデルと構成を選び、統合llama.cppで実行する簡易セットアップが提供されている。

ただし、「Hermesなら巨大モデルが少ないVRAMで高速に動く」わけではない。VRAM不足時はシステムRAMへ逃がせるが、その分速度は落ちる。また公式の8GB・16GBという目安も、あらゆるGGUFを快適に動かす最低要件ではない。

Hermes Agentの管理機能付きローカルモデルが向く使い方

Hermes Agentのローカルモデル機能が向いているのは、次のような人だ。

• エージェントの推論をクラウドAPIではなく手元のGPUで動かしたい
• GGUFの量子化やGPU層を毎回手動で決めたくない
• 8GB、16GB、24GBなど自分のVRAMで何が収まるか事前に確認したい
• 長いエージェント向けタスクでコンテキスト不足を起こしにくくしたい
• Hugging Face上のGGUFや手元の.ggufをエージェントへ接続したい
• メモリ、スキル、サブエージェント、ツール利用とローカル推論を同じエージェントで扱いたい

一方、特定のllama.cppビルド、細かなGPU層、独自サンプラーなどを固定して追い込みたい場合は、Hermesの管理機能付き実行環境だけに寄せる必要はない。公式は既存のllama-serverを検出して利用できるほか、OpenAI互換の接続先を指定する手動構成も用意している。

Hermesの強みは新しい推論エンジンを作ったことではなく、llama.cppとGGUFの面倒な選択をエージェント側へ吸収したことにある。

Hermes Agentとは

Hermes AgentはNous Researchが開発するAIエージェントで、MIT Licenseで公開されている。

通常のチャットUIよりエージェント寄りで、公式は永続メモリ、スキル、定期自動化、サブエージェント、隔離実行、Web/ツール利用などを主要機能としている。

ローカルAI目線で重要なのは、これらのエージェント機能へローカルモデルをそのまま接続できることだ。

構成を単純化すると次のようになる。

Hermes Agent
    ↓
local model manager
    ↓
llama.cpp / llama-server
    ↓
GGUF model
    ↓
CUDA / Metal / Vulkan / CPU

LM StudioやOllamaが「モデルを実行してAPIを提供する」側を中心にするのに対し、Hermesはその上でタスクを実行するエージェント本体が中心になる。

推論環境そのものを比較したい場合は、LM Studio・Ollama・llama.cppの違いも先に確認すると位置付けが分かりやすい。

ローカルモデルの導入はどう簡単になる？

Hermes Desktopでは、設定 → プロバイダー → Local Modelsから管理機能付き実行環境を導入できる。

公式の基本手順はシンプルだ。

1. Install runtimeでHermesがllama.cppビルドを取得する
2. 一覧からモデルを選ぶ
3. Hermesが手元ハードウェアに合わせたビルドを選ぶ
4. モデルをダウンロードする
5. Useを押すと以後のチャットがローカルモデルで動く

Hermesは実行環境を起動・停止し、アプリ再起動後も設定を維持する。クラウドプロバイダーへ戻す場合もモデル選択画面から切り替えられる。

この方式では、最初から--n-gpu-layersやコンテキストサイズを自分で計算する必要がない。

NVIDIAの2026年9月3日発表で何が変わった？

NVIDIAはIFA 2026で、Hermes AgentのRTX/DGX向け簡易ローカルセットアップを案内した。

WindowsではNVIDIA GPUを自動検出し、適切なモデルと構成を選び、NVIDIA最適化を含む統合llama.cppで動かすワンクリック設定を提供するとしている。

Hermes公式ローカルモデルドキュメントはWindows/LinuxでNVIDIA CUDAまたはCPUを実行環境対象としている。一方、NVIDIAの9月3日発表は簡易ワンクリック設定のLinux対応を近日対応予定としている。

したがって、

Linuxでlocal runtimeを使える
≠
Windowsと同じone-click UXがすでに完成している

と分けて読むのが安全だ。

GGUFはどう選ばれる？

Hermesの特徴は、モデル名だけでなく手元マシンへの適合度をダウンロード前に計算することだ。

一覧には大きく3段階の状態が表示される。

表示	意味	実用上の判断
緑	GPUメモリ内に収まる	まず選びやすい
黄	システムRAMも使う	動くが遅くなる可能性が高い
赤	マシンに対して大きすぎる	モデルかハードウェアを見直す

さらに複数量子化がある場合、HermesはGPU内で動かせる範囲から高品質なビルドを選ぶ。

4bit未満は自動候補にしない

公式ドキュメントでは、4bit未満は品質低下が大きすぎるという判断から、Hermesは4bitより小さいビルドを提示しないとしている。

VRAMが少ないPCで「とにかく2bitに落として巨大モデルを載せる」のではなく、一定以下ならシステムRAM利用または別モデルを選ぶ方向になる。

量子化によるVRAMと品質の一般的な違いは、量子化とVRAM・品質の関係の記事で整理している。

必要VRAMはどれくらい？

Hermes公式ドキュメントは目安として次を示している。

GPUメモリ	公式の目安
8GB以上	小型一覧掲載モデルを快適に実行
16GB以上	27〜35Bモデルを高品質で実行

ただし、この表を「27〜35Bなら16GBで何でも快適」と読んではいけない。

必要VRAMは、モデルアーキテクチャ、GGUF量子化、コンテキスト、KVキャッシュ、実行環境の追加負荷で変わる。MoEなら総パラメータと有効パラメータも分ける必要がある。

Hermes側がマシンごとに適合判定するのは、この差を固定のパラメータ数だけで決められないからだ。

8GB VRAM

8GB級は、小型モデルをエージェントに常駐させる入口として現実的だ。

ただし長いコンテキストや大きなモデルを選ぶとシステムRAM依存が増えやすい。エージェントは通常チャットよりツール実行結果や長い作業履歴を抱えることがあるため、単発チャットで動いたから十分とは限らない。

16GB VRAM

公式が27〜35B級の高品質ビルドまで目安に含めている帯だ。

とはいえ、モデル本体だけで16GBを使い切る構成ではコンテキストや実行環境の余白がなくなる。Hermesの適合表示を確認し、緑と黄を分けて判断したい。

24GB・32GB VRAM

VRAMが増えるほど、高品質量子化や大きなコンテキストをGPU内へ残しやすくなる。

Hermes固有の最低条件ではないが、エージェントを長時間使う用途では「最大モデルを載せる」より、同じモデルを余裕を持って常駐させる価値が大きい。

16GB・24GB・32GBの購入判断は、ローカルAI向けGPUのVRAM比較も合わせて確認したい。

VRAMに収まらないとどうなる？

Hermesはモデル重みがGPUメモリを超える場合、はみ出した分をシステムRAMへ配置できる。

公式ドキュメントでは、影響が小さいものからシステムRAMへ置き、エキスパート重みを先に逃がし、アテンションキャッシュは逃がさない方針が説明されている。

これはコンテキストを守るためだ。

ただしシステムRAMは専用VRAMの代用品ではない。

VRAMに完全fit
→ 高速になりやすい

一部をsystem RAMへ配置
→ 実行可能範囲は広がる
→ memory transferが増え、速度は下がりやすい

黄表示を「問題なく快適」と読むのではなく、「動作可能だが速度との交換条件がある」と読むべきだ。

64Kコンテキストをどう確保する？

Hermesは推奨モデルについて、少なくとも64Kコンテキストを確保する方針を示している。

モデルは最初から最大コンテキストを確保するのではなく、GPUに収まる画面から始まり、会話が長くなるにつれてネイティブ最大へ向けて拡張される。

状態フィードにContext window grownと出る場合はエラーではなく、この自動拡張だ。

エージェント用途ではこの設計が重要になる。

チャットでは数往復で終わる処理でも、エージェントはターミナル出力、ツール実行結果、サブタスクの要約などを長時間抱えることがある。最初から巨大KVキャッシュを確保してVRAMを圧迫せず、必要に応じてコンテキストを伸ばす考え方だ。

待機中モデルは15分後にメモリから解放され、次のメッセージで自動再読み込みされる。

Hugging FaceのGGUFも使える

Hermesの一覧だけに限定されない。

Find more modelsからHugging Face全体を検索でき、各GGUFファイルについてダウンロード数と手元マシンへのfitを表示する。

コミュニティモデルは一覧の検証済み表示を持たないが、ダウンロード後のメモリ管理は同様に扱われる。

すでに.ggufを持っている場合は、モデルファイルをライブラリへ追加できる。この操作は元ファイルをコピーせずリンクするため、同じ巨大GGUFを二重保存する必要がない。

これは大量のGGUFをすでに保有しているユーザーには便利だ。

Ollamaや自前llama.cppは使えない？

使える。

Hermesはllama.cppの管理機能を既定としているが、自分で起動済みのllama-serverがあれば検出して利用できる。

さらにOpenAI互換の接続先を指定できるため、手動セットアップではOllama、MLX、カスタムビルド、画面なしサーバーなどへ接続する構成も取れる。

したがって、Hermesを導入したから推論環境までHermes管理へ固定されるわけではない。

管理機能付き実行環境が向く人

• llama.cpp更新を追いたくない
• GGUF選択を自動化したい
• GPU fitをダウンロード前に知りたい
• コンテキストやメモリ配置を任せたい

自前サーバーが向く人

• 特定コミットのllama.cppを使いたい
• 独自ビルドやバックエンドを使いたい
• 複数アプリから同じサーバーを共有したい
• サンプラーやサーバー設定項目まで固定したい

この違いは、LM Studio・Ollama・llama.cpp比較の記事ともつながる。

対応GPU・OS

2026年9月4日時点の公式ローカルモデルドキュメントを整理すると次の通りだ。

OS / ハードウェア	ローカル実行環境
Windows + NVIDIA	CUDA
Linux + NVIDIA	CUDA
Windows / Linux + CPU	CPU
macOS + Apple Silicon	Metal
AMD GPU	Vulkanビルド

設定上のバックエンド設定項目にはauto / cuda / metal / vulkan / hip / cpuが用意されている。

ただし、「設定項目が存在する」ことと「全GPU・全モデルで同じ安定性」があることは別だ。AMDを含む構成ではドライバー、モデル、llama.cppビルドごとの相性を確認したい。

また前述の通り、NVIDIAが9月3日に発表した簡易ワンクリック設定はWindowsが先行しており、Linux版UXは近日対応予定とされている。

「完全ローカル」はどこまで？

ローカルモデルをダウンロードした後の推論について、Hermes公式ドキュメントはアカウントやAPI keyを必要とせず、ネットワークアクセスなしでモデルを実行できるとしている。

ただし、Hermes Agent全体のすべての行動が自動的にオフラインになるという意味ではない。

エージェントがWeb検索、外部API、MCP、メッセージ連携サービスなどのネットワークツールを使えば、そのツール通信は当然発生する。

したがってプライバシー目的なら、

1. モデル推論をローカルにする
2. 利用ツールを確認する
3. 外部プロバイダー代替経路を確認する
4. ネットワークアクセスが必要なスキルやMCPを確認する

まで分けて考える必要がある。

ローカル推論と完全オフラインワークフローは同義ではない。

GPUを買い替える判断材料にもなる

Hermesの適合表示は、単に「今動くモデル」を知るだけでなく、ハードウェア更新で何が解放されるかを見る材料になる。

モデルが緑ならGPU内にfit、黄ならシステムRAM、赤ならマシンに対して大きすぎると表示されるため、VRAM不足を感覚ではなくモデルファイル単位で確認できる。

ローカルAI向けにGPUを選ぶ場合は、最大モデルだけでなく、

• よく使う量子化をGPU内に置けるか
• 64K以上のコンテキスト用余白を残せるか
• エージェントと画像生成などを同時起動するか
• システムRAMへのオフロードを許容できる速度か

を見る方が実用的だ。