Snowflake 推出动态模型路由：在质量与成本间自动平衡 AI 代理调用

在大规模运行 AI 代理的企业团队发现，单一模型处理所有任务的效果都很差——该模型要么对简单问题而言过于昂贵，要么对复杂问题而言能力不足。模型路由（model routing）技术可自动为每项任务选择最合适的模型，正成为解决该问题的方案。

Snowflake 的 Cortex AI 网关现已提供动态模型路由功能以应对这一挑战：企业可选择“自动”（auto）而非固定模型，系统将为每项任务自动路由至在质量与成本之间实现最佳平衡的模型。Snowflake 表示，该功能可在某些工作负载上将 token 成本降低高达 3 倍——该数据源自公司内部测试结果——因为此前简单问题常由其能力最强的模型处理，导致响应成本更高、速度更慢，远超实际所需。

此举恰逢整个行业向自动化模型路由更广泛转型之际。Databricks、AWS、Google Cloud 和 Nvidia 均已宣布推出某种形式的模型路由技术。Snowflake 认为，模型路由不仅关乎价格与性能，还涉及治理（governance）与上下文（context）。

Snowflake 人工智能副总裁 Baris Gultekin 向 VentureBeat 表示：“要构建高质量、企业级的代理，正确处理上下文与治理至关重要。上下文、信任与模型选择三者密不可分。”

两项机制决定任务的路由去向。

该功能建立在 Snowflake 于 2026 年 7 月推出的 Cortex AI 网关基础之上，该网关是专为代理与模型流量设计的治理层。Gultekin 表示，在引入动态路由之前，模型选择依赖于按任务预设的静态列表，而非真正的回退（fallback）系统。

据 Gultekin 所述，动态路由本身依托于两项机制。

先由小型模型尝试。 根据 Snowflake 所称的“顾问模式”（advisor pattern），首先由一个较小的模型尝试执行任务；若其无法完成，则调用一个更大的模型作为工具，并在此基础上继续执行。

分类器依据任务历史进行分类。 一个独立的分类器经过去往查询训练，可自动将简单问题路由至更简单的模型。

客户仍可锁定特定模型。 自动路由为可选功能。客户可将路由限制于单一模型或一组预定义模型，系统仅在该限定范围内进行路由。

不收取单独费用。 Snowflake 完全按 token 使用量计价 AI 服务。路由至更便宜的模型即产生更低账单，路由决策本身不额外收费。

访问控制随任务而动，而不仅限于数据。

Snowflake 将路由与现有数据治理所采用的同一套访问控制机制绑定。

治理始于数据层面，采用基于角色的访问控制（RBAC）；随后延伸至模型层面，客户角色映射至经批准模型的集合；再进一步延伸至代理层面，代理可被限制享有比调用它的用户更窄的权限。

开源模型可在客户自有区域运行，以满足数据驻留（data residency）要求。Gultekin 表示，所有推理——无论开源模型还是专有模型——均保留在 Snowflake 的安全边界内，而非路由至外部供应商。该区域性与边界性设置对源自美国以外地区的开源模型尤为重要，包括在中国开发的 DeepSeek-V4-Flash 和 GLM-5.3。

Snowflake 的 近期收购 Natoma 公司增添了另一层能力。该交易带来了 100 多个具备范围限定、受治理访问权限的 MCP 连接器。例如，代理可仅获得对电子邮件等连接工具的只读访问权限，而非更广泛的权限。

上下文使更便宜的模型也能胜任工作。

Snowflake 最近宣布了其 Horizon Context 与 Cortex Sense 工具，以提供上下文能力。

若缺乏良好的上下文，模型必须自行开展探索性工作，包括编写并测试 SQL、在数据中搜索、以及在某操作失败时重试。Gultekin 解释道，该过程成本高昂，且通常需要能力更强的模型才能确保成功。预先打包上下文即可省去该探索步骤，这意味着更简单、更便宜的模型往往也能胜任相同任务。

Snowflake 还将代理记忆（agent memory）整合进该上下文中。随着代理被反复使用，其记忆持续更新，并融入后续查询之中。系统不会每次都从头开始重新解决同一问题；记忆本身即成为传递给模型的上下文的一部分。

OpenRouter、Databricks 与 Nvidia 正在竞相解决同一问题。

模型路由领域并不缺乏技术方案。OpenRouter 是其中最为人熟知的选项之一，它提供一个平台，使组织能够依据成本与性能进行路由。Nvidia 于 8 月 11 日宣布 Switchyard 作为一项技术层，以协助 AI 模型选择的路由。Databricks 亦推出了 Unity AI 网关的智能路由（Smart Routing）功能。 SanjMo 创始人兼首席分析师 Sanjeev Mohan 向 VentureBeat 表示：“有趣之处在于，这揭示了差异化竞争点已转移至何处。Snowflake 实际上并非在销售路由本身，而是在销售一种永不脱离受治理数据边界的路由，且该路由已内置访问控制、标签化及成本归因功能。”

Mohan 补充道，对于数据与合规性已围绕 Snowflake 构建的公司而言，保持数据原地不动并按团队归因支出的路由方式，确实是解决该问题的一项切实杠杆。而对于尚未形成此类重心的公司，中立网关则可能以更低摩擦跨更多模型进行路由。

Mohan 将市场划分为三个截然不同的阵营，而非单一竞争领域。Databricks 从数据工程与机器学习谱系（ML lineage）角度切入治理，其 Unity Catalog 对数据、模型及流水线实施治理，服务于构建与训练模型的团队。Snowflake 则从分析与访问控制角度切入治理，管控谁可访问哪些数据，并在各业务部门间归因使用情况。第三阵营包括 OpenRouter、LiteLLM、Portkey 等中立网关，以及 Azure AI Foundry 等云服务商路由器。这些方案侧重于模型广度与避免厂商锁定，而非深度治理。

选择路由器即意味着选择治理模型。

模型路由如今已成为企业的基本要求。真正关键的决策在于：哪种治理模型已契合其数据与团队的既有组织方式，而非哪家供应商的路由器速度最快或成本最低。

在代理规模化部署场景下，手动模型选择正日益成为一项成本负担。 当团队仅运行少量代理时行之有效的做法，在规模化时便会失效。数百个代理在未部署自动化成本核查机制的情况下频繁调用模型，成本将迅速累积。

应评估治理模型，而非路由器的功能清单。 据 Mohan 所言，真正的问题在于：哪种治理模型与企业已有的数据资产相匹配，以及哪种模型能提供所需的成本可见性，从而避免意外支出。

正确的起点取决于企业数据当前所在的位置。 莫汉表示，对于一家Snowflake商店而言，相较于原始模型的广度，其能从尊重现有访问模型并在平台内进行路由、同时将费用回传至成本中心的功能中获得更高价值。对于一个以Databricks为中心、且担忧训练与部署环节间数据血缘（lineage）连贯性的团队而言，围绕同一血缘关系构建的网关更能满足其需求。而对于一个采用多平台架构或以模型为先、希望在最小厂商锁定（lock-in）前提下实现最大选择自由度的团队，则更适合采用中立网关——这正是OpenRouter估值背后所强调的卖点。

莫汉表示：“对实践者而言，不要从路由器入手，而应首先考虑你已受管控的数据及平台承诺实际位于何处，以及你的利润率在多大程度上暴露于推理成本之下。”