オンライン推論とは？バッチ推論との違いと遅延・コスト設計を実装目線で解説【2026年版】

Amazon SageMaker のリアルタイムエンドポイントは、モデルコンテナが60秒以内に応答することを求め、1回に送れる本文を6,291,456バイトまでに制限しています（AWS「InvokeEndpoint」APIリファレンス・2026年8月時点）。Azure Machine Learning のマネージドオンラインエンドポイントは、スコアリングのタイムアウトが既定5,000ミリ秒、インスタンスあたりの同時要求数が既定1です。モデルを本番に載せる作業は精度を上げる作業とは別物で、この種の上限値と実行経路の設計がそのまま可否を決めます。この記事では、オンライン推論の定義をバッチ推論・非同期推論との違いから整理し、応答時間が伸びる3つの発生源、主要3サービスの制約値、切り替え時のトラフィック設計、入れない条件までを実装目線でまとめます。

まとめ：オンライン推論を選ぶ条件と、バッチ推論に寄せる境界

オンライン推論とは、学習済みモデルを推論用のサーバーに常駐させ、届いたリクエスト1件ごとにその場で予測を返す提供方式です。Vertex AI の表現では同期リクエスト、Azure Machine Learning ではリアルタイム推論のためのオンラインエンドポイント。呼び名は違っても、HTTPで受けてHTTPで返す構造は共通しています。

選ぶ条件は3つに絞れます。予測結果を見る人（または呼び出し元の処理）が待っていること、入力がリクエストの中に揃うこと、モデルが数百ミリ秒から数秒で応答を返せること。この3つが揃わない処理は、常駐させても待機時間ぶんの課金が積み上がるだけで終わります。判断は「結果をいつ使うか」から入り、翌朝までに揃えばよいならバッチ、数秒待てるなら非同期、画面が待っているならオンライン、という並びで振り分けます。

費用の効き方も先に押さえておきましょう。オンライン推論はインスタンスの起動時間で課金されるため、1日100件の予測でも24時間ぶんの料金がかかります。GPUを積んだ構成ならこの差は数十倍。バッチ推論はジョブ実行中だけの課金で済むかわり、結果が出るまでの待ち時間を業務側が飲むことになります。

オンライン推論の定義と、バッチ推論・非同期推論との実行経路の違い

提供方式の違いは「いつ計算するか」ではなく「どこで待つか」の違いです。まず定義を固定し、そのうえで4つの方式を横並びにします。

定義：学習済みモデルを常駐させ、1件ごとに同期で応答する方式

オンライン推論の実体は、学習済みモデルをメモリに載せたプロセスが常時起動し、HTTPリクエストを受けるたびに前処理・予測・後処理を実行して同じ接続で結果を返す仕組みです。Azure Machine Learning のドキュメントは、向く条件として「低遅延の要件がある」「モデルが比較的短時間で要求に応答できる」「モデルの入力が要求のHTTPペイロードに適合する」「要求の数をスケールアップする必要がある」の4点を挙げています。

3つ目の条件が見落とされがちです。数百MBの画像や動画をそのまま渡す設計は、入力がHTTPのボディに収まらないためこの方式に載りません。大きな入力はストレージに置いてURIだけを渡すか、後述の非同期推論へ切り替えることになります。

バッチ推論との違いは、起動の単位・待ち時間・入力の集まり方の3点

バッチ推論は、溜まったデータをまとめて処理するジョブです。ジョブの分割単位や並列度、失敗したときの再実行までを含む組み方はバッチ推論とは？ジョブ分割・並列度と再実行設計を実装目線で解説で扱っています。Vertex AI では BatchPredictionJob という非同期リクエストとして扱われ、Model をエンドポイントにデプロイする必要すらありません。モデルに直接データを送り、結果を出力先へ書き出して終了します。

この差はコードの書き方より運用に効きます。オンライン推論はモデルを差し替えるあいだも受け口を落とせず、後述する切り替え手順が要る。バッチ推論なら次回ジョブから新しいモデルを指すだけで済みます。障害時も同様で、再実行すれば済むバッチに対し、オンライン推論では失敗が呼び出し元のエラーとして表に出ます。

入力の集まり方も判断材料になります。1件の予測に必要な特徴量がリクエストの中身だけで完結するなら、オンライン推論が素直に組めるでしょう。過去30日の購買履歴の集計値のように、別のデータストアを引かないと揃わない特徴量が混ざると、その参照時間が応答時間に丸ごと乗ります。連続到着するデータを扱う設計そのものについては、ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説で処理モデルの側から整理しています。

非同期推論とストリーミング推論を含めた4方式の上限値と使い分け

実務で選択肢に入るのは4方式です。上限値まで含めて並べると、境界がはっきりします。

非同期推論はオンライン推論の親戚で、受け口は常駐したままリクエストをキューに積み、処理が終わったら結果をストレージへ置きます。呼び出し元はポーリングか通知で完了を知る作り。大きな画像の解析やドキュメント全文の処理は、ここが落としどころになります。

推論基盤そのもの（KServe・Triton・BentoML といったサービング層の組み方）は、方式選択の次の階層です。フレームワークごとの向き不向きはモデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説にまとめてあります。

応答時間の内訳と、オンライン推論で待ち時間が伸びる3つの発生源

「モデルが重いから遅い」で片付けると、対策を打つ場所を外します。1リクエストの時間は4つの区間に分解でき、遅延の多くはモデル計算以外で生まれます。

推論1件の内訳は前処理・特徴量取得・モデル計算・後処理の4区間

典型的な内訳は、リクエストの解析と前処理、外部から引く特徴量の取得、モデルの計算、結果の整形と後処理の4区間です。勾配ブースティング系の表形式モデルなら計算部分は数ミリ秒で、支配的になるのは特徴量の取得とネットワークの往復時間。画像分類など深層学習系ではモデル計算が数十ミリ秒から数百ミリ秒を占め、GPUの有無で桁が変わります。

最初にやるべきは、この4区間を個別に計測してログへ出すことです。全体のレスポンスタイムだけでは、特徴量ストアの遅延なのかモデルの計算なのか判別できません。区間ごとの数字があれば、キャッシュを置く場所もインスタンスタイプを上げるべきかも判断できます。GPUやメモリ帯域といったハードウェア側の詰まりは、GPUだけでは解決できない低レイテンシ推論の構造的ボトルネックが計算資源の側から掘り下げています。

特徴量の取得がボトルネックになる構造と、事前計算へ回す判断基準

オンライン推論で最も詰まりやすいのが特徴量の取得です。「直近30日の購入回数」「同一IPからの試行回数」のような集計特徴量は、リクエストの中身には含まれません。推論のたびにデータベースへ問い合わせれば、その1往復が数ミリ秒から数十ミリ秒、集計処理を含めば数百ミリ秒に達します。

対処は2つに分かれます。ひとつは事前計算で、集計値をバッチジョブで定期更新し、キーバリューストアから読むだけにする方法。もうひとつはリクエストに必要な値を呼び出し元から渡してもらう方法で、これは推論APIの引数設計の問題になります。前者は鮮度が更新間隔ぶん古くなるため、不正検知のように直前の行動が効く領域では使えません。

判断の目安は更新頻度です。1日1回で足りる特徴量は事前計算へ回し、秒単位の鮮度が要るものだけをオンラインで引く。全部を実時間で引く設計は、レイテンシ予算をすぐ食い潰します。

コールドスタートとモデルロードで初回応答が数十秒遅れる仕組み

3つ目の発生源が初回のモデルロードです。コンテナが起動してから重みをメモリへ展開するまでのあいだ、エンドポイントは応答できません。数GBのモデルならこの展開だけで数十秒かかることもあり、その間のリクエストは待たされるか失敗します。

SageMaker はこの状態を ModelNotReadyException として HTTP 429 で返します。サーバーレスエンドポイントのリソース準備中か、マルチモデルエンドポイントが対象モデルをロード中のときに出るもの。クライアント側は待ってから再試行する設計にしておきます。429を単なる流量超過として扱い即座にエラー画面へ倒す実装だと、スケールアウトのたびにユーザーへ障害が見えてしまう。

Azure Machine Learning 側では、コンテナの起動直後に readiness probe が走ります。既定値は initial_delay 10秒・period 10秒・timeout 2秒・failure_threshold 30。モデルのロードが10秒で終わらないなら initial_delay を延ばさないと、準備中のコンテナへトラフィックが向いて失敗します。

主要3サービスの制約値と、タイムアウト・同時実行数の設定基準

マネージドサービスの既定値は、そのまま本番に出せる値とは限りません。3社の公開仕様から、実装に直接効く数字を拾います。

SageMakerは6MB・60秒の壁とHTTP 429の切り分け

SageMaker のリアルタイムエンドポイントで守るべき数字は2つです。要求・応答の本文がそれぞれ6,291,456バイトまで、そしてモデルコンテナは60秒以内に応答すること。APIリファレンスは、処理が50〜60秒かかるならSDKのソケットタイムアウトを70秒に設定するよう明記しています。クライアント側のタイムアウトをサーバー側の上限より短く設定すると、サーバーは処理を続けているのにクライアントだけが切れ、再送で二重に負荷がかかります。

クォータ側も確認が要ります。エンドポイントあたりのインスタンス数は既定4、サーバーレスエンドポイントは既定5個、その合計同時実行数は既定10（いずれもリージョンあたり・引き上げ申請可）。負荷試験で頭打ちになったとき、モデルの性能ではなくクォータで止まっている場合があります。

Azure MLの既定値5000ミリ秒と同時実行1が招く詰まり

Azure Machine Learning のマネージドオンラインデプロイでは、request_timeout_ms の既定が5,000ミリ秒、許容最大が180,000ミリ秒。5秒で切れる設定のまま重いモデルを載せると、負荷が上がった瞬間からタイムアウトが並びます。

より効くのが max_concurrent_requests_per_instance の既定1です。1インスタンスが同時に1件しか処理しないため、2件目以降はキューで待ちます。この値を上げるにはモデル側が同時処理に対応している必要があり、Azure Machine Learning 推論サーバーを使う場合は環境変数 WORKER_COUNT の指定が前提。実際の並行処理能力より大きい値は遅延を伸ばし、低すぎる値は要求を429で拒否させます。モデル1プロセスが同時に捌ける数に合わせる、というのが公式の指針です。

インスタンス数の設計にも注意点があります。高可用性のため instance_count は3以上が推奨で、アップグレード実行用にコンピューティングの20%が予約される。必要なクォータは ceil(1.2 × 要求インスタンス数) × VMのコア数で、4コアの Standard_DS3_v2 を10インスタンス要求するなら48コアぶんの空きが要ります。この予約ぶんを見込まずに申請すると、デプロイがエラーで止まります。

Vertex AIはエンドポイント配備が前提のオンライン推論

Vertex AI では、オンライン推論を使うために Model リソースをエンドポイントへデプロイする手順が必須です。ドキュメントはこれを同期リクエストと呼び、「タイムリーな推論が必要な場合」を適用範囲としています。

対してバッチ推論は BatchPredictionJob による非同期リクエストで、エンドポイントへのデプロイは不要。モデルへ直接データを送り、「即時のレスポンスが必要なく、累積されたデータを1回のリクエストで処理する場合」に使います。エンドポイントの維持費が発生するかどうかが、そのまま両者のコスト差になるわけです。3社とも呼称と既定値は違っても、同期で返す代わりに常駐費用を払う構造は共通しています。

更新リリースと監視の設計、オンライン推論を壊さない切り替え手順

常駐している以上、モデルの差し替えは無停止で行う必要があります。切り替えと観測はセットで設計します。

blue/greenのトラフィック分割とミラーリングの使い分け

Azure Machine Learning のオンラインエンドポイントは、1つのエンドポイントに複数のデプロイをぶら下げ、割合を指定して振り分けられます。合計100%の範囲で配分し、新しいデプロイへ10%だけ流して様子を見る進め方が標準的。azureml-model-deployment ヘッダを付ければ配分を無視して特定のデプロイへ直接投げられるため、切り替え前の疎通確認はこれで行えます。

もうひとつの手段がトラフィックミラーリングです。本番の100%を既存デプロイへ流したまま、そのうち10%を新デプロイへ複製して投げる。ミラー先の結果はクライアントへ返らず、メトリックとログだけが残ります。与信スコアや価格の算出のように予測値の変化が読めないモデルでは、先に新旧の出力分布を突き合わせてから割合を動かす順序が安全です。

オートスケールの指標選びにも一言。Azure Machine Learning は Azure Monitor の自動スケールと統合され、CPU使用率70%超のようなメトリックベースの規則や、営業時間に合わせたスケジュールベースの規則を設定できます。ただしGPU推論では、GPUが飽和していてもCPU使用率は上がりません。指標をCPUのまま置くとスケールアウトが遅れるため、同時要求数やキューの待ち時間へ選び直します。

監視はp50でなくp99で見る基準と、学習時との特徴量のずれ

レイテンシの監視は平均値と中央値では足りません。遅延はコールドスタート・GC・キャッシュミスで裾が伸びるため、p95やp99で見ないと画面の体感と一致しない。タイムアウト値は「p99の実測 × 1.5」から逆算し、クライアント側をそれより長く取る順序で決めます。

もうひとつ必ず見るのが、学習時と推論時の特徴量のずれです。学習用のパイプラインで作った特徴量と、推論時にオンラインで組み立てる特徴量が、単位や欠損の埋め方で食い違う事故は珍しくありません。精度は落ちるのにエラーは出ないため、監視項目に入れていなければ数か月気づかないことも。入力データの分布を記録して学習時と比較する仕組みは、公開と同時に組み込んでおきます。

Azure Machine Learning ならデータ収集の設定で入出力を保存でき、収集割合（sampling_rate）の既定は1.0。全件保存が費用面で厳しければ、割合を落として傾向だけ追えます。

オンライン推論を見送る3条件と、非同期推論・バッチへの逃がし先

ここは言い切ります。次の条件に当てはまる処理へオンライン推論を入れるのは、費用と運用負荷の持ち出しにしかなりません。

見送り条件：入力が溜まってから使う・数分待てる・アクセスが疎

1つ目は、予測結果を使う先がまとめ処理のとき。夜間に全顧客の解約確率を出して翌日の架電リストを作る用途なら、入力が溜まってから一括で処理する形が素直で、エンドポイントを常駐させる理由がありません。

2つ目は、呼び出し元が数分待てるとき。帳票の一括判定や動画の解析は非同期推論のキューへ積み、完了通知を受ける形にすれば6MB・60秒の制約からも解放されます。SageMaker の非同期推論は1GB・1時間まで許容するため、オンラインでは載らない処理も通ります。

3つ目は、アクセスが疎なとき。1日数十件の予測のためにGPUインスタンスを24時間動かす構成は、費用対効果が合いません。コールドスタートを許容できるならサーバーレス推論が候補で、待機時間ぶんの課金を避けられます。判断の分岐は次のとおり。

• 結果を人や画面が待つ、入力が1件ずつ届く → オンライン推論
• 数分待てる、入力が大きい（数百MB級） → 非同期推論
• 翌日でよい、入力がまとまって存在する → バッチ推論
• 件数が少なく間欠的、初回の遅れを許容できる → サーバーレス推論

常駐GPUの空転コストと、サーバーレス推論へ切り替える判断基準

オンライン推論のコストは「単価 × 稼働時間 × インスタンス数」で決まり、リクエスト数は式に入りません。1日100件でも100万件でも、同じ構成なら請求額は変わらない。ここが従量課金のAPIと決定的に違う点です。

切り替えの目安は稼働率で測ります。1日あたりの実処理時間（リクエスト数 × 平均処理時間）を24時間で割り、この値が数%に留まるならサーバーレス推論か非同期推論へ倒す。稼働率が高い、あるいは初回応答の遅れが業務上許されないなら、常駐のまま維持してオートスケールの下限インスタンス数で守ります。SageMaker のサーバーレスエンドポイントは既定でリージョンあたり5個・合計同時実行10という枠があるため、複数モデルを載せるなら引き上げ申請の要否を先に確認します。

なお、大規模言語モデルの提供はここまでの前提と条件が変わります。トークンを1つずつ生成する構造上、応答時間が入力と出力の長さに比例し、KVキャッシュのメモリ管理が同時実行数を縛るためです。この領域はLLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説で別に扱っています。学習済みモデルを業務システムへ組み込む工程そのもの、つまり特徴量の設計から推論エンドポイントの運用までを外部と進める場合は、機械学習モデル開発で対応しています。

よくある質問

オンライン推論の設計で実際に問い合わせの多い論点を5つ挙げます。

オンライン推論とリアルタイム推論は同じ意味ですか？

実務ではほぼ同義で使われます。Azure Machine Learning は「リアルタイム推論のためのオンライン エンドポイント」という表現でこの2語を並べており、Vertex AI は「オンライン推論」を同期リクエストとして定義。細かく言えば、オンラインは提供方式（常駐して1件ずつ受ける）、リアルタイムは応答要件（短時間で返す）。非同期推論のように、常駐しつつ即時には返さない方式も存在します。

オンライン推論とバッチ推論はどちらが安く済みますか？

件数が少ないほどバッチが有利です。オンライン推論はインスタンスの稼働時間で課金されるため、1日100件でも24時間ぶんの料金がかかります。バッチ推論はジョブ実行中だけの課金なので、同じ100件なら数分ぶん。リクエストが常時流れている場合は逆で、ジョブの起動と終了を繰り返すより常駐したほうが単純です。稼働率が数%ならバッチか非同期、という基準で切り分けるとぶれません。

推論のレイテンシはどこまで下げれば十分ですか？

画面の応答として使うなら、推論部分は100〜300ミリ秒に収めると体感を損ないません。ただし基準は用途で変わります。広告の入札のように数十ミリ秒を求められる領域もあれば、審査業務のように数秒で足りる領域もあるためです。決め方は、呼び出し元が許容する全体の応答時間から通信・アプリ処理・データベースアクセスの実測値を引き、残りを推論の予算に充てる形です。

オンライン推論でモデルを差し替えるときの手順は？

既存デプロイを残したまま新しいデプロイを作り、トラフィックを段階的に移します。Azure Machine Learning ならエンドポイント配下に複数のデプロイを置き、割合を10%から動かす形。予測値の変化が読めないモデルでは、先にミラーリングで複製を流し、結果を返さずメトリックだけ比較してから割合を動かします。切り戻しは配分を戻すだけなので、旧デプロイは監視期間が終わるまで残します。

推論エンドポイントが429エラーを返すのはなぜですか？

原因は2系統あります。ひとつはモデルの準備が終わっていない場合。SageMaker はサーバーレスエンドポイントのリソース準備中やマルチモデルエンドポイントのロード中に ModelNotReadyException を HTTP 429 で返します。もうひとつは同時実行数の超過で、Azure Machine Learning では max_concurrent_requests_per_instance が低すぎると、システムが早期に失敗を返す挙動として429が出る。前者は待って再試行する実装、後者は同時実行数の見直しで対処が分かれるため、ログで切り分けてから手を入れます。

関連記事

• モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】：方式を決めたあとに選ぶサービング基盤の比較
• LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】：トークン生成型のモデルを提供する場合の設計
• GPUだけでは解決できない低レイテンシ推論の構造的ボトルネック：計算資源の側から見た遅延の発生源
• ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説：連続到着するデータを扱う処理モデル
• KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断を実装者向けに解説【2026年版】：同時実行数を縛るメモリ側の制約