我們是如何控制AI成本的

隨着AI技術在組織中的廣泛應用，成本控制已成為一個不容忽視的緊迫問題。與傳統軟件按許可證或席位計費的模式不同，AI服務採用令牌（token）計費，每次API調用都會產生新的成本，而且購買決策分散在每個開發者手中。這種模式與雲計算中的FinOps（財務運營）非常相似，但粒度更細、速度更快。

一個典型的案例曾在行業內引起轟動：一家公司的員工AI授權沒有設置使用限制，結果一個月內燒掉了近五億美元。雖然這個極端案例規模罕見，但其背後的問題卻具有普遍性。許多組織正在經歷類似情況：月度賬單從幾百歐元悄然攀升至數千歐元，卻無法追蹤是哪個服務或用户導致了增長。熟悉雲FinOps的人立刻就能識別出問題所在——成本失控並非源於單個昂貴的令牌，而是缺乏可見性和明確的邊界。

FinOps的核心思想是將財務治理與運營透明度相結合，使業務部門、IT和財務能在共享數據基礎上做出決策。同樣的邏輯適用於AI，只是成本單位發生了變化。好消息是，現在已有開放標準來實現這種透明度。OpenTelemetry GenAI語義約定（Semantic Conventions）提供了一套統一的詞彙表，用於以供應商中立的方式捕獲AI消耗並將其歸因到各個源頭。

AI成本控制並非全新的問題，而是粒度更細、速度更快的FinOps。如果組織已經在雲環境中建立了標籤策略，那麼只需將同樣的思路遷移到新的成本單位上即可。在雲FinOps中，我們通過標籤（如成本中心、團隊、環境）來歸因資源；AI需要同樣嚴謹的做法，只不過現在標籤要附加到每次模型調用上——用户、團隊、功能或工作流。沒有調用時刻的歸因，以後就無法從提供商的聚合賬單中分解出成本，異常也無法解釋，單個功能的商業價值更難以計算。

這裏有三點重要類比：首先，最大的實際問題是覆蓋率——雲項目中總有大量資源未打標籤而進入未分配桶，AI也是如此：是否每次調用都真的攜帶了身份標識？其次，槓桿都在源頭執行：雲中未打標籤的資源違反策略，AI中未經歸因的調用根本不被放行。第三，當同一套分類體系貫穿兩個世界時，就能首次回答“一個功能的總成本是多少”——包括基礎設施和AI。這正是FinOps開放成本與使用規範（FOCUS）所追求的共同點。

實現AI成本控制的五個槓桿是：第一，通過令牌歸因實現透明度，即將每次模型調用分配給用户、團隊和功能；第二，部署AI代理作為所有AI流量的中央控制點；第三，設置明確的限制和護欄，防止成本失控；第四，通過正確的模型選擇、精簡調用和緩存實現持續優化；第五，賦能團隊，讓他們理解並承擔自己的成本。

在實踐層面，每個模型調用都可以包裝成一個跨度（span），攜帶標準化的字段和自定義歸因屬性。例如，使用OpenTelemetry的Python SDK創建一個聊天跨度，設置gen_ai.operation.name、gen_ai.provider.name、gen_ai.request.model等標準屬性，以及enduser.id、team.name、feature.name等業務屬性，並在調用後記錄輸入輸出令牌數。這些信息足以進行成本分解，且從數據保護角度看，純成本監控無需存儲提示內容，元數據就足夠了。

最具實踐性的架構是AI代理（或AI網關），作為所有AI流量的中央通道。應用程序和工具（開發環境、聊天界面、Agent管道等）使用虛擬密鑰而非真實提供商密鑰，每次調用自動獲得歸因。代理捕獲消耗、模型、成本和延遲，執行限制，可將簡單任務路由到更小的模型，並按開放標準將遙測數據導出到分析系統。這樣，透明度不再是月末的後期分析，而是每次調用的組成部分。同時，這個途徑還能將之前不受控的直接使用（影子AI）納入治理。

設置限制和護ba欄是防止成本爆炸的關鍵。實踐中存在清晰的成熟度模式：團隊先引入請求數量限制，第一次賬單驚嚇後添加令牌消耗限制，第二次後添加每個週期和團隊的硬預算限制。這些限制在多個層面協同工作——請求數限制保護基礎設施，令牌限制控制實際消耗，預算限制防止批量處理或Agent循環導致的意外高峯。在網關中，可以為每個虛擬密鑰聲明這些限制，例如每分鐘最多120個請求、20萬個令牌，月度軟預算5000歐元（觸發警報）、硬預算6000歐元（拒絕調用），以及成本速率斷路器（每分鐘超過20歐元則停止失控Agent）。

最終，AI成本控制需要組織從被動應對轉向主動管理。通過可見性、中央控制、合理限制、持續優化和團隊賦能，AI的消費可以被有效治理，讓組織在享受AI帶來的價值的同時，避免財務風險。