Snowflake 的 Cortex AI Gateway 新增动态模型路由
在企业多年来几乎为所有任务分配同一个昂贵模型后,Snowflake 推出了动态模型路由。这项公告登上 Google News,并提出了一个颇具吸引力的承诺:在不牺牲企业所期待成果的前提下,降低 AI 使用成本。
关键进展并非 Snowflake 的产品目录中又增加了一个模型。Cortex AI Gateway 现在旨在于代理执行工作的每个环节选择合适的模型。简单请求可交由高效模型处理,而复杂推理则可转向前沿系统。
这使 Snowflake 加入了一场已涵盖 Amazon Bedrock、Google Vertex AI、Microsoft Foundry 和独立 AI 网关的竞争。不过,Snowflake 的切入点颇具特色:其客户已经在平台内存储受治理的业务数据,并运行分析工作负载。
机会很明确。Snowflake 可以将模型选择转变为托管的数据平台服务,而非另一个应用组件。风险同样明确:客户必须信任 Snowflake 的路由决策、质量衡量方式、治理控制以及其宣称的效率提升。
Snowflake 实际上对 Cortex AI Gateway 做了哪些改变
Snowflake 正在将模型选择从应用代码转移到更贴近企业数据的受治理控制层。
Snowflake 于 2026 年 8 月 18 日宣布在 Cortex AI Gateway 中推出动态模型路由。该公司此前于 7 月通过一则介绍监控、成本管理和代理治理控制的官方公告推出了更广泛的网关基础能力。该路由功能预计将进入私密预览阶段,而非立即全面上线。
AI 网关是位于应用与处理其请求的模型之间的控制层。它可以执行策略、记录使用情况、管理供应商,并在无需重写每个应用的情况下重定向流量。
动态路由增加了一项更具影响力的决策。网关不再只是将流量发送至开发者选定的模型,而是评估每项任务应由哪个获批准的模型处理。
Snowflake 表示,该系统会考虑质量、速度、客户偏好和成本。它将复杂度较低或重复性工作引导至高效模型,需要更深层推理的请求则可交由能力更强的前沿模型处理。
这种区别在代理执行期间尤为重要。企业代理很少只执行一种统一任务:它可能分类请求、检索记录、总结文档、生成代码、验证答案,并解释结果。
在每一步都使用可用的最大模型,具有操作上的简便性,但也可能在分类、格式化或常规检索任务上浪费 token。为每一个步骤手动分配模型,则会带来额外的维护负担。
动态路由承诺提供一条中间路径:Snowflake 维护选择逻辑,而管理员决定路由器可考虑哪些模型。随着可用模型变化,应用仍可保持一致的接口。
这则路由公告称,该能力将适用于 Snowflake CoCo 和 Snowflake CoWork。使用 Cortex AI Gateway 的第三方代理也可访问该能力。
管理员仍将保留对决策过程的边界控制。Snowflake 表示,路由器仅考虑获批准的模型,并遵守已配置的数据驻留设置。每项路由决策都会被记录,以供运营和合规审查。
该公司也在扩展模型目录。Snowflake 计划加入 DeepSeek-V4-Flash 0731 和 GLM-5.3,并继续提供来自 Anthropic、Google、Meta、Mistral、OpenAI 和 SpaceXAI 的模型。
这一扩展是路由战略的核心。当每个获批准选项都提供相似的性能和资源消耗时,路由器几乎没有多少可优化空间。更丰富的模型多样性,为将工作负载复杂度与高效系统相匹配创造了更多空间。
因此,最有用的理解框架比 Google News 的标题更广:Snowflake 正试图将模型选择变成一项持续的平台运营工作,而不再希望这一决策固定在应用代码中。
Google News 的关注为何忽略了 Snowflake 更大的押注
投资逻辑较少取决于单一功能,更多取决于 Snowflake 能否成为企业 AI 消费的控制点。
模型路由看起来可能只是一项技术便利。对 Snowflake 而言,它也是从存储和处理数据,扩展到治理代理如何消耗智能能力的一种方式。
这一位置之所以重要,是因为企业代理依赖上下文。它们需要结构化记录、文档、权限、业务定义和使用历史。Snowflake 已经为其客户管理了许多此类资产。
与该环境相连的网关,可以在模型接收请求之前应用现有访问策略。它还可以将模型消耗与团队、用户、应用和成本中心关联起来。
Snowflake CoCo 通过公司的基于角色的访问控制和标签系统扩展了这些控制能力。管理员可以分配默认模型、归属使用量、设定配额,并在接近配置限额时接收通知。
这比单纯的模型访问提供了更强的价值主张。模型供应商已经提供了能力出色的 API。更困难的企业问题在于:哪些系统可以看到特定数据、由谁付费,以及每项决策如何接受审查。
Cortex AI Gateway 有可能成为这些策略汇合的地方。Snowflake 将获得对应用层更大的影响力,而客户则获得一个统一的数据与 AI 治理运营界面。
这一战略也回应了不稳定的模型经济性。模型能力、延迟、可用性和使用费率都可能迅速变化。在应用设计阶段选定的模型,数月后可能变得效率不佳。
一个持续维护的路由器可在不迫使客户重建代理的情况下改变这一选择。Snowflake 可以集中评估新选项,并在多个产品中应用更新后的决策。
这种安排将工作从客户工程团队转移给 Snowflake,也转移了部分决策权。客户必须接受平台的路由策略能够反映他们自己对质量的定义。
随着代理工作负载扩张,这种权衡会变得更加重要。每周摘要可以容忍语气上的适度变化;由 AI 生成的数据管道则需要更严格的验证、可复现性和错误处理。
Snowflake 将期望的结果称为“智能效率”。这一表述意指以更少的不必要消耗,将模型、计算、数据和上下文转化为可衡量的业务价值。
在一篇对该战略的官方说明中,Snowflake CEO Sridhar Ramaswamy 表示,客户可以定义获批准模型及其关注的权衡取舍,之后网关会根据这些策略、成本和性能数据评估任务。Snowflake 还称,第二个模型会评估已完成的工作以形成反馈闭环;不过,客户仍需借助独立的生产环境证据来判断该机制保护质量的可靠性。
这一概念符合 Snowflake 基于使用量的商业模式。如果客户能够在可控预算内运行更多有价值的 AI 工作,他们就有理由继续将应用和数据留在该平台上。
然而,更低的 token 消耗并不自动意味着更低的平台总支出。客户可能将效率收益重新投入更多代理、更多请求或更复杂的工作流。
这一结果仍可能使 Snowflake 受益。更有力的信号将是:客户在降低每项已完成任务消耗的同时,增加有价值的工作负载。仅凭 token 总量下降,难以说明多少业务价值。
这也是为何投资者应将产品效率与收入收缩区分开来。更好的路由可减少浪费,同时鼓励更广泛的采用。最终对收入的影响取决于使用量、平台留存和工作负载扩张。
对开发者和业务团队而言,其价值更为实际。更少的模型专属集成可减少维护工作。当模型组合发生变化时,集中式路由也能让 AI 工作流更容易审计。
构建知识融合工作流的团队也面临相似原则。输出质量取决于对上下文来源和模型行为的共同治理,而不仅仅是选择最大的模型。
真正的竞争是 Snowflake 与客户自有路由之间的较量
Snowflake 的主要对手不是某一家模型供应商,而是客户在 Snowflake 之外构建的自控路由层。
Amazon Bedrock、Google Vertex AI、Microsoft Foundry 和独立网关都提供不同形式的多模型访问。客户也可以通过开源软件和直接调用供应商 API 来搭建路由能力。
这使“更多模型”成为不足以构成优势的主张。企业买家已经有多种途径可接入专有模型和开放权重系统。他们可以选择托管云服务、专业网关或内部编排方案。
战略问题关乎控制权:应由 Snowflake 决定请求如何在获批准模型之间流转,还是客户应将这一逻辑保留在自己的基础设施中?
客户自有路由提供可移植性。企业可以在多个云平台之间分配流量、运行自托管模型、协商供应商关系,并在不更换网关的情况下切换数据平台。
它还能提供更细粒度的路由规则。开发者可能需要针对延迟、上下文长度、司法管辖区、故障切换行为或任务专属评估设定阈值。通用的平台路由器未必能覆盖所有需求。
不过,自行掌控也会带来运营成本。团队必须维护供应商集成、身份验证、重试、可观测性、策略执行和评估数据。每增加一个新模型,就会引入一轮新的测试周期。
Snowflake 的回应是集成。如果数据、权限、应用和计费都已存在于 Snowflake 内部,将路由保留在那里便可减少多次交接。
公司的动态路由详情指出,每项决策都保持在现有治理边界之内。这种设计对试图控制模型蔓延的企业颇具吸引力。
Amazon 和 Google 则从更广泛的云平台定位切入市场。Bedrock 将基础模型与 AWS 的身份、网络、安全和基础设施相连接;Vertex AI 则将模型与 Google Cloud 服务及 Gemini 相连接。
Snowflake 无法匹敌超大规模云厂商的基础设施广度。相反,它可以主张企业数据提供了更有价值的控制点:路由从受治理的业务上下文已经存在的地方开始。
独立网关带来了不同的挑战。它们通常强调供应商中立性、自托管、细粒度可观测性,以及与多种应用框架的兼容性。
这些产品可以位于 Snowflake 之上,而非其内部。客户可能从 Snowflake 检索受治理数据,但通过外部网关发送模型请求。这种安排会限制 Snowflake 对 AI 层的控制。
因此,Cortex AI Gateway 必须证明,集成带来的价值超过可选性。其最核心的受众包括已经将 Snowflake 视为核心数据平台的组织。
其较弱的受众则包括追求多云可移植性或大规模自托管的团队。这些客户可能不愿将数据访问和模型选择都置于同一家供应商之下。
区域处理又增加了一层考量。Snowflake 支持跨 AWS、Azure 和 Google Cloud 区域的跨区域推理。管理员可以选择全球、特定云、区域或仅限主区域的边界。
根据区域控制,客户数据仍存储在其主区域。推理载荷可临时传输至获批准的处理区域。
Snowflake 表示,这些载荷不会在处理区域持久保存。在同一云服务提供商内,流量始终保留在该提供商的私有网络中。跨云流量则采用相互认证的加密方式。
这些控制措施扩大了模型可用性,但也为受监管行业的采购方带来了疑问。安全审查必须区分存储数据与瞬态提示词和响应。
禁用跨区域推理可提供更严格的数据驻留保障,但也可能限制可用模型和 Cortex 功能。这是在模型选择与地理限制之间真实存在的权衡。
对 Snowflake 而言,最理想的结果是让其网关成为使用 Snowflake 数据的应用的默认路径。客户仍可选择边界,而 Snowflake 则负责管理底层不断变化的模型生态。
另一种结果则不那么有利。客户可能将 Cortex AI Gateway 视为众多路由选项之一,并将其主要控制层保留在其他地方。
只有质量衡量有效,模型路由才能发挥作用
路由器最困难的工作不是找到更便宜的模型,而是判断该模型何时仍然足够好。
Snowflake 表示,Cortex AI Gateway 会选择能够有把握完成任务的最经济模型。这一说法把整个技术挑战都包含在“有把握”这个词中。
质量并非一个通用分数。某个模型可能擅长数据工程,却不擅长法律摘要。它可能生成正确的代码,却给出不可靠的解释。
即使单一工作负载也可能包含相互竞争的要求。一个支持代理可能需要准确性、低延迟、恰当语气、政策合规性和可靠引用。改善一个维度可能会削弱另一个维度。
因此,路由需要任务分类和可靠评估。系统必须先识别请求需要什么,才能选择合适的模型。
它还必须检测任务在执行过程中何时变得更困难。一个代理可能先进行简单检索,之后却遇到相互矛盾的证据。此时路由器需要升级路径。
Snowflake 的早期结果提供了有用信号,但它们仍属于公司自行开展的评估。在一项测试中,经过路由的代理构建 dbt 管道时,令牌效率最高提升至三倍。
Snowflake 表示,与仅使用前沿模型的方法相比,该测试保持了可比的质量。在另一项编码评估中,工程团队以约少 25% 的令牌完成了相同数量的拉取请求。
这些数字需要谨慎解读。“最高”描述的是观察到的最佳结果,而非普遍结果。可比质量同样取决于所选任务、评估人员和验收标准。
该公司尚未证明每个生产工作负载都能实现类似效率。动态模型路由也正迈向私有预览阶段,这限制了独立的运营证据。
Snowflake 还使用 ADE-bench 报告了额外的模型结果;该评估聚焦于智能体式数据工程。据称,DeepSeek-V4-Flash 使用 Snowflake CoCo 作为智能体框架时得分为 74.4%。
该公司表示,这一结果超过了其评估中纳入的领先专有模型。Snowflake 还报告称,GLM-5.2 在该基准测试中以最低令牌消耗获得了 66% 的分数。
这些结果支持将专业化工作路由至高效开放模型的理由。它们并不能证明这些模型是每一种企业工作负载的最佳选择。
基准测试设计至关重要。当提示词、工具和成功条件与评估相似时,模型可能表现强劲。生产数据则会带来不明确的需求、异常的模式、权限失败以及不断变化的业务定义。
路由器还需要防范无声的质量下降。一个消耗更少令牌但答案错误的系统并不高效。它只是将成本从推理转移到人工审查或运营故障中。
管理员需要有用的日志,而不只是路由记录。他们应能将每个模型决策与延迟、消耗、任务结果、回退行为和用户反馈关联起来。
应用团队还需要覆盖机制。一些受监管或高影响流程应使用固定且已验证的模型,直到受控审查批准其他选项。
Snowflake 表示,管理员可以限制可用的模型和供应商。该控制可降低风险敞口,但不能替代针对工作负载的测试。
合理的生产模式应将自动路由与明确的质量门槛结合。低风险任务可以采用更广泛的优化;高风险操作则可要求验证、固定模型或人工批准。
这并非否定动态路由,而是指出该功能要发挥作用所需的条件:在应用离开测试阶段后,路由质量必须仍然可观察。
同一原则也适用于更新。随着模型演进,Snowflake 可以修订选择逻辑。客户需要知道这些变化何时会影响既有工作流的输出。
自动改进听起来很有吸引力,直到模型变更改变了格式、拒答行为或工具使用方式。版本记录和可重复评估将成为诊断这些变化的关键。
私有预览将揭示 Snowflake 提供了多少控制能力。采购方应检查路由策略是否支持审计要求,而不会迫使开发人员从零散日志中重建决策过程。
开放模型为路由器提供了更大的经济杠杆
当高效的开放模型能够处理过去需要前沿系统完成的专业任务时,动态路由的价值会更高。
Snowflake 新增的模型与网关公告并非彼此独立。DeepSeek-V4-Flash 0731 和 GLM-5.3 扩大了每次路由决策可用的系统集合。
开放权重模型可提供不同的性能、部署和消耗特征。它们也降低了对少数专有模型供应商的依赖。
Snowflake 可以将这些模型置于一致的访问控制之下。客户无需为每次发布构建新的集成,也能获得模型选择权。
这种抽象很有用,因为模型领先地位会因工作负载而变化。一个系统可能擅长通用推理,另一个则可能更适合编码或数据转换。
稳定的网关接口使平台能够改变底层选择。应用可以继续发送请求,而 Snowflake 则更新评估并添加获批准的模型。
这种灵活性也赋予 Snowflake 谈判筹码。更广泛的模型池降低了某一家供应商成为每个请求默认选择的可能性。
如果竞争降低了获得可接受结果所需的资源,客户便可受益。然而,Snowflake 也因此有责任准确呈现这些权衡。
模型目录不能只是一份清单。Snowflake 需要提供可靠证据,说明哪些模型在特定业务条件下表现良好。
其 ADE-bench 结果提供了一个初步例子。该基准聚焦于数据工程,与 Snowflake 的客户基础和产品定位高度契合。
这种专业化可以成为其相较通用网关的优势。Snowflake 可以针对涉及模式、管道、SQL、分析和受治理企业上下文的任务评估模型。
不过,平台特定的评估可能引入偏差。通过 Snowflake CoCo 进行的测试可能更有利于为该环境优化的模型或工具配置。
一旦客户获得预览访问权限,独立测试将变得重要。企业应使用自己的数据和验收规则,将路由执行与固定模型基准进行比较。
开放模型也带来治理问题。组织可能批准部分供应商用于一般用途,同时限制其用于机密或受监管工作负载。
Cortex AI Gateway 表示将遵循管理员批准的模型列表。这意味着路由器的经济优化空间会因客户而异。
批准六家供应商的企业会给予路由器更多替代选项。另一家仅在一个区域内批准两种模型的企业,可能看到较小的改善。
区域可用性还可能进一步缩小模型池。严格的数据驻留要求可能会阻止访问成本与质量平衡最佳的模型。
这使得路由性能具有情境性。Snowflake 无法承诺一个通用效率比率,因为每位客户都定义了不同的运行边界。
因此,该功能的价值应根据客户允许使用的模型集合来衡量。采购方需要看到路由器在其自身政策范围内取得的结果。
模型多样性还可以提升韧性。如果某家供应商面临容量压力,网关可以将符合条件的流量导向其他地方。这取决于应用能否容忍不同模型输出之间的差异。
结构化输出、工具调用和安全行为在不同供应商之间并不完全相同。回退模型必须满足相同的应用契约。
Snowflake 的抽象可以向开发人员隐藏供应商差异,但无法消除这些差异。只要智能体能够采取具有重大影响的行动,就仍需进行谨慎验证。
更广泛的趋势有利于多模型系统。企业日益认识到,能力最强的模型并不自动意味着它适合每一个步骤。
Snowflake 正押注数据平台应协调这种组合。如果这一方法奏效,模型品牌将在日常企业应用中变得不那么显眼。
届时,网关将比任何单一模型集成更具战略重要性。它控制选择、政策、衡量,以及改善未来决策的反馈循环。
Snowflake 客户和 SNOW 投资者接下来应关注什么
三个信号将显示 Cortex AI Gateway 是会成为持久的平台优势,还是仍只是一个吸引人的预览演示。
第一个信号是私有预览的证据。Snowflake 需要在比其内部数据工程和编码测试更多的工作负载上获得客户结果。
采购方应寻找涵盖质量、延迟、令牌使用、回退率和人工修正的任务级衡量结果。这些结果应将路由与固定模型基准进行比较。
来自受监管行业的证据将尤其有用。金融服务、医疗保健和政府用户对数据驻留、访问和可复现性提出了更严格的要求。
如果预览客户报告在不提高错误率的情况下实现了稳定效率,Snowflake 的核心主张将更有说服力。如果结果差异很大,路由可能需要比宣传所称更多的手动配置。
第二个信号是路由控制的深度。管理员需要针对获批准模型、区域、工作负载、预算和升级行为制定清晰政策。
开发人员还需要了解单个决策的可见性。记录哪个模型处理了请求固然有帮助,但生产环境调试需要更多上下文。
团队应评估自己是否能够复现某个路由结果。他们还应审查模型固定、策略版本控制、评估挂钩机制,以及针对异常行为的告警。
强有力的控制能力将使 Cortex AI Gateway 区别于基础的自动选择器。薄弱的控制能力则会促使成熟客户转向外部编排方案。
第三个信号来自 Snowflake 的业务披露。投资者应关注产品采用情况、剩余履约义务、客户扩展,以及有关 AI 工作负载增长的评论。
没有任何单一指标能够证明模型路由正在推动营收增长。一个有参考价值的模式应当是:AI 活动增加、平台留存提升,同时每项完成任务的消耗得到控制。
Snowflake 还应说明,路由是否扩大了现有客户的使用量。相比仅在 Cortex 已提供的模型之间转移请求,新的智能体工作负载更具意义。
竞争将为这三个信号提供另一条线索。AWS、Google、Microsoft 以及独立网关供应商都会持续改进各自的路由和治理层。
Google 已在 Vertex AI 中提供 Model Garden 和模型优化能力。AWS 则将多模型推理与身份管理、网络、护栏及丰富的云服务相结合。
Snowflake 必须证明,贴近受治理的企业数据能够带来更好的运营体验。否则,客户可以在多个数据和云平台之上部署网关。
Google News 的热度会比这场竞争消退得更快。产品公告会吸引关注,但企业控制点是通过一次次部署决策逐渐形成的。
对于数据团队而言,当前的行动是先在加入预览计划前定义一套评估集。它应包含真实提示词、敏感案例、预期输出和可接受的错误阈值。
团队应衡量完成的成果,而不只是 token 数量。一个节省 token 却需要更多审查的路由,可能会增加总运营成本。
他们还应按后果对工作负载进行分类。状态摘要和格式化任务可以接受更广泛的优化;生产环境变更和受监管决策则需要更严格的控制。
对于企业采购方而言,若 Snowflake 已承载重要数据和权限,Cortex AI Gateway 值得关注。这种集成可减少模型管理工作,并简化治理。
寻求广泛可移植性的采购方,应权衡这种便利与更深平台依赖的风险。日后将路由迁出 Snowflake,可能需要新的策略、日志和应用集成。
对于知识工作者而言,其影响往往并不明显。一个工作场所智能体可能在一次请求中使用多个模型,而不会暴露这些切换过程。
这种不可见性只有在结果依然可靠时才有价值。用户不必理解模型路由,但管理员必须能够解释故障原因。
Snowflake 的思路具有说服力,因为企业 AI 不可能永远将每项任务都交给最昂贵的系统。它也不能将降低消耗视为成功的唯一标准。
如果 Cortex AI Gateway 能够在保留企业所需成果、控制能力和问责机制的同时选择成本更低的模型,它就能成功。这个标准远比路由流量困难得多。
关注 Google News 的读者应关注预览阶段的证据,而非标题中的投资措辞。决定性问题在于,客户是否信任 Snowflake 代表他们做出模型选择。
如果这种信任形成,Snowflake 就能在受治理数据与企业智能体之间占据有价值的一层。如果未能形成,客户将继续把路由逻辑掌握在自己手中。
哪一种结果会改变贵组织的决策:经验证的质量提升、更深入的管理控制,还是证明路由能扩大有用 AI 工作负载的证据?这才是下一步值得追踪的信号。



