vLLM本番APIサーバー運用：OpenAI互換・監視・負荷試験の実践

本番運用の要点

vLLMはvllm serveだけでOpenAI互換APIを起動できます。しかし本番では、モデルrevisionとコンテナを固定し、TLS・認証・流量制御を前段へ置き、TTFT・TPOT・queue・KV cacheを監視する構成が必要です。

基本の起動例

vllm serve Qwen/Qwen3.6-27B-FP8 \
  --host 127.0.0.1 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

モデル名や量子化は例です。--tensor-parallel-sizeは利用GPU数・モデル構造と合わせます。最大contextをモデル上限へ機械的に設定すると、KV cacheが増えて同時実行数が落ちるため、実際に必要な長さから始めます。

外部へ直接公開しない

Internet → Load Balancer / nginx → 127.0.0.1:8000 → vLLM

前段でTLS、API認証、IP制限、rate limit、request body上限、timeoutを設定します。ストリーミング応答を使う場合はproxy bufferingを無効化し、長い生成に合わせてread timeoutを調整します。

APIキーが設定できる構成でも、公開インターネットではWAFやgatewayを併用し、鍵のローテーションと利用量制限を持たせる方が安全です。

互換APIの確認

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model":"Qwen/Qwen3.6-27B-FP8",
    "messages":[{"role":"user","content":"3行で要約してください"}],
    "max_tokens":128
  }'

chat completionsが通っても、tool calling、structured output、reasoning parser、multimodal、Responses APIは別々に確認します。クライアントSDKが送るパラメータとvLLMの対応範囲も照合してください。

監視項目

層	見る項目	分かること
HTTP	2xx/4xx/5xx、timeout	利用ミスとサーバー障害
Latency	TTFT、TPOT、E2E p50/p95/p99	待ち時間と生成速度
Scheduler	running、waiting、queue time	過負荷と待ち行列
Cache	GPU/CPU KV cache、prefix hit	context容量と再利用効率
GPU	VRAM、utilization、power、温度	OOM予兆と計算資源の偏り

Prometheusのmetrics endpointとGPU exporterを組み合わせ、アプリ側のrequest IDで追跡できるようにします。ただしprompt本文のログ保存は、個人情報・機密情報の扱いを決めてから行います。

負荷試験

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --model Qwen/Qwen3.6-27B-FP8 \
  --dataset-name random \
  --num-prompts 1000 \
  --request-rate 8

random datasetだけでは実運用を再現できません。入力・出力長のp50/p95に近いデータ、共通prefixが多いデータ、画像あり、tool callありなどを分けて測ります。

容量計画

1. 単一リクエストでモデルが正しく動く構成を作る
2. 入力・出力長と同時実行の想定を作る
3. request rateを段階的に上げる
4. p95 TTFTが目標を超える直前を把握する
5. GPU追加、tensor/data parallel、replica追加を比較する

最大throughputだけでなくSLOを守れるrequest rateを採用します。短いリクエストと長いリクエストを別queueに分ける設計も有効です。

安全な更新

vLLM、PyTorch、CUDA、driver、model revisionはまとめて記録します。新versionは別環境で立ち上げ、golden prompts、tool call、負荷試験を通してから一部トラフィックを流します。v0.25.0ではMRv2標準化とlegacy attention削除があるため、最新変更の解説も確認してください。

よくある切り分け

• 起動時OOM: model length、GPU利用率、parallel設定、量子化を確認
• TTFT悪化: queue、長文prefill、request rateを見る
• TPOT悪化: batch、spec decode受理率、GPU間通信を見る
• JSONが崩れる: chat template、parser、structured output設定を確認
• 更新後だけ不具合: model revisionとrunner/backend差を固定して比較

まとめ

vLLM本番運用は、GPUを埋めることより、tail latencyと正しい出力を維持することが重要です。前段の保護、version固定、メトリクス、実データに近い負荷試験、段階更新を一つの運用手順にします。

公式資料

• OpenAI-Compatible Server
• vllm bench serve
• vLLM Metrics