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

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

目次

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

革命的なPagedAttentionアルゴリズムにより、vLLMは伝統的なサービング方法と比較して14〜24倍のスループットを実現し、生産環境でのLLMデプロイメントのための最適な選択肢となっています。

vllm logo

什么是vLLM？

vLLM（仮想LLM）は、2023年にリリースされた、高速なLLM推論およびサービング用のオープンソースライブラリで、生産環境デプロイメントの業界標準となっています。PagedAttentionという、サービス効率を劇的に改善する画期的なメモリ管理技術を導入しました。

主な特徴

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

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

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

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

マルチGPUサポート：vLLMは、複数のGPUにわたって大規模モデルを分散処理するためのテンソル並列性およびパイプライン並列性をサポートしています。1つの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クイックスタートガイド

最初のモデルの実行

コマンドラインインターフェースを使用して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 \  # 95%のGPUメモリを使用
    --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にわたってモデルを効率的に分散します。これは、単一のGPUのメモリに収まらないような70BパラメータのLLMをサービスするための必須条件です。

Ollamaは現在、マルチGPUサポートが限られており、主に単一GPUで動作します。これは、分散推論が必要な非常に大きなモデルには不向きです。

使用ケースの推奨

vLLMを選択する場合：

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

Ollamaを選択する場合：

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

多くのチームは両方を使用します：Ollamaで開発と実験を行い、vLLMで生産デプロイメントを行います。この組み合わせは、開発者の生産性を維持しながら、生産パフォーマンスを確保します。

vLLMとDockerモデルランナーの比較

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

アーキテクチャの哲学

Dockerモデルランナーは「AIのためのDocker」として設計されており、コンテナでAIモデルをローカルで簡単に実行できるようにすることを目指しています。モデルやフレームワークに関係なく、一貫したインターフェースを提供します。

vLLMは、LLMサービスに特化したインフェレンスエンジンであり、最大のパフォーマンスに焦点を当てています。これは、コンテナ化するためにDockerを使用する低レベルのツールです。

設定と開始

Dockerモデルランナーのインストールは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サービスで1秒あたり数百のリクエストを処理する必要がある場合、vLLMの最適化により、一般的なサービングアプローチと比較して2〜5倍のスループットが得られます。

Dockerモデルランナーは、使いやすさに焦点を当てており、最大のパフォーマンスではなく、ローカル開発、テスト、中規模ワークロードに適しています。vLLMがスケールで優れているようには、高度な最適化が実装されていません。

モデルサポート

Dockerモデルランナーは、ポピュラーなモデルへのワンコマンドアクセスを提供するキュレーション済みモデルライブラリを備えています。Stable Diffusion、Whisper、その他のAIモデルを含む複数のフレームワーク（LLMに限らず）をサポートしており、さまざまなAIワークロードに対してより汎用的です。

vLLMは、Transformerベースの言語モデルに深く対応したLLMインフェレンスに特化しており、HuggingFace互換のLLMをサポートしますが、画像生成や音声認識などの他のAIモデルタイプには対応していません。

生産デプロイメント

vLLMは、Anthropic、Replicate、その他多くの企業で日々数十億のトークンを処理する生産環境で実証済みです。そのパフォーマンス特性と高負荷下での安定性により、生産LLMサービスの事実上の標準となっています。

Dockerモデルランナーは、より新しいもので、開発およびローカルテストのシナリオに位置づけています。生産トラフィックを処理するには可能ですが、生産デプロイメントに必要な実績とパフォーマンス最適化が欠如しています。

統合エコシステム

vLLMは、Kubernetesオペレーター、Prometheusメトリクス、Rayによる分散サービング、既存アプリケーション向けのOpenAI APIとの広範な互換性を備えた生産インフラストラクチャツールと統合しています。

Dockerモデルランナーは、DockerのエコシステムとDocker Desktopと自然に統合しています。Dockerに標準化しているチームにとって、この統合により一貫した体験を提供しますが、専用のLLMサービング機能は少なくなります。

各ツールの使用タイミング

vLLMを使用する場合：

  • 生産LLM APIサービス
  • 高スループット、マルチユーザーのデプロイメント
  • クラウドデプロイメントでコストを最適化したい場合
  • Kubernetesおよびクラウドネイティブ環境
  • スケーラビリティとパフォーマンスが必要な場合

Dockerモデルランナーを使用する場合：

  • ローカル開発とテスト
  • 多様なAIモデルタイプ（LLMに限らず）を実行する
  • Dockerエコシステムに深く投資しているチーム
  • インフラセットアップなしで迅速な実験
  • 学習や教育目的

ハイブリッドアプローチ：多くのチームは、Dockerモデルランナーでローカルで開発と実験を簡便に行い、vLLMで生産デプロイメントを行います。Dockerモデルランナーのイメージを使用して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

これは、共通のプレフィックスを持つ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を使用している場合、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="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アプリケーション
  • 複数のリクエストにわたって繰り返すファイナローショット学習プロンプト

プレフィックスキャッシュは、プロンプトプレフィックスを共有するリクエストの時間まで最初のトークンを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 with PagedAttention：24GB VRAM、128同時シーケンス
  • 結果：同じメモリで4倍多くの同時リクエストを処理できます

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

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

これらのベンチマークにより、なぜvLLMが生産LLMサービングにおいてパフォーマンスが重要である場面で事実上の標準となったかが示されます。

コスト分析

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="レート制限を超えました")
    
    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は、バッチ推論においてよりシンプルで、はるかに高速です。

vLLMの将来

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

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

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

強化されたクォンタイズ：llama.cppで使用されているGGUFなどの新しいクォンタイズフォーマットをサポートし、AWQ/GPTQの統合を改善して、クォンタイズモデルのパフォーマンスを向上させます。

スパーキングデコードの改善：精度の低下なしにより効率的なドラフトモデルと適応型スパーキング戦略を導入して、より大きな速度向上を実現します。

注意の最適化：FlashAttention 3、極めて長いコンテキスト（100K+トークン）用のリング注意、および他の最先端の注意機構を導入します。

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

vLLMプロジェクトは、UC Berkeley、Anyscale、および広範なオープンソースコミュニティからの活発な開発を維持しています。LLMのデプロイメントが生産システムにとってますます重要になる中、vLLMのパフォーマンス標準としての役割はますます大きくなっています。

有用なリンク

このサイトの関連記事

  • ローカルLLMホスティング：2025年の完全ガイド - Ollama, vLLM, LocalAI, Jan, LM Studio & More - 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のGPU上で非常に最適化された推論を実行するためのNVIDIA TensorRT-LLM。vLLMとは異なる最適化戦略を持つ代替ソリューションで、比較や推論最適化の全体像を理解するために役立ちます。

  • OpenAI APIリファレンス - vLLMのAPIと互換性がある公式OpenAI APIドキュメント。OpenAIと自社ホスティングされたvLLMエンドポイントを交互に使用する必要があるアプリケーションを開発する際に参照してください。