ホームAIのバッチ処理は、レイテンシーとスループットをどのようにトレードオフするのか？

ホームAIのバッチ処理は、互換性のある処理を組み合わせることで全体のスループットを向上させます。ただし、各リクエストの待ち時間が長くなったり、他のユーザーと共有することで反復処理が遅くなったりする場合があります。

単一のプロンプトなら、アイドル状態のアクセラレーターにすぐ投入できます。一方、家庭用サーバーには、チャット、ドキュメントへのプロンプト、音声リクエスト、バックグラウンドジョブが重なって届くことがよくあります。ランタイムは、バッチを形成するためにリクエストを一時的に保持したり、デコード反復の合間に新しいシーケンスを追加したり、長いプレフィルを小さなチャンクに分割したりします。これらの選択によりアクセラレーターの稼働率は高まりますが、初回トークンまでの時間、トークン間の遅延、公平性も変化します。以下では、バッチ処理が役立つ場面と、スループットの向上がインタラクティブな体験の改善につながらなくなる場面を説明します。

バッチ処理は余ったアクセラレーター容量を共有処理に変える

1件のリクエストでは、特に小規模な行列演算や短いシーケンスの処理時に、すべての並列実行レーンを効率よく使い切れないことがあります。複数のリクエストを組み合わせると、より大きなテンソル演算を生成でき、アクセラレーターをより効果的に活用できます。

Orcaは反復レベルのスケジューリングを導入しました。これにより、すべてのシーケンスが完了するまで1つの固定バッチを維持するのではなく、生成反復の合間にリクエストを参加・離脱させられます。

向上効果は、単位時間あたりに完了したトークン数やリクエスト数で測定されます。これは、特定のユーザーがより早くトークンを受け取れることを保証するものではありません。

バッチウィンドウは計算開始前にキュー待ち時間を加える

より多くのリクエストを待つランタイムは、より大きく効率的なバッチを構築できます。しかし、アクセラレーターが利用可能な状態でも、最初のリクエストはその待ち時間を負担します。

スループットとレイテンシのトレードオフは、より大きなバッチによってデバイス効率が向上する一方、キュー待ち時間や反復時間が長くなると明確に現れます。

インタラクティブなホームAIでは、短い、または適応型のバッチウィンドウが通常適しています。バックグラウンドでの埋め込み生成は、会話形式の応答ではなく処理の完了が目的であるため、より長い待ち時間にも耐えられます。

長いプレフィルは短いデコード処理を停止させることがある

プロンプト処理では計算負荷の大きいプレフィルが実行されます。一方、進行中の会話では、メモリ帯域幅に制約されるデコードステップが繰り返し実行されます。これらを1つのバッチに混在させると、短いインタラクティブなデコード処理が長いドキュメントプロンプトの後ろで待たされることがあります。

DistServeは、プレフィルとデコードの干渉を分離します。これは、両フェーズで必要なリソースとレイテンシ特性が異なるためです。

チャンク化プレフィルは妥協案です。長いプロンプトを分割することで、チャンク間にデコードリクエストを実行できますが、ドキュメントの処理完了までにより多くのスケジューリングラウンドが必要になります。

最適な設定は、サーバーが1件の長い分析ジョブを優先するのか、それともストリーミング中の回答をすでに受け取っている複数ユーザーを優先するのかによって異なります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

シーケンス長が混在すると、すべてのバッチが不均一になる

リクエストごとに、プロンプトの長さ、出力の長さ、停止条件、モデル機能が異なります。すぐに完了するものがある一方で、処理を続けるものもあるため、バッチの構成は常に変化します。

vLLMは、ページ化されたKVキャッシュを使用する連続バッチ処理を採用しています。これにより、固定されたバッチ境界を待つのではなく、容量が利用可能になった時点で新しいリクエストを受け入れられます。

効率的なメモリ管理を行っていても、非常に長い応答は、多数の反復にわたってデコードスロットとKVキャッシュを消費します。そのため、バッチサイズはリクエスト数だけでなく、トークン数とメモリの予算で表すべきです。

より大きなバッチは、ユーザーごとのトークンレートを低下させることがある

1秒あたりの総トークン数が増えても、各ユーザーが受け取るデコード反復の割合は小さくなる可能性があります。集計スループットが高くなったダッシュボードの表示と、目に見えるストリーミングの遅延増加は両立します。

ZimaSpaceの家族内同時実行ガイドでは、1ユーザーのベンチマークから、複数の会話が重なった場合のレイテンシを予測できない理由を説明しています。

集計スループットと併せて、初回トークンまでの時間、トークン間の時間、リクエストごとの完了時間を測定してください。そうしなければ、ユーザーが直接体験することのない指標に合わせてバッチ処理を調整することになります。

インタラクティブ処理とバックグラウンド処理で異なるバッチポリシーを設定する

音声やチャットには、短いキューウィンドウ、同時実行数の制限、高い優先度を割り当てます。埋め込み生成、インデックス作成、要約、オフライン変換には、より大きなバッチと低い優先度を設定します。

公平なLLMサービングに関する研究では、トークンを考慮した公平性を採用し、1件のリクエストによる長い入力や出力が、過度な割合を無期限に占有しないようにしています。

最大バッチサイズだけでなく、実際の家庭内負荷を想定してテストしてください。有用な設定とは、インタラクティブな処理経路で求められる初回トークン時間とストリーミングレイテンシの目標を満たしながら、最高のスループットを実現する設定です。

1台のアクセラレーターで両方の処理クラスを満たせない場合は、1つの万能なバッチポリシーを採用するよりも、ワーカーやスケジュールを分けるほうが簡単なことがあります。

FAQ

バッチ処理を行うと、必ずレイテンシは増加しますか？

いいえ。効率的なバッチ処理によって、キュー全体の処理完了までの時間が短縮され、過負荷を防げる場合があります。ただし、バッチ形成のための待ち時間や、より長い反復処理の共有によって、個々のリクエストのレイテンシが増加することもあります。

バッチサイズはユーザー数のことですか？

正確には異なります。ランタイムは、アクティブなシーケンス数、トークン数、KVブロック数、総処理量などを基準に予算を設定する場合があります。また、1人のユーザーが複数のリクエストを同時に生成することもあります。

音声リクエストを埋め込み生成と同じバッチにすべきですか？

通常は、同じレイテンシポリシーの下で処理すべきではありません。音声はインタラクティブな処理である一方、埋め込み生成ジョブは待機でき、余剰容量があるときに大きなバッチで実行できます。