如何分析你的 LLM 用量檔案
每一筆 LLM 帳單背後都有一份檔案：服務商會交給你的用量匯出，逐列、逐模型、逐日。大多數人從不打開它，因為原始匯出是一堵 token 計數之牆，沒有總數、沒有結論。本指南說明從哪裡取得這份檔案、它裡面到底有什麼，以及一旦能清晰地看到它，值得尋找的三種模式——使用本站的 LLM usage analyzer（LLM 用量分析器），它只在你的瀏覽器裡讀取檔案，別無他處。
最後更新:
從哪裡匯出用量
從服務商保存數字的地方開始。OpenAI 在兩個地方提供用量：服務商主控台的用量頁，彙總目前計費週期內按日和按模型的活動；以及用量 API，以 JSON 返回相同資料——時間桶，每個桶含按模型彙總的結果，包含上下文 token、生成 token 和請求數。這個 JSON 形式值得了解，因為它是可以封存、對比並無需截圖就能餵給工具的那一種。今天就值得養成的習慣：每月拉一次 API 回應並保存。服務商在主控台只保留有限視窗的歷史；你自己的封存是你實際花費的唯一完整記錄，逐月如此。
Anthropic 以同樣的精神透過其主控台和報告 API 提供用量與成本報告：按日和模型彙總，可匯出為表格資料。其他服務商精緻程度不同，種類卻相同——從用量或帳單頁下載 CSV，或一個返回帶日期列資料的 API 端點。通用形式就是任何分析所需要的：一欄日期、一欄模型名稱、輸入 token、輸出 token，運氣好時還有快取 token、請求數和成本欄。如果服務商提供多種匯出，選擇它提供的最細粒度那一種——按日的按模型資料勝過按月的按項目資料，因為你自己做的彙總總能撤銷，服務商做的彙總卻不能。
檔案裡到底有什麼
一列用量是一個小而密集的主張：在這一天，這個模型服務了這麼多請求，讀了這麼多輸入 token——其中這麼多是快取的——寫了這麼多輸出 token。讀一份帶這些欄的檔案，你幾乎可以重建工作負載形狀的一切：提示詞是長是短、回答是否囉嗦、流量穩定還是突發、哪些模型在做真正的工作。檔案刻意不包含的內容同樣重要：沒有提示詞文字、沒有補全內容、沒有使用者內容。它是計數和名稱，這也是為什麼它可以比它所描述的流量更自由地處理——儘管正如最後一節所說，「更自由」不等於「任何地方都可以」。
有兩欄在分析前值得懷疑。第一欄是成本：有些匯出帶的是計費成本，有些帶的是標價估算，有些根本沒有，而檔案很少標明是哪一種。把成本欄當作服務商的數字，但在信任總數之前先核對日期範圍和被跳過或部分缺失的列。第二欄是快取 token 欄，服務商至少有五種不同命名方式，有時還把它摺疊進輸入計數而不單獨列出。如果輸入 token 對該模型來說便宜或昂貴得不合常理，表頭是第一個要看的地方——這正是分析器會展示其從表頭偵測到的欄對應、並讓你在計算任何東西之前糾正它的原因。
要找什麼：三種模式
第一，快取 token 比例。用快取輸入除以總輸入，按模型計算。任何有重複結構的工作負載——系統提示詞、文件前綴、固定的工具模式——都應該快取其輸入的很大份額，因為那個前綴在每次呼叫時都相同。在這樣的工作負載上比例接近零，意味著快取被關閉、快取在呼叫之間過期，或前綴中的某樣東西每次請求都在變——時間戳記、隨機 id、被重新排序的欄位——並悄悄破壞了它。修復這一個數字通常比重新談判模型更值錢，因為在每個主要服務商那裡，快取輸入都按全額費率的一小部分計費。
第二，模型組合。按成本而不是請求數對模型排序：當昂貴層級的成本份額大致與其真正需要的工作份額相符時，組合是健康的。要警惕的漂移是：旗艦模型的成本份額逐月上升而其請求份額持平——更長的提示詞、更長的輸出，或新流量被一個沒人記得設定過的預設值悄悄路由到大模型。第三，集中與尖峰：一個 API 金鑰、項目或模型主導檔案，既是成本事實也是爆炸半徑事實；而按日的尖峰——尤其在週末或夜間、沒人工作時——是重試迴圈、失控智能體或被濫用的洩漏金鑰的標誌。按日表格的存在就是為了讓那個尖峰不可能被錯過。
為不帶成本的檔案定價
許多匯出根本沒有成本欄，這時分析必須自己為檔案定價。分析器以透明的方式做這件事：每列都用本站 LLM pricing（LLM 價格）表定價——cost calculator（成本計算器）也使用的已核對標價——用服務商自己的公式：未快取輸入按輸入費率，快取輸入按快取費率（如有），輸出按輸出費率。模型名稱嚴格配對：精確配對、去掉服務商前綴後配對，或剝離末尾日期或 “latest” 後綴後配對。這種嚴格正是關鍵所在。更寬鬆的模糊配對最終會把微調模型當作其基礎模型定價，或把預覽當作正式版定價，總數會獲得它未曾掙得的置信度。
這正是為什麼配對不到任何條目的模型會被列出，而不是猜測。它們的 token 和請求仍然計數——你能看到其流量並判斷缺口是否重要——但成本留空，結果會標明其金額來自哪裡：檔案本身、由表計算、混合或無。讀任何計算出的總數時都要以這個標準衡量它：它是標價算術，不知道你的折扣、額度、批次費率或分層長上下文定價，所以不會與帳單精確到分地對上。它可靠做到的是排序：哪些模型、哪些日期、哪些模式主導了帳單。在成本工作中，排序通常是與決策相關的部分。
隱私，以及一套每月例行程序
用量檔案不含提示詞文字，但它在維運上仍然敏感：它點名你運行的每個模型、你按日的流量、你的增長曲線和你的支出——一套系統如何建構的、具競爭與安全相關性的指紋。這正是 LLM usage analyzer（LLM 用量分析器）在你的瀏覽器本機解析檔案、絕不上傳的原因。這條通用規則遠不止適用於這一個工具：一份檔案越是能概括你的基礎設施，把它貼到託管聊天或未知轉換器裡就越是壞主意，哪怕檔案字面上不含秘密。彙總資料也會洩漏，只是更安靜。
最後給一套小到真的能發生的例行程序。每月一次：匯出檔案，分析它，寫下四個數字——總成本及其來源、頭部模型的成本份額、快取 token 比例、最大的單個日期。與上個月的四個數字比較。這五分鐘的差異對比能在漂移、尖峰和失效的快取還便宜時抓住它們，一年下來能建立起任何服務商主控台都不會為你保留的封存。帳單只會讓只讀帳單的人吃驚。它們很少讓讀用量的人吃驚。
常見問題
該用哪種匯出——主控台 CSV 還是用量 API JSON？
都可以；它們描述同一活動。主控台 CSV 取得最快，足夠一次性查看。API JSON 是更好的習慣：它完整、可指令碼化、可封存，並以穩定形式攜帶按模型的 token 欄位（上下文、生成、如有的快取以及請求數）。如果兩者不一致，先檢查日期範圍和時區——主控台視圖通常以本機時間顯示，而 API 的桶是 UTC，這會移動一天的邊界，把支出在相鄰日期間挪動，總數卻不變。
我的快取 token 比例接近零。什麼會破壞提示快取？
通常的原因按順序是：流量所走路線上未啟用快取或不提供快取；呼叫間隔超過快取壽命，每個條目在複用前過期；或提示前綴在呼叫之間並非真的相同——注入的時間戳記、每請求 id、被打亂的工具列表或使用者專屬的第一條訊息，都會改變前綴並使快取未命中。在開頭逐位元組比較兩個原始請求：最先不同的地方就是快取停止配對的地方。修復方法是把所有可變內容移到穩定、共享的前綴之後。
為什麼工具不為我的一些模型估算價格？
因為在其表中對那個名稱不存在誠實的價格。微調繼承基礎模型的引擎，卻不一定繼承其價格，預覽的計費常與正式版不同，第三方部署遵循自己的合約——猜測其中任何一個都會讓總數看起來完整，卻讓它變錯。工具改為列出那些模型及其流量，讓你能從合約或帳單中自行定價那部分，並把每個數字的來源保持清晰地加入計算總數。