COLUMN

コラム

2026年06月28日

KubernetesでLLM推論を本番運用する完全ガイド2026｜vLLM・KubeAI・llm-d徹底比較

2026年、生成AIを本番システムで動かすことが当たり前になった。しかし「LLMをKubernetes上に乗せたい」と思い立ったとき、多くのエンジニアが同じ壁にぶつかる。「vLLM、KubeAI、llm-dって全部違うの？どれを使えばいい？」「GPUコストが高すぎて社内稟議が通らない」「設定が複雑すぎて本番まで持っていけない」。

CNCFの2026年年次調査によれば、生成AIを運用している組織の66%がKubernetesで推論ワークロードを実行している（K8s本番運用率は82%）。もはやKubernetes × LLM推論は特別な取り組みではなく、業界標準だ。

この記事では、Kubernetes上でLLM推論を本番稼働させるために必要な知識を体系的に解説する。ツールの選び方から実践的な構成、GPUコスト削減のコツまで、迷わず動かせるレベルまで一気に掘り下げる。

なぜKubernetesがLLM推論のスタンダードになったのか

LLM推論の基盤としてKubernetesが選ばれる理由は、単純に「コンテナが動く」からではない。AIワークロード特有の課題を解決する3つの強みがある。

① スケーラビリティと柔軟性
LLM推論はリクエスト数によって必要なGPUリソースが大きく変動する。Kubernetesのオートスケーリング機能を使えば、アイドル時はゼロにスケールダウンしてコストを削減し、トラフィックが急増したときだけGPUノードを起動できる。

② エコシステムの充実
vLLM、KubeAI、llm-d、Kueueなど、AI推論に特化したKubernetesネイティブのツール群が2025〜2026年にかけて急速に成熟した。CNCF（Cloud Native Computing Foundation）がこれらのプロジェクトを積極的に取り込み、標準化が進んでいる。

③ 標準化の加速：KARs v1.35
2026年3月、CNCFは「Kubernetes AI Requirements（KARs）v1.35」を発表した。安定したIn-Place Podリサイジング、ワークロード対応スケジューリング、高性能Pod間通信が必須要件として定義され、31の認定プラットフォームが対応済みだ。この標準化により、ベンダーロックインを避けながらマルチクラウド・オンプレミスで一貫したAI推論基盤を構築できるようになった。


LLM推論の基礎知識：なぜ普通のWebアプリと違うのか

KubernetesでLLM推論を動かす前に、その特殊性を理解しておく必要がある。LLM推論は通常のWebアプリケーションとはリソース特性がまったく異なる。


推論処理の3フェーズ

LLMが1つのレスポンスを生成するまでに、内部では3つのフェーズが実行される。

  • トークン化（CPU集約）：入力テキストをモデルが処理できるトークン列に変換する。CPUで処理されるため、比較的軽量。
  • Prefill（プリフィル）（GPU計算集約）：入力トークン全体を並列に処理してKey-Valueキャッシュ（KVキャッシュ）を生成する。GPUの計算能力がフル稼働する最も重い処理。このフェーズの終了時間が「TTFT（Time To First Token）」＝最初のトークンが返るまでの時間に直結する。
  • Decode（デコード）（GPUメモリ帯域集約）：生成されたトークンを1つずつ順番に出力する。GPUのメモリ帯域が律速となる。1トークンあたりの生成時間が「TPOT（Time Per Output Token）」だ。

ユーザーが体感するレイテンシ ＝ TTFT ＋（TPOT × 生成トークン数）


KVキャッシュ最適化が鍵になる理由

PrefillフェーズではKVキャッシュが大量のGPUメモリを消費する。同じプレフィックス（システムプロンプトなど）を持つリクエストが来た場合、KVキャッシュを再利用することで計算を大幅に省ける。このキャッシュ管理の巧拙がスループットとコストに直接影響する。後述するvLLMの「PagedAttention」やllm-dのインテリジェントルーティングは、このKVキャッシュ最適化を中心に設計されている。


2026年のKubernetes AI推論ツール完全比較

2026年現在、Kubernetes上でLLM推論を実行するための主要ツールは以下の5つだ。用途・規模・チーム体制によって最適な選択が変わる。

  • vLLM（推論エンジン）：小〜中規模向け。PagedAttention・OpenAI互換API・シンプルさが最大の強み。2026年のデファクトスタンダード推論エンジン。
  • KubeAI（K8s推論オペレーター）：小〜中規模向け。スケールゼロ・Istio/Knative不要・運用コスト低が強み。
  • llm-d（分散推論フレームワーク）：大規模向け。Disaggregated Inferenceにより13.9倍のスループット向上を実現。CNCFサンドボックスプロジェクト。
  • KServe（モデルサービング基盤）：中〜大規模向け。カナリアデプロイ・K8sネイティブオートスケーリングに強み。
  • Kueue（GPUジョブキュー）：全規模対応。フェアシェアスケジューリングでGPU利用率を最大2.4倍に改善。

選択フローチャート

まずはvLLM単体で動作確認してから本番化の方針を決めよう。

  • モデルが70Bパラメータ未満・チーム5人以下 → KubeAI + vLLM（シンプル・低コスト）
  • 70B以上・月間APIリクエスト1億以上・マルチモデル → llm-d + vLLM + KServe（エンタープライズ構成）
  • 複数チームでGPUを共有したい → Kueueを追加（全構成に有効）

各ツールの詳細

vLLM
PagedAttentionとContinuous Batchingを核に持つLLM推論エンジン。OpenAI互換のREST APIをそのまま提供するため、既存のアプリケーションをほぼ変更なしに移行できる。2026年のデファクトスタンダードとして、後述するすべてのツールのバックエンドとして機能する。

KubeAI
「本番向けAI推論をKubernetesで最も簡単に動かす」というコンセプトのオペレーター。v0.23.2からIstioやKnativeへの依存が完全になくなり、バニラのKubernetesクラスターで動作する。最大の特徴はスケールゼロ（Scale to Zero）：アイドル時はPodを0台に落とし、リクエストが来た瞬間に起動してコストを最小化する（コールドスタートは30〜120秒）。さらにKVキャッシュを意識したプレフィックス対応ロードバランシングを内蔵しており、同一プレフィックスのリクエストを同じPodに転送してキャッシュヒット率を高める。

llm-d（CNCF Sandboxプロジェクト）
2026年3月24日、GoogleとRed Hat・IBM Research・CoreWeave・NVIDIAが共同でCNCFサンドボックスに寄贈したKubernetesネイティブの分散推論フレームワーク。「あらゆるモデル・あらゆるアクセラレータ・あらゆるクラウド」をビジョンに掲げる。

最大の特徴はDisaggregated Inference（分離推論）：PrefillとDecodeを別々のワーカープールに分離し、それぞれ独立してスケーリングする。実測値ではTTFT（初回トークンまでの時間）35%以上短縮、P95テールレイテンシ52%改善、KVキャッシュヒット率35% → 70%（2倍）、250同時ユーザー時のスループットはGPU-only比で13.9倍を記録している。

Kueue
GPUリソースをチーム間でフェアに配分するジョブキューイングシステム。Kueueの導入により、GPU利用率が25〜35%から60〜85%まで改善したという報告がある（最大2.4倍）。複数チームや複数のLLMプロジェクトがGPUクラスターを共有する場合は、他のツールと組み合わせて必ず導入したい。


【実践】vLLM + KubeAIで本番LLM推論環境を構築する

ここからは、KubeAI + vLLMによる本番構成の実践ガイドを解説する。KubeAIはHelmチャートで10分程度でインストールでき、小〜中規模の本番環境を迅速に立ち上げられる。


ステップ1：KubeAIのインストール

KubeAIはHelm経由でインストールする。既存のKubernetesクラスター（v1.28以上）があれば、Istio・Knative等の追加依存なしにそのまま動かせる。

helm repo add kubeai https://charts.kubeai.org
helm repo update
helm install kubeai kubeai/kubeai --namespace kubeai-system --create-namespace


ステップ2：モデルのデプロイ

KubeAIはAIModelというCustom Resource（CR）でモデルを管理する。minReplicas: 0を設定するだけでスケールゼロが有効になり、リクエストが来るとKubeAIが自動的にPodを起動し、アイドル時は0台に戻す。

apiVersion: kubeai.org/v1
kind: AIModel
metadata:
  name: llama-3-1-8b
spec:
  model: ollama://llama3.1:8b
  minReplicas: 0      # スケールゼロ有効
  maxReplicas: 3
  resourceProfile: nvidia-gpu-l4:1


ステップ3：モニタリングの設定

本番運用には以下のメトリクスの監視が必須だ。vLLMは/metricsエンドポイントでPrometheus形式のメトリクスを標準公開しているため、追加設定なしで収集できる。

  • TTFT（Time To First Token）p99：ユーザー体験の最重要指標。Prometheusで収集し、Grafanaで可視化する
  • KVキャッシュ利用率：75〜80%を超えると急激にレイテンシが悪化する。この値をKEDA（Kubernetes Event-driven Autoscaling）のスケーリングトリガーとして使うのが推奨パターン
  • リクエストキューの深さ：バックプレッシャーの検知に使う


大規模運用に進むなら：llm-dとDisaggregated Inferenceの世界

KubeAI + vLLMで限界が見えてきたら、次のステップはllm-dによるDisaggregated Inference（分離推論）への移行だ。特に以下のケースで効果が大きい。

  • モデルサイズが70Bパラメータ以上（単一GPUに収まらない）
  • 月間APIリクエストが1億を超える（スケールアップのコストが無視できない）
  • 低レイテンシが要件（TTFT 500ms以下などSLAが厳しい）
  • 複数モデルを同一クラスターで運用する

llm-dアーキテクチャの概要

llm-dは3層で構成される。EPP（Endpoint Picker）がリアルタイムでKVキャッシュの状態を監視し、「このリクエストはどのPodが最もキャッシュヒット率が高いか」を判断してルーティングする。これにより、同じプロンプトプレフィックスを持つリクエストが自然に同じPodに集まり、キャッシュヒット率が35%から70%へと倍増する。

  • agentgateway / GKE Inference Gateway：インテリジェントルーティング層。KVキャッシュヒット率・キュー深さでリアルタイム最適Pod選択
  • llm-d Endpoint Picker（EPP）：中間調停レイヤー。各Podの負荷状況を収集・判断
  • Prefill / Decode ワーカー群：vLLMバックエンドを分離運用。計算集約とメモリ集約のノードを使い分け


GPUコストを削減するための実践的な設定

AI推論基盤で最も大きなコスト要因はGPUだ。G5・G6・P5インスタンスは1時間あたり数十ドルに達する。以下の設定を組み合わせることで、GPUコストを大幅に削減できる。


① Kueueによるフェアシェアスケジューリング

複数のチームやプロジェクトが同じGPUクラスターを使う場合、Kueueを導入するだけでGPU利用率が25〜35%から60〜85%に改善する。先着順のジョブキューで「頭詰まり（Head-of-Line Blocking）」を防ぎ、GPUを遊ばせる時間を最小化する仕組みだ。


② スケールゼロ設定のトレードオフ管理

KubeAIのスケールゼロ機能は強力だが、コールドスタートに30〜120秒かかる。用途に応じてminReplicasを調整しよう。

  • 社内ツール・低頻度利用：minReplicas: 0（コスト最優先）
  • ユーザー向けAPI：minReplicas: 1（レイテンシ優先）
  • 24/7高頻度：minReplicas: 2以上（可用性優先）

③ vLLMのKVキャッシュ最適化

vLLMのデプロイ時に以下の2つのオプションが特に効果的だ。--gpu-memory-utilizationを高くすればKVキャッシュが増えてスループットが上がるが、OOM（Out of Memory）リスクも上がる。まず0.85で動かして負荷テストで調整するのが安全だ。

--gpu-memory-utilization 0.90   # GPUメモリの90%をKVキャッシュに使用
--enable-prefix-caching          # プレフィックスキャッシュを有効化


まとめ

Kubernetes上でLLM推論を本番運用するための要点をまとめる。

  • まず vLLM + KubeAI から始める：PoCから本番まで10〜14日で構築できる最速スタートライン
  • 大規模化・低レイテンシが必要になったら llm-d へ：Disaggregated Inferenceでスループット最大13.9倍、TTFT 35%短縮を実現
  • GPUコスト削減には Kueue + スケールゼロ + KVキャッシュ最適化の三点セットが有効
  • KARs v1.35対応プラットフォームを選ぶことで、ベンダーロックインを避けながら標準化の恩恵を受けられる

これらの構成を自社で一から構築・運用するのは、相応のKubernetesとMLOpsの知識が必要だ。「AIワークロードに対応したK8s基盤を手早く用意したい」「GPU管理やスケーリングの運用負荷を下げたい」という場合は、マネージドKubernetes基盤という選択肢も検討してほしい。

オンプレで選ばれるマネージドコンテナ『Kubo』の詳細はこちら。



こちらの記事もあわせてお読みください

役に立ったら、記事をシェアしてください
最新コラム
コラム一覧を見る→
AI駆動開発セミナー

AI駆動開発セミナーを導入いただいた企業様の事例をご紹介

事例を見る→
Contact Usお問い合わせはこちら