# LLMサービング管理 ## 定義 LLM サービング管理(LLM serving management / LMaaS management)とは、Language-Model-as-a-Service(LMaaS)プラットフォームにおいて、(1) 複数 LLM インスタンスのリソース割当(オートスケーリング)と、(2) 受信リクエストの最適な振り向け先インスタンス決定(ロードバランシング/リクエストルーティング)を通じて、SLO(TTFT・TBT・正規化 E2E レイテンシ)を満たしながらリソース利用を最適化する管理層のことをいう。 LLM サービングシステムは、リクエストルーターと複数の LLM インスタンス(各インスタンスは完全モデルレプリカを vLLM 等の推論エンジンで実行)から構成される。インスタンスは Prefill フェーズ(計算バウンド)と Decode フェーズ(メモリバウンド)の二段階自己回帰生成を行い、KV キャッシュがメモリのボトルネックとなる([[LLM推論]])。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) ## 横断的知見 - **LLM のコールドスタート時間が反応的オートスケーリングを無効化する**: DeepSeek-R1(6,710 億パラメータ)では LLM インスタンスのコールドスタートに数十〜数百秒を要する。これは従来のマイクロサービス(ミリ秒オーダー)とは桁違いであり、「CPU 利用率 80% 超でスケールアップ」という反応的スケーリングが LMaaS では本質的に機能しない根拠となる。PreServe はこの制約に対し mLSTM による 10 分先読みワークロード予測で先行起動する解法を示した。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) - **LLM リクエスト間の負荷不均一性が均一想定ルーティングを無効化する**: ラウンドロビン・最少リクエスト(Least Request)・最低利用率(Minimum Use)は、リクエスト負荷が均一という前提に立つ。しかし LLM では応答長によって decode 段階の GPU メモリ使用量と推論時間が大きく変わり(ShareGPT: 応答長 5〜632 トークン)、重いリクエストが一部インスタンスに集中して KV キャッシュを枯渇させる。PreServe はプロンプト内容から応答長を予測し、prefill 負荷 + decode 負荷 + KV メモリオーバーフローリスクの 3 成分を合算してルーティングする。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) - **サービスレベル予測とリクエストレベル予測の二層化が不可欠**: 単一層の予測では「長期的なインスタンス数の過不足」(ワークロードスパイク)と「短期的なインスタンス内過負荷リスク」(リクエスト負荷不均一)を同時に対処できない。PreServe は(1) mLSTM によるトークン密度の 10 分先読みで長期インスタンス数を決定し、(2) DistilBERT + プロンプトチューニングによるリクエスト単位の応答長予測で短期 KV メモリ使用を先読みする二層構造を取る。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) - **LLM サービスはサービス種別固有のトークン分布を持ち、一律の管理は不適切**: Azure の code サービスは prompt TPS が chat の 2 倍程度だが、response TPS は逆に chat が code の約 4 倍。これはコーディング補助と会話という用途の違いを反映する。管理システムはサービスごとに prefill バウンドか decode バウンドかを区別する必要がある。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) - **インスタンスレベル最適化(DistServe・LoongServe 等)と管理レイヤー最適化(PreServe)は直交し組み合わせ可能**: LoongServe の弾性シーケンス並列は単一インスタンス内のスループットを高めるが、ワークロード変動への適応と複数インスタンス間の負荷均衡は管理レイヤーが担う。PreServe は管理レイヤーとして、LoongServe 等のインスタンスを下位の最適化単位として扱うことができる。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) - **インスタンス間の負荷分散(PreServe)とインスタンス内のリクエストスケジューリング(Niyama)は、QoS 管理の異なるレイヤーを担う相補的技術である**: PreServe は「どのインスタンスへリクエストを振り向けるか」(ルーティング)と「インスタンス数をどう増減するか」(オートスケーリング)を扱うのに対し、[[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] は「単一インスタンス(レプリカ)内で、到着済みの複数 QoS クラスのリクエストをどの順序・どのチャンクサイズで実行するか」を扱う。両者はインスタンス間/インスタンス内という異なるスコープで QoS 保証に取り組んでおり、PreServe のルーティングが振り分けたリクエストを、Niyama 型のスケジューラがインスタンス内で co-schedule するという積層構造が自然に成立する。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]], [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]]) - **「サイロ化されたインフラ」という同じ課題認識が、管理レイヤーとスケジューリングレイヤーの双方で独立に生まれている**: PreServe が扱う LMaaS 管理は「サービス種別ごとに専用インスタンスプールを持つと負荷変動時に資源が偏在する」という課題を持つが、Niyama も「interactive/batch を専用 GPU クラスタに分離すると資源利用効率が下がる」という同型の課題を、より細かいレプリカ内スケジューリングの粒度で指摘する。異なる粒度(インスタンスプール vs 単一レプリカ内リクエストキュー)で同じ「サイロ化の非効率」という設計問題が繰り返し現れることは、LLM サービング管理全体を通底する構造的な課題であることを示唆する。(Source: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]], [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]]) - **インスタンス間/インスタンス内のスケジューリングとは別に、単一インスタンス内部の並列化構成そのものを動的制御する管理レイヤーが存在する**: PreServe(インスタンス間ルーティング・オートスケーリング)と Niyama(インスタンス内 QoS スケジューリング)がいずれも「複数リクエストをどう資源に振り分けるか」を扱うのに対し、[[パイプライン並列化]] の DynaPipe は「単一インスタンスの[[パイプライン並列化]]構成(層のステージ割当)自体を実行時ワークロードに応じて再配分する」という、さらに下位レイヤーの動的制御を扱う。PreServe・Niyama がリクエストスケジューリングの管理層であるのに対し、DynaPipe は並列化トポロジそのものの管理層であり、両者は積層可能な直交した最適化対象である。(Source: [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]], [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]]) - **「どのインスタンスへ振り分けるか」に加えて「どのモデル・GPUへ配置するか」自体が協調最適化対象になりうる**: PreServe・Niyama は「モデル自体は固定で、複数インスタンス/リクエストへどう負荷分散するか」を扱う。これに対し BOute は、そもそも異種モデル(小モデル/大モデル)と異種GPU(RTX 5090/H100等)という2軸の異種性を前提に、「どのクエリをどのモデルへルーティングするか」と「どのモデルをどのGPUへどれだけ配置するか」を単一の多目的ベイズ最適化(MOBO)問題として同時決定する。ルーティング戦略が各モデルへの負荷分布を決め、それが最適デプロイメントを左右する一方、デプロイメントが各モデルの達成可能なレイテンシを決め、それが最適ルーティングを左右するという循環的依存があるため、逐次最適化(ルーティングを先に決めてからデプロイメントを決める、あるいはその逆)は準最適解に陥る。これは PreServe/Niyama が前提とする「モデル配置は所与」というスコープを一段広げた管理問題であり、LLM サービング管理の中でも「モデル選択」と「資源配置」を統合する層として位置づけられる。(Source: [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]]) - **モデル-GPUの親和性(affinity)はルーティング比率を動的に変える設計変数になる**: BOute は小モデル(Llama3.1-8B)が安価GPU(RTX 5090)上でH100比1.5倍低いP95レイテンシ、大モデル(Llama3.1-70B)がH100上でRTX 5090比2倍低いP95レイテンシという非対称性を実証し、この親和性を考慮した異種GPU配置に切り替えるとルーティング比率自体が最適な40/60から30/70へ変化することを示した(異種GPUデプロイメントが空けた予算を大モデルに再配分できるため)。これはPreServe等が前提とする「ルーティングとデプロイメントは独立に最適化できる」という暗黙の仮定が成り立たない具体例であり、LMaaS 管理においてハードウェア異種性を無視したルーティング設計は系統的に準最適になりうることを示す。(Source: [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]]) - **「コールドスタートが遅すぎて反応的スケーリングが機能しない」という同一観察に対し、PreServe は予測で回避し、FaaScale は機構自体を高速化する、時間軸の異なる 2 つの解決アプローチが独立に存在する**: PreServe は mLSTM によるワークロード予測でスケールアウトを先行実行し、コールドスタートの影響時間を「隠す」。一方 [[@2026__MLSys2026__FaaScale - Unlocking Fast LLM Scaling for Serverless Inference]] は、モデルのキープアライブ時間の 95% 超が 15 秒未満・実トレースでの SSD キャッシュミス率 64%/36% という実測に基づき、モデル転送(マルチキャスト)と推論実行を co-design することでコールドスタートに要する絶対時間そのものを PipeCast により短縮する(BurstGPT トレースで P90 TTFT 2.4×–5× 改善)。両者は「いつスケールするか(予測)」と「スケーリング自体をどう速くするか(機構)」という直交する層で同じ trilemma に取り組んでおり、原理上は積層可能である。詳細は [[モデルスケーリング高速化]] を参照。(Source: [[@2026__MLSys2026__FaaScale - Unlocking Fast LLM Scaling for Serverless Inference]]) ## 未解決の問い - PreServe のサービスワークロード予測は 24.4% の最大 APE を持つ。ピーク不確実性をさらに削減する手法(アンサンブル予測・強化学習ベースのオンライン適応など)は有効か。 - 新規 LMaaS サービスの「コールドスタート期間」(履歴データなし)に安全に機能するオートスケーリング戦略は何か。PreServe は数日分のデータで十分と主張するが、その根拠は不明確。 - 複数 LLM サービス(code/chat など)を同一インスタンスプールで混在させる場合(コロケーション)、サービスごとの SLO は互いに干渉するか。PreServe はサービス単位の独立管理を前提としている。 - LoongServe・DistServe・AIBrix など異なるインスタンスレベル最適化と PreServe を組み合わせた場合の実際の性能向上はどの程度か。 - マルチテナント LMaaS プラットフォームでの公平性(Fairness)と SLO 保証の両立は PreServe のスコープ外であるが、実運用上は必要になる。 - PreServe(インスタンス間ルーティング/オートスケーリング)と Niyama(インスタンス内 QoS スケジューリング)を実際に積層した場合、両レイヤーの制御ループが競合(振動)を起こさないか。PreServe のワークロード予測とインスタンス内のデッドラインスラック計算が矛盾する情報を出す可能性はあるか。 - DynaPipe のインスタンス内パイプライン層再配分と、PreServe のインスタンス間ルーティング・Niyama のインスタンス内 QoS スケジューリングを積層した場合、3 層の制御ループ(並列化トポロジ・リクエストスケジューリング・インスタンス配置)は互いに矛盾する意思決定をしないか。DynaPipe の window threshold による安定化と、PreServe/Niyama の予測ベース制御が異なる時間スケールで動く場合の相互作用は未検証。 - BOute のルーティング×デプロイメント協調最適化と、PreServe のインスタンス間ルーティング・オートスケーリングを同時に運用した場合、両者の意思決定は衝突しないか。BOute はモデル・GPU配置を静的に(約30秒の再スケジューリングで)決定するのに対し、PreServe はより高頻度にインスタンス数を増減する。時間スケールの異なる2つの制御ループが同一システムに共存する際の安定性は未検証。 - BOute は閾値ベースの単一ルータ(RouteLLM系)を前提とするが、Niyama のようなインスタンス内QoS差別化スケジューリングと組み合わせた場合、モデル・GPU配置の協調最適化(BOuteの役割)とリクエスト実行順序の協調最適化(Niyamaの役割)は独立に扱えるか、それとも両者も循環的依存を持つか。 - SuperInfer の RotaSched(GPU-CPU メモリ配置の SLO 駆動制御)を、PreServe(インスタンス間ルーティング)・Niyama(インスタンス内 QoS スケジューリング)と積層した場合、3 層(インスタンス間 → インスタンス内リクエスト順序 → GPU-CPU メモリ配置)の制御ループはどう調停すべきか。特に PreServe のワークロード予測に基づくインスタンス数の増減と、RotaSched が個々のインスタンス内で行う能動的スワップは、同じ「メモリ圧迫」シグナルに異なる時間スケールで反応するため、意思決定が競合しないか。 - GPU-CPU 密結合 Superchip(GH200 等)が広く普及した場合、PreServe・BOute が前提とする「GPU メモリは希少で高コスト」という資源制約モデルはどの程度緩和されるか。CPU DRAM への高速オフロードが標準化すれば、マルチテナント LMaaS のインスタンス数見積もりやコスト最適化(BOute)の前提パラメータ自体を見直す必要があるか。 - **リクエストスケジューリング(バッチング・チャンキング)と GPU DVFS は、同一の SLO レイテンシスラック予算を奪い合う結合した管理対象であり、片方のみを管理層の最適化対象とするのは不完全である**: PreServe(インスタンス間ルーティング/オートスケーリング)・Niyama(インスタンス内 QoS スケジューリング)・DynaPipe(パイプライン層再配分)はいずれも「リクエストや層をどう資源に振り分けるか」という資源軸のみを扱い、GPU の電力状態(周波数)は所与として扱う。これに対し [[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]] は、LLM サービング管理が扱うべき制御ノブに GPU DVFS を明示的に加え、SLO が生むレイテンシスラックを「資源効率(バッチング/チャンクサイズ)」と「電力効率(周波数)」の2軸に同時配分するプリフィル/デコード別スケジューラ(S1/S2)を提案する。これは LLM サービング管理の最適化対象が「どのリクエストをどう実行するか」から「どのリクエストをどの電力状態で実行するか」へと一段拡張されていることを示し、[[GPUエネルギー効率]] の観点が本 concept のスコープに直接連続することを裏付ける(Source: [[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]])。 - **BEAM のイベント駆動・フェーズ別(S1: Prefill Scheduler / S2: Decode Scheduler)という構造は、PreServe・Niyama が採用する「フェーズ・レイヤーごとに専用コンポーネントを持つ」という設計パターンと同型である**: PreServe はサービスレベル予測とリクエストレベル予測を二層化し、Niyama はインスタンス間/インスタンス内で管理層を分離するが、BEAM はさらに細かい粒度でプリフィル(計算バウンド、TTFT SLO)とデコード(メモリバウンド、TBT SLO)を別スケジューラに分離する。これは LLM サービング管理全体を通じて、「異なる性質を持つフェーズ・レイヤーには専用の意思決定コンポーネントを割り当てる」という設計原則が、管理層(インスタンス間)からリクエストスケジューリング(インスタンス内)、さらに単一リクエスト内のフェーズ制御(BEAM)まで一貫して繰り返し現れることを示す(Source: [[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]], [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]], [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]])。 - **単一インスタンス内でも「メモリ容量制約」自体を SLO 駆動でスケジューリングする管理層が独立に存在する**: PreServe(インスタンス間ルーティング)・Niyama(インスタンス内 QoS スケジューリング)・BEAM(電力状態)はいずれも GPU の計算資源・電力状態を制御ノブとするのに対し、[[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]] の RotaSched は「単一インスタンス内で GPU HBM が不足したときに、どのリクエストを CPU DRAM へローテーション(スワップ)するか」という、GPU-CPU 間メモリ配置そのものを SLO(Virtual Lag Time で定量化した TTFT/TBT 進捗の遅れ)に基づいて能動的に制御する。これは Niyama のチャンキング・優先度付け(GPU 上に留まったリクエスト間の実行順序制御)よりさらに一段下の層——「そもそもどのリクエストを GPU 上に留めるか」——を扱っており、LLM サービング管理のレイヤー構造(インスタンス間ルーティング → インスタンス内 QoS スケジューリング → GPU-CPU メモリ配置)に新たな最下層を加える。(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]], [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]]) - **GPU-CPU 密結合 Superchip の登場は、「メモリ容量が尽きたら受動的にプリエンプトする」という既存の SLO 管理前提を変える**: PreServe・Niyama・BEAM はいずれも GPU メモリ容量を所与の制約として扱い、その範囲内でリクエストをどう振り分けるかを最適化する。SuperInfer は NVIDIA GH200 の NVLink-C2C(900GB/s)により GPU-CPU 間の実効メモリ容量を大幅に拡張できることを示し、TTFT SLO 達成率を最大 74.7% 改善した。これは、[[KVキャッシュ管理]] が蓄積してきた「GPU メモリは希少資源」という前提そのものが、ハードウェア世代(Superchip)によって緩和されつつあり、LLM サービング管理の設計空間(何を制御ノブとして最適化するか)がハードウェア進化とともに拡張し続けることを示す一例である。(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) ## 関連 - ソース: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]] / [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] / [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]] / [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]] / [[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]] / [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]] - 概念: [[LLM推論]] / [[サービスレベル目標]] / [[Prefill-Decode分離]] / [[オートスケーリング]] / [[パイプライン並列化]] / [[GPUクラスタスケジューリング]] / [[モデルスケーリング高速化]] / [[GPUエネルギー効率]] / [[KVキャッシュ管理]] - エンティティ: [[vLLM]] / [[The Chinese University of Hong Kong]] / [[Sarathi-Serve]] / [[Sun Yat-sen University]] / [[NVIDIA GH200]] - 関連 MOC: [[Systems for ML - MOC]] ## 出典 - [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]] (LMaaS ワークロード特性分析・PreServe フレームワーク設計・評価結果) - [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]](インスタンス内 QoS 差別化スケジューリング、動的チャンキング、ハイブリッド優先度付け、積極的降格) - [[@2025__NeurIPS__DynaPipe - Dynamic Layer Redistribution for Efficient Serving of LLMs with Pipeline Parallelism]](パイプライン並列のステージ間サンプリング負荷不均衡を動的層再配分で解消、E2E レイテンシ 8〜41% 削減) - [[@2026__MLSys__BOute - Cost-Efficient LLM Serving with Heterogeneous LLMs and GPUs via Multi-Objective Bayesian Optimization]](異種モデルルーティングと異種GPUデプロイメントの多目的ベイズ最適化による協調最適化、既存手法比P95レイテンシ最大157%改善・コスト15〜61%削減) - [[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]](チャンクサイズ・マイクロバッチ数・GPU DVFS のミリ秒粒度共最適化によるエネルギー削減、vLLM比最大51%) - [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]](GPU-CPU 密結合 Superchip 向け SLO 駆動 KV キャッシュローテーション、Virtual Lag Time による能動的プリエンプション、TTFT SLO 達成率最大 74.7% 改善)