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

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

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_HISTORYSNOWFLAKE.ACCOUNT_USAGE.CORTEX_CODE_SNOWSIGHT_USAGE_HISTORYSNOWFLAKE.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_CREDITSFROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_CODE_CLI_USAGE_HISTORYWHERE USAGE_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())GROUP BY USER_IDORDER 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;- Give a power user a higher CLI limit (user-level overrides account-level)ALTER USER power_user SET CORTEX_CODE_CLI_DAILY_EST_CREDIT_LIMIT_PER_USER = 50;- Block one user from Snowsight entirelyALTER 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();- Track the CoCo domain (covers CLI, Snowsight, and Desktop)CALL my_quota!ADD_SHARED_RESOURCE('CORTEX CODE');- 500 credits per user per monthCALL my_quota!SET_PER_USER_LIMIT(500);- Optionally add a 50-credit-per-day ceilingCALL my_quota!SET_PER_USER_LIMIT(50, 'DAILY');- Automatically block users who reach the limitCALL 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;- Ensure the model objects are currentCALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH();- Grant one role access to a single modelGRANT 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 会始终展示当前用户可用的最新模型列表，并且它会自动反映所有访问控制设置。让用户在这里优先选择成本更合适的模型，就是日常使用层面的治理补充。

1. 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_QUERIESWAREHOUSE = <your_warehouse>SCHEDULE = 'USING CRON 0 * * * * UTC' - Every hourASCALL MONITOR_AND_CANCEL_RUNAWAY_QUERIES(50); - credit thresholdALTER 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 上。

原文地址：https://medium.com/snowflake/7-ways-to-control-your-snowflake-coco-ai-spend-91fe829fce82

点击链接立即报名注册：Ascent-Snowflake Platform Training-China更多 Snowflake 精彩活动请关注专区