連続バッチ処理は、大規模モデルのサーバー側で行われる動的スケジューリング手法です。システムは同じバッチ内のすべてのリクエストが生成されるのを待つことなく、次のバッチを置き換えます。代わりに、各生成ステップが終了した後に完了したリクエストを削除し、新しいリクエストを追加します。 主にGPU利用率と全体のスループットを向上させ、複数人が同時にモデルに電話をかけた場合のサービス効率を狙います。
なぜ静的バッチ処理が空待ちになりやすいのか
従来のバッチプロセッサはまず一連のリクエストを組み立て、それらをまとめて実行します。 しかし、生成タスクの入力と出力の長さは大きく異なります。数十トークンで答えるものもあれば、数百ステップを踏むものもあります。 短いリクエストが完了した後は、その位置が空のままになることがありますが、後のリクエストはバッチ全体が終了するまでキューで待つしかありません。
連続バッチ処理により、スケジューリングの細かさは「完全なリクエスト」から「現在の生成反復」へと絞られます。 トークン生成の各ラウンド終了後、スケジューラは終了するシーケンスと入力可能なシーケンスを確認し、次のバッチをまとめて作成します。 バッチメンバーは継続的に変化するため、しばしば反復スケジューリングや動的バッチ処理と呼ばれます。
1つのディスパッチは3つのタスクを同時に処理する必要があります
- スループット:利用可能な計算資源を埋めて、より多くのリクエストが一緒に進められるようにしましょう。
- 遅延:単に大きなバッチを待つだけでなく、すでに到着したユーザーを長い列に並ばせることもあります。
- ビデオメモリ:各アクティブなシーケンスはコンテキスト状態を保持しなければなりません。バッチが大きいほど、KVキャッシュへのメモリ負荷は高まります。
したがって、バッチ制限は必ずしも十分に良いとは限りません。 サービスフレームワークはまた、異なる長さの廃棄物埋め込み、プリエンプティブ戦略、優先順位付け、公平性、さらには異なる計算能力要件を必要とする入力プリパディングやトークンごとのデコードにも対応しています。
ユーザーはどう感じるでしょうか?
並行かつ安定したオンラインサービスでは、連続バッチ処理によりキューギャップが減り、より多くのユーザーが同じGPUセットに対応できるようになります。 しかし、スループットが増えたからといってすべてのリクエストが速くなるわけではありません。スケジューラが過負荷状態を追求すると、低優先度のリクエストはより長く待つことがあり、単一リクエストの遅延はさらに増加することもあります。
評価時には、最初のトークンの遅延、その後のトークン間の間隔、1秒あたりのトークン総数、そして高ランクの遅延を別々に観察する必要があります。 低同時実行の個人ローカルデプロイメントでは動的バッチをほとんど生成できず、その利点が制限される可能性があります。 APIであれチャットプラットフォームであれ、マルチテナント推論クラスターであれ、コストと体験を決定するのはコアインフラです。
