著者 GPU付きVPSは必要？CPUで十分な条件と選び方
GPU付きVPSは、速度とVRAM容量、バッチ処理のために選びます。量子化7B〜27B、埋め込み、Whisper smallはCPUで動くため、まず測定して判断できます。
GPU 付き VPS が必要ですか。それとも CPU で十分ですか？
GPU 付き VPS にすると、自分でモデルを実行する際に変わるのは 2 つです。トークンが生成される速度と、そもそもメモリに収まるモデルの大きさです。それ以外は何も変わりません。量子化した 7B から 27B のチャットモデルで一度に 1 人へ応答する場合、少量の埋め込み処理を行う場合、または Whisper small で音声を文字起こしする場合は、十分な RAM を搭載した通常の CPU VPS で処理できます。まず CPU で始め、気になる数値を測定してから、必要に応じて上位の構成へ移行してください。
理由はメモリ帯域幅にあります。言語モデルが 1 トークンを生成するとき、必要なすべての重みをメモリから読み込みます。4 ビットで量子化した 8B モデルは、ディスク上でおよそ 4.7 GB、メモリ上でもほぼ同じサイズです。そのため、1 トークンを生成するには約 4.7 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 は数倍に増加する一方、ユーザーごとの速度はわずかに低下するだけです。CPU ではこのようにはなりません。CPU サーバーで 2 人のユーザーが同時に処理すると、互いに速度をおおむね半分にします。多くのクライアントから呼び出される API を構築する場合、GPU を選ぶ根拠は、単一ストリームの生の速度よりもバッチ処理にあります。
プロンプト処理。 長いプロンプトの読み取りはメモリ帯域幅ではなく計算能力がボトルネックになるため、GPU はここで最も大きな差を出します。CPU では処理に 1 分かかる 30,000 token のコンテキストでも、GPU なら数秒で処理できます。各リクエストにドキュメントを詰め込む検索システムでは、この差を常に実感します。
概算値と読み方
以下のブロックには、2026 年 7 月時点で公開されている、4-bit 量子化した 8B モデルの単一ストリームにおける一般的な数値を示します。桁の目安であり、保証値ではありません。量子化方式、コンテキスト長、推論エンジンによって変わります。
The data behind this chart
[
{
"label": "8 vCPU, DDR4",
"mem_bandwidth_gbs": 40,
"tokens_per_sec": 6
},
{
"label": "16 vCPU, DDR5",
"mem_bandwidth_gbs": 75,
"tokens_per_sec": 11
},
{
"label": "24GB GPU",
"mem_bandwidth_gbs": 300,
"tokens_per_sec": 50
},
{
"label": "40GB data-centre GPU",
"mem_bandwidth_gbs": 1555,
"tokens_per_sec": 130
}
]24 GB GPU の行では、1 秒あたり 50 トークンです。DDR5 CPU ボックスでは 11 トークンです。およそ 5 倍の差であり、演算性能の差というより、帯域幅の比率に対応しています。実際のスループットは、帯域幅をモデルサイズで割った値を下回ります。コンテキストが増えると attention の処理量も増えますが、単純な割り算ではこの処理を考慮しないためです。
比較として、人間が読む速度は 1 秒あたり約 5～10 語です。1 人の読者にとって、1 秒あたり 15 トークン以上なら通常の入力速度と同じように感じられます。そのため、CPU のみの構成でも十分に実用になるケースが多くあります。
購入前にVRAM容量を見積もる
モデルファイルのサイズは下限であり、必要容量そのものではありません。重みの容量に加えて、KVキャッシュ（key-value cache。attention がトークンごとに保持するメモリ）と、約 1 GB のオーバーヘッドを見積もります。
2026年7月時点での実用的な目安は、モデルファイルのサイズ（GB）に、通常の 8k〜16k コンテキスト用として 20% を加えることです。4.7 GB の 8B モデルには、約 6 GB の VRAM が必要です。4bit の 27B モデルは約 16 GB で、必要な容量はおよそ 20 GB です。4bit の 70B モデルは約 40 GB で、48 GB のカード、またはより小容量のカード 2 枚が必要です。この計算方法は、さらに大きなモデルにもそのまま使えます。Kimi K3 のような 2.8 兆パラメーターのモデルで VRAM を計算する方法を見ると、カード選び自体が問題ではなくなる境界が分かります。
長いコンテキストでは、この目安は当てはまりません。KVキャッシュはコンテキスト長に比例して増加し、128k トークンでは重み自体を上回ることがあります。長いコンテキストを使用する予定がある場合は、まずキャッシュ容量を基準に見積もり、使用するエンジンがキャッシュの量子化に対応しているか確認してください。
実際にマシンに存在するものを確認する
GPU インスタンスでは、最初にドライバーが GPU を認識していることを確認します。
nvidia-smiGPU 名、ドライバーのバージョン、使用済みメモリと総メモリを一覧にした表が表示されます。NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver と表示された場合は、ドライバーがないか、カーネルのアップグレード後にカーネルモジュールが再ビルドされていません。標準の Ubuntu イメージでは、通常は sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install を実行し、その後に再起動して新しいモジュールを読み込みます。
コンテナでは、ドライバーだけでは不十分です。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 行がある場合、Toolkit はインストールされていますが、Docker の再設定または再起動が行われていません。そのため、nvidia-ctk 行を再実行してから再起動します。Compose では、driver が nvidia で、capabilities の一覧に gpu を含む deploy.resources.reservations.devices エントリが相当します。これは VPS 上の Docker Compose で説明した通常の service 定義に組み込めます。
アップグレード前に測定する
実際に使用するモデルを、現在利用できる 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 インスタンスは、同等の CPU インスタンスより数倍高額です。生成したトークン数ではなく、インスタンスが存在する時間ごとに課金されます。1 日に数件しかリクエストを処理しない GPU を常時稼働させる構成は、推論の実行方法として最も高コストです。分岐点になるのは利用率です。高稼働の GPU はトークン単価が低く、アイドル状態の GPU は完全な無駄になります。
現実的なパターンは3つあります。継続的に発生する少量の処理は、CPU VPS で実行します。たまに発生する難しいリクエストはホスト型 API に送り、トークン単位で支払います。バッチ処理、ファインチューニング、大量の埋め込み生成では 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〜16k のコンテキストで 4-bit 量子化した 8B モデルを実行する場合、約 6 GB です。重みが約 4.7 GB で、残りは KV キャッシュと約 1 GB のオーバーヘッドです。12 GB のカードなら、より長いコンテキストにも十分対応できます。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 を利用する価値はありますか？
通常はありません。1 人が読む速度は毎秒 5〜10 語であり、CPU サーバーでも約 13B までのモデルなら、それより速くトークンを生成できます。1 ユーザーでも費用を正当化しやすい用途は、長いプロンプト、画像生成、ファインチューニングです。多数のユーザーに同時提供する場合は、GPU を利用する強い理由になります。バッチ処理により、1 件のリクエストへの応答とほぼ同じコストで、1 台の GPU が 20 件のリクエストに応答できるためです。
GPU を時間単位で借りるべきですか、それとも常時稼働させるべきですか？
ファインチューニング、大量の埋め込み生成、バッチ文字起こしなど、処理が断続的な場合は時間単位で借りてください。GPU インスタンスは生成したトークン数ではなく、インスタンスの稼働時間に対して課金されるため、GPU が継続的に使用される場合にだけ常時稼働させます。トラフィックの少ないアシスタントなら、アイドル状態の GPU よりも CPU VPS、またはトークン単位で課金されるホステッド API の方が安価です。