你的服務商發來一張賬單。你大致能認出總額，然後有人問出真正重要的問題：哪個功能、哪個團隊、哪個客戶？如果沒人答得上來，問題不在賬單。LLM API 成本歸屬失敗的原因更簡單：你應用發起的那些呼叫，從來沒有帶著足夠的上下文被記錄下來，好把總額拆成若干部分。
當兩件事同時成立時，歸屬才開始起作用。服務商一側和你自己一側各有一本賬，而兩本賬能通過共享的 request 識別符號關聯起來。本指南就是搭這套東西：每本賬裡有什麼、每次請求要附帶的五個維度、把它們存下來的最小事件表，以及在你記錄的內容和你被計費的內容之間撕開缺口的那些陷阱。
為什麼賬單總額幾乎回答不了任何問題
服務商的後臺說的是服務商的詞彙。組織、專案、API key、模型。這些都是計費物件。而別人問你的問題是產品物件。摘要功能每個活躍使用者的成本是不是越來越高了？這個租戶的消耗還符合他們的套餐嗎？內部工具團隊能不能把它的負載遷到更輕的模型上而沒人察覺？
AI 用量的可見性就生滅在這道接縫上。盯著總額看多久都補不上這個缺口，基於同一批計費資料搭的任何看板也補不上，因為缺失的上下文只存在於一個瞬間：你的應用內部、請求發出的那一刻。那一刻程式碼還知道哪個使用者在等、哪個功能觸發了呼叫、哪個客戶在為它付錢。要麼當時就抓下來，要麼事後靠猜。
LLM API 成本歸屬背後的兩本賬
成本歸屬需要兩本賬，因為兩側知道的事情不同。
服務商一側的賬是你的對賬來源：實際被計數、被計費的東西。怎麼讀它取決於服務商。
OpenAI 把組織級的 Usage 和 Costs API 作為其 Administration 端點的一部分發布，文件對憑據說得很明確：應用請求用標準 API key，但 Administration 端點要用 Admin API key（Usage API 參考、Costs API 參考）。用量端點返回按時間分桶的聚合資料，你可以過濾和分組，包括按模型、專案、API key 和使用者。
Anthropic 在其 Admin API 中提供 messages usage 報告，其分組維度包括賬號、API key、工作區和模型，時間粒度可選按天、小時或分鐘分桶。Console 的用量頁面也可以按 API key 和模型匯出用量資料，這往往是把第一次對賬跑起來的最快辦法。
如果你通過 String AI 這樣的平臺消費模型，服務商一側比你想像的更近：用量記錄頁面會展示每次呼叫的詳細消耗，平臺文件列出了驅動這些消耗的因素，包括所用模型、輸入長度、輸出長度、是否上傳了檔案，以及對話歷史長度。這份清單很重要，因為它告訴你哪些請求欄位值得在你這一側記錄。
應用一側的賬是每次模型呼叫一行，由你的程式碼寫入：何時發生、由哪個模型服務、進出的 token 數、如何結束、耗時多久，以及只有你的應用才知道的歸屬標籤。服務商沒法給功能或客戶命名。那套詞彙住在這裡。
兩本賬之間的關聯鍵是 request 識別符號。服務通常會在每個響應裡返回一個 request ID，把它記錄下來是標準的運維實踐；在你每個應用事件上都寫上它，這樣你賬本里的任何一行都能追溯回服務商對同一次呼叫的檢視。關於對賬，需要一點現實感：兩本賬不會精確吻合，也不該吻合。聚合視窗不同，快取呼叫會塌縮，批處理落在與提交時不同的時間桶裡。目標是有節奏地解釋差異，而不是強行讓數字一致。
在呼叫點附加的五個維度
每次請求都應帶上五個歸屬維度。加上它們都不貴；而事後補加幾乎不可能。
- 使用者 ID。是哪個具體的人在等這個響應。如果你想按使用者統計 token 用量，這是唯一誠實的做法；共用一個 API key 恰好藏起了你需要的那個細節。
- 租戶或賬號。這項工作歸屬於哪個客戶，或哪個內部團隊。正是這個維度把一張用量賬單變成分攤賬單，至少也能變成內部展示賬單。
- 功能。觸發這次呼叫的產品能力：引導助手、每夜摘要、搜尋重排，或者你們團隊平時怎麼叫它。
- 路由或模型。在回退和路由都表態之後，實際服務這次請求的是哪個模型。把它與功能標籤分開保留；功能和模型是多對多關係，把兩者壓成一個就失去了把任一問題答好的能力。
- 環境。生產、預發，還是某個開發者的實驗。未打標籤的測試流量，是用量報告長出無法解釋的基線的經典途徑之一。
重要的部分是標籤附加在哪裡：在呼叫點、在程式碼裡、作為模型客戶端封裝層的必填引數。讀取日誌時才加上的標籤屬於重構，而從訊息文本重構就是猜。有一條規則能讓這件事保持誠實：如果一次呼叫說不清它的使用者、租戶和功能，那是 bug，不是資料點。
最小事件表，以及三個真正回本的檢視
在你考慮看板之前，先做一張原始事件表，每次模型呼叫一行。能回答大多數問題的最小列集：
| Column | What it holds |
|---|---|
| timestamp | when the call was made |
| request_id | the provider's identifier, when one is returned |
| user_id | who was waiting |
| tenant | customer or team |
| feature | product label |
| model | what actually served it |
| input_tokens, output_tokens | usage as reported for the call |
| status | completed, failed, retried, or cancelled |
| latency_ms | how long it took, recorded uniformly |
兩條結構性備註。第一，存原始事件，在它們之上再建聚合。在寫入時聚合，等於把今天的問題烤進 schema，而問題會變：按功能變成按客戶，再變成按功能加模型一起。第二，把狀態和耗時與用量放在同一張表裡，因為成本問題很少單獨到來；它們總是附著在可靠性問題上一起到來。
在原始表之上，三個檢視能自己賺回成本：
功能檢視按功能對一段時間內的用量和成本分組。按功能追蹤用量能抓住最重要的模式——某項能力的增長快於它的使用者基數——趁它還只是一條趨勢線、而不是一個季度驚嚇的時候。
客戶檢視按租戶切分消耗。這是財務和支援團隊都想要的檢視：一個用來核對用量是否跟隨合同，另一個用來在不等工程團隊的情況下回答某個賬號為什麼看起來不對勁。
模型檢視顯示哪些模型在服務哪些功能，比例如何。多模型成本追蹤從這裡開始，因為不同模型定價不同，所以組合的變化能解釋與用量規模無關的成本變動，反之亦然。
如果一個檢視沒有人會去看，就先別建。歸屬基礎設施很容易長出沒人讀的看板；從你已經被問到的三個問題開始。
你的日誌與賬單之間的四個陷阱
流式用量來得晚。響應以流返回時，token 計數通常要等流結束才最終確定。在第一個位元組就寫記錄的日誌器，恰恰會為使用者最在意的那批呼叫記下空的用量。要在流結束時寫記錄，或在最終 usage 事件到達時更新它。
失敗和重試也是用量。失敗的呼叫照樣可能消耗 input tokens，而重試邏輯會把你發出的所有東西成倍放大。只記成功呼叫的賬本在服務商的計數面前會顯示一個缺口，而這個缺口看起來會像是別人的錯。記錄每一次嘗試及其狀態，並標明哪一次最終成功了。
一個功能，多個模型。回退、分級路由、區域變體和多服務商配置，會把一個功能的用量散落到多行模型記錄上。如果你先按模型分組，你正在調查的那個功能就消失在碎片裡。按功能聚合，把模型保留為一列，而不是主鍵。
快取和批處理是有意改變時機的。快取響應意味著服務商統計到的呼叫次數少於你程式碼發出的次數。批處理按服務商的排期計數，而不是你的。兩者造成的差異都是正確的。有節奏地對賬，解釋差異，並把解釋儲存下來。你一旦通過調整日誌來“修正”差異，兩本賬都變成了虛構。
從歸屬到計費、配額與承諾
歸屬資料是任何你想許下承諾的前提：額度、套餐上限、團隊配額、面向客戶的用量報告。如果你說不出某個客戶消耗了什麼，你就無法給它設上限、定價或解釋，每一次配額談話都變成用猜測進行的談判。同一套機器在賣方一側的用法，也就是先計量再變現，在《2026 年如何將 API 變現》一文裡有講。
順序很重要：先埋點，再承諾。在能測量用量之前就公佈配額的團隊，接下來一個月都在談例外。
當這些承諾是按客戶給的，多租戶指南講了讓每個租戶的數字保持可分離的憑據、配額與歸屬安排。
接下來做什麼
- 先讓呼叫值得記錄。先看《五步快速上手》帶你從零走到第一次成功呼叫，那就是你應用賬本里的第一行。
- 先核實表面。再看《相容性清單》確認你的核算所讀取的響應形狀和流事件，這樣流水線記下的就真是它以為在記的東西。
- 用恰當的懷疑讀單個響應。 API 響應不是搜尋結果，而一次呼叫只是用來解釋更大事情的微弱訊號。
- 規劃你的模型組合。 別讓每個 AI 模型去做所有事；按任務分配模型，是讓模型檢視清晰可讀而不是噪音一片的習慣。
- 繼續探索。更多指南與開發者文章覆蓋整合路徑的其餘部分。
先追蹤，再拆分，從第一次呼叫就開始。把歸屬能力事後補裝到幾個月未打標籤的用量上，是這個專案的昂貴版本。