除錯成本差異

LiteLLM 與您的提供者帳單之間的成本差異，通常來自三個面向之一：token 匯入、LiteLLM 套用的成本公式，或模型對照表中過時或錯誤的定價。本頁將說明如何判斷您屬於哪一種情況。

步驟 1：選擇時間範圍

先鎖定一個可看出差異的特定時間區間。

• 能用的話，請至少使用 7 天的資料。
• 優先選擇使用量穩定的區間，避免單次尖峰主導比較結果。
• 在您的提供者儀表板與 LiteLLM UI 上，設定相同的開始與結束時間。

步驟 2：確認流量只經由 LiteLLM

如果有任何請求直接打到提供者（繞過 LiteLLM），提供者就會顯示較高的使用量。這是預期行為，不是 LiteLLM 的錯誤。

繼續前請先確認：

• 所有用戶端都使用您的 LiteLLM proxy base URL。
• 沒有任何 SDK 或腳本針對您正在比較的模型，直接使用提供者 API 金鑰連到提供者。
• 在所選期間內，相關模型只透過 LiteLLM 被呼叫。

如果您不確定，請依 LiteLLM 使用的 API 金鑰或 IAM principal 篩選提供者儀表板，而不是拿整個帳戶來比較。

步驟 3：比較 token 類別

在 LiteLLM UI 中，開啟 Model activity（位於 Usage analytics 下方），即可檢視每個模型的支出與 token。

捲動 Model 清單，並選取您要與提供者帳單對帳的模型。

在兩邊使用相同的時間範圍後，填入：

類別	LiteLLM	提供者	差異
總請求數	—	—	—
輸入 token	—	—	—
輸出 token	—	—	—
快取讀取 token	—	—	—
快取寫入 token	—	—	—

LiteLLM 會針對所選模型顯示各類別 token 使用量，例如 prompt、completion，以及與快取相關的 token。

請將這些數字與您提供者的使用量檢視畫面（例如 AWS billing tools、Azure Monitor 或 OpenAI usage dashboard）在相同期間內的資料進行比較。

快取 token 回報

• OpenAI： 快取讀取 token 通常會包含在回報的輸入 token 數量中。
• Anthropic： 快取讀取 token 通常會與未快取的輸入 token 分開回報。

請比較雙方正確的欄位，避免在不同儀表板之間以不同方式解讀「輸入」。

為什麼使用 10% 門檻？

提供者儀表板與 LiteLLM 不會在完全相同的時間戳記上為請求分桶。晚上 11:59 的一個呼叫，在兩邊可能會落入不同的每日總計。由於不同 SDK 與 API 的四捨五入方式，token 數量也可能略有差異。低於約 10% 的差異，通常可由邊界效應與四捨五入解釋；高於約 10% 的差異，通常表示有東西被計算錯誤、遺漏，或分類不同。

步驟 4：走對應的路徑

路徑 A：Token 數量不符

如果任何類別偏差超過約 10%，LiteLLM 可能沒有正確匯入該類別（或提供者儀表板對 token 的分類不同——請先重新檢查步驟 3）。

請提供給 LiteLLM 團隊的內容：

1. 兩個儀表板在顯示日期範圍時的截圖。
2. 哪個類別有差異（輸入、輸出、快取讀取、快取寫入，或請求數）。
3. 使用的端點（例如 /chat/completions、/responses、/embeddings）。
4. 請求中傳送的模型名稱（例如 anthropic.claude-opus-4-5、gpt-4o）。

供維護者除錯 ingestion

1. 以 verbose logging 啟動 proxy，例如：

   litellm --config config.yaml --detailed_debug

2. 使用回報的 endpoint 和 model 重現單一請求。
3. 檢查每個 streamed chunk（若有 streaming）或最終 response body 中的原始 usage object。
4. 將其與標準 logging object（或該次呼叫的 UI request log）比較。
5. 原始 provider usage 與 LiteLLM 記錄或彙總之間的任何落差，都是 ingestion 可能出錯的地方。

路徑 B：數量一致但 cost 錯誤

如果 token 和 request 計數在約 10% 內一致，但金額不同，請聚焦於 cost 的計算方式。

B1：公式問題

使用 provider 的 token breakdown 與公布費率（每百萬 tokens 或每 token）手動計算預期 cost。

加上 provider 適用的其他計費維度（例如 cache 建立、audio，或 tier surcharge）。如果您的手動計算與 provider 帳單一致，但與 LiteLLM 不一致，則 LiteLLM 中該 provider 或 modality 的實作可能有誤。

B2：model map 問題

如果公式結構與 provider 的計費方式一致，LiteLLM 的 model map 中的值可能已過時或不正確。請交叉檢查：

• model_prices_and_context_window.json
• provider 目前的公開定價

檢查您確切 model id（包含 provider 前綴）的 input_cost_per_token、output_cost_per_token，以及任何與 cache 相關的定價欄位。

供維護者

1. 以使用者的 provider 報告取得權威性的 token 數量。
2. 推導出可重現 provider 明細項目的公式。
3. 將其與 LiteLLM 對同一 provider 與回應形狀的 cost 路徑進行 diff。
4. 如果公式一致但數值不同，請更新 model_prices_and_context_window.json 中的定價（並遵循該檔案的專案同步 / 備份規則）。
5. 如果程式碼中的公式有誤，請修正計算並使用使用者的 token breakdown 新增迴歸測試。

還卡住嗎？

1. 在 BerriAI/litellm 開立 GitHub issue，附上您的 Step 3 比較表、endpoints，以及 model 名稱。

在 issue 中，以下資訊很有幫助：

• 可按需重現，還是間歇性發生？
• 單一 model 還是多個？
• 隨時間穩定，還是從特定 release date 或 config 變更開始？

供 LiteLLM 維護者

如果在 triage 後 Path A 和 Path B 都無法結案，您應該主動聯繫並安排與客戶的通話（support 或 engineering），並帶上 Step 3 表格和截圖——在將此問題定性之前。

檢查清單

□ Same time range on both dashboards
□ Confirmed no direct-to-provider traffic for those models
□ Compared: requests, input tokens, output tokens, cache tokens
□ Noted cache reporting differences (OpenAI vs Anthropic, and so on)
□ If > ~10% delta on quantities → Path A: report with screenshots, endpoints, model names
□ If quantities match → Path B: verify formula (B1) and model map pricing (B2)
□ If neither path fits → open a GitHub issue.

另請參閱

• 支出追蹤
• 從 GitHub 同步 model pricing