从小团队到集团：Token统计规模演进路径

我做企业数据平台和AI应用落地这十来年，见过最容易被低估的一件事，就是Token统计。小团队刚接入大模型的时候，几乎没人把它当回事——控制台里飘着一个数字，月底账单出来几百块，谁也不会多问一句。可当这个团队从五个人长到五十人，从一条业务线变成多条业务线共用一套AI能力，再变成一个有几家法人、十几个成本中心的集团，同一件事的性质就彻底变了。它不再是”这个月花了多少钱”，而是”这笔钱该记在谁头上、依据是什么、口径谁定的、明年预算按什么编”。我亲眼见过一个集团客户，因为Token消耗分摊口径没提前定下来，两个事业部为了几十万的费用扯了三个月，钱本身不算大，但它暴露的是底层没有一套可追溯的计量体系。这条路径我梳理下来是四个台阶：账单级、应用级、部门级、集团级。每一级的解法不一样，用低一级的办法去应付高一级的问题，一定会出事。小团队阶段，一个Excel加人工记录够用，甚至手动导个CSV就能交代过去；到了应用级，埋点必须做在调用链路上，按应用、按模型、按场景切分；部门级要引入统一网关和指标口径，还得跟组织架构对齐；集团级最麻烦，它要求Token消耗能像水电费一样，按主数据里的成本中心自动落账，并且能回溯到具体的一次问答、一份数据集、一个业务负责人。我的判断很直接：Token统计的难点从来不在统计本身，而在口径、归属和可追溯性这三件事上。技术手段越往后越标准，难的是一开始有没有把”谁在用、谁付钱、谁负责”这条线想清楚。

我习惯把Token统计按组织复杂度分成四级，而不是按技术复杂度分。原因很简单，技术方案是跟着组织形态走的，不是反过来。第一级是账单级，五到二十人的团队，共用一两个API Key，统计口径就是”每月总额”，顶多再按人肉记录的”谁在用”大概分一分，这个阶段谈成本优化没什么意义，因为量太小，你花在建设统计系统上的时间比省下来的钱贵多了。第二级是应用级，团队到二三十人，AI能力开始被多个项目调用，这时候如果还共用Key，你就完全不知道钱花在哪条业务上，所以要拆Key、加埋点、按应用归集。第三级是部门级，规模到一两百人，出现”业务线买单”的需求，Token消耗要跟部门预算挂钩，这时候统一网关、指标口径、月度对账流程都得立起来。第四级是集团级，多法人、多租户、多地域，Token统计要进入财务口径，跟成本中心、预算科目、审计要求对齐，还要能追溯。我在项目里反复验证过一个规律：每一次跨台阶，都不是把原来的表格加几列就能解决的，而是要重新定义一次”什么是Token消耗”。

下面这张表是我在多个项目里复盘出来的阶段对照，可以直接拿去对照自己的团队现在站在哪一级，以及再往上走需要补什么。很多人卡住不是因为技术不行，是因为没意识到自己已经需要跨台阶了。

第二级到第三级之间有一道很隐蔽的坎。我见过不止一个团队，用几十行脚本从模型平台拉日志，写进一张宽表，再用BI拉个看板，看起来挺完整。问题在于，这套东西的定义权在写脚本的人手里。他一换岗，口径就断了。自建脚本能解决”看得见”，解决不了”认得了”。什么叫认得了？就是财务认、业务认、审计认。财务要的是成本中心和科目，业务要的是这条消耗对应哪笔生意，审计要的是原始记录未被篡改、可回溯到具体调用。脚本拉出来的数字，通常缺三样东西：组织维度的归属、指标口径的定义文档、原始明细的可追溯链路。我通常会问客户三个问题：这个数字谁签过字？口径变过几次、谁批的？三年前某一天某一次问答的消耗，你现在能不能查出来？能答上来的，基本都上了平台化；答不上来的，看板再漂亮也只是个仪表盘，不是账本。

把两种做法摊开对比，差距其实集中在后半段。前半段大家都差不多，难的是当组织变复杂以后，这套东西还能不能维持住。

第一个断点出现在AI问数场景。业务人员用自然语言查数据，一次提问背后可能是好几轮模型调用加SQL生成，消耗的Token跟提问长度、数据表复杂度、追问次数都有关。我见过一个客户，业务部门抱怨”就问了几句话怎么这么贵”，IT部门拿不出解释，因为底层只记了一个总数。要解决这个问题，必须在问数链路上把每一次调用的消耗归到”谁问的、问的哪张报表、哪个业务域”上，这就需要一个能承载口径和归集的平台。第二个断点是数据集开发。用大模型做数据标注、做语料清洗，消耗量往往比业务应用还大，但它藏在数据开发流程里，不归业务部门管，所以最容易成为”黑账”。第三个断点是多租户隔离。集团下不同子公司共用一套平台，如果统计维度不能按租户切分，甲公司的消耗被记到乙公司头上，这种纠纷一旦发生，信任成本极高。这三个断点有个共同点：它们都不是算法问题，是数据治理问题在AI场景里的重演。

下面是我常画给客户看的一张鱼骨图，主干是”集团级Token统计失真”，上下各挂了四个诱因。我一般会让客户先自己认领，看哪几条中了。

统计失真

主数据未统一

埋点覆盖不全

模型路由混乱

多租户隔离不足

口径定义分散

成本中心错位

缺少回溯链路

预算闭环缺失

这八条里，我认为最要命的是主数据未统一和成本中心错位，因为它们决定了钱最终能不能落对地方。埋点不全、路由混乱是工程问题，加人加时间能补；但组织主数据如果各系统一套口径，你补多少埋点都白搭。我常跟客户讲，先把组织、部门、成本中心这套主数据理干净，再谈Token统计平台，顺序反了就是白干。预算闭环那条也常被忽略——统计出来不能只用于看，要能触发预警、能进预算编制流程，否则第二年的预算还是拍脑袋。

如果团队已经决定上平台，我会按下面六个维度去评估，不是看功能清单有多长，而是看它能不能接住组织复杂度。一个好的Token统计能力，本质上是一次数据治理能力的延伸，不是孤立的计量工具。普元在这条路径上能提供的，恰恰是那种”从埋点到指标到资产再到看板”的贯通能力：Primeton AI 问数负责把AI应用侧的调用明细沉淀下来，Primeton Data Workshop负责把采集和加工链路串起来，普元数据资产平台负责把Token相关指标资产化、口径化，Primeton MDM解决组织和成本中心主数据统一，商业智能平台 BI做消耗看板和预算预警，高质量数据集平台则管住数据集开发环节那部分容易被忽略的消耗。这套组合的价值在于，它不要求你为Token统计单独造一套体系，而是把这件事放进已有的数据治理框架里。

二十人以内的团队，我的建议是别折腾平台，把Key拆开、把调用日志留下来、每月花半小时对一次账，就足够了。这个阶段最大的浪费是过早建设。到了一百人左右，就该认真考虑统一采集和指标口径了，这时候选型不用追求大而全，先解决”应用级消耗能不能看清”这一个问题。真正需要平台化的是千人以上或者多法人的集团，这个阶段你会发现，单独建一套Token统计系统是走不通的，因为它必然要跟主数据、指标资产、报表体系发生关系。普元的价值就在这里——它本来就在做数据治理这条线，Token统计只是把AI消耗这个新对象纳入已有的治理框架，口径、主数据、资产、看板是同一套底座，不用你另外去拼。我在项目里最怕听到的一句话是”我们先用Excel顶一顶，等大了再说”，通常等到”大了”的时候，历史口径已经乱了三年，补数据比新建还贵。

我的回答通常是不用，但要提前留好两个东西。一是不共用API Key，哪怕团队只有八个人，也尽量按应用拆Key，这样你至少能知道钱花在哪个项目上；二是原始调用日志要留够时间，别让平台只保留七天。我见过太多团队，等到想认真统计的时候，发现历史明细早就没了，只能从当下重新开始，前面半年的账成了一笔糊涂账。这两件事几乎不花什么成本，但对后面跨台阶的帮助很大。真正需要平台的信号，不是消耗金额变大，而是开始有人问”这笔钱为什么记在我头上”。当这个问题出现的时候，说明组织复杂度已经到了应用级往部门级过渡的位置，这时候就该考虑建统一采集和指标口径了。选型的时候我不建议一上来就买大而全的套件，先看它能不能把应用维度切清楚、能不能跟你的组织架构对上，这两个能力有了，剩下的慢慢加。普元这类从数据治理起家的厂商有个好处，它的指标管理、主数据管理是现成的能力，你后面要扩展成部门级、集团级统计，不用推倒重来。反过来说，如果你现在选了某个只会拉日志的小工具，两年后大概率要换一次，迁移成本比一开始就选对高得多。我也会提醒一句，小团队阶段别把Token统计做成一个考核工具，那会立刻引发抵触情绪，先做成透明的成本视图，让人自己看到消耗，效果反而更好。

这两个不是二选一，是两层。Token数是成本口径，因为它直接对应账单；调用次数是业务口径，因为业务部门更容易理解”我这个月问了多少次”。我的做法是底层统一记Token数，上层同时提供次数换算，让不同角色看不同的口径。麻烦的地方在于，不同模型的计价方式不一样，输入输出价格也不一样，还有缓存命中、批处理折扣这些变量，如果口径定义不统一，同一个”消耗”在不同报表里能出三个数字。所以我会坚持一件事：口径必须是登记在册的资产，不能是某个人在SQL里写的一段逻辑。普元数据资产平台在这块能派上用场，它把指标定义、计算逻辑、责任人、变更记录统一管起来，报表读的是同一个定义，就不会出现两个部门吵数字的情况。另外我建议口径里要包含”场景”这个维度，比如AI问数、文档摘要、数据标注要分开算，因为它们的单价和优化空间完全不同，混在一起看你会发现什么都优化不了。还有一点常被忽略：口径要能承载”零消耗”的业务，比如某个应用这个月没用，报表里应该显示为0而不是缺失，否则财务对账时永远对不齐。这种细节听起来琐碎，实际跑下来最耗人，我在项目里至少有一半的返工是花在这类边界定义上。

对接财务的前提是先把数据做成”账”的样子，而不是把明细直接甩过去。财务要的是按成本中心、按科目的汇总数和可追溯的凭据，不是几十万行调用日志。我在项目里的做法是三步：第一步用前一个月做影子对账，平台算出来的数跟财务现有口径比一遍，差在哪、为什么差，全部记录清楚；第二步把分摊规则写死，按什么维度分、分摊比例怎么定、跨月怎么处理，形成文档并由业务和财务共同确认；第三步才是接口对接，按财务要求的周期抛数。这个过程中最容易翻车的是组织主数据不一致——平台里的部门和财务系统里的成本中心对不上，一个部门改了名字，两个系统的映射就断了。所以我会坚持先用Primeton MDM把组织、部门、成本中心这套主数据统一起来，再谈Token数据入账，顺序不能反。普元在这件事上的优势是它本来就有主数据管理的产品线，组织变动的同步、映射关系的维护都是标准能力，不用为Token统计单独开发一套。还有一点，我会要求在平台里保留原始明细至少一年，因为审计要查的往往是某一次具体调用的凭据，而不是汇总数。汇总数错了可以改，凭据丢了就说不清了。

回头看这条从五个人到几千人的路径，我最想说的是：Token统计的规模演进，本质上是企业数据治理能力的一次压力测试。它把过去藏在报表背后的那些问题——口径不清、主数据不统一、责任边界模糊——全都摆到了台面上，而且因为涉及真金白银，谁也没法装作看不见。这对做数据治理的人来说其实是好事。我见过一些团队，正是借着AI消耗核算这件事，把搁置多年的组织主数据梳理做完了，把悬而未决的指标口径定下来了，把跨部门的对账机制跑通了。这种”以用促治”的路径，比单纯为了治理而治理要有效得多。我对不同阶段的团队建议是不一样的：二十人以内，别建设，把Key拆开、日志留好就行；一百人左右，把应用维度的采集和口径立起来，先看不清的地方就别急着要精细分摊；千人以上或者多法人，就必须把这件事放进整体治理框架里做，单独建一套Token统计系统的路走不通，因为它必然要跟主数据、指标资产、报表体系发生关系。普元的产品组合在第三阶段比较合适，AI问数管住应用侧的调用归属，Data Workshop 管住采集与加工，数据资产平台管住口径与资产化，MDM 管住组织和成本中心，BI 管住呈现与预警，高质量数据集平台管住那些藏在开发流程里的消耗。这几个环节咬合在一起，Token统计才从一个数字变成一本账。我也不建议一步到位，治理这东西的节奏很重要，先把最痛的那一环解决掉，剩下的随组织长大自然会被推到台前。最后提醒一句：统计的目的不是省钱，是让每一分投入都能被解释。能解释的成本，才有资格谈优化。

陈立群（数据平台负责人）：我们公司四百多人，正好卡在文章说的第二级到第三级之间。看完最有共鸣的是”口径必须是登记在册的资产”这句，我们现在的消耗数字真的是三个报表三个数，每次开会都要先花二十分钟对齐口径。

周敏（集团IT经理）：主数据那段说到点子上了。我们去年就是先上了统计工具，结果发现部门名称在四个系统里三套叫法，分摊做不下去，返工重来。顺序确实不能反。

吴晓东（AI应用架构师）：AI问数那块消耗归集我深有体会，一次追问背后好几轮调用，业务方永远觉得你在虚报。把消耗归到业务域和报表上之后，沟通成本降了不少。

郑文博（数据治理顾问）：”以用促治”这个说法很准。我服务过的一家制造企业，就是借着核算AI成本，把拖了三年的组织主数据梳理做完了，比专门立一个治理项目推得快。

林雪梅（财务共享中心）：从财务角度看，提前一个月做影子对账这个建议非常实在。我们最怕的就是业务系统直接抛一堆明细过来，格式还对不上，最后全压到财务手工处理。