生成與推論
Batch Inference 批次推論是什麼？用等待換更低的成本
Batch Inference 批次推論，是把大量請求集中打包一次送出，不要求即時回應，等系統排程處理完再一起取回結果。因為不必為了即時性保留算力，單位成本通常比即時呼叫低很多。適合分類、標註、摘要、批次生成這類不必馬上看到答案的工作。
Batch Inference 批次推論是什麼？用等待換更低的成本
要把三萬筆客戶回饋分類，一筆一筆呼叫模型，帳單很快就會嚇到你。其實這件事根本不需要即時。
批次推論就是把「不急」變成折扣。你願意等，系統就用比較便宜的方式幫你跑完。
你將學到什麼
定義
把大量請求打包送出、不要求即時回覆，等處理完再一起取回結果。
白話比喻
像寄普通掛號而不是叫快遞。晚一點到，但便宜很多。
跟誰容易搞混
跟即時推論相對。使用者在等的路一律走即時，沒人在等的才走批次。
定義
Batch Inference 批次推論，是把大量請求集中打包成一批送出，不要求即時回應，等系統排程處理完之後再一起取回結果。
它省錢的原理很單純：即時服務必須隨時保留算力等你呼叫，那份「隨時待命」是要付錢的。批次不需要待命，系統可以挑資源比較空的時候跑，因此單位成本明顯較低。
代價是延遲。你換到的是成本，付出的是等待時間，所以它只適合沒有人在等的工作。
白話比喻
像寄件。急件叫快遞，一小時到，但每件都貴；不急的整批寄普通掛號，隔天到，單價低很多。東西一樣，差別只在你願不願意等。
所以判斷標準不是「重不重要」，而是「有沒有人在等」。很重要但沒人在等的工作，正是批次最好的對象。
批次推論跟即時推論差在哪？
| 比較點 | 即時推論 | 批次推論 |
|---|---|---|
| 回應時間 | 秒級，使用者當場看到 | 分鐘到小時級 |
| 單位成本 | 較高 | 明顯較低 |
| 適合的任務 | 對話、搜尋、互動功能 | 分類、標註、摘要、批次生成 |
| 設計方式 | 同步等待回覆 | 非同步，送出後再取結果 |
| 失敗處理 | 當場重試 | 整批重跑或補跑失敗的部分 |
實際用例
常見的三個場景。一是客戶回饋分類：把一整年的問卷與評論打包，一次跑完分類與情緒標註。二是知識庫建置：把上千份文件切片後批次轉成向量，隔天再上線查詢。三是內容整理：把大量會議逐字稿批次摘要成重點。
實務上我會把系統切成兩條路：使用者在等的功能一律走即時，其餘一律排進批次。這條分界線畫清楚，帳單跟延遲兩邊都會漂亮很多。
另外要注意速率限制。就算走批次，服務端仍有每分鐘的處理上限，一次丟太多可能被擋，設計時要留重試與分段送出的機制。
常見誤解第一個誤解是把批次當成「比較慢的即時」，於是在使用者流程裡直接呼叫，結果畫面卡住。批次一定要設計成非同步。第二個是以為批次一定比較便宜，量太小的時候，開發與維運成本會吃掉全部的折扣，先算過再導入。
本文源起本文為酒Ann 的 AI 名詞彙編系列，用白話把常見名詞一次講清楚。歡迎追蹤 酒Ann 的 Facebook。
延伸學習
常見問答
哪些工作適合走批次？
共同特徵是「沒有人在畫面前面等」。例如歷史資料的分類與標註、大量文件的摘要、資料清洗與欄位擷取、夜間跑的報表生成、知識庫的批次向量化。使用者互動中的回覆則不適合。
批次推論會等多久？
依服務與當下負載而定，通常從幾分鐘到數小時。設計時要把它當成非同步工作：送出後拿到一個工作編號，之後再回來取結果，而不是原地等著。
省下來的成本值得嗎？
資料量越大越值得。量小的時候，管理排程與取結果的工程成本可能比省下來的錢還多；量一旦上到幾萬筆，差距就很明顯了。先算清楚再決定。