別再為智慧付過多的錢｜DevDay 2026（第 2/2 段）
🏦 台灣Pay 銀行轉帳 💙 PayPal
用 prompt caching、programmatic tool calling、reasoning effort、batch/flex 降低 API 成本
- 11:38 有些情況不需要把 tool 結果傳回模型。programmatic tool calling 是讓模型執行一支小程式，由它協調 tool calls、處理結果，再把整理好的報告交回模型判斷
- 17:26 prompt caching 的第一建議是盡量讓 prompt 開頭保持一致。這樣能重用共用指令的前處理，不在相符段落裡的新資訊則由模型重新處理
- 22:36 建議行動三：一次只測一個改動。找到改善就保留該設定並繼續迭代，隨應用程式和模型演進持續跑 evals
💡 你可以怎麼用：如果你有用 API 串接自己的工作流程，可以先做兩件事：把固定的指示放在 prompt 最前面而且不要改動，讓快取發揮作用；再把不急的大量工作（例如整批文件摘要）改用 batch 處理。之後挑幾題代表性的題目，把 reasoning effort 調低測試，確認品質沒有下降再正式採用。
看全部 34 條重點
🧑🏫 這段是 OpenAI DevDay 的演講後半，主題是用 API 時怎麼少花冤枉錢。講者提出四個省錢方法：prompt caching、programmatic tool calling、reasoning effort、batch/flex，並用客戶案例和新工具說明效果。如果你或你的團隊按用量付 API 費用，這些方法可以直接拿來對照自己的做法。
- 11:38 有些情況不需要把 tool 結果傳回模型。programmatic tool calling 是讓模型執行一支小程式，由它協調 tool calls、處理結果，再把整理好的報告交回模型判斷↳ 模型呼叫工具（例如查資料庫、搜尋）之後，結果不一定要整包交回給模型讀。programmatic tool calling 是讓模型跑一支小程式，由程式去呼叫工具、整理結果，最後只把摘要交給模型判斷。
- 11:38 programmatic tool calling 的好處是不必把每一筆中間資料都送回模型↳ 假設查回一百筆資料，程式先自己篩選，模型只看整理後的結論。模型讀進去的內容變少，費用就跟著降低。
- 12:14 programmatic tool calling 也能減少工作流程在每個步驟呼叫模型的次數↳ 原本每做完一步，都要回頭問模型「下一步做什麼」。改成由程式一次跑完好幾個步驟後，呼叫模型的次數變少，可以省錢，也能省時間。
- 12:14 客戶案例 Clio 是提供律師事務所雲端管理軟體的法律 AI 公司。它在多步驟文件分析中使用 programmatic tool calling，prompt tokens 減少 38%，品質沒有下降↳ Clio 分析法律文件要經過好幾個步驟。改用這個做法後，prompt tokens 少了 38%，品質沒有變差。token 是模型計算文字量的單位，prompt tokens 指送進模型的輸入量。
- 12:46 第三個槓桿是 reasoning effort，應該把它當成需要測試的設定。reasoning effort 跟答案長短不同，很短的答案也可能需要大量推理↳ reasoning effort 是控制模型回答前要想多少的設定，想得越多越花錢。它跟答案長短無關，只回「是或否」也可能需要想很久，所以要實際測過，不能憑感覺調。
- 13:18 例行任務一律先用較低的 reasoning effort，再跑 evals 確認品質能不能維持。困難或有差異化的任務，多花 tokens 是值得的↳ 例行工作先把它調低，再用 evals 確認品質有沒有下降。evals 是一套固定的測試題，用來檢查模型答得好不好。真正困難、或是你產品賣點所在的任務，就值得讓模型多想一點。
- 13:18 要反覆跑 evals，才能做出有根據的決定↳ 每次調整都要重跑 evals，不要只看一次結果或憑直覺下結論。這樣每個決定都有數據支持。
- 13:48 第四個槓桿是 batch 或 flex API 處理，關鍵在於你願意等多久，例如要處理上千份文件、可以等一下的情況↳ batch 和 flex 都是把不急的工作用比較便宜的方式處理。判斷重點是你能等多久，例如一次要整理上千份文件，晚一點拿到結果也沒關係，就很適合用。
- 13:48 OpenAI batch API 提供 24 小時處理時段，token 價格比標準同步請求低 50%，適合不需要模型立即回應的工作流程↳ batch API 可以一次送出一大批請求，在 24 小時的處理時段內完成，token 單價比一般「送出後馬上等回覆」的同步請求便宜一半。適合不需要立刻拿到結果的工作。
- 14:20 選模型家族時，也要問自己會讓模型做多少工作。建議完整跑一次應用程式裡的任務，觀察輸入、輸出、重複的流程，以及 tool calls 的次數↳ 選模型時，除了看單價，也要看這件事會讓模型做多少工作。建議把應用實際從頭跑一遍，記下輸入多少、輸出多少、哪些步驟重複、呼叫了幾次工具。
- 14:50 找出能改善結果的地方，一次只改一個設定再迭代。應用程式和模型演進時，持續跑 evals↳ 找到可以改善的地方後，一次只改一個設定，才看得出是哪個改動造成差異。之後應用或模型有更新，也要再跑 evals 確認。
- 15:20 重點不是單純減少 tokens，而是以更低成本和可接受的延遲，得到成功的結果↳ 目標不是把用量壓到最低，而是把事情做好：在花費更少、latency 也可以接受的情況下拿到正確結果。latency 指的是等模型回應要花多久。
- 15:20 價目表上 cached inputs 的成本最多可低 90%，所以 prompt caching 對成本的影響最多可達 90%↳ prompt caching 會把重複出現的 prompt 開頭先處理好存起來，下次直接重用。價目表上，這種被快取的輸入（cached inputs）最多便宜 90%，所以它省錢的幅度最多可以到這個程度。
- 15:54 與其把大量資訊直接丟給模型，可以用 programmatic tool calling 把資料或 context 的處理交給程式碼，不放進模型的 context window，直接降低成本↳ 不要把一大堆資料直接塞給模型讀。context window 是模型一次能讀進去的內容，放得越多越貴。改成讓程式先處理資料，只把需要的部分交給模型，就能直接省下這筆費用。
- 15:54 Codex 有 reasoning effort 的滑桿，API 也能調整 reasoning effort。現在 API 調整 reasoning effort 不會破壞快取，這是幾週前隨 Astra 釋出的↳ Codex 是 OpenAI 的寫程式工具，介面上有調整 reasoning effort 的滑桿；API 是用程式串接模型的管道，同樣可以調。幾週前 Astra 推出後，在 API 調這個設定不會讓快取失效。
- 16:24 batch 或 flex：不急、可以延後的請求，價格比較低↳ 簡單講：請求不趕時間、可以晚點處理，就改用 batch 或 flex，價格會比較低。
- 16:54 prompt caching 預設就開啟，但很多客戶沒有把它用到最充分↳ prompt caching 不用另外開啟，預設就是開著的。但很多客戶的 prompt 寫法讓快取對不上，結果沒有真正享受到省下的費用。
- 17:26 prompt caching 的第一建議是盡量讓 prompt 開頭保持一致。這樣能重用共用指令的前處理，不在相符段落裡的新資訊則由模型重新處理↳ 最重要的建議是讓每次送出的 prompt 開頭盡量一模一樣，例如把固定的說明放在最前面。相同的開頭可以重用，後面新加的內容再由模型另外處理。
- 17:56 這個技巧搭配較新的模型家族，能大幅降低成本和延遲↳ 這個做法搭配比較新的模型，省下的費用和等待時間都會很明顯。
- 17:56 客戶案例 Blitzy 是 AI 軟體開發公司。它從單次 structured output 呼叫改成 Luna 的 tool calling loop，cache 重用率從 24% 提升到 90%↳ Blitzy 原本只呼叫一次模型，要求它直接輸出固定格式的結果（structured output）。改成 Luna 的 tool calling loop，也就是一輪接一輪呼叫工具之後，快取的重用率從 24% 提高到 90%。
- 18:28 Blitzy 在數千次正式環境呼叫中，output prompt tokens 少了 8.5 倍，成本比 GPD 5.4 mini（字幕原文）便宜 87%，還能處理多 2.2 倍的 context↳ Blitzy 在數千次正式上線的呼叫中，output prompt tokens 少了 8.5 倍，成本比 GPD 5.4 mini（字幕原文）便宜 87%，能處理的內容量還多了 2.2 倍。
- 19:00 較早的模型家族預設是自動快取，由系統依 token 間隔選擇 breakpoints。使用者可以讓 prompt 開頭一致，但不能自己決定邊界↳ 較早的模型是自動快取，系統會依固定的 token 間隔自己決定在哪裡切段（breakpoints）。使用者能做的只有讓開頭保持一致，切在哪裡沒辦法自己決定。
- 19:00 字幕提到 GPT-5.4 起情況改變，GPT-5.6 families 可以加 explicit breakpoints，意思就是「快取到這裡為止」↳ 字幕提到從 GPT-5.4 開始情況改變，GPT-5.6 系列可以自己加 explicit breakpoints。意思是在 prompt 裡做一個標記，告訴系統「快取到這裡為止」。
- 19:31 例子：有相同的長篇寫程式指令，結尾的任務每次都不同。可以把 breakpoint 放在穩定段落之後、變動任務之前，重用穩定部分，模型仍會處理變動的任務↳ 例如每次都送出同一大段寫程式的規則，最後才接上這次的任務。把標記放在規則後面、任務前面，規則的部分就能重用，模型還是會照常處理新任務。
- 19:31 想要更多控制可以用 explicit only mode，自行挑選要快取的部分，避免快取經常變動、之後也不會重用的內容↳ 想控制得更細，可以用 explicit only mode，只快取你指定的部分。常常變動、之後也不會再用到的內容就不要存，免得白做工。
- 20:01 GPT-6 Astra 保留 GPT-5.6 families 的所有快取功能，另外新增一項：對話進行中可以更改 reasoning effort，不會破壞快取↳ GPT-6 Astra 保留了 GPT-5.6 系列的所有快取功能，另外多了一項：對話進行到一半時更改 reasoning effort，原本的快取還是能繼續使用。
- 20:31 本來就能做到的功能：把工具放在 allowed tools 或其他參數裡，更換給模型的工具時不會破壞快取↳ 這是本來就有的功能：要更換給模型用的工具時，可以透過 allowed tools 或其他參數來調整，快取不會因此失效。allowed tools 是指定模型可以使用哪些工具的清單。
- 20:31 admin 網頁上推出了 prompt caching dashboard，可以查看、衡量、追蹤各應用程式的 cache hit rate↳ 管理後台新增了 prompt caching dashboard，可以查看各個應用的 cache hit rate，也就是有多少比例的請求成功用到快取，方便長期追蹤。
- 21:03 另外推出了 diagnostics API：給它兩個不同的查詢，它會指出 cache miss 發生在哪裡，方便你優化↳ 新推出的 diagnostics API 可以比對兩個請求，指出是哪裡不同造成 cache miss，也就是沒用到快取。這樣你就知道 prompt 該改哪一段。
- 21:03 總結：正確的指標是完成任務的成本，而不只是牌價。也談到如何為任務找到合適的模型↳ 總結來說，該看的是完成一件任務總共花多少錢，不是每個 token 的單價。單價便宜但要多跑好幾輪，總花費可能反而更高。
- 21:33 講者表示 OpenAI 的模型在成本與準確度上位於 Pareto frontier↳ 講者表示 OpenAI 的模型位在 Pareto frontier 上，意思是在成本和準確度的取捨中，已經做到同樣花費下最準的程度。這是講者自己的說法。
- 21:33 建議行動一：定義你要模型完成的任務，並訂出業務或使用情境要求的準確度門檻↳ 第一步：先講清楚要模型完成什麼任務，再訂出「準確到什麼程度才算合格」。門檻依業務需求而定，例如內部會議摘要可以容許小錯，合約審查的要求就高得多。
- 22:04 建議行動二：定義一組有代表性的任務，試不同的模型、設定、reasoning effort 和 prompts（看 prompt caching 的效果），畫出 Pareto frontier，找出在準確度門檻下最適合的模型配置 harness↳ 第二步：準備一組能代表實際工作的題目，用不同的模型、設定、reasoning effort 和 prompt 去跑，把成本和準確度畫成圖，找出達到門檻又最省錢的整套配置（harness）。
- 22:36 建議行動三：一次只測一個改動。找到改善就保留該設定並繼續迭代，隨應用程式和模型演進持續跑 evals↳ 第三步：一次只改一個地方，有改善就保留，再繼續試下一個。應用或模型有更新時，也要持續重跑 evals。
📘 術語
programmatic tool calling（程式化工具呼叫）：模型執行一支小程式，由它協調 tool calls、處理結果，再把整理好的報告交回模型判斷
prompt tokens（提示詞 token）：字幕未詳細解釋；Clio 案例用它衡量節省的量（少 38%）
reasoning effort（推理強度）：一個需要測試的設定，跟答案長短不同，短答案也可能需要大量推理
evals（評測）：字幕未定義；用來確認調整設定後品質是否維持，建議反覆執行
batch API（批次 API）：提供 24 小時處理時段，token 價格比標準同步請求低 50%
flex（彈性處理）：與 batch 並列，請求不急、可以延後時，付的錢比較少
synchronous requests（同步請求）：字幕作為 batch API 價格的比較基準（標準同步請求）
latency（延遲）：字幕未詳細解釋；目標是成本更低且延遲可接受
prompt caching（提示詞快取）：預設開啟，可重用相同 prompt 開頭的前處理；cached inputs 成本最多低 90%
context window（上下文視窗）：字幕未定義；把資料處理交給程式碼、不放進 context window，可以降低成本
cache hit rate（快取命中率）：可在 prompt caching dashboard 查看、衡量、追蹤
cache miss（快取未命中）：diagnostics API 能指出兩個查詢之間 cache miss 發生在哪裡
explicit breakpoints（明確斷點）：可以理解成「快取到這裡為止」，放在穩定內容之後、變動任務之前
explicit only mode（僅明確模式）：自行挑選要快取的部分，避免快取經常變動、不會重用的內容
allowed tools（允許的工具）：把工具加在 allowed tools 或其他參數裡，更換工具時不會破壞快取
diagnostics API（診斷 API）：給它兩個不同的查詢，告訴你 cache miss 發生在哪裡
Pareto frontier（柏拉圖前緣）：用來衡量成本與準確度的取捨，建議畫出來找最適合的模型配置
prompt tokens（提示詞 token）：字幕未詳細解釋；Clio 案例用它衡量節省的量（少 38%）
reasoning effort（推理強度）：一個需要測試的設定，跟答案長短不同，短答案也可能需要大量推理
evals（評測）：字幕未定義；用來確認調整設定後品質是否維持，建議反覆執行
batch API（批次 API）：提供 24 小時處理時段，token 價格比標準同步請求低 50%
flex（彈性處理）：與 batch 並列，請求不急、可以延後時，付的錢比較少
synchronous requests（同步請求）：字幕作為 batch API 價格的比較基準（標準同步請求）
latency（延遲）：字幕未詳細解釋；目標是成本更低且延遲可接受
prompt caching（提示詞快取）：預設開啟，可重用相同 prompt 開頭的前處理；cached inputs 成本最多低 90%
context window（上下文視窗）：字幕未定義；把資料處理交給程式碼、不放進 context window，可以降低成本
cache hit rate（快取命中率）：可在 prompt caching dashboard 查看、衡量、追蹤
cache miss（快取未命中）：diagnostics API 能指出兩個查詢之間 cache miss 發生在哪裡
explicit breakpoints（明確斷點）：可以理解成「快取到這裡為止」，放在穩定內容之後、變動任務之前
explicit only mode（僅明確模式）：自行挑選要快取的部分，避免快取經常變動、不會重用的內容
allowed tools（允許的工具）：把工具加在 allowed tools 或其他參數裡，更換工具時不會破壞快取
diagnostics API（診斷 API）：給它兩個不同的查詢，告訴你 cache miss 發生在哪裡
Pareto frontier（柏拉圖前緣）：用來衡量成本與準確度的取捨，建議畫出來找最適合的模型配置
✏️ 小考一題
根據影片，OpenAI batch API 的處理時段和價格優惠是什麼？
A. 12 小時處理時段，token 價格比標準同步請求低 50%B. 24 小時處理時段，token 價格比標準同步請求低 50%C. 24 小時處理時段，token 價格比標準同步請求低 90%D. 48 小時處理時段，token 價格比標準同步請求低 38%看答案
答案：B。[13:48] 字幕說 batch API 提供 24-hour processing window，at a 50% lower token pricing compared to standard synchronous requests
💛 覺得有幫助？支持一下
課本免費、沒有廣告，支持與否都能照常讀 🐰