別再為智慧付過多的錢｜DevDay 2026（第 1/2 段）

🧑‍🏫 這是 OpenAI 工程師在 DevDay 的座談，主題是怎麼讓 AI 用起來不花冤枉錢。核心觀念是：不要只比模型的單價，要算「做完一件事總共花多少」。接著教你怎麼挑剛好夠用的模型，以及模型以外還能省錢的幾個設定。

• 00:00 這場座談由 AI deployment engineering 團隊兩位成員主講，主題是如何優化 AI 成本。
  ↳ 主講的是 OpenAI 內部 AI deployment engineering 團隊（負責 AI 部署相關工作的團隊）的兩位成員，整場在談怎麼把 AI 的花費壓下來。
• 00:00 座談涵蓋三件事：優化成本時該看什麼指標、如何為任務 right-size 模型、模型以外還有哪些槓桿。
  ↳ 內容分三塊：省錢時該盯哪個數字、怎麼替任務挑剛好夠用的模型，以及換模型之外還有哪些地方可以調整。
• 00:40 座談會穿插 OpenAI 實際客戶的案例。
  ↳ 不只講理論，中間會穿插真實客戶的做法，讓你看到這些觀念實際用起來的樣子。
• 00:40 開發者最常犯的錯是看錯指標：多數人只看官網上 input、output tokens 的牌價。
  ↳ token 是 AI 處理和計費的文字單位。input 是你送進去的內容，output 是模型產出的內容。講者說大家最常犯的錯，就是只拿官網這兩種單價來比貴不貴。
• 01:13 以 cost per token 計算便宜的模型，換成 cost per task 計算不一定最便宜。
  ↳ cost per token 是每個 token 的單價，cost per task 是把一件事做完的總花費。單價便宜的模型，算總帳不一定省。
• 01:13 主要原因有兩個：一是便宜的模型可能要消耗或產生更多 tokens 才能完成任務；二是它可能根本完成不了，最後要由人介入處理。
  ↳ 原因有兩個。一是便宜模型可能要講更多、繞更多圈才做得完，用量反而暴增。二是它可能根本做不好，最後要派人收拾，人的時間也是成本。
• 01:13 所以開發者和企業該看的指標是 cost per task，不是 cost per token。
  ↳ 結論是：評估 AI 花費時，看的是「完成一件事花多少錢」，不是「每個字多少錢」。
• 01:54 Mandeep 舉了親身例子：飛往紐約的航班被取消，他在網路上找不到符合行程的替代航班。
  ↳ 講者 Mandeep 分享自己的經驗：他飛紐約的班機被取消，上網找不到時間合適的替代班機。
• 02:24 他打電話給航空公司，客服 chatbot 一直無法理解他要改班機、不要紅眼班機，最後只好要求轉真人。
  ↳ 他打給航空公司，客服 chatbot（自動回覆的聊天機器人）一直搞不懂他要改班機、而且不要紅眼班機，最後他只好要求轉真人。
• 02:24 真人客服接手後，幫他改訂經 Houston 轉機的航班，讓他在團隊 offsite 之前抵達。
  ↳ 真人客服很快幫他改訂經 Houston 轉機的航班，讓他趕上團隊的 offsite（離開辦公室舉行的團隊活動）。
• 03:03 航空公司用的模型 cost per token 也許比較便宜，但完成任務的實際成本是 tokens 費用再加上真人介入的時間。
  ↳ 航空公司用的模型也許單價便宜，但這件事的真正成本，是 token 費用再加上真人客服花的時間。單價省下的錢，可能全被人力吃掉。
• 03:33 Perplexity 案例：在他們的 research benchmark 上，six Astra 比前一代模型準確率高 9%，成本只要一半。
  ↳ Perplexity（一家 AI 搜尋服務）在他們的研究型 benchmark（用來比較模型表現的標準測驗）上測試，six Astra 比前一代準確率高 9%，成本卻只有一半。
• 03:33 six Astra 以 token 計價可能比較貴，但它用的 tokens 較少又能完成任務，所以以 cost per task 來看反而更有效率。
  ↳ six Astra 的單價可能比較貴，但它用的 token 比較少，又能把事情做完，所以算每件事的成本反而更划算。
• 04:04 Notion 案例：從 5.5 遷移到 5.6 sole 後，準確率提升，cost per task 減半。
  ↳ Notion（筆記與協作工具）把模型從 5.5 換成 5.6 sole 之後，答得更準，完成每件事的成本也砍半。
• 04:04 OpenAI 持續投入，不只提升模型效能，也提升 token efficiency，這對成本影響很大。
  ↳ token efficiency 指用更少的 token 把事情做完。OpenAI 除了讓模型變聰明，也在這方面持續投入，因為用量少了，帳單就直接變小。
• 04:40 要 right-size 模型，第一步是清楚定義任務，以及企業或開發者對這個任務期望的準確率。
  ↳ right-size 是替任務挑「剛好夠用」的模型。第一步是先講清楚任務是什麼，以及要做到多準才算及格。
• 04:40 以航空公司為例，目標可以訂成 80% 的詢問由 chatbot 解決；講者說若用 GPT Live 搭配 six sole 作為 delegate model，可能就不必轉給真人。
  ↳ 以航空公司為例，目標可以訂成「八成的詢問由 chatbot 解決」。講者說如果用 GPT Live 搭配 six sole 當 delegate model，也許就不用轉真人。影片沒有解釋 delegate model 是什麼。
• 05:18 目標是找出能以最佳成本達到該準確率的模型、harness 和設定組合。
  ↳ 目標是找出「模型＋harness＋設定」的哪一種組合，能用最低成本達到及格線。harness 在影片裡和模型、設定並列，沒有多解釋。
• 05:18 Pareto curve：把兩個彼此相關的變數畫成圖，在兩者之間取捨優化；這裡的兩個變數是準確率和成本。
  ↳ Pareto curve 是把兩個互相拉扯的數字畫在同一張圖上，看怎麼取捨。這裡的兩個數字是準確率和成本：通常想更準，就得花更多錢。
• 05:49 做法是嘗試不同的模型、設定、configuration 和 harness，算出每種組合的任務準確率，再挑出達到門檻且成本最低的那一組。
  ↳ 實際做法是把不同模型和設定的組合都試一輪，算出每組的準確率和花費，再從及格的組合裡挑最便宜的那組。
• 05:49 有些任務一開始就知道該用哪個模型，例如較簡單的任務可以用 Luna 做 routing。
  ↳ 有些任務一看就知道該用哪個模型。像 routing（判斷請求該分給誰處理）這種簡單的工作，用 Luna 就夠了。
• 06:22 較複雜的任務可能要讓 Astra 負責大部分規劃工作。
  ↳ 比較複雜的任務，可能就要交給 Astra 負責大部分的規劃，例如拆解步驟、決定先做什麼。
• 06:22 講者表示 OpenAI 的模型位於準確率與成本的 Pareto frontier 上，包括：six Astra（frontier 模型，智慧非常高）、6.1 sole（智慧水準很高，cost per task 很有效率）、Luna。
  ↳ 講者說 OpenAI 的模型都落在準確率與成本的最佳取捨線上：six Astra 最聰明，6.1 sole 很聰明又省，Luna 則是較小、較有效率的模型。
• 06:53 簡單分類或從文件抽取幾個欄位這類任務，大概可以用 Luna，建議在流程早期就測試較小、較有效率的模型。
  ↳ 簡單分類，或從文件抓出幾個欄位這類工作，大概用 Luna 就行。建議在一開始就先拿小模型試試看。
• 06:53 需要較多智慧的任務，先從 six Astra 開始測。測過不同模型後畫出 Pareto frontier，找出達到效能門檻、cost per task 又最佳的切點。
  ↳ 需要動腦的任務，就先從 six Astra 測起。各模型都測過、畫出取捨曲線後，找出及格、每件事成本又最低的那個點。
• 07:28 整理流程：先建立 evaluation sets，找出達到準確率門檻的模型，再去優化成本。
  ↳ 整個流程是：先準備 evaluation sets（一組測試題和標準答案），找出哪些模型夠準，再從裡面挑最省的。順序是先求準，再求省。
• 07:58 Luna maxing：很多客戶意外發現，Luna 搭配 high 或 extra high 的 reasoning effort，能贏過許多較大的模型，特別是前一代或競爭對手的模型。
  ↳ reasoning effort 是設定模型回答前要想多深。Luna maxing 指把小模型 Luna 的思考深度調到 high 或 extra high，很多客戶發現它能贏過不少大模型，尤其是前一代或對手的模型。
• 07:58 不少客戶把 Luna 當作開發者寫程式的主要模型，需要更高智慧時才改用其他模型。客戶反映 Luna 在 80、90% 的 workflow 都表現很好。
  ↳ 不少客戶把 Luna 當成寫程式的主力，需要更聰明時才換別的模型。客戶回報 Luna 在八、九成的工作流程裡都表現很好。
• 08:36 講者建議不要低估 Luna，值得試試看，它可能比你想的更能幹。
  ↳ 講者的意思是別因為 Luna 小就看不起它，實際拿來試，它可能比你想的更能幹。
• 08:36 今天也發表了 Decisions API，同樣針對較簡單的任務。
  ↳ 當天也發表了 Decisions API（API 是讓程式呼叫服務的介面），同樣是針對比較簡單的任務。影片這段沒有多講細節。
• 09:06 同一個模型家族的花費可能差很多，取決於處理和傳入的資訊量，以及要求的輸出。
  ↳ 就算用同一家族的模型，帳單也可能差很多，關鍵在你餵進去多少資料、要它產出多少內容。
• 09:06 模型之外，有四個能控制成本、同時維持品質的槓桿：prompt caching、programmatic tool calling、reasoning effort、batch 或 flex API processing。
  ↳ 除了換模型，還有四個能省錢又不犧牲品質的方法：prompt caching、programmatic tool calling、reasoning effort、batch 或 flex API processing。最後一項本段只提到名稱，沒有說明。
• 09:37 Prompt caching 的切入點，是找出 input prompt 裡重複出現的文字。
  ↳ prompt 是你送給模型的指令和資料。要用 prompt caching，先找出每次送進去的內容裡，有哪些是一直重複的。
• 09:37 例子：公司客服助理處理每位客戶時都用同一套公司政策和文件。Prompt caching 可以重用這些共用資訊的前處理，模型仍會處理 prompt 裡的新資訊，每次都產生新的回應。
  ↳ 例如客服助理每次都要讀同一套公司政策。prompt caching 就是把這些重複部分的前處理存起來重用，每位客戶的新問題照常處理，回答也照樣是新的。
• 10:18 Programmatic tool calling 的情境：線上訂單系統中，agent 要處理大量訂單並確認庫存是否足夠。
  ↳ programmatic tool calling 的例子是線上訂單系統：agent（會自己呼叫工具、一步步完成任務的 AI）要處理一大批訂單，確認庫存夠不夠。
• 10:18 agent 會呼叫多個工具處理訂單，找出缺什麼、什麼在路上，再把所有結果傳回作為 reasoning engine 的 LLM。
  ↳ agent 會呼叫好幾個工具，查出缺哪些貨、哪些在運送中，再把所有結果丟回給負責思考判斷的 LLM（大型語言模型）。
• 10:51 講者問台下：模型真的需要自己讀過並比較所有工具結果嗎？現場多數搖頭，答案是大概不需要，這就是 programmatic tool calling 的核心概念。
  ↳ 講者問台下：模型真的需要親自看完、比對每一筆工具結果嗎？大家搖頭。這就是重點：很多比對工作不必讓模型親自讀。
• 11:22 講者開始說明：某些情境下，可以把所有工具結果傳回給模型做判斷（本段字幕到此結束，後續在第 2 段）。
  ↳ 講者接著提到，有些情況確實可以把所有結果交給模型判斷。完整說明要看第 2 段。

根據講者引用的 Perplexity 案例，在他們的 research benchmark 上，six Astra 跟前一代模型相比結果如何？