4×RTX 3090サーバーがvLLM負荷で電源断？XServer VPSで同時1・2・4・8を実測

【PR】この記事にはA8.netのアフィリエイト広告を含みます。

先に結論：4×RTX 3090サーバーがvLLMリクエストで電源断する原因を、GPUなしXServer VPSで再現・特定することはできません。しかしCPU・RAM上限付きworkerへ同時1・2・4・8で計64件を送ったところ、64/64件成功、公開ready 20/20、OOM・再起動0でした。同時数1→8でp95は799.099ms→5,839.193msへ悪化し、throughputはほぼ増えません。判定は一部解決です。

今回確認できたのは、限られた計算資源をDockerで隔離し、並列数を上げたときのlatencyとRAMを測りながら本番APIを守る方法です。RTX 3090、vLLM、PSU、transient電力、GPU温度は未測定です。

4×RTX 3090サーバーはなぜリクエスト時に落ちる？

Redditの「4×3090 Server Shutting Down During Requests. Power Issue?」では、4枚のRTX 3090、1600W PSU、vLLM tensor parallel構成がrequest直後に停止するという個別体験が報告されています。投稿者はSSD温度対策後も停止し、電源やtransientを疑っています。

突然の電源断だけで原因は断定できません。PSU、配線、回路、GPU transient、温度、driver、motherboard、PCIe、softwareを個別に切り分ける必要があります。本記事はその投稿の原因を証明しません。

ZennのvLLM環境では並列数をどう扱っている？

Zennの「WSL×RTX3090でローカルLLMを動かす：vLLM + Qwen2.5-14B-AWQ構築記録」は、GPU確認、CUDA/PyTorch/vLLMの組み合わせ、並列処理可能数を環境条件とともに記録しています。

並列性は「高いほどよい」設定ではありません。model、context、KV cache、VRAM、CPU、timeout、目標latencyを揃えて負荷試験する必要があります。

XServer VPSで何を再現した？

vLLMやGPU電源断ではなく、resource上限へ達したworkerへ並列requestが来る状況を再現しました。Ollama qwen3:0.6bを3 CPU・1,800MiBへ制限し、同時数だけを1・2・4・8へ変更しました。

なぜDockerのCPU・RAM上限を付けた？

Docker公式Resource constraintsは、memory制限を設けないcontainerがhost memoryを使い切り、OOMに関わる可能性を説明しています。今回は実験workerだけに上限を付け、Caddy、FastAPI、PostgreSQL用の余白を残しました。

上限は故障を完全に防ぐものではありません。OOMKilled、restart、readyを同時に監視し、終了後に一時containerだけ削除しました。

[PR]
VPSでいろいろ試すなら『XServer VPS』

並列リクエスト64件の結果は？

p95はnearest-rank法です。同時数1→8で7.307倍になりました。一方throughputは1.302〜1.397 req/sで、8倍には増えていません。

同時数を上げてもthroughputが増えなかった理由は？

container CPU平均はすべて約299〜301%で、3 CPU上限へ張り付きました。処理能力が増えないまま待ち行列だけ増えたため、1件あたりlatencyが悪化したと解釈できます。

300%を少し超える値はDocker statsのsampling境界です。長時間の追加CPUを得たという意味ではありません。

RAMは並列数で増えた？

全体最大は1,212.4MiBで、1,800MiB上限内でした。今回の小型modelではOOMしませんでしたが、model size、context、並列数が変われば結果も変わります。

公開APIは負荷中も生きていた？

20/20回成功しました。全caseでdatabase=ok、artifact_storage=okを確認しました。実験containerはOOMKilled false、restart 0で、終了後に削除済みです。

p95を測る意味は？

平均だけでは、混雑時に遅いrequestが見えにくくなります。今回、同時8のp50は5,605.784ms、p95は5,839.193msでした。AI agentは複数toolを待つため、tail latencyが積み重なると全体が止まって見えます。

vLLM公式にもend-to-end request latencyのproduction metricがあります。backendが違っても、成功率、p50/p95、queue、throughputを分ける考え方は共通です。

電源断の切り分けにVPSはどう役立つ？

1. VPSまたはAPIへ同じrequestを送り、clientとpromptの問題を切り離す。
2. local GPU serverは同時1から上げ、電力・温度・driver logを同期記録する。
3. GPU枚数、tensor parallel、model、contextを一つずつ変える。
4. 突然の電源断なら再実行を止め、PSU・回路・配線を専門家へ確認する。
5. VPS queueに未完了jobを残し、worker復旧後に再開する。

電源断を繰り返して原因を探るのではなく、計算workerと司令塔を分離して証跡を残します。

初心者が迷いそうな点は？

• 同時数を増やしてもCPU/GPUが飽和すればthroughputは伸びない。
• error 0でもp95が悪化すれば利用者体験は落ちる。
• containerが生きていても公開APIのreadyを別に確認する。
• OOM/restart 0は電源・温度の安全証明ではない。
• Ollama CPU結果をvLLM GPU性能へ転用しない。

AIスマホ調査システムへどう反映する？

VPSのqueueでworkerごとの同時上限を持たせます。今回の3 CPU workerなら、throughputが伸びない同時8へ一気に渡さず、同時1〜2で処理し、残りはqueuedにします。

よくある質問

今回vLLMを使った？

いいえ。GPUなしVPSのOllama 0.33.2です。vLLM電源断の再現ではなく、制限付き並列負荷の実験です。

同時8が最もthroughputが高いので採用すべき？

差は小さく、p95は同時1の7.307倍です。応答時間とqueue要件を含めて決めます。

OOMしなければ安全？

いいえ。電源、温度、disk、driver、回路など別の故障があります。

XServer VPSが4×RTX 3090を代替する？

しません。今回の4GB・GPUなしVPSで確認したのは0.6B modelです。

突然電源断したGPUサーバーへ負荷試験を続けてよい？

推奨しません。再試行を止め、hardware・電源設備を安全に点検してください。

[PR]
VPSでいろいろ試すなら『XServer VPS』

4×RTX 3090の電源断問題はXServer VPSで解決した？

判定は一部解決です。元投稿の電源断原因は未解決です。一方、64件の制限付き並列試験は全件成功し、公開ready 20/20、OOM・restart 0でした。CPU飽和後は同時数を増やしてもthroughputが伸びず、p95だけが799.099→5,839.193msへ悪化することも分かりました。

XServer VPSは高出力GPUの代用品ではなく、jobを保持し、workerの同時数を制御し、故障時にも証跡を残す司令塔として有効です。