2026年のAI推論基盤は、単に「GPUを積んだKubernetesクラスタ」を用意すれば成立する段階を終えた。ボトルネックはGPU枚数よりも、どの単位で、どの順序で、どの制約を優先してGPUを割り当てるかというスケジューリング設計に移っている。特に、リアルタイム推論とバッチ推論が混在し、MIGスライス・時分割・DRA(ResourceClaim)が同時に存在する構成では、既存の運用知見だけでは設計が破綻しやすい。本稿はKubernetes標準のGPU割り当ての実装限界を整理した上で、NVIDIA KAI Schedulerの実装パターンを技術的に掘り下げ、導入判断と運用コストまで含めて設計指針を提示するものである。

Kubernetes標準スケジューラがGPU推論基盤で詰まる構造的理由

まず前提として、KubernetesのDevice Pluginフレームワーク自体は成熟している。Kubernetes公式ドキュメントではDevice Pluginsはv1.26でstable扱いであり、GPUを含むベンダー依存デバイスを拡張資源として扱う基盤は整っている。一方で、この成熟は「ノード上でデバイスを公開し、Podに割り当てる仕組み」の成熟であり、「多目的AI基盤における最適割り当て意思決定」の成熟とは一致しない。

現場で表面化する限界は大きく4つである。第1に、スケジューリング単位の粗さである。標準的なGPU要求は `nvidia.com/gpu: 1` のような整数要求が中心で、細粒度共有はデバイスプラグインや運用ルールに委譲される。第2に、割り当て最適化の文脈欠如である。標準kube-schedulerは汎用ワークロード向けであり、推論特有の「短命Pod大量投入」「同時多モデル混載」「通信近接性」を第一級で扱わない。第3に、共有時の安全性と性能トレードオフがユーザー側責任になりやすい点である。NVIDIA GPU OperatorのTime-Slicingドキュメントが明示する通り、time-slicingはMIGと異なりメモリ/障害分離を提供しない。第4に、キュー単位の公平性とSLO優先度の同時達成が難しい点である。標準機能だけで実装すると、最終的に独自コントローラ群・優先度運用規約・手動の再均衡ジョブに依存しやすい。

Dynamic Resource Allocation(DRA)はこのギャップを埋める方向に進んでいる。DRAはResourceClaim/DeviceClass/ResourceSliceを導入し、デバイス選択と共有をより宣言的に扱えるため、GPU要求を整数個数から脱却させる基盤になり得る。ただし2026年3月時点でも、DRAは機能ゲート付き拡張の側面が残り、ドライバ実装差と運用設計差が結果を左右する。つまりDRAは「万能解」ではなく、「次世代スケジューラが活用する共通API面」と捉えるほうが実務的である。

NVIDIA KAI Schedulerの実装パターン: トポロジー認識・MIG統合・時分割

KAI Schedulerは、Kubernetes上でAIワークロードを高密度運用するための専用スケジューラとして設計されている。公式READMEと設計文書を確認すると、特徴は単なる「別スケジューラ」ではなく、GPU基盤で衝突しやすい複数の制約を同時に扱う実装にある。2026-03-02公開のv0.13.0では、DRA関連の扱い改善やトポロジー制約周辺の機能追加が継続しており、実装が急速に拡張している。

第一の軸はトポロジー認識である。KAIのTopology Aware Scheduling(TAS)設計では、ラック/ゾーン/ノード等の階層トポロジーをCRDベースで扱い、`required` と `preferred` を分離して配置意思決定を行う。これにより「理想配置が空くまで待つ」か「性能を少し妥協して早く開始する」かをジョブ単位で制御できる。推論基盤で問題化しやすいのはcold startそのものではなく、起動後のレイテンシぶれである。通信経路が遠いPod群に分散配置されると、初回ロード時間よりも継続推論のp95/p99が劣化しやすい。TASはこの点で、スケジューラ段階から通信近接性を明示制約化できる。

第二の軸はMIGとGPU共有の統合運用である。KAIのGPU sharingドキュメントは、`gpu-fraction` や `gpu-memory` の注釈で分割要求を受け取るが、同時に「メモリ隔離を強制しない」ことを明示している。これは危険ではなく、責任境界の明確化である。ハード分離が必要な経路はMIG、過負荷吸収や小規模推論の高密度化はtime-slicing/分割合意で吸収し、ワークロード分類で使い分けるのが設計原則になる。NVIDIA GPU Operator文書でも、MIGはハードウェアレベルのメモリ/障害分離を提供し、time-slicingはそれを提供しない代わりに柔軟な多重化を提供すると整理されている。KAI導入時はこの差分をキュー設計に写像することが重要である。

第三の軸は時間軸での公平性制御である。KAIはTime-based Fairshareを備え、瞬間的な空き資源配分だけでなく、履歴利用を考慮した再配分・reclaimを行う。短時間バースト推論と長時間バッチ推論が同居するクラスタでは、「今空いているから取った者勝ち」を続けると、特定テナントが恒常的に得をする。KAIの時間減衰付き公平性は、この偏りを数理的に補正する。GPU資源争奪が日次で揺れる組織では、ここが標準スケジューラとの差分になる。

性能比較をどう読むか: ベンチマーク値より、失敗モード差を測る

実務で頻出する誤りは、単一ベンチマークで「KAIが何倍速いか」を先に求めることである。2026年3月時点で公開情報を確認すると、KAIはスケールテスト手順や評価観点(トポロジー制約付き分散ジョブ、GPU配分、キュー制御)を整備している一方、標準kube-schedulerとの完全同条件A/Bの汎用公開値は限定的である。よって導入判断では、絶対性能値より失敗モードを比較する方が再現性が高い。

比較軸は以下の4点で設計すべきである。1) 割り当て成功率: 要件付きジョブ(トポロジー、MIGプロファイル、共有可否)が初回で成立する割合。2) Pending滞留時間分布: 平均値ではなくp95/p99を追う。3) コールドパス時間: Pod作成から初回推論成功までを分解し、image pull、model load、queue waitを別計測する。4) 資源断片化率: 未使用GPUメモリ断片と「割り当て不能な空き」を分けて観測する。

標準kube-scheduler中心構成では、GPU関連の制約を外部コンポーネントに分散させるため、障害時に「どこで詰まったか」が見えにくくなる。KAIはスケジューライベントやキュー/PodGroup中心の説明可能性を設計に含めるため、失敗解析コストが相対的に低い。この差は、ピーク負荷時の復旧時間(RTO)に直接効く。速度比較よりも、障害時の調査可能性をKPI化する方が、運用組織にとって価値が高い。

導入判断フレーム: どの条件でKAIへ移行すべきか

移行判断は「GPU台数」ではなく「制約密度」で決めるべきである。以下の条件が2つ以上当てはまるなら、標準スケジューラ拡張を積み増すより、KAIを中核に据える方が総コストを下げやすい。

条件A: 1クラスタ内で、リアルタイム推論・バッチ推論・検証ジョブが同時稼働し、優先度衝突が恒常化している。
条件B: MIGとtime-slicingを併用し、ワークロード特性で割当ポリシーを分ける必要がある。
条件C: 分散推論/推論前処理で通信近接性が性能を左右し、配置ミスがp99遅延を悪化させる。
条件D: テナント間の「取り得」問題が顕在化し、時間軸公平性が監査対象になっている。
条件E: autoscaler連携時に、Pending解消の挙動が読めず過剰スケール/不足スケールを繰り返している。

逆に、単一チーム・単一モデル・ほぼ固定負荷で、GPU共有も限定的な環境では、標準構成+運用改善の方がシンプルである。重要なのは、KAIを「性能最適化オプション」ではなく「制約解決のアーキテクチャ選択」として評価することである。

運用コストの現実: 設計を変えずに導入すると失敗する

KAI導入で最も多い失敗は、スケジューラだけ入れ替えてキュー/ワークロード規約を旧来のままにするパターンである。成功させるには、少なくとも次の実装設計が必要である。

1. キュー設計の再定義
「部署単位」ではなく「遅延要件×再実行許容度×分離要件」でキューを切る。例として、`realtime-infer`(非プリエンプト/低遅延)、`batch-infer`(プリエンプト可)、`build-eval`(夜間優先)の3層に分ける。

2. GPUプロファイルの宣言的分類
MIG必須、time-slicing許容、専有必須を明示し、Podテンプレート/Admissionで逸脱を拒否する。GPU Operatorの制約(例: time-slicing時のメトリクス制限、MIG変更時のワークロード停止要件)を運用Runbookに固定化する。

3. cold start対策をスケジューリングと分離して管理
cold startは画像配布・モデル配布・初期化処理の問題であり、スケジューラ単体では解決しない。KAI導入と同時に、イメージキャッシュ、モデルウォーム、ノード事前起動を別レイヤで実装し、`queue wait` と `init latency` を必ず別指標で追う。

4. DRA移行の段階運用
既存device plugin要求とDRA(ResourceClaim)要求を一気に混在させると運用が破綻しやすい。まずは新規ワークロードからDRA適用し、割り当て失敗理由の可観測性を確保してから全体移行する。

5. 成果指標を「GPU稼働率」だけにしない
稼働率上昇だけを追うと、待ち行列悪化や高優先度遅延悪化を見逃す。最小セットとして、`p99 first-token latency`、`pending p95`、`eviction rate`、`queue fairness drift` の4指標を採用する。

総じて、2026年の推論基盤で問われているのは「GPUをどう買うか」より「GPU制約をどう定式化して自動化するか」である。Kubernetes標準は重要な土台であり続けるが、制約密度が高い組織では、KAIのような専用スケジューラ層を採用しない限り、設計負債は運用チームに累積し続ける。構造転換とは、ツール追加ではなく、スケジューリングをプロダクト要件として設計することを意味する。

実装時の評価実験テンプレート
設計判断を机上比較で終わらせないために、最低2週間のA/B運用を推奨する。A系統を標準kube-scheduler中心(既存構成)、B系統をKAI有効化構成として、同一モデル群・同一トラフィックリプレイで評価する。評価期間は平日ピークと夜間バッチを必ず含める。観測指標は、(a)初回トークンまでのp95/p99、(b)再スケジュール回数、(c)PodGroup単位の待機時間、(d)スケールアウト後の安定化時間、(e)テナント別GPU時間配分偏差の5点である。ここで重要なのは、平均値ではなく裾野を比較することである。推論基盤の障害は常に尾部で発生し、平均改善だけではSLO違反を防げない。

コスト試算の実務式
GPU基盤の費用対効果は、単純なGPU稼働率ではなく、"有効推論時間"で評価すべきである。実務上は次の近似式が使いやすい。有効推論時間 = 総GPU時間 - (待機時間 + 失敗再実行時間 + 低優先度退避による空白時間)。KAI導入で削減されるのは主に待機時間と再実行時間であり、ここが大きい組織ほど費用対効果は高まる。逆に、ワークロードが単純で待機が小さい組織では改善余地が限定される。PoC段階でこの式に沿って差分を算出し、少なくとも月次で5〜10%の有効推論時間改善が見込めるかを本番移行基準にするのが現実的である。

組織運用への影響
KAI導入はインフラチームだけの課題ではない。アプリケーションチームには、キューラベル・共有可否・再起動許容度をデプロイマニフェストに明示する責任が生じる。SREには、従来のノード中心監視に加えて、キュー階層・公平性・reclaimイベント中心の観測運用が必要になる。結果として、"GPUを申請して配る運用"から、"SLOに応じて配分ポリシーを継続改善する運用"へ役割が変わる。この転換を設計しないまま導入すると、スケジューラ高度化の効果が組織で吸収されず、かえって障害時の責任境界が曖昧化する。

FAQ

KAI Schedulerを入れればcold start問題は解決するのか

解決しない。KAIは主に割り当て意思決定と公平性制御を改善する。cold startはimage pull、モデル読み込み、ランタイム初期化、ノード起動に分解して別対策が必要である。

MIGとtime-slicingはどちらを優先すべきか

分離要件がある経路はMIGを優先し、過負荷吸収や低優先ジョブの高密度化はtime-slicingを使うべきである。NVIDIA公式文書の通り、time-slicingはMIGのようなメモリ/障害分離を提供しないため、同一ポリシーで混在させないことが重要である。

KubernetesのDRAがあるならKAIは不要ではないか

DRAは重要な標準化レイヤであり、デバイス要求表現を改善する。しかし実運用では、キュー公平性、トポロジー最適化、再配分戦略などのスケジューリングポリシーが別途必要であり、KAIはその層を担う。

どの段階でPoCから本番移行するべきか

最低でも、優先度別SLO、共有ポリシー、失敗時Runbook、4つの運用KPI(p99遅延、pending p95、eviction率、公平性ドリフト)が揃った段階で移行するべきである。機能検証のみのPoCでは本番の衝突を再現できない。

参考文献