# 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 のサービスワークロード予測は 24.4% の最大 APE を持つ。ピーク不確実性をさらに削減する手法(アンサンブル予測・強化学習ベースのオンライン適応など)は有効か。 - 新規 LMaaS サービスの「コールドスタート期間」(履歴データなし)に安全に機能するオートスケーリング戦略は何か。PreServe は数日分のデータで十分と主張するが、その根拠は不明確。 - 複数 LLM サービス(code/chat など)を同一インスタンスプールで混在させる場合(コロケーション)、サービスごとの SLO は互いに干渉するか。PreServe はサービス単位の独立管理を前提としている。 - LoongServe・DistServe・AIBrix など異なるインスタンスレベル最適化と PreServe を組み合わせた場合の実際の性能向上はどの程度か。 - マルチテナント LMaaS プラットフォームでの公平性(Fairness)と SLO 保証の両立は PreServe のスコープ外であるが、実運用上は必要になる。 ## 関連 - ソース: [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]] - 概念: [[LLM推論]] / [[サービスレベル目標]] / [[Prefill-Decode分離]] / [[オートスケーリング]] - エンティティ: [[vLLM]] / [[The Chinese University of Hong Kong]] - 関連 MOC: [[Systems for ML - MOC]] ## 出典 - [[@2026__ICSE__PreServe - Intelligent Management for LMaaS Systems via Hierarchical Prediction]] (LMaaS ワークロード特性分析・PreServe フレームワーク設計・評価結果)