> [!abstract] 概要(arXiv abstract の日本語訳) > 大規模言語モデル(LLM)の普及により、要求されるレイテンシが大きく異なる多様なアプリケーションが可能になった。既存の LLM サービングフレームワークは、対話的(interactive)とバッチ(batch)という粗粒度のワークロード分離に依存するサイロ化されたインフラに頼っており、リソース利用効率の低さと、細粒度な Quality-of-Service(QoS)差別化への対応力不足を招いている。これは運用上の非効率、過剰プロビジョニング、トラフィック急増時の負荷管理の悪さという結果につながる。 > > 本論文では、共有インフラ上で多様なワークロードを効率的に co-schedule できる、QoS 駆動の新しい推論サービングシステム Niyama を提示する。Niyama は細粒度の QoS 分類を導入し、アプリケーションが精密なレイテンシ要件を指定できるようにし、リアルタイムのシステム状態に基づいてスケジューリング判断を動的に適応させる。LLM 推論の予測可能な実行特性を活用し、Niyama は動的チャンキング機構を実装して、厳格な QoS 保証を維持しながら全体スループットを改善する。さらに Niyama は、公平性と効率のバランスを取るハイブリッド優先度付けポリシーを採用し、過負荷条件下でも段階的なサービス劣化を可能にする選択的リクエスト降格を用いる。 > > 評価の結果、Niyama は QoS 保証を維持しながら、現行のサイロ化デプロイメント比でサービング容量を 32% 向上させることが分かった。特に極限負荷下では、本システムは現行の戦略と比較して SLO 違反を一桁削減する。 ## 論文情報 - タイトル: Niyama: Breaking the Silos of LLM Inference Serving - 著者: [[Kanishk Goel]]・[[Jayashree Mohan]]・[[Nipun Kwatra]]・[[Ravi Shreyas Anupindi]]・[[Ramachandran Ramjee]] - 所属: [[Microsoft Research]] India - 媒体: arXiv(2025-03-28、cs.LG / cs.AI / cs.DC)。Microsoft Research の publication ページでは "QoServe: Breaking the Silos of LLM Inference Serving" という改題後のタイトルで、ASPLOS 2026(2026 年 3 月)採録として掲載されている(https://www.microsoft.com/en-us/research/publication/niyama-breaking-the-silos-of-llm-inference-serving/)。本ページは初版の arXiv:2503.22562(システム名・abstract は ASPLOS 版と同一)を原本として取り込んだ。 - arXiv ID: 2503.22562 ## 概要 Niyama は、LLM 推論サービングにおいて interactive(対話的)・batch(バッチ処理)の二値サイロを廃し、複数の QoS クラスを単一の共有クラスタ上で co-schedule する QoS 駆動スケジューリングシステムである。[[LLM推論]]の Prefill(計算バウンド)・Decode(メモリバウンド)というフェーズ特性の予測可能性を活用し、(1) 動的チャンキング、(2) ハイブリッド優先度付け、(3) 積極的降格、という 3 つの技術を組み合わせて、レイテンシ SLO の遵守と高スループットを両立させる。[[vLLM]] 上に構築された Sarathi-Serve([[Sarathi-Serve]])のスケジューラを拡張して実装されている。 ![[_attachments/arxiv-2503.22562/fig01-coschedule-vs-siloed.png]] (Figure 1(右上図)。左: SOTA サイロ構成では QoS 1(interactive)・QoS 2・QoS 3(いずれも non-interactive)がそれぞれ専用 GPU 群を持ち、負荷変動に対して個別にしか対応できない。右: Niyama は単一の GPU プール上で 3 つの QoS クラスを混在させたバッチを co-schedule し、GPU 台数を削減しながら各クラスの QoS を維持する。Source: 論文 Figure 1 の埋め込み画像。) ## 問題設定 - **入力**: 異なる QoS 要件(TTFT・TBT・TTLT のいずれか)を持つリクエストのストリーム。各リクエストはアプリケーションが指定した QoS クラス(interactive または non-interactive)に属し、クラス内でも SLO ターゲットをカスタマイズできる。 - **出力**: 各 QoS ターゲットを満たしながら、最大のサービング容量(スループット)を達成するスケジューリング判断。 - **前提**: [[Prefill-Decode分離]]の対極にあるアーキテクチャで、Prefill と Decode は同一レプリカ(同一 GPU 群)上で chunked-prefill を用いて co-located に実行される。これは vLLM・SGLang で一般的な運用形態である。 - **必要なデータ**: リクエスト到着時刻・プロンプト長・SLO ターゲット(TTFT/TBT/TTLT)・優先度ヒント(free/paid tier 等のアプリケーション由来情報)。 ## 提案手法 ### アーキテクチャ Niyama のリクエストは prefill queue・decode queue・relegated queue のいずれかに存在する(Figure 3)。 1. 新規リクエストは prefill queue に入る。 2. 各イテレーションで、decode queue の全リクエストと prefill queue からの 1 チャンクで構成されるバッチを組む。prefill 選択はハイブリッド優先度付けで決まる。 3. violation checker が選択リクエストの QoS 違反(発生済みまたは今回発生見込み)を検査し、違反する場合は relegated queue へ移して別のリクエストを選び直す。 4. 軽量な予測器がバッチのレイテンシを推定し、QoS 目標を守りつつチャンクサイズを最大化する。 5. 混合バッチ(prefill チャンク + decode トークン)を GPU の実行エンジンへディスパッチする。 6. prefill 完了後、リクエストは decode queue に移動する。 relegated queue のリクエストはシステム負荷が低い期間に機会的にサービスされ、永続的な棄却を避けつつ過負荷下での段階的劣化を実現する。 ![[_attachments/arxiv-2503.22562/fig03-architecture.png]] (Figure 3. Niyama のアーキテクチャ概要。QoS 1〜3 のリクエストが prefill queue に入り(①)、ハイブリッド優先度付けを行う prefill selector が次に処理するリクエストを選ぶ(②)。violation checker が QoS 違反を検知すると relegated queue へ移動し(③)、問題なければ chunk size estimator がチャンクサイズを決定する(④)。決定されたバッチ(⑤)は GPU 群へディスパッチされ(⑥)、prefill 完了後は decode queue へ移る(⑦)。Source: 論文 Figure 3 の埋め込み画像。) ### QoS クラスとデッドライン Niyama は interactive(TTFT + TBT の 2 SLO)と non-interactive(TTLT の単一 SLO)の 2 クラスを定義するが、クラス内でアプリケーション固有の SLO ターゲットを自由に設定できる(Table 2)。デッドラインは以下で定義される。 - interactive の初回トークン: `D_first = t_arrival + SLO_TTFT` - interactive の n 番目以降のトークン: `D_n = t_arrival + SLO_TTFT + (n-1)・SLO_TBT` - non-interactive: `D_total = t_arrival + SLO_TTLT` ### 動的チャンキング(Dynamic Chunking) State-of-the-art な chunked-prefill サービング([[Sarathi-Serve]]・vLLM)は固定チャンクサイズを使うため、最も厳格な QoS クラスの制約に合わせて小さいチャンクを選ぶと全体スループットが低下する(Figure 4 では固定チャンクサイズ 330 で 50 ms SLO を満たすとスループットが 28% 低下することを示す)。 Niyama は decode queue 内の各リクエストについて「次トークンのデッドラインまでの残り時間(スラック)」を計算し、現在バッチのどのリクエストのデッドラインも侵害しない範囲で最大のチャンクサイズを機会的に選ぶ。非対話リクエストの緩いデッドラインや、対話リクエストが低負荷時に蓄積したスラックを利用してチャンクサイズを拡大し、スループットを改善する(Figure 6 のイラストで固定チャンクサイズ方式と比較)。 ![[_attachments/arxiv-2503.22562/fig06-dynamic-chunking.png]] (Figure 6. Niyama の動的チャンキングによるスループット改善の模式図。(a) SOTA の固定チャンクサイズ方式では、A・B・C・D・E の 5 リクエスト(QoS 1〜3)を到着順に固定サイズで処理し、C のデッドライン違反(Missed deadline)が発生する。(b) Niyama の動的チャンキングでは、各リクエストのデッドラインスラックを活用してチャンクサイズを機会的に拡大し(Slack 区間の活用)、全リクエストを高速に処理してスケジュール全体の Speedup を達成する。Source: 論文 Figure 6 の埋め込み画像。) ### ハイブリッド優先度付け(Hybrid Prioritization) 既存のスケジューリングポリシー(FCFS・SJF・SRPF・EDF)はいずれも LLM 推論ワークロードで根本的な弱点を持つ(Figure 2)。EDF は低負荷では違反ゼロだが、負荷がしきい値を超えると違反率がほぼ 100% に急騰する。SRPF/SJF は高負荷に強いが、長いリクエストのデッドラインを公平性を無視して犠牲にする。 Niyama は EDF と SRPF を線形補間するハイブリッド優先度式を導入する。interactive リクエストの優先度は式 (4)、non-interactive リクエストの優先度は式 (5) で計算される。 ``` P_i = t_arrival_i + SLO_TTFT_i + α * Prefill_rem_i (式4, interactive) P_i = t_arrival_i + SLO_TTLT_i + α * (Prefill_rem_i + Decode_rem_i) (式5, non-interactive) ``` α は補間パラメータで、大きくするほど短いリクエストを優先する SRPF 的挙動に近づく。デプロイ時に設定可能なパラメータとして実装されている。non-interactive リクエストの decode 長は未知のため、アプリケーションごとの過去のトークン生成履歴から標準偏差 2 個分を上方向に見積もって近似する。 ### 積極的降格(Eager Relegation)と選択的プリエンプション ハイブリッド優先度付けだけでは過負荷下で全リクエストの QoS を満たせない(Figure 5)。Niyama は、TTFT/TTLT デッドラインをすでに違反した、または今回のイテレーションで違反しそうなリクエストを relegated queue へ積極的に降格させる。マルチテナント環境では free/paid tier などのアプリケーションヒントを使って低優先度リクエストを優先的に降格し、高優先度リクエストの QoS を維持する。低優先度リクエストが尽きた場合のみ、高優先度リクエストのうち違反済みのものを降格してカスケード違反を防ぐ。 さらに Niyama は選択的プリエンプションを実装する。decode queue のリクエストは TBT 制約が厳しいためプリエンプトしないが、prefill queue のリクエスト(すでに一部チャンクを処理済みでも)は、プリエンプトしてもデッドラインに違反しない場合に限り、より優先度の高い新規リクエストのために中断できる。これにより、大きなバッチリクエストの後ろで小さな対話的リクエストが head-of-line blocking されることを防ぎつつ、KV キャッシュの保持時間を最短化してメモリ圧を抑える。 ### 実装上の工夫 Niyama は [[Sarathi-Serve]] のスケジューラを拡張する形で実装されており、Sarathi-Serve 自体は [[vLLM]] の PagedAttention・テンソル並列基盤上に構築されている。各推論リクエストに QoS 要件(TTFT/TBT/TTLT)と優先度レベルを紐づけるよう vLLM API を拡張した。動的チャンクサイズの予測器は、[[Vidur]] LLM 推論シミュレータで収集した性能プロファイルで訓練した軽量なランダムフォレストモデルとして実装され、スケジューリングのオーバーヘッドを最小化している。ハイブリッド優先度付けは、デッドライン近接性と推定処理時間の両方を組み込んだ優先度キューで実装され、補間係数 α はデプロイパラメータとして設定可能。 ## 新規性 既存研究との対比: - **[[Sarathi-Serve]]・vLLM は固定チャンクサイズと FCFS(到着順)を使う**のに対し、Niyama は QoS ターゲットに基づく優先度付けとデッドラインスラックに基づく動的チャンクサイズを導入する。 - **Prefill-Decode 分離([[DistServe]] 等)は Prefill と Decode を物理的に別インスタンスへ切り離す**のに対し、Niyama は同一レプリカ上での co-location を維持したまま、複数 QoS クラスを共有インフラで co-schedule することでサイロ化の非効率を解消する。両者はアプローチが対極(分離 vs 共有)であり、資源分離と資源共有という異なる軸で LLM サービングの効率化に取り組んでいる。 - **クラウドの QoS 対応スケジューリング研究(Paragon・Quasar 等)は LLM 推論特有の二段階実行モデル(Prefill/Decode)・高いプリエンプションコスト・過負荷時の挙動を対象としていない**。Niyama はこれらの LLM 固有の特性を利用した初めての QoS 駆動スケジューリング研究であると論文は主張する。 - **過負荷時のグレースフルデグラデーション研究(Bouncer 等の admission control)は低遅延データシステム全般を対象とする**が、LLM 推論の文脈でこれを扱う研究は本論文が最初だとしている。 ## 実験設定 - **ハードウェア**: NVIDIA A100 GPU(80GB)。Llama3-8B は単一 A100、Qwen-7B はテンソル並列 2(2× A100)で評価。 - **データセット**(Table 1): ShareGPT(プロンプト長 p50=1730・p90=5696)、Azure Conv(p50=928・p90=3830)、Azure Code(p50=1930・p90=6251)の 3 種。それぞれ prefill/decode トークン比が異なる。 - **QoS 構成**(Table 2): 各データセットを 3 等分し、Q1(interactive、TTFT 6s・TBT 50ms、リクエスト比率 33.33%)、Q2(non-interactive、TTLT 600s)、Q3(non-interactive、TTLT 1800s)に割り当てる。 - **比較対象**: - Sarathi-Silo(SOTA サイロ構成): QoS バケットごとに独立した GPU クラスタ + Sarathi スケジューラ - Sarathi-FCFS: 統合クラスタ上で Sarathi + FCFS - Sarathi-EDF: 統合クラスタ上で Sarathi + EDF - Sarathi-SRPF: 統合クラスタ上で Sarathi + 最小残プロンプトトークン優先 - 最も厳格な QoS バケット(TBT 50ms)はチャンクサイズ 256、サイロ内の他 2 クラスはチャンクサイズ 2K を使用。共有クラスタベースラインは全てチャンクサイズ 256(最厳格クラスの TBT を満たすため)。 - **評価指標**: サービング容量(50 QPS を満たすのに必要な A100 台数)、goodput(p99 レイテンシ SLO を満たしつつ処理できるリクエスト/秒、違反許容率 1%)、TTFT/TBT/TTLT の中央値・p95 レイテンシ、SLO 違反率(全体・QoS バケット別・リクエスト長別)。 ## 実験結果 ### コスト効率(均一負荷、Figure 7a) 50 QPS の負荷を 3 データセットで処理するのに必要な A100 台数を比較すると、Niyama は SOTA サイロ構成比で GPU 必要台数を 13〜32% 削減した(Az Code: 62→42 台、Az Conv: 41→36 台、ShareGPT: 76→66 台)。 ![[_attachments/arxiv-2503.22562/fig07-capacity-goodput.png]] (Figure 7. (a) 50 QPS の負荷を処理するのに必要な A100 台数。Niyama は SOTA サイロ構成(オレンジ)比で全データセットにおいて必要台数を削減する。(b) 共有クラスタでの最大 goodput。Niyama(オリーブ)は Sarathi-FCFS 比 1.5〜2.4 倍、Sarathi-EDF 比 20〜40% 高い goodput を達成する。Source: 論文 Figure 7 を PyMuPDF でクロップ抽出。) ### Goodput(Figure 7b) Azure-Code データセットの共有 A100 クラスタでの goodput(p99 レイテンシ目標を満たしつつ処理できる QPS)は、Niyama が Sarathi-FCFS 比 1.5〜2.4 倍、Sarathi-EDF 比 20〜40% 高い値を示した(Azure Code: FCFS 1.5 → EDF 2.75 → Niyama 3.65、Azure Conv: FCFS 2.75 → EDF 3.55 → Niyama 4.25)。この改善は動的チャンキング・ハイブリッド優先度付け・積極的降格の組み合わせによるものである。 ### レイテンシと SLO 違反(過負荷、Figure 8・9) Llama3-8B + Azure-Code での評価では、Niyama は他のスケジューラ比で最大 40% 高い負荷まで各 QoS バケットのテールレイテンシ SLO を維持した。Sarathi-FCFS はデッドライン非認識のため head-of-line blocking で高負荷時に全リクエストが違反する。Sarathi-EDF はデッドライン近い順に処理するがキュー渋滞で高負荷時に FCFS と同様に破綻する。Sarathi-SRPF は中央値レイテンシは良好だが、長いリクエストの p95 レイテンシが無制限に増大し、低負荷(2 QPS 未満)でも長いリクエストのデッドラインを不必要に犠牲にする。Niyama は最大 30% 高い負荷までデッドライン違反ゼロを維持し、極限過負荷でも他方式より違反数が最も少なかった。 ### 動的負荷パターンへの応答(Figure 10・11) QPS が 2〜6 で 15 分ごとに変動する 4 時間の日周パターン評価(Table 3 のablation条件とは別評価)では、20% を低優先度としてマークした条件で、Niyama は重要タスクの違反ゼロ、全リクエストの違反率 8.64%(Sarathi-FCFS 81.88%、Sarathi-EDF 84.12%)を達成した。ローリング p99 レイテンシ(Figure 11)でも、Sarathi-FCFS は最初のバーストで崩壊して以降回復せず、Sarathi-EDF は最初のバーストは吸収するが 2 回目のピークで破綻するのに対し、Niyama は全ての重要リクエストと全体の 92% のリクエストで p99 SLO を満たした。 ### アブレーション(Table 3) Sarathi-EDF ベースラインから各要素を積み上げた場合のスループットとゴール達成度: | Config | 最適負荷 QPS | 最適負荷でのスループット向上 | 高負荷(6 QPS)違反率 | 高負荷での改善率 | |---|---|---|---|---| | Sarathi-EDF | 2.75 | - | 100% | - | | Niyama(DC のみ) | 3.3 | 20% | 74% | 26% | | Niyama(DC+ER) | 3.6 | 9% | 26% | 68% | | Niyama(DC+ER+HP) | 3.65 | 1.4% | 16% | 32% | (DC: 動的チャンキング、ER: 積極的降格、HP: ハイブリッド優先度付け。動的チャンキングが最適負荷でのスループット向上の主因(20%)、積極的降格が高負荷での違反削減の主因(74%→26%)であり、ハイブリッド優先度付けは最適負荷では効果が限定的だが高負荷で顕著に効く。) ## 考察 - Niyama の性能改善は、LLM 推論特有の Prefill/Decode 二段階構造とその予測可能性(特に Prefill の計算コストが入力長からほぼ決定的に見積もれる点)を利用したチャンクサイズの動的最適化に起因する。これは PD 分離アプローチが「別インスタンスに分けて資源を最適化する」のに対し、「同一インスタンス上でスラックを機会的に再配分する」という異なる資源利用戦略である。 - α パラメータ(Figure 12)は負荷に応じてチューニングが必要で、α を大きくすると中央値レイテンシは改善するが長いリクエストのデッドライン違反が増える。負荷変動に応じて α を動的調整する仕組みは論文内では固定値評価にとどまり、実装上のチューニング方針は明示されていない。 - 積極的降格は「違反確定のリクエストを早期に諦める」という設計であり、5% 程度の犠牲で残り 95% の SLO を守るというトレードオフを明示的に選択している。これは全リクエストを平等に扱う従来の過負荷対応(レート制限・短リクエスト優先)とは異なる設計思想である。 ## 強み / 弱点・課題 **強み**: - 複数 QoS クラスの co-scheduling により、サイロ構成比で最大 32% のリソース削減を実証。 - 動的チャンキング・ハイブリッド優先度付け・積極的降格という 3 要素が独立に寄与を持ち、アブレーションで定量化されている(Table 3)。 - 既存の vLLM/Sarathi-Serve エコシステムへの拡張として実装されており、独自の推論エンジンを新規開発していない。 **弱点・課題**: - non-interactive リクエストの decode 長予測は「過去のアプリケーション別統計 + 標準偏差 2 個分の上振れ」という単純なヒューリスティックであり、予測精度の定量評価(誤差分布)は論文中に示されていない。 - ハイブリッド優先度付けの補間パラメータ α は静的な deployment パラメータとして扱われており、負荷変動に応じた自動チューニング機構は提示されていない。 - 評価は単一モデル(Llama3-8B・Qwen-7B)・単一クラスタ規模(最大 2 GPU の TP)で行われており、大規模クラスタでのマルチレプリカ間ロードバランシングとの統合は評価対象外(§4 のセットアップは単一レプリカまたは共有クラスタ内の相対比較が中心)。 - Prefill-Decode 分離アーキテクチャとの直接比較評価は行われていない(比較対象はすべて co-located なスケジューラのみ)。