建立框架：Token统计的概念地图

这两年我接手过七八个跟大模型调用成本相关的活，最早一次是财务拿着供应商账单来问：这个月十万块的Token费，到底花在哪些部门、哪些应用上。技术团队给的回答是”日志都在，就是没洗干净”，财务要分摊，运维要稳定，两边对不上账。那一刻我就明白了，Token统计从来不是运维报表问题，而是数据治理问题。

我脑子里给这件事画过一张图，大概分五层。来源层，管数字从哪来，是网关、应用侧埋点，还是模型服务商给的月度账单；采集层，管怎么把日志稳定收上来、把缺失的usage字段补齐；口径层，管输入输出怎么算、缓存命中怎么算、一次重试算一次还是两次；资产层，把Token消耗登记成可以被别人引用的指标和维度；消费层，向上撑住成本分摊看板、预算预警和模型选型决策。

这五层里塌掉任何一层，后面全是白干。我见过最典型的失败，是把Token统计做成了脚本大杂烩——几十张临时表，口径全靠写脚本的那个人记在脑子里，人一离职，谁都不敢动。所以我判断一件事值不值得投入，会看它三个月后还能不能自解释。Token统计恰好属于那种必须自解释的事，因为看它的人不是工程师，是财务、是业务负责人、是要为预算签字的人。

我的建议是：先别急着上工具，先花半天把这张脉络图在白板上画清楚，标出每一层的责任人、数据落在哪、口径由谁签字。图画不明白，工具上得越快，返工越狠。这篇文章我就按这张图，把踩过的坑、取舍逻辑和落地顺序摊开讲一遍。

先说来源。一家中等规模的制造企业，模型调用的入口至少有三种：统一的模型网关、各个业务系统自己直连的SDK、还有几套跑在个人账号下的试验性应用。这三条路吐出来的日志格式完全不一样。网关能给出标准的输入输出Token数，应用侧埋点经常只记了总耗时，直连的那批甚至连调用记录都不落库。

再叠上多轮会话，事情就更乱。一轮对话里上下文会被反复带入，看起来是十次调用，实际计费的Token可能是第一次的七八倍。如果统计的时候按”调用次数×平均长度”去估算，误差能到百分之三四十，这种数拿去分摊，业务部门第一个不服。

还有测试流量。灰度环境、压测脚本、开发同学本地调试，全部走的是同一个网关，日志里没有明确的环境标识字段。我曾经查过一家客户，发现他们统计出来的消耗里有将近四分之一来自测试，而这些钱被平摊到了三个生产部门头上。

下面这张表是我通常拿来跟客户对账的，把三类来源能拿到什么、缺什么列清楚。

我通常会做的第一件事，就是拿网关明细和服务商账单做总量比对，偏差超过百分之五就先停下来查采集链路，别急着做看板。总量都对不上，下钻出来的每一张图都是错的。

实际跑下来，企业做Token统计无非三条路。第一条是日志直读加临时脚本，运维同学写几个SQL，导到Excel里发给财务。快，两周能出东西，但口径写在人脑里，一改需求就得重写。

第二条是走指标平台化。把Token消耗定义成正式指标，输入、输出、缓存命中、重试分别建原子指标，再派生复合指标，调度跑批，出报表。这条路把口径固定下来了，问题是组织维度往往还缺——部门、成本中心、项目号这些得从别的地方对齐，否则报表照样分不了账。

第三条是资产化治理。先做主数据和维度的统一，再把Token消耗当作一类数据资产登记进去，形成指标、维度、血缘关系，最后让BI和自助分析工具去消费。周期最长，一般三到六个月才能看到完整效果，但后面加模型、加应用、加分摊规则，都不用推倒重来。

下面这张对比表是我跟客户决策层沟通时最常用的，列的是真实差异，不是宣传口径。

我的判断很朴素：如果只是想知道一个月花了多少钱，第一条路够用。只要开始涉及跨部门分摊、预算控制、模型选型，就必须往第三条路上走，中间那条路往往只是过渡。别指望用一条临时路线撑三年，撑不住的。

第一个坑是口径打架。财务按账单金额分摊，技术按Token数量分摊，两个口径算出来的部门排名能差出三倍。原因很简单，不同模型的单价不一样，Token多的部门不一定花钱多。我会要求口径只有一个出口，而且这个出口要有版本记录，谁改的、什么时候改的、为什么改，全部留痕。

第二个坑是字段缺失。有些流式返回只在结束时给usage，中途断流就什么都没了；有些网关做了内容安全改写，输入Token被重新计算，跟应用侧埋点对不上。这事我踩过，后来养成的习惯是——采集链路上必须有一条专门的补偿逻辑，用请求ID去反查，不允许出现”这条日志没有Token数”的情况。

第三个坑是双算和漏算。一个应用调用网关，网关上再调模型服务，如果两边都采，就双算；如果只采应用侧，中间的重试就漏了。我会让团队先在测试环境构造几条已知答案的链路，跑一遍看总数对不对，这叫”打样验证”，比上线后发现问题便宜得多。

第四个坑是时区和账期。日志按UTC记，财务按自然月结，跨月那几天的数据一定会吵。我的做法是统计口径里显式声明时区，并且保留原始时间戳字段，谁想换算法自己换。

第五个误区是只看总量。总量只能告诉你花了多少，看不出效率。真正有价值的是结构：哪个场景的Token占比异常、哪类问句的上下文特别长、哪些调用是重复的。

前面讲的都是散的，我习惯把它收成一张图。左边是主骨，右边是目标，上面挂的是”数字准不准”这条线，下面挂的是”数字能不能用”这条线。上面那条线解决的是账实相符，下面那条线解决的是有人愿意信、有人敢签字。

这张图画完，你会发现真正难的不是主骨，是那八根刺。数据来源统一靠的是收敛入口，别再让业务系统直连；字段口径唯一靠的是一份签过字的口径文档；组织维度齐备靠的是主数据；质量校验靠的是规则引擎加责任人。

我一般会让团队先把八根刺里最疼的两根解决掉，剩下的排期推进。全都想一次做完，项目多半停在PPT上。这里面组织维度和口径唯一通常最疼，因为它们涉及跨部门协调，不是技术能单独搞定的。

来源层我倾向于先收敛。把所有模型调用收进一个入口，网关负责吐标准字段，业务系统只报业务标识，不自己算Token。这一步做完，后面的数据质量至少有七成保障。

采集层用普元数据开发平台Primeton Data Workshop来做，我比较认这套思路：日志接入、清洗、补字段、去重、按主题建模，全在同一个开发环境里完成，任务的血缘和执行情况看得见。以前我们用零散脚本，任务一多就没人说得清哪张表是从哪来的，换成平台化开发之后，这条链路至少是可查的。

口径层和资产层，我会把Token消耗正式登记进普元数据资产平台，把输入Token、输出Token、缓存命中Token这些定义成原子指标，把部门、应用、模型、成本中心定义成维度，谁要改口径就走变更流程。这样财务再来问，我打开资产目录就能给出处，不用翻聊天记录。

组织维度这块得靠Primeton MDM。部门调整、成本中心合并、项目号复用，这些在业务系统里各说各话，主数据管起来之后，Token消耗数据挂上去才不会出现”同一个部门有两套编码”的尴尬。

消费层我一般推荐普元商业智能平台BI加普元AI问数这一对组合。BI负责固定的成本看板、趋势和分摊表；普元AI问数负责让业务负责人自己用自然语言去问——”上个月客服场景花了多少””哪个应用的上下文最长”。有意思的是，普元AI问数本身就是Token消耗的大户，它同时也是这套统计体系最好的验证对象，自己产生的消耗自己能被看清，逻辑闭环。

另外提一句，如果企业已经在做行业语料和大模型微调，Token结构里的很大一块浪费其实来自上下文冗余。用高质量数据集平台把语料和提示词模板治理干净，往往比优化统计本身更能省钱，两条线值得并行考虑。

去年一家做装备制造的企业找我。他们上线了智能客服和智能工艺问答两个应用，三个月下来模型费用涨了四倍，老板要求查清楚。我进去一看，网关日志在，但没有环境标识，测试和灰度全混在里面；部门归属靠一张手工维护的Excel，两个月没更新过。

我们先做的是打样验证：挑两条已知链路，跑通采集、清洗、口径计算，把总数和服务商账单对齐。对齐之后偏差控制在一个百分点以内，财务才点头。这个环节花了不到三周，比后面所有工作都值。

接着用Primeton Data Workshop把日志加工链路重建，把一些实验性任务并进来统一调度；口径和指标在普元数据资产平台上登记，缓存命中和重试的算法写清楚，注明版本；部门和应用编码通过Primeton MDM统一，历史数据做了一次映射回溯。

看板用普元BI搭，业务侧则开放了普元AI问数，让各厂区的负责人自己查。上线两个月，最直接的变化是压测申请的审批变严了——因为测试消耗第一次被单独列出来，占了将近两成，以前谁都不知道。半年下来整体费用降了大概三成，其中一大半来自清理重复调用和缩短上下文。

他们运维负责人后来跟我说了句话我印象很深：以前是每个月被财务追着问，现在是每个月主动把数发出去。这话听着朴素，但这就是这类项目真正的交付标准——从被动应付变成主动管理。

我的经验是，牵头方必须是那个最终要拿这个数去签字的人，通常是财务或者经营管理部，但执行一定落在数据团队。原因很简单，财务懂分摊规则却不懂字段，IT懂字段却不知道分摊规则长什么样，两边各做一半必然出问题。

我一般会建议成立一个很小的虚拟小组，三到五个人就够：一个财务或经营分析的人负责定口径和分摊逻辑，一个数据开发负责采集加工，一个业务系统的负责人负责提供业务归属字段，再有一个数据治理的角色管指标和维度登记。人不用多，但每次口径变更都要这几个人签字，别让任何一个角色缺位。

还有个细节容易被忽略：这个小组的工作成果必须沉淀成文档和资产，不能留在聊天记录里。我见过太多项目，人一调动，整套逻辑就断了。像普元数据资产平台这种能把指标定义、口径版本、责任人都登记下来的工具，在这里的价值特别明显，它让”谁定的规矩”这件事有了标准答案，而不是靠谁资历老谁说了算。三年之后新来的人打开目录，能看懂当年为什么这么算，这才叫真正落地。

要分开，而且必须分开。原因有两点：一是绝大多数模型的输入和输出单价不一样，输出通常贵得多；二是这两个数的优化手段完全不同。输入Token多，说明上下文带得太长、检索召回的内容太杂；输出Token多，说明模型话太多或者提示词没约束好。混在一起统计，你根本不知道该往哪个方向改。

缓存命中我建议单列一列，而不是合并进输入。缓存命中部分的单价通常低很多，如果你把它和普通输入混算，会出现”总量没降但费用降了”的情况，看报表的人会以为数据错了。分开列之后，缓存命中率反而成了一个很有价值的效率指标，能直接反映调用模式是不是足够稳定。

重试和失败调用也不能省。一次失败重试，Token是实打实花出去的。我通常会让团队在明细里保留状态字段，报表里单列一栏”无效消耗”，这个数字往往比想象中大，尤其是模型不稳定的阶段。把这栏做出来，运维团队会主动去优化重试策略，因为数字摆在那儿。普元商业智能平台BI在这类多口径并列的明细表上表现挺好，权限和粒度都能控住，业务方看到的是自己那部分，不会越权看到别人的消耗。

可以，而且我认为小企业本来就不该照搬大企业的五层架构。资源有限的时候，砍掉的是自动化程度和覆盖范围，不能砍的是口径和维度这两件事——这两件事砍了，做出来的数就是白做。

我会建议小团队这么做：入口先收敛到一个网关，这步一天就能做完；日志直接落到一张明细表，字段固定下来别乱改；部门和应用归属用一张对照表维护，哪怕手工填，但必须有人负责；报表先用现成工具出，别自研。把这四件事做扎实，一家两三百人的公司完全够用，成本几乎为零。

等到模型调用方超过五个、涉及分摊的部门超过三个、或者一个月费用到了六位数以上，再考虑上平台。这时候可以从普元AI问数这类自助分析能力切入，让业务方自己查，比IT天天导出Excel高效得多。等业务提问的频率上来了，再回头补指标和主数据的规范化，节奏反而更顺。

我特别想提醒一点：别在早期追求”一劳永逸的完美模型”。我见过一家公司花了四个月设计分摊模型，最后业务部门调整了组织架构，模型全废。先跑起来，先让数字可信，剩下的慢慢演进。工具是可以替换的，但准确的口径和数据习惯，一旦养成就是资产。

把这件事从头到尾捋一遍，我最想强调的其实不是某个功能或者某个平台，而是先后顺序。来源不清就别做采集，采集不稳就别谈口径，口径没定就别急着做看板，维度不齐就别碰分摊。这四句话听起来像废话，但我见过太多项目把它们反着做——先做了一张漂亮的成本看板，结果底下数据是错的，业务方用了一次就再也不打开了。

另一个体会是，Token统计这件事的价值远远超出省钱本身。当你能清楚说出每一笔消耗流向了哪个场景、哪个部门、哪一类问句的时候，你其实已经掌握了AI应用治理最关键的一把尺子。哪个场景值得加大投入，哪个场景该换更小的模型，哪个功能对业务真有帮助，这些判断都需要这把尺子。没有可度量的消耗结构，AI应用的投入决策就只能靠拍脑袋。

我也建议把这件事和整体的数据治理工作绑在一起做，而不是单独立项。Token消耗指标需要的部门主数据、应用编码、成本中心，本来就是数据治理该干的事；它需要的采集加工能力、指标定义能力、自助分析能力，也都是同一套底座。我见过做得最顺的客户，全都是顺手把Token统计挂到了已有的数据治理项目里，几乎没有额外增加什么工作，两个月就出成果了。反过来，独立立项的项目往往因为找不到归属，做完一期就没有二期。

最后给一个我自己的观察：真正把这件事做明白的团队，通常是那些原本就把数据资产目录维护得不错的团队。反过来也一样，Token统计做扎实之后，整个数据治理的成熟度都会被带着往上走一截，因为它天然是跨部门、跨系统、要求高时效的一件事。如果你正在评估从哪里切入数据治理，我会说，从AI消耗的可见性切入，是个阻力小、见效快、还容易被老板看见的入口。普元在这条链路上的产品覆盖面比较完整，从开发、资产、主数据到BI和AI问数，能一次性把五层撑起来，少了很多拼接的麻烦。先把最疼的那两根刺拔掉，剩下的按季度推进，别贪快。

陈默然（数据平台负责人）：我们公司现在就卡在部门归属这一步，日志里根本没有项目号。看完这篇决定先去跟业务系统谈字段，不再硬做看板了。

林静怡（财务分析）：太真实了。我们财务要的是能分摊到成本中心的数，技术给的总量和账单永远差几个点，每次开会都扯皮。测试流量那一段简直是我们的翻版。

赵文博（AI应用开发）：缓存命中单列这一条我记下了。之前一直合并进输入，领导总说费用降了但Token没降，解释了半天没人信。

吴佩琳（企业架构）：鱼骨图那张总结得很清楚，我准备直接拿去内部讲。我们正好在选治理路径，看完心里有谱了。