批次推論和即時推論有什麼不同？
在 AI 推論服務架構設計中，「批次推論（Batch Inference）」與「即時推論（Real-time Inference）」常依任務特性選擇不同機制。下列關於兩者特性的敘述何者最正確？
AI 推論服務依任務特性，常選擇「批次推論（Batch Inference）」或「即時推論（Real-time Inference）」這兩種不同的機制。
問你：下列對這兩種推論機制特性的描述，哪一項最正確？
一句話總結
批次推論一次處理大量資料，以吞吐量為優先；即時推論每筆立刻回應，以低延遲為優先。
先感受問題：同一個模型，什麼時候跑有差嗎？
假設「優鮮電商」有一個商品推薦模型，用來預測「這個使用者最可能買哪些商品」。
模型有兩個使用場景：
場景一：每天凌晨兩點，系統把今天所有 50 萬個使用者的行為資料餵進模型，預測每個人明天的推薦清單，結果存進資料庫。白天使用者打開 App 時，直接從資料庫讀取昨晚算好的推薦。
場景二：使用者在搜尋框打字，每按下一個字，系統就要在 100 毫秒內給出推薦建議。如果等超過一秒，使用者就會覺得 App 卡、不好用。
場景一是批次推論：時間充裕，一次算很多，重視「能不能快速處理完所有人」。場景二是即時推論：時間緊，每一筆都要快，重視「每一次請求都要在很短的時間內回應」。
如果只用一種方式跑所有推論
「優鮮電商」在早期只用一套推論方式，結果踩了五個坑：
- 用批次跑即時場景：搜尋推薦等到所有請求湊滿一批才算，使用者要等好幾秒，抱怨連連
- 用即時跑批次場景：凌晨對 50 萬用戶一筆一筆算，CPU 一整晚高速運轉，電費暴增，還算不完
- 資源分配混亂：不分場景都用同一台伺服器，高峰期即時推論搶到資源，批次推論延誤；離峰期批次推論佔滿機器，即時推論延遲暴增
- 成本失控：即時推論需要常駐的高性能 GPU；批次推論其實可以用便宜的夜間離峰算力，混在一起就浪費錢
- SLA 說不清楚：業務要求「推薦要快」，但沒有區分是批次還是即時，工程師不知道該優化哪個指標
批次和即時分開設計，各取所長
「優鮮電商」把推論服務拆成兩條路：
批次推論路徑：凌晨排程，把 50 萬用戶的資料打包成大批次，一次送進模型，系統的目標是在天亮前把所有結果算完。這裡最重要的指標是吞吐量（Throughput）：單位時間內能處理多少筆資料。每一筆的延遲是幾秒還是幾十秒，不重要，因為反正使用者現在沒在看。
即時推論路徑：搜尋框每次輸入都觸發一次推論。這裡最重要的指標是延遲（Latency）：從請求送出到結果回來的時間，要穩定維持在 100 毫秒以內，不能忽高忽低。
這就是選項 B 描述的：批次推論多用於延遲容忍度較高的大規模資料處理，以吞吐量最佳化為優先；即時推論著重於請求回應時間的穩定性與低延遲特性。
技術版：推論架構設計中的關鍵概念
兩個核心指標：吞吐量（Throughput）是每秒能處理幾筆請求，批次推論的核心目標；延遲（Latency）是單一請求從送出到收到回應的時間，即時推論的核心目標。兩者通常是互相取捨的關係：想提高吞吐量就要等待更多請求湊批，等待就增加了延遲。
同步 vs 非同步的真實意義：同步（Synchronous）是請求發出後等待結果才繼續；非同步（Asynchronous）是請求發出後不等待，結果好了再通知。選項 A 把同步/非同步跟批次/即時搞混了，批次推論實際上更常用非同步（因為要等湊批），即時推論反而更常用同步（因為需要立刻回傳）。
實務上誰用哪種：批次推論常見場景：隔夜推薦系統、月底帳單計算、大規模圖像標記。即時推論常見場景：詐欺偵測（每筆交易立刻判斷）、語音助理（說完就要回應）、自駕車（毫秒級決策）。
為什麼出題者要考這題：AI 應用規劃師規劃系統架構時，必須根據業務需求選對推論模式。選錯了，不是使用者體驗差，就是成本暴增。這是規劃師最直接影響業務結果的判斷之一。
為什麼其他選項是錯的
A批次推論通常以同步請求方式回傳結果；即時推論則多採非同步機制
批次用同步（等結果），即時用非同步（不等結果）。
這把同步/非同步的概念套反了。批次推論通常是非同步的：提交一批任務後，不需要一直等著，等全部算完再取結果。即時推論反而更常是同步的：使用者發出請求，要等到結果回來才能繼續（因為要立刻顯示給使用者看）。
對同步/非同步的直覺是「批次要等很多人，所以同步等著」的人。同步/非同步描述的是「發出請求後要不要等」，跟批次大小無關。
C批次推論因計算資源需求高，僅適用於影像類模型；即時推論主要應用於結構化資料模型
批次推論只能用於影像，即時推論只能用於結構化資料。
批次推論和即時推論是架構模式，和資料類型無關。推薦系統（結構化資料）可以用批次推論；影像辨識（影像資料）也可以做即時推論（例如手機即時拍照辨識）。這個選項完全是捏造的限制。
以為「影像資料量大所以一定要批次」的人。資料量大可以是批次的理由之一，但不是唯一理由，更不是只有影像才能批次。
D即時推論通常限制為單筆資料輸入；批次推論則可支援同步多筆資料即時回傳
即時推論只能一次處理一筆，批次推論可以同步多筆立刻給結果。
即時推論也可以一次處理多筆，只要每筆都快速回應即可（例如 LLM 服務的 mini-batch）。批次推論更不是「同步即時回傳」，它的設計本意就是讓結果晚一點回傳，換取更高效率的批量處理。選項 D 把兩者的特性完全說反了。
望文生義，覺得「批次」就是「一次多筆結果立刻回傳」的人。批次的重點在「湊夠一批再一起算」，而不是「立刻回傳多筆」。
同個考點下次怎麼變形
信用卡詐欺偵測系統應該用批次推論還是即時推論？
詐欺偵測聽起來需要很快，但金融機構也常做大規模分析。
即時推論。每一筆交易發生當下，就需要在毫秒級內判斷是否為詐欺，才能決定是否放行或觸發驗證。如果等到一批再算，詐欺者早就刷完跑了。延遲容忍度極低的場景，一律選即時推論。
電商平台每週一次寄出個人化推薦 EDM，適合用哪種推論模式？
每個人都要算，但不急著現在就要。
批次推論。寄 EDM 不需要即時回應使用者，可以提前幾小時或一天，把所有用戶的推薦結果一次算完、存好，再定時觸發寄信。批次推論節省計算成本，也能選在低峰時段排程執行。
吞吐量（Throughput）和延遲（Latency）為什麼通常是取捨關係？
能不能兩個都要？又快又能處理很多？
提高吞吐量的方法之一是等待更多請求湊成一批再一起算（Batching），這會增加每筆請求的等待時間，也就是增加延遲。反過來，為了讓每筆請求盡快回應，就不能等著湊批，只能處理完一筆才接下一筆，吞吐量就下降。這是一個基本的系統設計取捨。
如果一個 AI 服務既要高吞吐量，又要低延遲，有什麼常見的解決方案？
這是一個矛盾需求，可以解決嗎？
常見的做法是分層架構：對延遲容忍度低的請求走即時路徑，其他請求走批次路徑。或者使用動態批次（Dynamic Batching）：在一個短暫的時間窗口（如 5 毫秒）內，湊到多少筆就一起算，平衡延遲和吞吐量。這是 NVIDIA Triton、TensorFlow Serving 等推論框架的常見功能。
AI 規劃師在設計推論架構時，「服務水準協議（SLA）」和推論模式選擇有什麼關係？
SLA 是合約條款，跟技術架構有關係嗎？
SLA（Service Level Agreement）定義了服務承諾，例如「99% 的請求在 200 毫秒內回應」。這直接決定推論架構：如果 SLA 對延遲有嚴格要求，就必須用即時推論；如果 SLA 只說「每天完成計算」，批次推論就夠了。AI 規劃師的工作就是把業務的 SLA 翻譯成技術架構決策。
想再往下看，這 5 個
- 批次推論（Batch Inference）積累大量資料後統一執行推論，以吞吐量最佳化為優先，適合對延遲不敏感的隔夜報表或個人化推薦
- 即時推論（Real-time Inference）每筆請求立即執行並回傳結果，以低延遲為優先，適合詐欺偵測、即時搜尋推薦、語音助理等場景
- 推論（Inference）訓練好的 AI 模型對新資料進行預測的過程，是批次與即時兩種架構模式的共同目標，架構選擇影響成本與體驗
- 模型服務化（Model Serving）將訓練完成的模型部署為可供查詢的服務，需根據批次或即時需求設計架構與資源配置策略
- 推論最佳化（Inference Optimization）透過量化、剪枝、動態批次等手段加速推論，兼顧批次吞吐量與即時低延遲的核心技術手段