這些限制並非一刀切,而是可以精細地依照模型、提供者,或是自訂的中繼資料維度(如使用者 ID、團隊或應用程式)來界定範圍 。例如,一個組織可以為每位使用者設定每日 200 美元的預算,為整個閘道的總支出設定每日 10,000 美元的上限,或是針對某個特別昂貴的模型設定每日 50 美元的限制 。每條規則都使用可設定的時間區間,並可選擇固定(對齊日曆)或滑動(滾動式)的重置策略 。
支出上限會在兩個獨立的層級上強制執行。帳戶層級的支出上限,適用於使用統一計費(Unified Billing)的組織,可限制所有閘道的總支出。而各別閘道上的規則則提供了更細緻的控制。無論哪個上限先達到,都會阻擋後續的請求 。這些限制同時適用於統一計費請求(由 Cloudflare 儲值,並收取 5% 交易手續費),以及自帶金鑰(BYOK)的設定,前提是模型的定價是已知的 。
直接回傳 429 錯誤固然直接,卻也相對粗暴。Cloudflare 的動態路由(Dynamic Routing,測試版)提供了一個更聰明的替代方案,允許在預算耗盡時,自動備援至更便宜的替代模型。路由流程中可以加入預算限制節點(Budget Limit nodes),在強制執行成本配額的同時,自動切換到另一個模型,而非直接捨棄請求 。
同一個系統還支援頻率限制節點、按百分比的 A/B 流量分流,以及根據請求中繼資料(如使用者方案或團隊)進行條件分支等功能,而且完全無需修改應用程式碼 。
或許最重大的宣佈,是一項處於封閉測試階段的身份驅動預算功能。它整合了 Cloudflare Access 以及組織現有的身份識別提供者(IdP),解決了共享 API 金鑰這個長久以來的問題。正如 Cloudflare 部落格所言,「沒人知道誰花了什麼錢」。將歸屬和強制執行機制直接與公司身份綁定,能讓資訊長和財務團隊,終於能為 AI 支出建立起如同其他業務項目般的單位經濟學基礎 。
這整套功能是 Cloudflare 對其客戶身上觀察到的具體市場失靈現象的直接回應 :
Cloudflare 將支出上限與真實的花費和人員連結起來,無疑是在押注一件事:AI 成本管理將變得像追蹤其他任何雲端基礎設施支出一樣,成為一項例行公事。
這些限制並非一刀切,而是可以精細地依照模型、提供者,或是自訂的中繼資料維度(如使用者 ID、團隊或應用程式)來界定範圍 。例如,一個組織可以為每位使用者設定每日 200 美元的預算,為整個閘道的總支出設定每日 10,000 美元的上限,或是針對某個特別昂貴的模型設定每日 50 美元的限制 。每條規則都使用可設定的時間區間,並可選擇固定(對齊日曆)或滑動(滾動式)的重置策略 。
支出上限會在兩個獨立的層級上強制執行。帳戶層級的支出上限,適用於使用統一計費(Unified Billing)的組織,可限制所有閘道的總支出。而各別閘道上的規則則提供了更細緻的控制。無論哪個上限先達到,都會阻擋後續的請求 。這些限制同時適用於統一計費請求(由 Cloudflare 儲值,並收取 5% 交易手續費),以及自帶金鑰(BYOK)的設定,前提是模型的定價是已知的 。
直接回傳 429 錯誤固然直接,卻也相對粗暴。Cloudflare 的動態路由(Dynamic Routing,測試版)提供了一個更聰明的替代方案,允許在預算耗盡時,自動備援至更便宜的替代模型。路由流程中可以加入預算限制節點(Budget Limit nodes),在強制執行成本配額的同時,自動切換到另一個模型,而非直接捨棄請求 。
同一個系統還支援頻率限制節點、按百分比的 A/B 流量分流,以及根據請求中繼資料(如使用者方案或團隊)進行條件分支等功能,而且完全無需修改應用程式碼 。
或許最重大的宣佈,是一項處於封閉測試階段的身份驅動預算功能。它整合了 Cloudflare Access 以及組織現有的身份識別提供者(IdP),解決了共享 API 金鑰這個長久以來的問題。正如 Cloudflare 部落格所言,「沒人知道誰花了什麼錢」。將歸屬和強制執行機制直接與公司身份綁定,能讓資訊長和財務團隊,終於能為 AI 支出建立起如同其他業務項目般的單位經濟學基礎 。
這整套功能是 Cloudflare 對其客戶身上觀察到的具體市場失靈現象的直接回應 :
Cloudflare 將支出上限與真實的花費和人員連結起來,無疑是在押注一件事:AI 成本管理將變得像追蹤其他任何雲端基礎設施支出一樣,成為一項例行公事。