我们是如何控制AI成本的

随着AI技术在组织中的广泛应用，成本控制已成为一个不容忽视的紧迫问题。与传统软件按许可证或席位计费的模式不同，AI服务采用令牌（token）计费，每次API调用都会产生新的成本，而且购买决策分散在每个开发者手中。这种模式与云计算中的FinOps（财务运营）非常相似，但粒度更细、速度更快。

一个典型的案例曾在行业内引起轰动：一家公司的员工AI授权没有设置使用限制，结果一个月内烧掉了近五亿美元。虽然这个极端案例规模罕见，但其背后的问题却具有普遍性。许多组织正在经历类似情况：月度账单从几百欧元悄然攀升至数千欧元，却无法追踪是哪个服务或用户导致了增长。熟悉云FinOps的人立刻就能识别出问题所在——成本失控并非源于单个昂贵的令牌，而是缺乏可见性和明确的边界。

FinOps的核心思想是将财务治理与运营透明度相结合，使业务部门、IT和财务能在共享数据基础上做出决策。同样的逻辑适用于AI，只是成本单位发生了变化。好消息是，现在已有开放标准来实现这种透明度。OpenTelemetry GenAI语义约定（Semantic Conventions）提供了一套统一的词汇表，用于以供应商中立的方式捕获AI消耗并将其归因到各个源头。

AI成本控制并非全新的问题，而是粒度更细、速度更快的FinOps。如果组织已经在云环境中建立了标签策略，那么只需将同样的思路迁移到新的成本单位上即可。在云FinOps中，我们通过标签（如成本中心、团队、环境）来归因资源；AI需要同样严谨的做法，只不过现在标签要附加到每次模型调用上——用户、团队、功能或工作流。没有调用时刻的归因，以后就无法从提供商的聚合账单中分解出成本，异常也无法解释，单个功能的商业价值更难以计算。

这里有三点重要类比：首先，最大的实际问题是覆盖率——云项目中总有大量资源未打标签而进入未分配桶，AI也是如此：是否每次调用都真的携带了身份标识？其次，杠杆都在源头执行：云中未打标签的资源违反策略，AI中未经归因的调用根本不被放行。第三，当同一套分类体系贯穿两个世界时，就能首次回答“一个功能的总成本是多少”——包括基础设施和AI。这正是FinOps开放成本与使用规范（FOCUS）所追求的共同点。

实现AI成本控制的五个杠杆是：第一，通过令牌归因实现透明度，即将每次模型调用分配给用户、团队和功能；第二，部署AI代理作为所有AI流量的中央控制点；第三，设置明确的限制和护栏，防止成本失控；第四，通过正确的模型选择、精简调用和缓存实现持续优化；第五，赋能团队，让他们理解并承担自己的成本。

在实践层面，每个模型调用都可以包装成一个跨度（span），携带标准化的字段和自定义归因属性。例如，使用OpenTelemetry的Python SDK创建一个聊天跨度，设置gen_ai.operation.name、gen_ai.provider.name、gen_ai.request.model等标准属性，以及enduser.id、team.name、feature.name等业务属性，并在调用后记录输入输出令牌数。这些信息足以进行成本分解，且从数据保护角度看，纯成本监控无需存储提示内容，元数据就足够了。

最具实践性的架构是AI代理（或AI网关），作为所有AI流量的中央通道。应用程序和工具（开发环境、聊天界面、Agent管道等）使用虚拟密钥而非真实提供商密钥，每次调用自动获得归因。代理捕获消耗、模型、成本和延迟，执行限制，可将简单任务路由到更小的模型，并按开放标准将遥测数据导出到分析系统。这样，透明度不再是月末的后期分析，而是每次调用的组成部分。同时，这个途径还能将之前不受控的直接使用（影子AI）纳入治理。

设置限制和护ba欄是防止成本爆炸的关键。实践中存在清晰的成熟度模式：团队先引入请求数量限制，第一次账单惊吓后添加令牌消耗限制，第二次后添加每个周期和团队的硬预算限制。这些限制在多个层面协同工作——请求数限制保护基础设施，令牌限制控制实际消耗，预算限制防止批量处理或Agent循环导致的意外高峰。在网关中，可以为每个虚拟密钥声明这些限制，例如每分钟最多120个请求、20万个令牌，月度软预算5000欧元（触发警报）、硬预算6000欧元（拒绝调用），以及成本速率断路器（每分钟超过20欧元则停止失控Agent）。

最终，AI成本控制需要组织从被动应对转向主动管理。通过可见性、中央控制、合理限制、持续优化和团队赋能，AI的消费可以被有效治理，让组织在享受AI带来的价值的同时，避免财务风险。