連続バッチ処理における非同期性の解放

[記事一覧に戻る](https://huggingface.co/blog) - 同期バッチ処理 - 並行性の作成 CUDA ストリームとは何か？ - デフォルトストリームと非デフォルトストリーム - 連続バッチ処理へ戻る - 同期の強制 CUDA イベントとは何か？ - 連続バッチ処理におけるイベントの使用 - 隙間の埋め込み ラスコンディション（競合状態） - 引き継ぎ - 完全な非同期ループ - 実際に機能するのか？ - 結論 *TL;DR: CPU と GPU のワークロードを分離することで、推論における劇的なパフォーマンス向上を実現する方法を解説します。* これは効率的な大規模言語モデル（LLM）推論に関するシリーズの第 2 弾です。[初回記事](https://huggingface.co/blog/continuous_batching)では、連続バッチ処理を基礎から解説しました。そこでは、KV キャッシュ、FlashAttention、アテンションマスクなどの概念を紹介し、本稿でそれらに基づいて構築していきます。 H200 の利用料は [Inference Endpoints](https://endpoints.huggingface.co/) で時間あたり約 5 ドルです。1 時間なら安価ですが、1 日使用するとすでに 120 ドルになります。この場合、GPU を最大限活用したいものです。**私たちは、Continuous Batching（連続バッチ処理）が、パディングに計算リソースを割くことなく密にバッチをスケジューリングすることで GPU の利用率を向上させることを確認しています。しかし、Continuous Batching が解決していない廃棄の第二の原因があります：デフォルトでは同期型であることです。これは CPU と GPU が交代で動作することを意味します。GPU が計算している間、CPU は待機し、CPU が次のバッチの準備をしている間、GPU は待機します。1 秒間に数百ステップを実行するループにおいて、これらのアイドル状態のギャップは蓄積され、後ほど示す通り、総実行時間のほぼ 4 分の 1 を占める可能性があります。GPU に 100% の時間計算を行わせるためには、これらのギャップを排除する必要があります。** これを実現するために、非同期バッチ処理（asynchronous batching）を使用できます：CPU によるバッチ準備と GPU によるバッチ計算を分離し、両者を並列で実行することで、常に生産的な GPU を維持します 🔥 ## 同期型バッチ処理 これは、単純な同期型バッチ処理の動作方法です： CPU が新しいバッチを準備する際、どのリクエストを含めるかを選択し、KV キャッシュテーブルを更新し、前回の実行で完了したリクエストを退去させ、空いたスペースを埋めるために新しいリクエストを受け入れます。これが完了すると、準備された入力データを GPU に転送します。GPU は順方向パスを実行し、各リクエストに対して新しいトークンをサンプリング（つまり選択）します。結果が CPU に戻され、CPU は各リクエストが直前に生成したトークンを知り、その後、このサイクルは再び繰り返されます。 右側の赤い注釈に注目してください：GPU が計算を終えた後、アイドル状態になります。次のバッチは、CPU が更新ステップ（出力トークンのサンプリング、リクエスト状態の更新、バッチの再スケジューリング）を完了するまで開始できません。 これが同期バッチ処理における核心的な非効率性です：CPU と GPU は交代で動作します。GPU が計算している間、CPU はアイドル状態です。CPU が更新を行っている間、GPU はアイドル状態です。いかなる状況においても、両者が同時に有用な作業を行うことはありません。単一の順方向パスにおいてはこれが小さな代償に思えるかもしれませんが、1 秒間に数百ステップを実行する連続バッチ処理ループでは、これらのアイドルの隙間が蓄積され、実際のスループット損失へと繋がります。 これを示すために、8B モデルを使用してバッチサイズ 32 で 8K トークンを生成する際の CPU と GPU に費やされる時間をプロファイリングしました： *同じようなグラフを生成したい場合は、連続バッチ処理コードにインストゥルメントを追加して CPU および GPU のアクティビティスパンをダンプし、[このスクリプト](https://gist.github.com/remi-or/8de44738629c4d3c72451aa01df1a2ab)を使用してください。* タイムラインは緑（GPU アクティブ、CPU アイドル）と赤（CPU アクティブ、GPU アイドル）が交互に現れる構造になっており、両者が重なることはありません。総生成時間は 300.6 秒で、そのうち GPU がアイドル状態になり CPU の完了を待っている時間が全体の 24.0% を占めています。GPU の視点から見れば、生成時間のほぼ 4 分の 1 が無駄になっています。これは悲観的な見方です。 楽観的な見方をすれば、CPU オーバーヘッドを完全に排除できれば、生成時間は 300 秒から 228 秒に短縮され（無料で 24% の高速化が可能！）ます。これには新しいカーネルやモデルの変更は不要で、ハードウェアの慎重な調整だけで実現できます。 根本的な考え方は単純です：バッチ N が計算を行っている間に、バッチ N+1 のバッチ準備をどのように実行するかを考えればよいのです。しかし、このシンプルなアイデアの背後にはいくつかの技術的課題が隠されています： - GPU で何かを実行し、制御権を CPU に返すにはどうすればよいか？ - 各タスクが起動する時点で、CPU または GPU のタスクに必要なデータが確実に準備されているようにするにはどうすればよいか？ - バッチ N+1 がバッチ N の予測結果に基づいている場合、どのようにしてバッチ N+1 を準備できるのか？ これらの質問に答えることで、非同期バッチ処理をゼロから構築していきます。この実装は、[transformers](https://github.com/huggingface/transformers) ライブラリにおける連続バッチ処理の一部として行った手順と同じです。コードを確認して比較することもお気軽に行ってください。 ## 並行性の作成 私たちの最終目標は、CPU と GPU の操作を**並行して**実行することです。どの操作が並列実行可能かを機械に伝えるために、操作を分類する方法が必要です。これを実現するには CUDA ストリーム（CUDA stream）を使用します。 ## CUDA ストリームとは何か？ CUDA がその操作をどのように順序付けるかを理解するためには、**CUDA ストリーム**について話す必要があります。ストリームは、GPU 操作（カーネル起動、メモリコピー、同期バリアなど）の順序付きキューであり、提出された順に実行されます。すべての GPU 操作は常に何らかのストリーム内でスケジュールされます。同じストリーム内の操作は逐次的です：GPU は前の操作が完了するまで次の操作を開始しません。一方、*異なる*ストリーム内の操作は互いに独立しており、並行して実行できます。具体例として、3 つの異なるストリームに 3 つの操作を起動した場合の実行順序は以下のようになります： 3 つの操作はすべて同時に開始されます。これは若干の簡略化です：すべての GPU 操作は最終的に CPU によって開始され、その開始にはわずかな時間がかかります。適切なカーネルの特定、呼び出しの実行、コマンドを CPU から GPU へ転送するなどの処理です。これを**CPU ランチオーバーヘッド**と呼びます。より現実的な図は以下のようになります。 操作自体は並行して実行されますが、各 CPU ランチのコストによって開始時刻がずれます。これらの CPU ランチイベントは実際の時間を要するため、非同期ワークフローに移行する際に「いつ何が開始されたか」を追跡するために引き続き示していきます。例えば、ストリームが**フラッシュ**されているかどうかを頻繁に確認します。これは、ストリーム内のすべての操作が実行済みであることを意味します。 ## デフォルトおよび非デフォルトストリーム PyTorch で CUDA ストリームを明示的に使用したことがない場合、その存在自体に驚くかもしれません。典型的な PyTorch スクリプトではこれらに触れられることはなく、GPU 操作が非同期であるという感覚もありません。CPU は GPU の完了を待ってから次に進むように見えます。この感覚は正確であり、**デフォルトストリーム**に由来するものです。 PyTorch の操作をストリームを指定せずに呼び出すと、それはデフォルトストリームに割り当てられます。デフォルトストリームには 1 つの特別な性質があります：それは**同期型**であることです。デフォルトストリーム上にスケジュールされた操作は、**すべての他のストリームがフラッシュされるまで待機**します。つまり、GPU 上のすべての作業が完了する前に、デフォルトストリームの単一の操作を開始することはできません。逆もまた真です：どのストリームに属する操作であっても、その起動前にデフォルトストリームのフラッシュを待つ必要があります。 したがって、デフォルトストリームの操作の結果を CPU に転送する場合でも、CPU に対して非ブロッキングであるはずの転送であっても、CPU はすべての GPU 操作が完了するまでブロックされます。これは、操作がデフォルトストリームにスケジュールされたためです。これにより、並行性を構築しようとするあらゆる努力は実質的に無効化されてしまいます。 そのため、デフォルトではないストリームを使用する必要があります。カーネル起動や非ブロッキングメモリコピーをキューに入れると、即座に CPU への制御が返されます。GPU はバックグラウンドで操作を実行しますが、CPU は待機しません。これが最初の質問に対する答えです：GPU 作業の起動後に CPU の制御を取り戻すには、デフォルトではないストリームを使用します。 この投稿の後半では、1 つのデバイスからもう一方へのすべてのメモリ転送が非ブロッキングであると仮定します。したがって、それらを我们自己で同期化する必要があります。 ## 連続バッチ処理に戻る GPU 上のどの操作もデフォルトストリームに配置してはならないことを確認しました。しかし、疑問が残ります：デフォルトストリームを使用しない場合、どのようなストリームを使用すべきでしょうか？同期バッチ処理の図を振り返りましょう。 GPU 上で実行される 3 つの明確な操作を特定できます。 - CPU から GPU への入力転送 - GPU 上での計算 - GPU から CPU への出力転送 これは、計算用ストリーム、CPU から GPU への転送用ストリーム、GPU から CPU への転送用ストリームの 3 つが必要であることを意味します。転送は独立して行われるため、それらを直列化する理由はなく、それぞれが独自のストリームを持ちます。 **用語に関する注記：CPU と GPU を語る際、CUDA ドキュメント全体で使用されている慣習では、CPU をホスト**、GPU を**デバイス**と呼びます。これ以降もこの慣習に従います。CPU から GPU への転送は**ホストからデバイス**（H2D）転送と呼ばれ、GPU から CPU への転送は**デバイスからホスト**（D2H）転送と呼ばれます。したがって、3 つのストリームとは、H2D ストリーム、計算用ストリーム、および D2H ストリームです。 次に、ストリームを使用して GPU でバッチ処理を非同期に起動し、CPU 制御に戻す方法を試してみましょう。CPU 側では以下の手順を実行します。 - CPU 上でバッチ入力データを準備する（ストリームなし、CPU のみの操作） - H2D ストリームを使用して GPU に転送する - 計算用ストリームを使用して GPU で計算を実行する - D2H ストリームを使用してバッチ出力を取得する - 結果を確認する（ストリームなし） もしこれを CUDA ストリームのみを使用して行うと、結果はほぼ即座に取得可能になりますが、その内容は誤りとなります。なぜそうなるのかを理解するために、何が起きたかを振り返ってみましょう。 ストリームは互いに独立しているため、3 つの GPU 操作はほぼ同時に起動されました。計算ストリームは H2D（ホストからデバイスへの）転送が完了するのを待たなかったため、フォワードパスはすでに GPU メモリに存在していたデータに対して実行されました。また、D2H（デバイスからホストへの）ストリームも計算の完了を待たなかったため、まだ計算されていない結果が転送されてしまいました。ステップ 5 は即座に返却されました。これは CPU をブロックするものが何もないためです。同期対象となるデフォルト・ストリームが存在しませんでした。 各操作は単独では正しく実行されています。問題は、ストリーム同士が互いを待機するように指示していなかった点にあります。計算は H2D 転送の完了後に開始され、D2H は計算の完了後に開始されるべきことは分かっていますが、その順序を強制していませんでした。ストリームの境界を超えて「あの操作が完了するまで、この操作を開始しないように」と指示するためのメカニズムが必要です。 ## 同期の強制 ストリーム間の同期を強制するために、**CUDA イベント**を使用します。 ## CUDA イベントとは何か？ CUDA イベントは、ストリームに記録できるマーカーです。GPU が実行中にそのマーカーに到達すると、イベントを完了状態として設定します。その後、他のストリームに対して、次の操作を開始する前にそのイベントの完了を待つように指示することができます。具体的には、2 つの操作があります：stream.record(event) は現在の位置にストリーム内にマーカーを挿入するものであり、stream.wait(event) はイベントが完了としてマークされるまでストリームの進行をブロックするものです。重要なのは、wait がブロックするのは *ストリーム* であり、CPU や並行して実行されている他のストリームではないということです：CPU の呼び出しは即座に返り、待機中のストリームのみが遅延します。 上記の図は、1 つのイベントが 2 つのストリームを同期化している様子を示しています。CPU は 3 つの操作を連続して発行します（3 つの小さなブロック）：ストリーム 1 で入力準備の起動、ストリーム 1 でのイベント記録、そしてストリーム 2 にその完了を待つように指示です。その後、CPU は即座に処理を続行します。ストリーム 1 が操作を実行し、完了するとイベントが設定されます。ストリーム 2 は待機マーカーの位置で常に停止しており、イベントが完了としてマークされた時点で計算を開始します。この一連の動作には CPU は関与していません：順序付けは完全に GPU 側で強制されました。 ## Continuous Batching におけるイベントの使用 私たちのケースに適用すると、この修正は非常に単純です。H2D（ホストからデバイス）転送をキューに追加した後、h2d_stream.record(h2d_done) を呼び出します。これにより、転送が完了した時点でイベントが完了済みとしてマークされます。順次実行フェーズ（フォワードパス）をキューに追加する前に compute_stream.wait(h2d_done) を呼び出すため、compute ストリームは h2d_done がセットされるまで開始されません。同様の処理を compute と D2H（デバイスからホスト）の間でも行います。model.forward によってフォワードパスを開始した後、compute_stream.record(compute_done) を呼び出し、出力転送をキューに追加する前に d2h_stream.wait(compute_done) を実行します。 その結果、明確な順序付けが保証されたパイプラインが構築されます： - H2D 転送は h2d_stream で実行される - compute_stream は h2d_done の完了を待ってからフォワードパスを実行する - d2h_stream は compute_done の完了を待ってから出力を転送する CPU はこれら一連の処理を順にキューに追加し、その後次の処理へ移ります。どの時点でも CPU がブロックすることはありません。GPU はイベントを通じて順序付けを強制し、依存関係が満たされ次第、3 つのストリームすべてが即座にアクティブになります。 上記の図は、このプロセスがどのように進行するかを示しています。CPU はバッチを準備した後、GPU へのすべての作業（H2D 転送、順方向パス、D2H 転送）をすばやくキューに追加します。各ステージの間には記録と待機呼び出しが挿入されます。その後、CPU は解放され、GPU が引き継いで、依存イベントが設定される順序で各ストリームを実行します。右側の緑色の注釈にご注意ください：D2H 転送が完了すると、CPU が戻ってきて結果を読み取ります。この最終的な同期は、全体のステップにおいて CPU がブロックする唯一の地点です。これを実現するために、出力転送後に D2H ストリーム上で 3 つ目のイベントを記録し、CPU 側で d2h_done_event.synchronize() を呼び出します。synchronize は、D2H ストリームがそのマーカーに到達するまで CPU をブロックします。 これは同期バッチングとの決定的な違いです：以前は CPU がすべての操作の後にブロックしていましたが、今では GPU が動作している間に「何か」を行うことができます。**この「何か」を特定する必要があります。なぜなら、現状では GPU の利用率の観点からは何も変化していないからです。** ## 空白を埋める CPU が利用可能な期間は、バッチ N を GPU にディスパッチしてからバッチ N+1 を GPU にディスパッチするまでの間です。その自然な用途は、バッチ N+1 の入力を準備することであり、それらを GPU にディスパッチして、バッチ N の計算が終了した時点で利用可能にしておくことです。では、どのようにこれを実現できるかを見ていきましょう。 バッチ N+1 の準備には、バッチ N を準備するために使用した同じ CPU 側のオブジェクト（現在のリクエストのリスト、キャッシュの状態、ホスト側のテンソルバッファなど）を再利用できます。ただし、2 つの点に注意する必要があります。 - データ破損：バッチ N+1 のデバイス側入力バッファは、バッチ N と同じにしてはいけません。GPU がまだ読み込んでいるデータを破損してしまうからです。 - データ転送：リクエストがバッチ N とバッチ N+1 の両方に含まれており、そのリクエストがバッチ N の出力で新しいトークンを生成する場合、そのトークンはバッチ N+1 の入力として必要になります。 これらの問題（データ破損とデータ転送）については、次の 2 つのセクションで取り扱います。 ## レース条件 まず、潜在的なデータ破損の問題に取り組みます。バッチ N とバッチ N+1 が同じデバイス側入力バッファを共有しており、かつバッチ N の計算がまだ完了していない間にバッチ N+1 の入力に対する H2D（ホストからデバイスへの）転送が始まったと想像してください。CPU は GPU が同じメモリからバッチ N を読み込んでいる最中にバッチ N+1 の入力を書き込む可能性があります。その結果、GPU は部分的に上書きされたデータを取得してしまい、結果が破損します。これがレース条件です。**ホスト側にも同様のリスクが存在します：バッチ N に対する H2D コピーがまだ進行中である間にコピー元のソースを再利用すると、転送自体が破損します**。 解決策は、2 つのテンソルセットを使用し、それらを交互に切り替えることです。GPU がスロット A からバッチ N を処理している間、CPU はバッチ N-1 の結果を用いてリクエストの状態を更新します。次に CPU は入力スロット B でバッチ N+1 の準備を行います。次のステップで、これらを入れ替えます。これは以下の図に示されています： もちろん、これにはコストが伴います：入出力テンソルを保存するために使用される RAM と VRAM の量が 2 倍になります。これは [FlashAttention](https://github.com/Dao-AILab/flash-attention) を使用する際に特に許容できるトレードオフです。なぜなら、FlashAttention は注意マスク（アテンションマスク）を必要としないためで、これが現在までに存在する最大の入力テンソルだからです。 しかし、2 つのスロットがあることは別の問題も生み出します。推論では通常、レイテンシを削減するために**CUDA グラフ**を使用します。要約すると、[CUDA グラフ](https://pytorch.org/blog/accelerating-pytorch-with-cuda-graphs/)とは、事前に記録された CUDA 演算のシーケンスです。これは特定のメモリアドレスに対して記録されます：スロット A 用にキャプチャされたグラフは、スロット B のバッファに対して再生することはできません。したがって、2 つのグラフが必要です。そして、各グラフが独自のメモリバッファを持つ場合、VRAM はさらに 2 倍になります。 解決策は**メモリプール**です。これは両方のグラフが割り当てる共有メモリーバッファであり、唯一の制約は同じプール内の 2 つのグラフが同時に実行されてはならないことです。バッチ N が完了するまでバッチ N+1 は開始できないため、この条件は常に満たされます。実際には、両方のグラフを合わせても 1 つのグラフと同じ程度の VRAM を使用します。初期化時に 2 回のキャプチャを行うコストのみが発生します。**同じプール内に任意の数の CUDA グラフを作成できても、総メモリ使用量はグラフ間の最大値に制限されたままです**。これは以下で示されています。 データ破損を防ぐ方法がわかったので、次にバッチ N の出力トークンをバッチ N+1 の入力として取り込むという 2 つ目の課題に取り組みます。 ## 継続（Carry-over） バッチ N とバッチ N+1 の両方に現れるリクエストを想定してください。バッチ N では新しいトークンが生成されます。そのトークンがバッチ N+1 における入力となります。問題は、バッチ N+1 の入力バッファを準備している時点では、まだそのトークンを保有していないことです。なぜならバッチ N はまだ実行中だからです。 これを解決するために、バッチ N+1 を構築する際にはプレースホルダートークンを使用します。後で理由が明らかになるため、プレースホルダーとして 0 を使用します。このプレースホルダーは、バッチ N の計算が完了し、バッチ N+1 が順伝播（フォワードパス）を開始する前に置き換えられます。このステップを**継続（carry-over）**と呼びます。これはバッチ N からバッチ N+1 へ新しいトークンを引き継ぐ操作だからです。継続の概念は以下に図示されています： キャリーオーバーを実行するには、バッチ N の出力トークン ID、バッチ N+1 の入力トークン ID、およびキャリーオーバーの実行方法を指示するテンソルの 3 つだけで十分です。このテンソルを**キャリーオーバーマスク**と呼びます。これは、キャリーオーバーが必要なトークンの宛先ターゲットと、不要なトークンには -1 を含んでいます。以下にその例を示します。 キャリーオーバー自体は以下の 4 つの操作から構成されます。 - バッチ N の出力からキャリーオーバーするトークンを新しいテンソル T に選択する - キャリーオーバーしたくないトークンを T でゼロ化する - T をバッチ N+1 の入力長に合わせて切り詰める - T をバッチ N+1 の入力 ID に加算する（そのためプレースホルダーの入力 ID は 0 という値を持つ） これら 4 つの操作は非常に軽量であるため、新しいバッチの開始時に実行し、CUDA グラフ内でキャリーオーバーを捕捉します。もしキャリーオーバーマスクに -1 のみが含まれている場合（-1 の値は：この位置はキャリーオーバーしないことを意味する）、最後のステップはゼロテンソルとの加算になります。これは頻繁には発生しません。なぜなら、複数のバッチにまたがるデコーディングリクエストは通常、連続したバッチでスケジューリングされるからです。 ## 完全な非同期ループ それではすべてを統合し、最初の 2 つのステップを追跡してみましょう。 ステップ 0 はコールドスタートです。前のバッチが実行されていないため、CPU がスロット A でバッチ 0 を準備し、同期バッチ処理の場合と同様にディスパッチします。まだオーバーラップは発生していません。 ステップ 1 は非同期ループが始まる箇所です。GPU は現在スロット A でバッチ 0 を実行中であり、CPU は空き状態です。CPU は直ちにスロット B でバッチ 1 の準備を開始します：完了したリクエストの退去、新規リクエストの受付、KV キャッシュルーティングテーブルの更新、継続マスクの構築などです。これらすべてが GPU と完全にオーバーラップして実行されます。バッチ 1 の入力が準備でき次第、CPU は作業を順次キューに追加します：スロット B に対する H2D（ホストからデバイスへ）転送を開始し、計算および D2H（デバイスからホストへ）ストリーム用のイベントを記録して待機し、その後次の処理へと進みます。 GPU 上では現在、2 つのことが並行して発生しています。スロット A では GPU が計算を終了し compute_done を設定することで、バッチ 0 の出力に対する D2H 転送が解放されます。一方、スロット B ではバッチ 1 の入力に対する H2D 転送が実行中です。これが完了すると h2d_done イベントが設定され、バッチ 1 の計算が開始されます。バッチ 0 からバッチ 1 への継続処理（carry-over）は、この計算の一部であり、通常のフォワードパスの前に発生します。スロット A とスロット B は独立しているため、これらすべての処理が自由にオーバーラップして実行されます。 一方、CPU はバッチ 0 の出力が到着するまで d2h_done_event.synchronize() でブロックされます。その後、出力を処理し、バッチ 0 に含まれていたすべてのリクエストの状態を更新して、バッチ 2 のスケジューリングを開始します。ループは現在実行中で、その後のすべてのステップがまさに同じパターンに従います。 以下の図で全体のワークロードを示します。各スロットには CPU および GPU の操作とイベント（これらもスロット固有です）に対して専用の色が割り当てられています。可読性の観点から、CPU による GPU 操作の起動（計算やデータ転送など）は表示していませんが、実際にはこれらの操作も行われています。これは、GPU 操作の起動にかかるレイテンシが示されている操作に比べて無視できるほど小さいためです。 バッチ N+1 の入力がバッチ N の完了時に GPU に準備されていれば、GPU はバッチ間でアイドル状態になることはありません。唯一の問題は、CPU が計算を完了する前に自身の作業を終了できるかどうかです。通常はその通りで、モデルの規模が拡大し続ける一方でバッチスケジューリングのコストは比較的安価なままなので、ボトルネックとなるのは GPU の計算であり、CPU ではありません。 ## 実際に機能するのか？ その答えを知るために、以前と同じ実験を行います：8K トークン、バッチサイズ 32、8B モデル。 タイムラインはほぼ完全に濃い緑色です：CPU と GPU が同時に動作しています。時々現れる薄い緑色のスライスは、GPU がアクティブだが CPU はすでに準備を終えて待機している瞬間を示しています。ほとんど見えない赤いマークはバッチ間の同期ポイントで、ここで CPU がブロックしてバッチ N の出力をサンプリングします。GPU の稼働率は総実行時間の 99.4% に達し、以前の 76.0% から向上しました。全体の生成時間は 300.6 秒から 234.5 秒に短縮され、22% の高速化が実現されました。CPU オーバーヘッドを完全に排除した場合の予測値は 24% でした。残りのわずかな差は避けられない同期ポイントによるものです。新しいカーネルもモデルの変更もありません：CPU と GPU が同時に作業できるようにしただけです。 結論として、当初は CPU と GPU が順次動作する同期型ワークロードであり、両者が十分に活用されていませんでした。スケジュールベースの依存関係からデータベースの依存関係へ移行し、同期ポイントを最適化することで、CPU と GPU のワークロードを分離することに成功しました。これにより、両ハードウェアの並列実行が可能となりました。その結果、GPU ワークキューを飽和状態にし、常に稼働させることが実現できました。これによってモデルの精度を維持したまま、生成速度が大幅に向上しました。ほぼ完璧な成果です。 完全な実装は [transformers](https://github.com/huggingface/transformers) ライブラリにあります。これが実際のコードにどのように変換されるかを確認したい場合は、連続バッチ処理の一般的なエントリーポイントは [continuous_batching.py](https://github.com/huggingface/transformers/blob/main/src/transformers/generation/continuous_batching/continuous_api.py) です。より非同期中心のコードは、[ContinuousBatchingAsyncIOs](https://github.com/huggingface/transformers/blob/5042bb7eb64b69efd351482a05b3803c48955cb4/src/transformers/generation/continuous_batching/input_outputs.py#L609) クラスに位置しています。 非同期バッチ処理は、強化学習における 16K+ のような長い生成長さに対して SOTA スループット（State-of-the-Art throughput）を解放するための一歩を踏み出します。しかし、その目標を達成するためには、他にもいくつかの小さな要素が必要です。次の記事では、リクエストのオフロード、デコード固有のカーネル、微細なコンパイルなどについて詳しく解説します。お楽しみに！ *謝辞：支援と洞察に富んだレビューを提供してくれた Pedro Cuenca 氏および Aritra Roy Gosthipaty 氏に心から感謝いたします。*

連続バッチ処理における非同期性の解放

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト