僕は月 5 ドルを払って、ほとんどの時間なにもしない VPS を 1 台維持している。1 GB の RAM、共有 CPU 1 コア、20 GB の SSD、パブリック IPv4 が一つ。VPS 業者はどこも似たようなスペックのこれを売っていて、個人プロジェクトを何か一つでも走らせたことがあれば、たぶん手元に、まだ余力のあるそういう箱がすでに一台転がっている。
先月、僕は自分のそれを Hermes Agent のゲートウェイに仕立てた。いま、それは Telegram で僕に返事をしてくれて、cron の定時ジョブで友達と共有している Discord チャンネルに要約を投げ、IMAP の受信箱を見張っていて——この文章を書いている今この瞬間——RAM は約 320 MB、CPU は 2% を切っている。コーヒー一杯の値段で、常時オンのアシスタントが手に入った。
この記事は、そのセットアップの実践ガイドであり、小さなマシンで本当に違いを生むほんの数個の判断についての話でもある。
実際に何が必要か
Hermes を動かすには、まともな業者（Hetzner、DigitalOcean、Vultr、Linode、Contabo、OVH——どれも同じものをほぼ同じ値段で売っている）の 5 ドル枠の VPS で十分だ。見るべき数字はこれだ。
- •最低 1 GB の RAM。 Hermes の Python プロセスそのものは起動後に 200〜300 MB あたりに落ち着く。Telegram、Discord、Slack などゲートウェイのスレッドがそれぞれ少しずつ上乗せする。言語モデル API ライブラリが応答をバッファしたり、たまに大きめのデータをロードするツールが走ったりするぶんの余裕も残しておきたい。
- •最低 10 GB のディスク。 Hermes 本体、すべての依存、セッション DB、cron の履歴、ログファイルを全部合わせても 5 GB 以下に余裕で収まる。残りはぜんぶマージンだ。
- •アウトバウンド HTTPS。 必要なネットワーク条件はこれだけだ。オプションの OpenAI 互換 API サーバを立てるか、Telegram アダプタをポーリングではなく webhook モードで動かすのでなければ、インバウンドのポートを開ける必要はない。
- •systemd が載ったモダンな Linux ディストリ。 Ubuntu 22.04 か 24.04 が一番面倒のない既定値だ。Debian 12 でも問題ない。ゲートウェイのサービスウィザードは、systemd を使って Hermes を常駐のシステムサービス、またはユーザサービスとして登録する。
このリストに敢えて入っていないもの：GPU、特定の CPU アーキテクチャ（AMD、Intel、ARM64 のどの VPS でも Hermes はちゃんと動く）、ドメイン名、リバースプロキシ、その他諸々。ゲートウェイは既定ではアウトバウンドしか使わない。
インストール、そしてそれが何をやっているのか
最初のコマンドは hermes setup。これがウィザードで、どのプロバイダを使うか（OpenRouter、Nous Portal、Anthropic、OpenAI、Hugging Face、またはローカル／カスタムのエンドポイント）を聞き、API キーの貼り付けを手伝い、デフォルトモデルを選ばせて、結果を ~/.hermes/config.yaml に書き込む。
小さなマシンで次に重要なのは hermes gateway install。このコマンドが Hermes を systemd サービスにしてくれるので、再起動しても勝手に立ち上がり、クラッシュしても自動で戻ってくる。スコープは user（ログインユーザとして動き、sudo 不要）か system（ログイン前から起動する、ヘッドレス機向け）から選べる。5 ドル VPS ならたいてい user スコープで十分だ。ヘッドレスな環境では Hermes が systemd の linger を自動で有効にしてくれるので、接続を切ったあともサービスは走り続ける。
そこから、hermes gateway enable telegram（あるいは discord、slack、signal、matrix など）でプラットフォームを一つずつ追加していく。アダプタはそれぞれプラグインで、1 プラットフォームだけ動かしてもいいし、8 個同時に動かしてもいい。プラットフォームを 1 つ足すときの追加メモリはごく小さい——Python オブジェクトで数 MB に、そのプラットフォームの SDK が内部でバッファしたいぶんだけだ。
小さな箱で本当に効く判断
安い VPS での体験の良し悪しを決めるのは、実質この 3 つの選択だ。
モデル選び。 VPS 上の agent のメモリ消費はモデルの大きさには依存しない——推論はこの箱の上では起きないからだ。しかし応答ごとのレイテンシとコストはモデル次第だ。個人用ゲートウェイのスイートスポットは、中サイズの速いモデル（Claude Sonnet、GPT-4.1 mini、Gemini Flash、または補助タスク用に Nous Portal の無料枠の MiMo v2 Pro）を既定にしておいて、必要なときだけ /model コマンドでより強いモデルに引き上げる、というあたりだ。ライブモデル切り替えのおかげで、この切り替えは会話を再起動することなく、会話の途中からそのままできる。
コンテキスト圧縮。 既定値のままで十分だ。Hermes はコンテキストウィンドウが埋まりかけると会話履歴を先回りして圧縮し、圧縮済みの要約はキャッシュされる。小さな VPS でこれが重要なのは、コンテキスト圧縮はローカルで走って CPU を食うからだ——圧縮をオンにしたままにしておけば、長い会話も速いままで、1 ターンでトークン予算を丸ごと燃やしてしまう事故も起きにくい。
認証情報プール。 API キーを複数本持っている人（プロバイダのアカウントを友人とシェアしていたり、複数の無料枠をローテーションしていたり）向けに、Hermes には同一プロバイダ内の認証情報プール機能がある。レート制限や 401 エラーのときに自動でキーを回してくれる。小さな VPS の上では、これは実質 N 本の無料枠を「いつでも使える 1 本」に束ねる仕組みになっていて、常時オンのアシスタントにぴったりだ。
そもそも、なぜこれが成り立つのか
5 ドルの VPS で本物の AI アシスタントを動かせるのは、Hermes が英雄的に最適化されたからではない。重い部分——言語モデル——を他人に任せて、調整・記憶・ツール実行のロジックだけをローカルに残す、というアーキテクチャの切り分けのおかげだ。この一刀両断があるから、月額がまともな額に収まり、ごく小さなマシンでもこれで十分足りる、という話になる。
昔は、アシスタントを自分でホストする＝モデルを自分で走らせる、という意味だった。いまは違う。いまは、モデルに「何をするか」を告げる側を走らせる、という意味になっている。