【比較】バッチ推論とリアルタイム推論の違い¶

概要¶

学習済みモデルから予測（推論）を得る方式は、大きく「バッチ推論（オフライン）」と「リアルタイム推論（オンライン）」に分かれます。バッチ推論は、大量データをまとめてスケジュール実行する方式で、スループット重視・レイテンシ許容（永続的なエンドポイントは不要）。リアルタイム推論は、リクエストごとに同期で即応する方式で、低レイテンシ要件（対話的）が中心です。AWS SageMaker でいえば前者が Batch Transform、後者が Real-Time Inference に対応します。

この 2 つはコスト構造・レイテンシ・データ鮮度・必要インフラ（キュー＋バッチジョブ vs 常時稼働エンドポイント＋オートスケール）が根本から違います。さらにまぎらわしいのが、推論サーバ側の「ダイナミック／継続バッチング（dynamic / continuous batching）」です。これは到着リクエストをまとめてスループットを上げるリアルタイム配信内部の最適化であって、データセットをまとめて処理する「オフラインのバッチ推論」とは別物です。この区別を含めて整理するのが本記事のねらいです。

例えるなら：宅配便の「まとめ便」と「即時便」¶

バッチ推論 … 夜間に倉庫へ届いた大量の荷物を、翌朝まとめて一括処理する「まとめ便」。1 個ずつの速さより、全体を効率よくさばくこと（スループット）を優先。窓口（エンドポイント）は常時開けておかなくてよい。
リアルタイム推論 … 来店客 1 人ずつにその場で応対する「即時便」。待たせない速さ（レイテンシ）が命で、窓口を常時開けて待機しておく必要がある。
（対比）継続バッチング … 即時便の窓口で、ほぼ同時に来た客を“1 回の処理にまとめて”さばいて回転を上げる店内オペレーション。店を閉めて夜間一括処理する「まとめ便」とは別の話。

詳細比較¶

比較軸	バッチ推論（オフライン）	リアルタイム推論（オンライン）
処理形態	大量データをまとめてジョブ実行（スケジュール／オンデマンド）	リクエストごとに同期で即時応答
最適化対象	スループット（全体の処理効率）	レイテンシ（1 件あたりの応答時間／SLO）
レイテンシ許容度	高い（数分〜数時間後でも可）	低い（ミリ秒〜秒オーダーの SLO）
エンドポイント	永続的な常時稼働エンドポイントは不要	常時稼働の推論エンドポイントが必要
データの鮮度	実行時点までのデータをまとめて処理（鮮度は実行間隔に依存）	最新の入力にその場で対応（鮮度高い）
典型インフラ	バッチジョブ＋オブジェクトストレージ（入出力ファイル）	ホスト型エンドポイント＋オートスケール（／キュー型は非同期推論）
コスト構造	ジョブ実行中だけ計算資源を確保（大量を効率よく）	トラフィックに応じ常時/スケールで確保（待機コストが出やすい）
代表ユースケース	夜間スコアリング、大量埋め込み生成、定期レポート	チャット応答、検索、レコメンド、不正検知の即時判定
AWS SageMaker での対応	Batch Transform（永続エンドポイント不要・大量データ）	Real-Time Inference（対話的・低レイテンシ）

よくある誤解¶

誤解1：「サーバ側のダイナミック／継続バッチング（continuous batching）＝オフラインのバッチ推論」 — 別概念です。継続バッチングは、リアルタイム配信中に到着したリクエストをまとめて GPU を効率よく回し、スループットを上げるオンライン配信内部の最適化です（vLLM はこの「継続バッチング」を高速化機能の中核に挙げています）。一方オフラインのバッチ推論は、データセット全体をジョブとしてまとめて処理し永続エンドポイントを要しない方式。前者はリアルタイム推論を“速くする実装テク”、後者は“処理方式そのもの”で、レイヤーが違います。「リクエストをバッチにまとめている＝バッチ推論をしている」ではありません。
誤解2：「バッチ推論はリアルタイム推論より常に安い」 — 一概には言えません。確かにバッチは待機エンドポイントを持たず計算を集約できるためコスト効率が良いことが多いですが、「安いか」は処理量・実行頻度・SLO 次第です。少量を頻繁に処理するならジョブ起動オーバーヘッドが効き、逆に大量を一括ならバッチが有利。鮮度が要るユースケースをコストだけでバッチ化すると、要件未達という別の損失が出ます。コストは「方式の優劣」ではなくユースケースとのトレードオフで判断します。
誤解3：「リアルタイム推論はバッチより精度が高い（最新だから賢い）」 — 推論精度はモデルと入力で決まり、配信方式（バッチ/リアルタイム）では変わりません。違うのは「データの鮮度」と「応答の即時性」であって、同じモデル・同じ入力なら出力は方式に依存しません。「リアルタイムにしたら精度が上がる」は鮮度や運用の改善を精度と混同した誤解です。
誤解4：「大きいペイロード・長時間処理ならリアルタイム同期エンドポイントで受ければよい」 — 同期エンドポイントは低レイテンシ前提で、巨大ペイロードや長時間処理には不向きです。SageMaker ではこの中間に「非同期推論（Asynchronous Inference）」があり、リクエストをキューに入れて非同期処理し、大きなペイロード・長い処理時間・準リアルタイム要件に向きます。二択（バッチ/リアルタイム同期）だけで考えると設計を誤ります。

実務での選び分け¶

対話・検索・即時判定など “待たせられない” → リアルタイム推論。常時稼働エンドポイント＋オートスケールで SLO（レイテンシ）を満たす設計にする。
夜間スコアリング・大量埋め込み生成・定期レポートなど “あとでまとめてでよい” → バッチ推論。スケジュールジョブ＋ストレージ入出力。永続エンドポイントを持たずコストを集約。
大きなペイロード／長時間処理／準リアルタイム → 同期エンドポイントでもオフラインバッチでもなく、非同期推論（キュー型）を検討。
スループットが頭打ちのオンライン配信 → 方式をバッチに変えるのではなく、配信側の継続/動的バッチング等のサーバ最適化（vLLM など）でリアルタイムのまま効率を上げる。
コスト見積もり → 「処理量 × 実行頻度 × SLO」で方式を選ぶ。待機コストが支配的ならバッチ/非同期、即時性が要件ならその分のコストを織り込む。「常にバッチが安い」と決め打ちしない。
鮮度要件の確認 → 「最新データで即応が必須」ならバッチ化不可。鮮度許容（実行間隔で足りる）ならバッチでコスト効率を取る。

ひとことまとめ¶

バッチ推論は「大量データをまとめてスケジュール実行する、スループット重視・レイテンシ許容・永続エンドポイント不要のオフライン方式」、リアルタイム推論は「リクエストごとに同期即応する、低レイテンシ SLO 前提の常時稼働オンライン方式」。サーバ側の継続/動的バッチングはリアルタイム配信を速くする内部最適化であって、オフラインのバッチ推論とは別物、と切り分けるのが要点です。

出典・参考¶

AWS SageMaker AI「Deploy models for inference」（Real-Time Inference は対話的・低レイテンシ要件向け。Serverless / Asynchronous など複数の推論オプション）: https://docs.aws.amazon.com/sagemaker/latest/dg/deploy-model.html
AWS SageMaker AI「Batch transform for inference」（大量データセットからの推論、永続的なエンドポイントが不要な場合に使う）: https://docs.aws.amazon.com/sagemaker/latest/dg/batch-transform.html
AWS SageMaker AI「Asynchronous inference」（リクエストをキューに入れて非同期処理。大きなペイロード／長い処理時間／準リアルタイム要件向け）: https://docs.aws.amazon.com/sagemaker/latest/dg/async-inference.html
vLLM Documentation（"Continuous batching of incoming requests" を高速化機能の中核に列挙＝オンライン配信時のスループット最適化）: https://docs.vllm.ai/en/latest/
vLLM Blog「Inside vLLM: Anatomy of a High-Throughput LLM Inference System」（継続バッチングはステップごとに新旧リクエストをまとめてスケジュールする配信時の仕組み）: https://blog.vllm.ai/blog/2025-09-05-anatomy-of-vllm