Snowflake将这一思路称为**“智能效率”（intelligence efficiency）**。重点不是单纯压低每个Token的价格，而是在质量可接受的前提下，降低一次成功完成业务任务的总成本。

Snowflake具体发布了什么

动态模型路由将通过Cortex AI Gateway提供，并集成到Snowflake的CoCo和CoWork产品中。接入该网关的第三方AI代理也可以使用这一能力。企业能够自行规定哪些模型可以参与路由，以及应用需要优先考虑什么，例如成本、质量或延迟。

在自动模式下，路由器的目标是选择最便宜、同时又有足够把握完成任务的获批模型。常规、重复或低复杂度请求可以交给更高效的开放模型；需要复杂推理的任务，则可以转交Anthropic、OpenAI和Google等厂商的前沿模型。

企业也不必完全放弃人工控制。客户可以固定使用某个模型，或缩小可选模型范围，从而避免自动路由带来的不可控变化。

Snowflake表示，路由过程还可以遵守数据驻留和治理政策，并记录每次请求所选用的模型。这意味着，该功能不仅服务于AI成本管理，也可能帮助需要审计模型选择过程的企业建立更完整的追踪链路。

动态路由预计如何工作

Snowflake介绍了两种判断任务是否需要更强模型的机制。

“顾问模式”：先小后大

在“顾问模式”（advisor pattern）中，小型模型会先尝试完成任务。如果它无法达到要求，就可以把大型模型作为工具调用，并继续处理后续步骤。

这种方式的逻辑很直观：不必为每个简单请求支付前沿模型的价格，但遇到困难任务时仍保留升级通道。不过，首次失败、模型升级和重试都可能增加Token消耗、延迟及系统复杂度。

基于分类器的路由

另一条路径是使用分类器。分类器根据历史查询中的模式识别较为简单的请求，并在任务开始前将其分配给更轻量的模型。

因此，企业可能采用两种不同策略：让小模型先做、必要时升级；或者先对请求分类，再直接选择更合适的模型。实际效果取决于路由器是否能改善最终任务结果，而不只是选中了一个更便宜的模型。

Snowflake称Token效率最高提升3倍

Snowflake称，在一项内部dbt数据管道工作负载测试中，动态路由在保持相近质量的情况下，Token效率最高达到单独使用前沿模型的3倍。在另一项编码工作负载测试中，工程团队在保持拉取请求处理量不变的同时，Token使用量减少了约25%。

这些数字应被视为厂商自行报告的内部评估，并非经过独立验证的客户结果。不同工作负载之间的差异也可能很大：路由器在重复性较高的数据工程或编码任务上表现良好，并不意味着它在长上下文研究、复杂工具调用或高风险决策中也会得到相同结果。

对客户而言，更有意义的指标不是孤立的“节省了多少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作为代理测试框架的内部测试中，ADE-bench得分为74.4%。公司还引用了此前对GLM-5.2的测试结果：该模型得分为66%，并在该基准测试中使用了最少Token。

需要特别注意，GLM-5.2的结果并不是GLM-5.3的公开评测结果，不能将两者混为一谈。

更多开放模型加入后，动态路由才有更大的发挥空间：模型池越丰富，系统越有机会把任务需求与成本、速度和能力组合匹配起来。对企业来说，这也意味着模型选择不必局限于少数最知名的前沿模型供应商。

Snowflake强调“受治理的数据边界”

Snowflake最核心的差异化主张，不是“能够路由模型”本身，而是模型访问和路由决策与其现有的数据治理环境相连接。

公司表示，新加入的开放模型由Snowflake自行提供服务，而不是简单代理第三方API；数据、推理计算、模型权重和代理编排都在Snowflake的安全边界内运行。Snowflake还强调，客户可以继续使用现有的基于角色的访问控制和审计机制。

这是一项来自Snowflake的架构主张，并不代表每种部署方式都自动满足所有合规要求。企业仍应核实部署区域、数据驻留规则、合同条款、日志行为，以及特定工作负载实际允许使用哪些模型。

对于已经把受治理数据和AI应用集中在Snowflake上的组织，这一方案的吸引力可能不只是“换用更便宜的模型”。它试图让模型选择成为与数据访问相同的一套控制、审计和成本管理体系的一部分。

它与其他路由方案有什么不同

模型路由并非Snowflake独有。Amazon Bedrock的智能提示路由也通过无服务器端点，在同一模型家族内的基础模型之间分配请求，并根据预测的响应质量和成本进行选择。

Databricks的Unity AI Gateway则通过中央控制平面连接模型和MCP服务，用于管理不同供应商之间的容量、可用性和支出。Google Cloud的API Gateway模型路由主要承担托管流量层的角色，将兼容OpenAI格式的请求转发到指定的Gemini Enterprise Agent Platform模型端点。NVIDIA NeMo Switchyard强调与供应商无关的路由SDK和层，可以将路由逻辑与具体供应商端点分离。OpenRouter则更侧重多供应商聚合和供应商级路由，默认在合适的供应商之间进行负载均衡，以提高可用性。

因此，真正值得比较的并不是“谁能把请求发送给更便宜的模型”，而是以下问题由谁负责、又在哪里完成：

• 数据访问和治理政策在哪里执行？
• 路由逻辑和模型运行位于同一平台，还是由中立网关分开管理？
• 企业能否查看模型选择、计费归属和失败重试记录？
• 模型、供应商、云环境和部署区域是否足够灵活？

对已经深度使用Snowflake数据平台的企业而言，紧密集成的治理模式可能更有吸引力。若企业更重视跨供应商迁移、独立路由逻辑或多云灵活性，中立型网关可能更合适。这不是简单的产品优劣之争，而是平台整合与可移植性之间的取舍。

评估成本节省时，别只看模型单价

企业在生产环境采用自动路由前，应使用具有代表性的实际工作负载，与固定使用前沿模型的基线进行对比。至少需要跟踪：

• 每个成功完成任务的总成本，而不仅是所选模型的Token价格；
• 路由器或分类器本身是否产生费用；
• 顾问模式升级、备用模型、重试或工具执行失败带来的额外调用；
• 端到端延迟，包括路由、检索、上下文组装和二次模型调用；
• 不同任务类别的成功率与输出质量；
• 小型模型可能引入的幻觉、政策违规和质量回退；
• 人工审核、修正、升级处理和返工成本；
• 数据驻留、可观测性、数据出口及供应商锁定限制。

Snowflake表示不会单独收取路由决策费用，而是按照Token消耗计费。但升级和重试仍可能增加总用量与延迟。因此，合理的验收标准应是：在满足应用质量和治理要求的前提下，动态路由是否降低了每个被接受结果的端到端成本。

结论

Snowflake此次公告包含两条主线：一是让Cortex AI Gateway在获批模型之间动态选择，二是扩展Cortex AI可用的开放模型范围。动态模型路由预计很快进入私有预览；DeepSeek-V4-Flash 0731已宣布进入私有预览，GLM-5.3则将在具备可用性后进入预览。

把简单任务交给便宜模型、把复杂任务交给强模型，这个思路本身并不新。Snowflake真正想强调的是：模型选择可以被放进其受治理的数据和安全边界中。

Snowflake报告的“最高3倍Token效率”值得关注，但还不能直接等同于企业账单会下降3倍。最终答案仍要通过客户自己的生产测试得出，并以端到端成本、质量、延迟、可靠性和人工修正量，而不是Token减少幅度作为判断依据。

Snowflake将这一思路称为**“智能效率”（intelligence efficiency）**。重点不是单纯压低每个Token的价格，而是在质量可接受的前提下，降低一次成功完成业务任务的总成本。

Snowflake具体发布了什么

动态模型路由将通过Cortex AI Gateway提供，并集成到Snowflake的CoCo和CoWork产品中。接入该网关的第三方AI代理也可以使用这一能力。企业能够自行规定哪些模型可以参与路由，以及应用需要优先考虑什么，例如成本、质量或延迟。

在自动模式下，路由器的目标是选择最便宜、同时又有足够把握完成任务的获批模型。常规、重复或低复杂度请求可以交给更高效的开放模型；需要复杂推理的任务，则可以转交Anthropic、OpenAI和Google等厂商的前沿模型。

企业也不必完全放弃人工控制。客户可以固定使用某个模型，或缩小可选模型范围，从而避免自动路由带来的不可控变化。

Snowflake表示，路由过程还可以遵守数据驻留和治理政策，并记录每次请求所选用的模型。这意味着，该功能不仅服务于AI成本管理，也可能帮助需要审计模型选择过程的企业建立更完整的追踪链路。

动态路由预计如何工作

Snowflake介绍了两种判断任务是否需要更强模型的机制。

“顾问模式”：先小后大

在“顾问模式”（advisor pattern）中，小型模型会先尝试完成任务。如果它无法达到要求，就可以把大型模型作为工具调用，并继续处理后续步骤。

这种方式的逻辑很直观：不必为每个简单请求支付前沿模型的价格，但遇到困难任务时仍保留升级通道。不过，首次失败、模型升级和重试都可能增加Token消耗、延迟及系统复杂度。

基于分类器的路由

另一条路径是使用分类器。分类器根据历史查询中的模式识别较为简单的请求，并在任务开始前将其分配给更轻量的模型。

因此，企业可能采用两种不同策略：让小模型先做、必要时升级；或者先对请求分类，再直接选择更合适的模型。实际效果取决于路由器是否能改善最终任务结果，而不只是选中了一个更便宜的模型。

Snowflake称Token效率最高提升3倍

Snowflake称，在一项内部dbt数据管道工作负载测试中，动态路由在保持相近质量的情况下，Token效率最高达到单独使用前沿模型的3倍。在另一项编码工作负载测试中，工程团队在保持拉取请求处理量不变的同时，Token使用量减少了约25%。

这些数字应被视为厂商自行报告的内部评估，并非经过独立验证的客户结果。不同工作负载之间的差异也可能很大：路由器在重复性较高的数据工程或编码任务上表现良好，并不意味着它在长上下文研究、复杂工具调用或高风险决策中也会得到相同结果。

对客户而言，更有意义的指标不是孤立的“节省了多少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作为代理测试框架的内部测试中，ADE-bench得分为74.4%。公司还引用了此前对GLM-5.2的测试结果：该模型得分为66%，并在该基准测试中使用了最少Token。

需要特别注意，GLM-5.2的结果并不是GLM-5.3的公开评测结果，不能将两者混为一谈。

更多开放模型加入后，动态路由才有更大的发挥空间：模型池越丰富，系统越有机会把任务需求与成本、速度和能力组合匹配起来。对企业来说，这也意味着模型选择不必局限于少数最知名的前沿模型供应商。

Snowflake强调“受治理的数据边界”

Snowflake最核心的差异化主张，不是“能够路由模型”本身，而是模型访问和路由决策与其现有的数据治理环境相连接。

公司表示，新加入的开放模型由Snowflake自行提供服务，而不是简单代理第三方API；数据、推理计算、模型权重和代理编排都在Snowflake的安全边界内运行。Snowflake还强调，客户可以继续使用现有的基于角色的访问控制和审计机制。

这是一项来自Snowflake的架构主张，并不代表每种部署方式都自动满足所有合规要求。企业仍应核实部署区域、数据驻留规则、合同条款、日志行为，以及特定工作负载实际允许使用哪些模型。

对于已经把受治理数据和AI应用集中在Snowflake上的组织，这一方案的吸引力可能不只是“换用更便宜的模型”。它试图让模型选择成为与数据访问相同的一套控制、审计和成本管理体系的一部分。

它与其他路由方案有什么不同

模型路由并非Snowflake独有。Amazon Bedrock的智能提示路由也通过无服务器端点，在同一模型家族内的基础模型之间分配请求，并根据预测的响应质量和成本进行选择。

Databricks的Unity AI Gateway则通过中央控制平面连接模型和MCP服务，用于管理不同供应商之间的容量、可用性和支出。Google Cloud的API Gateway模型路由主要承担托管流量层的角色，将兼容OpenAI格式的请求转发到指定的Gemini Enterprise Agent Platform模型端点。NVIDIA NeMo Switchyard强调与供应商无关的路由SDK和层，可以将路由逻辑与具体供应商端点分离。OpenRouter则更侧重多供应商聚合和供应商级路由，默认在合适的供应商之间进行负载均衡，以提高可用性。

因此，真正值得比较的并不是“谁能把请求发送给更便宜的模型”，而是以下问题由谁负责、又在哪里完成：

• 数据访问和治理政策在哪里执行？
• 路由逻辑和模型运行位于同一平台，还是由中立网关分开管理？
• 企业能否查看模型选择、计费归属和失败重试记录？
• 模型、供应商、云环境和部署区域是否足够灵活？

对已经深度使用Snowflake数据平台的企业而言，紧密集成的治理模式可能更有吸引力。若企业更重视跨供应商迁移、独立路由逻辑或多云灵活性，中立型网关可能更合适。这不是简单的产品优劣之争，而是平台整合与可移植性之间的取舍。

评估成本节省时，别只看模型单价

企业在生产环境采用自动路由前，应使用具有代表性的实际工作负载，与固定使用前沿模型的基线进行对比。至少需要跟踪：

• 每个成功完成任务的总成本，而不仅是所选模型的Token价格；
• 路由器或分类器本身是否产生费用；
• 顾问模式升级、备用模型、重试或工具执行失败带来的额外调用；
• 端到端延迟，包括路由、检索、上下文组装和二次模型调用；
• 不同任务类别的成功率与输出质量；
• 小型模型可能引入的幻觉、政策违规和质量回退；
• 人工审核、修正、升级处理和返工成本；
• 数据驻留、可观测性、数据出口及供应商锁定限制。

Snowflake表示不会单独收取路由决策费用，而是按照Token消耗计费。但升级和重试仍可能增加总用量与延迟。因此，合理的验收标准应是：在满足应用质量和治理要求的前提下，动态路由是否降低了每个被接受结果的端到端成本。

结论

Snowflake此次公告包含两条主线：一是让Cortex AI Gateway在获批模型之间动态选择，二是扩展Cortex AI可用的开放模型范围。动态模型路由预计很快进入私有预览；DeepSeek-V4-Flash 0731已宣布进入私有预览，GLM-5.3则将在具备可用性后进入预览。

把简单任务交给便宜模型、把复杂任务交给强模型，这个思路本身并不新。Snowflake真正想强调的是：模型选择可以被放进其受治理的数据和安全边界中。

Snowflake报告的“最高3倍Token效率”值得关注，但还不能直接等同于企业账单会下降3倍。最终答案仍要通过客户自己的生产测试得出，并以端到端成本、质量、延迟、可靠性和人工修正量，而不是Token减少幅度作为判断依据。