針對每個客戶工作流程發放獨立的 API 金鑰，能在開票時拉出乾淨且逐項的用量報表——無需手動剖析日誌、也不必猜測是哪位客戶產生了哪些成本。以下說明如何在統一儀表板中進行逐金鑰追蹤，以及它如何實際紓解多客戶營運的痛點。
代理機構對開票時最熟悉的問題
如果你為多個客戶運行 AI 工作，每到計費月底場景都很相似。你知道自己的 AI 總支出——供應商的儀表板顯示得很清楚。但它沒有顯示的是，這個總額如何按客戶拆分。而你恰恰需要這個拆分，因為你要向每位客戶就其份額開立發票，而且「他們的份額」必須可據以說明、逐項、且精準。
於是開始對帳。你匯出用量日誌，試圖從原始請求紀錄倒推每次呼叫屬於哪位客戶——解析時間戳、對照專案活動、在日誌含糊之處估算拆分。這很慢、容易出錯，而且最糟的是常常只是近似：當日誌無法乾淨地歸因成本時，你在猜；而猜測不該出現在你要讓客戶付款的發票上。你需要的資訊——每位客戶的成本——理論上存在，只是埋在彙總數裡，因為供應商的計費並不是為了呈現它而設計。
核心問題： 供應商的計費以你的帳戶為中心，而不是以你的客戶為中心。總額很清楚；至於每位客戶的拆分，則是你每個月從原始日誌手動重建。這種重建既慢又易錯，而且常常只是近似——這不是一張你要客戶付款的發票應有的基礎。
機制：每位客戶（或工作流程）一把金鑰，分開追蹤
解法在於結構，且很簡單。別把所有客戶的工作都走同一把 API 金鑰，而是為每位客戶——或每個客戶工作流程——發放一把獨立金鑰，並讓計費系統按金鑰追蹤用量。如此，你原本要手動重建的歸因會在源頭自動擷取：每個請求都帶著發出它的金鑰身份，而金鑰對應到客戶。每位客戶的成本不再是你重建出來的，而是你直接讀到的。
這與會計所稱的「成本中心」相同。每把金鑰就是一個帶標籤的桶。當請求執行時，其成本就落在該金鑰的桶裡；因為每把金鑰只屬於一位客戶，每個桶就是那位客戶的花費。到開票時，你不再剖析日誌——而是在儀表板上直接讀出各金鑰的總額。歸因問題由結構解決，而非靠事後勞力。
當所有客戶的工作都經由同一個統一端點運行時，這會運作得格外乾淨，因為所有金鑰——以及所有追蹤——都集中在一處。具備逐金鑰追蹤的統一 AI 閘道意味著一個帳戶持有每位客戶的金鑰、每把金鑰回報自己的用量，整體視圖位於單一儀表板，而不是分散在多個需要你再行彙整的供應商帳戶裡。
每把金鑰會擷取哪些內容
逐金鑰追蹤系統通常會為每把金鑰記錄下列足以組成發票行項目的維度：
• 總支出。 該金鑰在計費期間產生的所有請求之美元成本——即該客戶發票行項目的標題數字。
• 請求量。 該金鑰發出的呼叫次數，有助於驗證活動量，並滿足想了解付費內容的客戶。
• Token 用量。 輸入與輸出 Token 數，這是成本的基礎；若客戶質疑費用，能提供可辯護的拆解。
• 模型拆分。 該金鑰使用了哪些模型、各自產生成本多少——當客戶同時用到便宜模型處理大量任務、以及高階模型處理棘手任務時尤其有用。
以上各項皆以金鑰為粒度擷取，亦即以客戶為粒度擷取，因此無需任何日誌剖析即可得到乾淨的行項目。你過去手動拼湊的報告，現在成了你拉取的一份匯出。
為何「逐金鑰」優於其他替代方案
代理機構也嘗試過其他方法來解決客戶歸因。每種方法都有其失效模式，而逐金鑰追蹤能避開這些模式。
| Approach | How it works | Where it breaks |
|---|---|---|
| Single key, parse logs | One key for everything; reconstruct per-client splits from raw logs at invoice time. | Slow, error-prone, often approximate. The attribution is guesswork wherever logs are ambiguous. |
| Separate provider accounts | A separate account with each provider for each client. | Multiplies credentials, dashboards, and invoices. Unmanageable past a few clients; defeats the point of consolidation. |
| Manual spreadsheet tracking | Log each client's usage by hand as work happens. | Depends on discipline no one sustains. Falls out of date; errors compound silently. |
| Per-key tracking (unified) | One key per client on one account; usage tracked per key automatically. | Scales cleanly; attribution is captured at the source. The report is a read, not a reconstruction. |
其共通模式是：所有替代方案都把歸因工作推到開票時，並以手工方式完成；而逐金鑰追蹤則在請求發生時擷取歸因，且自動完成。差異會隨著客戶數放大：為兩位客戶剖析日誌已經繁瑣；到了十五位就成了兼職工作。逐金鑰追蹤在兩位或五十位客戶下所需努力同樣小——你發一把金鑰，然後讀出總額。
設定方式
採用逐金鑰追蹤是個輕量的工程。給代理機構的實作序列：
1. 每位客戶或每個工作流程發一把金鑰。 決定你的粒度。每位客戶一把金鑰是常見選擇；若單一客戶有多條希望分別計費的工作流，一些機構會更細，做到每客戶-專案或每工作流程一把金鑰。粒度越細，報表越細。
2. 清楚地命名金鑰。 以所屬客戶（或專案）為金鑰命名，讓儀表板讀起來像一份客戶清單，而不是一串不透明的權杖。這個習慣讓開票時的匯出即讀即懂。
3. 讓每位客戶的整合使用其專屬金鑰。 在每位客戶的部署中，使用該客戶的金鑰。因為金鑰只是憑證，這只是個組態值——除了在客戶環境中替換金鑰外無需其他程式碼變更。
4. 在開票時拉取逐金鑰用量。 計費期末，從儀表板讀出各金鑰的總額。這就是你的逐客戶拆分——支出、請求量、Token、模型拆分——可直接放進發票行項目，無需剖析任何東西。
5. 按客戶輪換或撤銷，而不影響其他人。 每位客戶一把金鑰，也就是每位客戶一個控制點。若客戶離場，撤銷其金鑰；若金鑰外洩，只輪換那一把。任何金鑰動作的衝擊範圍只限一位客戶，而不是整個營運。
由於用量是以相同的公佈費率、按 Token 計量收費，無論是哪把金鑰發出呼叫，逐金鑰的總額都能直接對應到底層的定價，因此你開立的金額能乾淨地追溯到你被收取的金額——再透明地加上你所設定的利潤幅度。
逐金鑰追蹤在計費之外帶來的價值
乾淨的開票是最顯著的好處，但同樣的結構也在代理機構關心的其他面向產生效益。
• 逐客戶的獲利能力。 當你能精確看到每位客戶的 AI 用量成本，你就能辨識哪些合作的利潤健康、哪些在悄悄吞噬費用。這不只是計費訊號，更是策略訊號——指引你該對哪些客戶關係重新定價或調整架構。
• 失控用量的早期預警。 逐金鑰可視性意味著某個客戶工作流突然飆升——例如配置錯誤的迴圈、意外的流量暴增——會直接顯示在該客戶的金鑰下，而不會淹沒在總量裡。你能在事態尚小時攔截。
• 更乾淨的客戶溝通。 當客戶問他們付了什麼，你可以給出逐項且可辯護的答案——請求量、Token、模型——而不是從一個總額中切出一份。這種透明度建立信任，也縮短帳務爭議。
• 工作範圍與報價的界定。 以歷史的逐客戶用量作為相似未來工作的報價基準是最佳做法。你根據自身真實數據估算，而不是猜測，讓提案更準確、並保護你的利潤。
對於規模化營運的機構而言，統一平台所提供的帳戶層級控管——團隊存取、支出可視化、管理監控——會把這項能力從計費便利擴展為真正的營運治理。企業級帳戶控管讓逐金鑰追蹤不只是如何開票，而是如何運作整個組織的一部分。
這意味著什麼
把 AI 支出歸因到個別客戶，是供應商計費原本沒有為之設計的問題——總額很明確，但代理機構每個月得從原始日誌手動重建每位客戶的拆分，既慢又近似。逐金鑰追蹤以結構解決它：每位客戶一把金鑰、用量按金鑰自動擷取，開票時讀報表而不是重建。它能從兩位客戶乾淨擴展到五十位；而能清理計費的同一套可視性，也同時揭示逐客戶的獲利能力、失控用量，以及更可靠的報價數據。
實際的下一步： 為每位客戶發一把命名清晰的金鑰，讓每位客戶的整合使用其專屬金鑰，並在下一個開票週期拉取逐金鑰總額。設定只需幾分鐘，而首個月的對帳會從剖析日誌變成匯出儀表板。具備逐金鑰追蹤的統一閘道把每位客戶的金鑰與用量集中在一處，因此整體畫面只在一個儀表板之遙。
供應商計費顯示的是你的總額，而不是逐客戶拆分——因此代理機構每個月都手動重建歸因。為每位客戶發一把金鑰，讓系統按金鑰追蹤用量，歸因便在源頭自動擷取：開票時你直接從儀表板讀出逐客戶的支出、請求量、Token 與模型拆分，而不是剖析日誌。它能隨客戶數量擴展，並同時作為獲利能力與治理的數據來源。
來源： 逐金鑰追蹤與統一儀表板行為已對照 CometAPI 平台文件（2026 年 6 月）驗證。計費工作流程模式來自常見的代理與多客戶營運實務。在將之用於實際計費流程前，請以當前平台文件確認具體儀表板能力。
平台功能會演進。本文按季度更新。