powered by TechFeed
表示モード
Deep Dive

KubernetesはAI時代に置き換えられなかった — 推論ワークロードの66%が既存基盤上で動いている現実

9月10日、Cloud Native Nowが「Kubernetes Did Not Miss the AI Wave. It Absorbed It」と題した記事を公開した。KubernetesがAIワークロードを別スタックとして切り離すことなく、既存のクラウドネイティブ基盤の中に取り込んで進化している実態について詳しく紹介されている。

9月10日、Cloud Native Nowが「Kubernetes Did Not Miss the AI Wave. It Absorbed It」と題した記事を公開した。KubernetesがAIワークロードを別スタックとして切り離すことなく、既存のクラウドネイティブ基盤の中に取り込んで進化している実態について詳しく紹介されている。


「AIにはKubernetesは古すぎる」という予測は外れた

新たなワークロードが登場するたびに「既存のインフラスタックは時代遅れになる」という声が上がる。AIブームでもそれは繰り返された。GPUという特殊ハードウェア、巨大なモデル、通常のWebサービスとは異なるトラフィックパターン——これらを理由に、AIには新たなクリーンスレートのプラットフォームが必要だと言われた。

実際には違った。

CNCFの2025年次調査(※元記事内で言及されているCNCF調査。URLの正確な公開パスについてはCNCFレポートページから最新版を確認されたい)によると、コンテナユーザーの82%が本番環境でKubernetesを運用しており、生成AIモデルをホストしている組織の66%がKubernetesを推論(インファレンス)に利用している。AIワークロードがKubernetes上に移ってきた理由は、推論サーバーがWebサービスと同じだからではない。「制御の問題」が既存の概念と重なっていたからだ——長期稼働プロセスの配置、高価なリソースの割り当て、ゲートウェイ経由の公開、スケーリング、オブザーバビリティ、セキュリティ、バージョン管理。これらは全てKubernetesが得意とする領域である。


標準化の動きが「答え合わせ」になっている

最も注目すべき動きは標準化の進展だ。CNCFは2025年11月にCertified Kubernetes AI Conformance Programを立ち上げ、当初18プラットフォームが参加。2026年3月のKubeCon EU(※元記事では正式イベントとして言及されている。最新の公式情報はKubeCon公式サイトから確認されたい)時点では31プラットフォームに拡大し、エージェント型ワークロードも対象に加わった。

参加企業のラインナップが象徴的だ。Amazon EKS、Google GKE、Microsoft Azure、Oracle Cloud Infrastructure、VMware vSphere Kubernetes Service、CoreWeave、Red Hat OpenShift、Akamai——ハイパースケーラー、プライベートクラウド、オンプレミス製品、GPU特化クラウド(ネオクラウド)、エッジプロバイダーが一つのコミュニティ標準に署名している。

業界が合意したのは「どこで動かすか」ではなく、「どう動かすか」だ。


コアAPIレベルでの実装:数字が示す効果

標準化はペーパー上の話だけではない。Kubernetesのコアには具体的な機能が追加されている。

  • Dynamic Resource Allocation(DRA): GPUなどのアクセラレータをKubernetesのコアAPIから直接リクエスト可能にする仕組み
  • Kueue: CPUやメモリと同様に、GPUリソースのクォータ管理とジョブキューイングを行うコンポーネント
  • Gateway API Inference Extension: モデルの認識、リクエストの優先度付け、KVキャッシュの局所性に基づく負荷分散をゲートウェイレイヤーに追加

元記事が引用するTechstrongのレポート(元記事内で参照されている計測データ。出典の一次情報はTechstrongが公開したレポートであり、元記事経由での引用である点に留意)では、これらが実際に効果を示している。多段階の推論評価において、Kueueは総処理時間(makespan)を最大15%削減し、Dynamic Resource AllocationベースのアクセラレータスライシングはジョブのMean Completion Timeを36%短縮Gateway API Inference Extensionとllm-dの組み合わせは負荷下でのTail Time to First Tokenを最大90%改善した。

なお、「Dynamic Accelerator Slicer」という呼称は元記事内での表記に基づいている。DRAの公式ドキュメント上の正式名称とは表記が異なる可能性があるため、実装を検討する際は公式ドキュメントの最新の用語定義を参照されたい。


企業のAI問題は「モデル研究」ではなく「運用」の問題

元記事が指摘する視点は現場のエンジニアに刺さる内容だ。CNCFの調査によると、AIモデルをデイリーデプロイしている組織はわずか7%で、半数以上の企業はモデルのトレーニング自体を行っていない

大半の企業がやっていることは、学習済みモデルを調達してきて、それを安全・安定・低コストで提供することだ。つまり企業におけるAIの課題は、ルーティング、キャパシティ管理、クォータ、アイデンティティ、オブザーバビリティ、コスト管理に集約される。これらはクラウドネイティブエコシステムが10年かけて解いてきた問題そのものである。

運用シグナルも変化している。レイテンシ・トラフィック・エラー・サチュレーションに加え、トークン消費量・リクエスト単価・出力品質・モデルの帰属情報が監視対象になりつつある。モデルレジストリはコンテナレジストリと並ぶ存在になり、プロンプトやエージェントはバージョン管理された本番設定として扱われる。


残る不確実性:上位レイヤーの争い

懸念点も記事は正直に書いている。AIゲートウェイ、評価プラットフォーム、エージェント制御プレーン、エージェントオブザーバビリティといった上位レイヤーは、まだオープン標準よりも商用ベンダーが速く動いている若いカテゴリだ。これらが独自仕様の制御ポイントとして固まってしまえば、ポータビリティは基盤レベルでは残っても、企業が最も影響を受けるレイヤーで失われる可能性がある。

AIは企業インフラに新たな独立スタックを生み出したのではなく、クラウドネイティブスタックに新たな仕事を与え、既存の仕組みを拡張させた——というのが記事の結論だ。

詳細はKubernetes Did Not Miss the AI Wave. It Absorbed Itを参照していただきたい。