「模型少用了 20% Token，所以 API 費用也會少 20%」——這是評估新模型時最容易出現、卻不一定成立的想法。
真正影響帳單的，通常不只是模型回覆了多少文字。一次任務可能還包含重複傳送的上下文、隱藏的思考內容、工具呼叫、失敗重試，以及為了達到相同品質而增加的執行輪次。模型更省 Token 是甚麼意思，必須放回完整任務、成功率和實際計費規則中理解，才不會把宣傳數字誤當成遷移收益。
模型更省 Token 是甚麼意思？先拆解四種消耗
模型所謂「更省 Token」，可能只代表其中一個環節變短，未必代表整個工作流程變便宜。常見消耗可拆成以下四類：
| 消耗來源 | 具體內容 | 可能造成的成本變化 |
|---|---|---|
| 輸入 Token | 系統提示詞、使用者問題、對話歷史、文件內容 | 多輪對話會重複傳送，總量可能持續增加 |
| 輸出 Token | 最終回答、程式碼、JSON、錯誤訊息 | 回答變短通常有利，但可能需要更多修正輪次 |
| 思考與中間結果 | 推理內容、規劃步驟、模型自我檢查 | 外部不一定完整顯示，但部分服務可能納入計費 |
| 工具與重試 | 搜尋、資料庫、Shell、API 呼叫及失敗重跑 | 單次回覆變短，仍可能因呼叫次數增加而變貴 |
例如，程式助手原本一次就能產出可執行的修補方案；新模型雖然每次輸出較短，卻需要連續呼叫測試工具、讀取錯誤日誌，再產生第二版修改。單看其中一次回答，確實省了 Token；看完整任務，總消耗可能反而增加。
因此，評估時應把「每次請求」改成「每項任務」。任務的起點是使用者提出需求，終點則是得到符合驗收標準的結果，而不是模型第一次回覆結束。
Token 減少了，為甚麼 API 帳單可能沒有下降？
輸入與輸出的單價不一定相同
不同服務通常會分開計算輸入與輸出，且兩者單價可能存在明顯差異。若新模型主要縮短輸出，但你的工作流程仍然反覆傳送大型系統提示詞、對話歷史或長文件，節省幅度就可能被輸入費用抵銷。
大模型 API 的比較，不能只看「每百萬 Token 的最低價格」。至少要同時記錄：
- 輸入 Token 數量；
- 輸出 Token 數量；
- 是否包含思考或中間結果；
- 快取命中與未命中部分；
- 工具呼叫和重試是否另行計算；
- 同一任務實際發出多少次請求。
一個簡化的 Token 成本計算公式如下：
總成本 = 輸入 Token × 輸入單價 + 輸出 Token × 輸出單價 + 快取未命中成本 + 工具及重試成本
這不是所有供應商的完整計價公式，但足以提醒團隊：模型名稱和輸出長度只是成本模型的一部分。
失敗率上升，會把節省吃掉
如果新模型在結構化輸出、工具參數或長文件理解方面較不穩定，應用程式可能需要重新請求。假設一次任務平均需要 1.2 次呼叫，換成新模型後變成 1.5 次，即使每次呼叫少用一部分 Token，總任務成本也未必下降。
重試不只帶來額外計費，還可能增加：
- 伺服器處理時間；
- 使用者等待時間；
- 併發數與頻寬壓力；
- 下游 API 的請求次數；
- 除錯和人工檢查成本。
呼叫次數增加，單次便宜也沒有用
AI Agent 特別容易出現這種情況。新模型可能更傾向先拆解任務、檢查環境、讀取工具結果，再決定下一步。這種行為有機會提升完成率，但也會令每個使用者任務包含更多模型回合。
| 評估方式 | 看到的結果 | 容易漏掉的問題 |
|---|---|---|
| 單次請求成本 | 新模型每次消耗較少 | 沒有計入重試和工具回合 |
| 每個回答 Token | 回答文字更精簡 | 沒有計入被重複傳送的上下文 |
| 每項完整任務成本 | 從開始到成功完成的總成本 | 需要建立一致的成功標準 |
| 每個有效結果成本 | 成本 ÷ 通過驗收的任務數 | 最能反映產品實際支出 |
真正值得比較的指標，通常是「每個有效結果的成本」，而不是某次請求顯示的 Token 數。
多輪對話和 AI Agent，為甚麼不能只看單次呼叫？
多輪對話的成本放大，通常來自上下文累積。假設每一輪都把完整歷史訊息傳回模型，輸入 Token 可能形成近似線性甚至更高的增長。當對話加入規則、文件、工具結果和錯誤紀錄後，後面每一輪都可能攜帶更多內容。
AI Agent 的成本鏈則更複雜：
- 模型接收系統提示詞和使用者目標；
- 模型決定是否呼叫工具；
- 工具回傳資料；
- 應用程式把結果重新放入上下文；
- 模型分析結果並決定下一個動作；
- 直到完成、失敗或達到輪次上限。
如果工具回傳的是完整網頁、整份日誌或大量資料庫欄位，問題就不只在模型輸出，而在每次回合都重新傳送大段內容。
建議為 Agent 設定明確上限，例如：
- 單項任務最多 8 次模型回合；
- 單次工具回傳限制字數或欄位數；
- 連續兩次相同工具呼叫時中止；
- 超過預算後轉人工或改用較簡單流程；
- 每項任務保存完整 trace，而非只保存最後答案。
這些是工程上的防護設定，不是所有情境都應採用相同數值。正式上線前，應根據任務完成率和錯誤分布調整。
新舊模型怎樣做公平的成本對照測試？
模型遷移成本不只是改一個 model ID。若測試條件不一致，團隊很容易得到錯誤結論。可以按照以下步驟執行：
1. 建立固定任務集
從真實流量抽取代表性任務，不要只挑容易回答的短問題。至少分成程式修改、長文件摘要、客服回覆、資料抽取和 Agent 工具操作等類別。
建議先建立 30 至 50 個固定案例，並保留原始輸入、必要上下文和預期結果。這個數字屬於測試規模建議，不是模型服務的官方要求。
2. 固定成功標準
「回答看起來不錯」不足以作為驗收。應把標準寫成可判斷的條件，例如：
- 程式能否通過既有測試；
- JSON 是否符合指定結構；
- 文件摘要是否涵蓋必要段落；
- 客服答案是否包含政策要求；
- Agent 是否完成工具操作而非只描述做法。
3. 記錄每一次請求明細
不要只在前端統計總額。每次呼叫至少保存模型名稱、時間、輸入 Token、輸出 Token、快取狀態、工具名稱、回合編號、錯誤類型和重試原因。
若供應商提供 usage 或 request ID，應一併保存，方便之後核對帳單。
4. 使用相同提示詞與工具條件
新舊模型必須使用相同的系統提示詞、文件版本、工具描述和溫度等參數。若為了讓新模型表現更好而同步改寫提示詞，這是產品整體升級測試，不應再稱為單純模型成本比較。
5. 重複測試並觀察分布
具有隨機性的模型不能只跑一次。每個案例至少重跑 3 次，比較平均值、中位數和最差情況。若任務結果差異很大，平均成本可能掩蓋少數極貴的異常任務。
6. 計算每個有效結果的成本
可用以下方式整理：
有效結果成本 = 全部呼叫成本 ÷ 通過驗收的任務數
再加入人工修正時間，便能更接近產品真正承擔的成本。對某些工作流程而言，模型帳單只佔總成本的一部分，人工覆核和等待時間反而更值得關注。
程式、長文件和客服任務，應該看哪些指標？
不同任務不能使用同一個「省 Token」標準。
程式開發：看一次完成率和修正輪次
程式助手應記錄測試通過率、成功修改比例、工具呼叫次數、重試率和人工改動行數。輸出短不一定代表效率高；如果少寫一段說明，卻多跑兩輪測試，總成本可能沒有改善。
長文件：看有效資訊密度和重複傳送量
長文件任務應特別記錄文件是否重複上傳、上下文裁剪後是否遺失關鍵內容，以及模型是否需要重新追問。除了 Token 數，也要觀察摘要覆蓋率、引用正確率和完成時間。
客服：看每個解決案件的成本
客服流程最重要的不是單次回覆短，而是能否在不轉人工的前提下解決問題。建議把首次解決率、轉人工率、重複追問次數和每宗已解決案件成本放在一起看。
提示詞快取和上下文裁剪，具體怎樣降低帳單？
如果每次請求都包含相同的角色規則、產品手冊或工具描述，應先確認服務是否支援提示詞快取，以及快取命中部分如何計費。常見可快取內容包括：
- 長期不變的系統提示詞；
- 固定格式的工具定義；
- 不常更新的產品規格；
- 企業內部政策和分類規則。
可變內容則應放在提示詞後段，例如當前問題、即時狀態和本輪工具結果。這樣較容易形成可重用的前綴。
上下文裁剪也不能只用「刪除最舊訊息」處理。更穩妥的方法是：
- 保留系統規則和目前任務目標；
- 將較早對話壓縮成結構化摘要；
- 只保留與當前任務相關的工具結果；
- 對大型日誌先做篩選，再傳送給模型；
- 設定上下文長度和單項任務預算。
你可以使用官方 Token 計算工具檢查提示詞大致會被切分成多少 Token，但實際帳單仍應以服務回傳的 usage 欄位和正式計費規則為準。
模型遷移後，怎樣設定預算告警和異常監控？
上線後不要只看每日總帳單，因為總量上升可能只是使用者增加，也可能是某一條 Agent 流程失控。建議至少分成四個維度：
- 按任務類型：程式、客服、摘要、資料抽取；
- 按使用者或團隊：找出異常高用量群組；
- 按模型與版本：比較遷移前後差異；
- 按呼叫鏈：追蹤哪個工具或哪一輪最耗費 Token。
可設定三層告警：
- 每日或每月預算接近上限時提醒；
- 單項任務超過平均成本時標記；
- 重試率、工具回合或輸出長度突然上升時自動暫停。
除了金額，也要監控 p95 任務成本、p95 完成時間、失敗率和每個有效結果成本。若只設定總金額告警，往往要到月底才發現某個工作流程已經持續浪費資源。
怎樣拆解真實任務的遷移前後差異？
在實際評估中，不應用估算值代替本站呼叫記錄。建議將同一項任務拆成「輸入、模型回覆、工具、重試、最終結果」五段，逐段對照新舊模型：
- 第一次輸入是否包含相同資料；
- 模型是否多產生思考或規劃回合；
- 工具回傳內容是否被完整帶回；
- 是否因格式錯誤而重試；
- 最終結果是否需要人工修正。
如果新模型的單次輸出少了，但工具回合增加，應把差異歸因於「流程成本上升」，而不是直接寫成模型失敗。反過來，如果輸出沒有明顯變短，卻因成功率提高而減少重試，整體任務成本仍可能下降。
這也是為甚麼本站的實際測試，應以真實呼叫記錄、相同任務樣本和可驗收結果為依據；沒有完整 trace，就不應宣稱某次遷移節省了固定比例。
評估 Token 節省，最容易踩中哪些坑？
只測短提示詞
短問題無法反映長文件、固定規則和多輪歷史帶來的輸入成本。生產環境若大部分請求都帶有長上下文，短提示詞測試會嚴重高估節省效果。
混用不同任務和不同成功標準
新模型測摘要，舊模型測程式修復，最後再比較平均 Token，結果沒有意義。任務類型、資料版本和驗收方式必須一致。
把官方估算當成生產帳單
官方能力說明和價格頁能提供計費規則，但無法知道你的重試率、快取命中率、工具回傳量和使用者行為。公開資料適合建立假設，不適合直接代替實際帳單。
忽略人工修正成本
模型若輸出稍短，但每宗案件多花幾分鐘人工整理，節省的 API 費用可能很快被抵銷。對客服、報告生成和程式修改尤其如此。
只看平均值
少數超長上下文或失控 Agent 任務，可能佔用大部分預算。除了平均值，至少要看中位數、p95 和最高成本案例。
需要隔離測試環境時，怎樣降低遷移風險？
若團隊目前直接在共用伺服器或正式環境切換模型，常見缺點是測試流量會污染正式帳單、不同開發者互相爭用資源，而且 Agent 的完整呼叫鏈不容易重現。當新舊模型需要並行驗證時，還會遇到權限、環境依賴和日誌保存不完整等問題。
相較之下，租用獨立的雲端 Mac 環境，可以把測試程式、憑證、瀏覽器狀態和模型呼叫記錄分開管理，較適合進行短期 A/B 測試、重現 Agent 流程，以及持續記錄每項任務成本。你可以先參考 ZilCloud 的雲端 Mac 方案，再按測試週期安排資源；若需要隔離環境與實際操作協助，也可查看 ZilCloud 的服務說明。
重點不是為了換一台電腦而換環境，而是讓模型遷移有可重複、可追蹤、可回退的測試空間。當團隊需要同時驗證程式、長文件和 AI Agent 工作流程時，這通常比在正式伺服器上邊改邊猜更容易控制大模型調用成本。