vLLM クイックスタート: 2026年の高性能LLMサービング

OpenAI API を使用した高速な LLM 推論

目次

vLLM は、UC Berkeley の Sky Computing Lab が開発した、大規模言語モデル (LLM) 用の高スループットでメモリ効率の良い推論およびサービングエンジンです。

革新的な PagedAttention アルゴリズムにより、vLLM は伝統的なサービング方法と比較して 14～24 倍のスループットを実現しており、生産環境での LLM 配置に最適な選択肢です。Ollama、Docker Model Runner、LocalAI およびクラウドプロバイダー（コストやインフラストラクチャのトレードオフを含む）の中で vLLM がどのように位置づけられるかについては、LLM ホスティング: ローカル、セルフホストおよびクラウドインフラストラクチャの比較 をご覧ください。

vllm ロゴ

vLLM とは？

vLLM（バーチャル LLM）は、2023 年にリリースされた、生産性の高い LLM 推論およびサービング用のオープンソースライブラリです。PagedAttention という、サービス効率を大幅に向上させる画期的なメモリ管理技術を導入しました。

主な特徴

高スループット性能：同じハードウェアを使用して HuggingFace Transformers と比較して、vLLM は 14～24 倍のスループットを実現します。この大きな性能向上は、連続バッチ処理、最適化された CUDA カーネル、そしてメモリフラグメンテーションを排除する PagedAttention アルゴリズムによるものです。

OpenAI API との互換性：vLLM には OpenAI の形式と完全に互換性のある組み込み API サーバーが含まれており、アプリケーションコードを変更せずに OpenAI からセルフホストされたインフラストラクチャへのスムーズな移行が可能です。単に API クライアントを vLLM のエンドポイントに接続するだけで、透明に動作します。

PagedAttention アルゴリズム：vLLM の性能の核心的なイノベーションは、PagedAttention です。これは、バーチャルメモリページングの概念を注意機構に適用します。KV キャッシュ（フラグメンテーションを引き起こす）のために連続したメモリブロックを割り当てる代わりに、PagedAttention は固定サイズのブロックに分割して、オンデマンドで割り当てます。これにより、メモリの無駄を最大で 4 倍まで削減し、はるかに大きなバッチサイズを可能にします。

連続バッチ処理：静的なバッチ処理ではすべてのシーケンスが完了するのを待たなければなりませんが、vLLM は連続（ローリング）バッチ処理を使用します。1 つのシーケンスが終了するやいなや、新しいシーケンスをバッチに追加できます。これにより、GPU の利用率が最大化され、入力リクエストのレイテンシーが最小限に抑えられます。

マルチ GPU サポート：vLLM は、大規模なモデルを複数の GPU にわたって分散処理するためにテンソル並列およびパイプライン並列をサポートします。単一の GPU のメモリに収まらないモデルを効率的に処理し、2 から 8 個以上の GPU に対応しています。

広範なモデルサポート：LLaMA、Mistral、Mixtral、Qwen、Phi、Gemma など、人気のあるモデルアーキテクチャと互換性があります。HuggingFace Hub からインストラクション調整済みモデルおよびベースモデルの両方をサポートします。

vLLM を使用するべき場面

vLLM は、特定のシナリオにおいてその強みが際立つため、以下のような状況で特に優れています：

生産 API サービス：多くの同時ユーザーに LLM を API で提供する必要がある場合、vLLM の高スループットと効率的なバッチ処理により、最適な選択肢です。チャットボット、コードアシスタント、コンテンツ生成サービスを運営する会社は、1 秒あたり数百のリクエストを処理する能力から恩恵を受けます。

高同時性ワークロード：アプリケーションが多くの同時ユーザーがリクエストを送信している場合、vLLM の連続バッチ処理と PagedAttention により、同じハードウェアを使用してより多くのユーザーを処理することが可能です。

コスト最適化：GPU のコストが懸念されている場合、vLLM の優れたスループットにより、同じトラフィックを処理するために必要な GPU の数を減らすことができ、インフラストラクチャコストを直接削減できます。PagedAttention による 4 倍のメモリ効率により、より小さい、安価な GPU インスタンスを使用することが可能です。

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

vLLM を使用しないべき場面：ローカル開発、実験、または単一ユーザーのシナリオでは、Ollama のようなツールが、シンプルなセットアップでより良いユーザー体験を提供します。vLLM の複雑さは、生産ワークロードでその性能の利点が必要な場合に正当化されます。

vLLM のインストール方法

事前条件

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

  • GPU：NVIDIA GPU で、コンピュート能力 7.0 以上（V100、T4、A10、A100、H100、RTX 20/30/40 シリーズ）
  • 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 バージョンのシステムでは、適切なホイールをインストールしてください：

# 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 クイックスタートガイド

最初のモデルを実行する

コマンドラインインターフェースを使用してモデルを開始します：

# OpenAI 互換 API で Mistral-7B をダウンロードして実行
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)

チャットコンプリート 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：1 バッチで処理するシーケンス数の最大値。

vLLM と Ollama の比較

vLLM と Ollama は、ローカル LLM ホスティングのための人気のある選択肢ですが、異なる使用ケースを対象としています。それぞれのツールをどのタイミングで使用するかは、プロジェクトの成功に大きく影響します。

パフォーマンスとスループット

vLLM は、マルチユーザーのシナリオで最大のスループットを設計しています。PagedAttention と連続バッチ処理により、数百の同時リクエストを効率的に処理できます。ベンチマークでは、vLLM が標準実装よりも 14～24 倍のスループットを達成し、高同時性下では Ollama よりも 2～4 倍のスループットを実現しています。

Ollama は、単一ユーザーのインタラクティブな使用を最適化し、個々のリクエストに対する低レイテンシーに焦点を当てています。vLLM のマルチユーザーのスループットには及びませんが、開発および個人的な使用において優れたパフォーマンスを提供し、より速い冷起動時間とアイドル時のリソース消費量が低いです。

使いやすさ

Ollama はシンプルさで勝ります。インストールは単一のコマンド（curl | sh）で、モデルを実行するには ollama run llama2 だけです。クォンタイズされたバージョンを含むモデルライブラリを提供しており、さまざまなハードウェアプロファイルに最適化されています。ユーザー体験は Docker に似ており、プル、実行、完了するだけです。

vLLM は、Python 環境管理、CUDA のインストール、サービングパラメータの理解、および手動のモデル指定が必要です。学習曲線は急ですが、パフォーマンス最適化のための細かなコントロールを得られます。この複雑さは、生産デプロイメントでハードウェアから最大のパフォーマンスを引き出したい場合に正当化されます。

API と統合

vLLM は、既存アプリケーションで OpenAI の API を使用している場合に、即座に置き換え可能な OpenAI 互換の REST API を提供します。これは、クラウドプロバイダーからセルフホストされたインフラストラクチャへの生産サービスの移行時にコード変更なしで重要です。

Ollama は、シンプルな REST API と専用の Python/JavaScript ライブラリを提供しています。機能はありますが、OpenAI の形式を期待するアプリケーションとの統合にはコード変更が必要です。しかし、Ollama-OpenAI アダプターなどのコミュニティプロジェクトがこのギャップを埋めています。

メモリ管理

vLLM の PagedAttention アルゴリズムは、同時リクエストのメモリ効率に優れています。同じ VRAM で、ナーディブな実装よりも 2～4 倍多くの同時ユーザーを処理できます。これは、生産デプロイメントにおけるコスト削減に直接つながります。

Ollama は、単一ユーザーのシナリオに適したシンプルなメモリ管理を使用します。アクティビティに基づいてモデルのロード/アンロードを自動管理し、開発には便利ですが、高同時性の生産使用には最適ではありません。

マルチ GPU サポート

vLLM は、テンソル並列およびパイプライン並列のネイティブサポートにより、2～8 個以上の GPU にわたってモデルを効率的に分散処理します。これは、70B パラメータの LLM などの非常に大きなモデルを 1 つの GPU に収まらないようにするための必須条件です。

Ollama は現在、マルチ GPU サポートが限定的で、主に 1 つの GPU で動作します。これは、分散推論を必要とする非常に大きなモデルには不向きです。

使用ケースの推奨

vLLM を選ぶべき時：

  • 複数の同時ユーザーに API を提供する生産環境
  • クラウドデプロイメントにおけるリクエストあたりのコストを最適化する必要があるとき
  • Kubernetes やコンテナオーケストレーションプラットフォームで実行するとき
  • 既存のアプリケーションに OpenAI API 互換性が必要なとき
  • マルチ GPU サポートを必要とする大規模モデルを処理するとき
  • パフォーマンスとスループットが重要な要件であるとき

Ollama を選ぶべき時：

  • ローカル開発と実験
  • 単一ユーザーのインタラクティブ使用（個人アシスタント、チャットボット）
  • 速いプロトタイピングとモデル評価
  • LLM について学ぶためのインフラストラクチャの複雑さを気にしないとき
  • パーソナルワークステーションやノートPCで実行するとき
  • シンプルさと使いやすさが優先されるとき

多くのチームは両方を使用します：Ollama を開発と実験に、vLLM を生産デプロイに。これにより、開発者の生産性を維持しながら、生産パフォーマンスを確保できます。

vLLM と Docker Model Runner の比較

Docker は最近、Model Runner（以前は GenAI Stack）を、ローカル AI モデルデプロイの公式ソリューションとして導入しました。これは vLLM とどのように比較するのでしょうか？

アーキテクチャの哲学

Docker Model Runner は「AI 用の Docker」として設計されており、コンテナで 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/vll次に、vLLM サーバーを起動します。

パフォーマンス特性

vLLM は、PagedAttention と連続バッチ処理により、マルチユーザーのシナリオで優れたスループットを提供します。生産 API サービスが 1 秒あたり数百のリクエストを処理する必要がある場合、vLLM の最適化により、汎用的なサービングアプローチよりも 2～5 倍のスループットを達成します。

Docker Model Runner は、使いやすさに焦点を当てており、最大性能を提供するには最適ではありません。ローカル開発、テスト、中規模ワークロードには適していますが、vLLM がスケールで優れている先進的な最適化は実装していません。

モデルサポート

Docker Model Runner は、人気のあるモデルにワンコマンドでアクセスできるカレッタモデルライブラリを提供します。Stable Diffusion、Whisper、その他の AI モデルを含む複数のフレームワークをサポートしており、さまざまな AI ワークロードに適しています。

vLLM は、Transformer 基盤の言語モデルに深くサポートされている 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 デプロイメント：

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 ビット、4 ビット）を使用してメモリを削減し、スループットを増加させます：

--quantization awq  # AWQ クォンタイズされたモデル用
--quantization gptq # GPTQ クォンタイズされたモデル用

プレフィックスキャッシュの有効化：システムメッセージが含まれるチャットボットなどの繰り返しのプロンプトを持つアプリケーションで有効化します：

--enable-prefix-caching

これは、共通のプレフィックスを持つ KV 値をキャッシュし、同じプロンプトプレフィックスを持つリクエストの計算を減らします。

一般的な問題のトラブルシューティング

メモリ不足エラー

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

解決策：

  • --gpu-memory-utilization を 0.85 または 0.80 に減少させます
  • 使用ケースが許容する場合、--max-model-len を減少させます
  • --max-num-seqs を減少させ、バッチサイズを小さくします
  • クォンタイズされたモデルバージョンを使用します
  • テンソル並列を有効にして、より多くの GPU に分散させます

低スループット

症状：サーバーが予想より少ないリクエストを処理します。

解決策：

  • --max-num-seqs を増やして、より大きなバッチを許可します
  • ヘッドロームがある場合、--gpu-memory-utilization を増やします
  • htop で CPU がボトルネックになっているか確認します – より高速な CPU を検討してください
  • nvidia-smi で GPU 利用率を確認します – 95% 以上である必要があります
  • FP32 を使用している場合、--dtype float16 で FP16 を有効にします

最初のトークン時間が遅い

症状：生成が開始するまでのレイテンシーが高くなります。

解決策：

  • レイテンシーキャリッジが重要なアプリケーションでは、小さなモデルを使用します
  • 繰り返しのプロンプトでプレフィックスキャッシュを有効にします
  • --max-num-seqs を減少させて、レイテンシーを優先します
  • サポートされているモデルでは、スペキュレーティブデコードを使用します
  • テンソル並列の設定を最適化します

モデルロードの失敗

症状：サーバーが起動できず、モデルをロードできません。

解決策：

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

高度な機能

スペキュレーティブデコード

vLLM は、小さなドラフトモデルがトークンを提案し、大きなターゲットモデルが検証するスペキュレーティブデコードをサポートしています。これにより、生成速度が 1.5～2 倍加速します：

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"}
)

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

繰り返しのプロンプトプレフィックスを再計算しないように自動的にプレフィックスキャッシュを有効にします：

--enable-prefix-caching

これは特に有効な場面：

  • 固定システムプロンプトを持つチャットボット
  • 一貫したコンテキストテンプレートを持つ RAG アプリケーション
  • 複数のリクエストにわたって繰り返されるファインショット学習プロンプト

プレフィックスキャッシュは、プロンプトプレフィックスを共有するリクエストの最初のトークン時間の 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 の利点を示します：

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

  • vLLM：64 個の同時ユーザーで ~3,500 トークン/秒
  • HuggingFace Transformers：同じ同時ユーザーで ~250 トークン/秒
  • Ollama：同じ同時ユーザーで ~1,200 トークン/秒
  • 結果：vLLM は基本実装より 14 倍の改善を達成します

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

  • 標準実装：24GB VRAM、32 個の同時シーケンス
  • vLLM と PagedAttention：24GB VRAM、128 個の同時シーケンス
  • 結果：同じメモリで 4 倍多くの同時リクエストが可能です

負荷下のレイテンシー（Mixtral-8x7B、2 個の A100 上）：

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

これらのベンチマークは、vLLM がパフォーマンスが重要な生産 LLM サービングのデファクトスタンダードとなっている理由を示しています。

コスト分析

vLLM を選ぶ際のコストの影響を理解しましょう：

シナリオ：1 日 100 万リクエストの処理

標準サービングの場合：

  • 必要：8 個の A100 GPU（80GB）
  • AWS コスト：~$32/時間 × 24 × 30 = $23,040/月
  • 100 万トークンあたりのコスト：~$0.75

vLLM の場合：

  • 必要：2 個の 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 への移行

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

移行前（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"}]
)

移行後（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 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?"
)

コードベース全体の API 呼び出しを更新する必要がありますが、OpenAI クライアントライブラリはより良いエラーハンドリングと機能を提供します。

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 は、バッチ推論に際して HuggingFace よりもシンプルで遥かに高速です。

vLLM の将来

vLLM は、エキサイティングな機能が含まれる迅速な開発を続けています：

非集約型サービング：プレフィル（プロンプト処理）とデコード（トークン生成）を異なる GPU に分離してリソース利用率を最適化します。プレフィルは計算制限され、デコードはメモリ制限されるため、専用ハードウェアで実行して効率を向上させます。

マルチノード推論：100B パラメータ以上の非常に大きなモデルを複数のマシンに分散して処理し、単一ノードの設定では処理できないモデルを処理できます。

強化されたクォンタイゼーション：llama.cpp で使用される GGUF や、クォンタイズされたモデルでより良いパフォーマンスを提供する AWQ/GPTQ の改善された統合をサポートします。

スペキュレーティブデコードの改善：精度の損失なしに効率的なドラフトモデルと適応的なスペキュレーション戦略を使用して、より高い加速を実現します。

注意の最適化：FlashAttention 3、非常に長いコンテキスト（100K+ トークン）用のリング注意、およびその他の最先端の注意メカニズムをサポートします。

より良いモデルカバレッジ：マルチモーダルモデル（視覚言語モデル）、オーディオモデル、および専用アーキテクチャが登場するたびにサポートを拡張します。

vLLM プロジェクトは、UC Berkeley、Anyscale、およびオープンソースコミュニティからの活発な開発を維持しています。LLM デプロイメントが生産システムにとってより重要になるにつれて、vLLM のパフォーマンスの基準としての役割はますます大きくなります。 LLM ホスティング: ローカル、セルフホストおよびクラウドインフラストラクチャの比較](https://www.glukhov.org/ja/llm-hosting/ “2026 年の LLM ホスティングに関する完全ガイド。Ollama、vLLM、Docker Model Runner、LocalAI およびクラウドプロバイダーを比較し、コスト、パフォーマンス、インフラストラクチャのトレードオフを学びましょう。")。

有用なリンク

このサイトに関連する記事

  • ローカルLLMホスティング：2026年完全ガイド - Ollama, vLLM, LocalAI, Jan, LM Studio & その他 - Ollama, vLLM, LocalAI, Jan, LM Studioなど、12以上のローカルLLMホスティングツールの包括的比較。APIの成熟度、ツールコールサポート、GGUF互換性、性能ベンチマークを含み、正しいソリューションを選択するのに役立ちます。

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

  • Docker Model Runner vs Ollama：どちらを選ぶべきか？ - DockerのModel RunnerとOllamaをローカルLLMデプロイに使用する際の、パフォーマンス、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モデルハブ - vLLMと互換性のあるオープンソースLLMの包括的なリポジトリ。サイズ、タスク、ライセンス、パフォーマンス特性に基づいてモデルを検索し、使用ケースに最適なモデルを見つけることができます。

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

  • NVIDIA TensorRT-LLM - NVIDIAのTensorRT-LLMは、NVIDIA GPU上で非常に最適化された推論を提供します。vLLMとは異なる最適化戦略を採用しており、比較や推論最適化の全体像を理解する際に役立ちます。

  • OpenAI APIリファレンス - vLLMのAPIと互換性のある公式OpenAI APIドキュメント。OpenAIと自社ホストされたvLLMエンドポイントの両方と連携して動作するアプリケーションを開発する際のリファレンスとして使用してください。