構築

Ollamaのコマンドは、覚えることがほとんどありません。pull して run するだけです。 詰まるのはコマンドではなく、その裏側です。 pullが何分かかるのか。1回目の応答だけ異常に遅いのはなぜか。使い終わったメモリはいつ返ってくるのか。このあたりは、動かしてみるまで分かりません。 さくらのVPS 2Gプラン（Ubuntu 24.04・GPUなし・CPUのみ）で測った数字と、公式ドキュメントの記載を突き合わせました。 確認できたこと pull は 0.5Bで38.6秒、1Bで2分4秒、3Bで2分56秒。ディスクはそれぞれ +380MB / +1,260MB / +1,840MB 増えた 1回目の応答が遅いのはモデルのロード時間。0.5Bで3.18秒、1Bでは43.6秒かかった モデルは既定で5分間メモリに保持され、そのあとアンロードされる（公式ドキュメントの記載） つまり5分以上間を空けると、あのロード時間がもう一度発生する ollama ps の Processor 列を見れば、CPUで動いているかGPUで動いているかが分かる（公式の記載。100% CPU のように出る） Ollama本体は常駐36MB。ディスクは2.1GB。モデルを3つ入れた時点で合計3.4GBだった 実測値は「実測」、公式ドキュメントの記載は「公式」と書き分けます。 基本のコマンドと、実際にかかった時間 コマンド 何をするか このサーバーでの実測 ollama pull <model> モデルを取得する 0.5B: 38.6秒 / 1B: 2分4秒 / 3B: 2分56秒 ollama run <model> "..." 1回だけ実行する 初回はロード時間が乗る（後述） ollama list 入っているモデルを見る 即時 ollama ps いま動いているモデルを見る 即時。Processor列が重要 ollama rm <model> モデルを消す 未測定 ollama serve サーバーとして起動する systemdに任せている 覚えるのはこれで足りました。 以下は、この表に書ききれない裏側です。 ...

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて自分のサーバーで実際に測った値か、公式ドキュメントの記載です。 ローカル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つ違う 自分のPC VPS 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 と直結していて、ダウンロードしながら展開しています。 そのため途中で切れても再開できません。 ...

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて公式ドキュメントの記載か、自分のサーバーで実際に測った値です。 Claude Codeを自分のVPSで動かしたい。まず決まるのは「どのプランを買うか」です。 各社のページを調べたら、全社が「4GB以上」と書いていました。 一方、Anthropicの公式要件も4GB以上です。 では2GBでは動かないのか。2GBのVPSに手で入れて、動かしました。最大268MBでした。 結論 結果 各社の要件 4GB以上（2GB以下は非対応と明記する社もある） 2GBでの実測 最大268MB / ファイル作成もコード実行も成功 Node.js 不要（ネイティブインストーラ） ディスク +206MB インストール時間 6分46秒 アカウント 有料プラン必須（無料のClaude.aiでは使えない） ただし、「4GBは要らない」とは書きません。 理由は最後に書きます。 対応している4社と、その必要メモリ Claude Codeのテンプレート／アプリイメージを公式に出しているのは、確認できた範囲でこの4社です。 提供元 形式 公表している必要メモリ XServer VPS アプリイメージ 4GB以上。2GB以下のプランでは利用不可 シンVPS アプリイメージ 4GB以上。2GB以下のプランでは利用不可 ConoHa VPS スタートアップスクリプト 最小3GB、推奨4GB以上 KAGOYA CLOUD VPS テンプレート 記載を確認できず （表のXServer VPSとConoHa VPSは広告リンクです。他社は提携していないため通常のリンクです。リンクの有無と、この表に書いた内容は無関係です。） XServer VPSとシンVPSは、2GB以下のプランでは選択肢に出てきません。 「安いプランを買ってから気づく」ことになります。 Anthropicの公式ドキュメントも同じです。 Hardware: 4 GB+ RAM, x64 or ARM64 processor 4社と公式で、数字が一致しています。 ConoHaのスクリプトが入れるもの ConoHaのドキュメントには、中身まで書いてあります。 ソフト バージョン Claude Code 最新 Node.js 22 ripgrep 13.0.0 UFW 最新 Fail2ban 最新 対応OSは Ubuntu 24.04 LTS のみ。 ...

前回、n8nは2GBのVPSに 402MB で載りました（実測記事）。そのとき「次はDifyを入れてみます」と書きました。 Difyの公式要件は 2CPU / 4GB。今回の環境は2GB、しかも本番の処理と公開中のサイトが同居しています。要件を満たしていません。 それを承知で載せて、10秒ごとに測りました。 結論から書きます。載ります。ただし2,076MB要求してきます。 上のオレンジ色が、物理メモリに収まらずスワップへ追い出された分です。881MB。 そして下のグラフ、起動から4分間はI/O待ちが最大91%。この間、SSHの接続が切れました。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 同居しているもの：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本 Dify：1.17.0（公式リポジトリの docker/ をそのまま使用、ベクトルDBは既定のweaviate） 記録：10秒間隔・自作スクリプト。free / vmstat / ps と cgroup の memory.current を読むだけ 時間：10分間（起動から自動停止まで） 前回までに43時間のベースラインと、n8nを載せた前後の数字が取ってあります。「載せる前」が分かっているので、増えた分がそのままDifyのコストになります。 先に：ディスクが10.6GB増える メモリの話の前に、こちらのほうが先に効きます。 イメージ取得前 12,971MB イメージ取得後 23,572MB 差分 +10,601MB イメージだけで10.6GB。 n8nは2.47GBだったので、4.3倍です。 内訳の上位はこうなっています。 イメージ サイズ dify-api 4.06GB dify-plugin-daemon 2.28GB dify-agent-backend 1.45GB dify-web 892MB dify-sandbox 848MB dify-agent-local-sandbox 779MB postgres / squid / nginx / weaviate / redis ほか 計 1.25GB dify-api の1本だけで4GB。n8nのイメージ全体（2.47GB）より大きい。 ...

「2GBのVPSでn8nは動くのか」を調べると、たいてい「動く」か「厳しい」のどちらかしか書いてありません。具体的に何MB増えるのかは、ほとんど出てきません。 実際に載せて、1分刻みで測りました。 合計402MB。 そして載せ終わってもまだ1.1GB空いています。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 元から動いていたもの：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本 記録：1分ごとにcronで自動記録（スクリプトは前の記事に載せています） 時間：2026-09-07 01:12 〜 01:37 前の記事で43時間分のベースラインを取ってあります。「載せる前」が分かっているので、増えた分がそのままn8nのコストになります。 結果：4段階に分けて測る 多くの記事は「n8nは○MB」で終わります。しかし実際に増えるものは1つではありません。 段階 システム全体のメモリ 増分 元の状態 438MB — ＋Dockerデーモン 476MB +38MB ＋n8nコンテナ起動 804MB +328MB ＋UIを開いてワークフローを1本 840MB +36MB 合計 +402MB ディスクは 10GB → 13GB（+3GB）。スワップは 0 → 37MB 使われました。 発見1：Dockerデーモンだけなら38MB 「Dockerは重い」とよく言われます。実際に測ると、デーモン単体では38MBでした。 導入直後の記録がこれです。 01:14 431MB python 90.8, systemd-journal 72.7, multipathd 26.7 ← 導入前 01:15 523MB apt-get 98.3, python 90.8, dockerd 87.6 ← インストール中 01:16 483MB python 90.8, dockerd 88.3, systemd-journal 72.9 ← 完了 01:19 478MB python 90.8, dockerd 87.0, systemd-journal 73.0 ← 安定 インストール中は apt-get で523MBまで上がりますが、終われば478〜485MBに落ち着きます。 ...