表示
超・人工知能研究所 Super AI Research Lab トップへ超・人工知能研究所AI Research Lab / ぱそ太郎工事中

since
平成38年9月29日

← 検索結果に戻る

検索文書の到着中にLLMの入力を処理する、同時要求向け配信手法

Stream2LLM

保存した記事を見るこのブラウザに保存します。無料会員で端末間の同期・フォルダ整理
原論文の図

Stream2LLMの原論文から掲載した図です。細部はクリックして拡大できます。

原論文の図の説明を読む

Figure 4: Performance models for recomputation vs. total swap latency costs across token counts on H200 and A40.

出典:Stream2LLM / arXiv ↗

概要

  • Stream2LLMは検索文書の到着とLLMの入力処理を重ね、複数の同時要求を扱う。
  • 入力更新時は共通する先頭部分の計算結果を残し、メモリー不足時は退避と再計算の予測時間を比べる。
  • 著者らは非ストリーミング方式に対するTTFTの改善と、メモリー逼迫時に処理順が待ち時間を左右する結果を報告した。
補足:編集した模式図で仕組みを確認する

VISUAL EXPLAINER

図でつかむ、Stream2LLMの仕組み

左から右へ読む
  1. 01質問と到着文書
  2. 02入力の共通部分を確認
  3. 03処理順とメモリーを決定
  4. 04入力処理を進行

原論文の説明をもとにした模式図です。処理の細部は省略しています。

研究の背景

Stream2LLMは、検索文書が届く間に大規模言語モデル(LLM)の入力処理を進める配信システムである。外部文書を参照する質問応答では、検索完了を待つ時間が、質問から最初の出力までの時間を延ばす。

複数人の要求を同時に扱うと、文書の到着時刻は要求ごとに異なる。処理済み入力の計算結果を置くGPUメモリーも共有するため、どの要求を先に進め、容量不足時に何を退避するかを決める必要がある。

手法

検索文書を受けると、入力を末尾に増やす追加型、または候補を差し替える更新型として扱う。旧入力と新入力の「最長共通接頭辞」、つまり先頭から連続して同じトークン列を調べ、その部分のKVキャッシュを残す。KVキャッシュは処理済みトークンの計算結果で、変更位置以降は無効にする。例えば二つ目の文書が変われば、共通する一つ目の文書の計算結果を再利用する。

次に、未完了の要求に優先順位を付け、処理量と必要なメモリーを見積もってから確保を試みる。不足時は優先順位に従って要求を一時停止し、キャッシュをCPUへ移して戻す時間と、捨てて再計算する時間の予測を比べる。対象は、入力をまとめて処理する「プリフィル」を出力生成から分けた構成である。

新規性

Stream2LLMは、複数の要求が並ぶ環境で、文書の追加と検索候補の差し替えの両方を扱うようvLLMを拡張する。入力が変わっても、共通する先頭部分の計算結果を残す。

要求の優先順位づけとGPUメモリーの確保を別の段階に分けた点も特徴である。メモリー不足時には、対象環境で測った時間に基づき、計算結果の退避と再計算を選ぶ。

従来手法との違い

比較対象は、検索結果がそろってから入力処理を始める非ストリーミング方式と、文書の到着や更新を優先順位に反映しない標準的なvLLMのスケジューラーである。前者は検索中に入力処理を進められない。

Stream2LLMは到着済みの文書から処理し、入力が変われば変更位置以降を計算し直す。著者らは、低負荷では各ストリーミング方式の差が小さく、メモリーの競合が強まると処理順の選択が重要になると報告している。

実験結果

著者らは、ウェブ巡回による文書の追加と、近似最近傍検索による候補の更新から収集した実際の検索ログで評価した。近似最近傍検索は、質問に近い文書候補を効率よく探す方法である。H100とH200のGPU、Llama-3.1のモデルを用い、最初のトークンまでの時間(TTFT)と処理量を調べた。

著者らによると、低負荷時にはストリーミング方式のTTFTが非ストリーミング方式に対して最大3.9~11.0倍改善し、処理量は同程度だった。極端なメモリー逼迫時には、不適切な処理順で末尾側の待ち時間が最大10倍悪化した。確認できた本文の範囲では、条件別の数値表とデータ分割の詳細は確認できない。

応用の可能性

編集上の応用案 · 論文が実証した用途とは区別しています。

編集上の応用案:社内規程を参照する質問応答で、検索済み文書を到着順にLLMへ渡す。入力は社員の質問と閲覧権限を確認した規程文書、出力は回答とその根拠文書とする。候補が途中で差し替わる検索工程なら、更新型の入力も試す。

必要な元データは規程文書と文書の到着・更新時刻を記録した検索ログである。回答確認用に質問と正解根拠のラベルを用意する。追加学習用データや物理センサーは想定せず、文書の渡し方を既存の検索工程と権限管理に合わせる。

応用先の候補からNauhに相談できます。

導入時の検証

導入時の検証案 · 対象データでの再評価が必要です。

導入時の検証案:検索対象の文書と、到着時刻・候補差し替えを含むログを用意する。同じ質問群を、検索完了後に入力する現行方式と到着順に入力する方式で流し、TTFT、処理量、混雑時の待ち時間、回答と正解根拠の一致を測る。

品質確認用には質問ごとの正解根拠ラベルを人手で作る。追加学習用データと物理センサーは使わず、既存の検索工程を追加型か更新型に合わせて接続する。対象環境で再計算とCPU退避の所要時間を測り、同時要求数を変えて比較する。

限界と課題

著者らは、共通する先頭部分を残す方法は末尾への追加や差し替えに適し、先頭近くが頻繁に変わる場合は利点が小さくなると述べる。また、対象は入力処理と出力生成を分けた構成の入力処理側であり、出力トークン間の遅延は評価していない。

編集上の検証事項は、自社の文書更新が評価対象の検索ログに近いか、回答品質を保てるか、混雑時の待ち時間がどう変わるかである。退避と再計算の選択には対象環境での時間測定が必要になる。

応用先の候補
研究内容と応用案に基づく分類です。業界での導入実績を示すものではありません。

出典

元のタイトル・要旨を確認する(英語)

Stream2LLM: Overlap Context Streaming and Prefill for Reduced Time-to-First-Token (TTFT)

Context retrieval systems for LLM inference face a critical challenge: high retrieval latency creates a fundamental tension between waiting for complete context (poor time-to-first-token) and proceeding without it (reduced quality). Streaming context incrementally--overlapping retrieval with inference--can mitigate this latency, but doing so with concurrent requests introduces new challenges: requests contend for GPU compute and memory, and scheduling must adapt to dynamic context arrivals. We present Stream2LLM, a streaming-aware LLM serving system for concurrent prefill-decode disaggregated deployments. Stream2LLM introduces adaptive scheduling and preemption for two distinct retrieval patterns: append-mode (progressive context accumulation) and update-mode (iterative refinement with cache invalidation). It decouples scheduling decisions from resource acquisition, enabling flexible preemption strategies guided by hardware-specific cost models, and uses longest common prefix matching to minimize redundant computation when input changes dynamically. To evaluate Stream2LLM, we collect two large-scale, real-world streaming workloads based on web crawling and approximate nearest neighbor search. Our evaluation demonstrates that streaming architecture delivers up to 11x TTFT improvements, with cost-aware scheduling providing critical benefits under memory pressure, all while maintaining throughput parity with non-streaming baselines. Code: https://github.com/rajveerb/stream2llm/tree/mlsys_artifact

論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新:2026-10-01