VPS に必要な RAM はどれくらい？用途別の実測値

多くの人は RAM を勘で選びます。「念のため」に買いすぎるか、深夜 3 時に OOM killer と出会うかのどちらかです。実はメモリは最もサイジングしやすいものの一つで、おおよその数値さえ知っていれば用途ごとの使用量は予測できます。ボット用の 1 GB マシンから、大きなモデルをローカルで動かしたい人が探す 64 GB サーバーまで、その数値を紹介します。

用途別のおおよその数値

これは典型的な構成での定常状態の実測値であり、ベンダーの最小要件ではありません。

注目すべき点が 2 つあります。第一に、「通常の」用途と LLM の差は巨大で、ボットと 70B モデルでは 200 倍も違います。第二に、ほとんどのサービスは 1〜4 GB で問題なく動きます。買いすぎるのは、めったに来ない将来に合わせてサイジングするからです。

LLM の計算式

言語モデルには簡単な見積もり方があります。パラメーター数 × 重みあたりのビット数 ÷ 8、にオーバーヘッドを加える。約 4.5 ビット（一般的な Q4 量子化）の 8B モデルなら、8 × 4.5 ÷ 8 ≈ 4.5 GB の重みです。コンテキストウィンドウ用（KV キャッシュはコンテキスト長とともに増えます）とランタイム用に 1〜2 GB を足すと、5〜6 GB になります。

正直な話をすると、CPU だけのサーバーではメモリは話の半分にすぎません。数個の vCPU で 7〜8B モデルなら毎秒数トークン、70B なら毎秒約 1 トークンと考えてください。バッチ処理、バックグラウンドのエージェント、個人的な実験には十分ですが、多数の同時ユーザー向けのチャット体験にはなりません。主にホスト型のモデル API を呼び出すなら、エージェントに必要なリソースはずっと少なくて済みます。AI エージェント向けの VPS サイジングを参照してください。

推測せずに測る

すでにサーバーがあるなら、数値はすぐ手に入ります。

free -h                              # look at "available", not "free"
ps aux --sort=-rss | head -n 8       # the biggest processes, by resident memory
docker stats --no-stream             # per-container usage

Linux は使われていない RAM をディスクキャッシュに使うため、「free」はいつも小さく、それが健全な状態です。大事なのは available、つまりカーネルが今すぐプログラムに渡せるメモリです。最も忙しい時間帯に available が約 25% 以上を保っていれば、サイズは適切です。頻繁にゼロになりスワップが増えていくなら、プランを上げてください。

過去に OOM による強制終了があったかも確認しましょう。

journalctl -k | grep -i "out of memory"

スワップはシートベルトであってエンジンではない

小さなサーバーに 1〜2 GB のスワップファイルを置くのは安価な保険です。一時的に多くのメモリを必要とするパッケージ更新や Docker ビルドが、強制終了されずに済みます。しかしサービスがスワップ上で動き続けると、すべてのリクエストがディスクを待つことになります。スワップはピーク用です。常にスワップしているなら、次のプランが必要です。

結局どれくらい買えばいいのか

• 1 GB：ボット 1 つ、小さな API 1 つ、静的サイト。
• 2 GB：データベースや Docker を使うものなら妥当な標準。
• 4〜6 GB：1 台で複数のサービス、サーバー上でのビルド、小さなローカルモデル。
• 32〜64 GB：大きなものをメモリに常駐させる必要があるときだけ。14B を超えるローカルモデル、大きな RAG インデックス、エージェント群などです。そのために大容量メモリのプランがあります。

直感より 1 サイズ小さいものから始め、1 週間 free -h を観察し、数値が示すならアップグレードしてください。EQVPS ではプランをアップグレードしてもデータはそのままで、日割りの差額だけが請求されます（プラン変更の仕組み）。