テクニカルガイド

連続バッチ処理

Continuous batching updates the active request set between generation iterations instead of holding one fixed batch until every request finishes.

このガイドを聴くAIによるナレーション · ~2 min

このページでは2分の読書
  1. 概要
  2. ディープダイブ
  3. 現実世界の実装
  4. 継続的バッチ処理の将来
  5. 実践する
  6. 探検を続けましょう
  7. よくある質問

概要

It can improve serving utilization, while capacity limits and scheduling policy still govern latency.

ディープダイブ

GPUs are fastest when they process many requests together in a batch. The naive approach, static batching, groups a fixed set of requests, runs them all to completion, then starts the next batch. The problem: language model outputs vary wildly in length, so short requests finish early and their slots sit idle while the batch waits for the longest one, wasting GPU cycles and delaying new arrivals. Continuous batching (also called in-flight or iteration-level batching, popularized by the Orca paper and used in vLLM, TensorRT-LLM, and TGI) operates at the granularity of a single decoding step. After each token is generated, finished sequences exit the batch and queued requests can be admitted when the scheduler has capacity. Iteration-level admission can improve utilization and reduce avoidable waiting compared with fixed batches; the measured effect depends on request lengths, capacity, and scheduling.

現実世界の実装

新しく到着したユーザー メッセージを次のバッチのキューに入れるのではなく、すぐに実行中のバッチに入れるチャット API

バッチの途中で短い完了した回答をエビクトし、そのスロットを埋め戻すことで、GPU が長い世代を待ってアイドル状態になることがなくなります。

連続バッチ処理と vLLM の PagedAttending を組み合わせて、各デコード ステップでシーケンスを安価に挿入および削除する

バッチをフル状態に保つことで、バースト的な可変長トラフィック下でも高い 1 秒あたりのトークン数を維持するコード補完サービス

継続的バッチ処理の将来

Serving teams balance throughput with time to first token and time between generated tokens. Long prefill work can delay decoding unless the scheduler splits or otherwise manages it. Capacity budgets, request priorities, and fairness policies determine which work is admitted. Continuous batching can be combined with paged caches, chunked prefill, and speculative decoding, but each combination should be measured on the actual traffic and hardware.

実践する

なぜそれが重要なのか

  • 費用と予算. アーキテクチャの決定により、パフォーマンスと運用コストが何年にもわたって推進されます。
  • より明確な判決. 技術教育は、チームが最新のスタックだけでなく、適切なスタックを選択するのに役立ちます。
  • 品質管理. より良いエンジニアリングの選択により、本番環境での信頼性に関するインシデントが減少します。

気をつけてください

  • 1 つのベンチマークを最適化すると、より広範なシステムの弱点が隠れる可能性があります。
  • インフラストラクチャとメンテナンスのコストは過小評価されがちです。
  • システムが複雑になるにつれて、セキュリティと可観測性のギャップが拡大する可能性があります。

次のステップ

  1. 実装前にレイテンシ、品質、コストの目標を定義します。
  2. 現実的な負荷とデータ条件でのベンチマーク。
  3. エラー、ドリフト、ユーザーへの影響を計測器で監視します。
  4. スケーリングの前に、ロールバックとインシデント対応のパスを準備します。

探検を続けましょう

無料ニュースレター

毎日のAIブリーフィングを受け取る

毎週平日の朝に英語で書かれた3つの検証済みAIストーリー。無料で永続的、広告なし。

毎週平日に1通のメール。ワンクリックで購読解除。住所を販売または共有しません。

自分自身をテストしてください

Take the Continuous Batching quiz

すべての回答に即時フィードバック、合格後は検証可能なID付きの共有可能な証明書を取得。

クイズを開始する

無料AI教育をサポート。AI Understandingは501(c)(3)の非営利団体です — 広告なし、課金壁なし、常に。 寄付をする

よくある質問

What is Continuous Batching?

Continuous batching updates the active request set between generation iterations instead of holding one fixed batch until every request finishes. It can improve serving utilization, while capacity limits and scheduling policy still govern latency.

LLM サービスの静的 (固定) バッチ処理の主な弱点は何ですか?

出力の長さが異なるため、完了したシーケンスは最も遅いシーケンスが完了するまでアイドル状態になり、GPU サイクルが無駄になり、新しいリクエストが遅延します。

連続バッチ処理ではリクエストの追加と削除はどの程度の粒度で行われますか?

継続的 (反復レベル) バッチ処理では、単一のデコード ステップごとにアクティブ セットが更新されるため、リクエスト全体ごとではなくトークンごとに動作します。

A continuous-batching request finishes and frees capacity. What can the scheduler do next?

Iteration-level scheduling can refill available capacity subject to memory, token, and other limits.

シーケンスの挿入/削除を安価にするために、連続バッチ処理と自然に組み合わせられる手法はどれですか?

PagedAttendance は、各シーケンスの KV キャッシュを独立したブロックに保存するため、途中でシーケンスを追加または削除しても、他のユーザーのメモリを妨げることはありません。

一般に、反復レベル (連続) バッチ処理の普及に貢献したと考えられている研究論文は何ですか?

Orca の論文では反復レベルのスケジューリングが紹介されており、このアイデアは vLLM、TGI、TensorRT-LLM などのサービス システムに採用されました。