唔准無上限燒錢！Cloudflare AI Gateway 用「真金白銀」幫你鎖死 AI 預算

好多公司一踩入 AI 領域就好似瀨咗嘢咁，成日要面對一個常見嘅噩夢：無端端收到張五六位數甚至更誇張嘅賬單，然後完全無辦法追溯到究竟係邊個團隊、邊個用家、定係邊個失控嘅程序搞到洗大咗。Cloudflare 喺 2026 年 6 月 5 日更新嘅 AI Gateway 就係對症下藥，將成本控制嘅方法由計算請求次數，轉變成追蹤「真金白銀」，仲要將呢啲預算同個別身份掛勾 。

點樣用「真金白銀」控制使費？

今次更新嘅核心，係由傳統嘅速率限制——即係限制 API 請求次數——轉變為建基於成本嘅預算，利用實際嘅 Token 使用量同模型定價，嚟追蹤累計使咗幾多錢 。當 Gateway 收到一個請求嗰陣，佢會根據已知嘅模型價格同消耗咗嘅 Token 嚟計算成本。如果喺設定好嘅時間範圍入面，總使費超過咗上限，個請求就會畀人用 HTTP 429 嘅錯誤代碼攔截住 。

預算範圍同點樣設定

呢啲上限唔係一刀切嘅。你可以好精細咁按模型、供應商，或者自訂嘅 Metadata 維度（例如用家 ID、團隊、應用程式）嚟設定範圍 。舉個例，一間公司可以設定每個用家每日有 200 蚊（美金，下同）預算、成個 Gateway 每日總使費上限係 10,000 蚊、或者限制某個特定嘅貴價模型每日最多只可以用 50 蚊 。每一條規則都可以設定一個可配置嘅時間窗口，並且揀用固定（跟日曆）或者滑動（滾動式）嘅重設策略 。

雙重 enforcement 機制

使費上限會喺兩個獨立嘅層面執行。一個係「帳戶級別」嘅使費上限，針對所有用緊 Unified Billing 嘅組織，限制晒所有 Gateway 嘅總開支。另一個係「每個 Gateway」嘅規則，提供更精細嘅控制。兩個上限係獨立執行嘅，是但一個上限爆咗先，都會攔截之後嘅請求 。呢啲上限適用於 Unified Billing 嘅請求——Cloudflare 會喺入錢嗰陣收 5% 手續費——同埋「自備金鑰」（BYOK）嘅設定，只要個模型嘅定價係已知嘅就得 。

動態路由：唔係死咗就算，識得後備

就咁用 HTTP 429 拒絕請求，其實係好粗暴嘅做法。Cloudflare 嘅動態路由功能（測試版）就提供咗一個更聰明嘅替代方案，當預算爆咗嗰陣，佢可以自動跳去用平啲嘅模型，唔會就咁放棄個請求。路由流程可以加入預算限制節點嚟執行成本配額，而唔係直接丟棄請求，改為自動切換到另一個替代模型 。同一個系統仲支援速率限制節點、按百分比嘅 A/B 流量分流，同埋根據請求嘅 Metadata（例如用家計劃或團隊）進行條件分支，全部都可以唔使掂到應用程式嘅代碼 。

用 Cloudflare Access 綁定身份嚟俾預算

可能最值得關注嘅宣佈，係一個整合咗 Cloudflare Access 同公司現有身份供應商（IdP）嘅「身份驅動預算」封閉測試版。呢個功能解決咗共享 API 密鑰嘅老問題，正如 Cloudflare 嘅網誌所講：「根本無人知道邊個洗咗啲錢」。將開支歸屬同執行直接同公司身份綁定，等 CIO（資訊總監）同財務團隊終於可以好似管理其他商業開支咁，為 AI 建立單位經濟效益 。

功能推出背後嘅市場壓力

呢套功能係 Cloudflare 觀察到客戶之間出現咗一啲好具體嘅市場失敗案例，而直接推出嘅回應 ：

• 使費失控： 好多公司抱住「做咗先算，埋單遲啲先諗」嘅心態，好 aggressive 咁採用 AI，結果帶嚟極之痛苦嘅超額開支同 CFO 嘅焦慮。
• 無辦法追溯邊個洗錢： 共享嘅 API 密鑰令到根本無可能將使費追溯返去特定嘅用家、團隊，甚至係一個自動化嘅 CI 作業。
• 盲舂舂用最貴嘅模型： 喺無預算限制之下，團隊會自動將所有任務都送去最貴嗰個前沿模型度，就算用個平啲嘅替代模型根本已經夠做。

透過將使費上限同真金白銀、真人掛勾，Cloudflare 今次係落重注，認為管理 AI 成本將來會變到好似追蹤任何其他雲端基礎設施開支咁，成為例行公事。