連続LLMバッチ処理中にGPU使用率のギャップが生じる原因は何ですか?

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

GPU使用率のギャップは通常、継続的バッチ処理のスケジューラーが実行可能な処理を組み立てられないか、依存関係による停止なしにアクセラレーターへ処理を供給できない場合に発生します。

ホームLLMサーバーでは高いスループットを報告しながら、デコード反復の間にGPU使用率が周期的に落ち込むことがあります。継続的バッチ処理は完了したシーケンスを削除して新しいシーケンスを受け入れますが、リクエストの到着がまばらな場合、KVブロックを利用できない場合、長いプリフィルがデコードをブロックする場合、またはCPUランタイムによるバッチ準備が遅すぎる場合には、処理を作り出せません。リクエストキューが満杯でも、同期処理やメモリ移動によってギャップが生じることがあります。

リクエスト供給とシーケンスの入れ替えによってバッチが空になることがある

継続的バッチ処理では、反復の境界で完了したシーケンスを置き換えます。リクエストの到着がバースト状であったり、出力が同時に完了したり、受け入れ制限によってリクエストが実行可能キューの外で待機したりすると、アクティブなトークン数がGPUの効率的な動作範囲を下回ることがあります。

継続的なバッチメンバーシップのベンチマークでは、入力長、出力長、到着時刻を変えながら、静的なリクエストメンバーシップと継続的なリクエストメンバーシップを比較しています。特徴として、アクセラレーターが正常に動作しメモリエラーもないにもかかわらず、使用率のギャップ中に実行可能なトークン数が少なくなります。

キューが本当に空であるなら、それはスケジューラーの欠陥ではありません。すべてのアイドル時間を失われた処理能力と解釈する前に、到着率、受け入れられたシーケンス数、反復ごとにスケジュールされたトークン数を比較してください。この違いは、後の家庭環境でのテストでも確認できます。

プリフィル、デコード、KV割り当てがスケジューラーの空白を生む

プリフィルでは多数のプロンプトトークンを計算負荷の高いカーネルで処理する一方、デコードでは各シーケンスを1トークンずつ進め、メモリ帯域幅がボトルネックになることがよくあります。両フェーズを混在させるとデコードが遅延する可能性があり、KVブロックの予約や回収によって反復間の受け入れが一時停止することもあります。

チャンク化プリフィルスケジューリングでは、長いプロンプトがサービス提供の反復を独占しないよう、チャンク化プリフィルを使用します。その仕組みにより、需要の弱さではなく、プリフィルの境界、KV割り当て、またはリクエストのプリエンプションと相関するギャップを特定できます。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

GPUのギャップがプロンプト長に応じて拡大し、出力長には左右されない場合は、プリフィルのスケジューリングがより有力な原因です。キャッシュの圧迫や追い出しに連動する場合は、キューが満杯でもメモリの受け入れ処理が原因です。この境界は、現実的な運用条件で個別に測定する必要があります。

CPUによる供給とデバイス間同期によってカーネルが枯渇することがある

トークン化、サンプリング、スケジューラーの判断、テンソルメタデータ、ホストからデバイスへのコピー、分散コレクティブ、ロギングは、メインカーネルの外部で実行されます。CPUスレッドの飽和やブロッキング同期によって、通常なら有効なバッチの間でGPUが待機することがあります。複数の処理が限られたコンテキストを奪い合うと、この影響が実際に現れます。

プリフィルとデコードの干渉に関する研究では、干渉を減らしてレイテンシー目標を達成するため、プリフィルとデコードのリソースを分離しています。この結果は、1つの使用率グラフがスケジューラー、ホスト、通信、アクセラレーターの動作を組み合わせて示していることを裏付けています。この依存関係は、最終的なインターフェースでも明示したままにする必要があります。

問題が現れる境界は、短いサンプリング間隔によって通常のカーネル境界が使用率ゼロとして報告される場合です。トレースまたはハードウェアカウンターでギャップを確認してください。ダッシュボードの平均化によって、1秒あたりのトークン数を低下させない見かけ上の谷が生じることがあります。

キュー、スケジューラー、カーネルのタイムラインを揃える

制御した定常到着とバースト到着を再現しながら、待機中、受け入れ済み、実行中のリクエスト、反復ごとのプロンプトトークン数とデコードトークン数、KVの空きブロック、プリエンプション、CPUスケジューラー時間、トークン化、サンプリング、コピー、コレクティブ、カーネル起動間のギャップ、GPUクロック、出力スループットを記録します。

継続的バッチ処理の動作とパターンを比較し、その後、到着率、プロンプト長、チャンク化プリフィルのサイズ、キャッシュ予算、CPUアフィニティを一度に1つずつ変更します。モデル、量子化、レイテンシー目標は維持してください。したがって、結果は元の証拠と照合する必要があります。

チューニング前に、それぞれの谷を需要なし、受け入れ停止、プリフィル干渉、キャッシュ圧迫、ホスト枯渇、同期処理のいずれかに分類します。原因となっている境界を最適化してください。より大きなバッチを強制しても、空のキューやブロックされたホストスレッドは解決できません。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.