K8s 1.30+ LLM推論プラットフォームデプロイ実践：GPU弾性スケジューリングとvLLM本番最適化完全ガイド

DevOps

概要

  • Kubernetes 1.30+ DRA（Dynamic Resource Allocation）メカニズムを習得し、マルチGPUシナリオでのきめ細かいスケジューリングとGPUメモリ分離を実現
  • vLLM + KEDAでLLM推論弾性スケーリングプラットフォームを構築し、0からNへの秒級自動スケーリングを実現
  • 本番級LLM推論プラットフォームのエンドツーエンド実践：モデルロード最適化、KV Cache管理、トラフィックルーティング、カナリアデプロイ

目次

一、LLM推論プラットフォームのアーキテクチャ設計

1.1 推論プラットフォームのコアコンポーネント

2026年、LLM推論プラットフォームは企業AIインフラのコアとなっています。本番級LLM推論プラットフォームは、モデルロードからリクエスト応答までのエンドツーエンドの能力をカバーする必要があり、そのコアコンポーネントには以下が含まれます：

┌──────────────────────────────────────────────────────┐
│                   API Gateway                         │
│     レート制限 · 認証 · ルーティング · 負荷分散 ·       │
│                   カナリア                             │
├──────────────────────────────────────────────────────┤
│                Inference Engine                       │
│     vLLM / TGI / Triton Inference Server             │
│     Continuous Batching · PagedAttention · Speculative│
├──────────────────────────────────────────────────────┤
│              Model Management                         │
│   モデルレジストリ · バージョン管理 · ホットロード ·     │
│   量子化変換                                           │
├──────────────────────────────────────────────────────┤
│              GPU Resource Layer                       │
│   DRAスケジューリング · GPUメモリプーリング · MIG        │
│   パーティショニング · マルチGPU並列処理                 │
├──────────────────────────────────────────────────────┤
│              Autoscaling & Scheduling                 │
│   KEDA HPA · Pod優先度 · スケジューリングトポロジー ·    │
│   予測スケーリング                                     │
└──────────────────────────────────────────────────────┘

API Gateway層はリクエストの統一エントリポイントを管理し、レート制限、認証、ルーティング、カナリアデプロイを含みます。Inference Engine層は推論のコアであり、vLLMはContinuous BatchingとPagedAttentionメカニズムにより2026年で最も主流なオープンソース推論エンジンとなっています。Model Management層はモデルのバージョン、ロード、変換を管理します。GPU Resource LayerはK8s DRAメカニズムによりGPUのきめ細かいスケジューリングを実現します。Autoscaling層はKEDAに基づきカスタムメトリクスベースのオートスケーリングを実装します。

1.2 推論モードの選択

LLM推論には2つのコアモードがあり、適切なモードの選択はプラットフォームのコストとパフォーマンスに直接影響します：

同期推論（Online Serving）：ユーザーリクエストにリアルタイムで応答、レイテンシ敏感（P99 < 2s）、チャットや補完などのインタラクティブシナリオに適用。常駐GPUリソースが必要で、コストは高いが最良の体験を提供。

非同期推論（Offline Batch）：推論タスクをバッチで投入、スループット優先、データ処理やコンテンツ生成などの非リアルタイムシナリオに適用。SpotインスタンスやアイドルGPUを活用でき、コストを大幅に削減。

本番環境では通常ハイブリッドモードを採用：日中はオンライン推論が主体、夜間はアイドルGPUリソースを活用してバッチタスクを実行し、GPU利用率を最大化。

1.3 主要パフォーマンスメトリクス

メトリクス 目標値 説明
Time to First Token (TTFT) < 200ms 初回トークンレイテンシ
Token Generation Rate > 100 tok/s GPUあたりの生成レート
GPU Utilization > 80% GPU計算利用率
GPU Memory Utilization > 90% GPUメモリ利用率
Request Success Rate > 99.9% リクエスト成功率
Cold Start Time < 60s モデルコールドスタート時間

二、K8s 1.30+ DRA GPUスケジューリング深掘り実践

2.1 DRAメカニズムのコアコンセプト

Kubernetes 1.30で正式に導入されたDynamic Resource Allocation（DRA）メカニズムは、GPUなどのアクセラレータのスケジューリング方法を根本的に変革しました。従来のExtended ResourceとDevice Pluginによるアプローチには3つの大きな課題がありました：パーティショニング不可 — 1枚のGPUを1つのPodにしか割り当てられない；共有不可 — 異なるPodが同じGPUを安全に共有できない；動的調整不可 — 割り当て後にリソースクォータをオンラインで調整できない。

DRAはResourceClaimとResourceClassの2つのコアAPIでこれらの問題を解決します：

  • ResourceClaim：ワークロードが必要とするリソースを宣言的に記述（例：「A100 GPU 2枚、各40GBメモリが必要」）
  • ResourceClass：リソースの供給ポリシーを定義（例：「A100を優先割り当て、不足時はA10Gにフォールバック」）
  • ResourceHandle：ドライバから返されるリソースハンドル、デバイスIDやトポロジー情報などを含む
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClass
metadata:
  name: nvidia-a100
driverName: gpu.resource.k8s.io/nvidia
parametersRef:
  apiGroup: gpu.resource.k8s.io
  kind: GPUParameters
  name: a100-config
---
apiVersion: gpu.resource.k8s.io/v1beta1
kind: GPUParameters
metadata:
  name: a100-config
spec:
  gpuType: "A100-SXM4-80GB"
  migStrategy: "single"
  memoryLimit: "40Gi"
  priority: 100
  fallbackGpuType: "A10G"
---
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference-server
spec:
  containers:
  - name: vllm
    image: vllm/vllm-openai:v0.8.0
    resources:
      claims:
      - name: gpu-claim
  resourceClaims:
  - name: gpu-claim
    resourceClaimTemplateName: a100-claim-template
---
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaimTemplate
metadata:
  name: a100-claim-template
spec:
  spec:
    resources:
    - name: nvidia-a100
      resourceClassName: nvidia-a100
      allocationMode: WaitForFirstConsumer

2.2 GPUメモリプーリングとMIGパーティショニング

マルチテナントシナリオでは、GPUメモリプーリングがリソース利用率向上の鍵となります。NVIDIA MIG（Multi-Instance GPU）は1枚のA100を最大7つの独立インスタンスに分割でき、各インスタンスは専用のGPUコアとメモリを持ちます。

apiVersion: gpu.resource.k8s.io/v1beta1
kind: GPUParameters
metadata:
  name: a100-mig-config
spec:
  gpuType: "A100-SXM4-80GB"
  migStrategy: "mixed"
  migProfiles:
  - name: "1g.10gb"
    count: 4
    memoryLimit: "10Gi"
    suitableModels:
    - "qwen3-4b"
    - "chatglm3-6b"
  - name: "2g.20gb"
    count: 2
    memoryLimit: "20Gi"
    suitableModels:
    - "qwen3-14b"
    - "llama3-8b"
  - name: "3g.40gb"
    count: 1
    memoryLimit: "40Gi"
    suitableModels:
    - "qwen3-32b"
    - "llama3-70b-awq"

2.3 マルチGPU並列スケジューリング

LLM推論ではマルチGPU並列処理が頻繁に必要です。K8s 1.30+のDRAはトポロジー認識スケジューリングをサポートし、割り当てられたGPUが同じNUMAノードまたはNVLinkドメイン内にあることを保証し、クロスノード通信によるパフォーマンス低下を回避します。

package scheduler

import (
    "k8s.io/kubernetes/pkg/scheduler/framework"
)

type GPUScheduler struct {
    topologyAware bool
    numaNodes     map[int][]GPUDevice
}

type GPUDevice struct {
    ID        int
    NodeID    int
    MemoryGB  int
    BusID     string
    NVLink    []int
}

func (s *GPUScheduler) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) {
    gpuClaim := extractGPUClaim(pod)
    if gpuClaim == nil {
        return 0, nil
    }

    devices := s.getAvailableDevices(nodeName)
    if len(devices) < gpuClaim.Count {
        return 0, nil
    }

    selected := s.selectOptimalDevices(devices, gpuClaim.Count)
    
    score := int64(0)
    if s.areOnSameNVLinkDomain(selected) {
        score += 100
    } else if s.areOnSameNUMANode(selected) {
        score += 70
    } else {
        score += 30
    }

    if s.hasEnoughMemory(selected, gpuClaim.MemoryPerGPU) {
        score += 50
    }

    return score, nil
}

func (s *GPUScheduler) areOnSameNVLinkDomain(devices []GPUDevice) bool {
    if len(devices) <= 1 {
        return true
    }
    firstNode := devices[0].NodeID
    for _, d := range devices[1:] {
        if d.NodeID != firstNode {
            return false
        }
        connected := false
        for _, link := range d.NVLink {
            if link == devices[0].ID {
                connected = true
                break
            }
        }
        if !connected {
            return false
        }
    }
    return true
}

三、vLLM推論エンジン本番最適化

3.1 Continuous BatchingとPagedAttention

vLLMのコアイノベーションはContinuous BatchingとPagedAttentionの2つのメカニズムにあります。Continuous Batchingは現在のバッチの実行中に新規リクエストを動的に挿入することを可能にし、従来のStatic Batchingの待ち時間の無駄を回避します。PagedAttentionはオペレーティングシステムの仮想メモリのページングメカニズムを応用し、KV Cacheを固定サイズのBlockに分割し、オンデマンドで割り当てと回収を行い、KV CacheのGPUメモリ断片化問題を解決します。

本番級vLLMデプロイメントの主要パラメータ設定：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen3-72b
  namespace: llm-inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm-qwen3-72b
  template:
    metadata:
      labels:
        app: vllm-qwen3-72b
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8000"
        prometheus.io/path: "/metrics"
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:v0.8.0
        command:
        - python
        - -m
        - vllm.entrypoints.openai.api_server
        - --model
        - Qwen/Qwen3-72B-Instruct-AWQ
        - --tensor-parallel-size
        - "4"
        - --gpu-memory-utilization
        - "0.92"
        - --max-model-len
        - "32768"
        - --max-num-seqs
        - "256"
        - --block-size
        - "16"
        - --swap-space
        - "8"
        - --enable-prefix-caching
        - --enable-chunked-prefill
        - --speculative-decoding-model
        - Qwen/Qwen3-7B-Instruct
        - --num-speculative-tokens
        - "5"
        - --port
        - "8000"
        ports:
        - containerPort: 8000
        resources:
          claims:
          - name: gpu-claim
        env:
        - name: VLLM_WORKER_MULTIPROC_METHOD
          value: "ray"
        - name: VLLM_ATTENTION_BACKEND
          value: "FLASHINFER"
        volumeMounts:
        - name: model-cache
          mountPath: /root/.cache/huggingface
        - name: shm
          mountPath: /dev/shm
      volumes:
      - name: model-cache
        persistentVolumeClaim:
          claimName: model-cache-pvc
      - name: shm
        emptyDir:
          medium: Memory
          sizeLimit: "16Gi"

3.2 Speculative Decoding最適化

Speculative Decoding（推測デコーディング）は2026年のLLM推論において最も重要な最適化技術の一つです。コアアイデアは、小規模モデル（Draft Model）を使用して候補トークンシーケンスを高速生成し、大規模モデル（Verifier Model）で並列検証し、正しいトークンを受け入れ、誤ったトークンを拒否することです。

vLLMでSpeculative Decodingを有効にするには、Draft Modelと推測長の設定が必要です。実際のテストでは、Qwen3-72B + Qwen3-7Bの組み合わせで、チャットシナリオにおいて1.5x-2.5xの高速化を実現し、出力品質の低下はありません。

from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen3-72B-Instruct-AWQ",
    speculative_model="Qwen/Qwen3-7B-Instruct",
    num_speculative_tokens=5,
    speculative_max_model_len=32768,
    tensor_parallel_size=4,
    gpu_memory_utilization=0.92,
    enable_prefix_caching=True,
    enable_chunked_prefill=True,
)

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=2048,
)

outputs = llm.generate(
    prompts=["量子コンピューティングの基本原理を説明してください"],
    sampling_params=sampling_params,
)

3.3 量子化とモデル圧縮

モデル量子化は推論コスト削減のコア手法です。2026年の主流な量子化スキームには以下が含まれます：

量子化スキーム 精度ロス メモリ節約 推論高速化 適用シナリオ
AWQ 4bit < 1% 60-70% 1.2-1.5x 本番首选
GPTQ 4bit 1-2% 60-70% 1.1-1.3x 互換性良好
FP8 < 0.5% 50% 1.5-2x H100/H200
GGUF Q4_K_M 1-3% 65-75% 1.0-1.2x CPU推論

AWQ（Activation-aware Weight Quantization）は現在の本番環境における首选スキームであり、重要なウェイトチャネルを保護することで量子化ロスを最小化します。Qwen3-72Bモデルの場合、AWQ 4bit量子化後は約38GBのメモリのみが必要で、2枚のA100-80GBで実行可能であり、FP16の144GB要件と比較して大幅に削減されます。

四、KEDAオートスケーリングとトラフィックルーティング

4.1 KEDAカスタムメトリクススケーリング

KubernetesネイティブHPAはCPU/メモリメトリクスのみをサポートしており、LLM推論シナリオのオートスケーリング要件を満たせません。KEDA（Kubernetes Event-Driven Autoscaling）はカスタムメトリクスベースのスケーリングをサポートし、LLM推論プラットフォームのオートスケーリングに最適な選択肢です。

コアスケーリングメトリクス：

  • リクエストキュー深度：vLLMが公開するvllm:num_requests_waitingメトリクス、保留中のリクエスト数を反映
  • GPU利用率：DCGM_FI_DEV_GPU_UTILメトリクス、GPU計算リソースの使用率を反映
  • 平均リクエストレイテンシ：カスタムメトリクス、サービス品質を反映
  • アクティブシーケンス数：vllm:num_requests_runningメトリクス、現在処理中のリクエスト数を反映
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: vllm-scaler
  namespace: llm-inference
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-qwen3-72b
  minReplicaCount: 1
  maxReplicaCount: 10
  cooldownPeriod: 120
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: vllm_requests_waiting
      threshold: "10"
      query: |
        sum(vllm:num_requests_waiting{deployment="vllm-qwen3-72b"})
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: vllm_avg_latency
      threshold: "2000"
      query: |
        histogram_quantile(0.95, 
          sum(rate(vllm:e2e_request_latency_seconds_bucket{deployment="vllm-qwen3-72b"}[2m]))
          by (le)
        ) * 1000
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleUp:
          stabilizationWindowSeconds: 30
          policies:
          - type: Pods
            value: 2
            periodSeconds: 60
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Pods
            value: 1
            periodSeconds: 120

4.2 予測スケーリング

履歴トラフィックパターンに基づく予測スケーリングは2026年の最先端プラクティスです。過去N日間のリクエスト量時系列を分析し、ProphetやLSTMモデルを使用して今後1時間のトラフィックを予測し、トラフィックピークに備えて事前にスケールアウトします。

import pandas as pd
from prophet import Prophet
from kubernetes import client, config

class PredictiveScaler:
    def __init__(self, deployment_name: str, namespace: str):
        self.deployment_name = deployment_name
        self.namespace = namespace
        config.load_incluster_config()
        self.apps_v1 = client.AppsV1Api()

    def predict_and_scale(self, metrics_df: pd.DataFrame):
        model = Prophet(
            changepoint_prior_scale=0.05,
            seasonality_prior_scale=10,
            daily_seasonality=True,
            weekly_seasonality=True,
        )
        model.fit(metrics_df)
        future = model.make_future_dataframe(periods=60, freq='min')
        forecast = model.predict(future)
        
        predicted_requests = forecast.tail(60)['yhat'].max()
        current_replicas = self._get_current_replicas()
        
        target_replicas = max(1, int(predicted_requests / 50))
        target_replicas = min(target_replicas, 10)
        
        if target_replicas != current_replicas:
            self._scale_to(target_replicas)
            print(f"Scaled from {current_replicas} to {target_replicas} replicas")

    def _get_current_replicas(self) -> int:
        deployment = self.apps_v1.read_namespaced_deployment(
            self.deployment_name, self.namespace
        )
        return deployment.spec.replicas

    def _scale_to(self, replicas: int):
        self.apps_v1.patch_namespaced_deployment_scale(
            self.deployment_name,
            self.namespace,
            body={"spec": {"replicas": replicas}},
        )

4.3 トラフィックルーティングと負荷分散

LLM推論のトラフィックルーティングでは、モデルバージョン、リクエスト優先度、バックエンド負荷を考慮する必要があります。Ingressの代わりにGateway APIを使用し、よりきめ細かいトラフィック制御を実現することを推奨します。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-route
  namespace: llm-inference
spec:
  parentRefs:
  - name: llm-gateway
  rules:
  - matches:
    - headers:
      - type: Exact
        name: X-Model-Version
        value: canary
    backendRefs:
    - name: vllm-qwen3-72b-canary
      port: 8000
      weight: 100
  - backendRefs:
    - name: vllm-qwen3-72b-stable
      port: 8000
      weight: 90
    - name: vllm-qwen3-72b-canary
      port: 8000
      weight: 10

五、モデルロードとKV Cache管理

5.1 モデルホットロードとプリロード

大規模モデルのコールドスタート時間はユーザー体験に影響する重要な要素です。Qwen3-72B AWQ量子化モデルをディスクからGPUにロードするには約30-60秒かかります。以下の戦略により5-10秒に最適化できます：

モデルプリロード：Pod起動時にモデルをGPUにロードし、Readiness Probeでモデルの準備完了を確認してからトラフィックをルーティング。

モデルキャッシュ：PVCを使用してモデルファイルを永続化し、スケールアウトのたびにリモートからダウンロードするのを回避。ModelCache DaemonSetと組み合わせてクラスタノードでよく使うモデルを事前キャッシュ。

階層ロード：まずモデル構造（数MB）をロードし、次にウェイト層をオンデマンドでロード。チャットシナリオでは、Embedding層と最初の数層のTransformerを先にロードし、最初のトークンに素早く応答。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: model-cache-daemon
  namespace: llm-inference
spec:
  selector:
    matchLabels:
      app: model-cache-daemon
  template:
    metadata:
      labels:
        app: model-cache-daemon
    spec:
      containers:
      - name: cache-loader
        image: python:3.11-slim
        command:
        - bash
        - -c
        - |
          pip install huggingface_hub
          python -c "
          from huggingface_hub import snapshot_download
          models = [
              'Qwen/Qwen3-72B-Instruct-AWQ',
              'Qwen/Qwen3-14B-Instruct-AWQ',
              'Qwen/Qwen3-7B-Instruct',
          ]
          for m in models:
              snapshot_download(m, cache_dir='/models')
          "
          sleep infinity
        volumeMounts:
        - name: model-cache
          mountPath: /models
      volumes:
      - name: model-cache
        hostPath:
          path: /data/model-cache
          type: DirectoryOrCreate

5.2 KV Cache最適化

KV CacheはLLM推論においてGPUメモリを最も多く消費する部分です。32Kコンテキスト長のリクエストの場合、KV Cacheは10GB以上のメモリを占有する可能性があります。最適化戦略には以下が含まれます：

Prefix Caching：同じSystem Promptを共有するリクエストに対し、共通プレフィックスのKV Cacheをキャッシュし、重複計算を回避。vLLMでは--enable-prefix-cachingで有効化。

KV Cache量子化：KV CacheをFP16からFP8またはINT8に量子化し、メモリ使用量を半減。精度ロスは無視できるレベル。

Sliding Window Attention：超長コンテキストの場合、最近のWトークンのKV Cacheのみを保持し、より古いKVペアを破棄。長文要約などのシナリオに適用。

from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen3-72B-Instruct-AWQ",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.92,
    max_model_len=32768,
    enable_prefix_caching=True,
    kv_cache_dtype="fp8",
    block_size=16,
)

5.3 GPUメモリプーリングと共有

マルチモデル共存デプロイシナリオでは、異なるモデルの推論Pod間でGPUメモリの無駄が生じる可能性があります。GPUメモリプーリング技術により、GPUメモリを共有リソースプールとして抽象化し、オンデマンドで割り当てと回収を行います。

NVIDIAのGPU OperatorとMPS（Multi-Process Service）の組み合わせにより、複数のプロセスが同じGPUの計算能力を共有しつつ、メモリ分離を保証できます。小規模モデル推論シナリオ（7B-14Bなど）では、1枚のA100で4-6個の推論インスタンスを同時実行可能です。

六、カナリアデプロイとA/Bテスト

6.1 モデルバージョンカナリアデプロイ

LLM推論プラットフォームのカナリアデプロイでは、複数のモデルバージョンを同時に管理し、段階的にトラフィックを切り替える必要があります。コアプロセス：

  1. 新バージョンのデプロイ：新Deploymentに新モデルバージョンをデプロイ、トラフィックはルーティングしない
  2. スモークテスト：内部テストエンドポイントを通じて新モデルの出力品質とレイテンシを検証
  3. カナリアリリース：1%のトラフィックを新バージョンにルーティング、エラー率とレイテンシをモニタリング
  4. 段階的ロールアウト：新バージョンのトラフィック割合を段階的に増加（1% → 5% → 20% → 50% → 100%）
  5. 完全切替：異常がないことを確認後、全トラフィックを新バージョンに切替
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-canary-route
  namespace: llm-inference
spec:
  parentRefs:
  - name: llm-gateway
  rules:
  - backendRefs:
    - name: vllm-qwen3-72b-v2
      port: 8000
      weight: 5
    - name: vllm-qwen3-72b-v1
      port: 8000
      weight: 95
  filters:
  - type: ResponseHeaderModifier
    responseHeaderModifier:
      set:
      - name: X-Model-Version
        value: v2

6.2 A/Bテストと効果評価

LLMのA/Bテストにおけるコアの課題は出力品質の評価です。従来のソフトウェアのような決定的な出出力とは異なり、LLMの出力は確率的であり、統計的手法による評価が必要です：

  • 人手評価サンプリング：両バージョンの出力を人手で採点し、統計的有意性を計算
  • LLM-as-Judge：GPT-4などの強力なモデルを審査員として使用し、出力品質を自動評価
  • ビジネスメトリクス比較：両バージョンのユーザー満足度、会話ターン数、タスク完了率などのビジネスメトリクスを比較

七、モニタリング・アラートとトラブルシューティング

7.1 コアモニタリングメトリクス

LLM推論プラットフォームのモニタリングは、インフラ、推論エンジン、ビジネスの3つのレイヤーをカバーする必要があります：

インフラレイヤー：

  • GPU利用率、メモリ使用率、GPU温度
  • ノードCPU/メモリ/ネットワークIO
  • GPU Xidエラー（ハードウェア障害）

推論エンジンレイヤー：

  • リクエストレイテンシP50/P95/P99
  • スループット（tokens/s）
  • リクエストキュー深度
  • KV Cacheヒット率
  • Speculative Decoding受諾率

ビジネスレイヤー：

  • リクエスト成功率
  • 平均会話ターン数
  • ユーザー満足度スコア
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: llm-inference-alerts
  namespace: llm-inference
spec:
  groups:
  - name: llm.rules
    rules:
    - alert: LLMHighLatency
      expr: histogram_quantile(0.99, sum(rate(vllm:e2e_request_latency_seconds_bucket[5m])) by (le)) > 5
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "LLM inference P99 latency exceeds 5s"
    - alert: LLMQueueBacklog
      expr: sum(vllm:num_requests_waiting) > 50
      for: 3m
      labels:
        severity: critical
      annotations:
        summary: "LLM request queue backlog exceeds 50"
    - alert: GPUMemoryExhaustion
      expr: DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_TOTAL > 0.95
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "GPU memory usage exceeds 95%"
    - alert: GPUXidError
      expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
      labels:
        severity: critical
      annotations:
        summary: "GPU Xid error detected, possible hardware failure"

7.2 よくあるトラブルシューティング

障害現象 考えられる原因 調査方法
OOM Kill KV Cache過大 / モデルメモリ超過 gpu_memory_utilizationとmax_model_lenを確認
リクエストタイムアウト キュー蓄積 / GPU利用率過高 num_requests_waitingとGPU利用率を確認
出力文字化け モデルロード不完全 / 量子化エラー モデルファイルの整合性を検証、量子化設定を確認
GPU利用率低 Batch Size過小 / リクエスト不均一 max_num_seqsを調整、トラフィック分布を確認
コールドスタート遅延 モデル未キャッシュ / ネットワーク帯域不足 PVCマウントを確認、モデルプリロードを有効化

7.3 ログとトレーシング

LLM推論リクエストのエンドツーエンドトレーシングは、API Gatewayから推論エンジンまでの完全なパスをカバーする必要があります。OpenTelemetry SDKを使用してvLLMにTrace Contextを注入し、リクエストレベルのエンドツーエンドトレーシングを実現することを推奨します。

八、まとめと展望

Kubernetes 1.30+はLLM推論プラットフォームに強力なGPUスケジューリングとオートスケーリング能力を提供します。本記事では、アーキテクチャ設計、DRA GPUスケジューリング、vLLM最適化、KEDAオートスケーリング、KV Cache管理、カナリアデプロイ、モニタリング・アラートの7つの観点から、本番級LLM推論プラットフォームの構築方法を体系的に解説しました。

主要ポイントの振り返り：

  1. DRAスケジューリング：K8s 1.30+のDRAメカニズムはGPUのパーティショニング、共有、動的調整を実現し、LLM推論プラットフォームのGPU管理の基盤となる
  2. vLLM最適化：Continuous Batching + PagedAttention + Speculative Decodingの組み合わせにより、推論スループットを2-5倍に向上
  3. オートスケーリング：KEDAのリクエストキュー深度とレイテンシに基づくカスタムメトリクススケーリングは、ネイティブHPAよりもLLMシナリオに適している
  4. KV Cache管理：Prefix Caching + KV Cache量子化 + Sliding Window Attentionは、メモリ最適化の三種の神器
  5. カナリアデプロイ：Gateway APIのウェイトベースルーティング + 統計的評価により、モデルバージョンのスムーズな切り替えを実現

今後、K8s DRAエコシステムの成熟とGPUハードウェアの進化（B200、GB200）に伴い、LLM推論プラットフォームはより高密度、より低コストの方向へ発展していくでしょう。FP8推論、KV CacheのCPU/SSDへのオフロード、マルチクラスタ連邦スケジューリングなどの技術が推論コストをさらに削減します。

関連記事

権威ある参考資料

ブラウザローカルツールを無料で試す →

#K8s 1.30#大模型推理#LLM部署#GPU调度#弹性伸缩#2026