vLLMクイックスタート：高パフォーマンスLLMサービング - 2026年

OpenAI APIによる高速LLM推論

目次

vLLM は、UC Berkeley の Sky Computing Lab が開発した、大規模言語モデル（LLM）のための高スループットかつメモリ効率に優れた推論およびサービングエンジンです。

革新的な PagedAttention アルゴリズムにより、vLLM は従来のサービング方法と比較して 14〜24 倍のスループットを実現しており、本番環境での LLM デプロイメントにおける第一候補のツールとなっています。 Ollama、Docker Model Runner、LocalAI やクラウドプロバイダーとの比較において、コストとインフラストラクチャのトレードオフを含め、vLLM がどのように位置づけられるのかを確認するには、LLM ホスティング：ローカル、セルフホスト、クラウドインフラストラクチャの比較 を参照してください。

vllm logo

vLLM とは？

vLLM（virtual LLM）は、迅速に本番デプロイメントの業界標準となった、LLM の高速推論とサービングのためのオープンソースライブラリです。2023年にリリースされ、サービングの効率を劇的に向上させた画期的なメモリ管理技術である PagedAttention を導入しました。

主な機能

高スループットのパフォーマンス: vLLM は、同じハードウェア環境における HuggingFace Transformers と比較して 14〜24 倍のスループットを実現します。この大きなパフォーマンス向上は、コンティニュアスバッチング、最適化された CUDA カーネル、そしてメモリフラグメンテーションを解消する PagedAttention アルゴリズムによるものです。

OpenAI API 互換性: vLLM には、OpenAI の形式と完全互換性のある組み込み API サーバーが搭載されています。これにより、アプリケーションコードを変更することなく、OpenAI からセルフホスト環境へのシームレスな移行が可能になります。API クライアントのターゲットを vLLM のエンドポイントに向ければ、透明に動作します。

PagedAttention アルゴリズム: vLLM のパフォーマンスを支える中核的な革新は PagedAttention です。これは、仮想メモリのページングの概念をアテンション機構に適用します。KV キャッシュに対して連続的なメモリブロックを割り当てる（これによりフラグメンテーションが引き起こされる）代わりに、PagedAttention はメモリを固定サイズのブロックに分割し、オンデマンドで割り当てを行います。これにより、メモリ waste が最大で 4 倍に削減され、はるかに大きなバッチサイズが可能になります。

コンティニュアスバッチング: すべてのシーケンスが完了するまで待つ静的バッチングと異なり、vLLM はコンティニュアス（ローリング）バッチングを使用します。あるシーケンスが完了するとすぐに、新しいシーケンスがバッチに追加できます。これにより、GPU の使用率が最大化され、新規リクエストのレイテンシが最小限に抑えられます。

マルチGPU対応: vLLM は、大きなモデルを複数の GPU に分散させるためのテンソル並列とパイプライン並列をサポートしています。単一の GPU のメモリには収まらないモデルも効率的にサービングでき、2 つから 8 個以上の GPU の構成をサポートしています。

幅広いモデル対応: LLaMA、Mistral、Mixtral、Qwen、Phi、Gemma などの人気のあるモデルアーキテクチャと互換性があります。HuggingFace Hub から、指示チューニング済みモデルとベースモデルの両方をサポートしています。

vLLM を使用すべき場面

vLLM は、その強みが光る特定のシナリオで特に優れています：

本番 API サービス: API を介して多くの並行ユーザーに LLM を提供する必要のある場合、vLLM の高スループットと効率的なバッチングにより、最善の選択肢となります。チャットボット、コードアシスタント、コンテンツ生成サービスなどを行う企業は、毎秒数百件のリクエストを処理できる能力から恩恵を受けます。

高並行ワークロード: アプリケーションに多数の同時接続ユーザーがリクエストを送信する場合、vLLM のコンティニュアスバッチングと PagedAttention により、他のソリューションよりも同じハードウェアで多くのユーザーをサービングできます。

コスト最適化: GPU コストが課題である場合、vLLM の優れたスループットにより、より少ない GPU で同じトラフィックをサービングでき、インフラストラクチャコストを直接削減できます。PagedAttention による 4 倍のメモリ効率により、より小さく安価な GPU インスタンスの使用も可能になります。

Kubernetes デプロイメント: vLLM のステートレス設計とコンテナフレンドリーなアーキテクチャは、Kubernetes クラスタに適しています。負荷下での一貫したパフォーマンスと、直感的なリソース管理により、クラウドネイティブインフラストラクチャとよく統合されます。

vLLM を使用すべきではない場合: ローカル開発、実験、またはシングルユーザーのシナリオでは、Ollama や llama.cpp のようなツールの方が、よりシンプルなセットアップと良いユーザーエクスペリエンスを提供します。vLLM の複雑さは、本番ワークロードのパフォーマンス利点が必要となった場合に正当化されます。

vLLM のインストール方法

前提条件

vLLM をインストールする前に、システムが以下の要件を満たしていることを確認してください：

  • GPU: 計算能力 7.0 以上（V100, T4, A10, A100, H100, RTX 20/30/40 シリーズ）の NVIDIA GPU
  • CUDA: バージョン 11.8 以降
  • Python: 3.8 から 3.11
  • VRAM: 7B モデルには最低 16GB、13B モデルには 24GB 以上、より大きなモデルには 40GB 以上
  • ドライバ: NVIDIA ドライバ 450.80.02 以降

pip によるインストール

最もシンプルなインストール方法は pip を使用することです。CUDA 11.8 以降のシステムで動作します：

# 仮想環境を作成（推奨）
python3 -m venv vllm-env
source vllm-env/bin/activate

# vLLM をインストール
pip install vllm

# インストールを確認
python -c "import vllm; print(vllm.__version__)"

異なる CUDA バージョンのシステムでは、適切な wheel をインストールします：

# CUDA 12.1 の場合
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# CUDA 11.8 の場合
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

Docker によるインストール

Docker は、特に本番環境において最も信頼できるデプロイ方法です：

# 公式の vLLM イメージを取得
docker pull vllm/vllm-openai:latest

# GPU サポートで vLLM を実行
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

--ipc=host フラグは、プロセス間の適切な通信を可能にするため、マルチGPU構成において重要です。

ソースからのビルド

最新の機能やカスタマイズが必要な場合は、ソースからビルドします：

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

vLLM クイックスタートガイド

最初のモデルの実行

コマンドラインインターフェースを使用して、モデルを指定して vLLM を起動します：

# Mistral-7B をダウンロードして、OpenAI 互換 API でサービング
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM は自動的に HuggingFace Hub からモデルをダウンロードします（キャッシュされていない場合）、そしてサーバーを起動します。サーバーが準備できていることを示す出力が表示されます：

INFO:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000

API リクエストの送信

サーバーが起動したら、OpenAI Python クライアントまたは curl を使用してリクエストを送信できます：

curl の使用例:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Explain what vLLM is in one sentence:",
        "max_tokens": 100,
        "temperature": 0.7
    }'

OpenAI Python クライアントの使用例:

from openai import OpenAI

# vLLM サーバーを指す
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM はデフォルトでは認証を必要としません
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Explain what vLLM is in one sentence:",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

Chat Completions API:

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "What is PagedAttention?"}
    ],
    max_tokens=200
)

print(response.choices[0].message.content)

高度な設定

vLLM はパフォーマンスを最適化するための多くのパラメータを提供します：

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # GPU メモリの 95% を使用
    --max-model-len 8192 \            # 最大シーケンス長
    --tensor-parallel-size 2 \        # テンソル並列で 2 つの GPU を使用
    --dtype float16 \                 # FP16 精度を使用
    --max-num-seqs 256                # 最大バッチサイズ

主要パラメータの説明:

  • --gpu-memory-utilization: 使用する GPU メモリ量（0.90 = 90%）。高い値を設定するとより大きなバッチが可能ですが、メモリ急増時の余裕が減ります。
  • --max-model-len: 最大コンテキスト長。これを小さくすると、より大きなバッチのためにメモリが解放されます。
  • --tensor-parallel-size: モデルを分割して使用する GPU の数。
  • --dtype: 重みのデータ型（float16、bfloat16、または float32）。通常 FP16 が最適です。
  • --max-num-seqs: バッチ内で処理するシーケンスの最大数。

vLLM と Ollama の比較

vLLM は、コンティニュアスバッチング、PagedAttention、マルチGPU サポートにより、高スループットなマルチユーザーの本番サービングのために設計されています。一方、Ollama は、迅速なローカルセットアップ、シングルユーザーの利便性、およびシンプルなモデル管理を最適化しています。

移行シグナル、計画ステップ、Docker Compose の設定、実用的なチェックリストを含む詳細な決定ガイドについては、Ollama から vLLM へ：ローカル LLM サーバーを移行すべき時 を参照してください。

vLLM と Docker Model Runner の比較

Docker は最近、ローカル AI モデルデプロイメントの公式ソリューションとして Model Runner（旧称 GenAI Stack）を導入しました。vLLM と比べてどのような違いがあるのでしょうか？

アーキテクチャの哲学

Docker Model Runner は「AI のための Docker」であることを目指しています。コンテナを実行するのと同じ ease で、ローカルで AI モデルを動かすためのシンプルで標準化された方法を提供します。複雑さを抽象化し、異なるモデルやフレームワーク間で一貫したインターフェースを提供します。

vLLM は、最大のパフォーマンスでの LLM サービングにのみ焦点を当てた専門的な推論エンジンです。これは完全なプラットフォームではなく、Docker でコンテナ化するローレベルのツールです。

セットアップと始め方

Docker Model Runner のインストールは、Docker ユーザーにとって簡単です：

docker model pull llama3:8b
docker model run llama3:8b

この Docker イメージワークフローとの類似性は、すでにコンテナを使用している開発者にとって直感的に馴染み深いものです。

vLLM は、より多くの初期セットアップ（Python、CUDA、依存関係）が必要ですが、事前構築済みの Docker イメージの使用も可能です：

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <model-name>

パフォーマンス特性

vLLM は、PagedAttention とコンティニュアスバッチングにより、マルチユーザーシナリオで優れたスループットを実現します。毎秒数百件のリクエストを処理する本番 API サービスにおいて、vLLM の最適化は、汎用のサービングアプローチよりも 2〜5 倍優れたスループットを提供します。

Docker Model Runner は、最大のパフォーマンスよりも使いやすさに焦点を当てています。ローカル開発、テスト、中程度のワークロードに適していますが、vLLM が規模拡大に優れるための高度な最適化は実装されていません。

モデルサポート

Docker Model Runner は、人気のあるモデルへのワンコマンドアクセスを提供する厳選されたモデルライブラリを持っています。LLM だけでなく、Stable Diffusion、Whisper など他の AI モデルを含む複数のフレームワークをサポートしており、さまざまな AI ワークロードにより多機能です。

vLLM は、トランスフォーマーベースの言語モデルへの深いサポートを持つ LLM 推論に特化しています。HuggingFace 互換の LLM なら何でもサポートしますが、画像生成や音声認識のような他の AI モデルタイプには拡張されていません。

本番デプロイメント

vLLM は、Anthropic、Replicate などの企業で本番環境において実績があり、毎日数十億のトークンをサービングしています。そのパフォーマンス特性と高負荷下での安定性により、本番 LLM サービングの事実上の標準となっています。

Docker Model Runner は比較的新しく、開発やローカルテストのシナリオにより向いている位置づけです。本番トラフィックをサービングすることは可能ですが、本番デプロイメントに必要な実績とパフォーマンス最適化が不足しています。

統合エコシステム

vLLM は、本番インフラストラクチャツールと統合できます：Kubernetes オペレーター、Prometheus メトリクス、分散サービングのための Ray、既存のアプリケーション向けの広範な OpenAI API 互換性。

Docker Model Runner は、Docker エコシステムや Docker Desktop と自然に統合されます。すでに Docker に標準化しているチームにとっては、統合的なエクスペリエンスを提供しますが、専門的な LLM サービング機能は少ないです。

それぞれの最適な使用場面

vLLM を使用するべき場合:

  • 本番 LLM API サービス
  • 高スループット、マルチユーザーのデプロイメント
  • 最大の効率が必要なコスト重視のクラウドデプロイメント
  • Kubernetes やクラウドネイティブ環境
  • 実証されたスケーラビリティとパフォーマンスが必要な場合

Docker Model Runner を使用するべき場合:

  • ローカル開発とテスト
  • さまざまな AI モデルタイプ（LLM 以外を含む）の実行
  • Docker エコシステムに深く投資しているチーム
  • インフラストラクチャ設定なしの迅速な実験
  • 学習や教育目的

ハイブリッドアプローチ: 多くのチームは、利便性のためにローカルで Docker Model Runner を使って開発し、パフォーマンスのために本番環境では vLLM をデプロイします。Docker Model Runner イメージを使用して vLLM コンテナを実行することも可能であり、両方のアプローチを組み合わせられます。

本番デプロイメントのベストプラクティス

Docker デプロイメント

本番環境対応の Docker Compose 設定を作成します：

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Kubernetes デプロイメント

本番スケールで Kubernetes に vLLM をデプロイします：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

モニタリングとオブザーバビリティ

vLLM は、監視のために Prometheus メトリクスを公開します：

import requests

# メトリクスを取得
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

監視すべき主要なメトリクス：

  • vllm:num_requests_running - アクティブなリクエスト数
  • vllm:gpu_cache_usage_perc - KV キャッシュ使用率
  • vllm:time_to_first_token - レイテンシ指標
  • vllm:time_per_output_token - 生成速度

パフォーマンスチューニング

GPU メモリ利用量の最適化: --gpu-memory-utilization 0.90 から始めて、観察された挙動に基づいて調整してください。高い値を設定するとより大きなバッチが可能になりますが、トラフィック急増時に OOM エラーのリスクがあります。

最大シーケンス長の調整: ユースケースで完全なコンテキスト長が必要でない場合は、--max-model-len を減らしてください。これにより、より大きなバッチのためのメモリが解放されます。例えば、4K コンテキストのみが必要な場合、モデルの最大値（通常 8K〜32K）を使用する代わりに --max-model-len 4096 を設定します。

適切な量子化の選択: サポートされているモデルの場合、量子化されたバージョン（8-bit、4-bit）を使用し、メモリを削減しスループットを向上させます：

--quantization awq  # AWQ 量子化モデルの場合
--quantization gptq # GPTQ 量子化モデルの場合

プレフィックスキャッシュの有効化: 繰り返されるプロンプト（システムメッセージ付きチャットボットなど）があるアプリケーションでは、プレフィックスキャッシュを有効にします：

--enable-prefix-caching

これにより、共通のプレフィックスの KV 値がキャッシュされ、同じプロンプトプレフィックスを共有するリクエストの計算が削減されます。

よくある問題のトラブルシューティング

メモリ不足エラー（OOM）

症状: サーバーが CUDA メモリ不足エラーでクラッシュする。

解決策:

  • --gpu-memory-utilization を 0.85 または 0.80 に削減する
  • ユースケースが許可する場合は --max-model-len を減らす
  • バッチサイズを縮小するために --max-num-seqs を下げる
  • 量子化モデルバージョンを使用する
  • より多くの GPU に分散するためにテンソル並列を有効にする

16 GB の単一カードでは、これらの OOM エラーの多くは、重みのみではなく KV キャッシュの予算に起因しています — 16 GB GPU での KV キャッシュ は、より小さいモデルに頼る前に、--max-model-len と --max-num-seqs の背後にある正確な数式、FP8 KV キャッシュ dtype、およびプレフィックスキャッシュのトレードオフを解説しています。

スループットが低い

症状: サーバーが期待以上に少ないリクエストしか処理できない。

解決策:

  • より大きなバッチを許可するために --max-num-seqs を増やす
  • 余裕がある場合は --gpu-memory-utilization を上げる
  • htop で CPU がボトルネックになっていないか確認する – より高速な CPU を検討する
  • nvidia-smi で GPU 使用率を確認する – 95% 以上であるべきです
  • FP32 を使用している場合は FP16 を有効にする：--dtype float16

最初のトークンが遅い

症状: 生成開始前に高いレイテンシがある。

解決策:

  • レイテンシクリティカルなアプリケーションではより小さいモデルを使用する
  • 繰り返されるプロンプトのためにプレフィックスキャッシュを有効にする
  • スループットよりレイテンシを優先するために --max-num-seqs を減らす
  • サポートされているモデルでは投機的デコーディングを検討する
  • テンソル並列の設定を最適化する

モデル読み込みの失敗

症状: サーバーが起動せず、モデルを読み込めない。

解決策:

  • モデル名が HuggingFace の形式と完全に一致していることを確認する
  • HuggingFace Hub へのネットワーク接続を確認する
  • ~/.cache/huggingface に十分なディスク容量があることを確認する
  • ゲート付きモデルの場合、HF_TOKEN 環境変数を設定する
  • huggingface-cli download <model> を使用して手動ダウンロードを試みる

高度な機能

投機的デコーディング（Speculative Decoding）

vLLM は投機的デコーディングをサポートしています。これは、小さいドラフトモデルがトークンを提案し、大きいターゲットモデルが検証する手法です。これにより、生成速度が 1.5〜2 倍に加速できる場合があります。投機的デコーディング方法に関する包括的なガイド（ドラフトモデル、EAGLE-3、P-EAGLE、n-gram）については、投機的デコーディング：品質低下なしでより高速な推論 を参照してください。

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

LoRA アダプター

複数のフルモデルを読み込むことなく、ベースモデルの上に複数の LoRA アダプターをサービングできます：

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

リクエストごとに使用したいアダプターを指定します：

response = client.completions.create(
    model="sql-lora",  # SQL アダプターを使用
    prompt="Convert this to SQL: Show me all users created this month"
)

マルチ LoRA サービング

vLLM のマルチ LoRA サービングにより、最小のメモリオーバーヘッドで数十のファインチューニングされたアダプターをホストできます。これは、顧客固有のタスクやタスク固有のモデルバリアントをサービングするのに適しています：

# 特定の LoRA アダプターでのリクエスト
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Write SQL query"}],
    extra_body={"lora_name": "sql-lora"}
)

プレフィックスキャッシュ

自動プレフィックスキャッシュを有効にすることで、繰り返されるプロンプトプレフィックスの KV キャッシュ再計算を回避します：

--enable-prefix-caching

これらは特に以下で効果的です：

  • 固定のシステムプロンプトを持つチャットボット
  • 一貫したコンテキストテンプレートを持つ RAG アプリケーション
  • リクエスト間で繰り返される Few-shot 学習プロンプト

プレフィックスキャッシュにより、プロンプトプレフィックスを共有するリクエストの最初のトークンまでの時間が 50〜80% 削減できる場合があります。

統合の例

LangChain 統合

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Explain PagedAttention in simple terms")
print(response)

LlamaIndex 統合

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("What is vLLM?")
print(response)

FastAPI アプリケーション

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

パフォーマンスベンチマーク

実世界のパフォーマンスデータは、vLLM の利点を示すのに役立ちます：

スループット比較（A100 GPU 上の Mistral-7B）：

  • vLLM: 64 並行ユーザーで 1 秒あたり約 3,500 トークン
  • HuggingFace Transformers: 同じ並行数で 1 秒あたり約 250 トークン
  • Ollama: 同じ並行数で 1 秒あたり約 1,200 トークン
  • 結果: vLLM は基本的な実装と比較して 14 倍の改善を提供

メモリ効率（LLaMA-2-13B）：

  • 標準実装: 24GB VRAM、32 並行シーケンス
  • PagedAttention 付き vLLM: 24GB VRAM、128 並行シーケンス
  • 結果: 同じメモリで 4 倍の並行リクエスト

負荷下でのレイテンシ（2xA100 上の Mixtral-8x7B）：

  • vLLM: 100 req/s で P50 レイテンシ 180ms、P99 レイテンシ 420ms
  • 標準サービング: 100 req/s で P50 レイテンシ 650ms、P99 レイテンシ 3,200ms
  • 結果: vLLM は高負荷下で一貫したレイテンシを維持

これらのベンチマークは、パフォーマンスが重要な本番 LLM サービングにおいて、vLLM が事実上の標準となった理由を示しています。

コスト分析

vLLM を選択することのコスト影響を理解する：

シナリオ：1日 100 万リクエストのサービング

標準サービングの場合:

  • 必要数: 8x A100 GPU (80GB)
  • AWS コスト: 約 $32/時間 × 24 × 30 = 月 $23,040
  • 100 万トークンあたりのコスト: 約 $0.75

vLLM を使用する場合:

  • 必要数: 2x A100 GPU (80GB)
  • AWS コスト: 約 $8/時間 × 24 × 30 = 月 $5,760
  • 100 万トークンあたりのコスト: 約 $0.19
  • 節約額: 月 $17,280（75% の削減）

このコスト上の優位性は、スケールと共に拡大します。毎月数十億のトークンをサービングする組織は、vLLM の最適化されたサービングを使用することで、素朴な実装と比較して数十万ドルを節約します。

セキュリティ上の考慮事項

認証

vLLM はデフォルトで認証を含んでいません。本番環境では、リバースプロキシレベルで認証を実装してください：

# Nginx 設定
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

または、エンタープライズグレードの認証とレート制限のために、Kong、Traefik、AWS API Gateway などの API ゲートウェイを使用します。

ネットワーク分離

vLLM は、インターネットに直接公開せず、プライベートネットワーク内で実行してください：

# Kubernetes NetworkPolicy の例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

レート制限

乱用を防ぐためにレート制限を実装します：

# Redis を使用したレート制限の例
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # 60 秒ウィンドウ
    
    if requests > 60:  # 1 分あたり 60 リクエスト
        raise HTTPException(status_code=429, detail="Rate limit exceeded")
    
    return await call_next(request)

モデルアクセス制御

マルチテナントデプロイメントでは、どのユーザーがどのモデルにアクセスできるかを制御します：

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # 全モデル
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

移行ガイド

OpenAI から vLLM へ

API の互換性により、OpenAI からセルフホストの vLLM への移行は簡単です：

Before（OpenAI）:

from openai import OpenAI

client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "Hello"}]
)

After（vLLM）:

from openai import OpenAI

client = OpenAI(
    base_url="https://your-vllm-server.com/v1",
    api_key="your-internal-key"  # 認証を追加した 경우
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Hello"}]
)

必要なのは 2 つの変更だけです：base_url と model 名の更新です。その他のコードはすべて同一のままです。

Ollama から vLLM へ

Ollama は異なる API 形式を使用しています。基本的なクライアント側の変更は、Ollama の REST エンドポイントから vLLM の OpenAI 互換 API に切り替えることです：

Ollama API:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={'model': 'llama2', 'prompt': 'Why is the sky blue?'})

vLLM 同等:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="Why is the sky blue?"
)

モデル選択、チャットテンプレート、段階的な移行、実用的なチェックリストを含む徹底的な移行ガイドについては、Ollama から vLLM へ：ローカル LLM サーバーを移行すべき時 を参照してください。

HuggingFace Transformers から vLLM へ

直接 Python 使用の移行：

HuggingFace:

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("Hello", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM:

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("Hello", sampling_params)
result = outputs[0].outputs[0].text

vLLM の Python API は、バッチ推論に対してよりシンプルで、はるかに高速です。

vLLM の将来

vLLM は、ロードマップに魅力的な機能があり、急速な開発が続いています：

分離型サービング（Disaggregated Serving）: プロンプト処理（prefill）とトークン生成（decode）を異なる GPU に分離して、リソース利用効率を最適化します。Prefill は計算リソースが制約となり、Decode はメモリが制約となるため、専用ハードウェア上で実行することで効率が高まります。

マルチノード推論: 非常に大きなモデル（100B パラメータ以上）を複数のマシンに分散させ、単一ノード構成では収まらないモデルのサービングを可能にします。

量子化の強化: GGUF（llama.cppで使用）などの新しい量子化フォーマットのサポートと、量子化モデルのパフォーマンス向上のための改良された AWQ/GPTQ 統合。

投機的デコーディングの改善: 精度の低下なしにより高い速度向上を達成するための、より効率的なドラフトモデルと適応的な投機戦略。

アテンションの最適化: FlashAttention 3、極端に長いコンテキスト（100K+ トークン）のためのリングアテンション、その他の最先端のアテンション機構。

より良いモデルカバレッジ: 多モーダルモデル（ビジョン・言語モデル）、音声モデル、専門的なアーキテクチャへのサポート拡大。

vLLM プロジェクトは、UC Berkeley、Anyscale、および広範なオープンソースコミュニティからの貢献により、活発な開発を維持しています。LLM のデプロイメントが本番システムにとってより重要になるにつれ、パフォーマンス標準としての vLLM の役割はますます大きくなっています。 vLLM と他のローカルおよびクラウド LLM インフラストラクチャのより広範な比較については、私たちの LLM ホスティング：ローカル、セルフホスト、クラウドインフラストラクチャの比較 をご覧ください。

役立つリンク

当サイト内の関連記事

  • ローカル LLM ホスティング：2026 年完全ガイド - Ollama、vLLM、LocalAI、Jan、LM Studio など - Ollama、LocalAI、Jan、LM Studio などを含む 12 つ以上のローカル LLM ホスティングツールの包括的な比較。vLLM の詳細な分析と並行して、API の成熟度、ツール呼び出しサポート、GGUF 互換性、パフォーマンスベンチマークをカバーし、最適なソリューションの選択を助けます。

  • Ollama チートシート - インストール、モデル管理、API の使用、ローカル LLM デプロイメントのベストプラクティスをカバーする完全な Ollama コマンドリファレンスおよびチートシート。Ollama を vLLM と並行して、または vLLM の代わりに使用する開発者にとって必須です。

  • llama.cpp クイックスタート（CLI およびサーバー付き） - llama-cli と OpenAI 互換 llama-server を備えた GGUF モデルの軽量な C/C++ 推論。細粒度の制御、オフラインデプロイ、または Python なしのミニマルスタックが必要な場合に最適です。

  • Docker Model Runner vs Ollama: どちらを選ぶべきか？ - ローカル LLM デプロイメントにおける Docker の Model Runner と Ollama の詳細な比較。パフォーマンス、GPU サポート、API 互換性、使用例を分析します。vLLM が存在する競争環境を理解するのに役立ちます。

  • Docker Model Runner チートシート：コマンドと例 - AI モデルデプロイメントのためのコマンドと例を含む実用的な Docker Model Runner チートシート。Docker のアプローチを vLLM の専門的な LLM サービング能力と比較するチームに有用です。

外部リソースとドキュメンテーション

  • vLLM GitHub リポジトリ - 公式 vLLM リポジトリ。ソースコード、包括的なドキュメンテーション、インストールガイド、活発なコミュニティディスカッションを含む。最新機能や問題解決に追いつくための必須リソースです。

  • vLLM ドキュメンテーション - 基本的なセットアップから高度な設定まで、vLLM のあらゆる側面をカバーする公式ドキュメンテーション。API リファレンス、パフォーマンスチューニングガイド、デプロイメントのベストプラクティスを含みます。

  • PagedAttention 論文 - vLLM の効率を支える PagedAttention アルゴリズムを紹介する学術論文。vLLM のパフォーマンス優位性の背後にある技術革新を理解するために必須の読み物です。

  • vLLM ブログ - 公式 vLLM ブログ。リリース告知、パフォーマンスベンチマーク、技術的深掘り、本番デプロイメントからのコミュニティケーススタディを特徴としています。

  • HuggingFace Model Hub - vLLM で動作するオープンソース LLM の包括的なリポジトリ。サイズ、タスク、ライセンス、パフォーマンス特性によってモデルを検索し、ユースケースに最適なモデルを見つけます。

  • Ray Serve ドキュメンテーション - スケーラブルで分散された vLLM デプロイメントを構築するための Ray Serve フレームワークのドキュメンテーション。Ray は、オートスケーリング、マルチモデルサービング、本番システムのリソース管理などの高度な機能を提供します。

  • NVIDIA TensorRT-LLM - NVIDIA による TensorRT-LLM。NVIDIA GPU 上での高度に最適化された推論。異なる最適化戦略を持つ vLLM の代替手段として、推論最適化の風景を理解するための比較に役立ちます。

  • OpenAI API リファレンス - vLLM の API が互換性を持つ公式 OpenAI API ドキュメンテーション。OpenAI とセルフホスト vLLM エンドポイントの両方で動作するアプリケーションを構築する際に参照してください。

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。