令牌与云支出之间缺失的度量指标

问题不在于 AI 团队缺乏成本数据，而在于令牌仪表板和云账单描述的是不同的系统，归属不同的团队，且没有可靠的方式将它们关联起来。

一名支持客服可能在完成一次工单前经历五次模型调用、一次检索步骤、两次工具调用以及一次重试。业务层记录的是一个已完成的案例，而基础设施层记录的是一堆请求、Pod、内存、加速器时间以及共享服务。只有当这些记录对齐时，成本优化才不至于仅凭猜测。

为什么令牌指标和云账单会讲述不同的故事？

令牌计数很有用。它们显示模型接收和返回的文本量，并帮助团队比较提示词、模型或路由选择。但它们并不能告诉你模型调用前后的情况、支持检索和工具使用的计算量、先前出现了多少次失败尝试，或最终结果是否真正有价值。

State of FinOps 2026展示了 AI 迅速渗透到常规 FinOps 工作中的速度：98% 的受访者如今管理 AI 支出，而 2025 年为 63%。但更大的预算项仍无法告诉你是哪条工作流消耗了资金以及原因。

两个文档处理任务可能使用大致相同的令牌数量。一个可能只需一次模型请求即可完成；另一个则可能从多个存储检索上下文、调用外部服务、回退到另一模型，并在一次用户看不到的验证失败后重新运行文档。令牌总数看似相近，但执行路径却大相径庭。

Unite.ai 已经探讨了为何令牌计数并不自动等同于业务价值。下一步是将这些计数与产生它们的工作负载关联起来。否则，团队可能在降低每令牌成本的同时，使每完成任务的成本变得更高。

完整的成本链是什么样的？

一个有用的成本链应从业务关注的结果出发。可能是已解决的支持案例、已处理的文档、已接受的代码更改，或已完成的代理工作流。其下的所有环节都需要一个能够在系统中追踪的标识。

应用层提供了首个关联点。请求 ID、追踪 ID、工作流名称或会话 ID 可以将多个模型和工具操作绑定到同一工作项上。若缺少此线索，十个相关事件看起来就像十笔无关的费用。

OpenTelemetry 为 GenAI 代理制定的约定为该层提供了新兴的词汇体系。它们涵盖操作、提供者、请求的模型、代理、会话、令牌使用、工具执行、错误以及工作流。这些约定仍标记为开发中，团队不应将其视为已完成的通用标准。它们之所以有用，是因为它们使关联问题具体化。

接下来是基础设施。AWS 为 EKS 提供的分摊成本分配数据可以将共享的计算和内存费用分配到 Kubernetes Pod，并展示集群、命名空间、部署、节点、工作负载名称和工作负载类型等细节。对于支持的加速实例，数据还涵盖 GPU、Trainium 和 Inferentia 的预留情况。

这就是链条的另一半。追踪可以说明应用尝试了什么；Kubernetes 的分配则可以展示哪些资源承担了工作。Unite.ai 关于在 Kubernetes 上部署和监控大语言模型的指南提供了更广泛的生产环境上下文，包括资源分配、扩展以及可观测性。

这种关联不会凭空发生。团队需要一个足够持久的标识符，以便将应用遥测与工作负载标签、分配记录或其他映射层关联起来。客户数据不应写入 Kubernetes 标签。团队应决定哪些低基数标识符能够安全地将工作流类别、服务或功能与其消耗的资源相连接。

一旦应用上下文就位，团队就可以开始按工作负载跟踪 Kubernetes 成本，并将命名空间、CPU、内存和 GPU 使用情况关联回实际工作。虽然这仍无法判断工作流是否创造了业务价值，但它为计算的基础设施层面提供了可供挂钩的具体数据。

企业应信赖哪种单元度量？

没有一种 AI 成本度量可以适用于所有团队。每令牌成本回答的是模型消耗层面的疑问；每 Pod 成本回答的是基础设施分配层面的疑问。两者都无法告诉产品负责人该功能是否值得保留。

最合适的分母通常是业务能够明确定义且产品团队能够影响的最小成果。支持业务可能会跟踪每解决案例的成本；文档系统可能使用每成功处理文件的成本；而代码助手则可以考察每接受更改的成本，而非每建议的成本。

成功会改变计算方式。

即使每次尝试成本低的工作流，如果经常失败、触发重复验证或将过多案例送交人工审查，整体成本仍可能很高。这就是为什么团队应将尝试成本与完成成本分离，并在可能的情况下使用每接受结果的成本。后者往往最有价值，因为它包含了系统产出但业务未能使用的工作。

代理系统使情况更为复杂，因为其路径可能在不同运行间变化。Unite.ai 对扩展代理式 AI 工作负载的经济性分析涵盖了路由、工具调用、重试以及工作流层面的归因。当这些行为消耗资源时，即使最终用户仅看到一个答案，也应计入单元度量。

该度量仍不可能完美。共享服务、缓存结果、批处理任务以及延迟处理都会模糊归因。一个对决策有用的估计胜过虚假的精确，尤其是当它能指示工程师应关注哪一层时。

谁拥有这个数字？

最难的部分可能是组织层面。机器学习团队了解模型调用和评估；平台团队了解工作负载和集群行为；FinOps 团队了解计费数据和分配规则；产品团队知道哪种结果最重要。

没有任何单一团队拥有完整的链条。

这会导致围绕哪个仪表板更准确的可预见争论。机器学习团队可能指出令牌使用下降，平台团队则看到 GPU 小时上升，产品团队则发现完成任务数量减少。这三种观察可以同时成立。共享度量必须解释它们之间的关系。

一个可行的起点是选取一个具有明确完成事件的生产工作流。为其赋予一个稳定的标识符。将该上下文贯穿模型和工具的追踪，映射到 Kubernetes 中运行的服务或工作负载，并选择一个业务分母。当该数字出现异常波动时，再将各团队聚集起来。

这种审查比精美的仪表板更为重要。突增可能源于更长的提示词、新的回退路径、GPU 资源未充分利用、自动伸缩策略的变更，或是产品决策导致更多工作流经 AI 功能。每一种原因都归属于不同的负责人。

自动化应在后期引入。推荐引擎只能依据收到的标签和阈值进行操作，若分母选择不当，可能让高效系统看起来浪费，或奖励用户拒绝的低成本工作流。团队需要足够的共享可视性，以在系统依据结果采取行动前区分模型行为、应用设计和基础设施分配。否则，自动化的成本修正可能削减容量、提升延迟，并将费用转移到更不显眼的地方。

成本链必须共享

只要每个团队仅优化自己可见的层面，AI 成本控制就会保持碎片化。令牌、追踪、Pod、加速器和发票并非相互竞争的度量，而是同一成本链的不同环节。

将它们关联起来的公司在第一天不可能得到完美的数字。关键在于团队能否将高额账单追溯到导致它的工作流，弄清楚变化原因，并判断结果是否值得这笔费用。