Gemma 4を本番環境にデプロイする方法（vLLM + Docker）

OllamaでノートPC上でGemma 4を実行するのは開発には最適です。しかし、何百もの同時ユーザーにサービスを提供し、毎分何千ものリクエストを処理し、レイテンシーを1秒以下に保つ必要があるとき — 本番グレードの推論エンジンが必要です。

そこでvLLMの出番です。本番環境で大規模言語モデルを提供するゴールドスタンダードで、Gemma 4と美しく動作します。

なぜvLLM？

vLLMはPagedAttentionを使用し、オペレーティングシステムがRAMを管理する方法でGPUメモリを管理します — リクエストが来て去るにつれて動的にメモリを割り当て・解放します。結果：

素朴な推論に対して2-4倍高いスループット
OpenAI互換API — クライアントコードを変更せずにGemma 4を差し替え
連続バッチング — リクエスト間のGPUサイクルの無駄なし
テンソル並列 — 大きなモデルを複数のGPUに分割

vLLMのインストール

# クリーンな環境を作成
python -m venv vllm-env
source vllm-env/bin/activate

# GPUサポート付きでvLLMをインストール
pip install vllm

適切なCUDAドライバーがあることを確認してください。vLLMにはCUDA 12.1以上と小さいGemma 4モデル用に少なくとも16GBのVRAMを持つGPUが必要です。

OpenAI互換APIでGemma 4を提供

始める最もシンプルな方法 — 1コマンドでAPIエンドポイントができます：

vllm serve google/gemma-4-26b \
  --host 0.0.0.0 \
  --port 8000 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --dtype bfloat16

任意のOpenAI SDKクライアントで叩けます：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed",  # vLLMはデフォルトでキーを要求しない
)

response = client.chat.completions.create(
    model="google/gemma-4-26b",
    messages=[
        {"role": "user", "content": "Explain quantum computing in one paragraph."}
    ],
    temperature=0.7,
    max_tokens=256,
)

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

美しさ：アプリが既にOpenAI APIを使用しているなら、文字通りbase_urlとmodel名を変更するだけ。それ以外はすべて同じです。

GPUメモリプランニング

ここがほとんどの人が間違えるところです。実際に必要なもの：

モデル	精度	最小VRAM	推奨VRAM	最大コンテキスト
Gemma 4 E4B	FP16	10 GB	16 GB	32K
Gemma 4 E4B	INT8	6 GB	10 GB	16K
Gemma 4 26B	BF16	52 GB	80 GB (A100)	32K
Gemma 4 26B	INT8	28 GB	40 GB (A100)	32K
Gemma 4 31B	BF16	62 GB	80 GB (A100)	32K

プロのヒント： --gpu-memory-utilizationフラグ（デフォルト0.9）は、vLLMが事前割り当てするVRAMの量を制御します。同じGPUで他のプロセスを実行している場合は0.8に下げましょう。ハードウェア理解に助けが必要？ハードウェアガイドをご確認ください。

マルチGPUセットアップの場合：

# Gemma 4 26Bを2つのGPUに分割
vllm serve google/gemma-4-26b \
  --tensor-parallel-size 2 \
  --host 0.0.0.0 \
  --port 8000

Dockerセットアップ

本番デプロイの正しい方法はDockerです。完全なdocker-compose.yml：

version: "3.8"

services:
  vllm:
    image: vllm/vllm-openai:latest
    ports:
      - "8000:8000"
    volumes:
      - model-cache:/root/.cache/huggingface
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
    command: >
      --model google/gemma-4-26b
      --host 0.0.0.0
      --port 8000
      --max-model-len 8192
      --gpu-memory-utilization 0.90
      --dtype bfloat16
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

volumes:
  model-cache:

起動：

# HuggingFaceトークンを設定
export HF_TOKEN=your_token_here

# サービスを開始
docker compose up -d

# ログを確認
docker compose logs -f vllm

# 動作確認
curl http://localhost:8000/v1/models

Docker特有のセットアップの詳細は、Dockerガイドをご覧ください。

バッチ推論

大きなデータセットを処理する必要がある場合 — たとえば10,000のドキュメントを分類 — バッチ推論は一度に1リクエストを送るよりはるかに効率的です：

from openai import OpenAI
import asyncio
import aiohttp

client = OpenAI(base_url="http://localhost:8000/v1", api_key="none")

async def process_batch(items, max_concurrent=50):
    semaphore = asyncio.Semaphore(max_concurrent)
    
    async def process_one(item):
        async with semaphore:
            response = client.chat.completions.create(
                model="google/gemma-4-26b",
                messages=[{"role": "user", "content": item}],
                max_tokens=128,
            )
            return response.choices[0].message.content
    
    tasks = [process_one(item) for item in items]
    return await asyncio.gather(*tasks)

# 最大50の同時リクエストで1000アイテムを処理
items = ["Classify this text: " + text for text in your_texts]
results = asyncio.run(process_batch(items))

vLLMは連続バッチングを通じて内部的にバッチングを処理します — 最大のGPU使用率のために自動的にリクエストをグループ化します。

ロードバランシング

高可用性のため、ロードバランサーの背後に複数のvLLMインスタンスを実行：

# nginx.conf
upstream vllm_backend {
    least_conn;
    server vllm-1:8000;
    server vllm-2:8000;
    server vllm-3:8000;
}

server {
    listen 80;

    location /v1/ {
        proxy_pass http://vllm_backend;
        proxy_set_header Host $host;
        proxy_read_timeout 120s;
    }
}

Vertex AI：マネージドオプション

インフラストラクチャを全く管理したくないなら、GoogleのVertex AIがマネージドGemma 4デプロイを提供します：

# gcloud CLI経由でデプロイ
gcloud ai endpoints create \
  --region=us-central1 \
  --display-name=gemma4-endpoint

gcloud ai models upload \
  --region=us-central1 \
  --display-name=gemma-4-26b \
  --container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/vllm-serve:latest \
  --artifact-uri=gs://your-bucket/gemma-4-26b

Vertex AIはスケーリング、モニタリング、GPU割り当てを処理します。予測ごとに料金を支払います。クエリあたりより高価ですが、運用オーバーヘッドがはるかに少ないです。

Google AI Studio（無料枠）との比較については、Google AI Studioガイドをご覧ください。

モニタリング

本番環境では以下のメトリクスを監視すべきです：

import requests

# vLLMはPrometheusメトリクスを公開
metrics = requests.get("http://localhost:8000/metrics").text

# 追跡する主要メトリクス：
# vllm:num_requests_running    — 現在の同時リクエスト
# vllm:num_requests_waiting    — キューの深さ
# vllm:avg_generation_throughput — トークン/秒
# vllm:gpu_cache_usage_perc   — KVキャッシュ使用率