著者 自分でホストできる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 ビットでリリースされます。これはパラメータ 1 billion 個あたり 2 GB に相当します。そのため、VPS でリリース時の精度のまま実行するケースはほとんどありません。実際に使用する量子化形式と、重みあたりの実際の平均ビット数は次のとおりです。
Q8_0は重みあたり約 8.5 ビットを使用するため、パラメータ 1 billion 個あたり約 1.1 GB です。Q6_Kは約 6.6 ビットを使用するため、1 billion 個あたり約 0.83 GB です。Q5_K_Mは約 5.7 ビットを使用するため、1 billion 個あたり約 0.71 GB です。Q4_K_Mは約 4.8 ビットを使用するため、1 billion 個あたり約 0.6 GB です。
運用上の計算には、パラメータ 1 billion 個あたり 0.6 GB を使用してください。メモリに制約のあるホストでは、Q4_K_M が妥当なデフォルトです。多くのタスクでは 8 ビットに対する品質低下が小さく、ファイル容量はほぼ半分になります。4 ビット未満では品質低下が急速に大きくなります。そのため、同じ世代のモデルであれば、70B を 2 ビットまで圧縮するより、32B を 4 ビットで使用したほうが通常は良い回答を得られます。メモリが不足する場合は、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
}
]上の weight 列には、パラメータ 1 billion 個あたり 0.6 GB というルールを適用しています。実際の GGUF ファイルは、embedding 層と output 層が他の層より高い精度で保持されるため、この値から数パーセント以内に収まります。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 となり、トークンあたり 128 KiB です。
Ollama のデフォルトのコンテキスト長では、この 8B モデルはキャッシュに半分の gigabyte を使用します。8192 tokens では 1 GB を使用します。モデルカードで示されている 128k コンテキストでは 16 GB を使用し、重みの 3 倍を超えます。70B は逆です。128k でのキャッシュは 40 GB で、重み自体より少なくなります。これは grouped query attention により、トークンあたりのコストがパラメーター数ほど急速に増加しないためです。
CPU のみのサーバーでは、Ollama のデフォルトのコンテキスト長は 4096 tokens です。GPU がある場合は、VRAM に応じてデフォルト値を選択します。24 GiB 以上 48 GiB 未満では 32k、48 GiB 以上では 256k です。サーバー上の OLLAMA_CONTEXT_LENGTH 変数で値を増やし、実行中のモデルに実際に適用された値を ollama ps の CONTEXT 列で確認します。この設定に関するメモリ計算は、num_ctx とコンテキスト長に関する記事で詳しく説明しています。
キャッシュの使用量を減らす方法は 2 つあります。モデルカードに記載されたコンテキストではなく、必要なコンテキストを指定します。チャットやコーディングの多くは 8k から 32k に収まります。もう 1 つは、キャッシュ自体を 8 bits に量子化する方法です。長いコンテキストでの想起性能が低下する可能性はありますが、使用量を半分にできます。
常駐モデルは、アンロードされるまで RAM を占有します
Ollama は最後のリクエストから 5 分間モデルをメモリに保持し、その後アンロードします。このデフォルト設定はラップトップには適していますが、サーバーでは適しません。アイドル時間のたびに、最初のリクエストで再びロード時間が発生するためです。
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 月時点では、Llama 3.2 の 3B、Qwen 3 の 1.7B と 4B、小型の Gemma および Phi リリースがこの範囲に含まれます。これらはサイズの例であり、推奨ではありません。モデル名は数か月ごとに変わりますが、計算方法は変わりません。
おおよそ 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 bit の 7B または 8B を 8k コンテキストで実行できます。重みの容量は約 4.8 GB です。16 GB なら、4 bit の 13B または 14B を実行できます。容量は約 8.4 GB です。パラメータ数より精度を優先してメモリを使いたい場合は、8B を 8 bit で実行することもできます。
制約になるのは速度です。CPU 上の 8B は、1 秒あたり約 3〜7 トークンを生成します。14B では約 1.5〜3.5 トークンです。人間の読解速度は 1 秒あたりおよそ 5〜10 トークンなので、CPU VPS 上の 8B は、遅いタイピストの入力を見ているような体感になります。バックグラウンドジョブには問題ありませんが、対話型チャットでは待ち時間が負担になります。VPS 上で実行した 8B 以上の Qwen 3 の実測結果を見ると、実際の動作を確認できます。
32～64 GB の VPS で動作するもの
4 ビット量子化した 32B は約 19.2 GB なので、コンテキストを短くすれば 32 GB プランに収まり、48 GB または 64 GB なら余裕があります。4 ビット量子化した 70B は約 42 GB なので、キャッシュを追加する前から 64 GB が必要です。
次に、速度を現実的に確認します。32B を CPU で実行すると、速度は毎秒約 0.6～1.5 トークンです。70B では毎秒 0.2～0.5 トークンです。この 70B で 500 トークンの回答を生成すると、約 20 分かかります。これらはバッチ処理向けのツールです。文書をキューに入れて夜間に処理するなら、速度は問題になりません。チャット画面の背後で動かす場合は、速度が大きく影響します。
Mixture of experts のルーティングではこの計算が変わります。このアーキテクチャ上の特徴は、理解しておく価値があります。MoE モデルは、各トークンを重みの一部だけに通します。総パラメーター数が 30B で、トークンごとのアクティブパラメーター数が 3B のモデルは、30B 相当のメモリを必要とします。一方、各トークンが読み込むのはアクティブなエキスパートだけなので、生成速度は密な 3B モデルに近くなります。32 GB のマシンでは、この構成の MoE は密な 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 ハードウェアでよく報告される範囲であり、特定のマシンのベンチマークではありません。実際の値は、メモリの世代、ホストのメモリチャネル数、同じリソースを奪い合う近隣テナントの数によって変わります。すでに使用できるモデルタグを使って、自分の環境で測定してください。
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 なら数秒です。ホストしているモデルをコーディングエージェントから利用するとき、最初にこの壁に突き当たります。回答の最初の 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 のキャッシュが必要になります。1 つの自己ホスト型モデルで同時ユーザーに対応する方法では、この上限がどこにあるかを確認します。
GPU をレンタルする価値があるかどうかも、計算で判断できます。実際に 1 か月あたり何トークンを生成するかが基準になります。GPU VPS と API トークンの損益分岐点に、その数値を示しています。
自己ホストできないもの
ここには異なる壁が2つあります。どちらに直面しているかを把握すると、判断しやすくなります。
1つ目は、重みが非公開であることです。最先端の商用モデルは配布されていないため、ダウンロードできるファイルはありません。RAM の容量を増やしても解決しません。インターフェース、検索取得レイヤー、エージェントループ、ログなど、モデルの周辺はすべて自己ホストできます。しかし、モデル自体はリモート API のままです。Claude を自己ホストできるかで詳しく説明しています。
2つ目は、オープンウェイトでも単純に大きすぎることです。最大規模のオープンリリースは、総パラメーター数が数千億に達する Mixture of Experts 構成です。これらにも同じ原則が当てはまります。総パラメーター数が 400B のモデルは、4 bit 量子化でも、キャッシュを含める前の重みだけで約 240 GB 必要です。これは専門的なハードウェアを要し、月単位で借りる費用は、ほとんどの人が 1 年間に API トークンへ支払う額を大幅に上回ります。Kimi クラスのモデルを自己ホストするために必要なものでは、実際に必要な要件を説明しています。
この2つの境界について、率直に言えば次のとおりです。負荷が安定していて、データをサーバーの外部に出すべきでない場合は自己ホストします。負荷が突発的に増減する場合や、本当に必要なのが最先端の回答品質である場合は、トークンを購入します。
選択前に利用可能な容量を確認する
free -h
nproc
lscpu | grep 'Model name'availableのfree -h列ではなく、total列を基準に計画します。totalには、システムがすでに使用しているメモリが含まれるためです。オペレーティングシステムとモデルサーバー用に、約 1 GB を差し引きます。残った容量を 0.6 で割ると、4 bits で保持できるパラメータ数の上限を、十億単位で求められます。次に、実際に必要なコンテキスト分の KV cache を差し引きます。残った値が答えです。モデル名の一覧とは異なり、この値は時間が経っても古くなりません。
FAQ
8B モデルの実行には、どれくらいの RAM が必要ですか？
4 bit 量子化では、重みに約 4.8 GB が必要です。これに加えて、コンテキスト長に応じた KV キャッシュと、OS およびモデルサーバー用に約 1 GB が必要です。8192 token のコンテキストでは、キャッシュが約 1 GB 増えるため、8 GB プランなら動作しますが、4 GB プランでは不足します。モデルカードに記載された 128k のコンテキスト長を完全に使う場合、キャッシュだけで 16 GB 必要になるため、32 GB プランが必要です。
VPS に vCPU が十分あるのに、モデルの処理が遅いのはなぜですか？
生成速度は CPU コア数ではなく、メモリ帯域幅に制限されるためです。各 token の生成では、アクティブな重み一式を RAM から読み出す必要があります。そのため、数個のコアでメモリチャネルが飽和すると、残りのコアは待機します。もう 1 つの一般的な原因は swap です。モデルが応答している間に vmstat 1 で si と so が non zero になっている場合、重みが RAM に収まっていません。各 token の一部がディスクから読み出されるため、見た目以上に大きな性能低下が発生します。
コンテキストウィンドウを長くすると、本当により多くのメモリが必要ですか？
はい。token 数に対して線形に増加します。一般的な 8B モデルでは、1 token あたり約 128 KiB の KV キャッシュを使用します。そのため、8192 token では 1 GB、131072 token では 16 GB が必要です。キャッシュは会話が長くなった時点ではなく、モデルのロード時に確保されます。そのため、送信する各 prompt が 200 token しかなくても、128k のコンテキストを指定すると、そのメモリが直ちに予約されます。
大規模モデルを 2 bits で実行するべきですか。それとも小規模モデルを 4 bits で実行するべきですか？
4 bits の小規模モデルを選んでください。品質は 8 bits から 4 bits までは緩やかに低下しますが、4 bits を下回ると急速に低下します。そのため、70B モデルを 2 bits に圧縮するより、同じモデル世代の 32B モデルを 4 bits で実行したほうが、通常は良い回答を得られます。過度な量子化はエラーメッセージではなく、繰り返しや指示の無視として現れます。そのため、prompt が原因だと考えやすくなります。4 bits を下限とし、代わりにパラメータ数を変更してください。
大手商用モデルと同等の能力を持つモデルを self-host できますか？
一般的な VPS では困難です。最も強力な open weight モデルは数千億パラメータに達します。4 bits では KV キャッシュを含める前から 200 GB を超える RAM が必要です。また、最も強力な商用モデルはそもそも配布されていません。一般的なハードウェアで適しているのは、特定の用途向けに優れた 8B から 32B のモデルを実行することです。用途を限定し、適切に prompt を作成した小規模モデルなら、汎用モデルと同等の性能を得られることもあります。最先端の品質が必要なら、どちらかを購入する前に API の料金と必要なハードウェアの費用を比較してください。