CoCo AI 成本优化指南：7 个关键方法 | 技术实践

Snowflake CoCo 可以将自然语言直接转化为实际工作流。它能够运行 SQL、执行多步流程，并在每一轮交互中调用大语言模型。尽管功能强大，但也带来了新的成本问题：Agentic 会话会根据处理的 tokens 消耗 credits，如果没有治理机制，成本很容易失控。

幸运的是，Snowflake 已经提供了一整套 AI 成本治理能力，这些能力可以通过 SQL、Snowsight 甚至直接在 CoCo 中进行管理。总体思路始终是三步：先了解成本花在哪里，再优化默认运行方式，最后在必要时设置强约束。

以下 7 个控制手段覆盖了从轻量监控到强制阻断的完整路径，并附上可直接使用的代码。

1、Usage history views：先知道成本花在哪

你无法治理自己看不见的东西。在设置任何限制之前，首先要明确成本基线。

CoCo 会将详细的使用遥测数据写入各个 surface 对应的 ACCOUNT_USAGE 视图：

SNOWFLAKE.ACCOUNT_USAGE.CORTEX_CODE_CLI_USAGE_HISTORY
SNOWFLAKE.ACCOUNT_USAGE.CORTEX_CODE_SNOWSIGHT_USAGE_HISTORY
SNOWFLAKE.ACCOUNT_USAGE.CORTEX_CODE_DESKTOP_USAGE_HISTORY

每一行代表一次请求，其中包含 TOKEN_CREDITS、总 TOKENS，以及在 TOKENS_GRANULAR 和 CREDITS_GRANULAR 中记录的按模型拆分的 input、output 和 cache tokens 明细。USER_ID、USER_TAGS 和 METADATA（例如角色名、推理区域）字段则提供了归因和分摊能力。

例如，下面这段查询可以统计过去 30 天里 CLI surface 上每个用户消耗的总 credits：

SELECT USER_ID,
SUM(TOKEN_CREDITS) AS TOTAL_CREDITS
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_CODE_CLI_USAGE_HISTORY
WHERE USAGE_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY USER_ID
ORDER BY TOTAL_CREDITS DESC;

这些视图最长保留 365 天的历史数据，并且会持续更新，因此既适合做实时 spot check，也适合做长期趋势分析。

2、/cost-intelligence skill：用自然语言询问成本

手写一次归因 SQL 还行，但如果每周都要重复一遍，就会变成纯体力劳动。

CoCo 内置了 /cost-intelligence skill，在 CLI、Desktop 和 Snowsight 三个 surface 上都可用。它专门用来回答 CoCo usage history 数据相关的问题，因此可以直接用自然语言提问，让 agent 帮助编写并执行 SQL。它也可以帮助创建和管理本文后面提到的 quotas 与成本控制。

使用方式很简单：在 CoCo 会话中输入 /cost-intelligence，或者直接描述问题，CoCo 会自动选择这个 skill。以下是几个常见起手式：

• "本月 CoCo CLI 中哪些模型产生的成本最高？"


• "按部门标签拆分 CoCo 支出"


• "为所有 AI 领域的用户创建配额，每月上限 500 积分"


• "为我的配额添加 75% 的通知阈值"

3、按 surface 设置每日 credit 限额：最快的单用户封顶方式

有时候并不需要一整套预算治理框架，只是希望限制任何单个用户每天在 CoCo 上最多能花费多少。

账户管理员可以通过三个 account-level 参数，为每个用户、每个 surface 设置 estimated daily credit limit：

• CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER：控制 CoCo CLI；


• CORTEX_CODE_DESKTOP_DAILY_EST_CREDIT_LIMIT_PER_USER：控制 CoCo Desktop；


• CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER：控制 Snowsight 中的 CoCo。

每个参数都会在滚动的 24 小时窗口内统计用户的预估使用量，一旦触达上限，就会阻断对应 surface 的访问，直到使用量重新回落到阈值以下。取值含义也很直接：

• -1（默认）：不设限制；


• 0：完全禁止访问；


• 正数：当 24 小时估算用量超过它时触发阻断。

可以先设一个账户级默认值，再对个别用户进行覆盖：

ALTER ACCOUNT SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;
ALTER ACCOUNT SET CORTEX_CODE_DESKTOP_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;
ALTER ACCOUNT SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 20;
- 给一个 power user 更高的 CLI 限制 (user-level 覆盖 account-level)
ALTER USER power_user SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 50;
- 完全禁止某个用户访问 Snowsight
ALTER USER restricted_user SET CORTEX_CODE_SNOWSIGHT_DAILY_EST_CREDIT_LIMIT_PER_USER = 0;

也可以反过来用：把账户参数统一设为 0，先默认封禁某个 surface，然后只给特定用户发放正数额度。

4、Per-user quotas：跨 AI domains 的强制阻断

前面这些按 surface 的参数很方便，但它们只能覆盖 CoCo。如果希望用一个统一的治理对象，同时覆盖 AI functions、Cortex Agents、Snowflake CoWork 和 CoCo，那么应该使用 per-user quotas。

Per-user quota 是 Snowflake 的一等对象，目前处于 public preview，所有账户都可以使用。它支持为每个用户设置 monthly limit 和可选的 daily limit，而且不同于 budgets，它可以在用户达到上限后自动阻止其继续发起新的 AI 请求，不需要额外写控制代码。

下面是一个典型配置流程：创建 quota、设置额度，并打开 block enforcement：

USE SCHEMA cost_mgmt_db.quota_schema;
CREATE SNOWFLAKE.CORE.QUOTA my_quota();
- 跟踪 CoCo domain (涵盖 CLI, Snowsight, 和 Desktop)
CALL my_quota!ADD_SHARED_RESOURCE('CORTEX CODE');
- 每个用户每月 500 credits
CALL my_quota!SET_PER_USER_LIMIT(500);
- 可选地添加每天 50 credits 的上限
CALL my_quota!SET_PER_USER_LIMIT(50, 'DAILY');
- 自动阻止达到限制的用户
CALL my_quota!SET_BLOCK_ENFORCEMENT_ENABLED(TRUE);

这里有几个值得记住的点：

• 额度周期按 UTC 自然月和自然日计算。月限额和日限额独立评估，到了新周期会自动解除阻断；


• Block enforcement 只覆盖 AI domains，也就是 AI functions、Cortex Agents、Snowflake CoWork 和 CoCo。一个 quota 只能跟踪 warehouse compute 或 AI domains 中的一类，不能同时覆盖两种计量体系；


• Enforcement 生效很快。支出超限通常会在几分钟内被识别，因此对交互式使用来说，超出的额度通常不会太多；


• Quota 还可以按 tags 定义作用范围，并用 UNION 或 INTERSECTION 逻辑组合选择用户。

此外，还可以给 quota 配置通知阈值、自定义 stored-procedure actions，或者直接在 Snowsight 的 Admin » Cost management » Budgets 中完成配置和管理。

5、Budgets：基于预测的提前预警

Quotas 是“硬刹车”，Budgets 是“提前报警”。两者不是替代关系，而是互补关系。

Budget 会把当月实际 credit 使用情况与设定上限对比，并基于时间序列预测判断是否可能超支。一旦预计会超过阈值，就会发出通知。它本质上是一个早期预警系统，默认只提醒，不会直接阻断消耗。

Snowflake 里有两类 budget：

• Account budget：监控整个账户层面的 credit 使用


• Custom budget：针对特定对象组或基于 tag 的范围，适合团队级或项目级可见性；如果聚焦 AI 支出，那么 AI_SERVICES service type 可以覆盖 Snowflake CoWork 和 Cortex Agent

通知可以发往邮箱列表、云消息队列（Amazon SNS、Azure Event Grid、Google Cloud Pub/Sub），或者通过 webhook 推送到 Slack、Microsoft Teams、PagerDuty。

不过这里有一个重要权衡：默认情况下，budget 的刷新间隔最长可达 6.5 小时。可以把它调成每小时刷新一次，形成 low-latency budget，以获得更密集的监控，但这会让 budget 自身的计算成本放大 12 倍。因此，只在确实需要更高刷新频率时才建议这样配置。如果需要的是“硬阻断”而不是“预警”，那就该用上一节提到的 quota。

6、Model access control：默认就把成本导向更合理的模型

并不是每一个请求都值得用上最强、也最贵的模型。控制用户究竟能调用哪些模型，往往是最具杠杆效应的成本治理手段之一。

在 Snowflake Cortex 里，目前有两套机制，只要其中任意一种允许访问，用户就能调用对应模型：

• Role-based access control (RBAC)：这是未来主推、粒度更细的方式。Snowflake 会在 SNOWFLAKE.MODELS schema 中维护模型对象，并提供与之匹配的 application roles，比如 SNOWFLAKE."CORTEX-MODEL-ROLE-ALL"。可以按角色只授予某些模型的访问权限。


• Account-level allowlist：也就是历史上的 CORTEX_MODELS_ALLOWLIST 参数，可配置为 All、None，或者一个以逗号分隔的小写模型名列表。

下面是使用 RBAC 给某个 role 授权访问指定模型的示例：

USE ROLE ACCOUNTADMIN;
- 确保模型对象是最新的
CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH();
- 授予一个 role 访问单个模型的权限
GRANT APPLICATION ROLE SNOWFLAKE."CORTEX-MODEL-ROLE-LLAMA3.1–70B" TO ROLE analyst_role;

需要特别注意的是：CORTEX_MODELS_ALLOWLIST 正在被弃用。从 2026 年 8 月开始，这个参数只能被改成 None；到 2026 年 11 月，它将被完全移除，模型访问控制将只剩 RBAC 一种方式。如果今天开始搭建模型治理，最好直接以 RBAC 为中心。若要完全切换到 RBAC，可这样设置：

ALTER ACCOUNT SET CORTEX_MODELS_ALLOWLIST = 'None';

在 CoCo 内部，聊天输入框里的 model picker 会始终展示当前用户可用的最新模型列表，并且它会自动反映所有访问控制设置。让用户在这里优先选择成本更合适的模型，就是日常使用层面的治理补充。

7、Automated guardrails：告警、任务与 runaway query 取消

如果特别关注 AI Functions 的支出，而这类支出又恰好容易在 agentic workflows 中出现，那么还可以基于 CORTEX_AI_FUNCTIONS_USAGE_HISTORY 视图，利用标准 Snowflake alerts 和 tasks 做出完全自动化的防护机制。

官方文档给出了三种可直接采用的模式：

• 账户级月度支出告警：每小时运行一次 alert，把当月累计 AI Function credits 与阈值比较，一旦超出，就通过 notification integration 给管理员发邮件，同时配合 state table 避免重复告警。


• 用户级月度支出限制：每小时运行一次 task，对超过月度 credit 预算的用户撤销专门的 AI Functions role；然后在下一个周期开始时，再用另一条月度 task 恢复访问。


• Runaway query 检测与取消：通过 task 按小时聚合每条 query 消耗的 credits，发现仍在运行且超阈值的 query 就自动取消，并把 query 详情邮件发给管理员。

其中，runaway query 模式的核心取消逻辑如下：

CREATE OR REPLACE TASK MONITOR_RUNAWAY_AI_QUERIES
WAREHOUSE = <your_warehouse>
SCHEDULE = 'USING CRON 0 * * * * UTC' - 每小时
AS
CALL MONITOR_AND_CANCEL_RUNAWAY_QUERIES(50); - credit 阈值
ALTER TASK MONITOR_RUNAWAY_AI_QUERIES RESUME;

这里必须明确一点：取消 query 只能阻止后续继续消耗成本，并不会退回已经消耗掉的 credits。而且 ACCOUNT_USAGE 视图本身也有最长 5 分钟的延迟。因此比较稳妥的做法，是先从监控开始，设定较为保守的初始阈值，然后再逐步收紧。

总结

这 7 个控制点可以组合成一套完整的 AI 成本治理策略，它们正好对应三个层面：可见性、优化和强制执行。

• See it：usage history views（1）与 /cost-intelligence skill（2）


• Shape it：model access control（6）


• Cap it：per-surface daily limits（3）、per-user quotas（4）、budgets（5）以及 automated guardrails（7）

一个比较务实的落地顺序是：先用 usage history 把成本基线跑出来，再把 model access controls 调整到合适状态，然后随着团队规模扩大，逐步叠加 daily limits、quotas 和 budgets。整个治理栈都可以通过 SQL、Snowsight 或直接在 CoCo 会话中管理，这意味着成本控制和真正产生成本的工作，本身就发生在同一个 surface 上。