K8s 1.30+大規模モデル推論弾力スケジューリング実践：vLLMデプロイとKEDA自動スケーリングディープガイド
云原生
概要
- K8s 1.30+のSidecarContainers、ReadWriteOncePod PVCなどの機能が大規模モデル推論サービスにより精細なリソース制御能力を提供
- vLLMのPagedAttention + ContinuousBatchingは現在のLLM推論サービスの事実上の標準であり、単一GPUスループットは従来方式の3-5倍に達する
- KEDAカスタムメトリクススケーリング（リクエストキュー深度、GPU使用率、TTFTレイテンシに基づく）はHPA CPUメトリクスより推論負荷に正確にマッチ
- 推論サービス3層弾力戦略：PodレベルHPA→Deploymentレベルローリングアップデート→Clusterレベルクラスタスケーリング
- 本記事はvLLM K8sデプロイからKEDA自動スケーリングまでの完全ソリューション、本番級YAMLとパフォーマンスチューニングパラメータ付き
目次
- K8s 1.30+と大規模モデル推論の新しい接点
- vLLM推論エンジンK8sデプロイ
- KEDAカスタムメトリクス自動スケーリング
- GPUリソース最適化とマルチテナント分離
- 3層弾力戦略と障害自己修復
- 本番級推論クラスタオブザーバビリティ
- まとめと関連記事
K8s 1.30+と大規模モデル推論の新しい接点
Kubernetes 1.30（Ubykah）はAI推論ワークロードに不可欠な複数の機能を導入した。SidecarContainersがGAに達し、ログ収集やメトリクス公開などのサイドカーコンテナがPod終了をブロックしなくなり、推論Podのローリングアップデート速度が60%向上した。ReadWriteOncePod PVCアクセスモードにより、モデルウェイトファイルのストレージがより安全かつ効率的になり、複数Podの同時マウントによる書き込み競合を回避できる。
┌──────────────────────────────────────────────────────────────────┐
│ K8s 1.30+ LLM推論アーキテクチャ │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ Inference Gateway (Nginx/Traefik) │ │
│ │ - 負荷分散: 最小接続数アルゴリズム │ │
│ │ - レート制限・サーキットブレーカー: トークンバケット │ │
│ │ - A/Bルーティング: モデルバージョンカナリアデプロイ │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ vLLM Pod (x N) │ │
│ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │
│ │ │ vLLM Server│ │ Log Sidecar│ │ Metrics │ │ │
│ │ │ (メイン) │ │(1.30 GA) │ │ Sidecar │ │ │
│ │ └────────────┘ └────────────┘ └────────────┘ │ │
│ │ GPU: NVIDIA A100/H100 │ │
│ │ モデル: RWX Pod PVCマウント │ │
│ └──────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ KEDA Scaler │ │
│ │ - メトリクス: リクエストキュー深度 / GPU使用率 / TTFT │ │
│ │ - 最小レプリカ: 2 (高可用) │ │
│ │ - 最大レプリカ: 20 (弾力上限) │ │
│ │ - クールダウン: 300s (フラッピング防止) │ │
│ └──────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
K8s 1.30+主要機能がLLM推論に与える影響
| K8s機能 | バージョン | LLM推論への影響 |
|---|---|---|
| SidecarContainers GA | 1.30 | 推論Podローリングアップデート60%高速化、サイドカーが終了をブロックしない |
| ReadWriteOncePod PVC | 1.30 | モデルウェイトファイルの排他マウント、書き込み競合回避 |
| PodReadyToStartContainers | 1.31 | 推論サービスレディネス検出の精度向上、未初期化Podへのトラフィック回避 |
| AppArmor GA | 1.31 | 推論Podセキュリティ強化、モデルウェイト漏洩防止 |
| Structured Authorization | 1.32 | マルチテナント推論クラスタの細粒度権限制御 |
vLLM推論エンジンK8sデプロイ
vLLMコア最適化原理
vLLMはPagedAttentionとContinuousBatchingの2つのコア技術により、GPUメモリ使用率を従来方式の30-40%から90%以上に向上させる。PagedAttentionはOS仮想メモリのページング機構を参考に、KV Cacheをブロック単位で管理し、メモリ断片化を排除する。ContinuousBatchingはリクエストレベルでスケジューリングし、現在のバッチの完了を待たずに新しいリクエストを実行に参加させる。
┌──────────────────────────────────────────────────────────────┐
│ vLLM PagedAttention + ContinuousBatching │
│ │
│ 従来方式 (Static Batching): │
│ ┌────┬────┬────┬────┐ │
│ │ R1 │ R2 │ R3 │ R4 │ 最長リクエスト完了まで待機 │
│ └────┴────┴────┴────┘ │
│ ████████████████████ GPUアイドル待機 │
│ │
│ vLLM (Continuous Batching): │
│ ┌────┬────┬────┬────┐ │
│ │ R1 │ R2 │ R3 │ R4 │ R1完了後すぐR5を挿入 │
│ └────┴────┴────┴────┘ │
│ ┌────┬────┬────┬────┐ │
│ │ R5 │ R2 │ R3 │ R4 │ R2完了後すぐR6を挿入 │
│ └────┴────┴────┴────┘ │
│ ████████████████ GPU持続的高使用率 │
│ │
│ PagedAttention KV Cache: │
│ ┌───┬───┬───┬───┬───┬───┬───┬───┐ │
│ │P0 │P1 │P2 │P3 │P4 │P5 │P6 │P7 │ オンデマンド物理ブロック │
│ └───┴───┴───┴───┴───┴───┴───┴───┘ │
│ R1→[P0,P1,P2] R2→[P3,P4] R3→[P5,P6,P7] │
│ 断片化なし、メモリ使用率90%+ │
└──────────────────────────────────────────────────────────────┘
vLLM K8s Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-qwen2-72b
namespace: llm-inference
labels:
app: vllm
model: qwen2-72b-instruct
spec:
replicas: 2
selector:
matchLabels:
app: vllm
model: qwen2-72b-instruct
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: vllm
model: qwen2-72b-instruct
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8000"
prometheus.io/path: "/metrics"
spec:
terminationGracePeriodSeconds: 120
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: vllm
model: qwen2-72b-instruct
topologyKey: kubernetes.io/hostname
containers:
- name: vllm-server
image: vllm/vllm-openai:v0.6.0
command:
- python
- -m
- vllm.entrypoints.openai.api_server
args:
- --model
- /models/Qwen2.5-72B-Instruct
- --tensor-parallel-size
- "2"
- --max-model-len
- "32768"
- --gpu-memory-utilization
- "0.92"
- --max-num-seqs
- "256"
- --enable-prefix-caching
- --enable-chunked-prefill
- --port
- "8000"
ports:
- containerPort: 8000
resources:
requests:
nvidia.com/gpu: "2"
cpu: "8"
memory: 32Gi
limits:
nvidia.com/gpu: "2"
cpu: "16"
memory: 64Gi
env:
- name: MODEL_NAME
value: "qwen2-72b-instruct"
- name: VLLM_WORKER_MULTIPROC_METHOD
value: "ray"
volumeMounts:
- name: model-storage
mountPath: /models
- name: shm
mountPath: /dev/shm
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 120
periodSeconds: 10
failureThreshold: 3
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 180
periodSeconds: 15
failureThreshold: 5
- name: metrics-exporter
image: prometheus-exporter/vllm-metrics:v1.0
ports:
- containerPort: 9090
resources:
requests:
cpu: "100m"
memory: 128Mi
volumes:
- name: model-storage
persistentVolumeClaim:
claimName: model-weights-pvc
- name: shm
emptyDir:
medium: Memory
sizeLimit: 16Gi
モデルウェイトPVC（ReadWriteOncePod）
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: model-weights-pvc
namespace: llm-inference
spec:
accessModes:
- ReadWriteOncePod
storageClassName: local-ssd
resources:
requests:
storage: 200Gi
vLLMパフォーマンスチューニングパラメータ
| パラメータ | デフォルト | 推奨値 | 説明 |
|---|---|---|---|
--gpu-memory-utilization |
0.9 | 0.92 | GPUメモリ使用率上限 |
--max-model-len |
モデルデフォルト | 32768 | 最大シーケンス長、KV Cacheサイズに影響 |
--max-num-seqs |
256 | 256 | 最大同時シーケンス数 |
--enable-prefix-caching |
false | true | プレフィックスキャッシュ、同じpromptでKV Cache再利用 |
--enable-chunked-prefill |
false | true | チャンクプレフィル、初回トークンレイテンシ削減 |
--swap-space |
4GB | 8GB | CPUスワップスペース、長シーケンスオーバーフロー時使用 |
KEDAカスタムメトリクス自動スケーリング
なぜHPAでは不十分か
K8sネイティブHPAはCPU/メモリ使用率に基づいてスケーリングするが、LLM推論サービスはGPU集約型であり、CPU使用率は実際の負荷を反映できない。推論PodのCPUが30%でも、GPUメモリが満杯でリクエストキューが深刻に蓄積している可能性がある。KEDA（Kubernetes Event-Driven Autoscaling）はカスタムメトリクススケーリングをサポートし、vLLMが公開するリクエストキュー深度、GPU使用率、TTFT（Time To First Token）などのメトリクスに基づいて正確にスケーリングできる。
KEDA ScaledObject
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: vllm-scaler
namespace: llm-inference
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: vllm-qwen2-72b
minReplicaCount: 2
maxReplicaCount: 20
cooldownPeriod: 300
pollingInterval: 15
advanced:
horizontalPodAutoscalerConfig:
behavior:
scaleDown:
stabilizationWindowSeconds: 600
policies:
- type: Pods
value: 1
periodSeconds: 120
scaleUp:
stabilizationWindowSeconds: 30
policies:
- type: Pods
value: 3
periodSeconds: 60
- type: Percent
value: 50
periodSeconds: 60
selectPolicy: Max
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus:9090
metricName: vllm_num_requests_waiting
threshold: "10"
query: |
avg_over_time(vllm_num_requests_waiting{model="qwen2-72b-instruct"}[1m])
- type: prometheus
metadata:
serverAddress: http://prometheus:9090
metricName: vllm_gpu_cache_usage_perc
threshold: "80"
query: |
avg_over_time(vllm_gpu_cache_usage_perc{model="qwen2-72b-instruct"}[2m])
- type: prometheus
metadata:
serverAddress: http://prometheus:9090
metricName: vllm_e2e_request_latency_seconds
threshold: "5"
query: |
histogram_quantile(0.95, sum(rate(vllm_e2e_request_latency_seconds_bucket{model="qwen2-72b-instruct"}[2m])) by (le))
マルチメトリクススケーリング戦略
┌──────────────────────────────────────────────────────────────┐
│ KEDAマルチメトリクススケーリング決定フロー │
│ │
│ メトリクス1: リクエストキュー深度 │
│ vllm_num_requests_waiting > 10 → スケールアップ │
│ │
│ メトリクス2: GPU KV Cache使用率 │
│ vllm_gpu_cache_usage_perc > 80% → スケールアップ │
│ │
│ メトリクス3: P95エンドツーエンドレイテンシ │
│ vllm_e2e_request_latency_seconds > 5s → スケールアップ │
│ │
│ 決定: いずれかのメトリクスがトリガーされればスケールアップ │
│ すべてのメトリクスが正常でなければスケールダウンしない │
│ クールダウン: スケールアップ30s / スケールダウン600s │
│ ステップ: スケールアップmax(3 Pod, 50%) / ダウン1 Pod/2min │
└──────────────────────────────────────────────────────────────┘
GPUリソース最適化とマルチテナント分離
NVIDIA MIGパーティショニング
A100/H100でMIG（Multi-Instance GPU）を使用し、単一GPUを複数インスタンスに分割してマルチテナント推論分離を実現。
apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaim
metadata:
name: mig-instance
namespace: llm-inference
spec:
devices:
- name: gpu
driver: nvidia.com/gpu
requests:
- name: mig-instance
deviceClassName: mig.nvidia.com/1g.10gb
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-small-model
namespace: llm-inference
spec:
replicas: 4
selector:
matchLabels:
app: vllm-small
template:
spec:
containers:
- name: vllm
image: vllm/vllm-openai:v0.6.0
args:
- --model
- /models/Qwen2.5-7B-Instruct
- --gpu-memory-utilization
- "0.90"
- --max-model-len
- "8192"
resources:
claims:
- name: mig-instance
resourceClaims:
- name: mig-instance
claimName: mig-instance
GPUタイムスライス共有
低優先度推論タスクにはGPUタイムスライス共有を使用し、複数Podで単一GPUを共有。
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-batch-inference
namespace: llm-inference
spec:
replicas: 2
selector:
matchLabels:
app: vllm-batch
template:
spec:
containers:
- name: vllm
image: vllm/vllm-openai:v0.6.0
args:
- --model
- /models/Qwen2.5-7B-Instruct
- --gpu-memory-utilization
- "0.45"
resources:
requests:
nvidia.com/gpu: "1"
limits:
nvidia.com/gpu: "1"
env:
- name: NVIDIA_VISIBLE_DEVICES
value: "0"
- name: CUDA_MPS_PIPE_DIRECTORY
value: "/tmp/nvidia-mps"
- name: CUDA_MPS_LOG_DIRECTORY
value: "/tmp/nvidia-log"
マルチテナントGPUリソースクォータ
apiVersion: v1
kind: ResourceQuota
metadata:
name: gpu-quota-team-a
namespace: team-a-inference
spec:
hard:
requests.nvidia.com/gpu: "8"
limits.nvidia.com/gpu: "8"
requests.cpu: "32"
limits.cpu: "64"
requests.memory: 128Gi
limits.memory: 256Gi
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: gpu-quota-team-b
namespace: team-b-inference
spec:
hard:
requests.nvidia.com/gpu: "4"
limits.nvidia.com/gpu: "4"
3層弾力戦略と障害自己修復
3層弾力アーキテクチャ
┌──────────────────────────────────────────────────────────────┐
│ 3層弾力戦略アーキテクチャ │
│ │
│ Layer 1: Podレベル (KEDA HPA) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ カスタムメトリクスベースのPodレプリカスケーリング │ │
│ │ 応答時間: 30-60s │ │
│ │ 粒度: 単一Deployment │ │
│ └──────────────────────────────────────────────────────┘ │
│ ↓ まだ不足 │
│ Layer 2: Deploymentレベル (ローリングアップデート) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ モデルバージョン切替、パラメータ調整のローリング更新 │ │
│ │ 応答時間: 5-15min │ │
│ │ 粒度: 単一モデルサービス │ │
│ └──────────────────────────────────────────────────────┘ │
│ ↓ クラスタレベル │
│ Layer 3: Clusterレベル (Cluster Autoscaler) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ ノードプールスケーリング、GPUノード追加 │ │
│ │ 応答時間: 3-10min (GPUドライバ初期化含む) │ │
│ │ 粒度: クラスタ全体 │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
障害自己修復：Pod異常検出と復旧
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-qwen2-72b
namespace: llm-inference
spec:
replicas: 2
selector:
matchLabels:
app: vllm
template:
spec:
containers:
- name: vllm-server
image: vllm/vllm-openai:v0.6.0
startupProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 60
periodSeconds: 10
failureThreshold: 30
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 120
periodSeconds: 10
failureThreshold: 3
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 180
periodSeconds: 15
failureThreshold: 5
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: vllm-pdb
namespace: llm-inference
spec:
minAvailable: 1
selector:
matchLabels:
app: vllm
model: qwen2-72b-instruct
推論サービスウォームアップ戦略
import httpx
import asyncio
import logging
logger = logging.getLogger(__name__)
class InferenceWarmer:
def __init__(self, base_url: str, model: str, warmup_prompts: list[str]):
self.base_url = base_url
self.model = model
self.warmup_prompts = warmup_prompts
async def warmup(self, rounds: int = 3):
for round_num in range(rounds):
tasks = [self._send_request(prompt) for prompt in self.warmup_prompts]
results = await asyncio.gather(*tasks, return_exceptions=True)
success_count = sum(1 for r in results if not isinstance(r, Exception))
logger.info(f"Warmup round {round_num + 1}: {success_count}/{len(tasks)} succeeded")
async def _send_request(self, prompt: str) -> dict:
async with httpx.AsyncClient(timeout=60.0) as client:
response = await client.post(
f"{self.base_url}/v1/completions",
json={
"model": self.model,
"prompt": prompt,
"max_tokens": 32,
"temperature": 0.0,
},
)
return response.json()
async def warmup_new_pod(pod_ip: str, model: str):
warmer = InferenceWarmer(
base_url=f"http://{pod_ip}:8000",
model=model,
warmup_prompts=[
"Hello, how are you?",
"What is the capital of France?",
"Explain quantum computing briefly.",
],
)
await warmer.warmup(rounds=3)
本番級推論クラスタオブザーバビリティ
vLLM Prometheusアラート
apiVersion: v1
kind: ConfigMap
metadata:
name: vllm-alerts
namespace: llm-inference
data:
alerts.yml: |
groups:
- name: vllm.rules
rules:
- alert: VLLMHighQueueDepth
expr: vllm_num_requests_waiting > 20
for: 2m
labels:
severity: warning
annotations:
summary: "vLLM request queue depth is high"
description: "Queue depth {{ $value }} exceeds threshold 20"
- alert: VLLMHighTTFT
expr: histogram_quantile(0.95, rate(vllm_time_to_first_token_seconds_bucket[5m])) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "vLLM TTFT P95 is high"
description: "TTFT P95 {{ $value }}s exceeds 2s threshold"
- alert: VLLMGPUOOM
expr: vllm_gpu_cache_usage_perc > 0.95
for: 1m
labels:
severity: critical
annotations:
summary: "vLLM GPU cache near OOM"
description: "GPU cache usage {{ $value }}% exceeds 95%"
- alert: VLLMHighErrorRate
expr: rate(vllm_request_errors_total[5m]) / rate(vllm_request_total[5m]) > 0.05
for: 3m
labels:
severity: critical
annotations:
summary: "vLLM error rate is high"
description: "Error rate {{ $value | humanizePercentage }} exceeds 5%"
Grafana Dashboard主要パネル
| パネル | メトリクス | 説明 |
|---|---|---|
| リクエストスループット | rate(vllm_request_total[1m]) |
秒間完了リクエスト数 |
| キュー深度 | vllm_num_requests_waiting |
待機中リクエスト数 |
| TTFT P95 | histogram_quantile(0.95, rate(vllm_time_to_first_token_seconds_bucket[5m])) |
初回トークンレイテンシ |
| TPOT P95 | histogram_quantile(0.95, rate(vllm_time_per_output_token_seconds_bucket[5m])) |
トークンあたりレイテンシ |
| GPU Cache使用率 | vllm_gpu_cache_usage_perc |
KV Cacheメモリ使用量 |
| 同時シーケンス数 | vllm_num_requests_running |
実行中シーケンス数 |
| エラーレート | rate(vllm_request_errors_total[5m]) / rate(vllm_request_total[5m]) |
リクエスト失敗率 |
推論パフォーマンスベンチマーク（Qwen2.5-72B, 2xA100）
| シナリオ | 同時接続数 | TTFT P50 | TTFT P95 | TPOT | スループット(tokens/s) |
|---|---|---|---|---|---|
| 短テキスト(128 in, 256 out) | 16 | 0.3s | 0.8s | 25ms | 4096 |
| 中テキスト(512 in, 512 out) | 8 | 0.5s | 1.2s | 30ms | 2048 |
| 長テキスト(2048 in, 1024 out) | 4 | 1.2s | 2.5s | 35ms | 1024 |
| 超長テキスト(8192 in, 2048 out) | 2 | 3.5s | 6.0s | 40ms | 512 |
まとめと関連記事
K8s 1.30+は大規模モデル推論サービスにより精細なリソース制御能力を提供する。vLLMのPagedAttention + ContinuousBatchingはLLM推論の事実上の標準であり、KEDAカスタムメトリクススケーリングはHPA CPUメトリクスより推論負荷に正確にマッチする。3層弾力戦略（PodレベルHPA→Deploymentレベルローリングアップデート→Clusterレベルクラスタスケーリング）は異なる負荷シナリオでの安定稼働を確保する。
開発の要点振り返り：
- vLLMデプロイ：prefix-cachingとchunked-prefillを有効化、GPUメモリ使用率0.92、max-num-seqsはGPU仕様に応じて調整
- KEDAスケーリング：リクエストキュー深度、GPU Cache使用率、TTFTレイテンシの3メトリクスでトリガー、スケールアップ30s/スケールダウン600sクールダウン
- GPU最適化：大規模モデルはGPU専有、小規模モデルはMIGパーティション、バッチ推論はタイムスライス共有
- 障害自己修復：startupProbe→readinessProbe→livenessProbeの3段階検出、PDBで最小可用レプリカを保証
- オブザーバビリティ：Prometheus + Grafanaフルチェーン監視、主要アラート：キュー深度>20、TTFT>2s、GPU Cache>95%
関連記事：
- AI Agentマルチエージェントオーケストレーション実践 — Agentオーケストレーションにおける推論サービススケジューリング
- K8s GPUスケジューリング実践：MIGパーティションとGPU共有 — GPUリソース管理とマルチテナント分離
- 大規模モデルRAGシステムゼロから本番級フルパイプライン実践 — RAGシステムにおける推論サービス統合
権威参考：
ブラウザローカルツールを無料で試す →
#K8s大模型推理#LLM弹性调度#vLLM K8s部署#推理服务自动伸缩#GPU推理优化#2026