Snowflake CoCo跨区域推理配置与合规指南

要为模型配置Snowflake CoCo：将账户级设置代理设为自动，在每个界面上设置每用户每日积分限制，并且除非法律要求，否则保持模型 RBAC 不变。这就是全部答案——下面解释了原因。

CoCo 运行在通过 Snowflake Cortex 提供的模型上。您的团队默认获得哪个模型、开发人员是否可以更改它以及他们可以花费多少都由您配置。这是为进行该设置的 ACCOUNTADMIN 准备的，完成后您将拥有一个默认模型、一个支出上限和一个成本归属说明。

如何设置账户级默认模型

CoCo 从系统管理的 CORTEX_CODE.CONFIG 架构中的代理对象读取其默认模型。ACCOUNTADMIN 创建它，CoCo 在会话启动时读取它。

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE AGENT CORTEX_CODE.CONFIG.DEFAULT
  FROM SPECIFICATION
  $$
  models:
    orchestration: auto
$$;

然后授予数据库、架构和代理的 USAGE 权限，以便设置实际生效。授予 PUBLIC 以实现账户级覆盖。

GRANT USAGE ON DATABASE CORTEX_CODE TO ROLE PUBLIC;
GRANT USAGE ON SCHEMA CORTEX_CODE.CONFIG TO ROLE PUBLIC;
GRANT USAGE ON AGENT CORTEX_CODE.CONFIG.DEFAULT TO ROLE PUBLIC;

在您对该规范进行创造性操作之前：`models.orchestration` 目前是唯一支持的键，因此没有按工作负载的配置，也没有针对聊天与代理工作的单独设置。如果您计划在账户级别将廉价任务路由到廉价模型，您无法做到。

要稍后更改默认值，请使用 `ALTER AGENT CORTEX_CODE.CONFIG.DEFAULT FROM SPECIFICATION` 并带上新值。设置适用于会话启动，Snowflake 指出具体行为可能因界面而异。完整参考：配置默认模型设置。

除非有理由，否则使用 `auto`

`auto` 让 Snowflake 选择模型，这适合几乎所有人。将 `auto` 解析出的结果视为 Snowflake 拥有的实现细节，随着新模型的发布可以更改——这就是使用它的意义。仅在特定原因下固定特定模型：评估运行的可重复性、命名供应商的合规要求、您追踪到特定版本的回归。如果您固定了，您就拥有了升级路径，而您会忘记自己拥有它。

检查您的账户实际可以访问哪些模型

这是让人们困惑的地方。您今天可以从 SQL 调用的模型不一定能在 `models.orchestration` 中命名，所以在固定之前请检查。

产品线涵盖 Claude 和 OpenAI GPT 模型，并随着新模型的发布而变化，因此这里打印的任何列表都会过时。聊天输入中的模型选择器显示您的账户当前实际可以访问的模型，Snowflake 将其视为权威来源，而不是固定列表。

该选择器中的一些条目是预览模型。Snowflake 对预览功能的立场是它们不适合生产工作负载，因此账户级固定一个预览模型是一个决定，而不是默认。

上下文窗口和输出限制因模型而异，因此在假设大上下文之前请检查跨区域推理。

对于代理工作，能力更重要。较弱的模型在困难的多文件重构中会失败、重试，并烧掉令牌来产生您丢弃的东西。每次成功结果的成本才是重要的数字。

开发人员如何在会话中覆盖模型

开发人员可以运行 `/model` 在会话中切换模型。子代理可以声明 `model: inherit` 以使用会话的模型运行，而不是静默地回退到不同的模型。

为什么 Snowflake CoCo 需要跨区域推理

CoCo 需要跨区域推理才能运行，您不应假设自己知道账户的设置。默认值取决于您的云、区域、账户创建时间和账户类型，Snowflake 已经随时间更改了这些默认值。某些账户仅限于某个地理区域，某些完全开放，某些仅限于本区域，某些完全排除在默认之外。检查参数在您自己的账户上，而不是推测它应该是什么。

您选择的范围既是模型可用性决策，也是合规性决策。缩小范围会缩小您可以访问的模型，而一个在某个账户中有效的 `models.orchestration` 值在另一个账户中可能无法访问。

将模型 RBAC 用于治理，而非预算

按模型的 RBAC 通过SNOWFLAKE.MODELS 中的应用程序角色存在，这是 Snowflake 推荐用于控制模型访问的方式：细粒度，且是未来机制。不过要谨慎限定范围，因为您可能没有考虑到的 Cortex 功能可能依赖于您限制的模型。如果您使用旧的 `CORTEX_MODELS_ALLOWLIST` 账户参数，它将被废弃，取而代之的是按已发布的分阶段计划进行模型 RBAC——该参数最终将变得不可设置然后消失，Snowflake 会在此过程中为您迁移现有配置。检查当前时间线并主动迁移，而不是等待被迁移。

这是一个治理杠杆。它不是预算杠杆。

如何限制每用户每日积分支出

这是您拥有的最实用的成本控制。每个界面一个参数：

CLI — `CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER`

Desktop — `CORTEX_CODE_DESKTOP_DAILY_EST_CREDIT_LIMIT_PER_USER`

Snowsight — `CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER`

这三个参数行为相同。它们默认为 -1，表示没有限制。正数会在窗口内估计使用量超过限制时阻止该界面。值 0 完全禁用该界面。

设置账户基线，然后为需要更多空间的人提高它：

ALTER ACCOUNT SET CORTEX_CODE_DESKTOP_DAILY_EST_CREDIT_LIMIT_PER_USER = 5;
ALTER USER power_user SET CORTEX_CODE_DESKTOP_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;

用户级覆盖账户级。“每日”低估了行为：窗口是滚动的 24 小时，一旦使用量衰减到限制以下，访问会自动恢复，因此没有人需要提交工单来解除阻塞。

因为 0 完全禁用界面，所以它不是好的节流器，而是好的开关。账户级 0 加上选择性的用户级提高是控制谁有权访问的干净方式。

用户级覆盖账户级。“每日”低估了行为：窗口是滚动的 24 小时，一旦使用量衰减到限制以下，访问会自动恢复，因此没有人需要提交工单来解除阻塞。

因为 `0` 会直接禁用该功能，所以它不是一个好的限流器，而是一个好的开关。账户级别的 `0` 加上针对特定用户的按需提升，是控制谁有权访问的干净方法。

信用额度并不是访问控制的全部。用户需要同时具备合格的数据库角色（`SNOWFLAKE.CORTEX_USER` 或 `SNOWFLAKE.CORTEX_AGENT_USER`）和非零信用额度才能访问相应功能。缺少任何一个，都会看起来像是坏了。

什么真正驱动你的 Snowflake CoCo 账单

使用量按 token 计费，输入和输出都计费。CoCo 会在不被要求的情况下努力降低这个数字：它每轮只发送对话的新部分，预先加载最常用的工具，并按需发现其余工具，还将大型工具结果卸载到磁盘而不是你的上下文中。当你切换主题时，开始一个新的对话仍然有帮助，因为不再需要的上下文就不会继续携带。

CoCo 消耗的仓库和存储按标准费率单独计费。给 CoCo 一个专用的仓库，是让这部分支出从一开始就在计费和查询历史中可分离的最简单方法。

对于 token 支出，ACCOUNT_USAGE 中有三个按功能划分的视图：`CORTEX_CODE_CLI_USAGE_HISTORY`、`CORTEX_CODE_SNOWSIGHT_USAGE_HISTORY` 和 `CORTEX_CODE_DESKTOP_USAGE_HISTORY`。它们按模型细分了 token 和信用额度，足以让你用自己的数据回答为所有人固定使用 opus 是否值得。如果你不想写 SQL，还有一个捆绑的 /cost-intelligence 技能可选。