vLLMでオープンLLMをセルフホスト推論する本番運用ガイド【2026年版】
クラウドAPIのコストが月数十万円を超えてきたとき、あるいは社内データを外部に送れないセキュリティ要件を突きつけられたとき、「自前のGPUでLLMを動かす」という選択肢を本気で検討し始めるエンジニアは多い。vLLMは、そのセルフホスト推論の実質的なデファクトスタンダードだ。PagedAttentionとcontinuous batchingによる高スループット、OpenAI互換APIサーバとしてのすぐ使える設計、そしてLlama・Qwen・Mistralといった主要オープンウェイトモデルの広い対応範囲が三拍子揃っている。この記事では、vLLMを使ってオープンLLMをセルフホストし、本番環境で安定稼働させるまでの実装手順と最適化ポイントを、コードと設定例を交えながら解説する。
結論：vLLMはPagedAttentionとcontinuous batchingで同等GPUで3〜5倍のトークンスループットを実現し、OpenAI互換APIサーバとして即座に既存コードベースへ組み込める。
- 要点1：pip install vllm → vllm serve <model> の2行でOpenAI互換推論サーバが立ち上がる。既存の openai SDK コードは変更不要
- 要点2：GPUメモリ見積りは「パラメータ数 × 精度バイト数 ÷ 0.8」が基準。AWQ量子化でLlama-3 70BのVRAM要件を140GB→35GBに削減可能
- 要点3：本番運用には /metrics（Prometheus互換）と /health エンドポイントを活用し、KVキャッシュ使用率・TTFT p99・リクエストキュー深さをアラートに設定する
対象読者：オープンLLMをGPUサーバで動かしたいMLエンジニア・インフラエンジニア。クラウドAPIコスト削減やデータ主権を確保したい開発チームのリード
今日やること：nvidia-smi でGPUのVRAM容量を確認し、pip install vllm で環境構築してモデルの起動を試す
なぜセルフホストか——API課金 vs GPUコスト、データ主権、レイテンシ
「セルフホストは面倒」という印象が先行しがちだが、スケールすればするほどコスト構造が逆転することが多い。APIと自前GPU、どちらが得かを判断するには、まず損益分岐の考え方を理解しておく必要がある。
コスト構造の比較
マネージドAPIの場合、料金は入出力トークン量に比例する。一方GPUサーバの場合、固定費（GPU代またはクラウドGPUインスタンス料金）がかかる代わり、追加のトークン消費ではコストが増えない。月間トークン使用量が一定を超えると、GPUが有利になる。
損益分岐点の考え方（想定シナリオ）：
- API課金: 1Mトークン当たり数ドル〜数十ドル（モデル・プロバイダーによって大きく異なる）
- クラウドGPUインスタンス: A100 80GB 1枚で月数十万円〜（オンデマンド）。スポットや予約で大幅削減可能
- 自社保有GPU: 初期投資は大きいが、長期で見ると月間消費が多いほどROIが高まる
ただし、「GPU代 < API代」が成立するかは使用量・モデル・GPU調達方法によって変わる。設備投資の回収期間や運用コスト（エンジニアの工数）も込みで計算する必要がある。単純にAPIコストと比べるだけでなく、インフラ管理の人的コストも加味した総コストで判断してほしい。
データ主権とコンプライアンス
金融・医療・法務領域では、未公開情報や個人情報をサードパーティのAPIに送ることを社内ポリシーや規制が禁止している場合がある。セルフホストであれば、推論時のデータは自社ネットワーク内に留まる。これはコスト以上に意思決定の決め手になるケースも多い。
レイテンシとカスタマイズ性
社内ネットワーク内でのリクエストは、インターネット越しのAPI呼び出しに比べてネットワークレイテンシが小さい。また、モデルの重みに直接アクセスできるため、量子化・LoRAアダプタの差し込み・プロンプトキャッシュの制御など、マネージドAPIでは不可能な細かい最適化が可能になる。
# 事前チェック: GPUの状態とVRAM容量を確認
nvidia-smi
# Expected output: GPU名, VRAM容量(例: 80GB / A100), 現在の使用状況
vLLMの仕組み——PagedAttentionとcontinuous batchingがスループットを変える
vLLMがなぜ高スループットを実現できるのかを理解しておくと、後述するチューニングの意味がより明確になる。中核は2つの技術、PagedAttentionとcontinuous batchingだ。
PagedAttentionとKVキャッシュ管理
LLM推論では、シーケンスが長くなるほどKVキャッシュ（Key-Valueキャッシュ）がVRAMを食う。従来の実装ではシーケンスに対して連続したメモリ領域を確保するため、未使用のVRAMが生まれやすかった。PagedAttentionはOSの仮想メモリ管理に着想を得て、KVキャッシュを固定サイズの「ページ」に分割し、非連続なメモリ領域を組み合わせて使える設計にした。この工夫でKVキャッシュの断片化を解消し、VRAMの無駄を最大55%削減できることが論文（SOSP 2023）で示されている（Efficient Memory Management for Large Language Model Serving with PagedAttention）。
Continuous Batching
従来のスタティックバッチングでは、バッチ内の全リクエストが終わるまで次のリクエストをキューに待機させる必要があった。Continuous batching（別名iteration-level scheduling）は、各デコードステップごとに完了したシーケンスを取り出し、新しいリクエストをすぐ埋め込む。これにより、GPUを遊ばせる時間が大幅に減る。同等のGPU構成でnative PyTorchの推論ループと比べて3〜5倍のスループット向上が報告されている（Spheron: LLM Serving Optimization on H100）。
実測値の目安（環境依存）
以下は公開されているベンチマーク値の参考例。環境・モデル・リクエストパターンによって変動するため、自分の環境での測定値を基準にすること。
| GPU | モデル | スループット目安 | 出典・条件 |
|---|---|---|---|
| A100 80GB | Llama 2 7B | 〜2,500 tokens/s | batch throughput（easecloud.io 2026） |
| A100 80GB | Llama 2 13B | 〜800 tokens/s | 同上 |
| H100 SXM5 | Llama 3.3 70B FP8 | 2,200〜2,400 tokens/s | 128+ concurrent requests（Spheron 2026） |
あくまで参考値だが、これらはNative PyTorchループの3〜4倍にあたることを念頭に置いてほしい。
セットアップ実装——インストールから最初のAPIリクエストまで
実際に手を動かしてみよう。前提となる環境は以下の通り。
動作環境：Python 3.10以上、CUDA 12.1以上、NVIDIA GPU（最低8GB VRAM推奨）、vllm 0.8.x系（2026年6月時点）
# Step 1: vLLMをインストール
pip install vllm
# Step 2: OpenAI互換APIサーバとして起動
# --model にHugging Faceのモデル名 or ローカルパスを指定
vllm serve meta-llama/Llama-3.2-3B-Instruct \
--host 0.0.0.0 \
--port 8000
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください
# Llama系モデルはHugging Face Hubのアクセス権が必要。事前にhf-cli loginを実行
起動すると、デフォルトで http://localhost:8000/v1 にOpenAI互換のエンドポイントが立ち上がる。
# curlでエンドポイントを確認
curl http://localhost:8000/v1/models
# チャット推論のリクエスト例
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "meta-llama/Llama-3.2-3B-Instruct",
"messages": [
{"role": "user", "content": "Pythonでフィボナッチ数列を生成するコードを書いてください"}
],
"max_tokens": 512,
"temperature": 0.7
}'
openai Pythonライブラリからも同様に使える。エンドポイントをvLLMサーバのURLに向けるだけで、既存コードをほぼそのまま流用できる点がvLLMの大きなメリットだ。
from openai import OpenAI
# vLLMをOpenAI互換サーバとして使う
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="dummy" # vLLMはデフォルトで認証不要（本番では--api-keyで設定）
)
response = client.chat.completions.create(
model="meta-llama/Llama-3.2-3B-Instruct",
messages=[
{"role": "user", "content": "このコードをレビューしてください: def add(a, b): return a + b"}
],
max_tokens=256,
stream=False
)
print(response.choices[0].message.content)
ポイントは、base_url を書き換えるだけで既存のOpenAI APIクライアントコードがそのまま動くことだ。本番移行時のコード変更コストが最小で済む。ストリーミングレスポンスの実装については、LLMエージェントのストリーミングSSE実装ガイドも参考にしてほしい。
GPUメモリ見積りと主要パラメータの調整
「どのGPUで何Bのモデルが動くか」はセルフホストの最初の壁だ。計算の基本を理解しておこう。
重みのVRAM使用量の計算
モデルの重みが占めるVRAMは以下の式で概算できる（実際には補正が必要）：
重みのVRAM (GB) ≈ パラメータ数 (B) × 精度バイト数
精度ごとのバイト数:
- FP32 (32bit): 4 bytes/param → 70B × 4 = 280 GB
- BF16/FP16 (16bit): 2 bytes/param → 70B × 2 = 140 GB
- INT8: 1 byte/param → 70B × 1 = 70 GB
- INT4/AWQ: 0.5 bytes/param → 70B × 0.5 = 35 GB
重みに加えてKVキャッシュと活性化メモリが必要。
--gpu-memory-utilization 0.9 の場合、重み + KVキャッシュで GPU VRAM × 0.9 に収める必要がある
つまりBF16のLlama 3 70Bを動かすには140GB VRAM（A100 80GB × 2枚以上）が必要になる。これがAWQ量子化（実質INT4相当）なら35GBまで削減でき、A100 40GB 1枚でも動作する（VRLA Tech: LLM Quantization 2026）。
key フラグの意味と調整方法
vllm serve meta-llama/Meta-Llama-3-70B-Instruct \
--gpu-memory-utilization 0.85 \ # GPU VRAM の85%を使用（デフォルト0.92）
--max-model-len 8192 \ # コンテキスト長の上限（デフォルトはモデル依存）
--tensor-parallel-size 4 \ # 4枚のGPUでテンソル並列
--quantization awq # AWQ量子化を使用（awq/gptq/fp8のいずれか）
--gpu-memory-utilization は0〜1の値で、デフォルトは0.92。高くするほどKVキャッシュに割り当てられるVRAMが増えてスループットが上がるが、OOMのリスクも高まる。実際の運用では0.85〜0.90から始めて徐々に調整するのが無難だ。
--max-model-len はプロンプト＋出力の合計トークン数の上限。モデルのサポートする最大コンテキスト長と、実際のユースケースの最大入力長のうち、より小さい値を設定するとよい。長すぎるとKVキャッシュが大量のVRAMを消費する。
OOMが出たときのトラブルシュート
# OOM発生時の確認手順
# 1. VRAMの実際の使用状況を確認
nvidia-smi --query-gpu=memory.used,memory.free,memory.total --format=csv
# 2. max-model-lenを小さく調整してみる
vllm serve <model> --max-model-len 4096
# 3. gpu-memory-utilizationを下げる
vllm serve <model> --gpu-memory-utilization 0.8
# 4. それでもOOMが出る場合は量子化を検討
vllm serve <model> --quantization fp8
量子化——AWQ/GPTQ/FP8でVRAMを削減するトレードオフ
量子化はVRAM使用量を削減しつつ、スループットを向上させる手段だが、品質とのトレードオフがある。vLLMが対応している主要な量子化手法を理解して適切に使い分けよう。
3つの量子化手法の特性比較
| 手法 | 精度 | VRAM削減 | 速度向上 | 品質劣化 | 推奨用途 |
|---|---|---|---|---|---|
| AWQ | INT4相当 | 〜75%削減 | 高い | 小さい | VRAMが厳しい本番環境 |
| GPTQ | INT4相当 | 〜75%削減 | 中程度 | 小さい | コミュニティモデルとの互換性 |
| FP8 | 8bit浮動小数点 | 〜50%削減 | 高い（H100最適） | 非常に小さい | H100環境・品質最優先 |
量子化の影響についての注意：vLLM/GPUStack公開データによると、AWQでLlama 2 70BのVRAMは140GB → 35GBに削減。FP8はモデルメモリを約50%削減し、スループットを最大1.6倍改善するとされているが、実際の劣化度合いはモデルとタスクによって異なる（GPUStack: Impact of Quantization on vLLM）。
量子化済みモデルの使い方
# AWQ量子化済みモデルを使う（Hugging Face上の量子化バリアント）
# Qwen2.5-72B-Instruct-AWQ などのモデルをそのまま指定
vllm serve Qwen/Qwen2.5-72B-Instruct-AWQ \
--quantization awq \
--max-model-len 16384
# GPTQ量子化モデルの例
vllm serve TheBloke/Mistral-7B-Instruct-v0.2-GPTQ \
--quantization gptq
# FP8量子化（H100での推論に最適。その他のGPUではソフトウェアシミュレーション）
vllm serve meta-llama/Meta-Llama-3.1-70B-Instruct \
--quantization fp8 \
--gpu-memory-utilization 0.9
# 注意: GPTQモデルはモデル名に quantization タイプが含まれることが多い
# 量子化手法とモデルが一致しているか確認すること
コミュニティから提供されているAWQ・GPTQモデルは品質が確認しやすいメリットがあるが、公式モデルと完全に同じ挙動を保証するものではない。重要な用途では自社でファインチューニング or 量子化したモデルを使うことを推奨する。
KVキャッシュのFP8量子化
# KVキャッシュもFP8にしてVRAMをさらに節約
vllm serve <model> \
--kv-cache-dtype fp8 \
--quantization fp8
# FP8 KVキャッシュはメモリを約50%削減するとされている
スループット最適化——テンソル並列、投機的デコード、バッチングチューニング
セットアップが完了したら、スループットを最大化するための最適化に入ろう。
テンソル並列（複数GPU）
大きなモデルを複数のGPUに分散させる、あるいはスループット向上のために複数GPUを使うには --tensor-parallel-size を指定する。
# 4枚のGPUで70Bモデルを動かす例
vllm serve meta-llama/Meta-Llama-3.1-70B-Instruct \
--tensor-parallel-size 4 \
--gpu-memory-utilization 0.9
# GPU 0〜3が使われる。CUDA_VISIBLE_DEVICES で制御可能
CUDA_VISIBLE_DEVICES=0,1,2,3 vllm serve <model> --tensor-parallel-size 4
# ポイント: tensor-parallel-sizeはGPU数の約数である必要がある
# 3枚のGPUで --tensor-parallel-size 4 は動かない
複数ノードにまたがる場合はpipeline parallelismも使えるが、ネットワーク帯域がボトルネックになりやすい。まずは1ノード内のテンソル並列から始めることを推奨する。
投機的デコード（Speculative Decoding）
投機的デコードは、小さなドラフトモデルで複数トークンをまとめて予測し、大きなメインモデルで一括検証することで、低同時接続数のシナリオでレイテンシを改善する手法だ。ドラフトモデルの承認率が0.7以上の場合、1.3〜2倍のスピードアップが報告されている。
# メインモデル: Llama 3.1 70B
# ドラフトモデル: 同じアーキテクチャの小さなモデル (8B) で投機的デコード
vllm serve meta-llama/Meta-Llama-3.1-70B-Instruct \
--speculative-model meta-llama/Meta-Llama-3.1-8B-Instruct \
--num-speculative-tokens 5 \
--tensor-parallel-size 4
# num-speculative-tokensは一度に投機するトークン数
# 大きすぎると検証コストが上がるため3〜5が現実的
# 注意: 投機的デコードはバッチサイズが小さい（1〜4リクエスト程度）場合に効果が高い
バッチングとコンカレンシーの調整
# 最大バッチサイズの制御
vllm serve <model> \
--max-num-seqs 256 \ # 同時処理するシーケンスの最大数（デフォルト256）
--max-num-batched-tokens 8192 # 1バッチで処理するトークン数の上限
# ストリーミングを大量に使う場合は max-num-seqs を大きめに
# レイテンシ重視なら max-num-seqs を小さくしてキャッシュヒット率を上げる
本番運用——ヘルスチェック、メトリクス、複数モデルの管理
起動できたら終わりではない。本番運用で安定稼働させるためのモニタリングと管理の仕組みを整えよう。
ヘルスチェックエンドポイント
# ヘルスチェック（HTTP 200なら稼働中）
curl -s -o /dev/null -w "%{http_code}" http://localhost:8000/health
# 200 が返れば正常
# モデル一覧の確認
curl http://localhost:8000/v1/models
Kubernetes環境では、これをlivenessProbeとreadinessProbeに設定する。
# Kubernetes Pod設定例（抜粋）
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 60
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 30
periodSeconds: 5
Prometheusメトリクスと監視
vLLMは /metrics エンドポイントでPrometheus互換のメトリクスを公開している。本番監視に欠かせないキーメトリクスは以下の通り（vLLM公式ドキュメント: Metrics）：
| メトリクス名 | 種類 | 意味 | アラートの目安 |
|---|---|---|---|
| vllm:num_requests_running | Gauge | 現在処理中のリクエスト数 | 上限の80%以上で警告 |
| vllm:num_requests_waiting | Gauge | キュー待ちのリクエスト数 | 10以上で警告 |
| vllm:kv_cache_usage_perc | Gauge | KVキャッシュの使用率（0〜1） | 0.95以上でアラート |
| vllm:time_to_first_token_seconds | Histogram | 最初のトークンが返るまでの時間（TTFT） | SLA閾値を超えたらアラート |
| vllm:generation_tokens_total | Counter | 生成トークンの累計数 | コスト管理・使用量追跡に活用 |
# Prometheusでのスクレイプ設定例（prometheus.yml）
scrape_configs:
- job_name: 'vllm'
static_configs:
- targets: ['<vllm-host>:8000']
metrics_path: '/metrics'
scrape_interval: 15s
Grafanaで vllm:kv_cache_usage_perc と vllm:num_requests_waiting を並べたダッシュボードを作ると、ボトルネックがKVキャッシュ不足なのか、GPU演算能力不足なのかを素早く判断できる。
APIキーによる認証設定
# 本番環境では必ず --api-key を設定
vllm serve <model> \
--api-key "your-secure-api-key-here" \
--host 0.0.0.0 \
--port 8000
# クライアント側の呼び出し
curl http://<server>:8000/v1/chat/completions \
-H "Authorization: Bearer your-secure-api-key-here" \
-H "Content-Type: application/json" \
-d '{...}'
複数モデルの管理と切り替え
複数のモデルを用途別に使い分けたい場合、vLLMインスタンスを複数起動してポートを分けるのが現実的だ。ルーティングはリバースプロキシ（nginx / Envoy）で制御できる。また、OpenAI互換ルーターとしてOpenRouter的なマルチモデルゲートウェイの概念をセルフホスト環境に持ち込む設計も有効だ。
# モデルAを8000番ポートで起動
vllm serve meta-llama/Llama-3.2-3B-Instruct --port 8000 &
# モデルBを8001番ポートで起動
vllm serve Qwen/Qwen2.5-72B-Instruct-AWQ --port 8001 --quantization awq &
# nginxで /v1/small → 8000, /v1/large → 8001 にルーティング
# upstream設定でロードバランシングも可能
Dockerでのデプロイ
# vLLM公式のDockerイメージを使ったデプロイ
docker run --gpus all \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-p 8000:8000 \
--ipc=host \
vllm/vllm-openai:latest \
--model meta-llama/Llama-3.2-3B-Instruct \
--gpu-memory-utilization 0.9
# --ipc=host はshared memoryのパフォーマンスのため推奨
# --gpus all で全GPUを使う。特定GPUなら --gpus device=0,1 のように指定
vLLM vs Ollama vs TGI——用途別の使い分け
LLMセルフホストの選択肢はvLLMだけではない。2026年時点での主要ツールの立ち位置を整理しておこう。
主要3ツールの比較表
| 比較軸 | vLLM | Ollama | TGI（Hugging Face） |
|---|---|---|---|
| スループット（高同時接続） | 最高（PagedAttention + continuous batching） | 低い | 中程度 |
| セットアップの簡単さ | 中程度 | 非常に簡単（1コマンド） | 中程度 |
| OpenAI互換API | あり（標準） | あり | あり |
| 量子化サポート | AWQ/GPTQ/FP8/GGUF等 | GGUF中心 | GPTQ/FP8等 |
| 開発・メンテ状況（2026年6月） | 活発 | 活発 | 2025年12月からメンテナンスモードに移行 |
| GPU要件 | NVIDIA/AMD GPU必須（実用的には16GB VRAM以上） | CPU動作可、GPU選択可 | NVIDIA GPU推奨 |
| 推奨シナリオ | 本番マルチユーザー/高スループット | ローカル開発/個人利用 | 既存TGIユーザーの継続利用 |
特筆すべきは、Hugging FaceのTGIが2025年12月以降メンテナンスモードへ移行した点だ（機能追加なし、バグ修正のみ）。2026年に新規でセルフホスト構成を構築するなら、vLLMかSGLangを選ぶのが現実的な選択だ（Build with Matija: vLLM vs Ollama vs TGI）。
用途別の選択指針
- 本番マルチユーザーシステム（数十〜数百同時リクエスト）: vLLMを選ぶ。スループット差は大きく、10同時接続でvLLMが800 tokens/s vs Ollamaが150 tokens/s程度の差が報告されている
- ローカル開発・個人利用・チームのプロトタイプ: Ollamaが最も手軽。1コマンドでモデルをダウンロードして動かせる
- 既存TGI運用環境: 直ちに移行する必要はないが、次のメジャーアップデートでvLLMやSGLangへの移行を検討する
AIエージェントシステムのデプロイ全体像（推論サーバ以外のコンポーネントも含む）については、AIエージェント本番デプロイ・サービング完全ガイドを参照してほしい。
よくある失敗パターンと回避策
失敗1：VRAMを過小評価してOOMが頻発する
「重みのサイズ = 必要なVRAM」と思って起動したら即OOM、というケースが多い。重みの他にKVキャッシュと活性化メモリが必要で、実際に必要なVRAMは重みサイズの1.3〜1.5倍程度になることが多い。
回避策: --gpu-memory-utilization 0.8 から始めて、安定稼働を確認しながら0.85→0.9と上げていく。また --max-model-len を実際のユースケースで必要な長さに制限することでKVキャッシュのピーク使用量を抑えられる。
失敗2：量子化モデルを選ばずに最初から動かせないと諦める
手元のGPUでBF16のモデルが動かないからといってセルフホストを諦めている場合、AWQやGPTQの量子化済みモデルで試してみていただきたい。Llama・Qwen・MistralはHugging Face Hub上に公式・コミュニティ提供の量子化済みバリアントが多数存在する。
回避策: モデル名に -AWQ や -GPTQ がついているバリアントを使い、対応する --quantization フラグを指定する。
失敗3：モニタリングを入れずに本番投入してブラックボックスになる
起動してAPIレスポンスが返ってきたので本番公開した結果、トラフィックが増えたときに何がボトルネックかわからずレイテンシが急上昇、というパターン。vLLMの /metrics エンドポイントはデフォルトで有効だが、Prometheusのスクレイプ設定とGrafanaのダッシュボードを最初から整備しておく価値は大きい。
回避策: 最低でも vllm:kv_cache_usage_perc と vllm:num_requests_waiting の2つをアラートに入れること。KVキャッシュが常に90%以上なら --gpu-memory-utilization を上げるか、--max-model-len を短くするサインだ。
失敗4：tensor-parallel-sizeをGPU数と一致させない
--tensor-parallel-size 4 を指定したのにGPUが3枚しかない、あるいはCUDA_VISIBLE_DEVICESで制限してGPUが2枚しか見えていない、という状態で起動すると即エラーになる。
回避策: nvidia-smiで認識されているGPU数を確認してから、その数の約数でtensor-parallel-sizeを設定する。
FAQ
Q. vLLMはWindowsで動きますか？
A. 公式にはLinux（CUDA環境）をサポートの主対象としています。2026年6月時点でWindowsネイティブのサポートは限定的です。WSL2（Windows Subsystem for Linux）＋CUDA環境であれば動作するケースがありますが、本番用途ではLinuxマシンまたはLinuxコンテナ（Docker）の使用を強く推奨します。
Q. Hugging Faceのモデルをダウンロードせずにローカルのモデルを使えますか？
A. 使えます。--model フラグにローカルのモデルディレクトリへの絶対パスを指定するだけです（例：vllm serve /data/models/llama3-70b）。モデルはHugging Faceの safetensors または pytorch_model.bin 形式に対応しています。
Q. vLLMでLoRAファインチューニング済みモデルは使えますか？
A. 使えます。--enable-lora フラグで有効にし、リクエスト時に使用するLoRAアダプタを指定できます。複数のLoRAアダプタを1つのベースモデルに対してリクエストごとに切り替えることも可能です。詳細はvLLM公式ドキュメントのLoRAセクションを確認してください。
Q. コスト削減の見積もりはどうすればよいですか？
A. 月間トークン使用量（入力＋出力の合計）をAPIプロバイダーの料金で計算した金額と、GPUサーバの月額コスト（クラウドGPUインスタンス料金またはオンプレのGPU償却＋電力コスト）を比較してください。運用エンジニアの工数もコストとして計上することを忘れないでください。単純な料金比較だけでなく、トータルコストで判断することが重要です。
Q. vLLM 0.8系と0.6系で設定の互換性はありますか？
A. 一部のフラグ名が変更・追加されているため、バージョンアップ時は公式のChangelog（github.com/vllm-project/vllm）を確認することを推奨します。特に量子化関連のフラグはバージョン間で変更が入りやすいです。
Q. AMD GPUでもvLLMは使えますか？
A. ROCm（AMD GPUのCUDA相当環境）をサポートしています。ただし、NVIDIA GPU向けと比べて対応機能が限定される場合があります。2026年6月時点での詳細な対応状況は公式ドキュメントのROCmセクションを確認してください。
まとめ：今日から始める3つのアクション
- 今日やること:
nvidia-smiでGPUのVRAM容量を確認し、「パラメータ数 × 精度バイト数」で動かしたいモデルの必要VRAMを概算する。pip install vllmして小さめのモデル（7B〜14B程度）で起動テストする - 今週中: OpenAI互換APIサーバとして動かし、既存のコードで
base_urlを差し替えてリクエストが通ることを確認する。Prometheusの/metricsエンドポイントをスクレイプしてGrafanaで基本ダッシュボードを作る - 今月中: 本番想定の同時接続数でベンチマークを取り、GPUコストとAPIコストの損益分岐を自社数値で計算する。AWQ量子化での品質比較を行い、本番へのロールアウト計画を立てる
あわせて読みたい:
- AIエージェント本番デプロイ・サービング完全ガイド — 推論サーバ以外のコンポーネント（ルーティング、ロードバランシング、スケーリング）を含む全体設計
- OpenRouterでマルチモデルゲートウェイを構築するコスト最適化ガイド — マネージドのマルチモデルゲートウェイとセルフホストの使い分け
参考・出典
- vLLM公式ドキュメント: vllm serve コマンドリファレンス — vllm-project（参照日: 2026-06-07）
- vLLM公式ドキュメント: Metrics（Prometheusエンドポイント） — vllm-project（参照日: 2026-06-07）
- Efficient Memory Management for Large Language Model Serving with PagedAttention — ACM SOSP 2023（原著論文）
- LLM Serving Optimization: Continuous Batching, PagedAttention on H100 — Spheron 2026（参照日: 2026-06-07）
- The Impact of Quantization on vLLM Inference Performance — GPUStack 2026（参照日: 2026-06-07）
- vLLM vs Ollama vs TGI: LLM Inference Engine の選び方 — Build with Matija（参照日: 2026-06-07）
この記事を読んでセルフホスト推論の全体像が見えてきた方へ
UravationではオープンLLMの自社環境構築からAIエージェント活用まで、エンジニアリングとビジネス両面の研修・コンサルを行っています。GPUインフラの選定から本番運用の最適化まで、チームの状況に合わせてサポートします。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書累計3万部突破。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
