継続的バッチ処理とは何か、ホームAIサーバーにとって重要になるのはいつか？

継続バッチ処理は、各デコード反復でアクティブなシーケンスをスケジュールし、固定バッチを待たずに新しいリクエストの参加と完了したリクエストの離脱を可能にします。

家庭内では、数秒のうちに音声リクエスト、文書に関する質問、コーディングプロンプトを1つのローカルモデルに送ることがあります。プロンプトと出力の長さはそれぞれ異なるため、固定バッチではスロットが無駄になり、短い応答は最も長い応答を待つことになります。継続バッチ処理は、モデルを中心に有用な処理を再構成し続けますが、その効果があるのはリクエストが重なり、サーバーに十分なメモリとスケジューリングの余裕がある場合に限られます。

反復レベルのスケジューリングが決定的な考え方

自己回帰デコードでは、各アクティブシーケンスがモデルの1回の反復ごとに、およそ1トークンずつ進みます。継続スケジューラーは次の反復で実行可能なシーケンスを選択し、容量が空いたら新しいリクエストを受け入れ、完了したシーケンスを直ちに取り除きます。

Orca論文は、リクエスト全体ではなくモデルの反復単位での反復レベルのスケジューリングを提案しました。その後、選択的バッチ処理によって互換性のある操作をまとめながら、リクエスト固有の処理は分離します。この違いは、後の家庭内テストでも確認できます。

これは、ユーザーへのトークンのストリーミング配信と同じではありません。ストリーミングは出力を届けるタイミングを変えますが、継続バッチ処理は複数のリクエストがモデルの実行を内部でどのように共有するかを変えます。自動化が続行される前に、中間結果を検査できる状態にしておく必要があります。

静的バッチ処理や到着ウィンドウ方式のバッチ処理との違い

静的バッチ処理では固定されたグループをまとめて処理するため、短いシーケンスは最も長いシーケンスが完了するまでパディングされることがよくあります。到着ウィンドウ方式や動的バッチ処理では、リクエストを短時間集めるために待機しますが、生成されたグループを1つの単位として実行する場合があります。継続バッチ処理では、反復ごとにメンバー構成を見直します。

vLLM論文は、反復レベルのスケジューリングとページ化KVキャッシュ管理を組み合わせ、変化するシーケンス集合でも厳格な連続予約を必要としないようにしています。スケジューリングとメモリ管理は、相互に補完するものであり、置き換え可能な機能ではありません。この境界は、現実的な運用条件で個別に測定すべきです。

アクティブなシーケンスが増えると、重みの読み出しを分散でき、スループットが向上する可能性があります。しかし、各リクエストはKVメモリと計算資源を奪い合います。稼働中のバッチが大きければ、レイテンシや公平性が自動的に向上するわけではありません。限られたコンテキストを複数のソースが奪い合うと、この実際的な影響が現れます。

メリットを生むのはモデルサイズだけでなく同時実行性

対話型のユーザーが1人だけの場合、未使用の容量を埋める2つ目のリクエストがないため、得られる効果は小さい可能性があります。複数の家庭内ユーザー、エージェントの分岐、バックグラウンド要約、または常駐モデルを共有する複数のアプリケーションが重なると、効果が現れます。

Sarathi-Serveは、プリフィル干渉がデコードレイテンシを乱す可能性を分析し、混合スケジューリングをより予測しやすくするためにチャンク化プリフィルを使用します。この結果は、継続バッチ処理という名称だけでなく、受付ポリシーも重要であることを示しています。この依存関係は、最終的なインターフェースでも明示しておくべきです。

限界点は、メモリ圧迫や過度な受付によって出力トークンあたりの処理時間とテールレイテンシが膨らむことです。KVキャッシュが満杯になると、プリエンプション、スワップ、再計算によってスループットの向上が失われ、対話型サービスが不安定になる可能性があります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

同時実行需要がそれを正当化するか判断する

現実的なプロンプトと出力の長さで、重なり合うリクエストを1件、2件、4件、8件再生します。スループット、初回トークンまでの時間、出力トークンあたりの時間、完了時間のp95、KV使用率、プリエンプション、リクエストクラスごとの公平性を記録します。

バッチ処理中のGPU使用率のギャップがある状態での動作と比較します。モデル、量子化、コンテキスト制限、ハードウェアを一定に保ったまま、継続バッチ処理を無効にした場合、または固定バッチをベースラインとした場合でも繰り返し測定します。したがって、結果は元の証拠と照合する必要があります。

重なりによって、対話型サービスのテールレイテンシを損なわずにスループットや容量が大幅に向上する場合は、継続バッチ処理を使用します。リクエストがほとんど重ならない場合は、スケジューラーを複雑化する前に、モデルの常駐性と起動レイテンシを優先します。この違いは、後の家庭内テストでも確認できます。