AIワークロード基盤技術サーベイ

# AIワークロード基盤技術サーベイ Navigation: [[index]] | [[overview]] > [!abstract] 要旨 > 本稿は、AI ワークロードを Kubernetes 上で動かすための基盤技術を 4 層——**スケジューリング・オーケストレーション・デプロイスタック・エージェントワークロード**——に分けて体系化する。中心的な主張は 2 つある。第一に、この 4 層はいずれも「**既存の Kubernetes 抽象が単純化されすぎていた**」という共通の診断から出発し、それぞれ異なる軸(資源要求の表現力・スケジューリング単位・トラフィックルーティングの意味論・ワークロード形状そのもの)で抽象を刷新している。第二に、刷新の方法論は「**エコシステム実装をコアへ吸収する**」方向と「**コアは汎用に保ちレイヤーを重ねる**」方向の 2 つに分岐しており、両者の緊張が現在の設計論争の主軸をなす。 > > 本稿の記述はすべて本 wiki に取り込み済みのソースに基づく。カバレッジが薄い箇所は §8 に集約し、本文中でも `> [!gap]` で明示した。 --- ## 1. 序論 ### 1.1 問題設定 Kubernetes が事実上の標準となった根拠は、[[@2026__KubernetesBlog__Running Agents on Kubernetes with Agent Sandbox]] の整理によれば「拡張性・堅牢なネットワーキング・成熟したエコシステム」にある。しかしこれらはいずれも**ステートレスなマイクロサービス**を前提に磨かれた性質である。AI ワークロードはこの前提を 4 方向から破る。 1. **資源が線形量で表せない**。GPU は MIG スライス・MPS 共有・NVLink 接続性といった属性を持ち、「GPU を 1 個」という要求では表現しきれない([[Dynamic Resource Allocation (DRA)]])。 2. **スケジューリング単位が Pod 1 個でない**。分散訓練・マルチノード推論は Pod 集合が同時に起動しないと、資源を消費したまま何も提供しない([[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]])。 3. **リクエストが等価でない**。LLM 推論は応答長により計算コストが桁で変わり、KV キャッシュという再利用可能な状態を持つため、ラウンドロビン負荷分散が成立しない([[Gateway API Inference Extension]])。 4. **ワークロード形状そのものが新しい**。エージェントは孤立・ステートフル・シングルトンであり、訓練とも推論とも異なる第 3 の形状をとる([[Agent Sandbox]])。 ### 1.2 分類軸と本稿の構成本稿は上記 4 つの破れに対応する 4 層を立てる。 | 層 | 何を決めるか | 代表技術 | 本稿 | |---|---|---|---| | スケジューリング | **いつ・どの資源を・どこに** 割り当てるか | DRA, TAS, Kueue | §2 | | オーケストレーション | Pod 集合を**どういう形状の単位**として扱うか | JobSet, LeaderWorkerSet, Workload/PodGroup API | §3 | | デプロイスタック | 推論トラフィックを**どう受けてどこへ流すか** | KServe, NVIDIA Dynamo, llm-d, AIBrix, GAIE, AI ゲートウェイ | §4 | | エージェントワークロード | エージェントという**新形状をどう実行するか** | kagent, Agent Sandbox, Agent Substrate | §5 | §6 で層をまたぐ設計パターンを抽出し、§7 で未解決の論争点、§8 でカバレッジの限界を述べる。 --- ## 2. スケジューリング層この層は 3 つの独立した軸で刷新が進んでいる。**資源要求の表現力**(DRA)、**配置の物理的近接性**(TAS)、**受け入れ制御と公平性**(Kueue)である。3 者は別々の KEP・別々のリポジトリで進行しており、統合設計は存在しない。 ### 2.1 資源要求の表現力: Dynamic Resource Allocation(DRA) #### 2.1.1 何を解くか [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]](著者 [[Patrick Ohly]]([[Intel]])、作成 2024-01-05、sig-node 主導)は、従来のデバイスプラグイン API の限界を 4 点に整理する。 1. **デバイス初期化・クリーンアップ**: FPGA 再構成に必要な設定を渡す手段がなく、終了後のポストストップ処理もない。 2. **部分割当**: MIG や SR-IOV による分割利用に、事前分割・事前公開が必要で動的生成できない。 3. **オプショナル割当**: 「あれば使う、なければ CPU へフォールバック」を表現できない。 4. **ファブリック越しデバイス**: ノードローカル発見が前提のため、Akri のようなプロジェクトは接続可能な全ノードへ重複公開する回避策を強いられる。重要なのは、KEP が **Non-Goal を明示している**ことである。デバイスプラグイン API の置き換えではなく共存を前提とし、「何らかの GPU が欲しい」という抽象化レイヤーの提供もスコープ外とする。[[Dynamic Resource Allocation (DRA)]] は「単一の線形量で表現できるデバイスにはデバイスプラグイン API が引き続き適する」と要約する。 #### 2.1.2 API と「構造化パラメータ」 4 つのオブジェクトからなる。 - **ResourceSlice**: 各ノードの DRA ドライバがデバイス一覧を公開する。デバイスごとに `attributes`(型付き値)と `capacity` を持つ。`resource.kubernetes.io/` 名前空間は標準属性用に予約され、本 KEP は **`pcieRoot`・`pciBusID` の 2 属性**を標準化した(ノード内トポロジ整合のため)。 - **ResourceClaim / ResourceClaimTemplate**: 要求の宣言。`spec` は不変、`status`(`allocation`・`reservedFor`)がシステムに更新される。永続的 claim(複数 Pod 間共有)と ephemeral claim(Pod ごと自動生成、OwnerReference で GC)の 2 ライフサイクルを持つ。デバイス選択は `device` 変数を介した **CEL 式セレクタ**。`AllocationMode` は `ExactCount`(既定)と `All`。 - **DeviceClass**: クラスタスコープのプリセット。管理者専用の危険な設定(root で初期化コマンドを実行する等)をユーザー入力側に許可しない設計上の分離がある。「構造化パラメータ」という名称の本質は、**スケジューラが理解できる属性(attributes/capacity + CEL)と、スケジューラが解釈しない不透明なベンダー設定を分離した**点にある。後者は「スケジューラのデバイス選択には使われず、割当確定後に DRA ドライバへそのまま渡される」。 #### 2.1.3 実装と成熟度バージョン列は KEP の `kep.yaml` に基づき次のとおりである。**Kubernetes 1.30 でアルファ → 1.31 で `v1alpha3` API 刷新 → 1.32 でベータ(`v1beta1`)→ 1.33 で GA 相当構造の `v1beta2` → 1.34 で GA 昇格**。最新マイルストーンは v1.35。スケジューラ側は新設の claim plugin が 7 つの拡張点(`EventsToRegister`・`PreEnqueue`・`Pre-filter`・`Filter`・`Post-filter`・`Reserve`・`Unreserve`)で動作する。CEL 評価コストのため `Filter` は**既定 10 秒のタイムアウト**を持ち、`DRASchedulerFilterTimeout` フィーチャーゲートで無効化できる。性能は `scheduler_perf` 実測で**定常状態 Filter 約 10ms、5000pod/500node 充填時で最大 200ms**。ノード側は CSI を参考にした gRPC インターフェース(`k8s.io/kubelet/pkg/apis/dra`)で、`NodePrepareResource` / `NodeUnprepareResources` により DRA ドライバが **CDI(Container Device Interface)の JSON を生成して CDI デバイス ID を返す**。セキュリティ設計として注目すべきは、**kubelet が ResourceClaim への書き込み権限を意図的に持たない**点である。侵害された kubelet が割当結果を偽装して DoS を行うことを防ぐ。一方、DRA ドライバはハードウェア管理のため root 権限を要しがちで権限昇格リスクを持つこと、ephemeral claim を kube-controller-manager が自動作成するため **RBAC による ResourceClaim 作成制限が事実上回避され得る**ことも KEP 自身が明記している。 #### 2.1.4 GPU 分割機構との関係ここは誤解されやすい点であり、[[Dynamic Resource Allocation (DRA)]] が明快に整理している。 > DRA が解くのは「どの(既に分割された)デバイスをどの Pod に割り当てるか」というオーケストレーション判断であって、**デバイスをどう分割するか自体は DRA の管轄外**である。 KEP 自身、需要に応じてカードを動的再構成する機能はスコープ外であり "partitionable devices" 拡張(KEP #4815)へ委ねると明記する。したがって [[GPU多重化(MPS・MIG)]] が扱うハードウェア層——MIG は最大 7 インスタンスへ物理分割し `<X>g.<Y>gb` プロファイルで表現、MPS は複数プロセスの GPU コンテキストを統合して単独 40% 程度の利用率を合算 80〜90% へ引き上げるがメモリは分離しない——とは補完関係にある。なお Kubernetes の GPU time-slicing は「実行のオーバーラップは提供せず単に切り替えを速くするだけ」であり、高スループット用途では MPS/MIG が優位である。動的スライシングの実装例が [[Dynamic Accelerator Slicer]](DAS、[[Red Hat]]、`github.com/openshift/instaslice-operator`)である。MIG スライスを just-in-time に生成・破棄し、静的事前スライシングによる断片化を避ける。[[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]] の Whisper 転写ベンチマークでは、同時実行数を GPU 数 8 からスライス数 25 へ増やすことで**平均ジョブ完了時間 28→18 分(36% 削減)、中央値 28→16 分、P95 51→36 分**を達成した。ただし**スライスパディング**により平均 GPU 利用率はわずかに低下する(44%→38%)。2 つの `3g.20gb` を単一 A100 に置くと残余キャパシティが割当不能になり、一部 SM がアイドルのまま残るためである。 > [!gap] DAS が DRA ドライバとして実装されているかは wiki に記載なし。DAS は OpenShift オペレータとしてのみ記述されており、DRA との接続を述べた記述は存在しない。また GA 条件「異なる組織による実 DRA ドライバ実装 3 件以上」を実際にどのベンダーが満たしたかも記載なし。 ### 2.2 配置の物理的近接性: Topology Aware Scheduling(TAS) #### 2.2.1 位置づけの注意 [[@2024__KEP__KEP-2724 Topology Aware Scheduling]] は **Kubernetes コア本体の KEP ではなく [[Kueue]] リポジトリ内の KEP** である(作成 2024-07-30、著者は kubernetes-sigs/kueue、個人名の記載なし)。[[Kueue]] は「設計拡張を独自の KEP フォーマットでリポジトリ内 `keps/` に持ち、コア本体の KEP プロセスとは別系統で運用している」。v0.19 系まで継続改訂される「生きた」文書である。 #### 2.2.2 何を解くか動機は明快である。 > AI/ML の分散訓練・推論ワークロードは Pod 間で大量のデータを交換するため、**同一ラック・同一ブロック内に Pod が収まっているかどうかで実行時間・コストが最大 2 倍変わりうる**。 [[トポロジ考慮型スケジューリング]] は「トポロジ」を「データセンターの物理的階層構造(ラック・ブロック等)をノードラベルの規約として表現したもの」と定義する。同じラベル値がグローバルに一意である必要はなく、階層はノード集合の相対的近接関係のみを表す。 #### 2.2.3 API 管理者は `Topology` CRD で `levels`(**最大 8 レベル**のノードラベルキー)を定義し、`ResourceFlavor.spec.topologyName` で紐づける。ユーザーは PodTemplate アノテーションで要求する。 - `kueue.x-k8s.io/podset-required-topology` — 指定レベル内に全 Pod を収める必須制約。満たせなければキューで待機し続ける。 - `kueue.x-k8s.io/podset-preferred-topology` — 指定レベルから開始し、収まらなければ上位へ段階的に緩和。 - `kueue.x-k8s.io/podset-unconstrained-topology` — 制約なし。TAS の会計精度は活かしつつ配置は縛らない。 - `podset-slice-required-topology` + `podset-slice-size` — PodSet を固定サイズのスライスへ分割し、スライス単位で要求する。**JobSet の ReplicatedJob インスタンス単位の co-location** に使う。 - `podset-slice-required-topology-constraints` — 上記の多層拡張。coarsest から finest の順に `{topology, size}` の JSON 配列(**最大 3 層**)を指定し、GB200/GB300 のような複雑トポロジ向けに datacenter → aizone 64 台 → block 32 台 → rack 16 台といった多層シンメトリー配置を表現する。 required/preferred/unconstrained は相互排他であり、明示のない PodSet は暗黙に unconstrained として扱われる(採用の摩擦を減らすための後付け仕様)。 #### 2.2.4 中核の設計制約 TAS は**割当を必ずトポロジ階層の最下位レベル単位で確定させる**。理由はレース条件の防止である。block 単位で割り当てたワークロードが実際には 2 つの rack にまたがってバインドされると、その後 rack 単位で要求する別ワークロードが同じ rack を空きなしと誤判定する。この制約が `TopologyAssignment` のデータ構造設計全体を貫く。 admission 後の実配置は **`kueue.x-k8s.io/topology` スケジューリングゲート**で nodeSelector 注入を遅延させる形で kube-scheduler へ伝達される。これが admission 層と配置層を接続する具体的機構である。 #### 2.2.5 配置アルゴリズム 3 種類あり、単一の最適解は存在しない。 - **BestFit**: 空き容量が多いドメインから選び、最後のドメインだけ最適化する貪欲法。 - **LeastFreeCapacity**: 空き容量が少ないドメインから埋める。 - **BalancedPlacement**: 2 隣接レベルでのみ、選んだドメイン集合へ Pod を均等分配する。**Allgather のような all-to-all 通信**向けの GPU ネットワーキング特化設計。 v0.15 以降の既定は `TASProfileMixed`(preferred/required は BestFit、unconstrained は LeastFreeCapacity)である。[[トポロジ考慮型スケジューリング]] は「収まりはしても偏った配置(容量 10・10 のドメインに 12 Pod を (10, 2) で配置)がクロスドメイン通信を増やす」という具体例で BalancedPlacement の必要性を説明する。 #### 2.2.6 スケールと障害対応 `TopologyAssignment` の内部表現は **etcd の 1.5MiB 単一オブジェクト上限**により刷新された。v1beta1(ドメインごと 1 エントリ)は現実的なノード命名規則で**約 2〜3 万ノード**が限界であり、v1beta2 の `Slices` + 共通接頭辞/接尾辞抽出による圧縮で**約 6 万ノード**、ヒューリスティックなプレフィックスツリー剪定を伴う複数スライスで**10 万ノード超**へ拡張した。v0.19 で Beta 昇格した `TASAssignmentsEncodingByHostnamePrefix` はホスト名の共通プレフィックスを検出してスライスをグループ化する。ノード障害時は、専用コントローラが影響を受けた TAS ワークロードへ情報を伝搬し、**単一ノード障害かつプリエンプション不要な場合に限り**新しい割当を探索する。ここで重要なのは、**回復の成否がオーケストレーション層の所有構造に依存する**ことである。[[トポロジ考慮型スケジューリング]] は「[[LeaderWorkerSet]] のように Workload のコントローラが Pod を再作成できる構造では再割当が有効に機能する」一方、bare pod や Deployment レプリカのように Workload が単一 Pod と運命を共にする構造では「実際にまだ動いているノードを空きと誤って会計し(過剰 admission)、かつ新しい割当先ノードを他ワークロードから奪う」**二重の会計破損**が起きると述べる。v0.19 の `SkipReassignmentForPodOwnedWorkloads` はこの構造差で挙動を切り分ける。 #### 2.2.7 2 パス設計(Cluster Autoscaler 統合) ProvisioningRequest AdmissionCheck が設定された ClusterQueue では、スケジューラは**quota だけ予約して TAS 割当を保留**し、AdmissionCheck が Ready になった時点で "second pass" として割当を計算する(`DelayedTopologyRequest` フィールド)。新規ノードが GPU ドライバインストール待ちで NotReady の場合は**指数バックオフ(基準 10 秒、上限 5 分)**で再試行し、超過でワークロードを evict する。 [[トポロジ考慮型スケジューリング]] はこれを「TAS が『**まだ存在しない資源(将来のノード)への配置制約**』という時間軸の問題を抱えている」ことの表れとし、DRA が「デバイスの割当」という別軸を扱うのと対照させる。 ### 2.3 受け入れ制御と公平性: Kueue #### 2.3.1 位置づけ [[Kueue]](kubernetes-sigs/kueue)は **Job・JobSet・LeaderWorkerSet・MPIJob 等**を対象に ClusterQueue によるクォータ管理と admission 制御を行う。決定的に重要な性質は次である。 > **kube-scheduler そのものを置き換えるのではなく、その手前で「いつ・どれだけの Workload を admission するか」を決定する層として動作する。** すなわち Kueue は Pod スケジューラではない。配置は kube-scheduler が行い、Kueue は入口を絞る。 #### 2.3.2 アーキテクチャ階層は **LocalQueue(namespace スコープ、投入の入口)→ ClusterQueue(クラスタスコープ、リソース境界・優先度クラス・admission 制御)→ ResourceFlavor(具体的なリソース種別・容量プール)** である。複数の ClusterQueue は **Cohort** に属し、Cohort 内で **borrowing**(クォータ融通)が成立する。内部のスケジューリングは 2 フェーズに分かれる。**nomination**(各 Workload を独立に ResourceFlavor へ割当候補として評価)と **evaluation**(順に処理し実際に admission)である。この 2 段構成が §2.2.4 の TAS と衝突する。TAS はノード単位で決定論的に配置するため、nomination 時に fit と判定された Workload が evaluation 時には fit しなくなる頻度が通常の quota スケジューリングより格段に高い。この衝突は**多数の ClusterQueue を持つ環境で Workload が数時間 suspended のまま停滞する障害を実際に引き起こし**、v0.19 の `TASRecomputeAssignmentWithinSchedulingCycle`(Beta、既定有効)で修正された。[[トポロジ考慮型スケジューリング]] はこれを「**粒度が細かく決定論的なスケジューリングほど、2 段階評価アーキテクチャの整合性コストが上がる**」という一般教訓として抽出する。 #### 2.3.3 実測性能 [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]] が 96 ジョブ・3 回実行で測定した結果は次のとおり(実験環境: ROSA、GPU ノード 1 × `p4d.24xlarge`(A100 8 基)、OpenShift 4.19.16 / Kubernetes 1.32)。 | 構成 | メイクスパン中央値 [分] | キュー時間中央値 / P95 [分] | |---|---|---| | Pure Jobs(ベースライン) | 60.5 | 0.0 / 0.0 | | Kueue BestEffortFIFO | 62.5 | 16.7 / 39.5 | | + Priority(`WorkloadPriorityClass`) | 54.7 | 19.5 / 44.5 | | + Preemption | **51.1** | 25.0 / 41.9 | | 2 ClusterQueue + Borrowing | 55.0 | 13.7 / 32.4 | 優先度とプリエンプションの組み合わせでメイクスパンは**ベースライン比約 15% 改善**する。admission attempt duration は全構成で**99 パーセンタイルでも 25ms 未満**であり、スケジューリングロジック自体のオーバーヘッドは無視できる。注目すべきは、**素の Kubernetes Job(60.5 分)が Kueue BestEffortFIFO(62.5 分)より速かった**という結果を論文が正直に報告している点である。これは非決定的な実行順序による偶発的な結果であり、Kueue は**決定的で再現可能なスケジューリング順序**を保証する。[[コンテナオーケストレーション]] はこれを「ベストケースのメイクスパンを犠牲にしてでも**運用上の予測可能性を優先する**設計判断」と評価する。 > [!gap] Kueue のクォータモデルの形式的定義(nominal quota / borrowingLimit / lendingLimit)、プリエンプションポリシーの分類、gang admission(all-or-nothing)の機構、`Workload` CRD のフィールド定義はいずれも wiki に記載なし。エンティティページの記述の大半は TAS KEP と ICPE 論文からの間接記述に依存している。Kubeflow 統合も記載なし。 ### 2.4 WAS(workload-aware scheduling) > [!gap] **「WAS」という略語も、独立概念としての workload-aware scheduling も wiki には存在しない。** 存在するのは次の 3 つの断片のみである。 1. **KEP-5710(workload-aware preemption)への参照**。[[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]] によれば、v1.37 で `GenericWorkload`・`GangScheduling` の 2 フィーチャーゲートが `GenericWorkload` へ統合された際、KEP-5710 を制御する `WorkloadAwarePreemption` ゲートも同時に統合された。両 KEP のライフサイクルは完全に同期し、卒業基準を同時に満たす必要がある。ただし [[Kubernetes Workload・PodGroup API]] 自身が「**KEP-5710 の具体的な設計(ワークロード単位の victim 選定アルゴリズム)はまだ本 vault に取り込んでいない**」と明記している。 2. **キューイングの workload-aware 化**。KEP-4671 は 4 つの代替案(現行維持 / ソートロジック変更 / `QueuedPodGroupInfo` を既存キューへ格納 / `PodGroup` 専用の独立キュー)を比較し、**代替案 3(専用キュー)を長期的ベスト**として採用した。 3. **Kueue の `Workload` オブジェクト**。ただし §2.3.3 の gap のとおり定義は未記述である。 ### 2.5 研究史との対照 Kubernetes ネイティブ実装は、GPU クラスタスケジューリング研究が積み上げた理論の**多くを将来課題として先送りしている**。[[GPUクラスタスケジューリング]] が集約する研究群と対照すると構図が見える。 - **[[Philly]]**([[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]、Microsoft): YARN Fair Scheduler 基盤。**16 GPU ジョブの利用率が 2 サーバ 43.66% から 8 サーバ 28.56% へ低下**し、割り当て済み GPU の処理サイクル利用率は全ジョブ平均 52.32% にとどまった。局所性を「待ってから緩和する」運用ヒューリスティックとして扱った。 - **[[HiveD]]**(OSDI 2020): 本番 2,232 GPU クラスタで、クォータ十分なテナントが私有クラスタなら経験しないはずの**最大 1,000 分超**のキューイング遅延([[共有異常]])を実証した。決定的なのは、これが **YARN-CS / Gandiva / Tiresias という設計思想の異なる 3 スケジューラすべてで発生した**ことである。スケジューラの改良では解決できないため、セル階層による事前予約([[Virtual Private Cluster]])という別レイヤーの抽象を導入した。 - **[[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling|Themis]]**([[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling]]): ML ジョブが**ギャングスケジューリングを要し配置に敏感である**という 2 特性が、DRF や LAS の共有インセンティブ・パレート効率性・嫉妬自由性の同時達成を**不可能にする**ことを示した。仕上がり時間公平性を指標とし部分割り当てオークションを多ラウンド実施することで、公平性を既存比 **2.25 倍以上**改善した。 - **[[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]]**(SC17)は KEP-2724 に **7 年先行**し、通信要求グラフと物理 GPU トポロジグラフの二部グラフマッピングという同型の問題を扱った。ただし SC17 が通信コスト・同居干渉・資源断片化を単一効用関数へ重み付き結合し Fiduccia-Mattheyses 系の再帰的二分割で最適化するのに対し、TAS は宣言的制約として表現する。SC17 は**通信集約的な小バッチジョブの同居で最大約 30% のスローダウン**を実測して干渉度を効用関数の独立項に組み込んだが、**TAS の KEP は同居ジョブ間の性能干渉を定量化する仕組みを持たない**。 [[Kubernetes Workload・PodGroup API]] はこの落差を次のように総括する。 > **プロダクショングレードの Kubernetes コア API は、まず「動くビルディングブロック」を提供し、HiveD/Themis 級の高度な保証は後続 KEP に委ねるという段階的経路を選んでいる。** なお TAS は単一ワークロードの配置制約に閉じており、HiveD の VC 抽象が扱う**テナント間の階層的な予約保証**までは踏み込んでいない。 > [!gap] Shockwave は wiki に一切存在しない。Gandiva・Pollux は他ページ内での言及のみで独立ページを持たない。Volcano・YuniKorn・coscheduling プラグインも同様で、設計・API の記述はない。 --- ## 3. オーケストレーション層この層の主題は「**Pod 集合をどういう形状の単位として扱うか**」である。2 つの流れが並行して進む。ワークロード形状ごとに専用 API を新設する流れ(§3.1)と、ギャングスケジューリングをコアの first-class API へ吸収する流れ(§3.2)である。 ### 3.1 ワークロード形状ごとの専用 API #### 3.1.1 JobSet > [!gap] **JobSet のカバレッジは極めて薄い。** 専用ページがないだけでなく、定義・設計・機能を説明した記述が wiki 内に存在しない。全出現箇所は「ワークロードコントローラ名の一つ」としての列挙にとどまる。API グループ、CRD 構造、failure policy / restart 意味論、Job / Indexed Job との構造的関係、TPU スライス対応、メンテナ・所属 SIG、リポジトリ URL はいずれも記載なし。 wiki から確実に言えるのは次の 4 点のみである。 1. **「真のワークロードコントローラ」の一員**。[[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]] の脚注は「『真のワークロードコントローラ』は Job・JobSet・LeaderWorkerSet 等の in-tree/out-of-tree のコントローラを指す」と定義し、所有関係図では `Job / JobSet / LWS` が `Workload` → `PodGroup` → `Pods` を作成・所有する主体として描かれる。 2. **[[Kueue]] の対象ワークロード種別**の一つ。 3. **`ReplicatedJob` という API 概念を持つ**。これは TAS の PodSet Slice アノテーションの用途説明——「JobSet の ReplicatedJob インスタンス単位の co-location などに使う」——から間接的に判明する。wiki 全体で JobSet の API 概念に触れた唯一の箇所である。 4. **障害回復が機能する所有構造を持つ**(§2.2.6 参照)。 JobSet の存在理由を裏づける最も有力な間接証拠は [[@2023__arXiv__The Flux Operator]] にある。同論文は Flux Operator の弱点として「MiniCluster 全体を単一の Indexed Job で構築するため、**リードブローカーとフォロワーブローカーで異なる Pod 仕様を持たせられない制約がある**(著者らは JobSet への将来的な移行を志向)」と記す。実際 Flux Operator は「Indexed Job がインデックス順に Pod を作成し、インデックス 0 が最後にクリーンアップされる」という副作用的性質を利用してリーダー選出を代替している。**単一 Job テンプレートでは非対称構成を表現できない**という実証的動機がここに現れている。なお `wiki/hot.md` の ingest ログには「JobSet/LeaderWorkerSet/MPIJob 等の統合対象は本文中で言及するに留め、個別エンティティページは作成しなかった」と記録されており、この不在は取りこぼしではなく ingest 時の明示的判断である。 #### 3.1.2 LeaderWorkerSet(LWS) [[LeaderWorkerSet]](kubernetes-sigs/lws、**sig-apps 傘下**)は「単一の StatefulSet では表現しにくい **1 Leader + 複数 Worker** の非対称なマルチノードレプリカ」をデプロイ・管理するカスタムリソース API である。各レプリカは Leader Pod 1 個と Worker Pod 群(**専用 StatefulSet で管理**)から構成され、レプリカ単位のローリングアップデート・スケーリングを支える。主用途は「**分散 LLM 推論・訓練など、複数ノードにまたがるモデル並列実行を単一の論理レプリカとして扱いたい**ワークロード」である。内部的には Leader 側も Worker 側も StatefulSet コントローラが Pod を実体化する。したがって LWS は StatefulSet の置き換えではなく、その上に非対称性を与える層である。 **ギャングスケジューリング対応(KEP-407)** が LWS 設計で最も文書化されている部分である。[[@2025__KEP__KEP-407 Gang Scheduling (LeaderWorkerSet)]](起草 2025-04-08、起点は Issue #167)の動機は明快である。 > 資源が逼迫しているとき、スケジューラが **Leader Pod を優先してスケジュールし Worker Pod を pending のまま放置**しうる。LWS の分散推論サービスは Leader・Worker の全 Pod が揃って初めて機能するため、この部分スケジューリングは「**クラスタ資源を消費しているのにどの推論サービスも提供できない**」リソースデッドロックを生む。設計は `BaseResourceProvider`(ヘッドレスサービス・ResourceClaim 作成)と `SchedulerProvider`(PodGroup 管理)を合成した `ReplicaResourceProvider` インターフェースにより、**Volcano・coscheduling scheduler-plugin・YuniKorn** をプラガブルに切り替える。所属先の指定方法はスケジューラごとに異なる(**Volcano はアノテーション `scheduling.k8s.io/group-name`、coscheduling はラベル `scheduling.x-k8s.io/pod-group`**)ため、この差異を `InjectPodGroupMetadata` の実装側へ閉じ込める。YuniKorn のように PodGroup CRD を持たないスケジューラは `CreatePodGroupIfNotExists` を no-op にすればよい。なお **ギャングスケジューリングポリシー自体の実装は Non-Goal** である。ライフサイクル設計の要諦は、**PodGroup の OwnerReference を Leader Pod に設定する**ことでライフサイクルを完全同期させる点にある。スケールダウン・削除・ローリングアップデートによる Leader Pod 再作成のいずれでも PodGroup が自動的に削除・再作成される。代替案(LWS コントローラが PodGroup を所有)は、スケールアップ/ダウン時の作成・削除処理が別途必要になり、**ローリングアップデート時に `maxSurge` が設定されていれば追加 PodGroup 作成も必要になる**ため却下された。 `MinMember` は StartupPolicy で切り替わる。**LeaderCreated Policy(既定)ではレプリカ全体のサイズ(1 Leader + (size-1) Worker)、LeaderReady Policy では 1** である。ただし**いずれのポリシーでも `MinResources` は常にレプリカ全体分を要求する**。資源不足時に Leader だけをスケジュールしても、その後 Worker が作成に失敗するだけで無意味だからである。 > [!gap] LWS のローリングアップデート詳細(更新順序、partition、maxUnavailable)、サブグループサポート(`subgroup` という語自体が wiki に存在しない)、グループ単位スケーリングの詳細、バージョン・リリース時期はいずれも記載なし。**さらに重要な欠落として、LWS と [[llm-d]] を結ぶ記述が wiki 全体に存在しない。** [[llm-d]] ページに LWS への言及は 1 箇所もない。両者が並ぶのは [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]] の関連研究欄(「KServe・AIBrix・NVIDIA Dynamo・LeaderWorkerSet など既存のサーバーレス LLM 基盤」)のみである。 #### 3.1.3 sig-apps の設計パターン [[LeaderWorkerSet]] と [[Agent Sandbox]] は、wiki が明示する共通パターンを形づくる。 > 両者は「**既存の StatefulSet 等の組み合わせでは表現しきれない AI 関連ワークロードの形状ごとに、sig-apps が専用の宣言的 API を新設する**」という共通パターンを示す。 LWS はマルチノードのモデル並列実行(Leader/Worker 非対称)、Agent Sandbox は孤立・ステートフル・シングルトンなエージェントランタイムという、それぞれ異なる形状に専用 API を与える。§5 で後者を扱う。 ### 3.2 ギャングスケジューリングの first-class 化 #### 3.2.1 KEP-4671: Workload / PodGroup API [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]](creation-date 2025-09-17、`status: implementable`、sig-scheduling 主導・sig-apps 参加、著者 8 名: erictune・wojtek-t・helayoty・44past4・andreyvelich・thockin・macsko・mm4tt)は、`scheduling.k8s.io` に **`Workload` と `PodGroup` の 2 種**を導入する。マイルストーンは **alpha v1.35 → beta v1.37(当初 v1.36 予定から延期)→ stable v1.38**。KEP-583(coscheduling)と KEP-5832(PodGroup API 分離、2026-03 に本 KEP へ統合)を置き換える。用語の定義は重要である。Kubernetes コミュニティは「ギャングスケジューリング」を "**all-or-nothing scheduling of a set of pods**" の意で用い、**時分割多重(time-multiplexing)を含意しない**。Feitelson and Rudolph や Slurm の用法とは異なる。 **なぜ 2 オブジェクトに分離したか**は設計の核心である。当初は `PodGroup` を `Workload` spec 内へ埋め込んでいたが、3 つの問題を生んだ。 1. `Workload` は**長寿命の設定意図**、`PodGroup` は**一時的なスケジューリング単位**であり、ランタイム実行単位を永続的定義オブジェクトへ結びつけることは関心の分離に反する。 2. ライフサイクル結合により、スタンドアロンの `PodGroup` が ResourceClaim 等を所有して GC できない。 3. 全 `PodGroup` のランタイム status を `Workload` に追跡させると、大規模 Workload で **etcd 1.5MB 上限**に容易に抵触し、単一 PodGroup の status 更新だけで巨大 Workload 全体への read-modify-write 競合が生じる。 API の要点。`Workload.spec.podGroupTemplates` は**最大 8 個**のテンプレートを持ち、作成後の追加・削除は不可(既存フィールドの更新は個別に許可)。各テンプレートは `Basic` か `Gang`(`minCount` による all-or-nothing)を選ぶ。`PodGroup.spec.schedulingPolicy` は参照方式でなく**コピー/インライン方式**を採り、「Workload 変更が既存の全 PodGroup へ波及する **action-at-a-distance**」を避けて自己完結オブジェクトにする。Pod は `spec.schedulingGroup.podGroupName`(**immutable**)で参照する。可変にすると「ギャングをスケジュール中に 1 Pod だけ除去された」というコーナーケースへの対処が必要になるためである。実装は 2 段階で進む。**Alpha(v1.35)** は `GangScheduling` プラグインが `PreEnqueue`・`WaitOnPermit`・`EventsToRegister` の 3 拡張点のみを実装する単純なバリア方式である。**Beta(v1.37)** は `scheduleOne` ループへ **Workload Scheduling Cycle** を導入し、PodGroup の全メンバー Pod を**単一クラスタスナップショット上でバッチ処理**する。新拡張点 `PlacementFeasiblePlugin`(`Wait`/`Unschedulable`/`Success`)を導入し、当初転用していた `Permit` から切り替えた(挙動が段階ごとに一貫せず、高速却下パスが必要だったため)。 **アルゴリズムの限界が明示されている**点は誠実である。 > **同種(homogeneous)な PodGroup は配置が存在すれば必ず発見できるが、異種(heterogeneous)な PodGroup や Pod 間アフィニティ/anti-affinity・トポロジ分散を持つ PodGroup は配置発見を保証しない。** 決定論的な処理順序に依存するため、intra-group 依存がある場合はクラスタ状態に関わらず配置を発見できないことがある(回避策として依存 Pod への低優先度割当がドキュメント化される)。また PodGroup 内の全 Pod は同一 `.spec.schedulerName` を共有せねばならず、不一致は全 Pod 却下となる。 Non-Goal は明示的である。**kube-scheduler への複数ワークロードキュー・公平性の導入(Kueue・Volcano.sh が引き続き担う)**、クラスタオートスケーリング統合、ワークロードレベルプリエンプション、異なるスケジューラ間のリソース競合解決はすべてスコープ外である。 #### 3.2.2 なぜ first-class API が必要かこれに対する wiki 内で最も直接的な一次記述は KEP の Drawbacks 節にある。 > **Volcano.sh・Co-scheduling plugin・Preferred Networks Plugin・Kueue の少なくとも 4 つの実装がすでに kube-scheduler 外でギャングスケジューリングを提供している。**それでも本 KEP を進める理由は、既存実装が本 KEP の目指す各種レース・デッドロック問題の全てには対処できていないこと、AI 時代にはこれらの概念が十分基盤的でありユーザーが拡張機能をインストールせずに済むべきという判断である。 #### 3.2.3 PodGroup 系譜と 2 レイヤーの独立解 [[Kubernetes Workload・PodGroup API]] が抽出する最も鋭い観察は、**同じ設計原理が異なる時期・異なるレイヤーで独立に発見された**という点である。 > **LWS の KEP-407 は本 KEP の `Workload`/`PodGroup` 分離設計より前(2025-04-08 起草、本 KEP は 2025-09-17)に、PodGroup の ownership を Leader Pod へ紐付ける同型の設計に到達している。**「**PodGroup の寿命を実行主体に厳密に一致させる**」という同一の設計原理を、KEP-407 はコア API 標準化を待たず既存の複数 PodGroup CRD 実装へ委任する形で先取り実装していた。両者は「ギャングスケジューリングのエコシステム分散」問題を、**コア(KEP-4671、kube-scheduler 拡張点)とコントローラ(KEP-407、Provider 抽象)という異なるレイヤーで独立に解いている**。 > [!gap] 系譜の「上流以前」側の記述は薄い。Volcano・coscheduling・YuniKorn について wiki にあるのは名前と 2 つのメタデータキー(`scheduling.k8s.io/group-name`、`scheduling.x-k8s.io/pod-group`)のみで、各 PodGroup CRD の構造や相違は記載なし。KEP-4671 の `minCount` と外部実装の `MinMember` の対応関係も記載なし。 ### 3.3 層の合成 > [!note] 「Kueue が admit → JobSet/LWS が Pod を実体化 → スケジューラが配置する」という連鎖を**一文で述べたページは wiki に存在しない**。以下は各段の一次記述を筆者が合成したものである。 1. **admission**: Kueue が ClusterQueue のクォータに基づき「いつ・どれだけ」通すかを決める(§2.3)。 2. **配置決定の予約**: TAS が有効なら、Kueue は配置まで計算したうえで `kueue.x-k8s.io/topology` スケジューリングゲートにより nodeSelector 注入を遅延させる(§2.2.4)。 3. **実体化**: 真のワークロードコントローラ(Job / JobSet / LWS)が `Workload` → `PodGroup` → `Pods` の**厳格な順序**で作成・所有する。非存在の PodGroup を参照する Pod は `UnschedulableAndUnresolvable` となり、PodGroup 作成時の informer Add イベントで再エンキューされる。LWS の場合は sts コントローラ → Pod Webhook → Pod コントローラ → sts コントローラ → Pod Webhook という**多段のコントローラ協調**を経る。 4. **配置**: kube-scheduler が PodGroup を専用キューから取り出し、単一スナップショット上で全メンバーを一括配置し、`schedulableCount >= minCount` で成否を判定する。 5. **障害回復・拡張**: ノード障害時の再割当はオーケストレーション層の所有構造に依存する(§2.2.6)。Cluster Autoscaler 統合は Kueue 側が 2 パス設計で既に解いている一方、コア側(KEP-4671)では **North Star Vision 要件(8)として先送りされ、`NominatedNodeName` によるリソース予約の緩和のみ**である。同じ問題に対する両層の成熟度が非対称である。この分業構造を [[コンテナオーケストレーション]] は次のように総括する。 > **GenAI 推論オーケストレーションでは、単一の統合ソリューションではなく「バッチスケジューリング」「アクセラレータスライシング」「分散推論ルーティング」の 3 層それぞれに特化したコンポーネントを組み合わせる分業型アーキテクチャが実用化されている。** [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]] は [[Kueue]]・[[Dynamic Accelerator Slicer]]・[[Gateway API Inference Extension]] という互いに独立した 3 プロジェクトを OpenShift 上で組み合わせ、それぞれ**メイクスパン最大 15%、平均ジョブ完了時間 36%、テール TTFT 最大 90%** の改善を**独立に**達成した。2016 年時点で観測された「first-class なマルチジョブサービス管理メカニズムの欠如」というギャップが、単一の汎用機能ではなく**特化コンポーネント群の疎結合な組み合わせ**で埋められつつあることを示す。 --- ## 4. デプロイスタック層この層は「推論トラフィックをどう受け、どこへ流すか」を扱う。**サービング制御プレーン**(§4.2)、**推論対応ルーティング**(§4.3)、**AI ゲートウェイ**(§4.4)の 3 段に整理できる。 ### 4.1 系譜: KFServing / KServe [[KFServing]]([[@2020__arXiv__Serverless inferencing on Kubernetes]]、ICML 2020 ワークショップ、著者は [[Clive Cox]]([[Seldon Technologies]])・[[Dan Sun]]([[Bloomberg L.P|Bloomberg L.P.]])・Ellis Tarn・[[Animesh Singh]]([[IBM]])・Rakesh Kelkar([[Microsoft]])・David Goodwin([[NVIDIA]]))は、[[Kubeflow]] 内で [[Knative]](さらに [[Istio]])を拡張したサーバーレス機械学習推論プロジェクトである。**プロジェクトは後に KServe へ改名された**。中核は単一の `InferenceService` CRD であり、TensorFlow・PyTorch・XGBoost・SKlearn をまたいで一貫したデプロイインターフェースを与える。保存済みモデルの場所とサーバー種別を指定するだけで、(1) 適切なサーバーイメージを持つ Knative サービス作成、(2) 主要ストレージからのアーティファクトダウンロード用 **storage initializer** 作成、(3) 推論エンドポイントのネットワーキング配線が自動化される。`canaryTrafficPercent` による段階的トラフィック移行も宣言的に行える。処理ステージは **Pre-process / Predict / Post-process / Explain** の 4 段で、**transformer**(リクエスト・レスポンスのデータ変換、例: テキストを特徴埋め込みベクトルへ変換)と **explainer**(個々の推論への人間可読な説明)が predictor の前後に挟まる。本稿の文脈で最も重要なのは、**GPU オートスケーリングの困難をリクエストベースへ逃がした**という設計判断である。GPU duty cycle メトリクスは一部のクラウドでしか容易に取得できず、CPU と GPU を組み合わせた判断も難しく、レイテンシベースはスケールダウン判断の実装が困難である。KFServing は **Knative Pod Autoscaler(KPA)のリクエストベースオートスケーリング**(in-flight リクエスト数と設定同時実行数の比較)を用いることでこれを回避した。 2020 年時点で既に報告されていた未解決課題が、その後の LLM 時代の課題設定を先取りしている。 - **スケールツーゼロの起動レイテンシ**: 大規模モデル(**5〜30GB**)ではゼロからの初回リクエストが prohibitive になり、低レイテンシ要件とサーバーレスの利点がトレードオフになる。 - **queue-proxy と CFS スケジューラの相互作用**: Linux カーネル CFS のバグにより、I/O 主体の「行儀の良い」コンテナでも CPU スロットリングを受けテールレイテンシが悪化する。 - **バッチ遅延**: 秒間トランザクション数がバッチサイズを下回るとレスポンスレイテンシがスパイクする。 - **Istio/Knative スタックの大規模運用**: 数百〜数千 InferenceService 規模で VirtualService が Ingress ゲートウェイのメモリフットプリントを増やす。 LLM 時代における KServe の扱いは二分される。[[@2025__EnvoyAIGatewayBlog__Envoy AI Gateway Reference Architecture]] は自ホスト型モデルサービング層として KServe を**推奨**し、「トークンベース自動スケーリングと GPU のゼロスケーリング」「マルチノード推論([[vLLM]] 経由)」「OpenAI 互換 API」「モデル/プロンプトキャッシング」を活用機能として挙げる。一方 [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]] は**批判的**であり、「KServe・RayServe は汎用 ML サービングには適しているが、**LLM 固有の最適化(バッチスケジューリング・KV キャッシュ連携・異種 GPU スケジューリング)を持たない**」と評価する。 > [!gap] **KServe のカバレッジは極めて薄い。** 単独エンティティページはなく、一次ソースは 2020 年の KFServing 論文 1 本のみである。現行 KServe の LLM 向け CRD、Open Inference Protocol、ModelMesh、GAIE 対応の有無はいずれも記載なし。LLM 時代の記述はすべて「他プロジェクトから見た KServe」に依存している。 ### 4.2 サービング制御プレーン [[@2025__arXiv__From Attention to Disaggregation - Tracing the Evolution of LLM Inference]] は、この領域の実装を 3 つのアーキタイプへ分類する。この分類が本節の骨格になる。 | | [[DistServe]] | [[AIBrix]] | [[NVIDIA Dynamo]] | |---|---|---|---| | アーキタイプ | research-first | **cloud-native production-ready** | **full-stack hardware co-design** | | コア概念 | 細粒度 P/D 分離 + シミュレーション駆動スケジューラで goodput 最大化 | GPU クラスタ全体を分離資源プールとして扱う Kubernetes 制御プレーン | NVIDIA フルスタックとの協調設計。671B 級を狙う | | 通信 | ノード内 NVLink 前提。**マルチノード拡張は通信オーバーヘッドで困難** | 分散 KV cache + cache-aware routing | [[NIXL]] による転送、**NATS による replica 同期** | | 典型統合先 | Ray Cluster、SwiftTransformer | AWS EKS、Istio、Prometheus | NVIDIA 独自相互接続・メモリ階層 | #### 4.2.1 NVIDIA Dynamo [[NVIDIA Dynamo]] はエンタープライズ向け分離型推論プラットフォームであり、GPU・NVLink・NVSwitch と密結合した hardware-software co-design により **671B パラメータ級**を狙う。主要コンポーネントは次のとおり。 - **Dynamo Planner**: リクエスト率・シーケンス長・GPU 利用率を取り込み、Prefill/Decode 間で GPU を再配分する **SLO 対応・event-driven** な動的資源割当。Kubernetes/Circus で zero-downtime スケールを行う。 - **Smart Router**: KV cache 対応ディスパッチャ。**グローバル radix tree** で KV ブロックの所在を追跡し、**KV overlap score と利用率**の組み合わせで hit rate を最大化する。random / round-robin / KV-aware モードを切替可能。 - **[[NIXL]]**: 異種メモリ・ストレージ間のハードウェア加速データ転送ライブラリ。Prefill/Decode 間のノンブロッキング KV 転送を担う。NCCL が訓練の同期的 many-to-many collective を担うのに対し、NIXL は推論で頻出の**非同期 one-to-one/one-to-few 転送**を担う役割分担にある。 - **[[KVBM (KV Block Manager)|KVBM]]**: GPU HBM / CPU DRAM / SSD / オブジェクトストレージを階層管理する統一メモリ層。3 層構造(ランタイム層 → KVBM ロジック層 → NIXL 層)をとり、write-through キャッシュとして機能する。実装上の要点として、**decode-centric 設計**を採る。新規リクエストは常に Decode ワーカーが受信し、ローカル Prefill かリモートオフロードかを判定する。`etcd` をワーカーディスカバリとリース管理に用い、Planner がリースの失効・新規発行で Prefill ワーカーを動的に増減させる。ワーカーは NIXL のメモリ登録記述子を `etcd` 経由で交換するため、以後の Prefill リクエストは**短い ID のみ**で済み制御メッセージが軽量になる。異種構成の例として **B200×4 台を Prefill、B300×8 台を Decode** に割り当てる roles 定義が示される。報告される数値は次のとおりである。**GB200 NVL72 上で最大 30× のリクエスト処理、Hopper GPU + Llama-70B で 2× スループット、Smart Router 単独で 3× TTFT 改善**(再計算削減による)。[[NIXL]] ページには別文脈で「680B パラメータ LLM・72GPU Blackwell NVL72 ラック構成で最大 30 倍の推論スループット向上」が記録されている。 NIXL の実測ベンチマーク([[SAKURA Internet]] [[高火力 PHY]] チーム、H100 HGX 2 台)は、**ノード内 NVLink で 400 GB/s 付近、ノード間 400Gbps NIC で 50 GB/s 付近**という結果を示し、「KV Cache 転送のボトルネックはソフトウェア層ではなく**物理リンクの帯域に収束する**」と結論する。 Planner が担う動的レートマッチングの必要性は、[[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]](NVIDIA、MLSys 2026)が数十万の設計点シミュレーションで裏づける。**最適な Ctx:Gen GPU 比はモデル・トラフィック・レイテンシ目標により大きく変動し、固定比率では緩いレイテンシ目標かタイトな TTL のいずれか一方でしか高性能を発揮できない**。disaggregation の恩恵は prefill-heavy なトラフィック(ISL >> OSL)と大規模モデル(>10B)で最大化される。 > [!gap] 上記シミュレーションは NVIDIA 独自の proprietary シミュレータに基づき、実機ベンチマーク(DistServe・Mooncake 等)との定量的突き合わせは行われていない。また Prefill/Decode 間のテンソル並列レイアウト変換カーネルのオーバーヘッドも「NVIDIA Dynamo の実装依存であり独立検証がない」と wiki が明記している。 #### 4.2.2 llm-d [[llm-d]](llm-d.ai)は「Kubernetes エコシステムを拡張し LLM 推論ワークロードを効率的にオーケストレーションするフレームワーク」である。構成上の位置づけは、**[[vLLM]] を推論エンジンとし、[[Gateway API Inference Extension]] の Endpoint Picker(EPP)を実装する**制御プレーンである。 [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]] の図説明が、wiki 内で最も具体的なアーキテクチャ記述である。 > llm-d による Kubernetes ネイティブな分離配信クラスタの構成。**推論ゲートウェイ、推論プール(prefill 用 Variant A と decode 用 Variant B)、KV cache を意識したスケジューラ、レプリカ数を調整する variant autoscaler** からなる。 **KV キャッシュ対応ルーティング**が中心的価値である。分散環境で類似プロンプトがキャッシュ非対応のまま異なるレプリカへルーティングされると、各レプリカが同じプレフィックス状態を再計算し GPU サイクルを浪費する。EPP は **queue-scorer・kv-cache-utilization-scorer・prefix-cache-scorer** の 3 ヒューリスティックを持ち、既定重みは各 1、実機 H100 環境向け調整値は **queue 2 / kv-cache 2 / prefix-cache 3** である。[[KVキャッシュ管理]] はこれを「プレフィックスキャッシュ管理の最適化対象が、単一エンジン内のデータ構造(trie/radix tree)やエンジン間の転送(Mooncake・LMCache)に加えて、『**Kubernetes のサービスディスカバリ・ロードバランシング層**』という新しい統合ポイントを持ちうる」と位置づける。 **P/D 分離**については、「超長プロンプト・短出力(要約)では Prefill プールへ GPU を追加し、長い出力(推論チェーン)では Decode プールへ追加する」という **variant autoscaler による動的シフト**が記述される。[[Prefill-Decode分離]] はこれを「P/D-Serve が数万 NPU 規模で示した『固定 pool だけでは TTFT SLO を守れない』という知見と同じ問題意識だが、llm-d は Kubernetes 標準のオートスケーリング機構に統合する点で異なるレイヤーの解を提示する」と評価する。 **WVA(Workload Variant Autoscaler)** は [[IBM Research]](主著者 [[Abhishek Malvankar]])が llm-d と共同設計したオートスケーラである([[@2026__arXiv__WVA - A Global Optimization Control Plane for llmd]]、arXiv 2603.09730、v2 2026-03-20、コードは `github.com/llm-d/llm-d-workload-variant-autoscaler`)。設計の要点は次の 5 点である。 1. **Variant という第一級抽象**: `Variant = ⟨Hardware, Parallelism, Quantization⟩`。実装では Hardware(GPU モデル)と Parallelism(レプリカあたり GPU 数)の 2 次元に限定し、`VariantAutoscaling` CRD として操作化する。 2. **エンジン内部飽和状態との密結合**: `queue_length` と `kv_cache_usage` を直接消費する。飽和レプリカ集合を閾値(既定 τ_kv=0.8、τ_q=5)で判定し、非飽和集合の平均余裕容量がトリガを下回るとスケールアップする。 3. **Headroom ベースの容量管理**: `Capacity_target = Load_current + δ_safety`。この定式化により **WVA は EPP のルーティングヒューリスティックをミラーでき、スケーリング判断がリクエスト受け入れとフェーズ整合することで制御ループの発振を緩和する**。 4. **Fragmentation-Aware Scale Down**: 純粋な反応的スケーラは *distributional masking*(クラスタ全体平均が低くても特定 Pod が飽和)に陥るため、非飽和レプリカの下限(既定 2)を強制する。 5. **HPA をアクチュエータとして再利用**: HPA を fork せず、意思決定ロジックのみ上位に重ねる。エフェメラルなメトリクスを CRD Status へ書かないことで、標準 HPA と比べ API サーバー負荷(etcd 書き込み)を大幅に削減する。物理クラスタ実験(**200 基の H100** を持つ OpenShift クラスタの 10 ノードサブプール、`Qwen/Qwen3-0.6B`、llm-d well-lit path 構成)の結果は次のとおり。 | リクエストレート [req/s] | 2 | 3 | 5 | 6 | |---|---|---|---|---| | スループット WVA | 2.0 | 2.9 | **5.4** | 5.8 | | スループット HPA | 1.7 | 2.9 | **3.9** | 5.4 | | 失敗数 WVA | 0.0 | 0.5 | **1.4** | 20.0 | | 失敗数 HPA | 3.7 | 2.1 | **15.3** | 18.8 | **5 RPS でピーク 37% のスループット改善、失敗数は約 11 分の 1** である。HPA が失敗する 2 要因は (1) **Saturation Rejection**(平均利用率目標により常に容量近傍で運用し、急激な負荷ステップが llm-d の admission control をトリガして HTTP 429/503 で拒否)、(2) **Scale-Down Instability**(シグナルノイズが処理中の Pod を終了させる)である。論文が誠実なのは、**6 RPS(最大デプロイ上限 10 レプリカ到達)で WVA が HPA に劣後する逆転**を明示的に報告する点である。上限に達すると保守的な HPA のほうがスループット・失敗数・レイテンシのすべてで優位になる。論文自身が挙げる限界には**Prefill/Decode フェーズ別の独立スケーリングが未対応**であることも含まれる。 > [!gap] **llm-d のバッカーに関する記述は薄い。**「Red Hat が llm-d を支援している」という明示的記述は wiki に存在しない。関連事実は ICPE 論文の著者所属が [[Red Hat]] であること、[[Kubernetes]] ページに「[[llm-d]] の CNCF Sandbox 提案」という 1 行があることのみ。また llm-d 公式が謳う複数の「well-lit paths」のカタログも記載なく、wiki 内では実質的に Precise Prefix-Cache Aware Scheduling の別名として扱われている。§3.1.2 のとおり LWS との関係も記載なし。 #### 4.2.3 AIBrix [[AIBrix]]([[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]]、主に ByteDance、arXiv:2504.03648v1、リポジトリは `github.com/vllm-project/aibrix` = **vLLM プロジェクト傘下**)は、GPU クラスタ全体を「分離資源プール」として扱い、**[[Kubernetes]] の粒度の粗い管理と [[Ray]] の細粒度高性能タスク制御を組み合わせるハイブリッド設計**を採る。推論エンジンとの協調設計(co-design)を基本哲学とする。制御プレーンの構成要素は、**Model Adapter (LoRA) Controller**(アダプタの動的ロード/アンロード、EndpointSlice によるアダプタ単位の発見)、**LLM-Specific Autoscaler**(KV キャッシュ利用率など LLM 固有メトリクスによる second-level スケーリング、KPA と APA の両アルゴリズム対応)、**GPU Optimizer**(**ILP ベース**で最適な GPU 組み合わせを動的選択、Mélange に着想)、**Unified AI Runtime**(vLLM・SGLang・TensorRT-LLM をプラガブルに収容する vendor-neutral sidecar、GPU ストリーミングローダでディスク I/O ボトルネックを回避)、**Cold Start Manager**、**Accelerator Diagnose Tools** である。データプレーンは **Request Router**(**Envoy Gateway を拡張**した LLM 対応 API ゲートウェイ、random・throughput・least-request・least-kv-cache・least-latency・prefix-cache-aware の 6 ポリシー)と **Distributed KV Cache**(スキャン耐性の退避ポリシー・非同期メタデータ更新・キャッシュエンジン同置)からなる。 **GPU 障害検知**として、ビルトイン機能を活用して障害を自動検知しワークロードへ影響が出る前に特定する診断ツールと、障害耐性テスト用のモックアップツールの 2 種を持つ。現時点で NVIDIA GPU と Ascend 910B NPU をサポートする。主要な数値(Bird-SQL、4 × A10)。分散 KV cache は **vLLM デフォルト比でスループット 129%↑・平均 TTFT 73%↓・P99 TTFT 79%↓**、vLLM プレフィックスキャッシュ比で **52%↑ / 65%↓ / 77%↓**。LLM 固有オートスケーラはネイティブ HPA 比で**レイテンシ 11.5%↓・トークンスループット 11.4%↑・スケーリング振動 33%↓**。ゲートウェイは**平均レイテンシ 19.2%↓・P99 79%↓**。異種 GPU サービングは同質 L20 構成比で**レイテンシ最大 20%↑(SLO 内)・コスト約 10%↓**、低トラフィック条件では **4.7× のコスト削減**。注目すべきは AIBrix が **Google らと連携して gateway-api-inference-extension プロジェクトへの採用も進めている**と述べる点である。独自ゲートウェイと標準化の両睨みという姿勢を示す。 #### 4.2.4 対照事例: Kubernetes ネイティブ制御プレーンを採らない選択 [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]] は本節への重要な対照である。Netflix は **JVM ベースの統合サービングシステム + Model Scoring Service + [[Triton Inference Server]] + Java 制御プレーン**という構成を採り、GAIE / llm-d / AIBrix といった Kubernetes ネイティブ推論制御プレーンは一切登場しない。2026 年夏に TensorRT-LLM → **vLLM** へ paved-path エンジンを切り替えたが、判断基準は性能ではなく**運用適合性**(カスタムモデルのロード容易性・カスタムデコード拡張フック・デバッグ性・研究本番間の移行コスト)だった。同記事が報告する具体的な運用ギャップは、抽象度の高い制御プレーン議論では見えない層のコストを示す。**Triton の組み込みブリッジは 40 以上ある vLLM メトリクスのうち 9 個しか橋渡ししない**ためトークンスループット・KV キャッシュ利用率・prefix キャッシュヒット率が欠落し、単一 `/metrics` へ統合する軽量 HTTP プロキシの自作を要した。また `response_format` がスキーマ上受理されるのに vLLM へ届く前に黙って捨てられる欠落を git-subtree でパッチしている。 ### 4.3 推論対応ルーティング: Gateway API Inference Extension #### 4.3.1 なぜ L7 LLM ルーティングが特殊か [[Gateway API Inference Extension]](GAIE)は「標準 [[Kubernetes Gateway API]] を拡張して分散 LLM 推論を管理する Kubernetes ネイティブな抽象化層」である。解こうとする問題は次のように述べられる。 > 通常の Kubernetes Service + Deployment による**ステートレスなラウンドロビン負荷分散**が、**ステートフルで計算コストが不均一、かつキャッシュ再利用・遅延対応ルーティングの恩恵が大きい** LLM 推論リクエストに不向きである問題に対処する。具体的な非対称性は 3 つある。 1. **リクエストあたりコストの可変性**: [[LLMサービング管理]] は「ラウンドロビン・最少リクエスト・最低利用率はリクエスト負荷が均一という前提に立つ。しかし LLM では応答長によって decode 段階の GPU メモリ使用量と推論時間が大きく変わり(**ShareGPT: 応答長 5〜632 トークン**)、重いリクエストが一部インスタンスに集中して KV キャッシュを枯渇させる」と述べる。 2. **KV キャッシュ親和性**: キャッシュ非対応ルーティングは同じプレフィックスの再計算を招く(§4.2.2)。 3. **状態の長時間保持**: 「**単一の LLM リクエストが長時間 KV キャッシュを保持しうる**ため、汎用リクエスト同時実行数よりもエンジン内部状態の直接監視のほうが高忠実度のシグナルを提供する」。 #### 4.3.2 構成要素 wiki が挙げる 2 つのコア構成要素は次のとおり。 - **InferenceGateway**: モデル登録・認証・バージョニング・ルーティングポリシーを備え、**複数モデルバージョンを単一の論理エンドポイント下で提供する**エントリポイント。 - **InferencePool**: バックエンドの [[vLLM]] レプリカ群を管理し、**[[llm-d]] の Endpoint Picker(EPP)として実装される推論スケジューラを統合**してキャッシュ対応・遅延最適化ルーティングを行う。 > [!gap] 「InferenceModel」という名称は wiki に記載なし。wiki が挙げるのは InferenceGateway と InferencePool の 2 つのみであり、CRD 名の改称経緯(InferenceModel → InferenceObjective 等)も記載なし。 #### 4.3.3 測定された効果とコスト [[@2026__ICPE__Evaluating Kubernetes Performance for GenAI Inference]] は GAIE を 2 つの側面から測定した。 **導入オーバーヘッド**: vLLM Simulator を用いた検証で、ClusterIP と InferencePool 無効時はほぼ同等の TTFT を示す一方、**InferencePool 有効時は同時実行度 6〜20 の範囲で 3ms〜11ms 高い TTFT** を示した。これはゲートウェイと endpoint picker のルーティング処理に起因する。 **実運用相当ワークロードでの効果**: 32 件の転写文(各平均 8,500 トークン、合計 272,000 トークン)を 256 リクエストとして送信した。**KV キャッシュ容量は GPU あたり 143,360 トークン、8 GPU 合計 1,146,880 トークン**であり、プロンプト総量がキャッシュ容量を上回るため Random Scheduling はキャッシュミスと prefill オーバーヘッドを必然的に生む設計になっている。結果、Random Scheduling の平均 TTFT(**約 500ms**)は Precise Prefix-Cache Aware Scheduling(**約 80ms**)の**約 6.25 倍**であり、99 パーセンタイルでは**最大 20 倍**遅い。エンドツーエンドでも Random は平均で約 1 秒、P99 で最大 6 秒遅い。論文の Takeaways は「**99 パーセンタイル TTFT を最大 90% 削減、エンドツーエンド遅延を最大 25% 改善**」とまとめる。 > [!contradiction] 同論文の Conclusion(§5)では「TTFT を最大 82% 改善」という別数値が併記されており、wiki は「論文内で TTFT 改善率の表記(90% と 82%)に軽微な不整合がある」と明記している。abstract は "sixfold" と表現する。 ### 4.4 AI ゲートウェイ [[AIゲートウェイ]] は、この製品カテゴリが「単一の実装パターンではなく『**新規統合実装**』対『**既存プロキシ拡張**』という異なる出自から独立に収束しつつある構造」を持つと整理する。両極を代表するのが agentgateway と Envoy AI Gateway である。 #### 4.4.1 Envoy AI Gateway(既存プロキシ拡張) [[Envoy AI Gateway]] は [[Tetrate]] と [[Bloomberg L.P|Bloomberg L.P.]] が **2024 年 10 月**に協業開始した OSS であり、[[Envoy Gateway]] コントロールプレーンを拡張し [[Envoy]] のデータプレーン拡張を活用する。設計方針は明確である。 > **独立の新規プロキシを作るのではなく、既存のクラウドネイティブ HTTP プロキシ実績(約 10 年の本番運用実績)へ AI トラフィック対応を継ぎ足す。** 根拠は「**LLM および MCP トラフィックは最終的に HTTP に依存する**」という主張である。 MVP の 3 機能は **トークンベースの使用量制限**(従来のリクエスト数ベースでは LLM の計算複雑性・コストを捉えられない)、**統一 API**(複数プロバイダ統合)、**アップストリーム認可**(認証情報の一元管理)である。 [[@2025__EnvoyAIGatewayBlog__Envoy AI Gateway Reference Architecture]](著者 Erica Hughberg (Tetrate)・Alexa Griffith (Bloomberg L.P.))は**二層ゲートウェイ設計**を提示する。**Tier One Gateway** は集約ゲートウェイクラスタに置かれ、外部プロバイダ(OpenAI・Anthropic・Bedrock・Vertex)または内部モデルサービスクラスタへのルーティング、認証、グローバルレート制限を担う。**Tier Two Gateway** は自ホスト型モデルサービングクラスタ内に置かれ、内部ルーティング・ロードバランシング・モデル特有のポリシーを担う。この分離により、プラットフォームチームは外部ゲートウェイに変更を加えずにモデルバージョン管理や内部セキュリティルールを適用できる。自ホスト型モデルサービング層は **KServe へ委譲**する(§4.1)。 **MCP 対応**([[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]])では、MCP がステートフルプロトコルであり複数のアップストリーム MCP サーバ(GitHub・Jira 等)との独立セッションを保持せねばならない点が課題となる。採用されたのは**トークンエンコーディング設計**である。ゲートウェイがアップストリームセッションのコンパクトな説明を安全で自己完結的なクライアントセッション ID へエンコードし、クライアントが返却すると**任意のゲートウェイレプリカがデコードできる**。 **却下された代替案が明記されている**点が設計文書として価値が高い。UUID を返却し Redis 等の共有ストアにマッピングを保存する集約化ステート管理は、(1) 管理対象コンポーネントの追加、(2) 高可用性アーキテクチャの複雑化、(3) 単一障害点リスクを理由に却下された。コストは鍵導出関数(KDF)によるセッション暗号化オーバーヘッドであり、**デフォルト設定(KDF 100,000 回反復)は数十ミリ秒を生むが、約 100 回反復への調整で 1〜2 ミリ秒まで削減できる**。 #### 4.4.2 agentgateway(新規統合実装) [[agentgateway]] は **Rust 実装の OSS ゲートウェイ**で、**[[Linux Foundation]] の一部としてホストされる**。中心的な価値提案は、**MCP ツールサーバ・A2A エージェント間通信・LLM 推論トラフィックを通常の API・マイクロサービスと同一のプロキシで前段配置できる**こと、すなわち「AI 用」と「通常用」でゲートウェイを分離しなくてよいことである。なぜ既存 API ゲートウェイでは不十分かを、ドキュメントは対比表で示す。 | 従来の API ゲートウェイ | agentgateway | |---|---| | ステートレスな request/response | 長命接続を伴う**ステートフルな JSON-RPC セッション** | | 1 リクエスト → 1 バックエンド | 複数 MCP サーバへの**セッションファンアウト** | | クライアント起点のみ | **双方向**: サーバが SSE でクライアントへイベントをプッシュ | | パス/ヘッダによる単純ルーティング | JSON-RPC メッセージ本体を理解する**プロトコル対応ルーティング** | | 静的なバックエンドマッピング | クライアント単位の**動的ツール仮想化** | 具体的に解決できない課題として、複数 MCP サーバへのツール一覧問い合わせのファンアウトと集約、SSE で push されるサーバ起点イベントのセッションへの経路制御、MCP/A2A 仕様進化に伴うプロトコルネゴシエーション、クライアントごとのツール可視性の動的調整、そして**ツールポイズニング対策**(直接改竄・シャドーイング・**rug-pull 攻撃**)の 5 点を挙げる。**ステートフル・長命接続・ファンアウトという性質ゆえに、パフォーマンスとメモリ安全性を非交渉可能な要件として Rust で実装されている。** 機能は 3 系統に分かれる。 - **LLM Gateway**: 統一 OpenAI 互換 API で **20 プロバイダ**(OpenAI・Anthropic・Bedrock・Azure・Gemini・Vertex AI・Copilot・Cohere・Ollama ほか)へルーティングし、**7 API 種別**(Chat Completions / Responses / Messages / Embeddings / Realtime / Count Tokens / Rerank)ごとのサポート状況を **5 段階**(ネイティブ・翻訳変換・ローカル推定・パススルー・未対応)で分類する。セルフホストモデル向けには **GAIE の Kubernetes Inference Gateway 拡張を実装**し、**GPU/KV キャッシュ利用率・プロンプト重要度・LoRA アダプタ・キュー長**に基づくルーティングを提供する。 - **MCP Gateway**: 複数 MCP サーバを単一エンドポイント下へ集約する**ツールフェデレーション**、**stdio・HTTP/SSE・Streamable HTTP** の各トランスポート対応、既存 REST API を MCP ツールとして公開する **OpenAPI 統合**、OAuth プロバイダ(Auth0・Keycloak)連携の MCP 認証仕様準拠。 - **A2A Gateway**: 能力の相互発見、対話モダリティ(テキスト・フォーム・メディア)の交渉、長時間実行タスクでの協調を、**内部状態やツールを露出させずに**仲介する。横断機能として、認証は JWT・API キー・Basic・MCP 認証仕様、認可は **[[CEL]] ポリシーエンジンによるきめ細かい RBAC**、オブザーバビリティは **[[OpenTelemetry]]** をビルトインで提供する。プラットフォーム非依存で、[[Kubernetes Gateway API]] の HTTPRoute・GRPCRoute・TCPRoute・TLSRoute に準拠する。 #### 4.4.3 2 つの設計軸 [[AIゲートウェイ]] は両者の比較から 2 つの一般的な設計軸を抽出する。 **軸 1: ステート配置**。「**エンコードして無ステート化**」(Envoy AI Gateway のトークンエンコーディング)対「**集約ストアで一元管理**」(却下された Redis 方式)という一貫した設計軸が存在する。 **軸 2: カテゴリ境界**。「**どこまでを自前実装し、どこから既存のモデルサービング基盤に委ねるか**」。agentgateway は GAIE を自前実装し、Envoy AI Gateway は KServe へ委譲する。 | | [[Envoy AI Gateway]] | [[agentgateway]] | |---|---|---| | 出自 | 既存 Envoy エコシステムの拡張 | Rust で新規実装した統合プロキシ | | MCP セッション状態 | トークンエンコーディング(ゲートウェイはステートレス) | ドキュメント概要の範囲では明記なし | | 主張する優位性 | 約 10 年の HTTP プロキシ本番実績、既存投資の再利用 | AI 用と通常用を分けない統合、Rust による性能・メモリ安全性 | | 自ホスト型モデル | KServe と連携(サービング層は外部委譲) | 独自の Inference Gateway 拡張で自前ルーティング | > [!gap] agentgateway については、standalone 版と mesh 版の二分、性能数値、[[Solo.io]] や [[kagent]] との具体的な統合方式のいずれも wiki に記載なし。ingest 済みなのは standalone ドキュメントのトップページのみで、下位 10 ページ(`mcp`・`llm`・`agent` 等)は未取り込みである。したがってツールポイズニング対策の具体的機構も不明のままである。Envoy AI Gateway 側もベンチマーク数値は KDF オーバーヘッド以外に記載なし。 --- ## 5. エージェントワークロード層 ### 5.1 なぜ第 3 のワークロード形状か [[@2026__KubernetesBlog__Running Agents on Kubernetes with Agent Sandbox]] は世代交代を次のように描く。生成 AI との対話は当初、**50 ミリ秒程度**で起動・実行・終了する**ステートレスな関数呼び出し**として扱われていた。現在は複数エージェントが協調しながら常時稼働し、文脈を維持し、外部ツールを使い、コードを書いて実行し、互いに通信するという**長時間稼働のパターン**へ移行している。エージェントは典型的に **孤立(isolated)・ステートフル・シングルトン**であり、「LLM のための**デジタルワークスペースまたは実行環境**」として振る舞う。必要とするのは**永続的なアイデンティティ**、**(しばしば未信頼な)コードを書いて実行するためのセキュアなスクラッチパッド**、そして**サスペンドと高速再開**をサポートするライフサイクルである。訓練・推論との差分を整理すると 6 点になる。 1. **ステートフル性と個体としてのアドレス可能性**。協調するマルチエージェントシステムは安定したホスト名とネットワークアイデンティティを要する。推論のステートレスなレプリカ集合ではこの要求が発生しない。 2. **未信頼コードの実行**。訓練・推論のワークロードは「自分が実行するコードを自分で書く」ことがないため通常のコンテナ隔離(runC)で足りる。**エージェントだけが gVisor / Kata Containers / microVM という追加の隔離層をワークロード種別のレベルで要求する。** 3. **バースト/アイドルサイクル**。「タスク間で数時間アイドルになりうる」「数週間にわたるほとんどアイドルな協調プロセス」。従来 Web サーバは「定常的なステートレストラフィック向けに最適化」されている。 4. **セッション単位隔離のスケール破綻**。理論上は **StatefulSet(サイズ 1)+ headless Service + PersistentVolumeClaim をエージェントごとに**組み合わせれば近似できるが、大規模に運用すると「**運用上の悪夢**」になる。単一ワークロードとしては表現可能だが、エージェント数のオーダーで増殖させる運用が破綻する。 5. **コールドスタートが体験品質を直接決める**。**Pod の新規起動は約 1 秒のオーバーヘッドを追加する**。「マイクロサービスの新バージョンをデプロイする分には全く問題ないが、**アイドル状態から再起動されたエージェントにとって、1 秒のコールドスタートは対話の連続性を壊す**」。すなわち起動レイテンシがインフラ効率指標ではなく**ユーザー体験の指標**になる。 6. **サスペンド/再開がワークロード契約に含まれる**。Deployment / StatefulSet の契約にはこの語彙がそもそも存在しない。 ### 5.2 kagent [[kagent]] は [[Solo.io]] が主導する Kubernetes ネイティブフレームワークであり、AI エージェントと MCP サーバを**宣言的(ノーコード)に構築・デプロイ**できる。**CNCF サンドボックスプロジェクトとして採択**されており、[[Lin Sun]](Solo.io の Open Source Head、CNCF TOC メンバー)や [[Peter Jausovec]] が関わる。発案の契機は組織的脆弱性の実例である([[@2025__PlatformersCommunity__An Introduction to Kagent - The Open Source Framework for AI Agents on Kubernetes]])。 > ハリケーン発生時、Solo.io の保険会社顧客の本番環境が週末にダウンし、クレーム対応が集中する中で主要エンジニアが緊急対応を強いられた。この事例が「**深い専門知識が少数の専門家に集中している**」という脆弱性を露呈した。タイムラインは 2024 年冬に構想開始、2024 年後期〜2025 年初期に試作、**2025 年 3 月にオープンソース化**である。アーキテクチャは「コントローラーと宣言的 API により、YAML ファイルでエージェント定義が可能」とされる。エージェントは **システムプロンプト + LLM + ツール** の 3 要素に分解され、ReAct 様のエージェントループ(ユーザークエリ → LLM がツール呼び出しを返す → エージェントが実際に呼ぶ → 結果を LLM へ戻す → 最終応答)で動く。ツールは JSON スキーマ(`name`, `description`, `input_schema`)で定義される。 **MCP** は「**USB-C ポートのような普遍的アダプター**」として「**ツールの爆発**」問題を解決する。複数エージェントが同じ外部システムへ個別にツールを実装するのは**アンチパターン**であり、MCP サーバが中間層となって再利用を可能にする。**A2A** により CrewAI・ADK・LangGraph など異なるフレームワークとの相互運用を実現する。 wiki 内で最も具体的な実行例は Istio Ambient Mesh + Argo CD の設定ミス自動修正デモである。エージェントが Kubernetes ツールで情報収集し、**HTTPRoute がポート 8080 を指すが実サービスはポート 80 でリッスン**という設定ミスを特定し、**許可取得後**に GitHub ツール(MCP 経由)でブランチ作成・YAML 修正・PR 生成まで自動化する。wiki はこれを「完全自律ではなく、**承認ゲート付きの自律修復フロー**」と評価する。 2026 年 8 月時点の実績は **163 回のリリース、174 名の貢献者、1,503 件のコミット、3,400 以上の GitHub スター**である。 **ロードマップは 2 時点で大きく異なる**ため区別が必要である。2025 年 8 月時点ではマルチフレームワーク対応(ADK 統合)・Bring Your Own MCP・関連プロジェクトとしての Agent Gateway が挙がっていた。一方 [[@2026__KagentDevBlog__The Future of kagent]](著者 [[Eitan Yarmush]]、2026-08-01)は運用経験から識別された **3 課題**を提示する。 1. **セキュリティ**: エージェントは危険性があり、ランタイム環境の**サンドボックス化が必須**。 2. **ファイルシステム**: **独自ファイルシステムアクセス**があってこそ長時間の問題解決が可能になる。 3. **効率性**: エージェントは **24 時間稼働が不要**なため、常時コンピュート予約は非効率。 wiki はこの 3 課題が「そもそも『**常時起動のコンテナ**』を前提とする Kubernetes の **Deployment 抽象**が、間欠的に短時間だけ動くエージェントのワークロード特性と**根本的にミスマッチ**していることを示す」と整理し、kagent チームが「Deployment の上に機能追加するのではなく、**ランタイム基盤自体を置き換える**」方針を選んだと評価する。移行先が [[Agent Substrate]] である。移行戦略は `release/v0.10.x` で現行ランタイムのサポートを継続しつつ `main` に新機能を集約し、**破壊的変更を含む**マイグレーションガイドを公開する形をとる。API 刷新は GitHub issue #2366 で議論される。 > [!gap] **kagent の CRD 名は wiki に一切ない。** `Agent`・`ModelConfig`・`Tool`/`ToolServer`・`Team` といったリソース名は vault 全体を検索しても 0 件である。kagent-dashboard / UI、kmcp、「kagent 2.0」というバージョン呼称も記載なし。コントローラの内部構造(reconcile ループ、コンポーネント構成)も「コントローラーと宣言的 API」という一文以上の記述はない。 ### 5.3 2 つの解法分岐: Agent Sandbox と Agent Substrate 同一の問題認識(サンドボックス化・アイドル時の低占有率・高速再開)から、**正反対の解**が出ている。これが本層で最も重要な構造である。 #### 5.3.1 Agent Sandbox(Kubernetes 内拡張) [[Agent Sandbox]](`kubernetes-sigs/agent-sandbox`、**Kubernetes SIG Apps**)は **Sandbox CRD** を中核とする。「Kubernetes プリミティブのみで構築された軽量・単一コンテナ環境」であり、3 点を提供する。 1. **未信頼コード実行のための強い隔離**: [[gVisor]] や [[Kata Containers]] のような**異なるランタイムをネイティブにサポート**し、マルチテナントかつ未信頼な実行に必要な**カーネル・ネットワーク隔離**を提供する。 2. **ライフサイクル管理**: アイドル環境を**ゼロへスケール**してリソースを節約しつつ、**中断した箇所から正確に再開**できることを保証する。 3. **安定したアイデンティティ**: 各 Sandbox に**安定したホスト名とネットワークアイデンティティ**を与え、マルチエージェントシステムで互いを発見・通信できるようにする。コールドスタート問題には **`SandboxWarmPool`**(Extensions 層)が応える。事前プロビジョニング済みの Sandbox Pod のプールを維持することで「**コールドスタートを事実上排除する**」。ユーザーは `SandboxTemplate` に対して `SandboxClaim` を発行するだけでよく、コントローラが事前ウォームアップ済み環境を即座に引き渡す。設計思想として、「AI 領域の変化が非常に速いため、**さらに高速な反復・開発を可能にする Extensions API 層**を備えて構築されている」。コア(Sandbox CRD)と Extensions を分離し、コア API の安定性を保ちながら実験的機能を素早く回す。マニフェストも `manifest.yaml`(コア)と `extensions.yaml`(拡張)に分離配布され、AI エージェント向けに Python SDK `k8s-agent-sandbox` が提供される。 > [!gap] 正確を期すと、**wiki 内で「CRD」と明示されているのは `Sandbox` のみ**である。`SandboxWarmPool` は Extensions として、`SandboxTemplate`・`SandboxClaim` はワークフロー記述の中で登場する。また **snapshot / restore / pause / checkpoint という語は Agent Sandbox の記述に一切使われていない**(「ゼロへスケール」「中断した箇所から正確に再開」のみ)。「code interpreter」「computer use」という用語も使われていない。Agent Sandbox 自体の CNCF ステータスも記載なし(CNCF Sandbox なのは kagent のほう)。ウォームプールから引き渡す際の実測レイテンシも記載なく、定量値は「Pod 起動 = 約 1 秒」のみである。隔離バックエンドについては、gVisor と Kata Containers が**選択肢として中立に併記される**のみで、**Agent Sandbox ブログ自体は性能トレードオフを論じていない**。[[gVisor]] ページはこの点を明示的に注記している。性能を論じるなら別ソースを引く必要がある([[@2021__Middleware__A Fresh Look at the Architecture and Performance of Contemporary Isolation Platforms]] の gVisor 起動約190ms・Kata 起動約600ms 等)。 #### 5.3.2 Agent Substrate(Kubernetes 外の専用基盤) [[Agent Substrate]] は **Google が創立した OSS** であり、**エージェントサンドボックスの完全なライフサイクル管理**を提供し、**100 ミリ秒未満の再開保証**を実現し、**[[microVM]] や [[gVisor]] を含む複数のサンドボックス技術**をサポートする。 kagent が移行することでもたらされる 3 つの改善は次のとおり。**セキュリティ**——すべてのコンピュートがデフォルトでサンドボックス化され、権限昇格やシステム領域への無許可アクセスが防止され、ネットワークトラフィックも完全制御される。**ファイルシステム**——各エージェントが専用ファイルシステムを取得し、**サスペンド時にスナップショット化**され既知の状態から再開できる。**効率性**——エージェントがワーカープールを共有し、実行中でないエージェントはリソースを保持しない。Solo.io の事例では **8 ポッドで 250 エージェント**という密度を実現している。 > [!gap] [[Agent Substrate]] ページ自身が gap 警告を出している。「現時点で Agent Substrate に関する情報は [[@2026__KagentDevBlog__The Future of kagent]] からの言及のみで、**独立した公式ドキュメントやリポジトリは未確認**」。MCP・A2A・agentgateway・ADK との関係も記載なし。 #### 5.3.3 対比 | | [[Agent Sandbox]] | [[Agent Substrate]] | |---|---|---| | 主体 | Kubernetes **SIG Apps** | **Google** 創立の OSS | | 採用者 | Kubernetes 本体エコシステム | **[[kagent]]** が次世代ランタイムとして採用 | | 解法の方向 | **Kubernetes 本体を宣言的 CRD で拡張** | **Kubernetes の Deployment 基盤から離れ、外に専用基盤を作る** | | 隔離技術 | gVisor / Kata Containers | microVM / gVisor | | 再開性能 | Pod 起動約 1 秒 → WarmPool で事実上排除 | **100 ミリ秒未満の再開保証** | | 状態保持 | 「中断した箇所から正確に再開」(snapshot 語なし) | **サスペンド時にスナップショット化** | | 密度 | 記載なし | **8 ポッドで 250 エージェント** | wiki の言葉を借りれば、「同じ問題意識から、一方は『**Kubernetes をエージェント向けに拡張する**』、他方は『**Kubernetes の外に専用基盤を作る**』という対照的な解を導いている点が、両ソースを並べて初めて見える構造である」。 ### 5.4 プロトコル層: MCP と A2A 役割分担は明快である。 > **MCP がエージェントとツールの接続を標準化するのに対し、A2A はエージェント同士の接続を標準化する。** [[Model Context Protocol]] は AI エージェントが外部ツール/API を**動的に発見・呼び出す**ためのオープン仕様であり、API への**自然言語インターフェース**を標準化する。本稿の観点で重要な論点が 3 つある。 1. **サーバ側とインフラ側の 2 層で並行に成熟している**。Google の Production Agent や Amazon の共通ツールハンドルが「エージェントに何を公開するか」という**サーバ側**の標準化であるのに対し、[[agentgateway]] は「複数の MCP サーバをどう集約・仲介・保護するか」という**インフラ層**の標準化である。 2. **ユーザーコンテキスト伝播のギャップ**。MCP 仕様には**ユーザー識別情報を伝播する標準機構がない**。[[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]] はこれを「MCP 仕様における最大の未解決課題」と明言し、JWT クレームを個々の JSON-RPC リクエストコンテキストへ注入する **Context-Aware Broker Protocol(CABP)** の 6 段パイプライン(Token Extract → Claim Validate → ACL Resolve → Context Inject → Response Sanitize → Audit Emit)として定式化する。 3. **ツール記述の質が信頼性を直接左右する**。`get_usage_info` という曖昧な名前・説明のツールをエージェントが一貫してスキップし、**記述を 4 文に拡張しただけでコード変更なしに解決した**という事例がある。`tools/list` レスポンスが「サーバとエージェント間の**事実上の API 契約**」である。 [[Agent2Agent Protocol (A2A)]] は、エージェントが互いの**能力を発見**し、**対話モダリティ(テキスト・フォーム・メディア)を交渉**し、**長時間実行タスクで協調**し、**内部状態やツールを露出させずに**動作できるようにする。 > [!gap] A2A の仕様バージョン・策定主体・ガバナンスは wiki に記載なし。[[@2025__SREcon25EMEA__From 4 Hours to 8 Minutes with AI Agents that Transform SRE Incident Response]] 自身が「A2A プロトコルの安定性・標準化状況(2025 年 10 月時点)は公式仕様を別途確認が必要」と明記している。 ### 5.5 運用: AIRE と AgentOps / AgenticOps の区別 [[@2025__SREcon25EMEA__From 4 Hours to 8 Minutes with AI Agents that Transform SRE Incident Response]]([[Peter Jausovec]]、USENIX SREcon25 EMEA、2025 年 10 月ダブリン)は **AIRE(AI Reliability Engineering)** を「ソフトウェア信頼性を高めるために、**コンテキスト対応エージェントを既存エンジニアリングワークフローへ埋め込む**取り組み」と定義する。アーキテクチャは複数エージェントが **MCP サーバを経由**して Azure・AWS・GCP・GitHub・Slack へアクセスする**二段の間接化**を特徴とする。キー能力は 4 段階で構成される。**Operational Knowledge**(ナレッジグラフ)→ **Awareness**(ビジネスインパクト理解・自律トリアージ)→ **Investigation**(過去インシデント・直近デプロイ・既知障害パターンから根本原因仮説を生成・検証)→ **Resolution**(最小限の人手介入で修正・復旧)。[[インシデントレスポンスAIレベル]] はこれを「IR Levels の **IR3〜IR4** が実際には何を意味するかを具体化した実装モデル」に対応づけ、Investigation が IR3、Resolution が IR4 に相当するとする。 > [!warning] **「4 時間から 8 分へ」という数値は wiki 内で二重に「裏付けなし」と警告されている。**「スライド本文では裏付けデータが示されていない(タイトルと公式ページ概要のみに記載)」「スライド内に根拠データなし。transcript なし」。引用する際は必ずこの留保を付す必要がある。分類上の注意として、[[エージェントシステム運用]] は **AgentOps と AgenticOps を明確に区別する**。 > **AgenticOps** はエージェントを使って**従来のシステムを**保守する取り組み。**AgentOps** はエージェントシステム**を**保守する——**対象と手段が逆転している**。この区別に従えば、**kagent / AIRE は AgenticOps の側**である。実際 wiki は AIRE を「AgentOps サーベイが定義する『AgenticOps』の典型実装」と明記する。一方 AgentOps は「LLM ベースのエージェントシステムの**信頼性・安全性・制御可能性**を維持するための運用技術の体系」であり、4 段階(モニタリング → 異常検知 → 根本原因局所化 → 解決)からなる。従来 AIOps との本質的差異は「トレースが**構造的実行パス**(マイクロサービス)から**意味的決定パス**(エージェント)へと変化する」点にあり、異常検知の正解定義が「統計的逸脱」から「**意味的タスク失敗**」へ移る。エージェント基盤を運用する側にとって示唆的な測定値をいくつか挙げる。[[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]] は失敗を Aborted / Reported / **Silent(警告なしの誤出力)** に分類し、**Silent 失敗率が AutoGen 65.71%・Mini-SE 61.09%・MapCoder 21.82%** と測定した。障害診断の全体精度はルールベース・LLM ベース両方で **56% を超えない**。単一障害で pass@1 が**最大 83.87% 低下**し、**パイプラインパターンが最も脆弱、反復パターンが最も頑健**である。また [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] は τ-bench で修復率が **43.09% → 60.16%(事後診断のみ)→ 69.11%(実行時介入を追加)** と改善することを示し、一度きりの診断フィードバックは **tool-call ステップ 13 で追従率 50% を割る**と報告する。 --- ## 6. 横断的考察: 反復する設計パターン 4 層を通して観察されるパターンを 5 つ抽出する。 ### 6.1 「単純化されすぎた旧モデル」を 2 軸で同時に刷新する [[Kubernetes Workload・PodGroup API]] の観察が最も明快である。 > DRA とギャングスケジューリングは、Kubernetes コアが**2 つの異なる軸**で「単純化されすぎた旧モデル」を置き換える、同時並行の進化として読める。[[Dynamic Resource Allocation (DRA)]] は **Pod あたりのデバイス要求表現力**(単一の線形量しか表せない旧デバイスプラグイン API)を刷新し、本概念は **Pod 集合のスケジューリング単位**(1 Pod 単位でしか考えられない旧 pod-by-pod cycle)を刷新する。この観点を §4・§5 へ延長すると、GAIE は**トラフィックルーティングの意味論**(全リクエストが等価という前提)を刷新し、Agent Sandbox は**ワークロード形状そのもの**(常時起動のステートレスコンテナという前提)を刷新している、と読める。4 層はすべて同型の運動である。 ### 6.2 ライフサイクルを実行主体へ厳密に一致させる KEP-407 が PodGroup の OwnerReference を Leader Pod に置き、KEP-4671 が `Workload`(長寿命の設定意図)と `PodGroup`(一時的なスケジューリング単位)を分離したのは、いずれも同一原理の適用である。前者が後者に **5 ヶ月先行**して同型の設計へ到達した事実は、この原理が設計者の趣味ではなく問題構造から導かれることを示唆する。 ### 6.3 etcd の 1.5MB 上限が API 設計を規定する同じ制約が独立に 2 箇所の設計を決めている。KEP-4671 は PodGroup を Workload から分離する 3 番目の理由として挙げ、TAS は `TopologyAssignment` のエンコーディングを v1beta1 から v1beta2 へ刷新する動機として挙げた(2〜3 万ノード → 6 万ノード → 10 万ノード超)。宣言的 API のスケール限界が、しばしばアルゴリズムではなくストレージ層の物理制約で決まる。 ### 6.4 「コアは汎用に保ちレイヤーを重ねる」 [[オートスケーリング]] はこの原則を独立に確認する。 > WVA は Kubernetes HPA のコアへ LLM 固有ロジックを組み込むことを明示的に退け、**HPA をアクチュエータとして再利用しつつ意思決定ロジックのみを上位に重ねる**。これは **KEDA がイベントソース対応を HPA の外側に拡張として実装するパターンや、Knative Pod Autoscaler(KPA)が Kubernetes 標準スケジューラの外側でリクエストベーススケーリングを提供するパターンと同型**であり、モデルサービングの黎明期(KFServing/KPA、2020 年)から LLM 時代(WVA、2026 年)まで一貫して採用されている。 ### 6.5 決定論性を性能より優先する Kueue が素の Kubernetes Job よりメイクスパンで劣ることを受け入れてまで決定的な admission 順序を選ぶ判断(§2.3.3)と、TAS が最下位レベル単位での割当確定を強制してレース条件を潰す判断(§2.2.4)は、同じ価値観に立つ。多テナント・本番環境では**公平性・予測可能性・再現性**がベストケース性能に優越する。 --- ## 7. 未解決の論争点 ### 7.1 吸収か、レイヤー重ねか §6.1 の「エコシステム実装をコアへ吸収する」原則(DRA・KEP-4671)と、§6.4 の「コアは汎用に保ちレイヤーを重ねる」原則(WVA・KEDA・KPA)は、表面上は逆向きである。 wiki はこの矛盾を明示的には論じていない。ただし手がかりはある。KEP-4671 が「複数ワークロードキュー・公平性」を Kueue/Volcano へ委ね続ける**非対称性**を [[コンテナオーケストレーション]] が指摘しており、これは両原則の折衷点として読める。DRA がデバイスプラグイン API を実質的に置き換えたのとは異なり、ギャングスケジューリングでは**コアがフレームワークのみ提供し、政策層はエコシステムに残す**という分業が選ばれた。 > [!note] この折衷の解釈は筆者によるものであり、wiki が直接述べているのは「非対称な関係にある」という事実の指摘までである。 ### 7.2 Kubernetes 内拡張か、外部専用基盤か §5.3 の Agent Sandbox 対 Agent Substrate は、この論争が最も先鋭化した形である。同じ 3 要件から正反対の解が出ており、どちらが勝つかを決める証拠は現時点の wiki には存在しない。判断材料として wiki が持つのは、Agent Substrate 側の **100 ミリ秒未満の再開保証**と **8 ポッドで 250 エージェント**という密度の主張だけであり、Agent Sandbox 側の対応する数値は測定されていない。なお [[@2023__arXiv__The Flux Operator]] は、この論争の**別領域における先例**として読める。[[Kubernetes]] ページは Flux Operator を「Kubernetes の外で確立された既存のワークロードマネージャをそのまま内側へ持ち込む」逆方向のアプローチとして位置づける。論拠は「Flux へのジョブ投入が Kubernetes API・etcd に負荷をかけず、**数十万〜数百万ジョブへスケール可能**」であることだった。 ### 7.3 理論的保証はいつ実装されるか §2.5 のとおり、HiveD の配置保証も Themis の公平性理論も、Kubernetes ネイティブ実装では Alpha/Beta 時点で先送りされている。KEP-4671 の North Star Vision 8 要件のうち、要件(8)(Cluster Autoscaler/Karpenter 統合を伴うギャングスケジューリング)は「最大の労力を要する」と明記されつつ、初期実装では `NominatedNodeName` によるリソース予約の緩和のみである。興味深いのは、**同じ問題を Kueue が既に 2 パス設計で解いている**(§2.2.7)一方でコア側が未着手という非対称である。エコシステム実装がコアより先行する構図が、吸収を志向する KEP の前提と緊張する。 ### 7.4 ルーティング層の新規性は本物か [[KVキャッシュ管理]] が立てる問いは重要である。 > GAIE の Precise Prefix-Cache Aware Scheduling は、SGLang の longest-shared-prefix-first や Mooncake の Conductor が既に確立したキャッシュ対応ルーティングのアルゴリズムと本質的に同等か、それとも Kubernetes ネイティブな実装固有の制約(**EPP とバックエンド間のテレメトリ伝達遅延**等)で異なる特性を持つか。同様に、GAIE 自体の導入オーバーヘッド(TTFT +3〜11ms)がエンジン内ルーティングと比べてどの程度の追加コストかも未検証である。 --- ## 8. カバレッジの限界本稿の記述可能性は wiki のカバレッジに制約される。層別の充足度を明示する。 | 項目 | 充足度 | 主な欠落 | |---|---|---| | **DRA** | 厚い | partitionable devices 拡張(KEP #4815)の原 KEP 未取り込み。GA 条件を満たしたベンダー実装名が不明 | | **TAS** | 厚い | 「NVLink ドメイン」という語はなく、扱うのはラック/ブロック。ノード内トポロジは DRA 側に分離 | | **Kueue** | 中程度 | クォータモデルの形式的定義、プリエンプションポリシー分類、gang admission 機構、`Workload` CRD 定義、Kubeflow 統合がいずれも欠落 | | **WAS** | **ほぼ absent** | 独立概念として存在しない。KEP-5710 は未 ingest と wiki 自身が明記 | | **JobSet** | **極めて薄い** | 定義・API 構造・failure policy・TPU スライス・Job/Indexed Job との関係・メンテナすべて欠落 | | **LeaderWorkerSet** | 中程度 | ローリングアップデート詳細、サブグループ、per-group スケーリング、**llm-d との関係**が欠落 | | **KEP-407 / KEP-4671** | 厚い | KEP-407 の実装ステータス不明。KEP-4671 の North Star Vision 8 要件のうち 4 つのみ判明 | | **PodGroup 系譜(上流以前)** | 薄い | Volcano・coscheduling・YuniKorn の設計・API 記述なし | | **KServe** | **極めて薄い** | 一次ソースは 2020 年の KFServing 論文のみ。現行の LLM 向け CRD・Open Inference Protocol・ModelMesh すべて欠落 | | **NVIDIA Dynamo** | 厚い | TP レイアウト変換オーバーヘッドの定量評価なし。設計空間探索は proprietary シミュレータ依存 | | **llm-d** | 中程度 | バッカー(Red Hat)の明示記述なし。well-lit paths のカタログなし。LWS との関係なし | | **AIBrix** | 厚い | ルーティング戦略の評価が Bird-SQL・A10/L20 に限定 | | **GAIE** | 中程度 | InferenceModel 等の現行 CRD 名が不明。「長命ストリーミング」を固有課題として名指しする記述なし | | **Envoy AI Gateway** | 中程度 | ベンチマーク数値は KDF オーバーヘッド以外なし | | **agentgateway** | 薄い | standalone ドキュメントのトップページのみ ingest。下位 10 ページ未取得。性能数値なし。Solo.io / kagent との統合方式なし | | **kagent** | 中程度 | **CRD 名がすべて欠落**。dashboard・kmcp・「2.0」呼称なし | | **Agent Sandbox** | 薄い | ソース 1 本。snapshot/restore の語彙なし。ウォームプールの実測レイテンシなし | | **Agent Substrate** | **極めて薄い** | ソース 1 本。wiki 自身が gap 警告。独立した公式ドキュメント未確認 | ### 8.1 優先的に埋めるべきギャップ本稿を書くうえで最も痛かった欠落を、ingest 候補として 5 件挙げる。 1. **JobSet の一次ソース**(`kubernetes-sigs/jobset` の README / API リファレンス)。オーケストレーション層の 2 本柱の一方が事実上空白である。 2. **KServe の現行ドキュメント**。デプロイスタックの系譜の起点でありながら、2020 年で記述が止まっている。 3. **kagent の API リファレンス**。CRD 名すら書けない状態は、エージェント層の記述可能性を大きく損なう。 4. **agentgateway の下位ドキュメント**(`mcp`・`llm`・`agent`)。ツールポイズニング対策という固有の主張が検証できない。 5. **KEP-5710(workload-aware preemption)**。wiki 自身が未取り込みと明記しており、「WAS」という問いに答えるための唯一の経路である。 --- ## 9. 関連ページ **概念**: [[Dynamic Resource Allocation (DRA)]] / [[トポロジ考慮型スケジューリング]] / [[Kubernetes Workload・PodGroup API]] / [[GPUクラスタスケジューリング]] / [[GPU多重化(MPS・MIG)]] / [[コンテナオーケストレーション]] / [[オートスケーリング]] / [[LLMサービング管理]] / [[Prefill-Decode分離]] / [[KVキャッシュ管理]] / [[AIゲートウェイ]] / [[エージェントシステム運用]] / [[インシデントレスポンスAIレベル]] / [[Virtual Private Cluster]] / [[共有異常]] / [[ネットワーク対応スケジューリング]] **実体**: [[Kueue]] / [[LeaderWorkerSet]] / [[Dynamic Accelerator Slicer]] / [[KFServing]] / [[llm-d]] / [[NVIDIA Dynamo]] / [[AIBrix]] / [[NIXL]] / [[KVBM (KV Block Manager)]] / [[vLLM]] / [[Triton Inference Server]] / [[Gateway API Inference Extension]] / [[Kubernetes Gateway API]] / [[Envoy AI Gateway]] / [[Envoy]] / [[agentgateway]] / [[kagent]] / [[Agent Sandbox]] / [[Agent Substrate]] / [[Agent Development Kit]] / [[Model Context Protocol]] / [[Agent2Agent Protocol (A2A)]] / [[Solo.io]] / [[Kubernetes]] / [[gVisor]] / [[Kata Containers]] / [[HiveD]] / [[Philly]] / [[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling|Themis]] / [[kube-burner]] **人物**: [[Patrick Ohly]] / [[Aldo Culquicondor]] / [[Abhishek Malvankar]] / [[Lin Sun]] / [[Peter Jausovec]] / [[Eitan Yarmush]] / [[Dan Sun]] / [[Clive Cox]]