メモリ

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に任せている 覚えるのはこれで足りました。 以下は、この表に書ききれない裏側です。 ...

「GPUがないパソコンやサーバーでローカルLLMは動くのか」。動きます。ただし、載せられるモデルの大きさは、ほぼ計算で決まります。 載せられるモデルファイル ≒ 空きメモリ ÷ 2.4 この2.4という倍率は、GPUなしのVPSで実際に測って出した値です。そしてこの計算を外れた瞬間、速度は段階的にではなく崖のように落ちます。 確認できたこと 必要メモリの目安はモデルファイルの約2.4倍。0.5Bのモデル（380MB）で実測930MBだった 0.5Bは15.36 tokens/秒で動き、1Bでは0.07 tokens/秒に落ちた。219分の1。段階的ではなく崖 Ollamaの公式ドキュメントには、必要メモリの記載がない。2026年9月13日に確認した 重いのはツールではなくモデル。Ollama本体の常駐メモリは36MBで、Dockerの49MBより軽い 先に埋まるのはメモリではなくディスクのことがある。Ollama本体だけで2.1GB 商用利用の可否はモデルごとに違う。同じQwen2.5でもサイズによってライセンスが分かれている この記事の数字には実測値と計算値が混ざっています。 どちらなのかは、その都度書きます。 載るモデルは「空きメモリ ÷ 2.4」で決まる 出発点は、GPUのないVPSで測った1本の実測値です。 モデルファイル 380MB → 実際のメモリピーク 930MB（2.4倍） さくらのVPS 2Gプラン、Ubuntu 24.04、GPUなし・CPUのみ。qwen2.5:0.5b を載せたときの値です。測定の詳細は2GBのVPSでローカルLLMは動くのかに書きました。 この倍率で逆算すると、載せられるモデルの上限が出ます。 載せられるモデルファイル ≒ 空きメモリ ÷ 2.4 同じ実測から、1Bのモデルが動かない理由も説明がつきます。 1Bのファイルは1,260MB。2.4倍すると約3,000MBが必要になります。そのときの枠は1,200MBでした。入るはずがありません。そして実際に入りませんでした。 倍率が1本のモデルからしか出ていない点は、そのまま弱点です。 0.5B以外では検証していません。 なお、この2.4倍はcgroupの memory.current から取った値で、モデルファイルのページキャッシュを含みます。 「アプリが確保した量」より大きめに出る数字です。余裕を見る方向に効くので、目安としては安全側ですが、そういう数字だという前提で読んでください。 公式のファイルサイズから逆算した早見表 ここから先は計算値です。 各モデルのファイルサイズは2026年9月13日にOllama公式ライブラリで確認した値、必要メモリはそれを2.4倍したものです。 モデル 公式のファイルサイズ 必要メモリの目安（×2.4） gemma3:270m 292MB 約700MB qwen2.5:0.5b 398MB 約960MB（実測930MB） gemma3:1b 815MB 約1,960MB qwen2.5:1.5b 986MB 約2,370MB llama3.2:1b 1.3GB 約3,120MB qwen2.5:3b 1.9GB 約4,560MB llama3.2:3b 2.0GB 約4,800MB gemma3:4b 3.3GB 約7,920MB 実測と一致しているのは2行目だけです。 他は倍率からの計算で、私は確かめていません。 ...

「2GBのVPSでローカルLLMは動くのか」。動きます。ただし0.5Bまでです。 0.5Bから1Bに上げた瞬間、生成速度が 15.36 tokens/秒 → 0.07 tokens/秒 に落ちました。219分の1です。段階的に遅くなるのではなく、崖から落ちます。 3Bはサービスごと落ちました。 結論 モデル ファイル ディスク増 メモリピーク 生成速度 結果 qwen2.5:0.5b 397MB +380MB 930MB 15.36 tok/s 動く llama3.2:1b 1.3GB +1,260MB 1,201MB（上限） 0.07 tok/s 実用不可 qwen2.5:3b 1.9GB +1,840MB — — 落ちた 必要メモリの目安は「モデルファイルの約2.4倍」。 0.5B（380MB）で930MBでした。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS（GPUなし・CPUのみ） Ollama：0.33.3 枠：systemdの MemoryMax=1200M / MemorySwapMax=1024M でOllamaを隔離 同居：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本が動いている実運用サーバー プロンプト：「日本の首都はどこですか。一文で答えてください。」 同居しているものがあるので、free の全体値は他の処理の影響を受けます。そのため、Ollama単体の数字はすべてcgroup（memory.current）から取っています。 Ollama本体だけで、ディスク2.1GB・メモリ36MB モデルを1つも入れていない状態です。 値 ディスク +2,160MB 常駐メモリ（cgroup） 36MB 待ち受け 127.0.0.1:11434 メモリは驚くほど軽い。 比較すると位置づけが分かります。 常駐メモリ Ollama本体 36MB Docker（dockerd + containerd） 約49MB n8n 402MB Dify（16コンテナ） 2,076MB 「AIツールは重い」わけではありません。重いのはモデルです。 ...

本記事はプロモーションを含みます。 記事内の一部のリンクは広告リンクです。リンクの有無で内容を変えていません。 掲載している数値はすべて自分のサーバーで実際に測った値か、公式ドキュメントの記載です。 「AI用途のVPSは4GB以上がおすすめです」。よく見る書き方です。 その4GBの内訳がどこにも書いてありません。 OSがいくら使うのか、ツールがいくら足されるのか、どこに余裕を見ているのか。根拠が出てこないので、自分の用途に当てはめようがない。 このサイトでは、ここまで4本の記事で全部自分で測ってきました。 その数字を積み上げて、必要なスペックを出します。 先に結論 やりたいこと メモリ ディスク 根拠 静的サイト＋小さな業務アプリ 1〜2GB 20GB〜 実測（アプリ3本で166MB） ＋ n8n で自動化 2GB 50GB〜 実測（+402MB、空き1.1GB残） ＋ Dify（起動して置くだけ） 4GB 100GB〜 実測（Dify単体で2,076MB） Dify を実際に使う 8GB 100GB〜 推定・未検証 ＋ ローカルLLM（0.5Bクラス） 2GB 20GB〜 実測（本体2.1GB＋モデル） ローカルLLM（1B以上） 4GB〜 50GB〜 推定・未検証 「実測」と書いた行は測った数字です。「未検証」の行は測っていません。どこまでが実測でどこからが推測か、はっきり分けて書きます。 土台：OSと常駐デーモンで何MB持っていかれるか まずアプリを何も載せない状態のコストです。ここを知らないと積み上げができません。 このサーバー（さくらのVPS 2Gプラン / Ubuntu 24.04）で、再起動直後・Dockerとnginxと自作アプリ1本が動いている状態が 398MB でした。 内訳のうち、多くの人が見落とすものが2つあります。 1. VPSでは働きようがないデーモンが50〜100MB 最初の記事で測った内訳です。 プロセス RSS 本来の用途 fwupd 44.0MB 物理デバイスのファームウェア更新 multipathd 26.7MB ストレージへの複数I/Oパスの管理 udisksd 13.4MB ディスク・リムーバブルメディアの管理 ModemManager 12.8MB モバイル通信モデムの管理 VPSに物理ファームウェアはありません。モバイル通信のモデムも刺さっていません。常駐3つで約53MB、fwupd が起動していると約97MB。 ...

前回、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に落ち着きます。 ...

前回の記事で、VPSのメモリを1回だけ測りました。ただしあれはアイドルに近い状態の1サンプルです。ピークは写っていません。 そこで、1分ごとに記録するスクリプトを仕掛けて放置しました。43時間、2,590サンプル、欠測ゼロ。 結果、予想は外れました。メモリのピークを作っていたのは、自分のアプリではありませんでした。 上がメモリ、下がCPUです。山が重なっていません。 これが今回いちばん面白かったところです。 測定条件 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 期間：2026-09-04 01:10 〜 09-05 20:19（43.1時間） 間隔：1分（cron） サンプル数：2,590（120秒を超える欠測ゼロ） 載せているもの：定期的にデータを取得して予測を回すバッチ処理と、静的サイト1本 使ったスクリプト 追加パッケージは不要です。free / vmstat / ps / awk だけで動きます。 #!/usr/bin/env bash set -u OUT="${1:-$HOME/vps-metrics.csv}" if [ ! -f "$OUT" ]; then echo "timestamp,mem_total_mb,mem_used_mb,mem_available_mb,swap_used_mb,load1,load5,cpu_idle_pct,p1_name,p1_rss_mb,p2_name,p2_rss_mb,p3_name,p3_rss_mb" > "$OUT" fi ts=$(date '+%Y-%m-%d %H:%M:%S') mem=$(free -m | awk '/^Mem:/{print $2","$3","$7}') swp=$(free -m | awk '/^Swap:/{print $3}') ld=$(awk '{print $1","$2}' /proc/loadavg) idle=$(vmstat 1 2 | awk 'NR==2{for(i=1;i<=NF;i++) if($i=="id") c=i} END{print (c?$c:"")}') top=$(ps -eo comm=,rss= --sort=-rss | head -3 | tr -d ',' \ | awk '{printf "%s,%.1f,", $1, $2/1024}' | sed 's/,$//') echo "$ts,$mem,$swp,$ld,$idle,$top" >> "$OUT" cronに1行足すだけです。 ...

さくらのVPS 2Gプランで、自作の業務システムを3本動かしています。9日間連続稼働、ロードアベレージ0.20、メモリは7割が空いたままです。 測ってみて、想定外だったことがあります。アプリ3本が使っているのは約166MB。一方で、このサーバーでは働きようがないOSのデーモンが、合計50〜100MBを占めていました。 自分のアプリより、使う予定のない仕組みのほうが目立つ。プラン変更を考える前に、見るべき場所がありました。 測定条件 数字を出す記事なので、どういう状態で測ったかを先に書きます。 サーバー：さくらのVPS 2Gプラン / Ubuntu 24.04 LTS 測定時刻：平日15:57、業務時間内だがアクセスはほぼない状態 稼働日数：9日15時間（無停止） サンプル数：1回（vmstat のみ5秒間） したがって以下の数字はアイドルに近い状態のものです。ピーク時の値ではありません。負荷時の測定は別途行い、追記します。 動かしている3本 すべて自作の業務システムです。フロントには Caddy を置いています。 システム 構成 常駐メモリ(RSS) 反応計測システム FastAPI 0.141.1 / uvicorn 0.52.4 / SQLite 約66MB 基幹システム Python + gunicorn（-w 1 --threads 8 -t 120） 約65MB 仮想待合室 Go（静的リンクの単一バイナリ）/ 設定はJSON 約35MB 3本合計 約166MB Caddy リバースプロキシ / HTTPS 約23MB 3本とも 127.0.0.1 のポートで待ち受けていて、外部に直接は晒していません。Caddyが受けて振り分けています。 基幹システムは自社の業務用なので、フレームワークやデータ構造の詳細は伏せます。この記事で必要なのはメモリの数字だけなので、そこは支障ありません。 3本で166MBに収まっている理由 DBサーバーを1台も動かしていないからです。 systemctl list-units --type=service --state=running \ | grep -iE "postgres|mysql|maria|redis|mongo" # → 何も返らない PostgreSQLもMySQLもRedisも入っていません。反応計測システムはSQLiteのファイル1つ（data/dareyomi.db）で動いています。 ...