著者 Matt Connor
OllamaをVPSで安全にホストする方法
7Bモデルには約8 GBのRAMが必要で、CPUでは毎秒4〜10 tokensです。OllamaをVPSで動かし、127.0.0.1:11434/v1から呼び出す構成と、port 11434を閉じる理由を解説します。
構築するもの
所有するサーバー上で動作する単一のオープンウェイト言語モデルです。HTTP API 経由で応答し、必要であればブラウザーでチャットページも利用できます。Ollama はモデルをダウンロードしてメモリに読み込み、http://127.0.0.1:11434 でリクエストを処理するコンポーネントです。インストールは 1 つのコマンドで完了します。難しい点は別の部分にあります。VPS の RAM に実際に収まるモデルを選ぶことと、認証のない推論サーバーを誤ってインターネット全体に公開しないことです。
最初に、重要な注意点を 2 つ示します。CPU のみの VPS では、小型モデルでも処理速度が遅くなります。また、API には組み込みの認証機能がありません。どちらも問題が発生しやすい部分であるため、以下で詳しく説明します。
数値で確認するサイズの現実
モデルのメモリ使用量は、おおむねモデルのファイルサイズに、実行時のオーバーヘッドとして約 1 GBを加え、さらにコンテキストウィンドウ分を加えた値です。代表的な Ollama モデルのデフォルトタグは、llama3.2:3b、llama3.1:8b、mistral:7bなどを含め、4-bit量子化（Q4_K_M）されています。これはパラメータ 1 billionあたり約 0.5 GBの RAMを使用します。すべてのデフォルトが Q4とは限りません。smollm2:135mのような小型モデルは 16-bitで提供されるため、計算する前にモデルのライブラリページで量子化の行を確認してください。計算は単純で、適合するかどうかを決める要素になります。最後のコンテキスト分は自分で設定します。Ollama の小さなデフォルト値を超えて num_ctx を増やすと長いプロンプトを扱えますが、RAM内の KV cacheが増加します。そのため、モデルが適合するか判断する前にコンテキスト長を決めてください。
llama3.2:3bのような 3Bモデルは約 2 GBのダウンロードで、実行には約 4 GBの空き RAMが必要です。mistral:7bやllama3.1:8bのような 7Bまたは 8Bモデルはディスク上で約 5 GBを占有し、約 8 GBの RAMを必要とします。快適に使うには 16 GBが必要です。13Bまたは 14Bモデルには、おおむね 16 GBが必要です。30Bから70Bの範囲のモデルには大容量 RAMのマシン、現実的には GPUが必要です。CPU VPSでは適合しないか、適合しても応答が遅すぎて実用になりません。
次に速度です。ここは過小評価されがちです。CPU推論はクロック速度ではなくメモリ帯域幅に制約されます。共有 vCPU VPSの帯域幅は限られています。1秒あたり 1桁から 10台前半の tokensを見込んでください。7-8Bの Q4モデルなら 1秒あたり 4から 10 tokens、3Bモデルなら 10から 25 tokens程度です。GPUはおおむね 1桁速くなります。ここに示した数値は意図的に概算です。下の実行手順で説明するように、自分のマシンで測定するのが確実です。どの記事の数値でもなく、この記事の数値も含めて、eval rateを信頼してください。
実用上の結論は、CPU上の小型量子化モデルは、処理速度を許容できるなら、下書き、要約、分類に十分役立つということです。より大きなモデルや高速な処理が必要なら、GPUインスタンスの予算を確保してください。特定の 1 つのモデルでこの計算を最初から最後まで確認したい場合は、VPS上で Nemotron 3.5 Lightningを実行するで、取得するタグ、実際に必要な RAM、CPUのみで処理が追いつくかを説明しています。
特定のモデルを特定のマシンで実行できるか評価するには、ここでメモリ使用量を見積もります。
Ollama のインストール
方法は2つあります。ベア VPS では、公式スクリプトが最も簡単です。
curl -fsSL https://ollama.com/install.sh | shこのコマンドにより、ollama という名前の system user が作成され、バイナリが /usr/local/bin/ollama にインストールされます。また、起動時に開始し、127.0.0.1:11434 に bind する ollama.service という名前の systemd service が登録されます。起動していることを確認します。
systemctl status ollama
ollama --versionすでに Docker を使用している場合は、コンテナを使用します。
docker run -d --name ollama \
-p 127.0.0.1:11434:11434 \
-v ollama:/root/.ollama \
--restart always \
ollama/ollamaポートマッピングの 127.0.0.1: プレフィックスに注意してください。これにより、ポートは localhost にのみ bind されます。-p 11434:11434 と記述すると、すべてのインターフェースで公開されます。これは、セキュリティセクションで警告している誤りです。インストール方法は1つだけ選択してください。スクリプトとコンテナを同時に実行しないでください。2つのプロセスがポートを奪い合うことになります。
最初のモデルを取得して実行する
ollama pull llama3.2:3b
ollama run llama3.2:3bpull はモデルのレイヤーをディスクにダウンロードします（このモデルでは約 2 GB）。run はレイヤーをメモリに読み込み、>>> プロンプトを表示します。質問を入力してください。重みをディスクから RAM に読み込む間、最初のトークンが表示されるまで数秒かかる場合があります。その後、回答がストリーミング表示されます。チャットを終了するには /bye と入力してください。Ollama はバックグラウンドで実行を続けます。
読み込まれている内容と、その構成を確認します。
ollama psPROCESSOR 列が実際の処理内容を示します。100% CPU は GPU を使用していないことを意味し、速度が遅い原因はここにあります。verbose フラグを使用して実際の速度を測定します。
ollama run --verbose llama3.2:3b "Write two sentences about Linux."最後に表示される eval rate 行が、このハードウェアでの 1 秒あたりのトークン数です。この値を基準に計画してください。
モデルの保存場所と必要なディスク容量
スクリプトでインストールし、サービスとして実行する場合、モデルは ollama ユーザーのホームディレクトリに保存されます。
sudo du -sh /usr/share/ollama/.ollama/models自分のユーザーで対話的に実行する場合、モデルは ~/.ollama/models に保存されます。コンテナでは、ollama という名前付きボリュームに保存されます。この違いは重要です。量子化済みの重みでも容量はすぐに増えるためです。3B モデルは約 2 GB、7-8B モデルは約 5 GB、14B モデルは約 9 GB を使用します。比較のために 4 つのモデルを取得すると、気付かないうちに 20 GB を消費します。保持するモデルに必要な容量を見積もってディスクを用意し、不要なモデルは ollama rm <model> で削除してください。同じ VPS で、写真ライブラリを保持する PhotoPrism または Immich など、別の大容量データを使用するサービスも実行している場合は、その使用量を空き容量から先に差し引いてください。残った容量を、実際にモデルへ割り当てられる容量として扱います。
制御するサービスとして実行する
インストールスクリプトはすでに ollama.service を登録しているため、追加の作業なしでブート時に再起動します。変更する価値がある設定は、モデルをメモリに常駐させる時間と、一部の構成での bind アドレスです。どちらも systemd の drop-in に記述するため、Ollama のアップグレードで上書きされません。
sudo systemctl edit ollama.serviceエディターに表示された [Service] ヘッダーの下に、次を追加します。
[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"OLLAMA_KEEP_ALIVE は、最後のリクエスト後にモデルをメモリに保持する時間です（デフォルトは 5 分）。1 日を通して問い合わせるサーバーでは、毎回 weights を再読み込みしないよう値を大きくします。メモリに余裕がないサーバーでは 0 に設定すると、リクエストの完了直後に RAM を解放します。モデルを一定時間ではなく無期限に常駐させる場合は、Ollama のモデルを常時ロードしておくで、リクエスト単位の keep_alive フィールドと、最初の時間がかかるリクエストではなく再起動後に weights を再びウォームアップする方法を説明しています。systemctl edit は unit ファイルを再読み込みするため、変更を適用するには再起動します。
sudo systemctl restart ollama最も重要なセキュリティ上のポイント
デフォルトでは、Ollama は 127.0.0.1:11434 に bind します。そのため、VPS 自身で動作するプロセスだけが接続できます。このデフォルト設定は正しいため、変更しないでください。
API には認証がありません。本当に何もありません。API key、ログイン機能、rate limit のいずれもありません。唯一の allow-list である OLLAMA_ORIGINS も、呼び出し可能なブラウザーの origin を制御するだけです（CORS）。別のマシン上の curl やスクリプトを阻止する機能はありません。11434 番ポートに到達できるユーザーは、pull 済みの任意のモデルを実行し、新しいモデルを pull し、モデルを削除し、CPU または GPU を無期限に最大負荷で占有できます。Shodan などのスキャナーは、公開された Ollama インスタンスを数千単位でインデックス化しています。外部公開されたインスタンスは、数時間以内に発見され、悪用されます。
したがって、絶対に避けるべき唯一の誤りは、OLLAMA_HOST=0.0.0.0 を設定して firewall で 11434 を開くことです。これにより、認証のない推論サーバーがインターネット全体に公開されます。0.0.0.0 上の 11434 を直接公開する構成は、どれだけ設定しても安全にはなりません。Ollama の documented settings には、local API に認証を追加するものがなく、origin allow-list もログイン機能ではないためです。これはこのサービスに関するルールであり、ポートを決して公開してはいけないという意味ではありません。リモートデスクトップ用の self-hosted RustDesk relay は、機能を提供するために public traffic を受け付ける必要があります。その代わり、独自の key-based authentication と、文書化された短いポート一覧を備えています。Ollama には、そのどちらもありません。
マシンの外部からモデルに安全に接続する方法は3つあります。
- ローカルに限定します。呼び出し元が同じ VPS 上の別のプログラム、cron script、bot、または ツールとモデルを接続する MCP server だけであれば、bind を
127.0.0.1のままにし、そのプログラムからhttp://127.0.0.1:11434を呼び出します。外部には何も公開されず、追加の設定も必要ありません。 - private tunnel 経由で接続します。VPS を 自分で運用する WireGuard VPN に接続し、
OLLAMA_HOSTを tunnel address に設定します（0.0.0.0ではなく、たとえば10.8.0.1）。接続できるのは VPN peer だけです。public internet からは、11434 上のサービスは引き続き見えません。 - 認証機能を持つ reverse proxy を前段に置きます。nginx、Traefik、または Caddy で TLS を終端し、password または token を要求してから
127.0.0.1:11434に proxy します。Ollama は localhost bind を維持し、public port で待ち受けるのは proxy だけです。これは、任意の local service の前段に nginx で Let's Encrypt certificate を設定する構成と同じです。
reverse-proxy の構成は、次に説明する chat UI が実際のログイン機能付きで提供する方法です。
TLS の背後に Open WebUI でチャット UI を追加する
Open WebUI はセルフホスト型のチャットインターフェースです。Docker で実行し、ローカルの Ollama を参照させます。
docker run -d \
--name open-webui \
--network=host \
-e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
-v open-webui:/app/backend/data \
--restart always \
ghcr.io/open-webui/open-webui:mainLinux VPS では、--network=host フラグが重要です。これはコンテナをホストのネットワーク名前空間に配置します。そのため、コンテナ内の 127.0.0.1 はホスト自身のループバックとなり、Ollama がほかのインターフェースで待ち受けなくても、コンテナは 127.0.0.1:11434 で Ollama に接続できます。別の場所で紹介するブリッジネットワークの構成である --add-host=host.docker.internal:host-gateway と OLLAMA_BASE_URL=http://host.docker.internal:11434 は、ここでは機能しません。その名前は Docker ブリッジのゲートウェイに解決されます。また、ホスト上で 127.0.0.1 にバインドされたサービスにはブリッジ経由で到達できません。そのため、Open WebUI は Ollama に接続できないという状態のままになります。
ホストネットワークの代わりに、Open WebUI はホストのすべてのインターフェースでポート 8080 を待ち受けます。-p のマッピングは破棄され、そのことを示す警告が Docker によって出力されます。そのため、ホスト側とプロバイダー側のファイアウォールの両方で 8080 を閉じ、TLS リバースプロキシだけを公開経路にします。初回アクセス時、Open WebUI は管理者アカウントの作成を求めます。このアカウントが認証層になるため、強力なパスワードを設定してください。
ノート PC から HTTPS 経由でチャットを開くには、127.0.0.1:8080 の前段に TLS リバースプロキシを配置します。すでにこのホスト上で複数の Docker アプリをルーティングしている場合は、複数のアプリで TLS を自動化する Traefik が最も適しています。1 つのラベルブロックで証明書を発行し、chat.example.com を Open WebUI にルーティングできます。同じラベル単位のアプリケーションルーティングを、このホスト上のほかのブラウザフロントエンドでも使用できます。ステータスダッシュボードでも、Jellyfin ライブラリを 90 年代のレンタル店として表示する Halcyon のような娯楽向けのアプリでも同様です。それぞれ固有のホスト名とログインを設定します。セキュリティセクションの原則も変わりません。公開ポートとログインはプロキシが管理し、Ollama は localhost に置いたままにします。Open WebUI 自身の 8080 もファイアウォールで保護します。
コードから OpenAI 互換エンドポイントを使用する
Ollama は /v1 で OpenAI chat API の一部を提供しているため、base URL と使い捨ての key の2つを変更すれば、ほとんどの OpenAI client library を使用できます。
from openai import OpenAI
client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
model="llama3.2:3b",
messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)api_key は client library が必要としますが、Ollama は無視します。そのため、任意の文字列を指定できます。model には、すでに pull 済みの名前を指定する必要があります。不明な名前を指定すると、model 'x' not found を含む 404 が返されます。通常の curl 呼び出しも同じ考え方です。
curl http://127.0.0.1:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'これが、model を agent や editor の tooling に組み込む方法でもあります。すでにそのサーバー上で開発している場合は、ローカル model をスクリプトや plugin の基盤として使用できます。tmux 内で VPS 上で実行する Claude Code と併用すれば、低コストでプライベートな下書き処理を有料 API から切り離し、負荷の高い推論は hosted model に任せられます。
障害パターンと、実際に表示される正確な文字列
プロセスが生成途中で「Killed」になる。 大きなモデルを起動すると、端末に Killed と表示されるか、サーバーログ (journalctl -u ollama) に llama-server process has terminated で始まる行が記録されます。これは Ollama 0.40.7 での表示です。2026 年 10 月 21 日に確認しています。以前のリリースでは llama runner process has terminated: signal: killed と表示されました。モデルに必要な RAM がサーバーの搭載量を超えたため、Linux の OOM killer がプロセスを停止しています。sudo dmesg | grep -i oom で原因を確認できます。Out of memory: Killed process ... のような行が表示されます。小型のモデル、または量子化を強くしたモデルを使います。13B の代わりに llama3.2:3b を使う方法もあります。あるいは swap を追加すると、物理 RAM をわずかに超える負荷でも、すぐに停止せず、低速ながら処理を完了できる場合があります。swap は即時クラッシュを遅い応答に変えるだけです。4 GB の環境で 70B モデルを実用的にするものではありません。端末を監視していない限り、この停止は通知されません。そのため、別の場所から問い合わせるサーバーでは、ollama.service に投稿する OnFailure= unit を用意しておくと、次のリクエストまで気付かない事態を避け、停止した瞬間に プッシュ通知用に運用する ntfy server から通知を受け取れます。
Ollama がモデルのロードを拒否する。 クラッシュせず、リクエストが直ちにエラーで失敗します。サーバーログには model is too large for system memory が記録されます。Ollama 0.40.7 での表示で、2026 年 10 月 21 日に確認しています。以前のリリースでは、プロンプトに Error: model requires more system memory (X GiB) than is available (Y GiB) と表示されました。これは、前述のクラッシュを回避する正常なエラー処理です。Ollama が必要メモリを計算し、OOM killer に処理させる前に停止しています。空き RAM より必要量が少ないモデルを選びます。空き RAM は free -h で確認できます。コンテキスト長を短くするか、より大きな VPS に移行してください。モデルをメモリに収めるためのフラグはありません。必要なメモリは実際に確保する必要があります。
最初のトークンだけ非常に遅く、その後は正常になる。 コールド状態のモデルでは、5 秒から 30 秒ほど何も表示されず、その後は通常どおりストリーミングされます。最初のロードでは、ディスクから RAM に重みを読み込んでいます。ストレージが遅いと、さらに時間がかかります。ロード後は OLLAMA_KEEP_ALIVE の期間、モデルがメモリに常駐するため、2 回目のプロンプトにはすぐ応答します。最初のロードが呼び出し経路上のタイムアウトを超えると、遅い応答ではなくエラーになります。どの層が context deadline exceeded を報告したかを特定することで、クライアント、プロキシ、ロード処理のどこが待機を打ち切ったかを確認できます。待ち時間が問題になる場合は、その値を大きくしてください。モデルが現在ロード済みかどうかは ollama ps で確認できます。
すべての処理が単純に遅い。 エラーはないものの、毎秒 10 トークン以下しか生成されません。これは CPU 推論が本来の速度で動作している状態です。ollama ps に 100% CPU と表示される場合、GPU はありません。これは不具合ではありません。設定だけで CPU を GPU に変えることもできません。主な制限要因はメモリ帯域幅だからです。ただし、VM では 1 つ試す価値のある設定があります。Ollama は検出した物理コア数からスレッド数を決めますが、ハイパーバイザーが誤った値を報告する場合があります。ollama run --verbose session で /set parameter num_thread 4 を試してください。必要に応じて vCPU 数を指定します。同じプロンプトを再実行し、最もよい eval rate が得られる値を使います。それ以外では、小型のモデルを使うか、速度を受け入れるか、GPU instance に移行してください。問題があると判断する前に、--verbose で実際の生成速度を測定します。速度ではなく回答の長さが待ち時間の原因なら、num_predict で回答を制限することで、冗長なモデルが読む予定のないトークンを数分かけて生成することを防げます。
別のマシンから接続すると拒否される。 ラップトップから実行すると、現在の curl (8.23.0、2026 年 10 月 21 日確認) では curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server と表示されます。Ubuntu 24.04 に付属する curl 8.5.0 では curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server と表示されます。「Connection refused」という文字列は、-v を追加した場合にだけ、connect to <ip> port 11434 from ... failed: Connection refused の行として表示されます。これは想定どおりの動作です。Ollama は localhost のみに bind します。0.0.0.0 に bind して「修正」してはいけません。これは、前述した公開設定の誤りそのものです。VPN 経由、または認証プロキシ経由でモデルにアクセスしてください。
11434 をインターネットに公開してしまった。 OLLAMA_HOST=0.0.0.0 を設定してファイアウォールを開放し、開始していないモデルの pull や、未知のクライアントによる CPU 使用率 100% を確認した場合、すでに発見され、利用されています。これは特殊な事例ではなく、最も重大な設定ミスです。127.0.0.1 または VPN アドレスに bind し直し、ファイアウォールで 11434 を閉じ、前段に認証を配置してください。公開中にそのアドレスから到達可能だったものは、第三者から問い合わせられたと考えてください。
バックアップとアップグレード
失う可能性のある状態はほとんどありません。モデルは再ダウンロードできるため、バックアップする価値があるのは、Open WebUI のデータボリューム、アカウント、チャット履歴、設定、および作成した systemd の drop-in だけです。一時的なコンテナを使ってボリュームをバックアップします。
docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
tar czf /backup/open-webui.tgz -C /data .インストールスクリプトを再実行して Ollama をアップグレードし、docker pull ghcr.io/open-webui/open-webui:main を実行してからコンテナを再作成して Open WebUI をアップグレードします。0.40 系ではディスクに関する注意が必要です。Ollama 0.40.2 は、以前のバージョンで取得したモデルをバックグラウンドでアップグレードする処理を開始しました。この処理では元のコピーがバックアップとして保持されるため、削除するまで追加のディスク容量を使用します。0.40.3 (11 October 2026) では、このバックグラウンドアップグレードが一時停止されました。アップグレード後に df -h を確認し、バックアップを削除するコマンドはリリースノートで確認してください。長期的にバージョンを固定しないでください。モデルの品質とランタイムはどちらも速いペースで変化するため、リリースノートを読み、自分のサーバーで再ベンチマークしてください。前四半期の数値をそのまま信頼してはいけません。
FAQ
CPU のみの VPS で本当に LLM を実行できますか？
はい。ただし制限があります。3B から 8B 程度の小さな量子化モデルは CPU で動作し、文章の下書き、要約、分類に実用的です。ただし速度は遅く、共有 vCPU では通常、1 秒あたり 1 桁から 10 数個のトークン程度です。13B 以上のモデルは非常に遅いか、RAM に収まりません。十分な速度や大きなモデルが必要な場合は、GPU インスタンスを使用してください。
各モデルにはどの程度の RAM が必要ですか？
多くの一般的なモデルがデフォルトで使用する 4-bit（Q4）タグについては、概算で、重みにパラメータ 1 billion あたり約 0.5 GB の RAM が必要です。これに約 1 GB のオーバーヘッドと、コンテキスト用の追加領域が加わります。そのため、3B モデルには約 4 GB、7-8B モデルには約 8 GB、14B モデルには約 16 GB の空き容量が必要です。free -h で空き容量を確認し、OS やサーバー上の他の処理に必要な領域も残してください。
Ollama API は認証されていますか？
いいえ。Ollama には組み込みの認証、API key、rate limit がありません。port 11434 に到達できるユーザーは、Ollama を完全に制御できます。OLLAMA_ORIGINS 設定は接続できるブラウザーの origin だけを制限し、接続元のユーザーは制限しません。そのため、Ollama はデフォルトで 127.0.0.1 に bind されます。また、インターネット上の 0.0.0.0 で 11434 を公開してはいけません。ローカルから接続するか、private VPN 経由で接続してください。login を追加する reverse proxy 経由で接続する方法もあります。
Web チャットインターフェースを追加するにはどうすればよいですか？
--network=host を使用して Docker で Open WebUI を実行すると、host の loopback を共有し、native Ollama の http://127.0.0.1:11434 に接続できます。その後、laptop からアクセスできるように、port 8080 の前段に TLS reverse proxy を配置します。proxy だけを公開経路にするため、firewall では 8080 を閉じてください。Open WebUI 自体の admin account が login を提供します。password は初回起動時に設定します。
自分のアプリケーションから呼び出すにはどうすればよいですか？
http://127.0.0.1:11434/v1 の OpenAI-compatible endpoint を使用してください。任意の OpenAI SDK の base URL にこの URL を指定し、API key には任意の文字列を渡します。API key は無視されます。model には、pull 済みのモデル名を指定してください。既存の OpenAI code は、通常、base URL と key を変更するだけでそのまま動作します。