> [!abstract] 概要(arXiv abstract の日本語訳) > Large Language Models(LLM)が大量の同時トラフィックを処理する規模へ拡大するにつれ、推論に必要なインフラの最適化が主要な課題となっている。GPU 資源の高コストを管理しつつ厳格なサービスレベル目標(SLO)を保証するため、事業者はレイテンシに敏感なオンラインリクエストとスループット志向のオフラインリクエストを多重化する異種ハードウェアクラスタにモデルを展開することが増えている。しかし Kubernetes horizontal pod autoscaler(HPA)のような従来の資源中心オートスケーラは、アプリケーション固有の SLO、ハードウェアの異種性、あるいは(KV キャッシュ利用率のような)エンジン内部状態をグローバルに考慮しない。これは不要なスケーリング、深刻な資源未活用、ステートフルな推論の破壊を招く。この限界に対処するため、我々は Workload Variant Autoscaler(WVA)を導入する。WVA は llmd と共同設計された専用の制御プレーンであり、スケーリング判断を推論サーバーの内部飽和状態と密結合させる。事前的な headroom ベースのスケーリングと fragmentation を意識したスケールダウンを利用することで、我々の実験は WVA が HPA 比で有効スループットを 37% 改善し、リクエスト失敗数を 10 分の 1 に削減することを示す。さらに、WVA のコスト意識ティアリングは、高性能アクセラレータへの均質なスケーリングよりも低コストでエネルギー効率の高いハードウェアバリアントを優先することで、本質的に全体の消費電力を削減する。 ## 論文情報 - タイトル: WVA: A Global Optimization Control Plane for llmd - 著者: Abhishek Malvankar・Lionel Villard・Mohammed Abdi・Tommaso Sgreccia・Evgeny Shindin・Braulio Dumba・Vishakha Ramani・Asser Tantawi・Tamar Eilam - 所属: [[IBM Research]](大半の著者)、[[University of Bologna]](Tommaso Sgreccia) - 媒体: arXiv プレプリント(v2) - 発表年: 2026 年 3 月 20 日(v2) - arXiv ID: 2603.09730 - コード: https://github.com/llm-d/llm-d-workload-variant-autoscaler ## 概要 本論文は、[[llm-d]](Kubernetes ネイティブな分散 LLM 推論フレームワーク)と共同設計されたオートスケーラ Workload Variant Autoscaler(WVA)を提案する。WVA は Variant という第一級抽象(ハードウェア・並列度・量子化のタプル)を導入し、KV キャッシュ利用率・キュー長といった推論エンジン内部の飽和シグナルに基づく headroom ベースのグローバル最適化によって、Kubernetes HPA が持つ資源中心・ハードウェア均質前提の限界を克服する。シミュレーションと実機 200-H100 クラスタでの評価により、有効スループット改善・リクエスト失敗削減・コスト/エネルギー効率改善を実証した。 ## 問題設定 LLM 推論はステートレスなマイクロサービスと本質的に異なり、Prefill(計算バウンド、初期 KV キャッシュを計算)と Decode(メモリ帯域バウンド、KV キャッシュに依存してトークンを逐次生成)の 2 フェーズから成るステートフルなプロセスである。KV キャッシュは大量の GPU メモリを消費し、メモリ容量が主要なボトルネックとなる。入力プロンプト長・出力トークン数によって処理時間が大きく変動するうえ、設備投資の巨大さから、旧世代の安価な GPU(A100 等)と新世代の高性能・高価な GPU(H100 等)が混在する異種クラスタが一般化している。 Kubernetes HPA のような従来の資源中心オートスケーラは、CPU・メモリ利用率の平均値を目標とする汎用制御であり、次の 3 点で不十分である:(1) アプリケーション固有の SLO を考慮しない、(2) ハードウェアの異種性を考慮せず全 Pod を交換可能な均質資源として扱う、(3) KV キャッシュフラグメンテーションやキュー長のようなエンジン内部の輻輳シグナルを捕捉できない。さらに HPA の平均値ベースのスケールダウンロジックは、クラスタ全体平均が低くても特定ノードで KV キャッシュが飽和している場合(fragmented usage)にレプリカを終了させてしまい、ステートフル推論を深刻に破壊する。 論文はこれらの課題を解く枠組みとして、コアの Kubernetes HPA そのものへ LLM 固有ロジックを組み込む選択肢を明示的に退ける。HPA はステートレスで交換可能な Pod 向けの汎用・最小公分母コントローラとして意図的に設計されており、KV キャッシュのフェーズ認識・Prefill/Decode 別スケーリング要件・異種ハードウェアティアリングをコア制御プレーンへ埋め込むことは後方互換性を壊しオーケストレータを肥大化させるとし、CNCF の新興イニシアチブ([5])を引き合いに、モノリシックな HPA 改変ではなく特化した分離データプレーン拡張が必要だと主張する。WVA は HPA を fork した代替ではなく、HPA を「アクチュエータ」として利用しつつその上に重ねる拡張可能な推論認識型制御プレーンとして設計される。 ## 提案手法 ### Variant 抽象 WVA の中核は Variant という第一級抽象である。単一のベースモデル(例: `Llama3-70b`)は複数の推論サーバー構成でデプロイされうる。論文は Variant を以下のタプルとして定義する。 $Variant = \langle Hardware, Parallelism, Quantization \rangle$ 本実装では Variant 空間を Hardware(GPU モデル)と Parallelism(レプリカあたりの GPU 数)の 2 次元に限定する。例えば `Variant A` は `(H100, 2 GPUs)`、`Variant B` は `(A100, 4 GPUs)` である。この抽象は `VariantAutoscaling`(VA)制御プレーンリソースとして操作化され、サービス全体を均質な Pod のプールとして扱う代わりに、各 Variant のコスト・性能トレードオフを独立に評価できるようにする。 ### 飽和モデル(既定戦略) WVA は `queue_length` と `kv_cache_usage` という粒度の細かいメトリクスを消費し、CPU 利用率のような汎用資源メトリクスとは異なりアプリケーションレベルの輻輳を直接測定する。全アクティブレプリカ集合を $R$ とし、測定可能な資源メトリクス $m \in \{kv, q\}$(KV キャッシュ利用率とキュー長)それぞれについて、オフラインプロファイリングで導出される「ハード飽和閾値」$\tau_m$ を定義する。飽和レプリカの部分集合 $S \subseteq R$ は次のとおり定義される。 $S = \{r \in R \mid U_{kv}(r) \geq \tau_{kv} \lor U_q(r) \geq \tau_q\}$ ここで $U_{kv}(r)$・$U_q(r)$ はレプリカ $r$ の瞬時 KV キャッシュ利用率とキュー長である。非飽和集合 $R \setminus S$ 上の平均余裕容量 $\delta_{avg}$ を計算し、この安全マージンが設定トリガ $\gamma$ を下回るとスケールアップイベントが発火する。 $\exists m \in \{kv, q\}: \frac{1}{|R \setminus S|}\sum_{r \notin S}(\tau_m - U_m(r)) < \gamma_m$ 逆に、レプリカを1つ除去した後も予測余裕容量が $\gamma$ を上回る場合にのみスケールダウンが許可される。llmd は Prefill(計算バウンド)ノードと Decode(メモリバウンド)ノードを区別し、WVA の `AutoscalingPolicy` はこの役割に応じて異なるスケーリングの積極度プロファイルを適用する(Role Awareness)。 ### グローバル最適化フレームワーク WVA の Control Plane Framework は、ローカル・Pod 中心のオートスケーラでは達成できないグローバル最適化戦略を可能にする。 **Headroom ベースの容量管理**: Headroom $\delta$ を、クラスタ内で新規リクエストを即座に処理できる余裕容量の総量として定義する。目標容量 $Capacity_{target}$ は、現在の負荷 $Load_{current}$ に安全バッファ $\delta_{safety}$ を加えた値として形式化される。 $Capacity_{target} = Load_{current} + \delta_{safety}$ 上式(トリガ条件)と headroom の目標式は、2 段階の反応的・事前的制御ループを構成する。トリガ条件が破られると、システムはアクチュエーション段階へ遷移し、目標割当を計算してグローバルに安全マージン $\delta_{safety}$ を回復する。この分離された定式化により、WVA は llmd 内のスケジューラ(EPP)のルーティングヒューリスティクスをミラーでき、スケーリング判断がリクエスト受け入れとフェーズ整合することで制御ループの発振を緩和する。 **フラグメンテーションを意識した安全性**: 異種分散システムでは負荷は一様に分布しない。純粋な反応的スケーラは distributional masking に陥りやすく、クラスタ全体平均利用率が低いとレプリカを終了してしまうが、ステートフル推論では特定 Pod が(llmd スケジューラのスコアラーに基づく)フラグメント化された使用状態のまま飽和している場合がある。WVA のグローバルオプティマイザは全レプリカの飽和シグナルを集約し、特定 Variant が確実にアイドルだと識別できる場合にのみスケールダウンを許可する。カスケード的な飽和のリスクをさらに緩和するため、オプティマイザは非飽和レプリカの下限(`MinNonSaturatedReplicasForScaleDown`、既定 2)を強制し、スケールダウン前にこの数を維持することをデータ損失・長時間実行リクエストの中断に対する決定論的な安全機構とする。 ### End-to-End ワークフロー リクエストは Gateway → llmd スケジューラ(最も非飽和な Pod を選択)→ 推論サーバー Pod という経路をたどる。WVA は以下のステップで最適容量を維持する(Figure 1 参照)。 1. **Metric Ingestion**: 最適化サイクル(Model Analyzer と Global Optimizer)が Collector 経由で推論サーバーから高精度な統計(KV キャッシュ利用率、キュー長)を消費する。 2. **Optimization Loop**: エンジンが Model Analyzer を使い、任意でグローバル最適化(Constrained Mode)を伴いながら Variant 間(例: A100 vs H100)の最適なレプリカ分配を計算する。 3. **Decision Caching**: 目標状態がインメモリの `DecisionCache` に書き込まれる。 4. **Reconciliation**: 決定エンジンまたは VA CRD の更新にトリガされた `Reconciler` がキャッシュを読み、`VariantAutoscaling` の Status に最適化済みの割当をパッチする。 5. **Actuation**: コントローラが scale subresource を持つ基盤の Kubernetes オブジェクトを、HPA 経由で目標レプリカ数へ更新する。 **Figure 1: WVA と llmd の統合構成** ![[_attachments/arxiv-2603.09730/fig01-wva-architecture.png]] (Figure 1. llmd 上のトラフィックフロー(Gateway → llmd scheduler → Inference Pods → Metrics Endpoint)と、HA モードで動く WVA の内部構成(Ingestion → Collector → Model Analyzer → Global Optimizer → Decision Cache/Reconciler → HPA → 複数の scale subresource)を示す構成図。Source: 論文 Figure 1.) ### アーキテクチャ WVA は 4 つの主要コンポーネントから成る。 - **Reconciler**: Variant の処理と状態更新(scale-to-zero ライフサイクル管理を含む)を担当する。 - **ScaleFromZero**: 標準 Reconciler ループより高頻度で動作する専用スレッド。MaaS(Model-as-a-Service)要件であるレイテンシに敏感なコールドスタートに対応し、初期トラフィックへの即応性を確保してリクエストドロップを防ぐ。 - **Collectors**: 異なる Collector 実装の登録を許すモジュラーフレームワーク。Prometheus・ローカルメトリクスエンドポイントなど多様なバックエンドからメトリクスを取り込める。 - **Decision Cache**: 最適化判断のための高性能インメモリ状態ストア。最適化ロジックを Kubernetes API サーバーから分離し、システム安定性を保ちながら必要なときだけ更新を反映する。 - **Optimizers**: プラグイン可能な戦略を実行する複合エンジン。参照実装では Model Analyzer と Global Optimizer から成る飽和ベースオプティマイザを配備し、コストとエネルギー効率のためにワークロードスケーリングを最適化する。 WVA は viper による階層的設定管理を採用し、GitOps・Helm 等の標準的な Kubernetes 運用ワークフローとシームレスに統合できるよう設計されている。 **設計思想(なぜプラガブルにするか)**: 論文は3つの理由を挙げる。(1) **推論エンジンの急速な進化**: vLLM や SGLang は継続的に変化し、chunked prefill や speculative decoding のような新機能がボトルネックを変えるため、固定的なキュー長ロジックのスケーラはエンジンのアップグレードごとに陳腐化する。(2) **相反するワークロード目的**: オンライン推論はレイテンシ SLO 順守(飽和前のスケールアップ)を要求する一方、オフラインバッチはコスト効率(キューを詰めてスループット最大化)を優先し、正反対のスケーリング目的を持つ。`AutoscalingPolicy` インターフェースはデプロイごとに異なる最適化アルゴリズムを差し替え可能にする。(3) **ハードウェアの多様性**: 飽和の定義はハードウェアによって異なる(A100 上のメモリバウンドモデルは KV キャッシュベースのスケーリングを要するが、H100 上の同モデルはテンソル並列オーバーヘッドに制約されうる)。プラガブルな Optimizer はコア再調整ループを変更せずにハードウェア固有ヒューリスティクスを注入できる。 **プラガブルインターフェース**: `AutoscalingPolicy`(スケーリング判断を計算)と `ActuationStrategy`(HPA や API など異なるアクチュエーション機構をサポート)という 2 つの Go インターフェースを定義し、コアコードベースを fork せずにカスタムスケーリングアルゴリズムやメトリクスバックエンドを注入できるようにする。この関心の分離は Mesos [7] のような拡張可能システムの設計を反映する。 **モジュラーなメトリクス収集**: V2 Collector API により `MetricsSource` インターフェースと動的な Registry を通じてメトリクス取得を抽象化し、Prometheus や直接プッシュ API 等の多様なバックエンドから、コアエンジンを変更せずにメトリクスを取り込める。Registry パターンは `FileSource`(シミュレーション用)のようなモックプロバイダによるテストも容易にする。 **プラガブルなリソースディスカバリ**: `CapacityDiscovery` インターフェースにより GPU インベントリの発見層も分離され、既定実装 `K8sWithGpuOperator` は Kubernetes ノードの GPU Operator ラベルを問い合わせるが、静的なインベントリファイルやカスタム GPU 管理システムを用いる非 Kubernetes 環境もサポートできる。 **Model Analyzer**: ローカルな飽和検知のコアロジックを担う。(1) 全 Pod から推論エンジン固有メトリクスエンドポイントをフィルタしてメトリクスを集約、(2) キュー長・KV キャッシュ利用率が閾値を超えるとスケールアップ要求を識別、(3) メトリクスパイプライン障害時に scale-to-zero を防ぐための safety net ターゲットを計算する。 **Global Optimizer**: ブート時の環境変数で設定可能な 2 モードで動作する。**Unconstrained Mode(既定)**は最適化問題を分離可能として扱い、各デプロイメントについて下位層の容量が無限であると仮定して独立に最適配分を解く。クラウドネイティブなオートスケーリングノードプールを前提とし、SLO 順守とコスト効率のみを最適化する。**Constrained Mode**はグローバルなクラスタ資源制約(例: 固定 64-GPU クラスタ)を尊重する主要運用モードであり、複数 Variant が同時にトラフィックパターンに基づく最適資源を要求する中、要求合計がクラスタ容量を超える場合には Global Optimizer が調停者として Greedy-by-Saturation ソルバーを用いて希少資源を割り当てる。アルゴリズムはスケールアップを要求する Variant をフィルタし、残余余裕容量($\delta$)の昇順で並べ替え(物理的飽和・SLO 違反に最も近いデプロイメントを優先救済)、次いで `variantCost` の昇順を二次的なタイブレーカとする。GPU は有限のクラスタ予算が尽きるまでこの優先度付きキューへ反復的に割り当てられ、SLO 安全性とエネルギー効率を本質的に最大化する。 **Readiness Gates & Target Resolution**: スラッシング(不完全なデータによる急速なスケールアップ/ダウンの繰り返し)を避けるため、WVA は厳格な readiness gate を実装する。`TargetResolved` Condition は対象 Deployment の存在をアクチュエーション前に検証し、存在しなければ `TargetNotFound` 状態へ入りアクチュエーションを一時停止する。`MetricsAvailable` Gate は Reconciler が `DecisionCache` 内の `MetricsAvailable` シグナルを検証し、メトリクスバックエンドへ到達できない場合はレプリカ数を変更せず最後に確認された正常状態を保持する。これはネットワーク分断時の推論ワークロード安定性に重要である。 **Reconciler**: 基本的な Kubernetes 制御ループプリミティブとして周期的に実行され、クラスタの実状態を望ましい設定へ整合させる。軽量に設計されており、最適化イベント用の Go チャンネル `DecisionTrigger` を監視し、`VariantAutoscaling` と Deployment のイベントをイベントフィルタ経由で追跡する(対象の作成・削除・マルチコントローラ分離のハンドリング)。イベントを受け取ると `DecisionCache` を確認し `VariantAutoscaling` の Status を計算済みの `DesiredOptimizedAlloc` で更新する。エフェメラルなメトリクスデータを CRD Status へ書き込むことは意図的に避けており、これにより毎回のメトリクスポーリングで Status を更新する標準 HPA [8] と比較して API サーバー負荷(etcd 書き込み)を大幅に削減する。WVA は複雑なロジックに基づき望ましい状態を計算する分析コンポーネントとしての役割を担い、実際のアクチュエーションは HPA 制御プレーンに委ねる。 ### 設定インターフェース 利用者は `VariantAutoscaling`(VA)カスタムリソースを宣言することで、特定ワークロード向けの最適化をインスタンス化する。各 VA リソースは論理モデルバリアントと物理 Kubernetes ターゲットを紐付ける。主要な仕様フィールドは、モデル識別子(`modelID`。複数 VA リソースを単一プールへグループ化)、Variant コスト(`variantCost`、既定 "10.0"。ソルバーは低コストの Variant を先に飽和させる)、スケールターゲット(`scaleTargetRef` で参照される対象 Deployment)である。飽和閾値(キュー長上限など)は設定マップで一元管理され、個々の Variant リソースを再デプロイせずに感度を調整できる。 ## 新規性 既存の Kubernetes HPA・KEDA・Knative Pod Autoscaler(KPA)はいずれも汎用的な資源・イベント・並行数メトリクスに基づく反応的スケーリングを行い、LLM 固有のステートフル性(KV キャッシュ)やハードウェア異種性を扱えない。WVA の新規性は次の点にある。 - **Variant というファーストクラス抽象**: ハードウェア・並列度・量子化を単一のタプルとして扱うことで、単一モデルの複数デプロイ構成を横断したコスト・性能トレードオフの評価をネイティブに表現する Kubernetes 抽象を導入する。 - **エンジン内部飽和状態との密結合(Deep Vertical Integration)**: 汎用資源メトリクスではなく KV キャッシュ利用率・キュー長という飽和シグナルに基づき、平均値目標への反応ではなく物理的な余裕容量(headroom)を事前に計算してスケーリングする。 - **数学的に純粋な制約充足問題としての定式化**: Chiron [18] の階層的バックプレッシャーとは異なり、WVA はスケーリングを $Capacity_{target} = Load_{current} + \delta_{safety}$ という制約充足問題として定式化し、コアスケジューリングループを変更しない。 - **クラスタ指向のハードウェアティアリング**: HeteroScale [19]・ModServe [20] のようなエンジン改変による micro-level 最適化とは異なり、WVA はクラスタオーケストレーション層からコスト・電力効率を優先する Variant 単位のティアリングを実現する。 ## 実験設定 評価は決定論的シミュレーションと物理クラスタ検証の二段構成である。 **シミュレーション環境**: KinD [10] 上で llmd フレームワークと WVA を並行稼働させ、`llm-d-inference-sim` [9] で本番相当のメトリクス発行パターン・キュー挙動を再現。`Qwen/Qwen3-0.6B` モデルを用い、`guidellm` [11] を商用グレードの負荷生成器として使用。全実験を 600 秒(10 分)実行し定常状態の安定性を観測。クラスタは 3 ワーカーノード(A100/H100 混在を模擬)。トークン長は境界正規分布に従う: 入力トークン(min=10, max=8192, 平均=4096, 標準偏差=2048)、出力トークン(min=10, max=2048, 平均=1024, 標準偏差=512)。オートスケーリングパラメータは WVA(KV キャッシュ閾値 $\tau_{kv}=0.8$、キュー長閾値 $\tau_q=5$、KV 余裕トリガ $\gamma_{kv}=0.3$)、HPA(目標平均キュー深度=3、目標平均 KV 利用率=0.5)、llmd スケジューラ(EPP、既定重みの queue-scorer=1・kv-cache-utilization-scorer=1・prefix-cache-scorer=1)。推論エンジンは物理的な KV キャッシュ制約(`--enable-kvcache`, `--kv-cache-size=1024`, `--block-size=16`)で構成し合計 16,384 トークンとした。`llama3-70b` という単一の論理モデル識別子を共有する 2 つの `VariantAutoscaling` リソース(`va-a100`: コスト 1.0、`va-h100`: コスト 2.5)を設定し、安価な `va-a100` が飽和するまで優先されるよう構成した。 **物理クラスタ検証**: 200 基の NVIDIA H100 GPU を持つ大規模均質 OpenShift クラスタ上で、10 ノードのサブプールを用い `Qwen/Qwen3-0.6B`(`--max-num-seqs=16000`)を配備。`llm-d-benchmark` [14] スイート経由で `guidellm` を実行し WVA と HPA を比較。EPP の `EndpointPickerConfig` はこのハードウェア向けに調整(queue-scorer 重み 2、kv-cache-utilization-scorer 重み 2、prefix-cache-scorer 重み 3)。llm-d well-lit path 構成 [15] を、[2, 3, 5, 6] req/s の段階的トラフィックパターンで検証した。 ## 実験結果 ### Experiment 1: Saturation Reactivity(シミュレーション) staircase 型の合成トラフィック(基準 ∼2 RPS → step 9 で ∼5 RPS → step 14 で ∼10 RPS)を注入し、WVA の応答を観測した。平均リクエストフットプリント ∼5,120 トークン(平均入力 4,096+平均出力 1,024)から、シミュレートされた推論サーバーは物理的に最大 3 並行リクエスト(3×5,120=15,360 トークン、93% 利用率)しか処理できず、`--max-num-seqs=256` の既定値がこの物理ボトルネックをマスクしないよう保証したうえで、WVA の 80% KV キャッシュ閾値($\tau_{kv}=0.8$)が 3 番目の並行リクエストで確実に破られるよう設計した。WVA が headroom 喪失に応じて新規レプリカを準備すると、llmd スケジューラ(EPP)が即座に新規容量へトラフィックをルーティングし、平均 KV キャッシュ利用率が安全水準へ低下した。 **Figure 2: Saturation Reactivity 実験結果** ![[_attachments/arxiv-2603.09730/fig02-saturation-reactivity.png]] (Figure 2. WVA のレプリカ数(主軸、赤の実線)・受信トラフィック(副軸、青の破線)・平均 KV キャッシュ利用率(第三軸、緑の実線)の時系列。トラフィックが突発的に立ち上がると、WVA のレプリカ数がほぼ同期してステップ状に増加し、KV キャッシュ利用率のピークを抑制する様子を示す。Source: 論文 Figure 2.) ### Experiment 2: Cost-Aware Scaling(シミュレーション) A100(コスト=1.0)と H100(コスト=2.5)の 2 Variant を配備し、ランプアップ負荷下でレプリカ数を観測した。結果は A100 レプリカが先にスケールアップし、A100 容量が飽和するか到着率が A100 プールの吸収能力を超えた場合にのみ H100 レプリカがスケールアップすることを示した。H100 は完全飽和時によりすぐれた性能あたり電力を提供するが、A100 は絶対的な熱設計電力(TDP)フットプリントが大幅に低い(A100 最大 400W 対 H100 SXM 700W [13])。基準トラフィックに A100 を優先することで、WVA は強力なアクセラレータをアイドル・部分負荷状態で稼働させ続けることに伴う電力ペナルティを回避し、無駄な均質スケーリングを防止する。 **Figure 3: Cost-Aware Scaling 実験結果** ![[_attachments/arxiv-2603.09730/fig03-cost-aware-scaling.png]] (Figure 3. A100(青)と H100(オレンジ)のレプリカ数のサンプリングステップ推移。A100 はステップ約6から約11にかけて先に飽和(3.3 レプリカ相当)し、H100 はステップ約20以降、A100 容量が尽きた後に立ち上がる。Source: 論文 Figure 3.) ### Physical Cluster Validation(実機 OpenShift、H100×200) **Throughput Stability**: HPA は平均利用率目標という基盤ロジックゆえに、急激な負荷ステップをタイムリーに追跡できず、不可避なキューイング遅延と早期のスロットリングによりスループットが劣化する。対照的に WVA の headroom ベースのスケーリングは必要容量を事前計算し、余裕容量バッファ($\delta$)を段階的な負荷増に合わせて維持することで、5 RPS でピーク 37% のスループット改善を達成した(Figure 4)。 **Figure 4: Throughput Stability 実験結果** ![[_attachments/arxiv-2603.09730/fig04-throughput-stability.png]] (Figure 4. リクエストレート [2, 3, 5, 6] req/s に対するスループット(req/s)の棒グラフ。WVA(赤)は 2.0/2.9/5.4/5.8、HPA(オレンジ)は 1.7/2.9/3.9/5.4 で、5 RPS でギャップが最大化する。Source: 論文 Figure 4.) **Request Stability**: Figure 5 はシステムの頑健性を示す。HPA は中程度の負荷(2〜5 RPS)でも(1) 平均利用率を目標とし常に容量近傍で運用するため、急激な負荷ステップが llmd の admission control をトリガして HTTP 429/503 でリクエストを拒否する Saturation Rejection と、(2) シグナルノイズが処理中の Pod を終了させてしまう Scale-Down Instability という 2 要因から失敗のベースラインを示す。一方 WVA の事前的余裕容量バッファはこれらの段階的増加を吸収し、飽和ベースの拒否を防止する。さらに WVA の Fragmentation-Aware Scale Down は、Pod が確実に drain されるまで終了させないため、5 RPS でのドロップを 1.5/s 未満に抑えつつ(HPA は 15/s 超まで急増)準飽和負荷での失敗を排除する。 **Figure 5: Request Stability 実験結果** ![[_attachments/arxiv-2603.09730/fig05-request-stability.png]] (Figure 5. リクエストレート [2, 3, 5, 6] req/s に対する失敗数。WVA(赤)は 0.0/0.5/1.4/20.0、HPA(オレンジ)は 3.7/2.1/15.3/18.8。5 RPS で WVA が HPA の約 11 分の 1 の失敗数となる一方、6 RPS(最大デプロイ上限 10 レプリカに到達)では WVA の失敗数が HPA を上回る逆転が生じる。Source: 論文 Figure 5.) **Efficiency & Replica Count**: WVA は中程度の負荷水準では HPA より低いレプリカ数を維持する。しかし 5〜6 RPS 間で重要な乖離が生じる: WVA は上限(10 レプリカ)まで積極的にスケールする一方、HPA は約 9.3 レプリカにとどまる。この過剰スケーリングは WVA の headroom ベーススケーリングの意図的な帰結である。llmd スケジューラは飽和シグナル(KV キャッシュ充満度等)に基づきリクエスト受け入れを制限するため、HPA は平均利用率を目標とすることで暗黙的にシステムを飽和状態に保ち、llmd に過剰負荷を拒否させる(スループットは低下するが)。対照的に WVA は余裕容量 $\delta$ を確保し、システムをわずかに未飽和のまま維持することで llmd がフル負荷バースト(5.78 req/s 対 5.45 req/s)を受け入れられるようにする。6 RPS は最大許容レプリカ数(10)の物理容量をワークロードが超える臨界飽和点にあたり、HPA は早期にアクセス受け入れを絞る(結果としてスループットは低いが最大ユニット数を要求しないことが多い)一方、WVA の headroom ベーススケーリングは 10 レプリカ超が安全バッファ維持に必要だと正しく計算し、オーケストレータが 10 に上限を設定しているため上限まで確実にスケールしサービスを最大化する。ハードウェアの物理限界に近い状態で処理することで WVA は著しく高いスループットを達成するが、末端の失敗がわずかに増加する。これは物理制約が理想的な headroom 供給を妨げる場合でも WVA が有用なサービス(Goodput)を最大化する設計哲学を示す。 ### Latency Distribution Figure 6 は、中程度の非制約負荷下で WVA のスケーリング戦略が SLO(Time To First Token: TTFT、Inter-Token Latency: ITL)を保護することを裏付ける。WVA(赤)は 5 RPS まで平均 TTFT・平均 ITL とも安定して SLO 境界内にとどまる。$\delta$ 安全バッファを事前的に確保することで、着信リクエストは即座に計算資源へ割り当てられ、反応的システムで平均 TTFT スパイクを支配するキューイング遅延を実質的に排除する。6 RPS ではわずかな平均レイテンシの上昇と SLO 違反リスクの増加が観測されるが、これは WVA の headroom ベーススケーリングが 10 レプリカのハード上限に制約される結果として予期される trade-off である。WVA が余裕容量を確保できなくなると、既存レプリカが $\delta$ バッファなしで超過トラフィックを吸収せざるを得ず計算資源の競合が高まる一方、HPA 構成では系がより低いレプリカ数(≈9.3)で安定し llmd の内部飽和閾値を頻繁にトリガして過剰リクエストを拒否する(スロットリング)。高い拒否率は受理されたリクエストの並行負荷を減らすことで見かけ上平均レイテンシを低く見せるが、WVA は資源競合の増加を代償に受け入れを最大化する。 **Figure 6: Mean Latency Distribution(TTFT・ITL)** ![[_attachments/arxiv-2603.09730/fig06-latency-distribution.png]] (Figure 6. 上段が TTFT(ms)、下段が ITL(ms)のリクエストレート別棒グラフ。TTFT は WVA が 0.0/0.8/1.8/100.0(ms)、HPA が 14.6/10.2/88.4/94.1(ms)。ITL は WVA が 0.0/23.7/26.5/100.0(ms)、HPA が 21.9/32.3/86.2/93.2(ms)。2〜5 RPS では WVA が HPA より低いか同等のレイテンシを保つが、6 RPS では上限到達により WVA のレイテンシが急増し逆転する。Source: 論文 Figure 6.) ## 考察 実機検証の結果は、深いアプリケーション内省(キュー長・KV キャッシュ利用率)を活用することで、WVA が静的ベースラインや汎用オートスケーラに対しレイテンシとコストのトレードオフを動的にナビゲートしながら顕著な効率向上を達成できることを裏付ける。ただし 6 RPS(デプロイ上限到達点)ではスループット・失敗数・レイテンシのすべてで WVA が HPA に劣後する逆転が生じており、これは headroom ベース戦略が「レプリカ数上限という外部制約」に直面した際の構造的な弱点を示す——WVA は上限まで積極的に受け入れを増やす設計であるため、上限到達後は安全バッファを持たない状態でリクエストを詰め込み続け、保守的な HPA よりも局所的に悪化する場合がある。 ## 強み / 弱点・課題 **強み**: - KV キャッシュ利用率・キュー長という推論エンジン内部の一次シグナルに基づく headroom ベースの事前的スケーリングにより、反応的スケーラが構造的に抱える「SLO 違反後に対応する」という遅延を回避する。 - Variant 抽象と Constrained Mode の Greedy-by-Saturation ソルバーにより、コスト・エネルギー効率を意識したハードウェアティアリングをオートスケーラのコアロジックとしてネイティブに扱える。 - プラガブルな `AutoscalingPolicy`・`ActuationStrategy`・`MetricsSource`・`CapacityDiscovery` インターフェースにより、vLLM/SGLang のような推論エンジンの急速な進化に対して、コア再調整ループを変更せず追従できる設計になっている。 - HPA をアクチュエータとして再利用しつつ意思決定ロジックのみを上位に重ねる設計により、既存の GitOps/Helm 運用資産・Kubernetes エコシステムとの互換性を保つ。 **弱点・課題(論文が明示する限界)**: - WVA は依然として反応の遅延に制約される。スケーリングはキューが積み上がり始めるか KV キャッシュ閾値を超えてから初めてトリガされるため、バースト性の高いワークロードでは一時的なレイテンシスパイクが依然発生しうる。著者らは LSTM やトランスフォーマーベースの時系列予測モデルを用いたトラフィック形状予測を将来課題として挙げている。 - エネルギー・カーボン強度シグナルを取り込んだエネルギー意識最適化は未実装であり、将来拡張として位置づけられている。 - Prefill/Decode フェーズ別の独立スケーリングは未対応であり、llmd スケジューラ(EPP)の新興フローコントロール機能との統合も今後の課題とされる。 - デプロイの最大レプリカ数という外部制約に達すると(実機検証の 6 RPS 地点)、WVA の積極的な headroom ベーススケーリングが安全バッファなしでの過負荷運用に陥り、スループット・失敗数・レイテンシのすべてで保守的な HPA に劣後する逆転が観測されている(論文自身が V.D 節・V.E 節で明示的に報告)。 ## 関連研究(論文 §VI の要約) - **イベント駆動オートスケーリング**: KEDA [16] はメッセージキュー等のイベントソースに基づくスケーリングで HPA を拡張しキュー深度に反応できるが、依然として Pod 中心であり `ScaledObject` を個別にスケールするためグローバル最適化コンテキストを欠く。コスト制約に基づき安価な Variant を優先するような判断はできない。 - **サーバーレス・リクエストベーススケーリング**: Knative Pod Autoscaler(KPA)[17] は同時実行数ベースのスケーリングを行うが、単一の LLM リクエストが長時間 KV キャッシュを保持しうるため、汎用リクエスト同時実行数よりも WVA のエンジン内部状態直接監視の方が高忠実度のシグナルを提供する。 - **LLM 中心のスケジューリング・スケーリング**: Orca [2] は可変長シーケンスを扱う iteration-level scheduling を先駆けた。Chiron [18] はバックプレッシャーシグナル(キューサイズ・SLO 順守)による階層的オートスケーリングを導入する。HeteroScale [19] は分散 Prefill-Decode アーキテクチャの異種ハードウェアプール間スケーリング調整を扱う。ModServe [20] はマルチモーダルモデル向けにモダリティ意識のスケジューリング・スケーリングへ分離概念を拡張する。これらがエンジン改変による micro-level 最適化に優れる一方、WVA はクラスタオーケストレーション層から Variant というネイティブ抽象を導入し、コアスケジューリングループを変更せずクラスタ意識のハードウェアティアリングを実現する点で異なる。 ## Future Work(論文 §VII) 著者らは (1) LSTM・トランスフォーマーベースの時系列予測によるトラフィック形状予測を用いた事前的スケーリングの高度化、(2) リアルタイム消費電力・カーボン強度シグナルを取り込むエネルギー意識最適化、(3) Prefill/Decode フェーズ別の独立スケーリングと llmd スケジューラ(EPP)の新興フローコントロール機能との統合、を今後の課題として挙げている。 ## Conclusion(論文 §VIII の要約) WVA は Variant という概念を導入し AI 推論をスケールで最適化する制御プレーンである。Variant を動的にオーケストレーションし事前的な安全 headroom を維持することで、反応的システムに典型的なキューイング劣化を回避し、より高い有効スループットとテールレイテンシ SLO の保護を両立する。著者らは、WVA 自体は llmd 向けに実装されているものの、オートスケーラと推論エンジンが「飽和という共通言語」を共有する Deep Vertical Integration というパターンは、将来のあらゆる AI サービングシステムに一般化可能な教訓であると位置づけ、持続可能な AI インフラの基盤として WVA を提示している。プロジェクトは https://github.com/llm-d/llm-d-workload-variant-autoscaler でオープンソース開発が継続中である。