为什么 Snowflake AI 需要新的 FinOps 策略？ | 技术趋势

随着 Snowflake 逐步发展为 AI 驱动的生态系统，Cortex AI 重新定义了成本治理，引入了基于 Token 的经济模式。这种模式重塑了企业如何衡量、优化工作负载的方式。传统的 FinOps 模型聚焦于调整数据仓库规模和查询优化，已不再符合当前基于 Token 的经济模式及 AI 驱动型工作负载的实际需求。

如今，FinOps 必须超越计算优化的范畴，将 AI 成本可见性、Token 追踪和模型治理纳入其中。借助 Cortex AI，其使用场景涵盖推理、微调和嵌入。在这些场景中，token 而非 credit，成为了新的价值货币。

随着底层 AI 模型的规模和复杂性持续扩大，这种转变的重要性愈发凸显。

模型正在呈指数级增长

AI 模型的增长正在以一种根本性重塑成本动态的规模加速。每一代新模型的参数数量都会成倍增加，导致计算强度、储存需求和 Token 使用量急剧上升。在短短几年内，模型规模已从数百万参数激增至数万亿参数。

随着模型规模呈指数级增长，其运营成本也随之同步增长。对于 Snowflake AI 工作负载而言，这种增长要求 FinOps 思维模式同时追踪 token 和 credit 的使用情况，以确保在模型复杂性和规模持续扩大的过程中，创新活动在经济层面仍具备可持续性。

为 AI 工作负载打造新一代 FinOps 模型

为了将这一愿景付诸实践，企业必须重新思考其 FinOps 基础，并建立针对 AI 工作负载量身定做的全新实践方法。而这一过程首先要理解，在 Cortex AI 时代，成本结构、指标和优化杠杆发生了怎样的演变。

构建一个具备 AI 意识的 FinOps 框架，第一步是理解 Snowflake 成本模型的根本性转变。

理解转变

要构建一个具备 AI 意识的 FinOps 框架，首先需要理解 Snowflake 的成本模型是如何演变的。从传统的基于计算的计费，向 AI 驱动的、基于 Token 的消耗模式转变，这个过程引入了新的变量，这些变量从根本上改变了成本的预测和优化方式。

传统 Snowflake 计费模式

Snowflake 的成本结构过去简单明了，基于仓库规模、运行时间和 credit 费率。FinOps 团队可以通过调整仓库大小或优化查询来轻松预测和控制开销。这种成本模型具有可预测性，并且计算资源的使用能够直接与业务需求相匹配。

SET dollar_cost_per_credit = 4;
SELECT     TO_DATE(start_time) AS usage_date,    warehouse_name,    SUM(credits_used) AS total_credits_used,    $dollar_cost_per_credit AS dollar_cost_per_credit,    dollar_cost_per_credit * total_credits_used AS total_costFROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORYWHERE start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP())GROUP BY ALLORDER BY usage_date DESC, warehouse_name;

这个模型是可控制、可观察、且可预测的。平台团队和工程师可以调节性能、监控使用情况，并将计算消耗与业务需求保持一致。

向基于 Token 的经济模式转变

Cortex AI 工作负载现在引入了一种新的经济层，以 Token 为中心，Token 表示在模型执行例如推理、微调或嵌入生成期间处理的文本单元的数量。

与根据计算时间线性增长的仓库 Credit 不同，token 消耗会根据输入提示、模型复杂度以及输出内容冗长程度而变化，这使得 AI 成本变得不那么可预测，并更加多维化。

为了量化这一点，FinOps 团队可以通过将 token 使用量与支持性计算资源相结合，来计算 AI 执行的总成本：

SELECT  (input_tokens + output_tokens) * ai_model  + serving_compute  + embedding_compute  + warehouse_compute AS cortex_costFROM cortex_usage_summary;

注意：不同的 AI 模型每 100 万 tokens 的 credit 费率上是不同的，其费率由模型质量与规模决定。

请参阅 Credit 消耗表以了解 Snowflake 支持的不同模型在每百万 token 上的具体 credit 消耗情况。

优化 AI 工作负载

即使是小型的人工智能任务，也可能产生巨大且意想不到的成本。某电商分析团队在使用 Snowflake Cortex AI 对客户评论进行总结时，就亲身经历了这一点。这个任务起初看起来简单且成本较低，然而由于使用了大型模型、评论文本较长，以及输出内容过于详细，它在不知不觉中消耗了远超预期的 credit。

ALTER SESSION SET QUERY_TAG = 'Customer Review - mistral-large';
SELECT    ASIN, USER_ID,    SNOWFLAKE.CORTEX.COMPLETE (        'mistral-large',        CONCAT(            'Summarize customer sentiment for the Amazon product',            'Provide:\n',            '- Overall Sentiment (Positive, Negative, or Mixed)\n',            '- Customer mood and tone in fewer words\n\n',            'ASIN: ', ASIN, '\n',            'Customer Reviews:\n', BODY        )    ) AS SENTIMENT_SUMMARYFROM demo_schema.AZ_REVIEWS_32K;

Overall Sentiment: PositiveCustomer mood and tone: Enthusiastic and secure

但执行结束后的指标如下：

· 处理记录数：约 32,000 条评论；

· 总 token 数（输入 + 输出）：4.4 百万；

· 使用模型： mistral-large；

· Token 成本： 约等于 22.47 credits。

为了解决这个问题，团队实施了几项优化措施：

· 预先筛选冗长的评论，以减少不必要的输入量；

· 限制模型输出长度，避免“长篇大论”；

· 对于只是提取情感倾向这样的“轻任务”，改用性价比更高的模型。

ALTER SESSION SET QUERY_TAG = 'Customer Review - mistral-7b (limit input and output)';
SELECT    ASIN, USER_ID,    SNOWFLAKE.CORTEX.COMPLETE (        'mistral-7b',        CONCAT(            'Summarize customer sentiment for the Amazon product',            'Provide:\n',            '- Overall Sentiment (Positive, Negative, or Mixed)\n',            '- Customer mood and tone in 10 or fewer words\n\n',            'ASIN: ', ASIN, '\n',            'Customer Reviews:\n', SUBSTR(BODY,1,500)        )    ) AS SENTIMENT_SUMMARYFROM demo_schema.AZ_REVIEWS_32K;

Overall Sentiment: PositiveCustomer mood and tone: Delighted with easy installation, peace of mind, and useful notifications.

通过使用更小的模型，并将评论文本限制在 500 个字符以内、输出内容限制为不超过 10 个词，最后一次运行 [Customer Review — mistral-7b (limit input and output)] 显著减少了 token 的使用量。同时，它在整个过程中仍保持了模型的准确性。

关键要点： AI 工作负载在 SQL 中看起来往往很轻量，但 token 的使用规模会随着输入长度和模型复杂度呈指数级增长。

并非所有模型都是相同的。某些模型比其他模型更适合特定任务。因此，请务必做好研究，为你的特定使用场景选择合适的模型。

使用高质量数据进行训练和微调

生成式 AI 模型的效率取决于其学习的数据质量。低质量的数据不仅会降低模型的准确性，还会通过低效的训练循环、过多的 token 消耗以及不必要的微调操作，悄然放大 AI 成本。

在花费第一个 token 之前，你的 AI 成本就已经在数据层开始产生了。

对于使用 Cortex AI 的团队来说，实现 FinOps 成功的基础在于采用受到治理、高质量、且统一的数据集。干净、经过验证的数据可以缩短反馈周期、减少重新训练的频率，并确保每一个 token 都能产生可度量的价值。

在 AI FinOps 中，数据准备就绪就是成本准备就绪。每一个不干净的数据集都会成为一项隐形的开支，最终在你的模型运行中体现出来。

构建 AI 成本可观测性

随着 Snowflake Cortex AI 引入诸如 token 与模型推理等新的成本驱动因素，FinOps 团队需要能够了解 AI 工作负载具体如何消耗资源。仅仅跟踪数据仓库 Credit 消耗的传统报表已经不再足够。现在的可观测性需要包括 token 使用量、模型调用活动以及用户级消耗。

为支持这一转变，Snowflake 现通过 ACCOUNT_USAGE 视图开放 AI 使用遥测数据：

例如，以下查询可帮助关联模型使用量、token 消耗和仓库计算资源，从而定位成本集中点：

SELECT    c.query_id,    c.function_name,    c.model_name,    c.tokens,    c.token_credits,    q.warehouse_name,    q.user_name,    q.query_tag,    q.query_text,    q.start_time,    q.end_timeFROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_FUNCTIONS_QUERY_USAGE_HISTORY cJOIN SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY qON    c.query_id = q.query_idWHERE q.start_time >= DATEADD('DAY', -7, CURRENT_TIMESTAMP())ORDER BY c.token_credits DESC;

以下查询汇总了 AI 服务 Credit 使用情况，并突出显示了 Cortex AI 工作负载中的成本集中点：

SELECT     start_time::TIMESTAMP AS hour_start_time,    SUM(credits_used) AS total_credits_used,    service_typeFROM snowflake.account_usage.metering_historyWHERE service_type='AI_SERVICES'GROUP BY ALLORDER BY total_credits_used DESC;

将这些洞察整合到定期的 FinOps 报告中后，团队就可以重新建立起以往对于计算仓库的可观测性，并将其应用到 AI 工作负载领域。

管理间接 AI 成本

在使用 Cortex Search 的过程中，我们发现大多数关注点通常集中在如何提供快速、准确且具备上下文理解的搜索结果。然而，我们注意到，间接成本更多来源于持续索引、元数据刷新，以及即使在空闲状态下仍保持运行的后台服务。

这些隐藏成本往往随着数据规模、模型复杂度和服务可用性而扩大，而不直接与用户活动量挂钩。如果缺乏有效的管理手段，它们会在不被注意的情况下不断累积，降低 AI 工作负载的成本效率。

建议关注以下关键策略：

· 优化索引效率，通过最小化仓库规模、批量更新、并仅在有真实业务需求时安排刷新来降低成本；

· 管理服务生命周期，对空闲或开发环境服务进行暂停，以避免不必要的运行成本。

索引是 Cortex Search 中资源消耗最密集的操作之一。为了提高索引效率并降低成本，我们采取了以下做法：

• 合并增量更新，而不是执行完整的重新索引；

• 将索引调度与实际业务刷新需求对齐；

• 在对数据实时性要求不高的情况下，暂停索引操作。

--Suspend IndexingALTER SEARCH SERVICE my_cortex_search_service SUSPEND;
--Resume Indexing when requiredALTER SEARCH SERVICE my_cortex_search_service RESUME;

这些实践执行确保了 AI 搜索既高效又具有成本效益，实现了业务运营需求与财务责任之间的平衡。

为 GenAI 构建 FinOps 文化

为了管理这一新的经济层面，我们必须将 FinOps 从计算优化发展到具备 AI 意识的成本治理。Cortex AI 引入了全新的消费维度，需要更深层次的协作、更高可见性和更主动的优化。

理解人工智能的真实成本（TCAI）

不再仅仅追踪计算 Credit，而是要衡量认知总成本，即 Token、推理、编排和服务计算的综合影响。通过在人工智能生命周期的每个阶段都建立透明度，将成本与业务成果联系起来。

嵌入跨团队问责机制

在工程、财务和产品团队之间建立共享的 FinOps 职责模型。通过共享仪表盘、配额和成本审查，确保在 AI 运营的每一个层面都具有可见性和责任归属。

控制使用量并检测异常情况

实施速率限制、预算警报和异常检测机制，以防止 token 或 credit 消耗失控。持续监控有助于尽早识别高成本 prompt 或低效模型。

基准测试并持续迭代

跟踪诸如每次推理成本、token 使用效率和从投入到产生价值的周期等指标，用于为 AI 支出制定基准并推动持续优化。

结语与洞察

Snowflake Cortex AI 已重新定义了 FinOps，将其从成本控制扩展到智能价值管理。这份新的 FinOps 策略以 AI token 经济学、成本可观测性以及团队间的共享问责为核心。

通过将财务洞察与技术执行相结合，并使财务、工程和数据团队保持一致，我们可以将 token 智能转化为可衡量且可持续的业务优势。

原文地址：https://medium.com/snowflake/why-snowflake-ai-demands-new-finops-playbook-df380d77fb84

点击链接立即报名注册：Ascent - Snowflake Platform Training - China