你有一個每晚執行 5,000 次請求的工作，耗時兩小時，而且沒人會在早上之前看輸出。而你正在為它付即時價格——因為在某個環節上，「API」變成了「同步 API」，那個打了 50% 折扣的 batch endpoint 從來沒有進入你的架構。
這就是 2026 年 LLM 預算中最常見的成本漏洞：容許延遲的工作付了即時費率。現在每家主要供應商都把非同步工作負載打了大約 50% 的折扣——LLM batch API 市場已經標準化在半價——OpenAI 的 batch API 有大約 24 小時的完成窗口、Anthropic 的 Message Batches 有大約 1 小時的窗口、Gemini 的 batch 分層，以及 DeepSeek 把同樣的概念折進它的尖峰／離峰定價裡。錢就擺在桌上，這份指南就是教你把它撿起來：batch API 是什麼、各家供應商的比較矩陣、可以直接複製的工作流程、batch 與即時模式的決策規則，以及把 batch 省下來的錢與快取、路由疊加在一起的組合數學。
Batch API 是什麼
重點：batch = 現在送出、稍後取回、只要付一半——每家主要供應商都標準化成了同樣的形狀。
機制到處都一致：你送出一個請求檔（JSONL），供應商把它排進佇列，在容量允許時處理，然後你在 batch 完成後取回結果。沒有串流、沒有互動延遲——這筆折扣就是對彈性的補償。
2026 年的供應商比較矩陣：
| 供應商 | 折扣 | 完成窗口 | 備註 |
|---|---|---|---|
| OpenAI | ~50% | 約 24 小時 | 參考實作 |
| Anthropic | ~50% | 約 1 小時 | 四者中最快的窗口 |
| Gemini | ~50% | 彈性分層 | batch 對應 Flex inference 分層 |
| DeepSeek | 離峰定價 | 尖峰／離峰窗口 | 用時鐘實現同樣的概念，2026 年 8 月生效 |
跨供應商比較追蹤了細節；模式完全相同——只要等得起，就付一半。
為什麼 Batch 處理真的能省錢
重點：帳單上最大的一項打 5 折，是定價決策，不是最佳化。
這套數學刻意平淡無奇。假設你每月的帳單是 $1,000，其中 60% 是容許延遲的工作（eval、索引、enrichment、夜間生成）。把這 $600 移到 batch：每月省 $300，一年省 $3,600，品質完全一樣。 輸出的 token 完全相同；唯一的差別是它們什麼時候送達。
有兩個注意事項讓這個數學保持誠實：
- 折扣適用在供應商層級，不是平台層級。 統一的 endpoint 照實收取底層供應商的費用——batch 費率就依 batch 費率通過。我們的成本最佳化手冊涵蓋了完整的槓桿組合；batch 是工程成本最低的那根槓桿。
- Batch 不是免費。 它是半價。另外一半仍然受益於快取與路由——也就是下面第五節要講的疊加數學。
如何建立 Batch 工作流程
重點：工作流程由四個部分組成——提交、冪等性、收集、復原——而復原那一塊是大家最常跳過的。
骨架，形狀上與供應商無關——請求格式遵循 chat completions endpoint 文件：
import json
from openai import OpenAI
client = OpenAI() # point at your provider or unified endpoint
# 1. Build the JSONL request file
with open("batch.jsonl", "w") as f:
for i, task in enumerate(tasks):
f.write(json.dumps({
"custom_id": f"task-{i}", # idempotency key — never omit
"method": "POST",
"url": "/v1/chat/completions",
"body": {"model": "gpt-4o-mini", "messages": task["messages"]},
}) + "\n")
# 2. Submit once — the custom_id makes retries safe
batch = client.batches.create(input_file=upload(batch_path), endpoint="/v1/chat/completions")
# 3. Poll or webhook until complete, then map results back by custom_id
# 4. Recover: failed rows get re-queued into the NEXT batch, not re-run inline四條讓它達到正式環境等級的規則：
custom_id是你的契約。 冪等性是讓重試安全的原因；沒有它，提交過程中的一次網路閃失就會重複工作、讓帳單加倍。- 依 ID 收集，不要依順序。 Batch 結果會以任意順序送達；把
custom_id對應回你的記錄，否則 join 會寫錯兩次。 - 規模上來之後，Webhook 勝過輪詢。 完成 callback 取代「每 5 分鐘檢查一次」的迴圈；錯誤碼 參考文件會告訴你哪些失敗可以重試。
- 復原是佇列，不是 hack。 失敗的列回到下一個 batch 週期。那些把失敗直接重新執行的團隊，就是親身領教 batch 速率限制 的團隊。
如何選擇：Batch 還是即時模式
重點：決策就一個問題——這份工作等得起嗎？——但有兩個明確的例外，答案永遠是否定的。
決策規則，直白地說：
- 工作等得起一小時嗎？ 放進 batch。
- 等得起一天嗎？ 放進窗口最划算的那家供應商。
- 有使用者正在等嗎？ 永遠不要 batch。
- 是 agent 迴圈嗎？ 永遠不要 batch。
第二個例外值得強調：agent 迴圈光看 token 量很像 batch 的候選，但它們的請求是因果鏈——每次呼叫都依賴上一次——因此在結構上就是互動式的。本系列的語音 agent 與客服聊天機器人架構，也因為同樣的理由是互動式的。Batch 是給有期限、可並行的工作用的，而這群工作比大多數團隊想像的還要小——這讓 50% 的折扣在真正適用的地方更有價值。
如何疊加省錢：Batch × 快取 × 路由
重點：batch、快取與路由是相乘的——一個在預算模型上重複使用已快取 prefix 的 batch 工作，成本只有天真版本的一小部分。
三根槓桿互不重疊，這正是它們能疊加的原因：
- Batch——容許延遲的工作在基礎費率上再打 5 折。
- Prompt caching——已快取的 input prefix 約 0.1×，而 batch 工作是理想的快取工作負載：同樣的模板重複執行數千次，byte 穩定的 prefix 幾乎每次都會命中。快取指南有機制細節；與 batch 的綜效就是那個乘數。
- 路由——batch 用哪個模型分層是一個路由決策：eval 用前沿模型，因為你在量測前沿；enrichment 用預算模型，因為沒人會讀。正式環境最佳化文件涵蓋路由機制。
一個實際的疊加案例：一個每晚 1,000 萬 token 的 enrichment 工作。中階模型的基礎費率：$30。Batch：$15。同樣的工作、穩定的 prefix 在 input 端以 0.1× 命中快取（假設 80% 的 token 被快取）：大約 $4-6。同樣的工作、同樣的輸出品質，只要一個路由設定和一個穩定的 prompt 模板。快速上手幾分鐘就能把管線接好；那個乘數才是會複利累積的部分。
常見的燒錢錯誤
重點：四種把折扣抵銷掉的方法——每一種都會默默把 50% 變回 100%。
- 在失敗的列上跑 eval。 只在 batch 完成的列上跑 eval；失敗的列是資料品質問題，把它們算進去會產生一個你會拿去最佳化的假分數。本系列測試指南裡的 CI 式 eval 紀律展示了這個模式。
- 讓結果過期。 Batch 結果有保留窗口；一個在你休假時完成、在收集前就過期的工作，就是一個全價卻沒有輸出的工作。把收集綁在完成事件上，而不是你的行事曆。
- 忽略 batch 專用的速率限制。 Batch 配額跟即時配額是分開的——假設兩者相同限制的團隊，會在 batch 進行到一半時發現自己的天花板。
- 跳過冪等性。 沒有
custom_id，就沒有安全的重試、沒有復原路徑——這是你能省略的最貴的四個字元。
常見問題
Batch API 實際上能省多少？
OpenAI、Anthropic 與 Gemini 的 batch 分層大約 50%，DeepSeek 的尖峰／離峰方案是以時鐘為基準的等效方案。省下的錢是每個 token 的，所以會隨你的容許延遲流量等比放大——也就是大多數帳單裡最大的一項。
Batch 完成要多久？
OpenAI 的窗口約 24 小時、Anthropic 約 1 小時、Gemini 綁在它的 Flex 分層上、DeepSeek 的離峰窗口由時鐘決定。選一個窗口符合你期限的供應商；折扣都一樣。
可以用 batch 模式跑 eval 嗎？
可以——eval 正是 batch 的典型工作負載。只跑在完成的列上，讓 prompt 模板保持 byte 穩定以利快取命中，並用完成 batch 的分數把關 CI。
Batch 跟 prompt caching 相容嗎？
相容得非常好——batch 工作會把同樣的模板重複數千次，這正是快取的理想輪廓。穩定 prefix + batch = 這份指南裡的折扣疊加。
哪些工作負載永遠不該 batch？
任何使用者會等待的東西，以及任何有因果鏈的東西——agent 迴圈與互動式語音／聊天在本質上就是即時的。Batch 決策是「等不等得起」，不是「大不大」。
統一的 endpoint 會通過 batch 折扣嗎？
會——batch 費率就是供應商費率，endpoint 照供應商收費，折扣原封不動。endpoint 的工作是一把 Key 和一個儀表板；那 50% 是供應商的，而且它會流經整個管道。
總結
2026 年的 LLM batch API 生態系標準化程度驚人：每家主要供應商都大約打 5 折，完成窗口是唯一真正的差異點。做法是機械式的——找出你工作負載中容許延遲的部分、把它移到 batch、保持 prefix 穩定、依任務路由模型分層——而 batch、快取與路由的組合，通常能比天真版本的帳單低 60-80%。折扣就擺在桌上；問題只在你的架構撿不撿得起來。
把你帳單中容許延遲的 60% 拿出來，砍掉一半。取得你的 TokSpan API Key——$5 免費額度，用在你的第一個 batch 上——讓每個工作的成本親自告訴你省了多少。