← 概念辨析に戻る

Concept Contrast Fable

オンライン推論とバッチ推論

先に結論:一方はミリ秒級の応答を要求し、ユーザーが結果を待っている。もう一方は数時間キューで走らせ、翌日に答えを受け取れる。推論モードを選び間違えれば、コストが爆発するか、顧客が待てないかのどちらかだ。

一方はミリ秒級の応答を要求し、ユーザーが結果を待っている。もう一方は数時間キューで走らせ、翌日に答えを受け取れる。推論モードを選び間違えれば、コストが爆発するか、顧客が待てないかのどちらかだ。

寓話

即時キッチンと中央キッチン

河辺の飯館は、一方で散客を受け、一方で書院に百人分の昼食を作る。料理人の阿桂は、似て見える二つの事を管理している。一つは客が座って注文し、鍋のそばですぐ出る料理。もう一つは早朝に名簿どおりに弁当を一批用意すること。新しい店員は面倒がり、二つの冊子を一つにまとめ、どうせどちらも成否に関わると考えた。

最初は誰も反対しなかった。店主は両方を「調理」として記帳し、臨時客も大鍋を待ち、弁当も一つずつ炒めた。店主はページ数が減ったのを見て、彼らを省力だと褒めた。しかし繁忙期になると、旧帳は突然説明できなくなった。前の屋台が終わっていなかったのか、後の屋台が守らなかったのか、誰も答えられなかった。

彼らはまずより多くの印とスローガンを補い、各人にもっと詳しく書くよう求めた。結果、冊子は厚くなり、争いは増えた。事が起きたとき、誰もが自分をかばう一言を見つけられたが、どちらを先に救うべきかは誰も分からなかった。

老管事は皆を庭に呼び集め、実際の経過に沿って歩き直させた。目の前の動作に関心のあるものは第一冊に、後続の負担に関心のあるものは第二冊に入れた。二冊は互いに参照し合うが、もはや同じページに混ざることはない。

ランチタイムに散客は待ちくたびれて怒り、書院の方は分割が遅すぎて授業に遅れた。分けた後、多くの古い結論が変わった:ある仕事は賑やかに見えても、実は面倒を防いでいなかった;ある取り決めは普段目立たなくても、災害時に全体を守った。

新人が再び混同しないよう、老管事は彼らにそれぞれ小さな案件を処理させた。二冊の帳簿がそれぞれ自分の問題に答えられ、かつ境界で互いに接続できたときだけ、その小さな案件は合格となる。もし誰かが依然として二つの事柄を一ページに書くなら、現場に戻って誰が先に動き、誰が最後に責任を負うかをもう一度見なければならない。はっきり見えないときは、一度多く問い合わせるほうがましで、曖昧な帳簿を一夜越しにしてはならない。本当に事故が起きる日には、一行の区別が欠けるだけで一隊の人が無駄に忙しくなるからだ。

阿桂は前厅と後院を分けた。前厅では小さな鍋で素早く炒め、後院ではリストに沿ってまとめて洗い、切り、蒸し、煮る。両側は米と小麦粉を共有するが、異なるリズムで作業を割り振る。後に新人が入ってくると、老管事はただ一言だけ覚えさせた。誰かがテーブルの前で待っていれば、すぐに応答しなければならない。あるリストがすでに確定していれば、まとめて一度に完了させるべきだ。

オンライン推論

リクエストが届くと即座に処理し、遅延はミリ秒から秒単位。チャット、検索、リアルタイム推薦など即時フィードバックが必要な場面に適するが、1回あたりのコストは高い。

バッチ推論

大量のリクエストを一括にまとめて統一的に処理する。遅延は分から時間単位だが、単位コストは大幅に下がる。オフライン注釈、レポート生成、データクレンジングなど、即時性に敏感でないタスクに適する。

物語の対応

  • 前厅で3分で提供:オンライン推論、低遅延、高単価。
  • 中央厨房の大量調理:バッチ推論、高スループット、低単価。
  • 100件の団体給食注文:大量バッチのタスクで、遅延には敏感でないがコストと一貫性には敏感。
  • レシピと仕入れルートを共有:同じモデルがオンラインとバッチの両方の推論モードを同時に支えられる。

プロジェクトに落とし込む

アーキテクチャ設計時にリクエストを二種類に分ける:リアルタイム系はオンライン推論、レポート系・分析系・バッチ処理系はバッチ推論。バッチ推論の単位 token コストはオンライン推論の 50% 以下になることもあるが、前提として遅延を受け入れられること。また注意:バッチ推論の結果をリアルタイムシーンで使う場合、追加のキャッシュ層が必要になる。

京ICP备2026014272号