想在串接前完成 AI API 費用估算，最可靠的做法不是用「每次對話大概多少錢」來猜，而是把真實或模擬的代表性請求送進計數與測試流程，分別記錄輸入、快取輸入、輸出，以及模型可能另外計價的項目；接著乘上預估請求量，並在上線後用 API 回傳的 usage 持續修正。
先掌握一個原則：Token 不等於字數。同一段文字的 Token 數會受到模型、編碼方式與語言影響，因此不宜把固定的中文字符數或英文單字數比例當成帳單公式。OpenAI 也明確說明，input、cached input 與 output Token 的費率可能不同，其他 API 功能也可能有不同計費單位。官方 Token 說明
AI API 費用估算先看什麼？五個預算欄位
建立試算表時，先不要急著填單價。第一步是把每種工作負載拆開，例如簡短問答、文件摘要、知識庫查詢、多輪客服，或非同步的大量處理工作。每一種工作負載都應獨立量測，因為它們的請求結構可能不同。
| 欄位 | 用途 | 估算時的做法 |
|---|---|---|
| 未快取 input Token | 請求中依一般 input 費率計價的部分 | 以代表性完整請求量測，記錄每次請求的用量分布。 |
| cached input Token | 請求中依快取 input 費率計價的部分 | 只有模型與請求實際產生這類用量時才填列，不能直接假設所有重複內容都會適用。 |
| output Token | 模型產生內容所計入的 output 用量 | 以 API usage 為準，不要只數畫面上看得到的回答長度。 |
| 模型特定 Token 費項 | 例如 cache write 或長上下文門檻造成的不同費率 | 逐一核對所選模型的價格頁與條件；這一欄不可省略。 |
| 非 Token 計費項目 | 可能以其他單位計費的 API 功能 | 依實際使用的功能與官方計費規則另列，不要混進文字 Token 單價。 |
這些欄位是一份基礎預算模板，不是所有模型與所有情境都適用的一條完整公式。特別是模型可能設有 cache write 費用、長上下文門檻，或其他不同計費單位；因此，選定模型後仍要以該模型當前的官方價格條件逐項核對。
月費核心公式：先做模板，再補上模型特定條件
若以美元建立月預算，可先在試算表使用下列結構。所有 Token 數量都應換算成「百萬 Token」後，再乘以對應單價。
月成本（USD）＝未快取 input 用量 × input 單價＋cached input 用量 × cached input 單價＋output 用量 × output 單價＋模型特定費項＋非 Token 計費項目
其中，月用量可由「每日請求數 × 每次請求 Token 用量 × 預估計費天數」推得。不過，正式預算不應只放平均值。建議同時建立保守、中位與尖峰三種情境，分別填入較低、典型與較高的每次請求 Token 數，以及對應的請求量。
試算表建議欄位
- 工作負載名稱：例如「客服單輪問答」或「文件摘要」。
- 模型與服務層級：避免不同模型或不同服務條件混在同一列。
- 每日請求數、計費天數。
- 每次請求的未快取 input、cached input、output Token。
- 模型特定費項：依模型價格文件決定是否啟用，例如 cache write 或長上下文費率。
- 非 Token 計費項目：僅在專案確實使用相關功能時填列。
- input、cached input、output 的當前單價與查核日期。
- 保守／中位／尖峰情境，以及團隊自行設定的預算緩衝比例。
若團隊需要以新台幣管理內部預算，可在試算表另設匯率假設欄位，將美元成本換算成內部預算數字；實際付款、稅務與結算安排則應另向服務供應商及財務人員確認。
不要用字數猜：如何量測代表性 Prompt 的 Token
字數只能協助你快速判斷內容規模，不能取代 Token 量測。較穩妥的流程如下：
- 列出主要請求類型。至少選出會占最多流量或最可能變長的情境。
- 準備代表性內容。包含實際會送入的系統指示、使用者輸入、文件內容、對話脈絡與其他請求內容。
- 先計算完整 input。OpenAI 提供 input-token counting API，可用來計算完整的 Responses input。查看官方說明
- 發送測試請求並保存 usage。從 API 回應的 usage 檢查單次請求用量；不同端點的欄位名稱可能不同。查看 API 用量說明
- 不要只留一筆樣本。把短、中、長內容分開保存，讓後續預算能反映不同請求規模。
- 把量測值回填試算表。以每類請求的實測數值取代原先猜測，並保留量測日期、模型與設定，方便日後比較。
為什麼回答很短，API 帳單仍可能偏高？
可見回答文字不是唯一的成本線索。以 OpenAI 的說明為例，reasoning tokens 不會顯示在最終回答文字中，但會計入 output usage，並依 output tokens 計費。因此，若使用的模型或工作流程涉及這類用量，只看畫面上的回答長度，可能低估實際成本。
實務上，應優先以 API 回應中的 usage 作為單次成本基準，再搭配請求本身的 input 規模檢查異常。這也適用於內容較長、請求結構較複雜，或包含額外 API 功能的情境。
RAG、多輪聊天、檔案或圖片工作：預算要怎麼拆？
這類工作不宜與簡短單輪問答共用同一組平均 Token。比較好的做法是：把每一種請求結構當成獨立工作負載，各自量測完整 input、cached input、output 與適用的其他費項。
- RAG：以實際送入模型的完整請求作為量測對象，不要只計使用者問題本身。
- 多輪聊天：使用代表性的對話長度進行測試，並把不同對話階段分成短、中、長情境。
- 檔案、圖片或其他功能：先確認該功能的官方計費單位，再另設費用欄位；不要直接用文字 Token 單價套算。
- 批次工作：若工作不要求即時完成，可評估 Batch API。OpenAI 表示 Batch API 的模型費用相對同步 API 折扣 50%，官方處理目標為 24 小時內，因此應依工作時效決定是否適用。查看 Batch API FAQ
完整範例：每日 1,000 次請求如何試算月成本？
以下是假設情境，用來展示試算方法，不代表任何專案的實際使用量。假設選用 GPT-5.6 Luna，且每次請求都在其基礎費率適用的上下文條件內；每日 1,000 次、每月 30 天，每次有 1,000 個未快取 input Token、0 個 cached input Token，以及 500 個 output Token。
截至 2026 年 9 月 11 日，GPT-5.6 Luna 的文字 Token 基礎費率為：input 每 100 萬 Token US$0.20、cached input 每 100 萬 Token US$0.02、output 每 100 萬 Token US$1.20。查看 GPT-5.6 Luna 官方模型頁
| 項目 | 計算 | 結果 |
|---|---|---|
| 月請求數 | 1,000 次／日 × 30 日 | 30,000 次 |
| 未快取 input 用量 | 30,000 × 1,000 | 30,000,000 Token |
| output 用量 | 30,000 × 500 | 15,000,000 Token |
| input 成本 | 30 × US$0.20 | US$6.00 |
| output 成本 | 15 × US$1.20 | US$18.00 |
| 基礎 Token 成本小計 | US$6.00＋US$18.00 | US$24.00 |
這個 US$24.00 僅是該假設下的基礎 Token 成本小計，未包含 cached input、cache write、其他 API 功能或其他模型特定費項。GPT-5.6 Luna 的單次 prompt 若超過 272K input tokens，完整請求會適用不同費率；其 cache writes 也另行計價。因此，遇到長上下文或快取相關用量時，不能把上表的基礎費率直接延用。
三情境預算：保守、中位、尖峰怎麼做？
單一平均值容易掩蓋高用量請求。建議對每個工作負載至少建立三列預算，讓團隊在開發前就能看見成本範圍。
| 情境 | 填寫原則 | 適合用來回答的問題 |
|---|---|---|
| 保守 | 使用較低的請求量與較短的代表性 input／output。 | 若使用量低於預期，月成本大約落在哪裡？ |
| 中位 | 使用目前最具代表性的請求量與 Token 用量。 | 一般營運月份需要編列多少預算？ |
| 尖峰 | 使用較高的請求量與較長的代表性內容，並納入可能出現的模型特定費項。 | 流量或內容規模上升時，成本風險在哪裡？ |
緩衝比例應是團隊自己的風險管理設定，而不是固定常數。若尚未有正式流量資料，較重要的是明確標示每個假設：每日請求數從何而來、每次請求使用哪組量測樣本、哪些費項尚未啟用，以及單價的查核日期。
上線後如何用 usage 校正下個月預算？
API 成本估算不是一次性的試算。上線後，應定期把實際 usage 與原先的情境預算對照，找出差異是來自請求數、input、cached input、output，還是模型特定或非 Token 項目。
- 依工作負載、模型或專案標籤整理請求資料。
- 檢查 API 回應的 usage，記錄各端點實際提供的用量欄位。
- 比較實際單次用量與原先的保守、中位、尖峰假設。
- 將異常偏高的請求另建一列，而不是用全站平均值掩蓋它。
- 用最新單價與最新 usage 重算下個月預算，並保留變更紀錄。
OpenAI 提供 Usage API、Costs endpoint 與 Usage Dashboard 等用量與成本檢視方式；Costs endpoint 與 Usage Dashboard 的成本資料會對帳至帳單，但因記錄方式不同，明細不一定完全一致。做月度核對時，應以帳務對帳需求與各工具的資料用途分開理解。查看 Usage API 文件
降低 API 成本的優先順序
在尚未掌握實際 usage 前，不必先猜哪一項最佳化一定最有效。先從量測結果找出最大成本來源，再依優先順序處理：
- 減少不必要的重送內容：先檢查高 input 用量請求中，哪些內容確實需要保留。
- 為輸出設定明確範圍：若產品只需要短格式結果，就以產品需求約束輸出內容，並觀察 output usage 是否下降。
- 評估快取相關用量：確認模型的 cached input 與 cache write 規則後，再決定是否值得調整請求設計。
- 把不需即時完成的工作分流：符合時效需求時，可評估批次處理的成本與處理時間取捨。
- 依工作負載做模型路由：先以量測與產品品質要求定義每類任務，再檢視不同模型條件下的預算影響。
AI API 費用估算常見漏算清單
- 只估可見回答字數，沒有核對 output usage。
- 只記 input 與 output，漏掉 cached input、cache write 或長上下文門檻。
- 把不同模型、不同服務條件的單價混在一起。
- 把文字 Token 的算法套用到採其他計費單位的功能。
- 只用一筆「平均請求」推估所有工作負載。
- 價格表更新後，試算表仍沿用舊單價。
- 上線後沒有用 API usage 回頭校正假設。
一份可用的 API 預算表，重點不在於第一次就算得完全精準，而在於每一個數字都有來源、每一項費用都有欄位可放，並能隨著實際 usage 持續修正。先建立代表性請求樣本，再以模型當前價格與上線後資料迭代，才能讓預算真正支援產品決策。
