Pratyusha Duvvuri：让工程和财务都能理解 AI Token 支出

Pratyusha Duvvuri 问观众 tokenomics 是什么意思，并预测答案各不相同。她的团队与约 100 家公司交流，听到的需求从了解 token 成本到按团队完整计算投资回报不等。

Duvvuri 介绍自己在 Galileo 负责智能体可观测性、分布式追踪和 tokenomics 的工作；Galileo 后来通过收购成为 Cisco 的一部分。她说自己提出的是工作定义，而非唯一公认的含义。

她描述了一种变化：行业不再只是为高 token 消耗而自豪，也开始关注效率。随着 AI 工具普及，管理者越来越希望了解支出是否产生了有用结果。

模型选择体现了这种权衡。在一个内部场景中，较便宜的模型在团队评测中得到 96%，更强模型得到 99%；Duvvuri 说，由于前者的质量已经足够，团队选择保留较便宜的模型。

面对客户的任务则可能不同：为了更好的质量，她可能愿意承担更高成本。决策取决于评测、错误的后果和交付价值，而不只是 token 单价。

服务商定价增加了复杂性。Duvvuri 说，企业协议可能因客户、积分价格和用量门槛而异，因此公开标价并不总能解释某家公司的实际支出。

她的团队将产品用户分为工程师、工程经理和财务人员。即使查看相同的底层用量，这三个群体也需要不同视图。

工程师可能想知道使用了哪些模型和技能，以及是否超出月度预算。眼前的问题是如何调整具体工作流或模型选择。

工程经理可能比较各团队的采用情况、成果和成本。支出更高的团队可能产出更好，而成本较低的团队可能没有达到目标；用量数字需要结合业务背景。

财务团队需要预算、提醒、支出归属，以及对投资回报有依据的解释。Duvvuri 将变化的 token 账单比作乘出租车时不知道最终车费。

她认为，按服务商分开的仪表盘迫使用户在多个平台间切换，也可能无法照顾所有三类用户，尤其是在财务需要整合不同协议时。

对账使数据不像仪表盘看起来那样固定。服务商可能修订此前报告的费用，因此统一系统需要更新数据，并解释早期估算与后续账单之间的差异。

财务归属也可能不同于普通管理层级。公司分配运营费用和销售成本的方式，不一定与人员系统中的汇报关系一致。

Duvvuri 将 tokenomics 定义为 token 用量与成本的可观测性和可解释性。在她看来，可解释还包括理解模型选择、归类使用场景，以及将支出与投资回报联系起来。

为了填充产品数据，她的团队需要人员层级、服务商 API 凭据和组织标识，以及财务层级。系统利用服务商数据，约每天刷新一次用量视图。

客户可能对共享人员数据比较敏感。Duvvuri 说，团队接受只包含姓名、ID、岗位职能等有限字段的 CSV，不要求提供人力资源系统中的所有细节。

演示中，具体数值经过模糊处理。管理者视图提供日期筛选、财务日历、成本和采用率仪表盘，以及团队是否使用 AI 工具和支出如何变化的趋势。

她说，预测是管理者和财务常见的需求：他们想知道预算是否会在一周或一个月内耗尽。演示包含一个预测用量视图，但不确定性相当大。

组织树将个人支出向上汇总到经理和高管。用户可以沿层级向下查看团队和个人用量，而不必只看全公司的总数。

产品还可以按岗位类别分组，让管理者比较销售、产品和工程团队的消耗。其他筛选条件包括模型、推理设置、个人和岗位职能。

财务视图采用不同的部门和成本类别层级。Duvvuri 说，每个人的成本都会汇入一个财务节点，基于角色的访问规则则限制查看者可以查看哪些团队。

她说，团队在十周内从最初客户访谈推进到正式发布。客户希望获得预测能力，也希望将 token 支出与迁移、产品发布或获得客户等业务结果联系起来。

一个挑战是在市场和客户需求不断变化时设计可扩展产品。新的需求可能迫使团队修改已经服务大量用户的数据模型。

另一个挑战是让界面对需求截然不同的三类用户都足够简单。第三个挑战是对账：服务商首次报告后的数据可能变化，产品必须反映这些修订。

人员和汇报关系也会随时间变化，因此历史成本应该归给谁并不容易判断。Duvvuri 最后邀请观众重新思考 tokenomics 对自己组织的意义。