開発実践ガイド

Hermes AgentでローカルLLMを使う方法|GGUF・必要VRAM・64Kコンテキストを確認

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

Hermes Agentを手元のLLMにつなぎたい。でも、GGUFの種類や必要VRAMを見ているうちに、どれを選べばよいか分からなくなる。

かがり

GGUFに量子化にVRAM……候補が多すぎて、どれを選べばいいのよぉ!

ロコ

まずHermesのLocal Models一覧を開こう。「memory fit」と「Context」で候補を絞れるよ。

HermesのLocal Modelsは、量子化やGPUへの配置を任せられる入口です。

モデルを読み込めることと、ツールを使う長い作業まで待てることは、少し違います。この記事では2026年10月21日時点の公式案内を基に、導入後にどこを見ればよいかを説明します。実機で速度を比べた結果ではありません。

GGUFモデルを選ぶ

GGUFは、ローカルでモデルを動かすために使われるファイル形式です。配布名に付くQ4などの量子化は、重みを少ないビット数で表して容量を減らす方法を指します。小さくできる分、手元のGPUへ載せやすくなりますが、回答や速度への影響はモデルと方式によって変わります。

自分で配布物を探す場合は、GGUFという名前だけで決めず、配布元の対応説明と、使う実行エンジンを合わせます。同じ形式でも、モデルの構造や使える機能まで同じとは限りません。初回は、Hermesのカタログから選ぶ方が、こうした組み合わせを一つずつ調べる手間を減らせます。

かがり

モデルの容量がVRAMより小さければ、選んで大丈夫なの?

ロコ

会話を処理する分も必要なんだよ。Hermesが計算した収まり方から見てみよう。

VRAMはモデルサイズだけでは足りない

メモリはモデル本体以外にも使います。会話を処理するKVキャッシュや作業領域、画像などの追加入力にも空きが必要です。特に、会話を一度に扱える長さであるコンテキストを広げると、KVキャッシュも増えます。短い質問で動いたモデルが64Kの文脈でも同じように収まる、とは限りません。

そこで管理型Local Modelsでは、コンテキスト長・GPUへの配置・量子化をHermesがまとめて管理します。最初に見るのは、細かな層数の設定ではなく、カタログのmemory fitとContextです。後半で説明する自前サーバーなら手動調整できますが、その手順を管理型の画面で探す必要はありません。

導入はLocal Modelsから始める

公式Local Modelsガイドでは、macOS・Windows・Linuxのx64/arm64向けデスクトップアプリは、全リリースチャンネルでLocal Modelsが既定で有効です。この対象なら、canaryへの切り替えや --local 付きの起動は不要です。--local は公式が案内するその他のプラットフォーム向けの入口です。

対象のデスクトップアプリを開いたら、次の順に進めます。

  1. Settings → Providers → Local Modelsを開く
  2. 実行環境が未導入ならInstall runtimeを実行する
  3. モデルカタログから候補を選ぶ
  4. Downloadを実行する
  5. UseでLocal Modelsへ切り替える

この流れで、Hermesがハードウェアに合うllama.cppを用意し、モデルを動かすサーバーの起動と停止も扱います。ダウンロードする候補を選ぶ前に、次の二つの表示を見ておきましょう。

モデル一覧の「memory fit」を見る

memory fitは、その候補を今のマシンで動かす際の収まり方です。ダウンロードする前に、次の色で見分けられます。

  • green: GPUメモリへ収まる
  • amber: システムRAMも使う
  • red: このマシンでは大きすぎる

最初の候補にはgreenが選びやすいです。amberも実行候補ですが、一部をシステムRAMへ置くため、待ち時間が増えることがあります。色と一緒に、Context欄の開始時の長さと、広げられる上限も見ます。

通常は、GPUまたは統合メモリへ完全に収まり、予測20 tokens/s以上の候補から推奨が選ばれます。この数字は予測なので、手元で測った速度として読まないようにしましょう。条件に合う推奨がなくても、収まるモデルを自分で選ぶことはできます。

8GB・16GBはカタログ上の目安

公式資料には、8GB以上なら小型のカタログモデル、16GB以上なら27〜35B級を高品質で扱う目安が載っています。手持ちのGPUから候補を探す入口にはなります。

ただし、8Bや30Bという規模だけを合わせても、同じ条件で動くとは限りません。使う候補のmemory fitを優先して見てください。

Hermesが収まりを計算するときは、次の分も数えます。

  • モデルの重み
  • 量子化
  • コンテキスト状態
  • 実行環境のバッファー
  • 画像用投影器
  • MTPバッファー

画像用投影器は画像をモデルへ渡す部分、MTPバッファーは複数トークンの予測で使う作業領域です。こうした分もあるため、ファイル容量だけをVRAMと比べるより、一覧の計算結果を見る方が選びやすくなります。

Hermes Agentの推奨モデルは64Kコンテキストを確保

Hermesは、質問だけでなく、ツールの使い方を示すスキーマやシステムプロンプトもモデルへ渡します。その余裕を見込み、管理型の推奨モデルには少なくとも64Kのコンテキストを確保する設計です。

この保証の対象は、管理型の一覧で推奨されるモデルです。管理型は会話に合わせて文脈の枠を広げ、メモリや速度などの条件で広げられないときは会話を圧縮します。今どれだけの枠で動いているかは、コンテキストメーターで見てみましょう。

Ollamaなどを手動でつなぐ場合、この保証がそのまま付くわけではありません。推奨モデルと同じ条件でエージェント処理を試すなら、接続するサーバー側にも実効64K以上の文脈枠を用意します。

システムRAMへの退避は速度との交換条件

GPUへ収まりきらないモデルでも、一部をシステムRAMへ置いて使える場合があります。amberの候補を考える際は、この動きが待ち時間へどう響くかを見ます。

RAMも使えるとモデルの候補は広がります。ただ、CPU側の処理やGPUとの転送が増えるため、GPU内だけで処理するときより遅くなりやすいです。

短い返答が出たら、次は普段のツールを使う作業へ進みましょう。起動できても、エージェントが何度もモデルへ問い合わせるたびに長く待つなら、使い続けにくくなります。最後の回答までに掛かった時間を見て、greenの小型モデルへ戻すか、大きなモデルの回答を待つかを選びます。

4bit未満は管理型カタログで選ばれない

メモリが足りないと、もっと小さな量子化を探したくなります。ただ、管理型カタログは品質低下を理由に4ビット未満を提示しない方針です。

4ビットでもGPUに入りきらなければ、まずRAMへ退避して収まるかが判断されます。RAMも含めて4ビットの構成を動かせないマシンでは、そのモデルは実行できないと判定されます。「GPUに入らないならRAMで必ず動く」とは考えず、候補ごとの表示を見てください。

量子化を自分で指定する必要があるなら、管理型の設定を探し続けるより、次のカスタム接続を検討します。

自前サーバーも接続できる

すでにモデルを動かしているサーバーがあれば、管理型へ移すほかにも接続方法があります。

Hermesは手元のllama-serverを検出して使えるほか、OpenAI互換の接続先も指定できます。Ollama、MLX、vLLMなど、今使っている環境を自分で管理したい場合の選択肢です。

その代わり、次の項目は自分で合わせる必要があります。

  • コンテキスト
  • モデル
  • エンドポイント
  • メモリへの収まり
  • 実行環境の更新

管理型で任せられた部分も自分の担当になるため、使い慣れたサーバーを残す利点と、設定を保つ手間を比べて選びましょう。

16GB級で試す順番

16GB級を持っていても、最初から一番大きい候補を選ぶ必要はありません。まずgreenの小さめモデルで、次の流れを通してみましょう。

  1. green表示の小さめモデルを一つ選ぶ
  2. 推奨候補のContext表示を確認し、短い会話からツールを含む処理へ進む
  3. ステータスバーを右クリックし、System resourcesを有効にしてVRAM・RAM使用量を見る
  4. 応答速度を確認
  5. 必要ならamber候補へ広げる

amberへ広げたら、greenで試したのと同じツール作業を送って比べます。短い会話では気にならなくても、ツールの結果を何度も読む処理では待ち時間の差が大きく感じられることがあります。

かがり

greenなら、もう仕事も任せていいのかしら?

ロコ

色で分かるのは収まり方だよ。道具を選べるかと、返ってきた結果を読めるかは次に確かめよう。

最初のツール作業には、書き込みや送信を伴わないものを選びます。例えば、テスト用メモを読む道具があるなら「このメモの担当と期限を教えて」と依頼し、実際にその道具を選んだか、返答がメモの内容と合うかを見ましょう。返答が速くても、読んでいない内容を補っていたら候補を見直します。正しく読めた場合も、その一件の結果として残し、長い会話での動作は別に確かめます。

Windows・Linux・macOSでバックエンドが違う

現行公式ドキュメントでは、Windowsは対応NVIDIA向けCUDA、x64向けVulkan、またはCPU、Linuxはx64/arm64のNVIDIA向けCUDA(CUDA 13ドライバーが必要)、Vulkan、またはCPU、macOSはMetalまたはCPUが案内されています。対応するx64環境ではHIP/ROCmも明示的に選べます。

自分のOSが一覧にあっても、GPUとドライバーの組み合わせまで合わせて見ます。backend: autoはNVIDIAならCUDA、AMD・Intel GPUならVulkanを優先し、対応するビルドへ切り替えます。想定と違う速度なら、実際に選ばれたバックエンドとビルドも確かめてください。

カスタムエンドポイントではコンテキスト設定に注意する

カスタム接続で見落としやすいのが、モデルの公称値とサーバーの設定の違いです。たとえばOllama側で実際に用意した文脈枠が短ければ、モデル自体が長い文脈へ対応していても、その枠で動きます。

手動構成では、短いコンテキストで起動してから、メモリと速度を見て必要な長さへ伸ばせます。ただし、短い試験が通ったことと、管理型の推奨モデルと同じ条件で使えることは分けましょう。比較するなら実効64K以上へそろえ、その値をHermesへ正しく伝えます。長い枠を確保できない場合は、短い質問で使うか、ツールを多く使う仕事に別のモデルや構成を用意します。

関連ガイド

最初の一歩は、Local Modelsで収まる候補を一つ選び、短い会話からツール作業まで進めることです。すでにあるLM Studioへつなぐ方を選ぶなら、モデルの用意にはGGUFの取り込み手順を使えます。

量子化を変えたら、メモリだけでなく、普段の質問に欲しい答えが出るかも比べてみてください。手元で足りない条件が分かってからPCを考えるなら、ローカルAI向けBTOの構成選びで用途に合う容量を整理できます。

まとめ

  • Hermes Agentは管理型ローカルモデルでllama.cppの導入、ハードウェアに合う量子化、メモリへの収まり、コンテキスト設定をまとめて管理する
  • Hermesの管理型ローカルモデルは、推奨モデルで少なくとも64Kのコンテキストを確保する。ツールを含む処理もこの保証範囲を起点に試す
  • 公式目安では8GB以上で小型カタログモデル、16GB以上で27〜35Bを高品質で扱えるが、全モデル共通の最低VRAMではない
  • GPUへ収まらない一部の重みはシステムRAMへ退避できるが、動作可能と高速動作は別に判断する

公式サイト

各リンクから、配布元のファイルや説明を開けます。