AI の普及に伴い、クラウドネイティブエコシステムは、従来の一般的なウェブサービスやバッチ処理とは異なる要件に直面しています。希少なアクセラレータの共有、分散ワークロードの実行、モデルやデータの配置、状態を考慮した推論リクエストの処理など、AI/ML ワークロードに適した新しい仕組みが求められています。

本セッションでは、スケジューリングやサービングを主な切り口として、関連する Kubernetes/CNCF 周辺のプロジェクトや OSS の動向を概観します。Workload-Aware Scheduling (WAS), Kueue, Gateway API, Inference Extension などの技術が、AI/ML インフラにおいてどのような課題を解決し、どのような役割を担うのかを紹介します。

さらに、Preferred Networks の社内 AI/ML 基盤における実践を題材に、さまざまな要素技術がどのように連携し、AI/ML の実験・開発・学習・推論を支えるのかを説明します。AI/ML インフラに関心のある開発者やプラットフォームエンジニアを対象とした、エコシステムの全体像をつかむための入門セッションです。

SB Intuitionsでは、NVIDIA GB200 NVL72 で構成されたオンプレミスKubernetesクラスタを推論基盤として運用しています。 この上には、自社でフルスクラッチ開発したLLMおよびSTT/TTSモデルの商用ホスティングと、社内・グループ会社向けの検証用の大規模open-weightモデル提供という、特性の異なる多数のモデルが同居しています。

これらのモデル群を効率よくk8sクラスタでホスティングするためのInferenceプラットフォームをGateway API, Gateway API Inference Extension (GAIE), llm-dという、upstreamで標準化が進むスタックで構築しています。一方でこれらは "1モデル1InferencePool"、"OpenAI互換の /v1/chat/completions API" を暗黙の前提としており、社内の要求を満たせないケースがありました。本セッションではこのプラットフォームの技術要素と構築する際にあった技術的な課題について取り上げます。

具体的には、

• 多品種のモデルを共通の方法でデプロイ,払い出しするための仕組みを自前で用意する必要があった
• 2026年8月時点では、audioを入力にとる /v1/audio/transcriptions のようなエンドポイントをそのままでは扱えない
• vLLMにロードされた個々のLoRAアダプタ単位でのアクセス制御は標準では提供されていない

といった課題に対し、どのように対処したのかを紹介します。

With the rapidly growing demand for Agentic AI, it is essential to design a unified system that not only processes individual requests at high performance but also handles routing that takes long-term context and KV cache into account, manages model outputs involving tool usage, supports deployments spanning multiple GPUs and nodes on Kubernetes, and ensures operations that expect failures and updates.

In this session, we will provide an overview of the evolution of NVIDIA Dynamo since v1.0 - which reached general availability (GA) in March 2026 - as a set of features that constitute the Agentic AI infrastructure. As for the features for agents, we will introduce a mechanism that normalizes model-specific outputs into OpenAI-compatible responses in the case of tool calling and reasoning. Also, we will discuss how the agent harness can pass execution intent - such as priority and expected output length - as "Agent Hints," which Dynamo then incorporates into routing and scheduling. In long agent sessions, KV cache handling and routing become particularly important. We will explain the evolution of KV-aware routing, which has advanced in response to these demands. Related to this, there are options for routing deployment. In addition to the approach using the Dynamo Frontend, we will also introduce methods for working with Kubernetes Gateways together via the Gateway API Inference Extension (GAIE) and the Endpoint Picker Plugin (EPP). Furthermore, we will clarify the role of Grove in Kubernetes orchestration and discuss the deployment and scaling of AI workloads, including disaggregated serving. Finally, we’ll provide an overview of request migration, graceful shutdown, load control, fast model loading, trace replay, simulation, and other features from the perspective of the resiliency and validation required in real-world operations.

We'll provide the first step toward viewing Dynamo not merely as a high-speed inference server, but as an agent-aware, cloud-native, distributed and disaggregated inference platform that balances performance and operability.

This lightning talk will be conducted in English, but the presentation slides will have Japanese content. This talk presents an overview of KServe's network architecture in Serverless mode, which is backed by the Knative Serving platform and a service mesh, along with network security considerations for intra-cluster communication. By default, KServe doesn't offer any network security option, but we can implement network traffic restrictions at the service mesh level. This talk will showcase Istio's AuthorizationPolicy to control traffic from clients in tenant namespaces to KServe's AI inference endpoints in other namespaces.

日本語タイトル:共有GPUクラスタのまま、自由を増やす——少人数運用で試したvCluster 私たちは約4名のチームで、データセンター設備からKubernetesまで、社内向けオンプレGPU基盤を運用しています。 当初はAI研究者によるNotebookやGPUジョブの利用が中心で、Namespace単位の分離で十分でした。しかし、AIアプリケーション開発チームが増えるにつれ、CRDやOperatorを含むHelmチャートなど、Namespaceの権限だけでは扱いにくいアプリケーションを検証したいという要求が生まれました。 そこで、共有GPUクラスタを維持しながら利用者の自由度を高めるため、vClusterを導入しました。HostのNode情報を同期することで、GPUノードの指定には従来のYAMLをほぼそのまま利用でき、既存ワークロードを大きく変更せずに移行できました。 本LTでは、NodeやIngressなど、HostとvClusterの間で何を共有するかという設定を取り上げ、既存の操作性を維持しながら分離を追加するために得られた知見を紹介します。

AI エージェントが主流となりつつある時代、Kubernetes の運用はどう変わるのでしょうか。本セッションでは、CNCF Sandbox の kagent を実際に動かしながら、その問いを初心者目線で一緒に考えて行きます。

kagent を使うと、AI エージェントは特別な基盤ではなく Kubernetes 上の “普通のワークロード” として動きます。まず「エージェントとは何か（プロンプト＋モデル＋ツールの組み合わせ）」と「MCP（Model Context Protocol）という “道具のつなぎ方” 」を整理します。

そのうえでデモとして、CrashLoopBackOff・ImagePullBackOff・Service の設定ミスという “よくある3つの障害” を、エージェントがチャットで調査して直す様子をお見せします。ユーザー（デモ実行者）が行うことは「障害を仕組む」ことと「結果を確認する」ことだけです。調査も修復もエージェントが行います。生成 AI や MCP の予備知識は不要です。

そして最後に、動かしてみて見えてきた「AI エージェント時代の Kubernetes 運用」を考えます。運用者の役割が「操作する」から「意図を伝えて承認する」へ移っていくこと。実際に手を動かした実感をもとにお話しします。