自宅サーバーで動かせるAIモデルの選び方

セルフホストできる AI モデルを決める要素

セルフホストできる AI モデルは、1 つの数値で決まります。サーバーの RAM 容量です。モデルファミリーやフレームワークよりも、重みを余裕を残してメモリに収められるかどうかが重要です。この記事では、その判断に使う計算方法を説明します。ランタイムのインストールは別の作業です。VPS で Ollama を実行するガイドで説明しています。

結果を決めるコストは 2 つあります。重みはパラメーター数と量子化方式で決まる固定コストです。コンテキストウィンドウは実行時コストです。昨日はロードできたモデルが、今日はロードできなくなるまで、このコストは見落とされがちです。

パラメータあたりのビット数によるサイズ計算

モデルファイルの内容は、ほぼすべてが重みデータです。各重みは特定のビット数で保存されます。量子化とは、学習時の精度よりも少ないビット数で保存することを指します。これにより、わずかな精度の低下と引き換えに、大幅なメモリ節約が可能になります。モデルのサイズは以下の計算式で決まります。

weights in GB = (parameters in billions x bits per weight) / 8

ほとんどのモデルは16ビットでリリースされており、これは10億パラメータあたり2 GBに相当します。一部のモデルはあらかじめ部分的に量子化されています。例えば、OpenAIの gpt-oss は、Mixture of Experts（MoE）の重みを 4 bit MXFP4 で事後学習しています。いずれにせよ、VPS上で16ビットの重みをそのまま実行するケースはほとんどありません。実際に遭遇する量子化形式と、重みあたりの平均ビット数は以下の通りです。

• 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ビットを下回ると品質低下が急速に進むため、70Bモデルを2ビットに圧縮するよりも、同じ世代の32Bモデルを4ビットで実行する方が、通常は良好な回答が得られます。メモリが不足している場合は、4ビットを下回る前に、モデルのサイズクラスを下げてください。

[
  {
    "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 つ目のコストです。モデルの読み込み時に確保され、指定したコンテキスト長に合わせてサイズが決まり、その長さに比例して増加します。

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

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:4b

ollama 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 bit 量子化された 1B から 4B のモデルに相当します。2026 年 8 月時点では、このクラスには Llama 3.2 の 3B 版、Qwen 3 の 1.7B 版および 4B 版、そして小型の Gemma や Phi シリーズが含まれます。これらはあくまでサイズの目安であり、推奨事項ではありません。モデル名は数ヶ月ごとに変わりますが、計算式は変わりません。

生成速度は、おおよそ 6 から 14 トークン/秒を見込んでください。このサイズのモデルは、分類、タグ抽出、短い要約、段落のスタイル書き換えといった限定的なタスクに適しています。複数ステップの推論や、複数のファイルにまたがるコード生成には不向きであり、プロンプトを工夫しても改善しません。

このティアにおける障害の主な原因はスワップです。モデルがメモリに収まらない場合、Linux は読み込みを拒否しません。代わりにメモリをディスクへ退避（ページング）します。1 つのトークンを生成するたびに全ウェイトを読み込む必要があるため、生成速度は 1 トークンあたり数秒まで低下します。モデルの回答中に free -h を監視し、vmstat 1 の si 列と so 列を確認してください。vmstat 出力の 1 行目は起動時からの平均であるため無視し、カウンターはモデルだけでなくシステム全体を対象としている点に留意してください。アイドル時にゼロであったスワップイン/アウトが生成開始と同時に増加する場合、そのモデルはそのプランに対して大きすぎます。

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であり、OllamaがLlama 3.3 70B (Q4_K_M) に対して提示する43 GBという数値と一致します。これは48 GBプランにギリギリ収まるサイズですが、長いコンテキストを扱うには64 GBが必要です。

次に、速度について現実的に判断してください。CPU上で動作する32Bモデルの速度は、1秒あたり0.6から1.5トークン程度です。70Bモデルの場合は0.2から0.5トークンとなります。70Bモデルで500トークンの回答を得るには約20分かかります。この速度では、モデルが完了する前にリクエストが終了してしまうことが一般的です。Ollamaの前段にあるクライアントやプロキシのタイムアウトが先に発生するためで、これがcontext deadline exceededエラーの原因となります。これらはバッチ処理向けのツールです。夜間にドキュメントのキューを処理させるのであれば速度は問題になりませんが、チャットウィンドウの背後で利用する場合には非常に重要になります。

Mixture of Experts (MoE) によるルーティングは、この計算式を変化させます。これは学習しておくべき唯一のアーキテクチャの詳細です。MoEモデルは、各トークンを重みの一部のみに通します。合計パラメータ数が30Bで、トークンあたりのアクティブパラメータ数が3Bのモデルは、30B相当のメモリを必要としますが、生成速度は3Bの密なモデルに近いものになります。各トークンがアクティブなエキスパートのみを読み込むためです。32 GBのサーバーでは、このような構成のMoEの方が、密な30Bモデルよりもはるかに実用的です。覚えておくべき原則は、「合計パラメータ数がメモリを決定し、アクティブパラメータ数が速度を決定する」ということです。

CPU 推論の速度は、実際にはどの程度ですか？

1 トークンを生成するには、アクティブなすべての重みをメモリから 1 回読み出す必要があります。これを回避する方法はないため、CPU での生成速度はコア数ではなくメモリ帯域幅で決まります。上限は、使用可能なメモリ帯域幅を重みのサイズ（バイト単位）で割った値です。小規模な共有 VPS では、vCPU 全体で現実的に 10〜25 GB/秒程度になるため、4.8 GB のモデルでは最大でも約 2〜5 トークン/秒です。

[
  {
    "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：7Bまたは8Bモデルを4 bit量子化し、短いコンテキストで実行可能。
• 16 GBのVRAM：14Bモデルを4 bit量子化し、実用的なコンテキストで実行可能。または8Bモデルを8 bit量子化して実行可能。
• 24 GBのVRAM：32Bモデルを4 bit量子化し、短いコンテキストで実行可能。
• 48 GBのVRAM：70Bモデルを4 bit量子化し、適度なコンテキストで実行可能。長いコンテキストや並行処理には、80 GB程度の容量が必要。

モデルが収まりきらない場合、Ollamaはモデルを分割し、一部のレイヤーをGPUに、残りをCPUに割り当てます。ollama psはPROCESSOR列で分割状況を報告し、78%/22% CPU/GPUのように表示されます。これは機能というより警告として捉えてください。CPU側の処理がボトルネックとなり、すべてのトークンがCPU上のレイヤー処理を待機するため、レイヤーの4分の1がCPUにあるモデルは、GPUの速度ではなくCPUの速度に近い動作となります。意図しない分割が発生した場合は、まずコンテキスト長を短縮してください。多くの場合、キャッシュが容量超過の原因です。

並行処理も、リソースを拡張すべき理由の一つです。モデルの重みは同時リクエスト間で共有されますが、各アクティブなリクエストには個別のKVキャッシュが必要です。例えば、8Bモデルを8kコンテキストで10人のユーザーが同時に利用する場合、重みに加えて10倍の 1 GBのキャッシュが必要になります。単一のセルフホストモデルで並行ユーザーを処理するでは、その限界点について解説しています。

GPUをレンタルする価値があるかどうかも計算の問題であり、最終的には月間で生成するトークン数に依存します。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 キャッシュ、さらに OS とモデルサーバー用に約 1 GB が必要です。8192 トークンのコンテキストではキャッシュに約 1 GB 追加されるため、8 GB のプランであれば動作しますが、4 GB では不足します。モデルカードで謳われている 128k のフルコンテキストを利用する場合、キャッシュだけで 16 GB となるため、32 GB のプランが必要です。

VPS の vCPU に余裕があるのにモデルの動作が遅いのはなぜですか？

生成速度はコア数ではなくメモリ帯域幅に制限されるためです。トークンを 1 つ生成するたびに重みデータ全体を RAM から読み出す必要があり、数個のコアでメモリチャネルが飽和すると、残りのコアは待機状態になります。もう一つの一般的な原因はスワップです。プロンプト送信前に vmstat 1 で si と so が 0 であり、回答生成中に数値が上昇する場合、重みデータが RAM に収まりきっておらず、ディスクから読み出されている可能性が高いです。これは見た目以上に大きな負荷となります。

コンテキストウィンドウを長くすると本当にメモリが必要になりますか？

はい、メモリ消費量はトークン数に対して線形に増加します。一般的な 8B モデルでは 1 トークンあたり約 128 KiB の KV キャッシュを消費するため、8192 トークンで 1 GB、131072 トークンで 16 GB となります。キャッシュは会話の進行中ではなくモデルの読み込み時に確保されるため、128k コンテキストを指定すると、送信するプロンプトが 200 トークン程度であってもその分のメモリが即座に予約されます。

大きなモデルを 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 の利用料金と比較検討してください。