128GB の統合メモリ。GPU に最大 96GB まで。Hermes Agent を localhost に向けて、他人のサーバーを使わない。
「誰もがローカルエージェントは無料だと言いますが、私はその考え方は正しくないと思います。」Hermes Agent をクラウドモデルで実行すると、クレジット代が 1 日 10〜20 ドルかかる上に、API キー、顧客データ、ビジネスワークフローを他人のサーバー経由でルーティングするプライバシーリスクもありました。解決策は、エージェントとそれが呼び出すモデルを自分が所有するハードウェアに置き、24 時間 365 日稼働させること。そうすれば、全体がインフラストラクチャとなり、継続的な請求にはなりません。
これは比較ではなく、ビルドログです。常時稼働マシンとしての Minisforum MS-S1 MAX、その上にワークフローレイヤーとしての Hermes Agent。 これらを組み合わせることで、クローゼットに置きっぱなしで、常にオンライン、そして実際のビジネスタスク（コンテンツ作成、リサーチ実行、ツール呼び出し、サブエージェント管理）を、トークンごとのクラウド費用やデータのネットワーク外部への流出なしに処理できるセットアップになります。以下では、MS-S1 MAX の内部構成、セットアップ方法、実際のパフォーマンス数値、そしてその上に Hermes Agent を実用的なビジネス自動化スタックとして組み込む方法を説明します。
ハードウェア: MS-S1 MAX の内部構成
MS-S1 MAX は AMD の Strix Halo プラットフォーム上に構築されており、ローカルで大規模言語モデルを実行するための現時点で最も高性能なミニ PC 向けシリコンです。その理由は、強力な CPU と、このフォームファクター向けに AMD が提供する最大の統合 GPU を組み合わせているからです。これが、単純なチャットしか処理できないマシンと、ツール呼び出し、サブエージェント、長いコンテキストを自身で処理できる実際のエージェントループを実行できるマシンの違いです。
SoC 仕様 (AMD Ryzen AI Max+ 395, 4nm Strix Halo, 45-120W TDP):
1コンポーネント 仕様 CPU 16 cores / 32 threads, Zen 5, 3.0 GHz base – 5.1 GHz boost, 64MB L3 cache グラフィックス Radeon 8060S, 40 CU RDNA 3.5, 2.9 GHz, system-shared VRAM NPU XDNA, 50 TOPS PCIe Gen 4, 16 lanes RAM LPDDR5X, 8000 MT/s, up to 128GB, quad channel, 256GB/s bandwidth
40 CU / 2560 シェーディングユニットの iGPU は、生の性能ではディスクリートの RX 7600 XT にほぼ匹敵し、24 時間 365 日棚の上で稼働させ続けられるほど小型のミニ PC に組み込まれています。
iGPU がノートパソコンよりもここで強力に動作する理由: 8060S は通常、ノート PC シャーシでは約 55W に制限されています。MS-S1 MAX の大型冷却ソリューション（6 本のヒートパイプ、デュアルファン）により、Minisforum はパフォーマンスモードで電力制限を 120W まで引き上げることができ、それに伴い持続クロックも高くなります。これは、短期間のバーストではなく、継続的に推論を実行することを想定したマシンにとって重要です。
ビジネスワークフローを可能にする RAM の仕組み: MS-S1 MAX は 128GB のはんだ付けされた統合クアッドチャネル LPDDR5X を搭載しています。AMDGPU ドライバーは GTT (Graphics Translation Table) を介してシステム RAM を VRAM として割り当てることができ、このマシンでは iGPU がそのプールの最大 96GB を確保し、CPU には 32GB を残します。この 96GB の上限により、この 1 台のマシンで本格的なモデルをホストし、同時にエージェントプロセス、ダッシュボード、その他の常時稼働サービスを同一ボックス上で実行できます。
モデルレイヤーのセットアップ (Strix Halo 上の llama.cpp)
Strix Halo 上で llama.cpp 用の事前構築済み Toolbox コンテナをメンテナンスしており、いくつかのバックエンド（vulkan-amdvlk、vulkan-radv、rocm-6.4.4、rocm-6.4.4-rocwmma、rocm-7rc-rocwmma）に対応しています。これらは主に HP G1a Mini（同じ Strix Halo チップ）向けに構築されていますが、MS-S1 MAX を含むほとんどの Strix Halo マシンで動作します。テストでは vulkan-radv バックエンドが最も安定しており、大規模モデルも問題なくロードできます。
BIOS/UEFI: 最小 VRAM 割り当てを 1GB（Minisforum BIOS の最小値）に設定します。これにより、AMDGPU ドライバーが GTT 経由でシステム RAM を VRAM として自由に割り当てられるようになります。
カーネルパラメータ（Arch Linux でテスト済みですが、Strix Halo カーネルをサポートする最近のディストリビューションなら動作するはずです）VRAM 割り当てを最大化し、レイテンシを低減します:
amd_iommu=off amdgpu.gttsize=131072 amdttm.pages_limit=33554432 amdttm.page_pool_size=15728640
GPU パススルーで Toolbox を作成:
toolbox create llama-vulkan-radv
--image docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv
-- --device /dev/dri --group-add video --security-opt seccomp=unconfined
中に入る:
toolbox enter llama-vulkan-radv
内部では、llama-cli と llama-server がモデルを実行する準備ができています。すべてのレイヤーを GPU に強制して、CPU を他のすべて（エージェントプロセス、Tailscale、ダッシュボード）のために解放します:
1# 端末のみ2llama-cli --no-mmap -ngl 999 --flash-attn on -m <model>34# Web サーバー UI — Hermes Agent が指す先5llama-server --no-mmap -ngl 999 --flash-attn on --host <ip_address> --port <port_number> -m <model>
使用したモデルは Hugging Face 上の Unsloth から入手した GGUF 形式のものです。
モデルの切り替え: llama-swap を使うと、手動で再起動することなくエージェントにサービスを提供するモデルを簡単に切り替えられます。Linux バイナリをダウンロードし、chmod +x して、config.yaml を定義します。
1models:2 "OpenAI-20B-GPT-OOS":3 cmd: |4 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/gpt-oss-20b-GGUF/gpt-oss-20b-F16.gguf -c 400005 "gemma-3-27b-it-abliterated":6 cmd: |7 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/gemma-3-27b-it-abliterated-GGUF/gemma-3-27b-it-abliterated.q6_k.gguf -c 400008 "OpenAI-20B-NEO-CODEPlus":9 cmd: |10 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/OpenAI-20B-NEO-CODEPlus-Q5_1/OpenAI-20B-NEO-CODEPlus-Q5_1.gguf -c 4000011 "OpenAI-120B-GPT-OOS":12 cmd: |13 llama-server --no-mmap -ngl 999 --flash-attn on --port ${PORT} -m /models/gpt-oss-120b-GGUF/gpt-oss-120b-UD-Q4_K_XL-00001-of-00002.gguf -c 40000
これにより、マシンに直接触れることなく、異なるタスク（素早い返信には軽量で高速なモデル、より高度な推論が必要な場合には 120B モデル）に応じてモデルを切り替える Web UI が提供され、チャット履歴は切り替え後も保持されます。
パフォーマンス数値 (このマシンがエージェントワークロードを処理できる理由)
llama-bench を使用したプロンプト処理 (pp512) とテキスト生成 (tg128) の結果:
1モデル サイズ プロンプト処理 (t/s) テキスト生成 (t/s)2GPT-OSS-120B (Q4_K_XL) 58.7GB 454.15 ± 2.98 56.61 ± 0.033GPT-OSS-20B (F16) 12.8GB 965.54 ± 9.56 46.84 ± 0.064Gemma-3-27B (Q6_K) 20.6GB 178.14 ± 1.09 9.65 ± 0.015Qwen3-30B-A3B (BF16) 56.9GB 163.01 ± 1.33 9.23 ± 0.04
常時稼働のエージェントにとって重要な数値: 完全ローカルの 120B モデルが 56.6 トークン/秒で生成しています。これは、Hermes Agent が複数ステップのツール呼び出しチェーンを実行しても、すべてのタスクが長い待ち時間になることがないほど高速です。
実際の負荷テスト: GPT-OSS-120B に「LLM に関するエッセイを生成（5000 語）」というプロンプトを与えたところ、7,990 トークンが 51.2 トークン/秒で生成されました。iGPU の平均消費電力は約 110W、エッジ温度は 68〜69°C で安定し、静かで特に高温にはなりませんでした。これは、6 本のヒートパイプとデュアルファンの冷却機構、およびファンカーブを改善した BIOS 1.03 アップデートのおかげです。この電力と熱のプロファイルこそ、このマシンをビジネスボックスとして 24 時間 365 日稼働させることを現実的で安全なものにしている理由です。
NPU: XDNA 2 NPU（50 TOPS）は、まだサポートが未成熟なため、このセットアップでは使用していません。Ryzen AI NPU での LLM 推論を可能にするプロジェクト FastFlowLM は、将来的にさらに多くのワークロードをオフロードする方法として有望ですが、現時点では Windows が必要です。
ワークフローレイヤー: その上に Hermes Agent を配線する
ここでマシンはベンチマークから実際のビジネスツールへと変わります。Hermes Agent は、上記のローカルモデルを活用して、実際に動作するもの（コンテンツの下書き、ツール呼び出しの実行、ブラウジング、サブエージェントの管理、スケジュールに従ったアクション）に変換するレイヤーです。
1. Hermes Agent をインストールし、ローカルモデルを指定します。 Hermes のオンボーディングでは、モデルプロバイダーを尋ねられます。ローカル/セルフホストの OpenAI 互換を選択し、llama-server が実行されている localhost:<port> を指定し、ローカルなので API キーはスキップします。Hermes は最低 64,000 トークンのコンテキスト長を必要とします。ワークフローに大量のコーディングや長いドキュメントが含まれる場合はその値を上げ、メールやソーシャル投稿などの短いタスクには低く保ちます。
2. ローカルモデルをデフォルトに設定しますが、唯一のオプションにはしません。 実際のプロダクションセットアップは設計上ハイブリッドですが、それはハードウェアが追いつかないからではなく、一部のタスク（素早い返信、簡単な書式設定、短い検索）には 120B のローカルモデルが本当に必要ないからです。ローカルモデルをデフォルトに設定し、実際に価値が追加されるケース（負荷の高いツール呼び出しチェーン、長いデバッグループ、速度がプライバシーよりも重要なタスク）には、フォールバックプロバイダー（OpenAI、Claude、または Open Router）をルーティング指示とともに追加します。Open Router はこれを安価に実現する方法です: 10 ドルで約 1,000 リクエストが購入でき、重要でないサブエージェントタスクの逃し弁として役立ちます。
3. 24 時間 365 日稼働させ続けます。 ビジネスワークフローは、ラップトップを閉じたときに停止しない限り機能しません。Hermes Agent が起動時に自動的に再起動するように設定します:
1sudo systemctl enable tailscaled2sudo systemctl enable hermes-agent
Hermes Agent がデフォルトで systemd サービスとしてインストールされていない場合は、任意の AI コーディングアシスタント（Codex、Claude、Gemini、Warp）が同等のサービスファイルを生成できます。
4. Tailscale を使ってどこからでもアクセスできるようにします。 これにより、MS-S1 MAX は「座って操作しなければならないマシン」からインフラストラクチャへと変わります。ミニ PC と、実際に日常的に作業するデバイス（ラップトップ、スマートフォン）に Tailscale（無料の個人プラン、最大 6 ユーザー）をインストールします。両方が同じ Tailscale ネットワーク上にあれば:
- ラップトップからミニ PC に SSH 接続して、エージェント自身では実行できない管理コマンドを実行
- Hermes Agent のダッシュボードを、物理的には別の部屋や国にあるマシンであっても、localhost で動作しているかのようにリモートで開く
- iOS では、一部のターミナルアプリ（Termius）が Tailscale が期待する SSH ハンドシェイクをスキップするため、Tailscale のアクセス制御で SSH アクセスモードを「accept」に設定すると、スマートフォンから接続できるようになります。これは、机を離れているときにスタックしたワークフローを修正するのに便利です。
5. エージェントにビジネスタスクを実行させます。 このようにスタックを配線すると、日常のパターンは次のようになります: リサーチ、執筆、要約、およびルーチンのツール呼び出しは、MS-S1 MAX 上で無料でローカル実行され、結果は Telegram、ダッシュボード、または Hermes が統合する任意の場所にプッシュされます。高速である必要があるもの（リアルタイム、顧客向け）や、ローカルモデルでは真に匹敵できない推論が必要なものは、デフォルトではなく例外としてフォールバックプロバイダーにルーティングされます。
ハードウェアの選択が実際に得られるものを左右する理由
ローカルモデルは、その上のすべてのボトルネックです。低い 2 桁のトークン/秒の 9B モデルでも Hermes Agent を実行できますが、サブエージェントやツール呼び出しを伴う複数ステップのエージェントタスクは数分に及ぶため、フォールバックルーティングが引き継がなければならない前に、どれだけのワークロードを現実的にローカルに留めておけるかが制限されます。56+ トークン/秒の 120B クラスのローカルモデルは、ローカルマシンが単独で吸収できる日常のワークロードの量を変えます。ビジネスロジックの多くは自分が所有するハードウェアに留まり、クラウドフォールバックは、些細でないすべてのもののデフォルトパスではなく、真のエッジケースのためのツールになります。
プライバシーはハードウェアによって変わらない部分です。 ローカルで実行されているモデルが何であれ、API キー、顧客データ、ビジネスワークフローはネットワークの外に出ることはありません。これは、小さなモデルを実行する Raspberry Pi でも、120B モデルを実行する MS-S1 MAX でも同じです。ハードウェアが決めるのは、クラウドオプションに手を伸ばす前に、どれだけの有用な作業が行われるかということだけです。
実用的な takeaways
実際にビジネスワークフローを処理することを目的とした 24 時間 365 日稼働のローカルエージェントスタックには、次の要件があります: 真に有能なモデルをロードするのに十分な統合メモリ、そのモデルを継続的に実行するのに十分な持続的な電力/熱ヘッドルーム、そして、常時オンにしても実際の費用として現れないほど低いアイドル消費電力。
MS-S1 MAX の 96GB アドレス可能な iGPU メモリ、110W の持続負荷消費、静かな 6 ヒートパイプ冷却がそのハードウェア面をカバーします。llama-server をローカルで実行し、Tailscale 経由でどこからでもアクセス可能な Hermes Agent がワークフロー面をカバーします。これらを組み合わせることで、クローゼットに置いて永久に稼働し、継続的なクラウド請求やデータの外部流出なしに、ビジネスの日常的な AI ワークロードの有意義な部分を処理できる単一のミニ PC が完成します。
一般的なワークステーション用途としても、MS-S1 MAX は PCIe とデュアル M.2 拡張、約 5W のアイドル電力、デュアル 10Gbps イーサネット、USB4 v2（80Gbps）を備えています。これらはいずれも LLM 固有のものではありませんが、このマシンがエージェントボックス以上の二重の役割を果たす場合にはすべて重要です。
