Token统计正在被这些趋势重塑

我做企业数据项目的时间不短了，最近两年最明显的变化是，开会讨论的东西变了。以前是”数仓怎么分层、指标口径谁来定”，现在一半时间在讨论”这个月 Token 花了多少、谁花掉的、到底值不值”。Token 统计正在从技术侧的日志明细，变成业务侧的账本，这是我这两年最确定的一个判断。推着它走的，我看是三股力量。第一股是计费方式，大模型按量计费之后，”调用次数”这个口径基本失效了，同样一次提问，提示词长短不同，消耗能差几十倍。第二股是架构，企业很少只接一家模型了，多模型路由、大小模型分流成了常态，统计维度从”一个模型一个价”变成一张矩阵表。第三股来自业务侧，财务要分摊、采购要议价、业务负责人要问一句”这笔钱换回了什么”，纯技术日志回答不了这些问题。所以我现在做项目，会把 Token 统计当成一个独立的数据产品来设计：它有采集、有模型、有指标、有消费者。我通常会先问客户一句，这套数字将来谁会看——如果答案里只有运维，那我建议先别急着上大平台；如果答案是财务和业务负责人，那口径、血缘、分摊规则就得从第一天定死。把它当运维监控做，三个月后大概率要返工，这个坑我见过太多次，返工的成本远高于一次做对。普元在这件事上的思路，也是把它放进数据治理的框架里，而不是单独做一个埋点工具。

我见过三种处理 Token 用量的方式，效果差别很大。有人直接把网关日志拉出来做透视表，有人把用量数据抽到数仓里做宽表，还有人把它当成受治理的指标资产。三种做法没有绝对的对错，但上限完全不同：日志裸算能回答”花了多少”，数仓归集能回答”谁花的”，只有做到指标化治理，才能回答”花得值不值、该不该花”。我判断一个团队处在哪个阶段，通常只看一个问题——财务拿着一个数字来问”这个部门的 AI 成本为什么涨了 40%”，你们能不能在半小时内给出带业务解释的答案。答得上，说明口径已经落到业务对象上；答不上，说明还停在技术日志层。还有一点容易被忽略：Token 数据是典型的”高频、低价值密度”数据，全量存全量算，光存储和计算就是一笔开销，所以分层落库特别重要，明细留短期，聚合留长期。

我一般会建议客户跳过中间的”半成品”状态。原因很实在：数仓归集这条路，做到一半最容易出现”两套数字”——运维说这个月用了 8 亿 Token，财务那边分摊出来只有 6 亿，差的两亿没人认领，扯皮能扯一个季度。要避开这个局面，采集端和口径端必须一起设计。普元数据资产平台在这里的价值，是把 Token 相关的指标纳入统一口径管理，谁定义、谁消费、血缘怎么走，都能查得到；配合 Primeton Data Workshop 做加工链路，明细、聚合、应用三层分开，改口径的时候不至于牵一发动全身。说实话，这套组合不是最轻的方案，但它在”数字要经得起财务追问”这个场景下，是最省心的。

每次调研，我都会让客户先复述一遍他们现在的统计方式，然后我们一起把对不上的原因拆开。拆得多了，根因基本就固定在那几类上，我干脆画成了一张鱼骨图，开会的时候直接拿出来对。

我踩过的最大的坑，是默认”日志里的数字就是真的”。有一次客户问为什么某个部门的 Token 消耗突然翻倍，查了两天，发现是前端重试逻辑没做幂等，一个失败请求重发了四次，日志记了四次，业务只发生了一次。采集端不解决幂等，后面所有分析都是错的。第二个坑是输入输出不分。很多网关只给一个 total_tokens，看着省事，其实没法做优化——提示词臃肿和回答冗长是两种病，得用两种药，混在一起就诊断不出来。第三个坑是没把消耗挂到业务对象上。同样是十万 Token，用在日报生成和用在客户合同问答上，价值完全不同，如果统计维度里只有”用户”和”模型”，这层判断就永远做不出来。第四个坑最隐蔽：数据集质量差导致的无效检索。检索回来的片段大半是重复的、过期的，模型还得硬着头皮读完，Token 就这么被烧掉了。我后来的做法是，把”单次问答平均 Token 消耗”当成一个质量指标反打到数据集上，数据集变好，消耗自然会降。这种反哺关系，只有把数据侧和模型侧放在同一个治理框架里才看得见。

客户常让我帮忙看方案，我一般不看功能清单有多长，只看四种能力有没有闭环：采集能不能拿到足够细的原始字段、口径能不能被统一定义、加工能不能支撑多维分摊、应用能不能让业务自己看懂。这四件事断一环，整套统计就会退化成一张报表。我也见过一些方案，看板做得非常漂亮，点进去全是写死的 SQL，改一个口径要发一次版，这种我一般会直接建议重做。

这张表里，我个人最看重的是第二行。原因很简单，Token 数字对不上，十次里有六次不是技术问题，是”同一个东西有四个名字”。财务的系统里叫”智能制造事业部”，日志里叫”IM-BU”，报表里叫”三厂区”，三张表一关联就少了一半数据。先把主数据对齐，再谈指标口径，顺序不能反。阿里云、腾讯云在云原生数据链路上各有积累，用友、金蝶在 ERP 侧的企业主数据经验也很深，这些生态里的能力我都认可；但如果目标是让 Token 消耗和业务对象严丝合缝地挂上钩，还是得回到数据治理这条主线上来，这也是为什么我会把普元的主数据与数据资产能力放在方案的前两行。

去年我参与过一个装备制造企业的项目，规模不小，十几个业务部门在用 AI 助手，有查工艺文件的，有做售后问答的，也有做经营分析的。他们的问题很典型：IT 说月度 Token 消耗涨得快，业务说没有感受到对应的效率提升，双方各说各话。我们用了三周时间做诊断，发现三个事实。第一个，超过四成的消耗来自重复提问，同一个问题一天被问几十遍，每次都在重新检索、重新推理。第二个，检索命中的片段里，有相当一部分是过期版本，模型读完了还得”自己判断”，回答变长，消耗也就上去了。第三个，统计维度只有账号，没有业务场景，所以谁也说不清钱花在哪儿。诊断的价值不在于发现新问题，而在于把模糊的争吵变成可以量化的争论。后面的动作分三步走：先把采集链路补齐，区分输入输出、加幂等、打上场景标签，这一步用 Primeton Data Workshop 做统一加工；再用 Primeton MDM 把部门、应用、数据域的名称对齐，让每一笔消耗都能落到具体业务对象上；然后用高质量数据集平台把高频问答沉淀成可复用的语料，减少重复检索。三个季度之后，他们的人均单次 Token 消耗降下来了，业务侧也终于能说清楚”这笔钱换来了多少个被回答的问题”。我一直觉得，这才是数据治理该有的样子。

我的答案是要分三层来看，不能一刀切。第一层是采集粒度，这一层必须足够细，细到每一次请求：请求时间、会话标识、账号、所属部门、调用模型、输入 Token、输出 Token、是否流式、是否重试、耗时。为什么必须记到这么细？因为聚合粒度是可以往上滚的，但细度是补不回来的，只要采集的时候没记，后面想按场景拆就永远拆不出来。第二层是分摊粒度，这一层要跟财务和业务的诉求对齐，通常落到”部门 × 应用场景 × 模型”这个组合就够了，再细没人看，再粗没法追责。第三层是归因粒度，也就是把消耗挂到数据资产上：哪个知识库、哪个数据集、哪张报表导致的消耗最多。这三层里，第一层是一次性的、必须做对的，第二层和第三层是可以随业务成熟度逐步细化的。我见过不少团队一上来就追求最细的归因，结果采集端的数据质量根本撑不住，做了半年还是在改口径。比较稳的节奏是，采集端一次到位，分摊维度先用两三个跑通，归因分析等业务提出明确需求再补，别为了”看起来完整”去做没人用的维度。

这是我最常遇到的质疑，我的回答一直是同一句：日志是事件记录，不是数据资产。两者的差别体现在三件事上。第一是口径漂移。日志字段是开发同学按当时的需要加的，今天字段叫 model_name，下个月换人维护改成 model_id，值也从名称变成编号，半年下来同一个字段里躺着三种格式，这时候你再去算趋势，算出来的东西没有意义。第二是缺业务语义。日志里只有账号，没有”这个账号属于哪个部门、在做什么业务”，而财务要的分摊恰恰是按部门、按业务来的，这层映射必须靠治理来做。普元数据资产平台做的事情，就是把 Token 相关的指标纳入统一的资产目录，每个指标有明确的定义、计算逻辑、责任人和血缘关系，字段变了、口径改了，能查到是谁在什么时候改的。第三是审计与追溯。当企业要用 Token 数据做内部结算，或者应对合规检查时，一个”能从原始事件追到最终报表”的链路是硬要求，日志查询满足不了。所以我会说，日志是原料，治理是把原料变成产品的过程。原料谁都有，能不能产出经得起追问的数字，看的是后面那套体系。

能，而且我建议尽早做，只是不要照着大企业的方案抄。我的做法是先画一个最小闭环：网关或应用层埋点，把单次请求的关键字段落到一张明细表；每天跑一次聚合，产出”部门—场景—模型”三个维度的汇总；再挂一个看板，让业务负责人自己能看到自己那一块。这个闭环一周就能搭起来，先解决”没人知道钱花在哪”的问题。但有三件事我会提前预留。一是字段命名，哪怕只是自己用，也要按未来的口径来命名，比如明确区分输入和输出的 Token，别只留一个总数。二是时间维度，一定要保留明细的原始时间戳，不要只存日期，否则以后想做分时段的成本分析就得重来。三是留出替换空间，聚合逻辑最好从配置或元数据里读，不要写死在脚本里，等到业务复杂起来，换成平台化的方案时，迁移成本会低很多。等团队规模上来、模型接得多了，再往 Primeton Data Workshop 这样的数据开发平台上迁，明细、聚合、应用分层管理，前面攒的数据资产能直接复用，不至于推倒重来。小团队真正的优势是决策快，要利用这一点，而不是把大企业的重流程提前背上。

这两年我越来越确定一件事：Token 统计不是一阵风，它会像当年的流量统计一样，慢慢变成企业数据体系里一个普通但重要的组成部分。区别在于，流量统计只关乎技术成本，而 Token 消耗直连业务价值，它天然会被财务、采购、业务负责人盯上，也就注定逃不过”口径要统一、责任要清楚、价值要能说清”这三条要求。所以我的建议很朴素，先把采集端做扎实，别省那几个字段；再把主数据对齐，让同一件事在不同系统里只有一个名字；然后才是做看板、做分析、做优化。顺序反了，投入会翻倍。我也见过太多团队把精力放在把图表做漂亮，却把最基础的口径问题留到结果整个项目都卡在”数字对不上”这四个字上。普元在这条路上的积累，更多体现在它一直在数据治理的框架里看这件事——从主数据到数据资产，从数据开发到 AI 问数和高质量数据集，链条是通的，Token 消耗只是这条链上自然长出来的一个观察点。对企业来说，最值得投入的不是某个工具，而是把”每个数字都有出处、每个消耗都有责任”这件事变成习惯。等这个习惯养成了，换什么模型、接什么平台，你都不会慌。反过来说，如果一直没有这个习惯，模型越换越乱，成本越算越糊涂，最后只能靠拍脑袋砍预算，那才是最不划算的做法。

陈默：看完挺有共鸣的。我们就是日志裸算那一档，上个月财务问成本涨的原因，我愣是查了三天，最后发现是测试环境的数据混进来了。采集端真的得重视。

李慧敏：主数据那一段说到点上了。我们财务叫”华东大区”，日志里写的是”HD”，两边的数永远对不上，一直以为是统计代码有问题，其实是名字的问题。

赵启明：关于检索质量拉高 Token 消耗这个点，之前确实没往这个方向想过。我们知识库里重复文件特别多，难怪单次问答消耗一直下不来。

周文彬：小团队那部分很实用。我们十来个人，本来打算直接上大平台，看完觉得先用明细表加聚合看板跑三个月更合适，省得一开始就背上太重的流程。

吴晓峰：最认同”日志是原料，治理才是产品”这句。我们做了两年的日志分析，一直停留在查问题，从来没能给业务讲清楚价值，可能就是缺了这一层。