我們是如何控制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帶來的價值的同時，避免財務風險。