團隊降低 LLM API 成本時，通常會去找更便宜的行項、更小的模型或者折扣。真正把成本降下來的工程師把它當成一套有順序的流程：先測量，去掉浪費，縮減傳送出去的內容，把可延後的工作挪到更便宜的執行路徑，把快取穩定下來，在質量護欄後面做模型尺寸調整，再對照你起步時的基線做驗證。順序很重要，因為後面每一步都依賴前面幾步所證明的東西。跳過測量直接把模型降級，結果掉進質量回退，你就既說不清省了多少錢，也說不清質量去哪兒了。本文是這條序列的樞紐，它引用的每一個機制都在按步驟連結的姊妹文章裡深入講過。
第零步：測量與 API 成本歸屬
在你用一句話回答“哪些功能在消耗賬單”之前，別的都別開始。沒有測量的 LLM 成本最佳化計劃就是在猜，而猜會產生兩種經典失敗：砍掉了並非問題的東西，或者為了省下四捨五入級別的誤差而犧牲質量。用三組訊號建立基線。第一，按功能、團隊和客戶分組的支出與用量，讓最大的行項可見，使用用量與成本追蹤指南裡的歸屬方法。第二，快取相關的用量欄位，因為它們在你去動快取之前就能告訴你快取到底有沒有生效。第三，重試次數和被拒請求率，因為看起來像需求的一部分其實是浪費，詳見重試預算指南。把基線寫下來。後面每一步都會對照它來評判。
第一步：先消滅浪費，再談最佳化
最便宜的 token 是你從不發出的那個，而最常見的成本問題都是浪費，不是定價：
- 重試風暴。對本不可重試的錯誤（比如 403 這一類或硬性消費上限）應用退避重試，只是在反覆傳送永遠不會成功的請求。更糟的是疊加重試：一個帶自動重試的 SDK 加上應用層的重試包裝，可以讓每次邏輯呼叫的請求量成倍放大。測一下你的棧有沒有這種巢狀。
- 靜默失效的快取。如果 prompt 字首裡有時間戳或隨機 ID，或者動態內容排在穩定內容之前，或者工具定義每次部署都被改動，快取就永遠不會命中。於是你在每個請求上都付一次新的快取寫入，卻永遠拿不到一次讀取。機制在快取指南里，而這個模式值得專門檢查一遍。
- 失控的 agent 迴圈。工具定義佔用 prompt 空間，而每一次迴圈迭代都會重發不斷變長的對話。沒有輪次上限、沒有 token 預算的迴圈就是一個開著的龍頭；工具呼叫指南講了迴圈的設計。
- 重複的上下文。同一份長文件被貼上進許多次呼叫，而一個快取字首或一個文件引用就夠用，這就是純粹的重複。
第二步：縮減每個請求的 token
OpenAI 的成本最佳化指南把槓桿歸為三種策略：減少請求、最小化 token、選擇更小的模型。它還指出成本與延遲是相關聯的，所以這裡的大部分工作會付兩次回報。具體來說：把總是成對出現的呼叫合併成一個請求而不是兩個；在長答案對誰都沒用的時候限制輸出長度，因為輸出才是貴的方向；要求結構化輸出只包含下游程式碼真正讀取的欄位；去掉不影響答案的上下文。輸出長度限制同時也是一個可靠性特性：有界的答案更容易校驗，而校驗不花錢。
第三步：可延後的工作用 batch API 還是 flex 處理
有些工作不需要即時響應，這個事實應該被計入價格。存在兩條官方路徑：
- Batch API。對 OpenAI 來說，Batch API 非同步處理作業：你把請求收集到一個檔案裡，啟動一個 batch 作業，在請求執行時查詢它的狀態，完成後取回收集好的結果。對 Anthropic 來說，Message Batches API 的工作方式相同：提交大量請求做非同步處理，輪詢狀態，完成後取回。大多數批次在 1 小時內完成，你可以在所有訊息完成時或 24 小時後（以先到者為準）訪問結果，如果處理在 24 小時內沒有完成，批次就會過期。適用性測試很簡單：量大、不需要即時響應、能容忍小時級的週轉。
- flex 處理。OpenAI 的成本指南把 flex 描述為對 Chat Completions 或 Responses 請求顯著更低的成本，代價是響應更慢、偶爾資源不可用，定位在非生產或較低優先順序的工作，比如模型評估、資料富集或非同步負載。邊界不言自明：面向使用者的互動流量不屬於這裡，因為偶發的不可用是一個產品決策，而不是一個工程細節。
第四步：正確處理 prompt 快取的 TTL
快取是順序紀律最能見效的一步，也是小錯誤最能毀掉收益的一步。Anthropic 的 prompt 快取文件裡的規則是：快取引用整個 prompt、工具、system 和 messages，按這個順序，直到並包含你指定的那個塊。所以設計原則是穩定優先：把很少變化的內容放在前面，把易變內容移到斷點之後，並在穩定性結束的地方放顯式標記。有兩個細節會咬住那些把快取當成設完就忘的開關的團隊。第一，TTL 預設是 5 分鐘，另有 1 小時的選項但要額外付費，指導建議是對使用頻率高於每 5 分鐘的 prompt 保留 5 分鐘預設值（它會持續重新整理），而把 1 小時版本留給使用頻率低於每 5 分鐘但高於每小時的 prompt。第二，邊界情況：如果最後一個塊已經帶有相同 TTL 的顯式快取標記，自動快取就是空操作；如果標記的 TTL 不同，API 會返回 400 錯誤。快取寫入和快取讀取的定價與基礎輸入 token 不同，而且這些倍數會與其他定價修飾項疊加，所以計價算賬屬於官方定價頁面，不屬於估算。還有一條運維說明：快取命中不計入你的限流額度，所以修好快取既改善成本也改善餘量。機制，包括如何從用量欄位核實命中，見快取實踐指南。
第五步：更小的模型，配上質量護欄
第三種官方策略是選擇更小的模型，OpenAI 把它表述為在降低成本和延遲與保持準確率之間取得平衡。“保持”是關鍵的那個詞，而它不會自己發生。按每個任務的約束來選模型，而不是按名氣，使用模型選擇指南裡的框架：這個具體工作負載到底需要什麼準確率、延遲和能力？然後守住護欄：一套迴歸測試，用同一批任務跑更小的模型，並把輸出與當前基線比較，這樣降級就是一個被測量過的決定，而不是一個悄悄發生的決定。悄悄拿質量換成本是能做的最糟的交易，因為賬單下降的同時產品在退化，而沒人能把哪項改動歸因到哪個後果。
第六步：對照基線驗證
在第零步的基線確認之前，上面每一個動作都只是假設。用三項檢查閉環，一起評估，絕不單獨看一項：
- 成本曲線。改動之後，按功能和按團隊的支出是否真的在往下走？
- 快取行為。命中率上升了嗎，還是某次字首改動把它悄悄歸零了？
- 質量。拒絕率、校驗失敗率，以及對輸出做抽樣人工評審，都與改動前的同一樣本對比。
如果三項裡任何一項變差，就回退那一個動作，保留其他動作。一次只改一處，才讓歸因成為可能；這和事故日誌對待證據是同一種紀律，只是提前了一步，用在了決策本身上。
那條基線迴圈是釋出前模型驗證在成本側的版本；測試手冊描述了針對模型和 prompt 改動的同一套紀律。
順序檢查清單
- 先測量：按功能劃分的支出、快取欄位、重試與被拒率。把基線寫下來。
- 消滅浪費：不對不可重試的錯誤重試，不疊加重試層，不留不穩定的快取字首，不放任 agent 迴圈，不重複上下文。
- 縮減 token：更少的請求、更短的輸出、更緊的 schema、更少的無關上下文。
- 挪走可延後的工作：大批次非同步作業用 batch API；非生產或低優先順序負載用 flex；絕不用在互動流量上。
- 修快取並注意 TTL 細節：穩定優先的字首、顯式斷點、清楚空操作和 400 這兩個邊界情況，計價算賬放在官方頁面上。
- 按回歸套件而不是按希望來調整模型尺寸。
- 事後驗證三項訊號，任何讓其中一項回退的改動都回退掉。
- 保留回滾開關：上面每一步都應該是你能單獨撤銷的配置變更。
這就是全部的訣竅。在支出上打贏的團隊把它當作一條兩端都有測量的工程式列，而你呼叫的任何端點的端點級事實都在該平臺自己的文件裡。