推論とサービング

モデルの予測（推論）をいつ計算するかには、大きく2つのやり方があります。バッチ推論は、夜間などにまとめて全員分を計算して保存しておき、使うときは読むだけにする方法です。オンライン推論は、リクエストが来たときにその場で計算して返す方法です。

判断の目安：「入力が事前に全部分かっているか」と「答えがどれくらい古くても許されるか」で決めます。対象のユーザーや商品が決まっていて、1日前の結果でよいならバッチが簡単で安全です。今の行動や、事前に分からない入力（自由な文章）を使うならオンラインが必要です。

まずバッチで始めて効果を確かめ、鮮度が足りないと分かってからオンラインにするのも良い進め方です。

バッチとオンラインは、どちらか一方を選ぶものではありません。重い計算を事前に済ませ、鮮度が要る部分だけその場で計算すると、速さ・費用・鮮度のバランスが取れます。

ハイブリッド：実務ではよく組み合わせます。

• 候補はバッチ、並べ替えはオンライン：推薦で、ユーザーごとの候補 数百件を夜に計算しておき、表示するときに今の状況を使って上位を並べ替えます。重い計算をバッチに寄せ、軽い計算だけその場で行います。
• 重い特徴量はバッチ、軽い特徴量はリアルタイム：過去1年の集計は夜に計算して保存し、直近5分の行動だけをストリーム処理で更新します。
• 代わりの答え：オンライン推論が時間内に返らなければ、バッチで計算しておいた結果や人気順を返します。

オンライン推論は、モデルを API の後ろに置くだけではなく、特徴量の取得・前処理・後処理・ログまで含めた1つのサービスです。どこが遅いか、どこが落ちるかを分けて考えられるように、区間ごとに分けて設計します。

推論 API を本番に出すと、精度と同じくらい「どれだけ速く返るか」が問われます。おすすめや検索の並べ替えのように、画面を出す途中で呼ばれる推論は、遅いとページ全体が遅くなり、タイムアウトすれば結果を出せません。

ここでは、速さをどの数字で見るか、どこが遅いのかをどう切り分けるかを押さえます。

推論のレイテンシ（応答の速さ）は、平均ではなく p99（遅いほうから1%の値）で見ます。平均が速くても、時々遅いと利用者は待たされます。また、サーバーが起動したばかりのとき、モデルの読み込みや初回の準備で最初のリクエストだけ遅くなるコールドスタートにも注意し、起動時にモデルを読み込んで試しに推論しておく（ウォームアップ）、最小の台数を0にしない、などで避けます。

そのほか、同じ入力への答えや埋め込みのキャッシュ、特徴量を取りに行く回数を減らす（まとめて取る）、モデルのサーバーを利用者の近くに置く、なども効きます。何が遅いのか（特徴量の取得・前処理・モデルの計算・後処理）を区間ごとに測ってから手を打ちます。

ダイナミックバッチング

量子化・蒸留

下の「ブラウザで試す」の図では、アプリが推論を依頼し、ゲートウェイが推論サーバーへ振り分け、オンラインの特徴量ストアから特徴量を取り、短い時間待ってリクエストを束ねて GPU で計算し、結果を返すまでを順に追えます。上の図の区間（特徴量の取得・モデルの計算など）が、それぞれ図のどの手順にあたるかを対応させると、どこを測ればよいかが見えます。束ねるために待つ時間は、1件あたりの遅延を増やす代わりに GPU の効率を上げる取引である点にも注目してください。

ダイナミックバッチング：GPU は1件ずつより、まとめて計算するほうがずっと効率が良いです。そこで、短い時間（例：数 ms）だけリクエストを待ってまとめ、一度に計算します。全体で処理できる量が大きく増える代わりに、待つ分だけ1件の遅れが増えるので、「最大の待ち時間」と「最大のまとめる件数」を調整します。Triton Inference Server などの推論サーバーに機能があります。LLM では、生成の途中でも新しいリクエストを差し込む continuous batching（vLLM などが対応）が使われます。

量子化・蒸留：

自分たちで LLM を動かす場合、ボトルネックは多くの場合 GPU のメモリ（重み＋KV キャッシュ）と、decode のメモリの読み出しの速さです。量子化で重みを小さくすると、その分 KV キャッシュに回せて同時に処理できる数が増えます。

推論のサーバーが遅い・落ちたときに、画面ごと止めてしまうのが一番悪い形です。モデルは「付加価値」であることが多いので、代わりの答え（フォールバック）を用意して機能を保ちます。

タイムアウトとリトライの考え方は SRE の解説で