Snowflake 動態模型路由登場：AI Gateway 逐項工作揀模型，目標慳成本但唔犧牲質素

企業亦唔一定要完全交出控制權。用戶可以鎖定指定模型，或者縮窄可選模型範圍，避免自動路由喺某些高風險工作上自行轉換模型。

Snowflake 又表示，路由過程可以遵守資料駐留要求及治理政策，並記錄每次請求最終揀咗邊個模型。對需要審計、追蹤及解釋模型選擇原因嘅企業嚟講，呢點同慳 token 一樣重要。

佢預計點樣揀模型？

Snowflake 提到兩種主要機制：advisor pattern 同分類器路由。

Advisor pattern：細模型先試，唔掂先升級

喺 advisor pattern 入面，較細嘅模型會先處理任務。如果佢未能以足夠質素完成工作，就可以呼叫較大型模型作為工具，然後繼續完成流程。

好處係，唔使每次都為簡單請求支付 frontier model 嘅價格，同時保留一條處理複雜任務嘅升級路徑。

不過，呢種做法亦可能帶來額外成本：第一次嘗試、升級呼叫、重試同延遲，都會增加 token 使用量及系統複雜度。真正要睇嘅，唔係細模型有冇「試過」，而係最後個任務有冇一次過完成、質素有冇達標。

分類器路由：預先判斷任務難度

另一條路係用分類器參考歷史查詢模式，先將較直接嘅請求分流去簡單模型。換句話講，系統可以有兩種做法：

1. 先由細模型開始，唔夠先升級；
2. 先判斷請求類型，再直接揀合適模型。

對企業而言，分類器嘅準確度會直接影響成效。如果判斷錯誤，表面上揀咗平模型，但之後出現重試、人手修正或重新執行，總成本可能反而上升。

Snowflake 報告嘅效率數字，應該點睇？

Snowflake 稱，喺一項內部 dbt pipeline workload 測試入面，動態路由喺維持相若質素之下，token 效率最高提升 3 倍，相對於全程只使用 frontier models。另一項 coding workload 測試就顯示，工程團隊喺維持 pull-request 產出嘅同時，token 使用量大約減少 25%。

呢啲數字要留意兩點：

• 係 Snowflake 自己做嘅內部評估；
• 唔係經獨立驗證嘅客戶生產環境結果。

而且，路由喺重複性較高嘅資料工程或 coding 工作表現理想，唔代表喺長上下文研究、複雜工具調用，或者高風險決策上都會有同樣結果。

因此，企業唔應該只問「慳咗幾多 token」，而要計算：每一個成功完成、通過驗收嘅任務，實際成本係幾多。質素、延遲、可靠性、人手覆核同返工時間，都應該一併計入。

DeepSeek 同 GLM 加入模型池

Snowflake 同時擴大 Cortex AI 可用嘅模型選擇，加入 DeepSeek-V4-Flash 0731 同 Z.ai 嘅 GLM-5.3。DeepSeek-V4-Flash 0731 已宣布進入私人預覽，包括 CoCo；GLM-5.3 就表示即將進入私人預覽，但要視乎模型供應情況。

Snowflake 稱，DeepSeek-V4-Flash 喺由 CoCo 作為 agent harness 嘅內部測試中，ADE-bench 得分為 74.4%。

至於 GLM，Snowflake 引用嘅係早前 GLM-5.2 測試，報告得分為 66%，並指佢喺該 benchmark 使用最低 token 量。呢個結果唔係 GLM-5.3 嘅公開評估，所以唔應該當成 GLM-5.3 已經取得 66% 分數。

更多開放模型加入模型池，對動態路由策略有實際作用：模型選擇越多，系統理論上越有機會將任務需求，同成本、速度及能力配對。不過，模型數量增加亦意味住企業要花更多工夫做測試、版本管理、政策設定及質素監控。

Snowflake 最想突出嘅，唔只係慳錢

Snowflake 嘅主要差異化說法，係將模型路由放入原有嘅受治理資料環境之內。公司表示，新增嘅開放模型由 Snowflake 自己提供服務，而唔係單純代理第三方 API；資料、推理運算、模型權重同 agent orchestration，均喺 Snowflake 嘅安全邊界內運作。公司亦指出，企業可以沿用現有嘅角色型存取控制（RBAC）及審計機制。

呢個係 Snowflake 提出嘅架構主張，唔代表所有部署情況都自動獲得同一種保證。企業仍然要自行核實：

• 實際部署地區；
• 資料駐留要求；
• 合約及供應商條款；
• 日誌記錄方式；
• 指定工作實際可以使用邊啲模型。

對本身已經將受治理分析數據及 AI 應用放喺 Snowflake 嘅機構，呢個賣點會比較直接：模型選擇唔再係應用程式外面另一套零散邏輯，而可以同資料存取、權限及審計放喺同一個控制框架內。

同其他模型路由方案有咩分別？

模型路由本身唔係 Snowflake 獨有。以 Amazon Bedrock 為例，Intelligent Prompt Routing 會透過一個 serverless endpoint，喺同一個模型家族內嘅 foundation models 之間作出路由，按預測回應質素及成本選擇模型。

Databricks 嘅 Unity AI Gateway 就由中央控制平面管理模型及 MCP services 嘅請求，並集中處理供應商之間嘅容量、可用性及支出。

Google Cloud 嘅 API Gateway model routing，主要係一個受管理嘅流量層，接收 OpenAI-compatible 請求，再轉送到指定嘅 Gemini Enterprise Agent Platform model endpoints。

NVIDIA NeMo Switchyard 則以供應商無關嘅 SDK 或路由層為定位，將路由邏輯同實際供應商 endpoint 分開。 OpenRouter 就較偏向多供應商聚合及 provider routing，預設會喺合適供應商之間作負載平衡，以提高可用性。

所以，真正有意義嘅比較唔係「邊間公司識唔識揀平模型」——而係以下幾樣嘢由邊度管理：

• 資料及模型治理；
• 路由政策；
• 模型實際執行位置；
• 帳單及成本歸因；
• 跨供應商可攜性。

如果企業嘅受治理資料、權限、agent orchestration 同 AI 使用本身已經集中喺 Snowflake，整合式方案可能較方便。相反，如果最重要係跨雲、跨供應商彈性，或者想保留獨立於單一資料平台嘅路由邏輯，中立型 gateway 可能更合適。最終仍然要逐項核實模型池、地區、部署方式同資料政策，唔可以只睇產品名稱入面有冇「routing」。

接受「慳成本」之前，企業應該量度乜？

一個認真嘅評估，應該用代表性生產 workload，將自動路由同固定使用一個 frontier model 嘅基準方案比較。至少要追蹤：

• 每個成功完成任務嘅總成本，而唔係只睇所選模型嘅 token 價格；
• 路由器或分類器本身有冇額外收費；
• advisor 升級、fallback、重試及工具執行失敗帶來嘅額外呼叫；
• 端到端延遲，包括路由、檢索、上下文組裝及第二次模型呼叫；
• 各類 workload 嘅成功率及輸出質素；
• 較細模型引入嘅幻覺、政策違規及質素倒退；
• 人手覆核、修正、升級處理及返工成本；
• 資料駐留、可觀測性、資料外傳及供應商鎖定限制。

Snowflake 表示唔會另外就路由決策收費，而係按 token 使用量計費。不過，升級同重試仍然可能推高總 token 及延遲。

因此，最合理嘅驗收標準係：動態路由有冇降低一個已完成並獲接受嘅任務嘅總成本，同時保留應用程式需要嘅質素、可靠性及治理水平，而唔係單睇 token 數字有冇下降。

結論：Snowflake 賣嘅係「受治理嘅模型選擇」

Snowflake 今次其實係同時推兩件事：一方面，推出 Cortex AI Gateway 動態模型路由；另一方面，擴大 Cortex AI 可用嘅開放模型，包括 DeepSeek-V4-Flash 0731 及 GLM-5.3。功能預計即將進入私人預覽，DeepSeek-V4-Flash 0731 已宣布進入私人預覽，而 GLM-5.3 就要視乎供應情況。

將簡單請求交畀平啲模型、複雜任務先用強模型，呢個概念本身唔新。Snowflake 真正想突出嘅，係將呢個決定放喺自己嘅受治理資料及安全邊界內。

公司報告嘅 3 倍 token 效率值得留意，但未足以取代企業自行測試。對準備採用嘅團隊嚟講，最終應該以端到端成本、輸出質素、延遲、可靠性同人手修正量作判斷，而唔係將「少用 token」直接等同於「慳咗錢」。