ローカルLLMは「モデルをダウンロードすれば終わり」ではありません。
llama.cppなどの推論ランタイム、量子化ファイル、GPUへ載せる量、コンテキスト長まで調整する必要があり、初心者にはここが最初の壁になります。
Hermes AgentのLocal Modelsは、この調整をできるだけ隠す設計です。
公式ドキュメントによると、端末のハードウェアを見て適したllama.cppビルドを取得し、モデルごとにメモリ適合度を判定し、利用可能な中で最も品質の高い量子化を選びます。
モデルを選んでDownload、Useと進めるだけで、ローカル推論へ切り替えられます。
ただし、自動化されることと、どんなPCでも大型モデルが快適に動くことは別です。
特に16GB VRAMで27B級を使う場合、モデル本体だけでなくKVキャッシュやアプリ側のメモリも考える必要があります。
Hermes AgentはクラウドAPIだけでなく、オープンモデルを自分のPC上で実行できます。
Local Modelsでは公式llama.cppランタイムの取得・更新、モデルのダウンロード、量子化選択、メモリ配置をHermes側が管理します。
公式説明では、モデル一覧に「GPU内に収まる」「システムRAMを使うため遅くなる」「このマシンでは大きすぎる」という適合表示が出ます。
ユーザーがGPU layer数やcontext sizeを毎回手作業で決めなくてもよいのが特徴です。
ダウンロード後はネット接続なしでも実行でき、クラウドへプロンプトを送らない構成にできます。
機密性を重視する用途では大きな利点ですが、モデル取得時やソフト更新時にはネット接続が必要です。
ローカルLLMでは、モデル名だけでなくGGUFの量子化、GPUへ載せるlayer数、context size、推論バックエンドまで選ぶ必要があります。
Hermes AgentのLocal Modelsは、これらを個別に調整する代わりに、PCの構成を見て実行可能な組み合わせを自動で選ぶ方向に寄せています。
そのため、ローカルLLMを初めて触る人にとってのメリットは「最高速になること」よりも「設定ミスを減らしやすいこと」です。
一方、細かな量子化やバックエンド、context sizeを自分で固定したい上級者は、Ollamaやllama.cppを直接使う方が自由度は高くなります。
Ollamaやllama.cppを直接使う場合、自分でモデルを探し、量子化を選び、メモリに合わせて設定する自由があります。
一方、Hermesはその判断を自動化し、初心者が失敗しやすい設定項目を減らします。
Hermesは既存のllama-serverも検出でき、OpenAI互換サーバーを指定する手動構成も残しています。
つまり「完全自動しか使えない」のではなく、標準は自動、必要なら手動へ降りられる設計です。
Hermes Agentはツール利用を含むエージェント動作のため、少なくとも64Kトークンのコンテキストを必要とします。
Ollamaは環境によって標準のcontext lengthがこれより小さい場合があるため、外部Ollamaサーバーへ接続するときは「モデルが起動するか」だけでなく、実際に64K以上へ設定されているかを確認する必要があります。
ここは、普通のローカルチャットでは問題なくてもHermes Agentでは起動条件を満たさない原因になりやすいポイントです。
既存のOllama環境を流用したい人は、モデル名、VRAM、RAMと合わせてcontext lengthも確認してください。
公式ドキュメントは8GB以上のGPUで小型カタログモデル、16GB以上で27〜35Bモデルを高品質で動かせるとしています。
ただし、この表現を「27Bなら必ず16GB VRAMだけで余裕」と読むべきではありません。
量子化後のモデルサイズ、KVキャッシュ、コンテキスト長、画像入力の有無で必要量は変わります。
Hermesの適合表示がamberになりシステムRAMへ一部を逃がす場合、起動できても生成速度は落ちます。
特に長文を常用するなら、VRAMをぎりぎりまでモデル本体で使い切る構成は余裕がありません。
一般に量子化を軽くするとモデルファイルは小さくなり、必要メモリも減らしやすくなります。
ただし、容量を減らすほど品質とのトレードオフが強くなります。
Hermesが4bit未満を自動候補から外しているのは、単に動けばよいのではなく、エージェントとして使える品質を保つことを重視しているためです。
16GB VRAMで大型モデルを使うときは「最小サイズを無理に入れる」より、Hermesがgreenで提示する量子化を基準にする方が分かりやすいでしょう。
さらに大きなモデルをamberで動かすか、少し小さなモデルをGPU内へ完全に収めるかは、品質と速度のどちらを優先するかで変わります。
Hermesは複数の量子化候補から、そのPCでGPU内に収まる中で品質の高いものを選びます。
公式は4bit未満について品質損失が大きいとして、管理対象の自動候補にしない方針を示しています。
2bitなど極端な量子化で「16GBに入った」という第三者例があっても、それはHermes公式の推奨条件とは別です。
容量を優先した実験値と、日常利用を想定した品質基準を混同しないことが重要です。
大型モデルほど常に使いやすいとは限りません。
27B級がRAM退避を伴って動く構成より、9B〜14B級がGPU内に完全に収まり、長いコンテキストでも余裕を残せる構成の方が、応答速度やツール実行の待ち時間では快適になることがあります。
エージェント用途では1回だけ文章を生成して終わるのではなく、ツール呼び出し→結果の読み込み→次の判断を繰り返します。
1ステップあたりの差が小さくても、複数ステップでは待ち時間が積み重なるため、モデルサイズだけでなく「一連の作業が何分で終わるか」で比較するのが実用的です。
Hermesはメモリ配置を管理しますが、GPUに収まり切らないモデルはシステムRAMを使うことがあります。
CPU/GPU間の転送が増えると、トークン生成速度は大きく下がる可能性があります。
そのためモデル一覧では、ダウンロードできるかだけでなくMemory fitの表示を見るべきです。
greenはGPU内に収まる、amberはRAM利用で遅くなる、redは大きすぎるという意味です。
快適さを優先するならgreenを基準に選ぶ方が分かりやすいでしょう。
デスクトップ版ではSettings→Providers→Local Modelsを開き、Install runtimeを実行します。
次にカタログからモデルを選びDownload、完了後にUseを押します。
以後の新しいチャットは選択したローカルモデルで動きます。
Windows/LinuxではNVIDIA CUDAまたはCPU、macOSではApple SiliconのMetalが公式対象です。
AMD GPU向けにはVulkanビルドが用意されています。
すでにllama-serverを動かしている場合は、それを利用することもできます。
モデル本体がGPUに収まっても、会話が長くなるとKVキャッシュが増えます。
64Kや128Kのような長いコンテキストを使う場合、短文チャット時の適合表示だけでは余裕を判断できません。
最初は標準コンテキストで速度とGPUメモリ使用量を確認し、その後に実際の用途まで伸ばすのが安全です。
HermesのステータスバーではGPU利用率、GPUメモリ、RAMを確認できます。
16GB VRAMで27B級を使うときに見落としやすいのが、VRAM容量だけでは必要メモリを判断できない点です。
HermesのMemory fitはモデル本体だけでなく、コンテキスト状態、ランタイムのバッファ、画像モデルで使うvision projector、MTP用バッファまで含めて起動構成を計算します。
そのため、同じ27B級でも量子化や最大コンテキスト、画像対応の有無によってgreen・amberの判定が変わります。
Windows/LinuxについてHermes公式は「27BならシステムRAMが何GB必要」と一律の数字を示していません。
GPUからあふれた重みはシステムRAMへ配置できますが、その分だけ生成速度は落ちます。
つまり16GB VRAMのPCでは、VRAMだけでなく搭載RAMにも余裕がある方が扱いやすい一方、快適性を優先するならまずgreen判定のモデルを選ぶのが基準になります。
Apple SiliconはGPU専用VRAMではなく統合メモリをCPUとGPUで共有するため、Windowsの「16GB VRAM」と単純比較できません。
HermesのMac向け手動ガイドでは、27B・35B級は32GB以上の統合メモリを目安としています。
Macではモデルファイル、KVキャッシュ、OSやアプリの使用分を同じメモリ空間で考える必要があります。
速度を左右するのはモデルのパラメータ数だけではありません。
amber判定で一部がシステムRAMへ退避している、会話が長くなってKVキャッシュが増えている、画像入力や長いコンテキストを使っている、といった条件が重なるほど応答は遅くなります。
Hermesは必要に応じてコンテキストを拡張し、より大きなウィンドウが収まらない場合や生成が遅すぎる場合は会話圧縮へ切り替えます。
「Qwenの27B級が起動したか」だけで判断せず、実際の用途で数往復させたときのGPUメモリ、RAM、応答速度を確認するのが重要です。
ステータスバーのSystem resourcesを有効にするとGPU利用率、GPUメモリ、RAMを確認できるため、モデル選びの比較に使えます。
ローカル実行が向くのは、入力データを端末外へ出したくない人、API従量課金を避けたい人、同じPCで継続的にエージェントを動かしたい人です。
一方、GPUを持っていない、最大性能を優先したい、巨大コンテキストを頻繁に使う場合はクラウドモデルの方が扱いやすいことがあります。
Hermes Agentはローカルとクラウドを切り替えられるため、すべてを一方へ寄せる必要はありません。
普段はローカル、難しいタスクだけクラウドという使い分けも現実的です。
ローカルモデル選びでは「動く最大モデル」ではなく、自分の用途で待ち時間と品質のバランスが取れるモデルを選ぶことが重要です。
Hermes Agent Local Modelsの価値は、ローカルLLMそのものを速くすることより、量子化・ランタイム・メモリ配置の面倒な判断を自動化する点にあります。
16GB VRAMは27〜35B級へ入る一つの目安ですが、長文や画像入力まで含めて常に余裕があるとは限りません。
モデルの適合表示と実際のGPU/RAM使用量を確認し、「起動できるか」ではなく「自分の用途で速度を維持できるか」で判断するのが現実的です。
.png){kind=logo}
