AI API 成本追蹤：Token 與模型群組

AI API 成本追蹤要真正有用，每一筆費用都應能對應到一筆請求、一個模型、一個模型群組，以及實際計量的工作單位。月度總額只能告訴你支出變了；單筆請求記錄才能回答為什麼。

Modelflare 將模型價格、計量用量、群組政策與請求記錄放在同一條證據鏈上，避免只根據畫面上看得到的文字估算費用。

一筆請求費用的四個層次

1. 模型價格

每個模型都有自己的計價基礎。多數文字模型分別計算輸入與輸出 Token；圖片、音訊、重新排序或其他 API 可能使用不同計量單位。有些功能也會套用版本化的進階定價規則，無法用單一 Token 單價表示。

請以模型與價格中的即時模型與 API 格式契約為準，不要把價格直接寫死在應用程式中。

2. 實際計量用量

閘道會記錄已完成請求由上游回傳或推導出的用量。對 Token 計價的文字模型，輸入與輸出會分開保存，因為兩者單價可能不同。

終端機中看到的串流文字不是可靠的計費依據。工具項目、推理內容、快取輸入、正規化 Token 或供應商專屬用量欄位，即使沒有以一般 Assistant 文字顯示，也可能納入計費。

3. 模型群組倍率

實際選用的路由群組可以對基礎用量費用套用銷售倍率。例如群組倍率為 0.9，代表該筆請求按模型基礎費用的 90% 計算。

群組倍率只影響用量計費，不會改變儲值實際加入錢包的額度。

4. 最終請求記錄

用量記錄會把計算結果與模型、群組、狀態、Token、時間及其他安全營運資料連結起來。失敗或取消的請求可能走不同結算路徑，因此資料庫中保存的結果，比用戶端自行估算更具權威性。

用量記錄應比較哪些項目

支出變動時，可依下列面向逐項比對：

• 模型： 流量是否切到輸入、輸出或功能價格不同的模型？
• 群組： 實際主要或備援群組是否使用不同倍率？
• 協定： Chat Completions 與 Responses 之間切換後，用量結構是否不同？
• 輸入大小： Prompt、檢索內容、檔案或工具結果是否增加？
• 輸出大小： 輸出上限或 Agent 迴圈是否產生更多內容？
• 狀態與重試： 失敗是否又觸發其他成功完成的嘗試？
• 時間： 生成時間變長是否真的伴隨更多輸出，還是只是排隊等待？

請用穩定的請求 ID 或應用程式專用金鑰鎖定工作負載，不要把帳戶內無關流量混在一起比較。

設定可執行的成本邊界

依工作負載拆分 API 金鑰

正式環境、開發環境、自動化與個人工具應各自使用不同金鑰。每把金鑰都能設定名稱、到期日、群組政策，以及有限或不限額度。

有意識地選擇群組

不要只看群組名稱。請檢查即時模型供應、倍率、存取條件、RPM 與備援政策。價格較低的主要群組搭配可接受的備援，往往比難以說明的隱性路由更容易預測。

先減少輸入，再限制輸出

過長的 System Prompt、重複對話紀錄、檢索文件與工具結果，經常是輸入用量的大宗。移除不再影響答案的上下文；用戶端能安全參照或快取的資料，也不要每次重送。

檢查 Agent 迴圈

一次使用者操作可能觸發多筆模型請求。請逐輪追蹤工具呼叫與重試，不要把最後看到的一段答案當成唯一一次 API 呼叫。

為什麼用戶端估算會有落差

本機 Tokenizer 或字元數適合做容量規劃，但可能與實際計費不同，原因包括：

• 供應商可能以不同方式正規化或計算內容；
• 快取、推理、圖片、音訊或工具單位可能有獨立價格；
• 閘道結算使用實際選中的模型與群組；
• 失敗與退款取決於真實請求生命週期；
• 價格可能更新，但舊請求仍保留當時已記錄的結果。

進行財務核對時，應比對已保存的用量與錢包記錄，不要從單一畫面欄位反推帳戶餘額。

可重複執行的檢查流程

1. 依一把 API 金鑰與時間範圍篩選用量記錄。
2. 按模型與實際群組整理請求。
3. 比較每筆請求的輸入、輸出、狀態與費用。
4. 檢查離群值是否來自重試、過長上下文、工具迴圈或備援切換。
5. 改變路由前，再次確認即時價格與群組政策。
6. 工作負載需要硬性支出上限時，為金鑰設定有限額度。
7. 調整後用相同指標重新檢查。

成本控制的起點是正確歸因。模型、群組、用量與結果只要始終相連，團隊就能針對真正的支出來源優化，而不是從彙總數字猜測。