ローカルモデル
目次
Hermes はオープンなモデルを、自分の端末のなかだけで動かせます。推論エンジン （llama.cpp）のダウンロードと管理、手元のハードウェアに合うビルドの選択、 メモリのやりくりまで Hermes が引き受けるので、コンテキスト長も GPU レイヤー数も量子化も設定せずに済みます。使う人はモデルを選ぶだけで、 あとは Hermes がやります。
何も端末の外には出ません。アカウントも API キーも要らず、モデルを ダウンロードしたあとはネットワークにもつなぎません。
デスクトップでの提供状況とダウンロード
Local Models は、macOS・Windows・Linux（x64 と arm64）のデスクトップアプリでは、どのリリースの チャンネルでも最初から有効です。それ以外のプラットフォームでは、アプリを --local 付きで起動すると 表示されます。ランタイムは最初から 同梱されていることがあります。同梱されていない場合は、管理ツールのインストール経路に進みます。 llama.cpp の最新版を適当にダウンロードすることはありません。
エンジンのインストール、エンジンの更新、カタログのモデル、Hugging Face からのダウンロード、 クイックスタートでは、Pause（一時停止）と Resume（再開）が使えます。一時停止したジョブは、 Local Models を離れて開き直しても表示されたままです。一時停止は、転送をチャンクの区切りで止めます。 展開、検証、サーバーの起動はそれぞれ別の段階です。
PM は、CUDA のランタイム DLL を含むエンジンの部品をすべて、pm/lock.json にある URL と SHA-256 の固定値に従ってダウンロードします。モデルの重み、分割された GGUF の各部分、 画像認識用のプロジェクター、ドラフトモデルも同じダウンローダーを使います。バイト単位の進み具合は、 完了済みのファイルや再開した範囲も含めた、ダウンロード計画の全体を対象にしています。 クイックスタートでは、エンジンとモデルの進み具合を別々の段階として表示します。
途中までのダウンロードは、署名されたアプリのパッケージの外にある、PM の書き込み可能な cache/partials 領域に置かれます。Range に対応したホストからは、足りないバイトだけを再開して取得します。 Range に対応していないホストでは、そのファイルを最初から取り直します。完了したファイルは再利用されます。
導入
- 設定 → Providers → Local Models を開きます（初回設定の途中で
Run models locally を選んでも構いません）。
- Install runtime を押します。手元のハードウェア向けの公式 llama.cpp
ビルド（数百 MB）を Hermes がダウンロードして検証し、以後は最新に 保ちます。
- カタログからモデルを選んで Download を押します。
- Use を押します。これ以降の新しいチャットは、ローカルのモデルで
動きます。
流れはこれで全部です。サーバーは Hermes と一緒に起動・終了し、アプリを 再起動しても設定は残ります。クラウドのプロバイダーに戻したいときも、 モデル選択欄で 1 回押すだけです。
ターミナルからは、hermes model → Local models で同じ設定ができます。 手元の端末に合わせて見積もったカタログを一覧にし（★ がおすすめの印です）、 固定版のエンジンを入れ、進み具合を表示しながらモデルをダウンロードし、 サーバーを起動して、そのモデルを既定にします。すでにディスクにあるモデルも候補に出ます。 Ctrl+C でダウンロードを一時停止し、同じモデルをもう一度選ぶと再開します。
Hermes が何をダウンロードするか決めるしくみ
カタログに並ぶモデルは、ダウンロードする前に 手元の端末 を基準に 値踏みされます。各行に出るのは次の情報です。
- メモリの収まり — 緑（*Fits your GPU*: GPU メモリだけで動きます）、
黄（*Uses system RAM*: 動きますが遅くなります）、赤（*Too big for this machine*: この端末には大きすぎます）。
- コンテキスト — そのモデルが最初に使う長さと、伸ばせる上限。
- 手元のハードウェア向けに選ばれたビルドのダウンロードサイズ。
モデルにはいくつかの品質段階（量子化）があります。Hermes は GPU だけで 動き切るなかで最も品質の高いビルドを選び、メモリの少ない端末には同じ モデルのより小さなビルドを同じ保証のまま渡します。4 ビットを下回ると 品質の落ち方が大きすぎるので、それより小さいビルドは用意しません。 システム RAM にあふれさせた 4 ビットのビルドすら動かせない端末では、 そのモデルは動かない、ということです。
収まらないモデルも理由付きで表示に残るので、ハードウェアを増強すると 何が使えるようになるかがいつでも分かります。
Hermes がおすすめするのは、GPU かユニファイドメモリの中だけで動き、 予測で毎秒 20 トークン以上出せるモデルのうち、いちばん品質の高いものです。 端末のメーカーが別の既定モデルを決めていることもあり、その場合は そのモデルが収まる限りそちらをおすすめします。この基準に届くモデルが一つもないときは おすすめを出しませんが、収まるモデルならどれでも選べます。
メモリ管理のしくみ
ローカルのモデルはメモリの置き場所で生き死にが決まります。そのため Hermes が最初から最後まで管理し、つまみは一切出しません。
- モデルは GPU に完全に収まるコンテキスト長で始まり、会話が長くなって
余地が要るにつれて本来の上限へ向けて伸びていきます。長い作業の途中で ステータス欄に "Context window grown" と出ることがありますが、これは 長さが伸びただけでエラーではありません。
- 推奨モデルには最低でも 64K のコンテキスト長が確保されます。 モデルが
GPU のメモリより大きいとき、Hermes は影響のいちばん小さい順（まず エキスパートの重み、アテンションのキャッシュは決して動かしません）で あふれた分をシステム RAM に置き、速度をいくらか譲ってこの長さの保証を 守ります。
- メモリの収まりは起動時の構成込みで数えます。 モデルのファイルだけ
ではなく、コンテキストの状態、ランタイムのバッファ、画像認識用の プロジェクタ、MTP のバッファまで勘定に入ります。マルチトークン予測 （MTP）では、大きなバッチだと同じコンテキスト長であふれてしまう場合に 小さなバッチを使います。MTP 自体は有効なままです。再起動後に伸びた 長さを復元するときも、同じ計算が走ります。
- 会話の圧縮は、長さを伸ばせるかを確かめたうえで行われます。 もっと
長い窓が収まらない、生成が遅すぎる、あるいは本来の上限に届いた場合、 Hermes はサーバーが受け取っていない長さを名乗る代わりに、会話を圧縮 します。
- 使われていないモデルは 15 分で読み込みを解いて GPU メモリを空けます。
次のメッセージが来れば自動で読み直します。
ステータスバー
ステータスバーを右クリックして System resources を有効にすると、 ローカルのモデルが動いている間の GPU 使用率・GPU メモリ・RAM を その場で確認できます。コンテキストのメーターは、モデルが実際に使って いる長さを常に映します。
もっとモデルを探す
カタログは選りすぐりの出発点であって、そこで打ち止めではありません。 同じページの Find more models から Hugging Face 全体を検索できます。
- 検索結果にはダウンロード数と、手元の端末に合わせたファイル単位の
収まり判定が出るので、GPU だけで動き切るかどうかをダウンロード前に 確かめられます。
- 落としてきたモデルはカタログのものとまったく同じように動きます。
Hermes がモデルのファイル自体を読んで、コンテキスト長とメモリの 置き場所を決めるからです。違うのは、コミュニティのモデルには こちらの「検証済み」バッジが付かないという点だけです。
- すでに
.ggufのファイルを持っているなら、Add model file で
コピーせずに手持ちに取り込めます（元のファイルはその場に残ります）。 取り込んだらすぐ使えます。
自前の llama-server を使う
すでに llama-server が端末で動いている場合、Hermes はそれを見つけて、 自前のサーバーを起動せずにそちらを使います。OpenAI 互換のサーバーで あれば、カスタムのエンドポイントを向けて全部を手動で握ることもできます。 付属のランタイムはあくまで既定であって、必須ではありません。入力欄には サーバーのルート（たとえば http://127.0.0.1:8080）でも、/v1 まで 付けた URL でも構いません。接続テストが両方を試し、実際に /models を 返したほうを保存するので、チャットの問い合わせも、モデル一覧を取れたの と同じ場所へ届きます。手動で組む場合（Ollama、MLX、独自ビルド、画面の ない CLI の端末など）は Run Hermes Locally with Ollama と Run Local LLMs on Mac を見てください。
設定
付属のランタイムは config.yaml の local_runtime セクションで制御します。 デスクトップの画面がこの値を書いてくれますが、CLI や画面なしの運用の ためにここに載せておきます。
local_runtime:
enabled: false # true = start the managed server with Hermes.
# The desktop "Use" button sets this automatically.
backend: auto # auto | cuda | metal | vulkan | hip | cpu
detect_ports: [8081] # extra ports to probe for a llama-server you run
# yourself (the default probe is :8080 only)llama-server を自分で決まったポートに立てて動かす場合も、選び方は同じ model.provider: llamacpp のままで動きます。そのポートを local_runtime.detect_ports に並べるか、providers: の下で接続先を はっきり書いてください（明示した設定のほうが、サーバーの自動検出より 優先されます）。
providers:
llamacpp:
base_url: http://127.0.0.1:8081/v1
model: my-model/model の Local の行も provider: llamacpp も、そのサーバーを指す ようになります。つながるサーバーが 1 つもないときは、知らないプロバイダー だとか API キーがないといった言い方ではなく、ローカルのランタイムの話だと 分かるエラー（「the local model server isn't running」）が出ます。
エンジンのバージョンは PM のロックファイルだけで決まり、local_runtime.tag で 上書きすることはできません。起動時は、インストール済みの PM のエンジンをダウンロードせずに使います。 新しい固定版が出たら、デスクトップの更新ボタンからインストールしてください。
モデルは、端末で共有される models/ ディレクトリに置かれます。エンジンのバイナリは PM のストアに置かれ、runtimes/llamacpp/ には変更されうるプリセットとサーバーの状態が入ります。 ローカルのモデルを主役のモデルに据えるときは、いつもの model.provider: llamacpp と model.default の設定を使います。
必要なものと限界
- Windows: 対応する NVIDIA の環境では CUDA、x64 では Vulkan、または CPU。
Linux: x64 と arm64 の NVIDIA での CUDA（CUDA 13 対応のドライバーが必要）、Vulkan、または CPU。 macOS: Metal または CPU。HIP/ROCm は、対応する x64 の環境で明示的に選んだときだけ使います。 対応していないバックエンドと環境の組み合わせは、ダウンロードを始める前に失敗します。
backend: autoは、NVIDIA なら CUDA、AMD と Intel の GPU なら Vulkan を優先し、
使えなければ上に挙げたその環境向けのビルドに切り替えます（GPU が見つからなければ CPU）。 Vulkan か HIP のエンジンでは、単体の GPU はそのカード自身のメモリで大きさを見積もり （システムの RAM ははみ出した分の置き場です）、起動のたびにほかのプログラムがそのカードで使っている分を差し引きます。 内蔵 GPU はシステムの RAM を共有するので、RAM から見積もります。 Quickstart はモデルを選ぶ前にエンジンを入れるので、選ばれるモデルはカードに合ったものになります。
- メモリ 8 GB 以上の GPU があればカタログの小さめのモデルは快適に動き、
16 GB 以上なら 27〜35B のモデルを高い品質で動かせます。
- モデルが揃っているかは、カタログのサイズの見積もりではなく、サーバーの応答と突き合わせて確かめます。
中断した転送は、再開できるよう途中までのファイルを残します。欠けたファイルが公開されることは ありません。エンジンのアーカイブは、使う前に SHA-256 で検証します。
- モデルを削除すると、画像認識のアダプタや投機的デコード用の相棒まで
含めて、そのモデルが置いたファイルをすべて消します。