著者 自宅サーバーで動かせるAIモデルの選び方
手元のRAM容量からモデルを選べます。4 GB、16 GB、64 GBのVPS別に必要メモリを計算し、CPUの実測トークン速度とコンテキストの隠れたコストも解説します。
セルフホストできる AI モデルを決める要素
セルフホストできる AI モデルは、1 つの数値で決まります。サーバーの RAM 容量です。モデルファミリーやフレームワークよりも、重みを余裕を残してメモリに収められるかどうかが重要です。この記事では、その判断に使う計算方法を説明します。ランタイムのインストールは別の作業です。VPS で Ollama を実行するガイドで説明しています。
結果を決めるコストは 2 つあります。重みはパラメーター数と量子化方式で決まる固定コストです。コンテキストウィンドウは実行時コストです。昨日はロードできたモデルが、今日はロードできなくなるまで、このコストは見落とされがちです。
サイズ計算: パラメータあたりのビット数
モデルファイルのほぼ全体を重みが占めます。各重みは、一定のビット数で保存されます。量子化とは、学習時の精度より少ないビット数で重みを保存することです。精度は少し低下しますが、メモリを大幅に節約できます。サイズは次の式で直接求められます。
weights in GB = (parameters in billions x bits per weight) / 8モデルは 16 ビットでリリースされます。これは 10 億パラメータあたり 2 GB に相当します。そのため、VPS でリリース時の精度のまま実行するケースはほとんどありません。実際に使用する量子化形式と、重みあたりの実際の平均ビット数は次のとおりです。
Q8_0は重みあたり約 8.5 ビットを使用するため、10 億パラメータあたり約 1.1 GB です。Q6_Kは約 6.6 ビットを使用するため、10 億パラメータあたり約 0.83 GB です。Q5_K_Mは約 5.7 ビットを使用するため、10 億パラメータあたり約 0.71 GB です。Q4_K_Mは約 4.8 ビットを使用するため、10 億パラメータあたり約 0.6 GB です。
実用上の計算には、10 億パラメータあたり 0.6 GB を使用してください。メモリに制約のあるサーバーでは、Q4_K_M が妥当なデフォルトです。多くのタスクでは 8 ビットに対する品質低下が小さく、ファイルサイズはほぼ半分になります。4 ビット未満では品質低下が急速に大きくなります。そのため、同じ世代の 4 ビットの 32B よりも、2 ビットに圧縮した 70B のほうが通常は回答品質で劣ります。メモリが不足する場合は、4 ビット未満に下げる前にサイズクラスを下げてください。
The data behind this chart
[
{
"label": "3B",
"weights_gb": 1.8,
"kv_8k_gb": 0.9,
"kv_128k_gb": 14
},
{
"label": "8B",
"weights_gb": 4.8,
"kv_8k_gb": 1,
"kv_128k_gb": 16
},
{
"label": "14B",
"weights_gb": 8.4,
"kv_8k_gb": 1.5,
"kv_128k_gb": 24
},
{
"label": "32B",
"weights_gb": 19.2,
"kv_8k_gb": 2,
"kv_128k_gb": 32
},
{
"label": "70B",
"weights_gb": 42,
"kv_8k_gb": 2.5,
"kv_128k_gb": 40
}
]上記の重みの列には、10 億パラメータあたり 0.6 GB というルールを適用しています。実際の GGUF ファイルは、埋め込み層と出力層が他の層より高い精度で保持されるため、この値から数パーセント以内に収まります。4 ビットの 3B モデルは約 1.8 GB です。8B は 4.8 GB です。32B は 19.2 GB、70B は 42 GB です。
コンテキスト長が重みより多くの RAM を消費する理由
KV キャッシュ（key value cache。会話中の各トークンについてモデルが保持する attention の状態）が、2 つ目のコストです。モデルの読み込み時に確保され、指定したコンテキスト長に合わせてサイズが決まり、その長さに比例して増加します。
KV キャッシュの計算式と数値の確認場所
bytes per token = 2 x layers x kv_heads x head_dim x bytes per element2 は key と value を数えています。layers、kv_heads（num_key_value_heads として一覧表示）、head_dim の値はすべて、モデルのカードページにある config.json に記載されています。16 bit キャッシュでは、要素あたりのバイト数は 2 です。一般的な 8B モデルは 32 層、8 個の key value head、128 の head dimension を持つため、2 x 32 x 8 x 128 x 2 = 131072 bytes となり、1 トークンあたり 128 KiB です。
Ollama のデフォルトのコンテキスト長では、この 8B モデルはキャッシュに 0.5 GB を使用します。8192 トークンでは 1 GB を使用します。モデルカードに記載された 128k コンテキストでは 16 GB を使用し、これは重みの 3 倍を超えます。70B は逆です。128k でのキャッシュは 40 GB で、重み自体より少なくなります。これは grouped query attention により、パラメータ数ほど速くトークンごとのコストが増加しないためです。
Ollama のデフォルトのコンテキスト長は、CPU のみのサーバーでは 4096 トークンです。GPU がある場合は VRAM からデフォルト値を選びます。24 GiB 以上 48 GiB 未満では 32k、48 GiB 以上では 256k です。サーバー上の OLLAMA_CONTEXT_LENGTH 変数で値を増やし、実行中のモデルに実際に割り当てられた値を ollama ps の CONTEXT 列で確認します。この設定に関するメモリ計算は、num_ctx とコンテキスト長に関する記事で詳しく説明しています。
キャッシュを減らす方法は 2 つあります。モデルカードに記載されたコンテキストではなく、必要なコンテキストを指定します。通常のチャットやコーディング作業の多くは 8k から 32k に収まります。もう 1 つは、キャッシュ自体を 8 bit に量子化する方法です。長いコンテキストでの想起性能が低下する可能性はありますが、サイズを半分にできます。
常駐モデルは、アンロードされるまで RAM を保持します
Ollama は最後のリクエストから 5 分間モデルをメモリに保持し、その後アンロードします。この既定値はノート PC には適していますが、サーバーには適しません。アイドル時間のたびに、最初のリクエストで再度ロード時間が発生するためです。
ollama ps
ollama stop qwen3:4bollama ps は常駐しているモデルを一覧表示します。SIZE 列には保持しているメモリ容量が表示され、UNTIL 列には有効期限が表示されます。モデルを常駐させるには、サービスで OLLAMA_KEEP_ALIVE=-1 を設定します。0 を指定すると、各レスポンスの完了直後にアンロードされます。
sudo systemctl edit ollama.service[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"sudo systemctl daemon-reload
sudo systemctl restart ollamaプロンプトを 1 回送信し、その 10 分後に再度 ollama ps を実行します。モデルは引き続き一覧に表示されます。これがまさに目的です。誰も使用していなくても、その RAM を保持しているためです。常駐モデルは空き容量ではありません。16 GB の VPS では、8k コンテキストの 8B モデルがサービスの稼働中ずっと約 6 GB を保持します。そのため、サーバーはモデルだけでなく、モデルとアプリケーションを合わせた容量を基準に設計してください。メモリへのモデル常駐では、コールドスタートの遅延とのトレードオフを説明しています。
4 GB VPS で動かせるもの
オペレーティングシステムとモデルサーバー用に約 1 GB を確保すると、残りは約 3 GB です。これは、デフォルトの 4096 トークンコンテキストで 4 ビット量子化した 1B〜4B モデルに相当します。2026 年 8 月時点では、この範囲に 3B の Llama 3.2、1.7B と 4B の Qwen 3、小型の Gemma および Phi リリースが含まれます。これらはサイズの例であり、推奨ではありません。モデル名は数か月ごとに入れ替わりますが、必要メモリの計算は変わりません。
生成速度は、1 秒あたりおよそ 6〜14 トークンを見込んでください。この程度の小型モデルは、分類、タグ抽出、短い要約、段落の社内スタイルへの書き換えなど、範囲の狭い処理に適しています。一方、複数段階の推論や複数ファイルにまたがるコード作成は苦手で、プロンプトを工夫しても改善できません。
このクラスで問題になりやすいのは swap です。モデルがメモリに収まらなくても、Linux は読み込みを拒否しません。代わりにメモリの内容をディスクへページアウトします。1 トークンを生成するたびにすべての重みを 1 回読み取るため、生成速度は 1 トークンあたり数秒まで低下します。モデルが応答している間、free -h と si および so の各列を vmstat 1 で監視してください。生成中に swap in と swap out が 0 以外になる場合、そのモデルはこの構成には大きすぎます。
8～16 GB の VPS で動かせるもの
ここから、セルフホストモデルが実用的に役立つようになります。8 GB では、4 ビットの 7B または 8B を、重みが約 4.8 GB、コンテキスト長 8k で実行できます。16 GB では、4 ビットの 13B または 14B を、約 8.4 GB で実行できます。パラメーター数より精度を優先してメモリを使う場合は、8B を 8 ビットで維持することもできます。
問題は速度です。8B を CPU で実行すると、1 秒あたり約 3～7 トークンを生成します。14B では約 1.5～3.5 トークンです。人が読む速度は、毎秒 5～10 トークン程度です。そのため、CPU VPS 上の 8B は、遅いタイピストを見ているような体感になります。バックグラウンドジョブには十分ですが、対話的なチャットでは負担になります。VPS 上で実測した 8B 以上の Qwen 3 の実行結果を見ると、実際の動作を確認できます。
32 GB から 64 GB の VPS で動作するもの
4ビット量子化した 32B は約 19.2 GB なので、コンテキストを短くすれば 32 GB プランに収まり、48 GB または 64 GB なら余裕があります。4ビット量子化した 70B は約 42 GB なので、キャッシュを追加する前から 64 GB が必要です。
次に、速度を正しく見積もります。CPU 上で 32B を実行すると、速度は毎秒 0.6〜1.5 トークン程度です。70B では毎秒 0.2〜0.5 トークン程度です。その 70B で 500 トークンの回答を生成すると、約 20 分かかります。この速度では、モデルが処理を完了する前にリクエストが通常失敗します。Ollama の前段にあるクライアントまたはプロキシのタイムアウトが先に発生するためです。これが コンテキスト期限超過エラー の原因です。これらはバッチ処理向けのツールです。文書をキューに入れて一晩処理するなら、速度は問題になりません。チャット画面の背後で実行する場合は、速度が大きな問題になります。
Mixture of experts のルーティングによって、この計算は変わります。これは、理解しておく価値がある唯一のアーキテクチャ上の詳細です。MoE モデルは、各トークンを重みの一部だけに通します。総パラメータ数が 30B で、トークンごとのアクティブパラメータ数が 3B のモデルは、30B 相当のメモリを必要とします。一方、各トークンがアクティブなエキスパートだけを読み込むため、生成速度は密な 3B モデルに近くなります。この構成の MoE は、32 GB のマシンでは密な 30B よりもはるかに実用的です。覚えておくべき原則は、総パラメータ数がメモリ使用量を決め、アクティブパラメータ数が速度を決めるということです。
CPU 推論の速度は、実際にはどの程度ですか？
1 トークンを生成するには、アクティブなすべての重みをメモリから 1 回読み出す必要があります。これを回避する方法はないため、CPU での生成速度はコア数ではなくメモリ帯域幅で決まります。上限は、使用可能なメモリ帯域幅を重みのサイズ（バイト単位）で割った値です。小規模な共有 VPS では、vCPU 全体で現実的に 10〜25 GB/秒程度になるため、4.8 GB のモデルでは最大でも約 2〜5 トークン/秒です。
The data behind this chart
[
{
"label": "3B",
"tokens_per_second_low": 6,
"tokens_per_second_high": 14
},
{
"label": "8B",
"tokens_per_second_low": 3,
"tokens_per_second_high": 7
},
{
"label": "14B",
"tokens_per_second_low": 1.5,
"tokens_per_second_high": 3.5
},
{
"label": "32B",
"tokens_per_second_low": 0.6,
"tokens_per_second_high": 1.5
},
{
"label": "70B",
"tokens_per_second_low": 0.2,
"tokens_per_second_high": 0.5
}
]これらは一般的な VPS ハードウェアでよく報告される範囲であり、特定の 1 台で測定したベンチマークではありません。実際の値は、メモリの世代、ホストのメモリチャネル数、同じリソースを使用する近隣テナントの数によって変わります。すでに取得している任意のモデルタグを使って、自分の環境で測定してください。
ollama run qwen3:4b --verbose "Write three sentences about disk latency."回答の終了後に表示されるサマリーには、eval rate: ... tokens/s という行があります。これが生成速度です。同じサマリーにある load duration にはディスクから重みを読み込む時間が含まれるため、セッションの最初の実行は無視してください。トークン毎秒を正しく測定するでは、比較に使える値を得る方法を説明しています。
ここでは、2 つの結果に驚く人が多くいます。vCPU を追加してもすぐに効果がなくなります。およそ 8 コアを超えると、追加したコアは演算ではなくメモリ待ちになるためです。また、共有プランでは、同じコマンドでも時間帯によって異なる値が返ります。これは設定ミスではなく、負荷の高い近隣テナントによる CPU steal time が原因です。
プロンプトの読み込みは、回答の生成とは異なる処理です。プロンプト処理は計算負荷が中心であるため、コア数に応じてスケールします。この処理では GPU が最も大きく差を広げます。長い文書の場合、CPU では読み込みに数分かかりますが、GPU では数秒で済みます。これは、自分でホストしているモデルに coding agent を接続するときに最初に直面する大きな制約です。各ターンで、回答の 1 トークン目が返る前に、ファイルのコンテキストとツール定義が毎回再送信されるためです。
GPU を追加すると何が変わるか
計算方法は変わりません。適用する容量の範囲が変わるだけです。VRAM は厳格な上限なので、レンタルする前に収まるか確認してください。
- 8 GB の VRAM なら、短いコンテキストで 4 bit の 7B または 8B を実行できます。
- 16 GB なら、十分なコンテキストで 4 bit の 14B、または 8 bit の 8B を実行できます。
- 24 GB なら、コンテキストを短く保つことで 4 bit の 32B を実行できます。
- 48 GB 以上なら、キャッシュと同時実行の余裕を確保しながら 4 bit の 70B を実行できます。
モデルが収まらない場合、Ollama はモデルを分割します。一部のレイヤーを GPU に、残りを CPU に配置します。ollama ps の PROCESSOR 列には、分割結果が 78%/22% CPU/GPU のような形式で表示されます。これは機能ではなく、警告として扱ってください。すべてのトークンが CPU 側のレイヤーの処理を待つため、CPU 側のレイヤーが処理速度を決めます。そのため、レイヤーの 4 分の 1 が CPU に配置されたモデルは、GPU の速度よりも CPU の速度に近くなります。意図しない分割が発生した場合は、まずコンテキスト長を短くしてください。通常はキャッシュによって容量の上限を超えています。
容量を増やすもう 1 つの理由は、同時実行です。同時に処理するリクエスト間で重みは共有されますが、アクティブな各リクエストには固有の KV キャッシュが必要です。そのため、8k のコンテキストで 8B を 10 ユーザーが同時に使用すると、重みに加えて 1 GB のキャッシュが 10 倍必要になります。1 つの self-hosted モデルで同時接続ユーザーに応答する場合も、この上限を基準に判断します。
GPU をレンタルする価値があるかどうかも、計算で判断できます。実際に 1 か月で生成するトークン数が基準になります。GPU VPS と API トークンの損益分岐点に、その数値を示しています。
自分でホストできないもの
ここには2つの異なる壁があります。どちらに直面しているのかを把握すると、判断しやすくなります。
1つ目は、重みが非公開であることです。最先端の商用モデルは配布されていないため、ダウンロードできるファイルはありません。RAM を増やしても状況は変わりません。インターフェース、検索レイヤー、エージェントループ、ログなど、モデルの周辺はすべて自分でホストできます。ただし、モデル自体はリモート API のままです。Claude を自分でホストできるかでは、この点を詳しく説明しています。
2つ目は、オープンウェイトでも単純に大きすぎる場合です。最大規模のオープンリリースは、総パラメータ数が数千億に達する mixture of experts 方式です。これらにも同じルールが当てはまります。たとえば、総パラメータ数が 400B のモデルを 4 bits で動かす場合、キャッシュを含める前でも重みだけで約 240 GB が必要です。これは専門的なハードウェアが必要な規模であり、月単位で借りる費用は、ほとんどの人が1年間に API トークンへ使う金額を大きく上回ります。Kimi クラスのモデルを自分でホストするために必要なものでは、実際に必要な要件を説明しています。同じ違いは Ollama のライブラリ内にも見られます。GLM 5.2 は cloud model としてのみ掲載されている一方で、実際に VPS へダウンロードできるのは、より小さな派生モデルです。
両者を分ける正直な基準は次のとおりです。負荷が安定していて、データをサーバーの外へ出したくない場合は自分でホストします。負荷が突発的に変動する場合や、最先端モデルの回答品質こそ必要な場合は、トークンを購入します。
選ぶ前に、利用可能な容量を確認する
free -h
nproc
lscpu | grep 'Model name'free -h の available 列ではなく、total 列を基準に計画してください。total には、システムがすでに使用しているメモリが含まれるためです。オペレーティングシステムとモデルサーバー用に約 1 GB を差し引きます。残った容量を 0.6 で割ると、4 ビットで保持できるパラメータ数の上限を十億単位で求められます。次に、実際に必要なコンテキスト用の KV キャッシュ分を差し引きます。残った値が答えです。モデル名の一覧とは異なり、この値は古くなりません。
FAQ
8B モデルの実行には、どの程度の RAM が必要ですか？
4 bit 量子化の場合、重み用に約 4.8 GB が必要です。これに加えて、コンテキスト長に応じた KV キャッシュと、オペレーティングシステムおよびモデルサーバー用に約 1 GB が必要です。8192 トークンのコンテキストではキャッシュに約 1 GB が追加されるため、8 GB プランなら動作しますが、4 GB プランでは不足します。モデルカードに記載された 128k のコンテキスト長を完全に使用する場合、キャッシュだけで 16 GB が必要になるため、32 GB プランが必要です。
VPS に十分な vCPU があるのに、モデルの動作が遅いのはなぜですか？
生成処理はコア数ではなく、メモリ帯域幅によって制限されるためです。各トークンの生成では、アクティブな重み一式を RAM から読み出す必要があります。そのため、数個のコアでメモリチャネルが飽和すると、残りのコアは待機します。もう 1 つの一般的な原因は swap です。モデルが応答している間に vmstat 1 がゼロ以外の si と so を示す場合、重みが RAM に収まっていません。その結果、各トークンの一部がディスクから処理され、見た目以上に大きな性能低下が発生します。
コンテキストウィンドウを長くすると、本当により多くのメモリが必要ですか？
はい。トークン数に対して線形に増加します。一般的な 8B モデルでは、1 トークンあたり約 128 KiB の KV キャッシュを使用します。そのため、8192 トークンでは 1 GB、131072 トークンでは 16 GB が必要です。キャッシュは会話が長くなった時点ではなく、モデルの読み込み時に確保されます。そのため、送信するプロンプトが毎回 200 トークンしかなくても、128k のコンテキストを指定すると、そのメモリが直ちに予約されます。
大規模モデルを 2 bit で実行すべきですか。それとも小規模モデルを 4 bit で実行すべきですか？
4 bit の小規模モデルを選んでください。品質は 8 bit から 4 bit までは緩やかに低下しますが、4 bit 未満では急速に低下します。そのため、70B モデルを 2 bit まで圧縮すると、通常は同じモデル世代の 32B モデルを 4 bit で実行した場合より悪い回答になります。過度な量子化はエラーメッセージではなく、同じ表現の繰り返しや指示の無視として現れます。そのため、プロンプトが原因だと誤解しやすくなります。4 bit を下限とし、代わりにパラメータ数を変更してください。
大手商用モデルと同程度の性能を持つモデルを、自己ホストできますか？
通常の VPS ではできません。最も強力なオープンウェイトモデルは数千億パラメータに達します。4 bit では、KV キャッシュを含める前から 200 GB を超える RAM が必要です。また、最も強力な商用モデルはそもそも配布されていません。一般的なハードウェアで適しているのは、特定の用途向けに優れた 8B から 32B のモデルを実行することです。用途を限定し、適切にプロンプトを設計した小規模モデルなら、汎用モデルに匹敵することもあります。最先端の品質が必要な場合は、どちらかを購入する前に、API の料金と必要なハードウェアの費用を比較してください。