GPU付きVPSは必要？CPUで十分な条件と選び方

GPU 付きの VPS が必要ですか、それとも CPU で十分ですか？

GPU 付きの VPS を使うと、モデルを自分で実行する際に変わるのは、トークンの生成速度と、そもそもメモリに収まるモデルのサイズです。それ以外は何も変わりません。量子化した 7B〜27B のチャットモデルで 1 人ずつ応答する場合、低負荷の embedding 処理、または Whisper small による音声文字起こしであれば、十分な RAM を備えた通常の CPU VPS で処理できます。まず CPU で始め、気になる数値を測定してから、必要に応じて上位の構成へ移行してください。

理由はメモリ帯域幅にあります。言語モデルが 1 トークンを生成するとき、必要なすべての重みをメモリから読み込みます。4 bit で量子化した 8B モデルは、ディスク上で約 4.9 GB、メモリ上でもほぼ同じサイズです。そのため、1 トークンの生成には約 4.9 GB のデータ移動が必要です。マシンのメモリ帯域幅をこの数値で割ると、1 秒あたりのトークン数の上限が得られます。この 1 回の割り算で、確認するほぼすべてのベンチマーク結果を説明できます。

GPU が実際にもたらすもの

帯域幅。 最新のホストのサーバー向け DDR5 は、毎秒数十 GB を転送します。GPU メモリ（VRAM、ビデオ RAM）は、毎秒数百 GB から 1,000 GB を超えるデータを転送します。この比率が高速化の度合いであり、その差は大きくなります。

速度を伴う容量。 RAM を 64 GB 搭載した CPU サーバーでは、4 ビットの 70B モデルを読み込めます。動作はしますが、チャットというより読書に近い速度です。この場合、GPU が役立つのはモデルが VRAM に収まる場合だけです。レイヤーが system RAM にあふれた瞬間、低速な経路が処理を支配するためです。

バッチ処理のスループット。 ここは過小評価されがちです。GPU が 1 ユーザー向けに生成している間は、メモリ待ちになるため、計算資源の大部分がアイドル状態になります。20 件のリクエストを同時に処理すれば、同じ重みの読み込みを 20 件で共有できます。ユーザーごとの速度はほとんど低下しないまま、合計 tokens per second は数倍に増加します。llama.cpp などの CPU 推論エンジンもバッチ処理をサポートしており、効果はハードウェアとワークロードによって異なります。多数のクライアントが呼び出す API を構築する場合、GPU を使う根拠は単一ストリームの最大速度よりもバッチ処理にあります。

プロンプト処理。 長いプロンプトの読み込みはメモリ負荷ではなく計算負荷であり、ここでは GPU が最も大きな差を生みます。CPU で 1 分かかる 30,000 tokens のコンテキストでも、GPU なら数秒で処理できます。すべてのリクエストにドキュメントを詰め込む検索システムでは、この差を常に実感します。

概算値と読み方

実際のスループットも、帯域幅をモデルサイズで割った値を下回ります。これは、コンテキストが長くなるにつれて attention の処理が増え、単純な割り算ではその処理量を考慮できないためです。

比較として、英語の成人の黙読速度は平均で毎秒約 4.0〜4.3 語です。ノンフィクションでは 1 分あたり 238 語、フィクションでは 260 語です。毎秒 15 tokens 以上であれば、1 人の読者にとっては通常のタイピングとすでに同程度に感じられます。そのため、CPU のみを使用する構成でも、気付かないうちに十分な性能を発揮するものが多くあります。

購入前に VRAM 容量を見積もる

モデルファイルのサイズは最低ラインであり、必要容量そのものではありません。重みに加えて、KV cache（key-value cache。attention がトークンごとに保持するメモリ）と、約 1 GB のオーバーヘッドを見積もってください。

KV cache は一律の割合で加算せず、個別に計算してください。重みを量子化しても、cache は量子化されないためです。full-attention モデルは、各トークンについて、すべての layer と KV head ごとに key と value を保存します。FP16 では 1 つの数値あたり 2 bytes です。これは Ollama のデフォルトの cache type です。2026-10-27 に確認した Ollama の model metadata では、Llama 3.1 8B は 32 layers、8 KV heads、128 dimensions です。この構成では、1 トークンあたり 128 KiB になります。8k context では約 1.07 GB、16k では 2.15 GB です。したがって、4.9 GB の 8B model は、8k で約 7 GB、16k で約 8 GB の VRAM を必要とします。4 bit の 27B model は約 17 GB です（Ollama の library にある Gemma 3 27B）。Gemma 3 の metadata では sliding window が 1,024 tokens なので、cache の大部分は増加し続けません。そのため、20 GB 以上を見込んでください。4 bit の 70B は約 43 GB です（Llama 3.3 70B）。80 layers では、FP16 cache だけで 8k で約 2.7 GB、16k で 5.4 GB 増えるため、余裕の少ない 48 GB card、または小容量の card 2 枚が必要です。この計算方法はさらに大きなモデルでも使えます。Kimi K3 のような 2.8 trillion parameter model の VRAM 計算では、card を選ぶこと自体が問題ではなくなる境界を確認できます。

この点が最も重要になるのは、長い context を使う場合です。Llama 3.1 のような full-attention model では、KV cache は context length に比例して増加し、128k tokens では重み自体を上回ることがあります。sliding-window attention または chunked attention を使う model は異なります。Hugging Face の Transformers documentation では、Mistral、Gemma 2、Llama 4 を例として挙げています。これらの model では、対象 layer の cache が window または chunk size に達すると増加が止まるため、合計容量の増加が緩やかになります。長い context を使う予定なら、まず cache 用の容量を見積もり、engine が cache quantization に対応しているか確認してください。Ollama では、OLLAMA_KV_CACHE_TYPE=q8_0 はデフォルトの f16 の約半分のメモリを使用します。ただし、cache quantization は Flash Attention が有効な場合にのみ適用されます。context length も明示的に設定してください。Ollama は VRAM からデフォルト値を選びます。24 GiB 未満では 4k、24〜48 GiB では 32k、48 GiB 以上では 256k です。70B model を 48 GB card で実行すると、このデフォルト値では card の容量を大幅に超える cache が必要になります。

マシンに実際に搭載されているものを確認する

GPU インスタンスでは、最初にドライバーが GPU を認識していることを確認します。

nvidia-smi

GPU 名、ドライバーのバージョン、使用中のメモリ量と総メモリ量を一覧にした表が表示されます。NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver は NVIDIA-SMI がドライバーに接続できないことを示します。ドライバーがインストールされ、カーネルモジュールが読み込まれていることを確認します。標準の Ubuntu イメージでは、通常は sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install を実行してから再起動し、新しいモジュールを読み込みます。計算用マシンでは、Ubuntu のサーバー向けドキュメントは sudo ubuntu-drivers install --gpgpu を推奨しています。これは server ドライバーのブランチを選択します。

コンテナでは、ドライバーだけでは不十分です。デバイスをコンテナに渡すには、Docker に NVIDIA Container Toolkit が必要です。

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

次に、コンテナ内からデバイスの引き渡しが機能することを確認します。

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

同じ表が表示されるはずです。GPU の capability を満たせないことを示す docker: Error response from daemon: could not select device driver 行が表示された場合、Docker は要求に一致するデバイスドライバーを見つけられませんでした。Toolkit がインストールされていることを確認し、nvidia-ctk 行と再起動をもう一度実行します。Compose では、同等の設定は deploy.resources.reservations.devices エントリです。この driver は nvidia で、capabilities のリストに gpu が含まれます。これは VPS 上の Docker Compose で説明した通常のサービス定義に組み込めます。

アップグレード前に測定する

実際に使用するモデルを、現在利用できる CPU マシンで実行し、数値を記録します。VPS で Ollama を使用して LLM をセルフホストする場合は、1 つのフラグを指定するだけです。

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

出力の末尾には実行時間が表示されます。eval rateは、1 秒あたりの生成トークン数です。prompt eval rateは、マシンが入力を読み取る速度です。この 2 つの数値から、どのアップグレードが有効か判断できます。eval rateが低い場合はメモリ帯域幅の問題です。長い入力でprompt eval rateが低い場合は、計算性能の問題です。

GPU を搭載したマシンでは、モデルが実際に GPU に配置されたことを確認します。

ollama ps

すべて収まる場合、PROCESSOR列には100% GPUと表示されます。収まらない場合は、43%/57% CPU/GPUのような表示になります。一部だけ分割して配置すると、通常は予想以上に性能が低下します。すべてのトークンが、遅い側の処理を待つ必要があるためです。

コストの考え方

GPU インスタンスはトークン数ではなく、プロビジョニングされた計算時間に対して課金されます。料金体系と停止中のインスタンス料金はプロバイダーによって異なります。1 日に数件のリクエストしか処理しない GPU を常時稼働させると、支払った時間の大半がアイドル状態になります。損益分岐点を決めるのは利用率です。高稼働の GPU はトークン単価が低く、アイドル状態の GPU はコストを浪費するだけです。

現実的な運用パターンは 3 つあります。継続的に発生する少量の処理は CPU VPS で実行します。まれに発生する処理負荷の高いリクエストはホスト型 API に送り、トークン単位で支払います。バッチ処理、ファインチューニング、大量の embedding 処理では GPU を時間単位で借り、処理後に削除します。これらを組み合わせるのは一般的です。常時稼働の VPS における AI エージェントのコスト管理で説明した予算管理の考え方も適用できます。ただし、ここで漏れになるのはトークン数ではなくアイドル時間です。

GPU なしでも問題なく動作するもの

低ボリュームの Embeddings。小規模な embedding model であれば、少数の CPU コアで毎分数百件の短いドキュメントを処理できます。一度構築した index は、高速である必要がありません。

文字起こしには Whisper small と base。CPU 上の faster-whisper では、small model をほぼリアルタイムで文字起こしできます。一晩かけて実行するパイプラインには十分です。

1 人または 2 人で使用する、約 27B までの量子化 chat model。処理は遅くても、読みやすく、実用的です。

バッチジョブと呼べる処理全般です。誰も画面を見ていない場合、経過時間の短さは必須条件ではなく、スケジュール上の問題になります。

GPU が実際に必要になるのは、小規模な adapter を超える学習または fine-tuning、多数の同時接続ユーザーへの提供、画像や動画の生成、そしてレイテンシー自体が要件となるリアルタイム音声処理です。

FAQ

7B または 8B モデルには、どの程度の VRAM が必要ですか？

8k コンテキストで 4-bit 量子化した 8B モデルを実行する場合、Ollama のデフォルトである FP16 キャッシュでは約 7 GB が必要です。16k では約 8 GB 必要です。重みは約 4.9 GB で、KV キャッシュが 8k では約 1.07 GB、16k では約 2.15 GB 増え、残りのオーバーヘッドが約 1 GB です。8 GB のカードなら 8k では収まりますが、16k では余裕がありません。12 GB のカードなら、より長いコンテキストにも十分対応できます。キャッシュを q8_0 に切り替えると、キャッシュが占める容量はおよそ半分になります。128k のコンテキストで実行する予定がある場合は、キャッシュ用の容量を別に見積もってください。キャッシュが重みより大きくなる可能性があるためです。

GPU なしで Ollama を実行できますか？

はい。Ollama は自動的に CPU にフォールバックし、モデルを保持できるだけの RAM だけを必要とします。4-bit の 8B モデルでは、メモリ速度に応じて毎秒およそ 5〜12 トークンを見込めます。これは 1 ユーザーの読書速度に近い値です。CPU で本当に問題になるのは長いプロンプトです。30,000 トークンのコンテキストの読み取りは計算負荷が高く、応答の生成よりはるかに時間がかかります。

GPU が CPU よりほとんど速くないのはなぜですか？

通常の原因は、モデル全体が VRAM に収まらず、一部のレイヤーが CPU で実行されていることです。そのため、各トークンが遅い側の処理を待つことになります。ollama ps を実行し、PROCESSOR 列で 100% GPU を確認してください。分割されている場合は、より小さい量子化またはより小さいモデルを使用します。もう 1 つの一般的な原因は、モデルの読み込み時間が測定結果の大部分を占める短いベンチマークです。

1 ユーザーで GPU VPS を使う価値はありますか？

通常はありません。英語を黙読する成人の平均速度は毎秒約 4.0〜4.3 語です。CPU ボックスの出力速度をこの読書速度と比較する前に、毎秒トークン数を毎秒単語数へ換算する必要があります。1 ユーザーでもコストを正当化しやすいのは、長いプロンプト、画像生成、ファインチューニングです。同時に多くのユーザーへ提供する場合は、GPU の 1 回の重み読み出しをバッチ処理で複数のリクエストに共有できるため、GPU を使う最も強い理由になります。

GPU を時間単位で借りるべきですか、それとも常時稼働させるべきですか？

ファインチューニング、大量の埋め込み処理、バッチ文字起こしなど、処理が一時的に集中する場合は時間単位で借ります。常時稼働させるのは、カードが継続的に使われる場合だけにしてください。プロビジョニングした GPU の料金は、生成したトークン数ではなく利用時間に基づくためです。トラフィックの少ないアシスタントなら、アイドル状態の GPU よりも CPU VPS のほうが安く済みます。トークン単位で支払うホステッド API のほうが安い場合もあります。