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

OpenAI API を活用した高速 LLM 推論

目次

vLLM は、UC Berkeley の Sky Computing Lab によって開発された、大規模言語モデル（LLM）向けの高速スループットかつメモリエフィレントな推論およびサーバーエンジンです。

革命的な PagedAttention アルゴリズムを採用している vLLM は、従来のサービング方法と比較して 14〜24 倍のスループットを実現し、本番環境での LLM 導入における事実上の標準となっています。vLLM が Ollama、Docker Model Runner、LocalAI、およびクラウドプロバイダー（コストとインフラのトレードオフを含む）の中でどのように位置するかについては、LLM ホスティング：ローカル、セルフホスト、クラウドインフラの比較をご覧ください。

vllm ロゴ

vLLM とは何か？

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

主要な特徴

高いスループット性能: vLLM は、同じハードウェアを使用した場合、HuggingFace Transformers と比較して 14〜24 倍の高いスループットを提供します。この劇的なパフォーマンス向上は、連続バッチ処理、最適化された CUDA カーネル、およびメモリ断片化を排除する PagedAttention アルゴリズムによって実現されています。

OpenAI API 互換性: vLLM には、OpenAI の形式と完全に互換性のあるビルトイン API サーバーが含まれています。これにより、アプリケーションコードを変更せずに、OpenAI からセルフホスト環境へのシームレスな移行が可能になります。API クライアントを vLLM のエンドポイントに指すだけで、透明性を持って動作します。

PagedAttention アルゴリズム: vLLM のパフォーマンスの核心にある革新は、PagedAttention です。これは仮想メモリページングの概念をアテンションメカニズムに適用したものです。KV キャッシュ（Key-Value Cache）に対して連続的なメモリブロックを割り当てる（これが断片化を引き起こす）のではなく、PagedAttention はメモリを固定サイズのブロックに分割し、オンデマンドで割り当てることができます。これにより、メモリの無駄を最大 4 倍削減し、はるかに大きなバッチサイズを可能にします。

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

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

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

vLLM を使用するタイミング

vLLM は、その強みが光る特定シナリオで特に優れた結果を出します。

本番環境 API サービス: 多くの同時ユーザーに API を介して LLM を提供する場合、vLLM の高いスループットと効率的なバッチ処理が最適な選択です。チャットボット、コードアシスタント、またはコンテンツ生成サービスを実行している企業は、1 秒間に数百のリクエストを処理できる能力から恩恵を受けます。

高同時負荷ワークロード: アプリケーションで多数の同時ユーザーがリクエストを行う場合、vLLM の連続バッチ処理と PagedAttention により、代替手段と比較して同じハードウェアでより多くのユーザーをサービングできます。

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

Kubernetes 展開: vLLM のステートレス設計とコンテナフレンドリーなアーキテクチャは、Kubernetes クラスターに理想的です。負荷時の一貫したパフォーマンスと straightforward なリソース管理は、クラウドネイティブインフラとよく統合されます。

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

vLLM のインストール方法

前提条件

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

  • GPU: 計算能力 7.0 以上の NVIDIA GPU（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 クイックスタートガイド

最初のモデルの実行

コマンドラインインターフェースを使用して、モデルで 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": "vLLM とは何かを一文で説明してください:",
        "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="vLLM とは何かを一文で説明してください:",
    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": "あなたは役立つアシスタントです。"},
        {"role": "user", "content": "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 vs 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 互換の REST API をデフォルトで提供するため、既存アプリケーションにおける OpenAI API のドロップイン代替となります。これは、コード変更なしで本番環境サービスをクラウドプロバイダーからセルフホストインフラへ移行する際に不可欠です。

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

メモリ管理

vLLM の PagedAttention アルゴリズムは、同時リクエストに対して優れたメモリエフィシアンスを提供します。同じ VRAM で、素直な実装と比較して 2〜4 倍の同時ユーザーをサービングできます。これは、本番環境の展開におけるコスト削減に直接つながります。

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

マルチ GPU サポート

vLLM は、ネイティブのテンソル並列処理およびパイプライン並列処理で優れており、2〜8 以上の GPU にわたってモデルを効率的に分散できます。これは、単一の GPU に収まらない 70B パラメータのような大規模 LLM をサービングする際に不可欠です。

Ollama は、現在のところマルチ GPU サポートが限られており、主に単一の GPU で最もよく機能します。これにより、分散推論を必要とする非常に大規模なモデルには適さなくなります。

ユースケース推奨事項

vLLM を選ぶ場合:

  • 多くの同時ユーザーによる本番環境 API サービング
  • クラウド展開における 1 件のリクエストあたりのコスト最適化
  • Kubernetes またはコンテナオーケストレーションプラットフォームでの実行
  • 既存アプリケーションのための OpenAI API 互換性の必要性
  • マルチ GPU サポートを必要とする大規模モデルのサービング
  • パフォーマンスとスループットが重要な要件である場合

Ollama を選ぶ場合:

  • ローカル開発および実験
  • 単一ユーザーの対話的使用（個人用アシスタント、チャットボット）
  • 迅速なプロトタイピングおよびモデル評価
  • インフラの複雑さなしに LLM を学ぶ
  • 個人のワークステーションやラップトップでの実行
  • シンプルさと使いやすさが優先事項である場合

多くのチームは両方を使用します：開発と実験には Ollama を、本番環境の展開には vLLM を使用します。この組み合わせにより、開発者の生産性を維持しながら、本番環境のパフォーマンスを確保できます。

vLLM vs Docker Model Runner の比較

Docker は最近、ローカル AI モデルデプロイのための公式ソリューションとして Model Runner（旧 GenAI Stack）を導入しました。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/vllm-openai:latest --model <model-name>

パフォーマンス特性

vLLM は、PagedAttention と連続バッチ処理により、マルチユーザーシナリオで優れたスループットを提供します。1 秒間に数百のリクエストを処理する本番環境 API サービスの場合、vLLM の最適化は、一般的なサービングアプローチよりも 2〜5 倍優れたスループットを提供します。

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

モデルサポート

Docker Model Runner は、ワンコマンドアクセスで人気のあるモデルを含む厳選されたモデルライブラリを提供します。Stable Diffusion、Whisper、およびその他の AI モデルなど、LLM だけでなく複数のフレームワークをサポートし、異なる 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 ビット、4 ビット）を使用してメモリを削減し、スループットを増加させます。

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

プレフィックスキャッシングの有効化: システムメッセージを備えたチャットボットなど、繰り返しのプロンプトがあるアプリケーションの場合、プレフィックスキャッシングを有効にします。

--enable-prefix-caching

これは、共通のプレフィックスを持つリクエストに対して計算を削減します。

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

メモリ不足エラー

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

解決策:

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

低いスループット

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

解決策:

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

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

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

解決策:

  • レイテンシクリティカルなアプリケーションには、より小さなモデルを使用する
  • 繰り返しのプロンプトにはプレフィックスキャッシングを有効にする
  • スループットよりもレイテンシを優先するために --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="これを SQL に変換してください：今月作成されたすべてのユーザーを表示"
)

マルチ LoRA サービング

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

# 特定の LoRA アダプターでリクエスト
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "SQL クエリを書く"}],
    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("PagedAttention を簡単な言葉で説明してください")
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("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 人の同時ユーザーで約 3,500 トークン/秒
  • HuggingFace Transformers: 同じ同時負荷で約 250 トークン/秒
  • Ollama: 同じ同時負荷で約 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 を選択することのコストの影響を理解します。

シナリオ：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="レート制限超過")
    
    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 への移行は簡単です。

移行前（OpenAI）:

from openai import OpenAI

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

移行後（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": "こんにちは"}]
)

必要な変更は base_url と model 名の更新のみです。他のすべてのコードは同一のままです。

Ollama から vLLM へ

Ollama は異なる API 形式を使用します。以下に変換方法を示します。

Ollama API:

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={
        'model': 'llama2',
        'prompt': 'なぜ空は青いのですか？'
    })

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="なぜ空は青いのですか？"
)

コードベース全体で 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 は、バッチ推論のために単純で、はるかに高速です。

vLLM の未来

vLLM は、ロードマップ上のエキサイティングな機能で急速な開発を続けています。

分散サービング: プリフェル（プロンプト処理）とデコード（トークン生成）を異なる GPU に分離して、リソース利用率を最適化します。プリフェルは計算バウンド、デコードはメモリバウンドであるため、特殊なハードウェアで実行することで効率が向上します。

マルチノード推論: 非常に大規模なモデル（100B+ パラメータ）を複数のマシンに分散し、単一ノードセットアップでは大きすぎるモデルをサービング可能にします。

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

スペキュレイティブデコーディングの改善: より効率的なドラフトモデルと適応的推測戦略により、精度の損失なしに高いスピードアップを達成します。

アテンション最適化: FlashAttention 3、非常に長いコンテキスト（100K+ トークン）のためのリングアテンション、およびその他の最先端のアテンションメカニズム。

より良いモデルカバレッジ: 多モーダルモデル（ビジョン言語モデル）、音声モデル、およびそれらが発生する専門アーキテクチャへのサポートの拡大。

vLLM プロジェクトは、UC Berkeley、Anyscale、および広範なオープンソースコミュニティからの貢献により、アクティブな開発を維持しています。LLM デプロイが本番システムにとってより重要になるにつれて、パフォーマンス標準としての vLLM の役割は成長し続けています。

ローカルおよびクラウド LLM インフラストラクチャとの vLLM のより広い比較については、LLM ホスティング：ローカル、セルフホスト、クラウドインフラの比較をご覧ください。

便利なリンク

サイト内の関連記事

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

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

  • CLI およびサーバーを使用した llama.cpp クイックスタート - llama-cli と OpenAI 互換 llama-server を備えた軽量 C/C++ 推論。Python なしで最小スタック、オフラインデプロイ、または細かい制御を必要とする場合に理想的です。

  • Docker Model Runner vs Ollama：どちらを選ぶべきか？ - ローカル LLM デプロイのための Docker の Model Runner と Ollama の詳細な比較で、パフォーマンス、GPU サポート、API 互換性、およびユースケースを分析します。vLLM が動作する競争環境を理解するのに役立ちます。

  • Docker Model Runner チートシート：コマンドと例 - Docker の公式 LLM ツールでローカルに 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 フレームワークドキュメント。Ray は、自動スケーリング、マルチモデルサービング、および本番環境システムのリソース管理などの高度な機能を提供します。

  • NVIDIA TensorRT-LLM - NVIDIA GPU 上で高度に最適化された推論のための NVIDIA の TensorRT-LLM。異なる最適化戦略を備えた vLLM の代替案であり、推論最適化の風景を理解するために有益です。

  • OpenAI API リファレンス - vLLM の API が互換性を持つ公式 OpenAI API ドキュメント。OpenAI とセルフホスト vLLM エンドポイントを相互に動作させる必要があるアプリケーションを構築する際に参照します。