著者 GPU付きVPSは必要？CPUで十分なケースと判断基準
GPU付きVPSは生成速度と大容量モデル、バッチ処理で有利です。量子化7B～27B、少量のembedding、Whisper smallならCPUで動くため、まず測定して判断します。
GPU付きVPSが必要ですか。それともCPUで十分ですか？
GPU付きVPSは、モデルを自分で実行する際の2つの点を変えます。トークンの生成速度と、メモリに収まるモデルの最大サイズです。それ以外は何も変わりません。量子化した7B～27Bのチャットモデルで一度に1人へ応答する場合、少量のembedding処理を行う場合、またはWhisper smallで音声を文字起こしする場合は、十分なRAMを搭載した通常のCPU VPSで処理できます。まずCPUで始め、問題になる数値を測定してから、より上位の構成へ移行してください。
理由はメモリ帯域幅です。言語モデルが1トークンを生成するとき、必要なすべての重みをメモリから読み込みます。4ビットに量子化した8Bモデルは、ディスク上でおよそ4.7 GB、メモリ上でもほぼ同じサイズです。そのため、1トークンの生成には約4.7 GBのデータ移動が必要です。マシンのメモリ帯域幅をこの数値で割ると、1秒あたりのトークン数の上限が得られます。この単純な割り算で、目にするベンチマークのほとんどを説明できます。
GPUで実際に得られるもの
帯域幅。 最新のホストに搭載されたサーバー向けDDR5は、毎秒数十GBを転送します。GPUメモリ（VRAM、ビデオRAM）は、毎秒数百GBから1TBを超えるデータを転送します。この比率が高速化の度合いであり、その差は大きいです。
速度を維持した容量。 RAMが64 GBあるCPUマシンでは、4ビット量子化した70Bモデルを読み込めます。ただし、会話というより読書に近い速度で動作します。ここでGPUが役立つのは、モデルがVRAMに収まる場合だけです。レイヤーがシステムRAMにあふれた瞬間、低速な処理経路に戻るためです。
バッチスループット。 ここは過小評価されがちです。GPUが1人のユーザー向けに生成していると、メモリ待ちになるため、計算資源の大部分がアイドル状態になります。一度に20件のリクエストを処理すれば、同じ重みの読み出し結果を20件すべてに利用できます。ユーザーごとの速度はほとんど低下しない一方、合計のtokens per secondは数倍以上に増加します。CPUではこのようには動作しません。CPUマシンで同時に2人のユーザーが処理すると、互いの速度をおおむね半分にします。多数のクライアントが呼び出すAPIを構築する場合、GPUを選ぶ主な理由は、単一ストリームの生の速度よりもバッチ処理です。
プロンプト処理。 長いプロンプトの読み取りはメモリ帯域幅ではなく計算能力が律速になります。そのため、GPUが最も大きく優位に立てる処理です。CPUで1分かかる30,000トークンのコンテキストは、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の行では、DDR5 CPUマシンの11に対し、1秒あたり50 tokensを示しています。およそ5倍ですが、これは生の演算性能の差ではなく、帯域幅の比率に対応しています。実際のスループットも、帯域幅をモデルサイズで割った値を下回ります。単純な割り算では、増加するコンテキストに対するattentionの追加処理を考慮していないためです。
比較として、人は1秒あたり約5から10語を読みます。1人の読者にとっては、1秒あたり15 tokens以上なら通常のタイピングと同程度に感じられます。そのため、CPUのみの構成でも問題なく使えるケースが多くあります。
購入前にVRAM容量を見積もる
モデルファイルのサイズは下限であり、必要容量そのものではありません。重み、KV cache（key-value cache。attentionがトークンごとに保持するメモリ）、および約1 GBのオーバーヘッドを見積もります。
2026年7月時点での実用的な目安は、モデルファイルのサイズ（ギガバイト）に、通常の8kから16kのコンテキスト用として20パーセントを加えることです。4.7 GBの8Bモデルには、約6 GBのVRAMが必要です。4ビットの27Bモデルは約16 GBで、約20 GBが必要です。4ビットの70Bモデルは約40 GBで、48 GBのカード、または小容量のカード2枚が必要です。
長いコンテキストでは、この目安は当てはまりません。KV cacheはコンテキスト長に比例して増加し、128kトークンでは重み自体を超えることがあります。長いコンテキストを使用する場合は、まずcacheの容量を基準に見積もり、使用するengineがcache quantizationに対応しているか確認してください。
マシンに実際にあるものを確認する
GPU instance では、まず driver が card を認識していることを確認します。
nvidia-smiGPU name、driver version、使用中の memory と total memory を一覧表示する table が必要です。NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver は、driver がないか、kernel upgrade 後に kernel module が再構築されていないことを示します。stock Ubuntu image では、通常は sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install を実行し、その後 reboot して新しい module を読み込みます。
container の場合、driver だけでは不十分です。Docker が device を渡せるように、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次に、container 内から passthrough が機能することを確認します。
sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi同じ table が表示されるはずです。満たせない gpu capability を示す docker: Error response from daemon: could not select device driver 行がある場合、toolkit はインストールされていますが、Docker の再設定または再起動が行われていません。そのため、nvidia-ctk 行と restart をもう一度実行します。Compose では、同等の設定は deploy.resources.reservations.devices entry です。その driver は nvidia で、capabilities list に gpu を含めます。これは VPS 上の Docker Compose で説明した通常の service definition に組み込めます。
アップグレード前に測定する
実際に使用するモデルを、現在使用している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モデルは、少数のCPUコアで1分あたり数百件の短いドキュメントを処理できます。一度構築したIndexは、高速である必要がありません。
文字起こしにはWhisper smallとbaseを使用できます。CPU上のFaster-whisperは、smallモデルでほぼリアルタイムの文字起こしができます。夜間に実行するパイプラインには十分です。
1〜2人で使用する場合は、約27Bまでの量子化Chatモデルを使用できます。処理は遅いですが、結果を読み取れ、実用になります。
バッチジョブと呼べる処理全般です。画面を誰も監視しない場合、実時間の速度は必須条件ではなく、スケジュール上の要素になります。
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語で、最大約13Bのモデルであれば、CPUサーバーでもそれより速くトークンを生成できます。1ユーザーでもコストを正当化できるケースは、長いプロンプト、画像生成、ファインチューニングです。同時に多数のユーザーへ提供する場合は、最も強い理由になります。バッチ処理により、1つのGPUで1件の要求に応答するコストに近いコストで20件の要求に応答できるためです。
GPUを時間単位で借りるべきですか、それとも常時稼働させるべきですか？
ファインチューニング、大量の埋め込み生成、バッチ文字起こしなど、処理が断続的な場合は時間単位で借りてください。GPUインスタンスは生成したトークン数ではなく、インスタンスの稼働時間に対して課金されるため、GPUを常時稼働させるのはカードを継続的に使用する場合だけにしてください。トラフィックの少ないアシスタントは、アイドル状態のGPUよりも、CPU VPSまたはトークン単位で課金されるホステッドAPIのほうが安価です。