← 概念辨析に戻る

Concept Contrast Fable

同じものに聞こえるが、開けてみると二つのスイッチだ

先に結論:連続バッチ処理と動的バッチ処理はほとんどのドキュメントで同じものとして扱われるが、具体的な実装では、スロットのエンキュー時期、解放戦略、バッチ内リクエストの削除可能性が異なる。誤って使うとレイテンシの変動やスロットの浪費を引き起こす。

連続バッチ処理と動的バッチ処理はほとんどのドキュメントで同じものとして扱われるが、具体的な実装では、スロットのエンキュー時期、解放戦略、バッチ内リクエストの削除可能性が異なる。誤って使うとレイテンシの変動やスロットの浪費を引き起こす。

寓話

二軒の麺屋はどちらも茹でたらすぐ出すが、槽の交換と碗の返却の規則が違う

町に二軒の湯麺屋があり、どちらも客の麺の注文を一つの鍋でまとめて茹でると言っていた。常連客は聞いて、どうせ何杯かまとめて茹でるのだから、火も水も人手も省けると、大差ないと思っていた。市場の日で客が路地の入り口まで並んだとき、二軒の違いが露わになった。

南館の竈は常に火が入っていた。最初の麺がまだ完全に鍋から出ないうちに、後厨は新しく来た小碗麺を空いた竹籠に詰め込んだ。客が早く食べれば竹籠が空き、次の一杯がすぐに補充された。鍋には常に麺が煮えており、竈の火は鍋が完全に空になるのを待たずに次の回を受け入れた。

北館も列の長さを見て鍋にまとめる。店主は十人の客が来たと見ると、十碗を一鍋にまとめ;次の客がゆっくり来れば、少なめにまとめて鍋を開ける。そのバッチ化は客の到着リズムで変わるが、各鍋は依然として一鍋ずつ起ち上がり、下がる。

ある外地の老板が視察に来て、両店とも「動的」と言うのを聞き、危うく契約を間違えそうになった。南館の師匠は竹籠を持ち上げて彼に見せた。ここの鍵は、鍋が実行時に絶えず補位し、古い麺と新しい麺が交錯して存在できることだ。北館の番頭は言った。私の鍵は、鍋を開ける前にその時の行列に合わせてバッチを組み、開けたらこのバッチで最後まで進むことだ。

その日の午後、急ぎの注文が来た。南館では竹籠が一つ空いたので、急ぎの注文をすぐ入れた。隣にまだ出ていない古い注文の碗がいくつかあったが。北館は現在の一鍋が出るまで待ってから、急ぎの注文を次の鍋に入れた。急ぎの注文はより長く待つが、各鍋の帳尻はより整っていた。

商会は後に登記冊を改めた。連続バッチ処理は実行中に継続的に補位し、スロットを生成終了に応じて段階的に解放することを強調する。動的組批はリクエスト到着状況に応じて臨時にバッチを組み、開批前にサイズを調整できることを強調する。二つの語には重なりがあるが、「開批前のバッチ組み」と「実行中の補位」を一つの事柄に混同してはならない。

それ以来、推論エンジンを買う人は必ず三つのことを尋ねる。新しいリクエストは実行中のキューに差し込めるか。完了したスロットはすぐに解放できるか。バッチサイズは開始前に決まるのか、実行中に変わり続けるのか。三つを聞き終えれば、誰がどの種類の竈を売っているかはっきりする。

後に外地の老板が二つの竈を買い戻して試運転し、帳簿が本当にものを言った。南館の方式は散発的な客流で空鍋が少なく、北館の方式は一括の出前でより会計しやすい。用語は近いが、適した商売は同じではない。

連続バッチ処理

推論サービスは稼働中に新しいリクエストを受け入れ続け、既存のリクエストが完了したらスロットを解放して新しいリクエストを補充し、オンラインサービスのスループットとリソース利用率を高める。ポイントは稼働中の継続的な補充にある。

動的バッチ処理(飛行バッチ処理)

リクエストの到着状況に応じて動的にバッチを構成し、スループットとレイテンシの間で折り合いをつけるためによく使われる。要点は現在のトラフィックに合わせてバッチを組むことで、具体的な実装は連続バッチ処理と重なる場合があり、スロットの解放と補充のセマンティクスを確認する必要がある。

物語の対応

  • 南館の竈は常に火が入り、絶えず補充される:continuous batching の実行中における継続的な補充
  • 北館はその時々の客の流れで一鍋をまとめる:dynamic batching のバッチ開始前の動的グルーピング
  • 急ぎの注文を稼働中のキューに差し込めるか:二つの実装を分ける鍵となる問い
  • 竹籠が空になったらすぐに新しい注文を入れるか:スロット解放戦略
  • 両社とも動的と言うが仕組みは異なる。サプライヤー用語は実装の詳細を問いただす必要がある
  • 三つの調達質問:抽象的な用語を検証可能な行動に落とし込む

推論エンジンの選定に落とし込む

推論エンジンを評価するときは、バッチ処理をサポートするかどうかだけを見てはいけない。具体的な意味を問いただすべきだ。新しいリクエストを実行中のキューに挿入できるか、完了したリクエストのスロットを即座に解放できるか、バッチサイズはバッチ開始前に決まるのか実行中に継続的に変化するのか。オンライン対話は通常、連続的な補位によるリソース利用率とテールレイテンシの挙動をより気にする。オフラインタスクは、バッチごとに揃えてから一括処理することをより受け入れやすい。ベンダーが dynamic や continuous をサポートすると言うなら、まずリクエストの進入、生成、解放、補位のタイミング図を描かせよ。

京ICP备2026014272号