バッチサイズは最初のトークンのレイテンシとトークンごとのレイテンシにどのような影響を与えるか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does Batch Size Affect First-Token and Per-Token Latency? - Zima Store Online

より大きなバッチは、合計トークンスループットを向上させることが多い一方で、キューイング、より負荷の大きい反復処理、メモリ圧迫によって、最初のトークンまでの遅延やトークン単位のレイテンシを増加させる可能性があります。

バッチサイズが1のローカルモデルでは、各デコードステップでごくわずかな処理のためにモデルの重みを移動させるため、アクセラレーターを十分に活用できない場合があります。リクエストをまとめることで、その移動を分散し、スループットを向上させられます。ただし、リクエストは受付を待つことがあり、長いプリフィルによってデコードがブロックされる場合もあります。また、アクティブなシーケンスが増えるたびにKVキャッシュとトークン処理が増加するため、最適なバッチは、スループット、応答性、レイテンシ目標内での有効処理量のどれを重視するかによって異なります。

バッチ処理はリクエスト間でモデル処理を分散させる

バッチ化された行列演算では、複数のシーケンスのトークンをまとめて処理するため、ハードウェアの使用効率が向上し、固定的な起動コストや重み転送コストを、より多くの有効な処理に分散できます。処理能力、メモリ帯域幅、キャッシュ容量、スケジューリングのオーバーヘッドのいずれかが飽和する前に、最も大きな効果が得られます。

Orcaの反復レベルスケジューリングでは、反復レベルのスケジューリングを導入し、デコード反復の間に完了したシーケンスを離脱させ、新しい処理を参加させます。これにより、静的なバッチの最も長いメンバーが終わるまで、すべてのリクエストを待機させる必要がなくなります。

バッチサイズは、設定された最大値、受け入れられたシーケンス数、または1回の反復で処理されるトークン数を指す場合があります。連続バッチ処理ではこれらの値が異なるため、性能レポートでは、どの数量を制御し、観測したのかを明記する必要があります。この違いは、後の家庭環境でのテストでも確認できます。

最初のトークンまでのレイテンシにはキューイングとプリフィルが含まれる

最初のトークンまでの時間は、リクエストが到着した時点から始まり、スケジューラーでの待機、プロンプトのプリフィル、最初のデコードステップを含みます。バッチの構築を待つポリシーではキュー時間が増加する可能性があり、大きなプロンプトを受け入れると、1回の反復を占有して既存のインタラクティブなリクエストを遅延させる場合があります。

現在の連続バッチ処理の比較では、連続バッチ処理がリクエストを動的に受け入れたり削除したりする仕組みと、積極的なスケジューリングがスループットとTTFTのバランスに与える影響について説明されています。これにより、バッチサイズだけでは最初のトークンへの応答性を予測できない理由が明確になります。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

チャンク化されたプリフィルでは、長いプロンプトとデコード処理を交互に実行できますが、チャンクサイズが新たなトレードオフになります。小さなチャンクはインタラクティブなトークンを保護する一方で、スケジューリングのオーバーヘッドを増やします。大きなチャンクはプリフィル効率を高めますが、より長いブロック間隔を生み出します。この境界は、現実的な運用条件で個別に測定する必要があります。

トークン単位のレイテンシは実行中の反復に左右される

デコード中は、通常、1回のステップでアクティブな各シーケンスについて1トークンが生成されます。シーケンス数が増えるとバッチが大きくなり、合計トークン毎秒が向上する一方で、各反復の所要時間が増加する可能性があります。コンテキスト長の不均一性、キャッシュ圧迫、プリエンプション、分散同期によって、ばらつきも生じます。

DistServeのプリフィルとデコードの分離では、計算特性とサービス目標が異なることから、プリフィルとデコードを分離します。この設計は、合計スループットの最適化が、TTFTおよび出力トークンあたりの時間と両立しない場合がある理由を示しています。複数のソースが限られたコンテキストを奪い合うと、その実際の影響が現れます。

失敗の境界は、オフラインのスループットグラフから最大のバッチを選び、インタラクティブなホームアシスタントに適用することです。キューイングやトークン間隔がユーザー向けの目標に違反する場合、アクセラレーターの使用率が高くても、公称スループットは利用可能な有効処理量とはみなせません。

Featured

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

ZimaCube2

バッチの有効処理量のフロンティアを把握する

短いチャット、長いRAGプロンプト、バックグラウンドジョブを、到着率を制御して再生します。最大シーケンス数とバッチトークン上限を変化させながら、TTFTのパーセンタイル、トークン間レイテンシ、エンドツーエンドレイテンシ、プロンプトおよび出力のスループット、キューの深さ、キャッシュ使用量、プリエンプション、拒否されたリクエストを測定します。

連続バッチ処理の動作を利用して、設定上の上限と各反復で実際に確認されたライブバッチを区別します。プロンプトと出力の分布を固定し、最初のトークンとトークン間隔の両方の目標を満たしたリクエストの割合を報告します。

1秒あたりの生のトークン数ではなく、これらの目標の範囲内で完了できる処理量を最大化する設定を選択します。バックグラウンドのバッチによってインタラクティブな有効処理量が低下する場合は、それらを分離または優先度を下げ、モデル、量子化、コンテキスト構成、スケジューラーを変更した後に再テストします。