← 概念辨析に戻る

Concept Contrast Fable

来たらすぐやると、十分に貯まってからやる

先に結論:連続バッチ処理はリクエスト到着時に動的にバッチを組み、リクエスト完了時にスロットを解放し、オンラインサービスの待ち遅延を下げることを狙う。バッチ推論は一群のリクエストを集めて一括処理し、より高い GPU 利用率でスループットを得ることを狙う。どちらもバッチ処理だが、一方はオンライン遅延に、他方はオフラインスループットに向き合う。

連続バッチ処理はリクエスト到着時に動的にバッチを組み、リクエスト完了時にスロットを解放し、オンラインサービスの待ち遅延を下げることを狙う。バッチ推論は一群のリクエストを集めて一括処理し、より高い GPU 利用率でスループットを得ることを狙う。どちらもバッチ処理だが、一方はオンライン遅延に、他方はオフラインスループットに向き合う。

寓話

二軒の麺屋、一軒は客が来たらすぐ茹で、一軒は揃うまで鍋に入れない

老城には二軒の麺屋があり、一筋の街を隔てていた。甲館の大竈は一度に八杯の麺を下せるが、老宋の規律は一杯来たら一杯下す——竈が空けば新しいのを補い、早く来た者が早く下され、食べ終わればすぐ出る。乙館の大竈も一度に八杯だが、老田の規律は八杯そろってから竈を開く——早く来た客は後の客を待ち、竈が開かなければ煮ない。

急ぐ運搬人は皆、甲館へ行く。一杯の麺を鍋に入れ、寝返りを打つほどの間に茹で上がって持ち帰れる。竈の八つの枠はいつも満杯に見える——古い碗が回され、新しい碗が補充される。運搬人たちはこれを、来るのが速く去るのも速い、竈は人を待たないと言う。乙館のほうでは、一人の運搬人が線香二本分ほど待っても、竈にはまだ三杯足りず数が揃わない。老田は焦らず、八杯揃ってこそ最初の鍋の味が正しいと言う。

しかし別の種類の客は乙館の方が割安だった。東家たちが宴会を開き、一度に四十碗の麺を注文する。乙館の大竈は五回に分け、各回八碗を一緒に鍋に入れ、竈の火の利用率が高く、老田は一度に大卓分を出せた。甲館の一碗ずつ別煮では、何碗目でも竈には常に出入りがあるが、四十碗の麺は途切れ途切れに一時間待たされた——前の人が食べ終わってから次の人が座るため、竈のいくつかの格子がゆっくり食べる客に占められていたからだ。

老宋と老田は商会に呼ばれて討論した。老宋は、自分の竈はいつでも仕事をしており、竈が空いて客を待つことはないと言った。老田は、自分の竈は毎回火を開けると満杯に使い、一つの竈格が一杯の麺にずっと占められて全体を遅らせる問題はないと言った。商会の人々は聞き分けた。両方ともバッチ処理だが、一方はオンライン遅延——食卓に出す速さ——を優先し、もう一方はオフラインスループット——単位時間に何杯出せるか——を優先している。

本当に両者の勝敗を分けたのは、ある混合注文だった。一つの商隊が両方に別々に発注し、脚夫のための早飯は早く出し、宴席の冷菜はあまり待たせられないと要求した。老宋の早飯は老田より丸々二倍速かったが、宴席が卓に並ぶ時間は老田より遅かった——竈の区画が早飯の客に占められ、宴席の器は残りの区画に押し込まれてゆっくりしか出せなかったからだ。老田の宴席は揃ってから同時に卓へ出たが、三人の脚夫が揃うのを待って空腹に耐えかね、他店へ移ってしまった。

後に商会が分類の提案を出した。客が同期して待つ必要がなく、一つの竈で一日に何杯出せるかだけを求めるなら、老田の方式で、一鍋分そろったら投入し、竈の火の利用率を最大にする。客が来たらすぐ食べ、食べ終わったらすぐ帰るなら、老宋の方式で、来たら槽に入り、完了したら解放する。

二軒の麺屋は後にメニューに一行の説明を加えた。客が来たらすぐ茹でるのを連続バッチ処理、揃ったら茹でるのをバッチ推論と呼ぶ。竈は同じ竈で、火の入れ方によって誰が待ち、どれだけ待つかが決まる。

連続バッチ処理

オンラインサービスで動的にバッチを組む——リクエストが到着すると即座にスロットへ入り、個々のリクエストが完了するとスロットはすぐに新しいリクエストへ解放される。目標は個々のリクエストの待ち遅延を最小化することであり、リアルタイム場面に適する。

バッチ推論

リクエストをまとめて収集してから一括処理し、スロットが埋まってから推論を開始し、完了後にバッチ全体を返す。目標はGPU利用率とスループットの最大化で、オフラインバッチ処理に適している。

物語の対応

  • 甲館来一碗下一碗:連続バッチ処理で、リクエストが来たらスロットに入り、完了したら解放
  • 乙館は八碗そろってから煮る:バッチ推論、バッチが満杯になるまで待って一括処理
  • 荷担ぎは皆、甲館へ行く:連続バッチ処理で個々のリクエストの遅延を下げる
  • 宴席四十碗で乙館がより速い:バッチ推論はスループットシーンで利用率が高い
  • 混合注文は両側に勝ち負けがある:シーンがバッチ処理戦略の優劣を決める
  • 竈は同じ竈、火の付け方が違う:同じハードウェアでも、異なるスケジューリング戦略が異なる性能特性を生む

推論サービスのデプロイに落とし込む

オンライン推論サービス(対話、コード補完、検索推薦)はデフォルトで連続バッチ処理を使う——リクエストが到着するとすぐにスロットに入り、完了すると解放され、単一リクエストの遅延体験を保証する。オフライン推論タスク(バッチ評価、データ注釈、コンテンツ処理)はバッチ推論を使う——バッチが満杯になってから一括処理し、GPU 利用率を最大にする。混合需要がある場合は、入口層で分流し、同じモードで二つの場面を同時にサービスしないことを勧める。

京ICP备2026014272号