【2026年版】vLLM on Kubernetes完全ガイド — GPU Operatorで実現するLLM推論サーバーの本番運用

この記事の概要

• vLLMはUC Berkeley発のLLM推論サーバー。PagedAttentionによる高効率GPU利用・OpenAI互換APIが強み
• KubernetesにNVIDIA GPU Operator + vLLM Production Stackを入れれば、Helmコマンド数本で本番級の推論基盤が立ち上がる
• KEDAでKVキャッシュ使用率やキュー深度をもとに自動スケールすることで、コストを最小化しながらレスポンスタイムSLAを守れる

背景・概要

2026年現在、「社内でLLMを動かしたい」という要望はもはや珍しくなくなりました。
ただ、OpenAIやAnthropicのAPIをそのまま使うのではなく、セキュリティやコスト・カスタマイズの観点からオンプレ or 自社クラウド上で推論サーバーを自前運用したいというニーズが急増しています。

そこで主役となるのが vLLM（Very Large Language Model serving） です。
GitHubスターは40k+を突破し、Llama・Mistral・Gemma・Falcon・Command Rなど主要モデルに対応。
特に「PagedAttention」と「Continuous Batching」の2技術により、従来手法の最大24倍というスループットを叩き出します。

この記事では、Kubernetes + NVIDIA GPU Operatorという定番インフラ構成でvLLMをゼロから本番環境に構築する手順を、実際のマニフェストとHelmコマントとともに解説します。
「インフラは得意だけどMLは初めて」というエンジニアでも迷わず進められる内容を目指しました。

詳細解説

なぜvLLMがKubernetes上でのLLM推論に選ばれるのか

vLLMの核心技術は PagedAttention です。
OSの仮想メモリ管理の考え方をKVキャッシュに応用し、GPUメモリのフラグメンテーションを大幅に低減します。

従来のLLM推論サーバーでは、生成中のシーケンスが増えるとGPUメモリが断片化し、並列処理できるリクエスト数が激減していました。
PagedAttentionはKVキャッシュを固定サイズの「ページ」に分割して管理することで、この問題を根本的に解決。
同じGPUで処理できる同時リクエスト数を数倍〜十数倍に増やせます。

加えて、OpenAI互換の /v1/chat/completions エンドポイントを標準提供するので、既存のLangChain・LlamaIndex・OpenAI SDK資産をほぼ無改修で流用できる点も現場では地味に助かります。

事前準備：NVIDIA GPU Operatorのインストール

GPU付きKubernetesクラスターを用意したら、まず NVIDIA GPU Operator を入れます。
これ1本でGPUドライバー・デバイスプラグイン・コンテナランタイムの設定が自動化されます（以前はこれを手動でやる地獄でしたが、今は本当に楽になりました）。

# NVIDIA GPU Operatorのインストール
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm install gpu-operator nvidia/gpu-operator \
  --namespace gpu-operator \
  --create-namespace \
  --set driver.enabled=true \
  --set toolkit.enabled=true \
  --wait

インストール後、GPU搭載ノードに自動でラベルが付きます。

# GPU情報の確認
kubectl get nodes -o json | jq '.items[].metadata.labels | with_entries(select(.key | startswith("nvidia.com")))'
# 例: "nvidia.com/gpu.product": "NVIDIA-A100-SXM4-40GB"

vLLM Production Stackのデプロイ

2025年1月にvLLMプロジェクトが公開した Production Stack は、K8sネイティブなクラスター規模デプロイのリファレンス実装です。
vLLMエンジン本体 + ルーター + キャッシュサーバーをHelmで一括展開できます。

# Helmリポジトリの追加
helm repo add vllm https://vllm-project.github.io/production-stack
helm repo update

# values.yamlを用意してインストール
cat <<EOF > vllm-values.yaml
servingEngines:
  - name: llama3-8b
    model: meta-llama/Meta-Llama-3-8B-Instruct
    replicaCount: 2
    resources:
      limits:
        nvidia.com/gpu: "1"
    nodeSelector:
      nvidia.com/gpu.product: NVIDIA-A100-SXM4-40GB
    # HuggingFaceトークンはExternal Secrets Operatorで管理推奨
    env:
      - name: HF_TOKEN
        valueFrom:
          secretKeyRef:
            name: hf-token
            key: token
EOF

helm install vllm vllm/vllm-stack \
  --namespace vllm \
  --create-namespace \
  -f vllm-values.yaml \
  --wait

デプロイ後、ポートフォワードで動作確認できます。

kubectl port-forward -n vllm svc/vllm-router 8000:80 &

# OpenAI互換APIでテスト
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Meta-Llama-3-8B-Instruct",
    "messages": [{"role": "user", "content": "こんにちは！"}]
  }'

KEDAによるオートスケーリング設定

本番で一番重要なのがスケーリング戦略です。
GPUサーバーは高価なので、リクエストが少ない夜間にレプリカを減らし、ピーク時に自動で増やせるようにしたい。

vLLM Production StackはKEDA（Kubernetes Event-driven Autoscaling）との統合をサポートしており、PrometheusメトリクスをもとにKVキャッシュ使用率やキュー深度でスケーリングできます。

まずKEDAをインストール。

helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda --namespace keda --create-namespace

次に、KVキャッシュ使用率80%超えでスケールアウトするScaledObjectを定義します。

# vllm-scaledobject.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-llama3-scaler
  namespace: vllm
spec:
  scaleTargetRef:
    name: vllm-llama3-8b  # Deploymentの名前
  minReplicaCount: 1       # 夜間は1台まで落とす
  maxReplicaCount: 8
  cooldownPeriod: 300      # スケールダウンは5分待機
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-server.monitoring.svc.cluster.local
        # KVキャッシュ使用率（0〜1のfloat）の95パーセンタイルが0.8（80%）を超えたらスケールアウト
        query: |
          quantile(0.95,
            vllm:gpu_cache_usage_perc{job="vllm-llama3-8b"}
          )
        threshold: "0.8"

kubectl apply -f vllm-scaledobject.yaml

ここ、地味に大事なポイントですが — ReadWriteMany（RWX）でモデルウェイトをマウントしておくと、スケールアウト時に新Podがモデルを再ダウンロードせず、数分で立ち上がります。
FSx for Lustre（AWS）やAzure NetApp FilesなどのRWXストレージを使いましょう。

モデルの切り替えとMermaid構成図

実際の構成をざっくりまとめると以下のようなイメージです。

graph TD
    Client[クライアント / LangChain等] -->|OpenAI互換API| Router[vLLM Router Service]
    Router -->|負荷分散| Engine1[vLLM Pod #1\nLlama-3 8B]
    Router -->|負荷分散| Engine2[vLLM Pod #2\nLlama-3 8B]
    Engine1 --- GPU1[NVIDIA A100 #1]
    Engine2 --- GPU2[NVIDIA A100 #2]
    KEDA[KEDA ScaledObject] -->|スケール制御| Router
    Prometheus[Prometheus] -->|KVキャッシュ使用率| KEDA
    RWX[(FSx for Lustre\nモデルウェイト)] --- Engine1
    RWX --- Engine2

実務での活用方法

シナリオ1: 社内RAGシステムの推論基盤として

社内ドキュメントをベクトル化してS3 Vectorsに格納し、RAGの推論部分をvLLM on EKSで処理するアーキテクチャが2026年のスタンダードになりつつあります。
従量課金のAPIと比べて、月次リクエストが1億回を超えてくると自前運用のコスパが逆転します。

シナリオ2: LoRAアダプターでモデルを社内特化チューニング

vLLMはLoRA（Low-Rank Adaptation）アダプターをサポートしており、ベースモデルはそのままにして社内ドメイン特化の軽量チューニングを当てられます。
Production Stackではモデルごとにアダプターを複数定義できるので、「法務チーム向け」「技術サポート向け」など複数のユースケースを1クラスターで捌くことも可能です。

まとめ

• vLLM はPagedAttentionとContinuous Batchingで高効率LLM推論を実現するOSS
• NVIDIA GPU Operator でノードのGPU設定を自動化、手動設定地獄から解放される
• vLLM Production Stack（Helm）でRouter・Engine・Cacheをまとめてデプロイ
• KEDA × PrometheusでKVキャッシュ使用率をトリガーにしたコスト効率の良いスケーリングを実現
• RWXストレージでモデルウェイトを共有することが、スケールアウト速度の鍵

社内LLM基盤の構築は「AIチームの仕事」ではなく、今やインフラSEが先頭に立つ分野になっています。
この記事の構成で組んでみると「意外と動くやん」という感触を得られるはずです。
ぜひ試してみてください。

⚠️ 料金情報はすべて執筆時点（2026年5月）のものです。最新情報はAWS/GCP/Azure各公式サイトでご確認ください。

参考リンク

• vLLM 公式ドキュメント
• vLLM Production Stack（GitHub）
• NVIDIA GPU Operator
• KEDA – Kubernetes Event-driven Autoscaling
• Deploying LLMs on Kubernetes: vLLM, Ray Serve & GPU Scheduling Guide (2026)
• How to deploy and benchmark vLLM with GuideLLM on Kubernetes（Red Hat Developer）