AI Gateway Auto Router 釋出，幫助企業降低 AI 成本

從我們與各階段 AI 採用旅程中的公司對話中，我們看到了一些共同模式。首先是探索階段，當你引入每個新工具、自由發放 API 金鑰並讓令牌流動時。隨後，你會聚焦於組織的標準工具，用於代理式編碼、非技術工作流程，以及執行和部署代理。隨著公司正式化 AI 採用，他們想要管理和監督使用者的令牌支出，但預算和規則只能做到一定程度。最好的節省是使用者根本沒有注意到的。

今天，我們在公開測試版中釋出了 Cloudflare 的 Auto Router，可通過 AI Gateway 訪問。將您的模型設定為 cloudflare/auto，Auto Router 將自動將每個請求路由到足以完成任務的模型，無需終端使用者考慮模型選擇。我們在內部使用 Auto Router 並通過 OpenCode harness 的早期結果顯示，與僅使用前沿模型（如 OpenAI Sol 和 Anthropic Claude Opus）相比，成本可節省高達 30%。

我們為什麼構建它

從我們在 Cloudflare 跟蹤 AI 支出的自身經驗來看，我們瞭解到管理成本需要多管齊下的方法。此前，我們討論過如何設定預算和圍繞 AI 支出的限制，以及如何檢視誰在組織內消費，通過將員工與其 AI 使用關聯。

在許多 harness（包括 OpenCode、Claude Code 和 Codex）中，個人使用者仍然手動選擇模型。當然，並非所有任務都是相同的，個人往往會使用過度的模型。例如，如果你只是想總結電子郵件或聊天執行緒，你不需要 Opus 級別的智慧。然而，你也不想完全阻止安全工程團隊使用該模型。

我們的目標是讓 AI Gateway 成為內部部署 AI 的組織的控制平面。因為每個使用者、代理和工具的每個請求都已通過它流動，AI Gateway 在觀察和執行之外擁有獨特的位置。預算、支出限制和基於身份的分析為組織提供可見性和防護欄，但它們仍然依賴個人逐請求做出成本意識的選擇。下一步是讓閘道器本身代表使用者做出智慧決策：將每個請求傳送到足以完成任務的模型。這樣，組織可以自動降低支出，而使用者在真正需要時仍能訪問最強大的模型。

結果

我們在 Cloudflare 內部使用 Auto Router，既在 OpenCode 部署中，也在Cloudflare OS——我們的自定義代理 harness 中。根據我們的內部使用，我們看到與前沿模型在編碼任務上的結果相當。

Auto Router 在廣泛的知識工作任務中表現最佳，例如大型組織中技術和非技術團隊共同工作的典型任務。我們在內部通用知識工作基準上評估了 cloudflare/auto 與 OpenAI 的 GPT-6 Sol 和 Anthropic 的 Claude Opus 5.5。該基準使用模擬工作空間工具，涵蓋電子郵件、日曆、Slack、檔案、旅行和財務等常見日常工作流程。每個任務要求模型使用這些工具生成可驗證的答案或完成操作。

^{每個模型每個任務包含 3 個樣本，共 97 個任務。括號中的數值表示通過 10,000 次任務級自助抽樣（bootstrap resamples）估計出的 95% 置信區間，保留了每個任務內的全部 3 次重複。“pp”表示百分點。}

我們的 Auto Router 提供了與其它最先進日常主力模型相似的效能，成本僅為 Sol 的 80% 以及 Opus 的 35%。雖然這初聽起來可能令人意外，但理解模型路由器所解決問題的一個視角是跨模型的“參差邊界（jagged frontier）”。解決問題的能力往往存在於這個模型組合的某處；路由器的任務就是在平衡質量和價格的同時，為每個任務選擇正確的模型。節省的成本來自於無需為非前沿任務支付前沿價格，並且這種節省會隨著此類任務的增多而增加。

另一個見解是，更低的 Token 價格並不總能帶來更低的成本結果。紙面上看起來更便宜的模型，最終可能會為解決問題消耗不成比例的更多 Token。路由器應該最小化預測的軌跡成本，而不僅僅是通過每百萬 Token 的美元單價進行負載均衡。

這在今天已經非常有用，但這只是 Auto Router 從 Cloudflare 在推理路徑中的地位所能學習到的內容的開始。

工作原理

當你向 cloudflare/auto 傳送請求時，AI Gateway 首先會構建能夠實際服務該請求的 模型池。它會過濾掉不支援請求格式或執行模式的模型，並考慮與閘道器關聯的憑據、計費配置、訪問控制策略和支出限額。它還會在停機期間過濾掉不健康的上游提供商或模型，並在故障排除後自動將它們重新納人池中。

對於剩餘的候選者，路由器會檢視對話的精簡檢視。它會考慮最近的訊息，優先處理最新的輪次。然後，對話會被髮送到執行在 Workers AI 上並在我們邊緣網路的 GPU 上部署的多頭分類模型。該分類器會產生兩組訊號。首先，它會為 14 個任務類別（如編碼、規劃、研究、資料分析）分配機率。然後，它會在 1 到 5 的標度上對請求的四個維度進行評分：複雜性、模糊性、利害關係和對早期上下文的依賴。

一個單獨的評分矩陣將這些訊號與模型基準測試結果結合起來，以估計每個模型對請求的適合程度。為了校準評分矩陣，我們為一組示例任務和難度配置檔案定義了首選模型，然後調整權重以產生這些選擇。

最後，路由器將期望質量與每個模型的輸入和輸出 Token 價格結合起來。在簡單的請求中，價格權重更高，因此當較小的模型能力足夠時便能勝出。隨著難度的增加，成本懲罰下降，更強的模型有更大的勝出空間。簡單來說，cloudflare/auto 選擇具有最高效用的模型，其定義為：

對於除錯或程式設計等長時間的智慧體會話，成本與其說是由模型的標價決定，不如說是由隨會話長度增長的快取讀取成本決定的。切換模型會丟棄快取，並迫使新模型重新寫入整個上下文。這樣做可能是值得的，因為具有更便宜的快取讀取和快取寫入價格的模型可以很快通過省下的開銷抵消重新寫入的成本。

自動路由器（Auto Router）並沒有完全避免模型切換，而是將快取讀寫的成本考慮在內。在單輪對話（一個使用者輸入迴圈）中，快取處於命中狀態，切換很少划算，因此最好繼續使用同一模型。跨輪次時，自動路由器會施加一個隨上下文中已有 Token 數量增加而增加的切換懲罰。對於在該會話中仍然保持有效快取的模型，按其更便宜的快取讀取費率計費。其他所有候選模型都將按重寫上下文的完整成本計費，因此對話越深入，切換所需的“回本”代價就越高——這需要通過使用更少總體 Token 或更便宜的快取重讀來獲得更高質量的結果來實現。切換模型還有另一個成本：大多數模型無法讀取另一個模型的推理 Token，因此丟棄推理 Token 的模型切換意味著新模型可能必須以輸出價格重新進行推理。未來，我們希望通過讓路由器在切換時傾向於停留在同一個模型系列中來解決這個問題。

隨後，路由器會返回一個按排名排序的列表。AI Gateway 會首先嚐試獲勝的模型，如果該提供商無法提供服務，則可以轉至另一個符合條件的模型。

這一整體設計具有幾個好處。兩階段架構（任務和維度分類器到評分矩陣）意味著路由決策是清晰易讀的，因為你可以檢查每個任務的預測類別和複雜度，以瞭解它是如何轉化為模型選擇的。在釋出新模型時調整路由器也不需要重新訓練——我們只需將其基準測試衍生的權重新增到評分矩陣中即可。同一個分類器還可以支援不同的路由配置檔案。例如，除了 cloudflare/auto 之外，我們計劃在未來發布其他路由器，包括 cloudflare/auto-best，它使用相同的分類和模型池，但選擇預期質量最高的那一個，而不應用成本權衡。

下一步計劃

我們今天的釋出僅僅是一個起點，我們將繼續加大對研究和新路由策略的投入。在短期內，我們希望實現以下目標：

• 擴充套件通過 cloudflare/auto 提供的模型
• 在過濾模型時包含零資料保留要求
• 在選擇模型時考慮提供商的容量
• 為每個請求選擇合適的推理或思考級別
• 增加對 Responses API 和 WebSockets 的全面支援
• 探索將結構化決策模型作為首輪分類器

Auto Router 在測試期間免費。閱讀我們的開發者文件瞭解更多資訊。

致謝：本專案的順利完成也離不開 Mats Dodd、Sam Scott、Oliver Yu 和 Jeff Rafter 的努力。