> [!abstract] 概要(arXiv abstract の日本語訳) > Generative AI(GenAI)、特に推論が急速に支配的なワークロード種別として台頭するにつれ、Kubernetes エコシステムはその固有の需要をネイティブにサポートするよう積極的に進化している。本産業論文は、新興の Kubernetes ネイティブなプロジェクト群を組み合わせることで、スケーラビリティやリソース効率といったコンテナオーケストレーションの利点を複雑な AI ワークフローにもたらす方法を示す。我々は、自動音声認識と要約からなる例示的なマルチステージのユースケースを実装・評価する。第一に、Kueue を用いてジョブを管理し、Whisper モデルで音声ファイルを転写するバッチ推論に取り組み、並列ジョブ実行を増加させるために Dynamic Accelerator Slicer(DAS)を用いる。第二に、転写文をまとめて要約するために大規模言語モデルへ渡す離散的なオンライン推論シナリオに取り組み、これは Kubernetes Gateway API Inference Extension(GAIE)を巡る最近の発展を活用した新規のソリューションである llm-d を用いてホストされ、推論リクエストの最適化されたルーティングを行う。我々の知見は、これらの相補的なコンポーネント(Kueue、DAS、GAIE)が結合して一貫性のある高性能なプラットフォームを形成し、Kubernetes が要求の厳しい GenAI ワークロードのための統一基盤として機能する能力を証明することを示す。Kueue は総メイクスパンを最大 15% 削減し、DAS は平均ジョブ完了時間を 36% 短縮し、GAIE は llm-d と連携して高負荷下でもテール Time to First Token 遅延を最大 90% 改善した。 ## 論文情報 - タイトル: Evaluating Kubernetes Performance for GenAI Inference: From Automatic Speech Recognition to LLM Summarization - 著者・所属: Sai Sindhur Malleni([[Red Hat]]、現在は NVIDIA)、Raúl Sevilla([[Red Hat]]、マドリード)、Aleksei Vasilevskii([[Red Hat]]、ミュンヘン)、José Castillo Lema([[Red Hat]]、マドリード)、André Bauer([[Illinois Institute of Technology]]、シカゴ) - 媒体: arXiv プレプリント(v3)。ユーザー報告および付属リポジトリ名(`icpe26-k8s-ai-apis`)から ICPE 2026 (ACM/SPEC International Conference on Performance Engineering) 採録の産業論文と推定される。ℹ️ 推定: 本文中に採録の明示的な記載はない。 - 発表年: 2026(arXiv 投稿日 2026-02-11、初出年 2026) - arXiv ID: 2602.04900 - コード・実験設定リポジトリ: https://github.com/RedHatResearch/icpe26-k8s-ai-apis ## 概要 本論文は、Kubernetes ネイティブな 3 つの新興プロジェクト([[Kueue]]、Dynamic Accelerator Slicer (DAS)、Gateway API Inference Extension (GAIE))を組み合わせ、自動音声認識(ASR)とLLM要約からなるマルチステージ GenAI 推論パイプラインを [[Red Hat OpenShift]] Service on AWS (ROSA) 上に実装・評価した産業論文である。バッチ推論(Whisper 転写)とオンライン推論(LLM 要約)の両方を対象に、スケジューリング・アクセラレータスライシング・分散推論ルーティングの各層で性能改善を定量化している。 ## 問題設定 - 入力: [Earnings-22 データセット](Earnings-22)から選定した 32 件の企業決算説明会の音声ファイル(medium Whisper モデル用 16 件、large Whisper モデル用 16 件)。 - 出力: (1) バッチ ASR 転写ジョブの完了時間・メイクスパン、(2) 転写文を要約する LLM 推論の TTFT・エンドツーエンド遅延。 - 前提条件: ROSA クラスタ(コントロールプレーン 3 ノード `m5.2xlarge`、インフラノード 3 ノード `r5.xlarge`、GPU ノード 1 台 `p4d.24xlarge`、NVIDIA A100 GPU 8 基、us-west2 リージョン)。OpenShift 4.19.16(Kubernetes 1.32 ベース)、NVIDIA GPU Operator v25.3.4。 - 評価スコープの限定: モデル精度は評価対象外とし、オーケストレーション基盤のシステムレベル性能・効率・運用オーバーヘッドのみに焦点を当てる。 ## 提案手法 - **アーキテクチャ**: 図 1 に示す技術スタックは、[[Red Hat OpenShift]] 上で ASR([[Whisper]] + Batch/Queue Scheduling を担う [[Kueue]])と LLM 推論/要約([[vLLM]] + Distributed Inference of LLMs を担う llm-d、GPU Slicing を担う DAS)を GPU ドライバ・ランタイム層の上に構成し、基盤は AWS EC2 の GPU ノード群である。 **Figure 1: 技術スタック全体像** ![[_attachments/arxiv-2602.04900/fig01-tech-stack-overview.png]] (Figure 1. OpenShift を基盤に、上段が ASR(Whisper)と LLM 推論(vLLM)のワークロード層、中段が Kueue(バッチ/キュースケジューリング)・llm-d(分散推論)・DAS(GPU スライシング)のオーケストレーション層、下段が GPU ドライバ・ランタイム + GPU パーティショニングを介して AWS EC2 の物理 GPU に接続する構成。Source: Adapted from Figure 1.) - **Kueue によるバッチスケジューリング**: LocalQueue(namespace スコープ、ジョブ投入の入口)→ ClusterQueue(cluster スコープ、リソース境界・優先度クラス・admission 制御を宣言的に定義)→ ResourceFlavor(具体的なリソース種別・容量プール)という階層的マッピングで構成される(図 2)。ClusterQueue の admission controller は現在のリソース使用量と設定上限に基づき、ジョブがそのキューに admission 可能かをまず評価する。 **Figure 2: Kueue の動作機構** ![[_attachments/arxiv-2602.04900/fig02-kueue-mechanism.png]] (Figure 2. 複数の LocalQueue が Cohort 内の Cluster Queue に接続され、各 Cluster Queue は Resource Flavor を介して CPU/GPU/spot インスタンスタイプ別の Kubernetes Nodes 群にマッピングされる。破線は borrowing 関係(Cohort 内でのクォータ融通)を示す。Source: Adapted from Figure 2.) - 論文は Kueue の 2 つの構成を比較評価している。(a) 2 つの LocalQueue が単一の ClusterQueue(GPU 8 基)にマッピングされる構成、(b) 2 つの LocalQueue がそれぞれ独立した ClusterQueue(GPU 4 基ずつ)にマッピングされ、Cohort を介して未使用クォータを借用できる構成(図 3)。 **Figure 3: Kueue 構成比較(Whisper 転写実験)** ![[_attachments/arxiv-2602.04900/fig03-kueue-setup-comparison.png]] (Figure 3. (a) 2 LocalQueue + 1 ClusterQueue(GPU 8 基を単一クォータで共有)。(b) 2 LocalQueue + 2 ClusterQueue + GPU borrowing(各 4 GPU クォータを Cohort 経由で相互に融通可能)。いずれも ResourceFlavor: GPU Node (8 GPUs) に admission され、Job Controller に渡る。Source: Adapted from Figure 3.) | Aspect | Kueue | DAS | llm-d and GAIE | |---|---|---|---| | Purpose | Job queuing and batching | GPU/accelerator slicing | Distributed LLM inference | | Resource Mgmt | Workload admission based on quotas | Dynamic GPU slices per pod | Pools of model servers | | Scheduler Link | Uses admission hooks | Enforces slices via scheduler | Routes requests to optimal inference endpoints | | Workloads | Batch/AI jobs needing fairness | GPU-as-a-Service + Data Science | LLM prefill/decode tasks | | Isolation | Fair queuing, priorities | Strong GPU isolation | Through inference pools | | Perf. Focus | Throughput + fairness | GPU utilization, low waste | Efficient parallel inference | | Complexity | Light, native integration | Needs custom device plugins | Requires distributed inference layer | | Extensibility | Generic; policy-extensible | AI-specific; NVIDIA MIG focus | Integrates with Kubernetes Gateway API | (Table 1. Kueue・DAS・llm-d and GAIE の役割比較。) - **DAS(Dynamic Accelerator Slicer)によるアクセラレータスライシング**: NVIDIA MIG を用いて、ワークロード要求に応じて GPU スライスを just-in-time で生成・破棄する OpenShift オペレータ。静的な事前スライシングによるリソース断片化や、ノード初期化時の静的割当がワークロード変化時にサービス中断を招く問題に対処する。DAS は (1) 新規ジョブへの即時スライス提供、(2) ワークロード変化に応じた動的な割当・回収、(3) NVIDIA GPU Operator と連携した正確なデバイス構成の公開、(4) スケジューリングとスライス割当のバインディング(Pod は provisioning 成功後にのみ物理 GPU スライスを受け取る)、の 4 つの課題に対応する。 - **llm-d と GAIE(Gateway API Inference Extension)による分散推論**: llm-d は、通常の Kubernetes Service + Deployment によるステートレスなラウンドロビン負荷分散が LLM 推論(ステートフル・計算コストが不均一・キャッシュ再利用と遅延認識ルーティングの恩恵が大きい)に不向きである問題に対処する。GAIE は標準 Gateway API を拡張し、(i) InferenceGateway(モデル登録・認証・バージョニング・ルーティングポリシーを備えたエントリポイント)と (ii) InferencePool(バックエンドの [[vLLM]] レプリカ群を管理し、llm-d の Endpoint Picker (EPP) として実装される推論スケジューラを統合)という 2 つのコア構成要素を提供する。 **Figure 4: llm-d 構成概要** ![[_attachments/arxiv-2602.04900/fig04-llm-d-setup.png]] (Figure 4. Inference Gateway(Envoy)が状態に基づき最適なレプリカを選択し、Inference Scheduler の KV-Cache Manager から Load / KV Cache Report を受け取って Inference Pool 内の vLLM engine(Qwen3-8B、8 レプリカ)へルーティングする。各 vLLM エンジンは Shared Prefix Cache を共有する。Source: Adapted from Figure 4.) - **KV キャッシュを軸にしたルーティング**: transformer ベース LLM の prefill フェーズは計算コストが高く、KV キャッシュへの結果格納後、decode フェーズはこれを再利用して冗長計算を避ける。分散環境で類似プロンプトがキャッシュ非認識のまま異なるレプリカへルーティングされると、各レプリカが同じプレフィックス状態を再計算し GPU サイクルを浪費する。llm-d は GAIE のプログラム可能なスケジューリング層を通じ、キャッシュ局所性とワークロードテレメトリに基づいてルーティングを最適化する「Precise Prefix-Cache Aware Scheduling(well-lit path)」戦略を実装する。 - **推論エンジン**: バックエンドには [[vLLM]] を用いる。PagedAttention により KV キャッシュのきめ細かい共有を可能にし、動的バッチング・コンテキスト再利用を冗長メモリコピーなしで実現する。 ## 新規性 先行研究(§2.3 Related Work)は、学習向けの学習ベーススケジューラ([[PAX]]、KaiS)、GPU スライシング技術(nvshare、DISC、Jormungandr、KIS-S)、分散推論の個別技術(Alpa、PetS、[[DistServe]]、ServerlessLLM)など、個々のシステムコンポーネントやマイクロベンチマークに焦点を当てたものが大半であった。本論文は、フルスタックかつ最新の AI ワークロードの運用オーバーヘッド・性能・スケーリング挙動をエンドツーエンドで評価する研究が相対的に少ないというギャップに対処し、ASR(Whisper)→ 要約(LLM)という完全なパイプラインを、独立コンポーネントの評価ではなく統合されたユースケースとして評価する点で新規である。また新しいスケジューリングアルゴリズムやモデルアーキテクチャを提案するのではなく、実運用に近い環境での Kubernetes ネイティブコンポーネントのシステムレベル挙動の特性づけに徹している。 ## 実験設定 - **実験環境**: Red Hat OpenShift Service on AWS (ROSA)。コントロールプレーン 3 × `m5.2xlarge`、インフラノード 3 × `r5.xlarge`、GPU ノード 1 × `p4d.24xlarge`(NVIDIA A100 GPU 8 基、us-west2)。OpenShift 4.19.16(Kubernetes 1.32)、NVIDIA GPU Operator v25.3.4。Whisper 転写ジョブは Red Hat UBI 10 ベースのコンテナイメージ。 - **データセット**: Earnings-22 ベンチマーク([[Earnings-22]]、125 件の企業決算説明会コーパス)から 32 件を選定(medium Whisper モデル用 16 件、large Whisper モデル用 16 件)。 | Metric | Count | Mean [s] | SD [s] | Median [s] | Min [s] | Max [s] | |---|---|---|---|---|---|---| | All Jobs | 32 | 3127.38 | 1217.90 | 3287.51 | 1258.34 | 7405.44 | | Large Model Jobs | 16 | 3077.63 | 1584.01 | 3119.85 | 1258.34 | 7405.44 | | Medium Model Jobs | 16 | 3177.13 | 742.37 | 3287.51 | 1682.72 | 4380.08 | (Table 2. 使用した音声データセットの概要。全て転写対象音声ファイルの再生時間の統計。) - **比較対象**: (1) Kueue 実験: Pure Jobs(ベースライン、Kueue 未使用)/ Kueue BestEffortFIFO / + Priority / + Preemption / 2 ClusterQueues + Borrowing の 5 構成。(2) DAS 実験: No MIG vs MIG(限定同時実行 8 ジョブ)、No DAS vs DAS(全 32 ジョブ)。(3) GAIE 実験: ClusterIP(標準 Kubernetes サービス) vs InferenceGateway のみ vs InferenceGateway + InferencePool(推論スケジューラ込み)、および Random Scheduling vs Precise Scheduling のルーティング戦略比較。 - **評価指標**: メイクスパン(全ジョブ完了までの経過時間)、キュー時間・実行時間、admission attempt duration(P50/P95/P99)、ジョブ完了時間(平均・中央値・P95)、GPU/Tensor Core/DRAM/CPU 利用率、Time to First Token (TTFT)、inter-token latency (ITL)、エンドツーエンドリクエスト遅延。 - **ツール**: 負荷生成・分析には [[kube-burner]](Kubernetes/OpenShift 向けの宣言的ワークロードオーケストレーションフレームワーク、jobLatency カスタム計測を含む)を使用。LLM 推論ベンチマークには [[GuideLLM]](OpenAI 互換エンドポイントに対する多重度別リクエスト生成)を使用し、転写文を実際のプロンプトデータセットとして投入。要約対象 LLM には [[Qwen3]]-8B(Qwen/Qwen3-8B、オープンウェイト)を採用し、[[vLLM]] レプリカ 8 基で提供。 ## 実験結果 ### スケジューリング(Kueue) | Configuration | Makespan (Med, Min–Max) [分] | Queue Time (Med / P95) [分] | Exec Time (Med) [分] | |---|---|---|---| | Pure Jobs (Baseline) | 60.5 (59.1–60.5) | 0.0 / 0.0 | 28.4 | | Kueue BestEffortFIFO | 62.5 (62.4–65.8) | 16.7 / 39.5 | 9.4 | | + Priority | 54.7 (52.2–56.1) | 19.5 / 44.5 | 9.5 | | + Preemption | 51.1 (49.2–52.7) | 25.0 / 41.9 | 8.9 | | 2 ClusterQueues + Borrowing | 55.0 (54.2–60.0) | 13.7 / 32.4 | 8.7 | (Table 3 抜粋。96 ジョブ・3 回実行の集計。すべて分単位。) - 純粋な Kubernetes Job(Kueue 未使用)はメイクスパン 60.5 分と、Kueue BestEffortFIFO(62.5 分)より短かったが、これは非決定的な実行順序による偶発的な結果であり、Kueue は決定的で再現可能なスケジューリング順序(medium-4, large-4, medium-5, large-5, ... の順)を保証する。 - 優先度クラス(WorkloadPriorityClass)の付与でメイクスパンは 54.7 分に、さらにプリエンプションを有効化すると 51.1 分(ベースライン比で約 15% 改善)に短縮された。 - 2 ClusterQueue + Borrowing 構成は、medium ClusterQueue の完了後に未使用 GPU を動的に再割当てすることで公平性と利用率のバランスが最も良好だった。 - admission attempt duration は全構成で 99 パーセンタイルでも 25ms 未満であり、Kueue のキューイングロジックはスケジューリング遅延に対して無視できるオーバーヘッドしか課さない(Table 4)。2 LocalQueue + 2 ClusterQueue 構成では cross-queue 同期とリソース借用調整のため P95 ≈ 17ms、P99 ≈ 24ms とわずかに高いテール遅延を示した。 ### アクセラレータスライシング(DAS) | Metric | No MIG | MIG | No DAS | DAS | |---|---|---|---|---| | Concurrent Jobs | 8 | 8 | 8 | 25 | | Mean Job Completion Time [分] | 14 | 17 | 28 | 18 | | Median Job Completion Time [分] | 10 | 13 | 28 | 16 | | P95 Job Completion Time [分] | 36 | 40 | 51 | 36 | | Mean GPU Utilization [%] | 45 | 19 | 44 | 38 | (Table 5・Table 6 抜粋。No MIG/MIG は限定同時実行 8 ジョブ、No DAS/DAS は全 32 ジョブでの結果。) - MIG スライス単体では(同時実行数を固定した場合)ジョブ完了時間がやや悪化する(平均 14→17 分)。これはリソース制約による性能劣化であり、平均 GPU 利用率も 45%→19% に低下した。 - しかし DAS を有効化して並列実行可能ジョブ数を GPU 数(8)からスライス数(25)へ増やすと、待ち時間の削減がスライスあたりの実行時間劣化を上回り、平均ジョブ完了時間は 28→18 分(36% 削減)、中央値は 28→16 分、P95 は 51→36 分に改善した。 - DAS 使用時は平均 Tensor Core 利用率・DRAM アクティビティが約 3 倍、ワーカーノードの平均 CPU 利用率が約 4 倍(10%→37%)に増加した。平均 GPU 利用率のわずかな低下(44%→38%)は、MIG スライス割当パターンによる「スライスパディング」(残余キャパシティが割当不能になり一部の Streaming Multiprocessor がアイドルになる現象)による。 ### 分散推論(llm-d + GAIE) - GAIE コンポーネント単体のオーバーヘッド: vLLM Simulator を用いた検証で、ClusterIP と InferencePool 無効時はほぼ同等の TTFT を示す一方、InferencePool 有効時は同時実行度 6〜20 の範囲で 3ms〜11ms 高い TTFT を示した(図 5)。この追加オーバーヘッドはゲートウェイと endpoint picker のルーティング処理に起因する。 **Figure 5: GAIE 導入オーバーヘッド** ![[_attachments/arxiv-2602.04900/fig05-gaie-overhead-ttft.png]] (Figure 5. ClusterIP・InferencePool: On・InferencePool: Off の 3 シナリオで、同時実行度 5〜20 に対する平均 TTFT(ms)を比較。InferencePool 有効時のみわずかに高い TTFT を示す。エラーバーは 95% 信頼区間。Source: Adapted from Figure 5.) - 実運用相当のワークロード(32 件の転写文、各平均 8,500 トークン、合計 272,000 トークンを 256 リクエストとして GuideLLM から送信、KV キャッシュ容量は GPU あたり 143,360 トークン、8 GPU 合計 1,146,880 トークン)では、プロンプト総量がキャッシュ容量を上回るため Random Scheduling はキャッシュミスと prefill オーバーヘッドを必然的に生む。 **Figure 6: TTFT 比較(Random vs Precise Scheduling)** ![[_attachments/arxiv-2602.04900/fig06-ttft-random-vs-precise.png]] (Figure 6. 同時実行度 5〜20 に対する TTFT(対数スケール)。Random Scheduling の平均 TTFT(約 500ms)は Precise Scheduling(約 80ms)の約 6.25 倍。Random Scheduling の 99 パーセンタイルは Precise Scheduling比で最大 20 倍遅い。エラーバーは 95% 信頼区間。Source: Adapted from Figure 6.) **Figure 7: エンドツーエンド遅延比較** ![[_attachments/arxiv-2602.04900/fig07-e2e-latency-random-vs-precise.png]] (Figure 7. 同時実行度 5〜20 に対するリクエストあたりのエンドツーエンド遅延(秒)。Random Scheduling は平均で Precise Scheduling より約 1 秒遅く、P99 では最大 6 秒遅い。Source: Adapted from Figure 7.) - Takeaways(§4.4)では、GAIE の Precise Scheduling による改善を「99 パーセンタイル TTFT を最大 90% 削減、エンドツーエンド遅延を最大 25% 改善」とまとめている一方、Conclusion(§5)では「TTFT を最大 82% 改善」という別数値も併記している。⚠️ 論文内で TTFT 改善率の表記(90% と 82%)に軽微な不整合がある。abstract は「sixfold(6 倍以上)」と表現しており、これは本文中の「約 6.25 倍」の平均 TTFT 改善に対応する。 ## 考察 - 3 つのコンポーネント(Kueue・DAS・GAIE)はそれぞれ異なるパイプライン段階(キューイング/バッチ管理、GPU スライシング、分散推論ルーティング)を担当し、相補的に機能することで Kubernetes を GenAI 推論の統一基盤として機能させうることを示している。 - Kueue は決定性・公平性・再現性を重視した設計であり、素の Kubernetes スケジューラの「たまたま速い」非決定的順序と比較して、実運用でのキャパシティプランニングや SLA 遵守に資する。 - DAS による MIG スライシングは、個別ジョブレベルではリソース制約による性能劣化を伴うが、並列度の増加による待ち時間削減効果がそれを上回るというトレードオフが明確に示された。 - GAIE の Precise Scheduling は、KV キャッシュのプレフィックス再利用を最大化することで、ランダムルーティング比で大幅な TTFT・エンドツーエンド遅延の改善を達成しており、KV キャッシュを考慮したルーティングの重要性を裏付けている。 ## 強み / 弱点・課題 **Strengths** - 個々のコンポーネント評価にとどまらず、ASR→要約という現実的なマルチステージパイプライン全体をエンドツーエンドで評価した産業論文である点。 - 各コンポーネント(Kueue/DAS/GAIE)について、複数の構成バリエーション(優先度・プリエンプション・borrowing、MIG の有無、ルーティング戦略)を比較する体系的な実験設計。 - 実験設定・マニフェストを GitHub で公開しており再現性が確保されている。 **Weaknesses/Limitations** - モデル精度は評価対象外であり、システム性能のみに焦点を当てている(著者ら自身が明記する限定事項)。 - Kueue と DAS の統合(GPU メモリを拡張リソースとして公開し、Kueue がクォータ・admission 制御を、DAS が MIG スライス割当を担う統合)は執筆時点で開発中であり、本評価では両者は個別に(統合されない形で)評価されている。 - ケーススタディは単一の GPU 世代(NVIDIA A100)・単一クラウド環境(ROSA on AWS)に限定されており、他のアクセラレータ種別やマルチクラウド環境への一般化可能性は未検証。 ## 関連 - 関連システム: [[Kueue]] / [[Red Hat OpenShift]] / [[vLLM]] / [[Qwen3]] - 関連組織: [[Red Hat]] / [[Illinois Institute of Technology]] - 関連概念: [[コンテナオーケストレーション]] / [[GPUクラスタスケジューリング]] / [[KVキャッシュ管理]]