LLMエンジンの過負荷は、なぜキャンセルだけでは回復しないのか

導入

LLMへの呼び出しがタイムアウトすると、クライアントやプロキシは自動的に再試行することが多い。そこで、利用者が離れた呼び出しをキャンセルできれば、推論エンジンは負荷から回復できると考えがちだ。しかしarXivで公開された研究は、この見方に注意を促している。キャンセルがエンジンに届くころには、リトライがプロンプト処理の大半を終えている可能性があるからだ。

実験で分かったこと

研究者はvLLM上で3種類のオープンモデルを使い、過負荷、リトライ、キャンセルの組み合わせを検証した。さらに1つのモデルでは、クライアントの各試行と、エンジン内で生成された実行を結び付けるスケジューラトレースを分析した。主な結果は次の通りだ。

• キャンセルだけでは回復しなかった。 リトライを有効にした実験では、キャンセル単独でサービスが復旧したケースはなかった。過負荷後に到着した呼び出しのうち、配信されたのは12〜38%にとどまった。
• キャンセルは計算の後に来る。 vLLMが実行したリトライは、タイムアウトの半秒未満前にprefillを開始することが多かった。その後に中止された実行でも、プロンプトトークンの79〜85%をすでに計算していた。
• 負荷指標も損失を見逃す。 vLLMのプロンプトトークンカウンターは、実際に計算されたプロンプトトークンの約3分の1から半分を記録できていなかった。この指標だけでは、リトライによる浪費を過小評価しうる。

代替策も比較された。リトライ予算は追加試行を抑えることでサービスを回復させたが、過負荷中の多くの呼び出しは配信されなかった。一方、リクエスト統合は重複する試行をまとめ、キャンセルによって実行中の処理が先に中止されていなければ、過負荷以降のすべての呼び出しを届けた。ただし、一部は遅れて到着した。

意義

この研究は、「キャンセルできたか」だけでは運用状態を評価できないと示す。APIでキャンセル済みになっていても、推論エンジンはすでに大半の計算を終えている場合がある。また、エンジンが空いたとしても、利用者が必要な応答を受け取ったとは限らない。

LLMサービスの運用者は、リトライをクライアント側だけの信頼性機能ではなく、容量管理の一部として扱う必要がある。上限付きリトライ、重複の早期検出、リクエスト統合、実際に計算した全トークンを含む計測が有効な候補になる。万能な対策が示されたわけではないが、評価の軸は明確だ。リトライが追加した実行量と、最終的に利用者へ届いた呼び出しの両方を測る必要がある。

出典：arXiv