本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて自分のサーバーで実際に測った値か、公式ドキュメントの記載です。

ローカルLLMの構築記事を探すと、出てくるのは自分のPC（WindowsやMac、自作機）か、自社サーバー（ハードウェアを買う話）のどちらかです。

VPSに立てる話が、ほとんど見つかりません。

私は、さくらのVPS 2Gプラン（GPUなし・CPUのみ）にOllamaを入れて動かしています。その過程で、PCに入れるのとは違う問題に2つぶつかりました。 どちらも、PCなら起きないか、起きても実害が出ないものです。

確認できたこと

  • 公式のインストールスクリプトは、1.34GBを一発勝負で落とす構造。実測で89分かけて55.6%で切れた。途中から再開できない
  • wget -c で落としてから展開すれば2分1秒で終わった
  • 公式のアップグレード手順も、同じスクリプトの再実行。つまり更新のたびに同じ賭けをする
  • Ollamaに認証はない。 公式ドキュメントには「公開のしかた」は書いてあるが、公開したあと誰が叩けるのかは書かれていない
  • systemdでメモリ枠を切ると、モデルが暴れても同居しているサービスが巻き添えにならない

PCに入れるのとVPSに入れるのは、前提が3つ違う

自分のPCVPS
GPU載っていることがある基本的にない
稼働使うときだけ24時間動き続ける
ネットワーク家庭内LANの内側グローバルIPで直結

3つ目が、この記事のいちばん重要な点です。 自分のPCで OLLAMA_HOST を広げても、届くのは家の中だけです。VPSで同じことをすると、インターネット全体から届きます。

GPUがないことの影響（どのモデルまで載るか）はGPUなしでローカルLLMは使えるのかに分けて書きました。この記事は構築の手順と、立てたあとの安全に絞ります。

公式の「3行」は、1.34GBの一発勝負

Ollamaの公式インストール手順はこれです。

curl -fsSL https://ollama.com/install.sh | sh

これを実行したら、89分かけて55.6%で切れました。

curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

やり直しです。 このスクリプトは curl | zstd -d | tar -x と直結していて、ダウンロードしながら展開しています。 そのため途中で切れても再開できません。

配布物は 1,433,825,108バイト（1.34GB）。これを一発で落とし切る必要があります。

原因は特定できていません。 失敗の直後に同じURLへ curl を投げたら 10.8 MB/s 出ました。配布元が常に遅いわけではありません。あの時間帯だけ経路が細かった可能性が高いですが、確証はありません。

ただし対処は原因に関係なく有効です。 1.34GBを一発勝負で落とす構造そのものが弱い。

そしてこれは、インストール時だけの問題ではありません。 公式ドキュメントのアップグレード手順は、同じスクリプトの再実行です。

How can I upgrade Ollama? （中略）curl -fsSL https://ollama.com/install.sh | sh

つまり更新のたびに、同じ賭けをすることになります。 自分のPCなら失敗しても「もう一度やる」で済みますが、VPSは稼働中のサーバーです。 深夜に90分かけて失敗する運用を、繰り返す理由はありません。

手順：落としてから展開する

同じ配布物がGitHubのリリースにあります。こちらを wget -c で落とします。

wget -c --tries=0 --waitretry=15 --timeout=60 \
  https://github.com/ollama/ollama/releases/download/v0.33.3/ollama-linux-amd64.tar.zst

2026-09-07 20:55:24 (11.3 MB/s) - saved [1433825108/1433825108]

2分1秒で完了しました。 89分の失敗のあと、同じ回線で、です。

wget -c を使う理由は2つあります。

  • -c は途中から再開できる。 切れても最初からになりません
  • wgetはHTTP/1.1しか使わない。 さきほどの HTTP/2 PROTOCOL_ERROR は起きません

落としたら、壊れていないか確認してから展開します。

zstd -t ollama-linux-amd64.tar.zst
sudo install -o0 -g0 -m755 -d /usr/local/bin /usr/local/lib/ollama
sudo tar --zstd -xf ollama-linux-amd64.tar.zst -C /usr/local

展開は10.9秒でした。

Ollamaに認証はない。公式も書いていない

ここがVPSでいちばん危険な場所です。

公式ドキュメントのFAQには、ネットワークに公開する方法が書かれています。

How can I expose Ollama on my network? Ollama binds 127.0.0.1 port 11434 by default. Change the bind address with the OLLAMA_HOST environment variable.

書いてあるのは、ここまでです。

私が2026年9月13日に確認した範囲では、このFAQに「公開したAPIを誰が叩けるのか」「認証をどうするのか」という記載はありません。 プロキシの節ではnginxでポート11434へ転送する例が示されていますが、そこにも認証の話は出てきません。

つまり、OLLAMA_HOST=0.0.0.0:11434 としてVPSで起動した時点で、そのAPIは世界中の誰でも叩ける状態になります。 ポートスキャンで見つかれば、他人のサーバーでモデルを回されます。CPUだけのVPSなら、それだけでサービスが止まります。

だから既定値のまま縛ります。

Environment="OLLAMA_HOST=127.0.0.1:11434"

既定値も 127.0.0.1 なので、書かなくても同じ動きです。それでも明示して書き残します。 「意図してローカルに縛った」と分かる状態にしておかないと、あとから設定を触る人（半年後の自分を含む）が、軽い気持ちで 0.0.0.0 にします。

外から使いたい場合の選択肢は、私が確認した範囲では次のとおりです。

方法認証備考
SSHポートフォワードSSHの鍵追加のソフトが要らない。いちばん簡単
nginxのリバースプロキシ＋Basic認証Basic認証公式FAQにプロキシの例はあるが、認証の例はない
VPNの内側に置くVPN構成が増える

私が使っているのはSSHポートフォワードだけです。 下2つは構成として妥当だと考えていますが、このサーバーでは試していません。 試していないものを「おすすめ」とは書きません。

systemdのunitと、メモリ枠を切る理由

配布物にサービス定義は含まれていないので、自分で書きます。

sudo useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama
sudo tee /etc/systemd/system/ollama.service > /dev/null <<'EOF'
[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Environment="OLLAMA_HOST=127.0.0.1:11434"
MemoryMax=1200M
MemorySwapMax=1024M

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now ollama

MemoryMax と MemorySwapMax が、VPSならではの部分です。

VPSには、たいてい他のものが同居しています。私のサーバーでは、静的サイトと業務アプリが動いています。枠を切らずにモデルを載せて失敗すると、巻き添えで全部が止まります。

実際、枠を超えたときに何が起きるかは測りました。1Bのモデルを載せたとき、枠に5万回以上当たり、生成速度は0.07 tokens/秒まで落ちました（実測の全記録）。このとき枠を切っていなければ、同じ状態がサーバー全体で起きていたはずです。

枠があると、壊れるのはOllamaだけで済みます。 Restart=always を書いてあるので、落ちても3秒後に戻ります。

数字は自分の環境に合わせてください。私の環境ではOSのメンテナンス用に最低300MBを空けています。目安は、空きメモリから他のサービス用の余裕を引いた残りです。

どのモデルを載せるか

構築が終わったら、載せるモデルを決めます。GPUがない環境では、上限はほぼ計算で決まります。

載せられるモデルファイル ≒ 空きメモリ ÷ 2.4

この2.4倍は実測から出した値です。そして、この計算を外れた瞬間に速度は崖から落ちます（0.5Bで15.36 tok/s、1Bで0.07 tok/s）。モデル別の早見表はGPUなしでローカルLLMは使えるのかにまとめました。

費用：VPSとクラウドAPI、どちらが安いか

正直に書きます。用途が小さいなら、APIのほうが安いです。

さくらのVPS 2Gプランは月額1,706円（2026年9月時点の公式価格・税込）。これは使っても使わなくても固定で出ていきます。 一方、クラウドのAPIは従量課金です。月に数百回しか呼ばないなら、APIのほうが安く済みます。

VPSが有利になるのは、次のどれかに当てはまるときです。

  • データを外に出せない。 費用の比較ではなく、要件として決まっている場合
  • 常時・大量に呼ぶ。 固定費を上回るだけの回数を回す場合
  • すでにVPSを借りていて、余っている。 私の場合はこれです。業務システムを載せているサーバーの空きメモリで動かしているので、Ollamaのために増やした費用はゼロです

3つ目は見落とされがちですが、実際にはいちばん現実的だと思います。 Ollama本体の常駐メモリは36MBで、使っていないときのコストはほぼゼロだからです。

プラン別の積み上げはAI用途のVPSは何GB必要かに書きました。価格・仕様は変わるので、申し込む前に公式の最新情報を確認してください。

さくらのVPS公式：https://vps.sakura.ad.jp/

（上記は広告リンクです。この記事の手順と結論は、提携の有無とは無関係です。 上に書いたとおり、用途によってはAPIのほうが安いとも書いています。）

この記事が書けなかったこと

  • nginx＋Basic認証とVPNは、このサーバーでは試していません。 構成として妥当だと考えているだけです
  • Ollamaが実際に攻撃を受けた事例は確認していません。 「認証がない」ことと「公式に記載がない」ことを確認しただけで、被害の統計は持っていません
  • バージョンは0.33.3の時点の話です。 配布方法もドキュメントも変わります
  • MemoryMax の最適値は測っていません。 1,200MBは私の環境で他のサービスを守れる値として決めたもので、最適化した結果ではありません
  • GPUありのVPSは扱っていません

出典

  • Ollama Docs FAQ（OLLAMA_HOST の既定値と変更方法、アップグレード手順、プロキシの例／2026年9月13日確認）
  • Ollama GitHub Releases（配布物の入手先）
  • 実測値は当サイトの測定による（さくらのVPS 2Gプラン / Ubuntu 24.04 LTS / GPUなし / Ollama 0.33.3）

関連記事