GPT-5.5 API成本怎麼算？快取、長Context、Batch與Priority

GPT-5.5 API 成本不能只看每百萬 Token 單價

這篇文章原本已經把 Input、Cached Input、Output、長 Context、Batch、Flex、Priority、工具呼叫與人工返工放在同一張成本表裡；接下來把判斷方法補得更精確。成本頁會更新，帳單也會因為模型版本、服務層、快取命中、重試和請求長度而變動，所以任何「每千次請求」的試算都要先寫清楚模型快照、日期、輸入輸出 token、是否命中快取、是否超過長上下文門檻，以及請求實際採用的 service tier。

截至 2026 年 8 月 17 日查核，OpenAI 官方 GPT-5.5 模型頁列出 1,050,000 token context window、128,000 token 最大輸出，以及 Standard 的每百萬 token Input 5 美元、Cached Input 0.50 美元、Output 30 美元；官方頁同時提示，估算輸入超過 272K token 時，Standard、Batch 與 Flex 會對整個 session 採用較高的輸入與輸出倍率。這些數字是官方頁在查核日的條件，不應直接套用到 GPT-5.5 Pro、其他模型或未來價格頁。

一、先把成本拆成五個可追蹤的桶

一個可用的成本模型，不是把帳單總額除以請求數，而是把每次工作拆成五個桶。第一桶是輸入 token，並再拆成未快取輸入與快取輸入；第二桶是輸出 token，包含模型產生的可見文字與可能計費的推理輸出；第三桶是服務層和長 Context 倍率；第四桶是工具、瀏覽器、向量檢索、程式執行器、網路、儲存與監控；第五桶是失敗重試、人工覆核、返工和資料治理。只記第一、二桶，最容易得到一個看似精準、實際不能用來做採購決策的數字。

建議在每次請求的 usage log 留下至少這些欄位：model、snapshot、service_tier、input_tokens、cached_tokens、output_tokens、reasoning_tokens（若回應提供）、tool_calls、retry_count、latency、任務是否通過驗收，以及任務最後是否需要人工修正。之後用「總成本 ÷ 通過驗收的任務數」計算 cost per accepted task；如果只用「總成本 ÷ API 請求數」，一個連續失敗十次後才由人工完成的工作，會被錯誤地算成十一個便宜請求。

可以用下面的概念式建立內部試算表：成功任務成本 = 未快取輸入費 + 快取輸入費 + 輸出費 + 長 Context 或服務層倍率 + 工具與基礎設施 + 重試 + 人工覆核。這不是替官方帳單重算，而是把不同工作流放在同一個比較單位。對同一批任務同時記錄完成率、P95 延遲、人工分鐘和資料風險，才知道價格下降是否真的帶來營運成本下降。

二、Prompt Caching 的省錢前提是「前綴完全相同」

Prompt Caching 最常見的誤解，是以為只要兩次請求包含相似資料就一定算快取。官方指南的核心條件是可重用的 prompt prefix 必須符合 exact prefix match；可預測的 system instructions、工具定義、輸出 schema 和固定規則應放在前面，會變動的使用者資料、日期、工單和檢索內容放在後面。若把 request id、目前時間或每次都變動的 schema 版本插在開頭，後面的長段落即使相同，也可能無法沿用同一個快取前綴。

因此，快取優化不是把所有歷史訊息無限堆進 prompt，而是設計穩定的請求形狀。可以把固定政策、工具 schema、格式要求和角色邊界固定在前綴；把任務內容、檢索結果和使用者資料放在尾端；再用 API 回傳的 usage.cached_tokens 觀察命中量。不要只從總帳單下降推論快取有效，因為同一時間可能也改了輸出長度、路由模型或重試次數。

快取命中也不代表輸出、工具和人工成本會一起按九成下降。Cached Input 只作用在符合條件的輸入部分；輸出仍可能是最大成本，工具服務也可能完全不在模型 token 單價裡。對 Agent 工作流，應分別比較 cache hit 與 cache miss 的完整成功任務成本，再確認品質、延遲和資料處理政策沒有因為追求長前綴而變差。

快取還要和資料治理一起設計。官方資料控管說明指出，prompt caching 可能在 GPU 本地儲存加密的 KV tensors；Responses API 的應用狀態、abuse monitoring logs、Zero Data Retention 與 Modified Abuse Monitoring 也有不同條件。這代表「快取很便宜」和「資料完全不留存」是兩個不同問題，必須由法務、資安和工程分開驗證。

三、長 Context 的費用與品質是兩條曲線

1,050,000 token context window 是規格上限，不是鼓勵每次都把整個知識庫塞進請求。當輸入靠近長上下文區間時，輸入費、輸出費、KV cache、網路傳輸、等待時間和失敗重試都可能一起增加；更長也不保證模型能在文件中找到正確句子，或把找到的資訊用在正確工具上。長 Context 的驗收至少要拆成放得進去、找得到、引用對、執行對四個問題。

本文原有的「超過 272K」試算，應理解為官方 GPT-5.5 頁目前列出的倍率條件，而不是所有模型、所有 endpoint、所有未來價格的通用規則。尤其 Priority 對長 Context 的適用條件，不能由 Standard、Batch 或 Flex 的規則反推；採購前應把 model、context 長度、service tier 和帳戶可用性一起送進小型試算，並保留查核日期。

工程上可以先做三段式分流。短任務使用完整固定前綴與短輸入；中等任務先做檢索，只帶入與問題相關的段落；真正需要長文件全貌的任務，才使用長 Context，並把超長輸入、輸出、重試和工具回合分別記錄。若檢索後的成功率與完整長 Context 相近，較短的輸入通常更容易快取、測試和控管，不能因為模型提供大窗口就取消資料分層。

四、Batch、Flex、Priority 不是同一種「打折或加速」

Batch API 適合可非同步處理的工作。官方指南把它定位在離線評測、分類、嵌入和其他不需要立即回覆的工作，並說明可用較低成本與獨立的 rate limits；一個 Batch 請求也有 JSONL、批次數量、檔案大小和 completion window 等約束。這讓它適合把一整晚的評測、內容標註或資料清理排成工作，但不適合把使用者正在等待的互動式 Agent 每一步都丟進去。

Flex Processing 是用較低成本換取較慢回應與偶發資源不可用。官方指南提醒 Flex 可能回傳資源不可用的 429，且不是每個模型都支援；適合非生產、低優先、評估和非同步資料豐富工作。若把 Flex 當作唯一的正式交易路徑，遇到資源暫缺時就會把節省的 token 費變成等待、重試和人工處理成本；穩健做法是有明確 timeout、退避和 Standard fallback，並在成本表列出 fallback 比例。

Priority 則是服務層選擇，不應簡化為「一定更快」或「所有任務都值得加價」。要檢查的是帳戶是否可用、該模型與輸入長度是否支援、實際回應回報的 service_tier、價格和速率限制。對延遲敏感的互動任務，Priority 可能有商業價值；對大量離線工作，Batch 或 Flex 的成本結構可能更合理。每種 tier 都要以同一批任務比較 P50、P95、錯誤率、完成率與成功任務成本，而不是只看第一次回應。

可把路由寫成一個簡單決策：需要立即回覆且失敗代價高，先用符合帳戶條件的 Standard 或 Priority；可延後、數量大、允許 24 小時窗口，評估 Batch；可延後、成本敏感、能接受偶發資源不可用，評估 Flex。這是工作流設計，不是永久模型承諾；官方價格、可用性與帳戶 tier 變更時，應重新跑小樣本。

五、不要把「模型價格」誤當成「Agent 價格」

GPT-5.5 API 的一次回答可能只是一個回合，也可能觸發搜尋、瀏覽器、資料庫、程式執行、函式呼叫和重新規劃。每個回合都可能帶著新的輸入前綴和工具結果回到模型，令輸入 token 和快取命中形狀改變。Agent 的實際成本因此與狀態機有關：工具是否重複、是否在錯誤時無限重試、是否把大份工具回傳原文再次送入、是否需要人工接管，都要進入 usage log。

最實用的觀測不是「平均每次幾個 token」，而是任務級的分布：成功任務的 token P50/P95、工具回合數、無效呼叫比例、重試比例、人工接管率、每任務外部服務費、延遲和最後驗收結果。若把工具回傳截斷或先做結構化摘要能保留同樣完成率，就可能比單純更換模型更有效；若縮短 prompt 讓工具選錯，則表面上省錢，實際上提高了返工成本。

對有副作用的工具，成本和風險要一起算。建立訂單、發送信件、修改資料或發布文章前，應有去重鍵、權限檢查、預覽和可回讀證據；一次錯誤寫入造成的客服、退款或修復時間，通常遠高於那次 API token。成功任務的定義應包含外部狀態正確，不是模型輸出看起來完整。

六、用 30 個任務把成本假設變成可比較證據

第一輪 PoC 可以準備 30 個真實但去識別化的任務：10 個一般互動、6 個長文件、5 個需要快取前綴、4 個工具寫入、3 個故障恢復、2 個明確需要拒絕的高風險案例。每題固定輸入資料、工具 schema、驗收規則和時間限制，分別測 Standard、Batch 或 Flex 適用的離線工作；只有適合即時的任務才加入 Priority 比較。不要讓不同 tier 使用不同題目，否則價格差異會被任務難度混淆。

每個任務至少跑三次，記錄 model snapshot、service tier、cache hit/miss、輸入與輸出 token、是否超過 272K、工具回合、P50/P95 延遲、429 或其他失敗、重試、人工修正分鐘、資料治理事件和最後是否通過。結果表要同時呈現「每成功任務成本」與「成功率」，例如 A 路由每次便宜但只有 70% 通過，B 路由較貴但有 95% 通過，不能只用單次 token 費判斷 A 勝出。

可以把結果分成四個營運門檻：互動品質、成本上限、延遲上限、資料與權限安全。只要其中一項未達標，就把該路由標為需修正，而不是用平均數掩蓋尾端失敗。對 Batch 和 Flex 特別保留未完成、超時和資源不可用的案例；對 Priority 保留實際 service tier 與長 Context 限制；對快取保留 cached_tokens，而非只保存總 token。

七、API 成本試算表的欄位與公式

內部試算表可以一列代表一個「成功任務」，欄位順序建議是：任務 ID、模型與 snapshot、service tier、未快取輸入、快取輸入、輸出、長 Context 狀態、模型 token 費、工具服務費、基礎設施分攤、重試費、人工分鐘、是否通過，以及總成本。這樣從 GPT-5.5 改到其他模型時，仍能保留相同驗收口徑；只要更新價格和路由欄位，不必重寫整份方法。

若需要做情境分析，可以建立三種情境而不是只報一個預測值。保守情境使用 cache miss、較長輸出、一次重試和較高人工覆核；基準情境使用實測 P50；樂觀情境使用實測 cache hit、短輸出和穩定工具。每種情境都要附上實測樣本數與日期，不能把官方標價直接當成全公司年度成本。年度預算還要加入 rate limit、尖峰排隊、模型版本切換和價格變更的緩衝。

最後，月度報表要把「量」和「品質」分開看。API 請求量增加不一定是壞事，可能是成功任務增加；單價下降也不一定是好事，可能是重試和人工返工變多。每月至少回顧成功任務數、每成功任務成本、快取命中率、長 Context 比例、Batch/Flex/優先服務層占比、失敗與重試、P95 延遲和人工接管率，才能知道優化是否真的穿透到業務結果。

常見問題：GPT-5.5 API 成本與服務層

GPT-5.5 目前單價可以直接寫死在產品預算嗎？

不建議。可以把官方模型頁的查核價格作為基準，但預算還要帶上模型快照、使用量、快取命中、輸出長度、長 Context、service tier、工具、重試和人工。價格頁更新時，重新執行同一批任務，比直接把新單價乘上去年請求量更可靠。

Prompt Cache 命中後是不是整個請求都打折？

不是。它只降低符合 exact prefix match 的輸入部分；輸出、工具服務、重試、人工和其他基礎設施仍需另外計算。請直接讀 usage.cached_tokens，並比較完整成功任務成本。

Batch 適合多回合 Agent 嗎？

若每個回合需要使用者立即看到結果或依上一回合決定下一步，就不適合把整段互動當成 Batch。若是離線評測、分類、資料豐富或預先生成，可以把獨立請求批次化；多回合流程仍要先確認可否拆成獨立、可重試和可驗收的工作。

Flex 比 Priority 便宜，是否所有工作都應改用 Flex？

不是。Flex 的設計取向是較低成本、較慢且可能資源不可用；Priority 的價值則在符合條件時處理延遲敏感工作。用任務的截止時間、失敗代價、fallback 能力和實測完成率決定，不要用單一價格排序所有工作。

快取代表資料不會被保留嗎？

不代表。快取、abuse monitoring、Responses 應用狀態、第三方工具或 MCP 的保存條件不同；敏感資料要按官方資料控管頁、帳戶設定、合約與組織政策逐項確認。成本優化不能取代資料分類與留存審查。

官方資料與查核範圍

• OpenAI 官方 GPT-5.5 模型頁：context、輸出上限、價格與長 Context 條件
• OpenAI 官方 Prompt Caching 指南：exact prefix、cached_tokens 與請求排序
• OpenAI 官方 Batch API 指南：非同步工作、JSONL、成本與完成窗口
• OpenAI 官方 Flex Processing 指南：較低成本、延遲與資源不可用
• OpenAI 官方資料控管指南：abuse monitoring、Responses 狀態與資料保存條件

本文的實務結論是：先用官方頁確認模型、日期和條件，再用同一批任務記錄 cache hit、長 Context、Batch、Flex、Priority 或 Standard 的實測結果，最後以每個成功任務成本做路由決策。若沒有 usage、失敗、工具和人工資料，任何精確到小數點的 API 成本答案都只是單價換算，不是完整的營運成本。