実測

「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ツールは重い」わけではありません。重いのはモデルです。 ...

前回の記事で、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）で動いています。 ...