アーカイブ / LLM
対話と一括処理の期限を見てLLM推論を振り分ける「Niyama」
Niyama
Niyamaの原論文から掲載した図です。細部はクリックして拡大できます。
出典:Niyama / arXiv ↗概要
- Niyamaは対話と一括処理を共有基盤で扱い、要求の期限に応じて処理順と入力の分割量を変える。
- 著者は、示された固定負荷の条件で、Sarathi-Serveの分離構成より必要なGPU数で見た効率が12〜32%改善したと報告する。
- 過負荷時には期限を守れない要求を別の列へ移す。導入時には、その待ち時間と処理時間の予測精度を測る必要がある。
補足:編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Niyamaの仕組み
- 01期限付き要求
- 02処理順と違反判定
- 03入力分割量の決定
- 04混合処理と回答出力
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
Niyamaは、応答を急ぐ対話と、完了時刻が重要な一括処理を同じLLM推論基盤で扱う。LLM推論とは、学習済みの言語モデルに入力を渡し、文章を生成する処理である。
用途別に設備を分けると、一方が混雑しても他方の空き容量を使いにくい。対話では最初の出力と後続の出力間隔、要約では完了までの時間が重要になるため、要求に応じた期限管理が必要となる。
手法
要求はまず入力処理用の列に入る。Niyamaは、対話には初回出力までの時間と出力間隔、一括処理には完了までの時間を指定し、期限と残りの仕事量から処理順を決める。例えばチャットと長文要約が同時に来た場合、次に進める入力を選び、期限違反が避けられない要求は別の列へ移す。
入力を読み込む「プリフィル」は、分割した「チャンク」単位で処理する。Niyamaは、回答を一単位ずつ生成する「デコード」中の要求について、次の出力期限までの余裕を調べ、守れる範囲でチャンクを大きくする。選んだ入力と進行中の出力をまとめて実行し、入力処理が終わった要求はデコード用の列へ移す。処理時間の予測には、シミュレータの性能記録で学習したモデルを使う。
新規性
Niyamaの特徴は、対話の初回・途中の出力と、一括処理の完了に別々の期限を設け、同じ推論基盤で処理する点にある。実行中の要求に残された時間を使い、入力の分割量を毎回調整する。
処理順には期限と残りの仕事量を組み合わせる。過負荷時には期限違反が避けられない要求を別の列へ移し、ほかの要求への遅延の波及を抑える設計である。
従来手法との違い
著者が容量評価の比較対象とするのは、対話用と一括処理用を分けたSarathi-Serveの構成である。入力を固定量ずつ処理すると、対話の短い応答間隔に合わせた設定が、期限に余裕のある要求にも及ぶ。
Niyamaは要求を共有基盤に集め、実行中の要求の期限に合わせて処理量を変える。論文は先着順、期限順、短い仕事を優先する方式の弱点も検討するが、比較結果を未評価の運用条件に広げることはできない。
実験結果
著者はShareGPT、Azure Conv、Azure Codeの要求を用い、Llama3-8BをA100一台、Qwen-7BをA100二台で評価した。到着時刻はポアソン分布という確率モデルで生成し、元データの入力・出力トークン数を保つ設定である。トークンはモデルが扱う文章の単位を指す。
著者によると、三つの期限区分に要求を等分した固定負荷の図では、二つのデータセットでSarathi-Serveの分離構成より必要なGPU数で見た効率が12〜32%改善した。容量は最大32%増え、容量を50%上回る負荷でも95%超の要求が遅延目標を満たしたと報告する。確認できた本文の範囲では評価節が途中で切れており、各数値の詳細な条件は確認できない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案:社内の問い合わせチャットと文書要約を同じ推論基盤で受ける。入力は質問文と要約対象文書、出力は逐次表示する回答と完成した要約とする。チャットには初回出力と出力間隔、要約には完了までの期限を付ける。
適用には、使用するモデルの処理時間を示す性能記録と、用途別の過去の生成長が必要になる。要求種別、期限、業務上の優先度を受付時の情報として渡し、受付・出力時刻を計測する。外部センサーは想定しないが、この用途で待ち時間が改善するかは未検証である。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案:まず、チャットと要約の到着時刻、入力長、生成長、初回・後続・最終出力時刻を記録する。同じ要求列を用途別の分離構成と共有構成で処理し、期限違反率、処理可能な要求数、別の列に移された要求の待ち時間を比べる。
共有構成には、処理時間の予測用の性能記録と用途別の生成長履歴を用意する。要求種別、期限、優先度を付けて受付処理から渡し、時刻計測を追加する。外部センサーは想定せず、予測が外れる要求や負荷急増時を分けて測る。
限界と課題
著者は、過負荷時には全要求の期限を守れないため、一部を別の列に移すと説明する。移された要求は負荷が低いときに処理される。また、一括処理の出力長は事前に分からず、用途別の生成履歴から見積もる。
編集上の検証事項は、移された要求の待ち時間、性能予測のずれ、履歴の少ない用途での処理順である。確認できた本文の範囲では評価節が途中で切れており、結果ごとの詳細な条件や表は確認できない。
出典
元のタイトル・要旨を確認する(英語)
Niyama : Breaking the Silos of LLM Inference Serving
The widespread adoption of Large Language Models (LLMs) has enabled diverse applications with very different latency requirements. Existing LLM serving frameworks rely on siloed infrastructure with coarse-grained workload segregation -- interactive and batch -- leading to inefficient resource utilization and limited support for fine-grained Quality-of-Service (QoS) differentiation. This results in operational inefficiencies, over-provisioning and poor load management during traffic surges. We present Niyama, a novel QoS-driven inference serving system that enables efficient co-scheduling of diverse workloads on shared infrastructure. Niyama introduces fine-grained QoS classification allowing applications to specify precise latency requirements, and dynamically adapts scheduling decisions based on real-time system state. Leveraging the predictable execution characteristics of LLM inference, Niyama implements a dynamic chunking mechanism to improve overall throughput while maintaining strict QoS guarantees. Additionally, Niyama employs a hybrid prioritization policy that balances fairness and efficiency, and employs selective request relegation that enables graceful service degradation during overload conditions. Our evaluation demonstrates that Niyama increases serving capacity by 32% compared to current siloed deployments, while maintaining QoS guarantees. Notably, under extreme load, our system reduces SLO violations by an order of magnitude compared to current strategies.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新:2026-10-01




