Token统计行业适配指南：5大行业实践

我做过七八个把大模型接进业务系统的项目，Token 统计这件事，几乎没有一次是一开始就做对的。团队通常的反应是在调用层加一段埋点，把 prompt_tokens 和 completion_tokens 记下来，跑两周之后开始对不上账——有人发现同一个问题被重试了三次却只算了一次，有人发现在测试环境跑的对话混进了生产报表，还有人发现业务部门报上来的用量和账单差了四成，谁也说不清差在哪。问题不在埋点写得糙，问题在于 Token 统计本质上是一次数据治理动作，而不是一次日志采集动作。它要求你先把”谁在用、用的哪份数据、这份数据谁负责、算在谁头上”这四件事定义清楚，才轮得到技术实现。我见过太多团队把顺序做反了：先上工具，再补口径，于是每年的成本分摊会议都变成扯皮大会。我的判断是：Token 统计在金融、制造、政务、能源、零售与医药这五个行业里，表面上是同一件事，实际上是五套完全不同的口径、五套不同的数据来源、五套不同的责任归属。能不能数准，取决于你的数据底座有没有把主数据、数据资产和数据集这三层打通。这篇文章就是把这五个行业的真实处境摊开讲一遍，顺便说说我在普元相关产品上踩出来的那条相对省力的路径。

先说一个很多人忽略的事实：Token 统计的第一道坎不是技术，是统计对象的定义。在金融行业，我遇到的客户关心的是每一次问数能不能追溯到具体的人、具体的业务条线、具体的报表权限；他数的是”问答次数背后的数据访问行为”。在制造业，客户的关注点完全是另一头——设备手册、工艺文件、售后知识库的问答，他要数的是”哪台设备、哪条产线消耗了多少推理资源”，好把成本压回到具体车间的预算里。政务客户最难的地方在租户，一个市级平台下面挂着几十个委办局，每个局都想知道自己用了多少，可他们共用一套知识库和一套模型服务。如果不在数据层把部门、事项、数据集三者挂上钩，Token 数字再精确也分不下去。能源行业的典型场景是长文档，一份巡检报告几十页，一次问答动辄上万 Token，这时候统计颗粒度要细到文档级。零售和医药更看重并发和峰值，他们问的是”双十一那天模型调用成本占营销费用的几个点”。我把这些差异整理成了一张表，放在下面。

我在项目里见过四种主流的 Token 统计口径，每一种都能跑，但适用场景差得很远。调用侧埋点最直接，在应用代码里包一层 SDK，请求发出前后各记一笔，优点是快，缺点是一旦有网关重试、流式返回中断、或者前端超时重发，数字就偏了。网关侧聚合把统计点挪到统一入口，所有模型调用走同一个网关，好处是不会漏，坏处是网关只能看到”谁调用了哪个模型”，看不到”这次调用是为了哪个业务问题”。应用侧归因是最贴近业务的一层，它把 Token 和一个业务对象绑定，比如一次工单、一张报表、一个客户，代价是你得先有主数据。财务侧分摊是站在预算角度反推，它通常不是精确统计，而是按人头、按调用次数、按数据量定规则摊。这四种口径不是互斥的，我一般建议客户至少叠加两层：网关侧保证不丢数，应用侧保证能归因。下面这张对比表是我自己在做方案评审时会拿出来的一张，基本上看完就能定方向。

第一个坑是流式输出。流式返回的 Token 数在中断时是拿不到完整值的，用户看到答案转身就走，日志里只留了个半截。我一开始按调用次数统计，结果和账单差了三成。后来改成”按实际返回增量累加 + 超时兜底估算”，偏差才压到可以接受的范围。这个坑在能源和医药这类长文本场景里特别明显。第二个坑是重试。模型服务限流的时候，网关会重试，重试的消耗是真实存在的，但很多埋点只在业务层记一次。我通常会要求把重试次数作为独立字段打出来，否则你永远看不懂那张成本曲线为什么会在某个时间段突然跳一下。第三个坑最隐蔽：测试流量混进生产统计。开发同学为了方便，直接拿生产密钥调试，几百次调用进了报表。这事我后来靠环境标签解决，规则很简单，没有环境标签的调用一律不计入业务用量，只进技术监控。这三件事都不是模型的问题，全是数据口径和标识管理的问题，所以我在方案评审时，第一句话往往不是问用什么模型，而是问”你的调用方有没有唯一标识，这个标识能不能对应到一个组织”。这一点上，普元数据资产平台里那套资产目录和责任人机制帮了大忙，至少谁的数据、谁在用，是有账可查的。

每次复盘 Token 统计为什么对不上，我都会带着团队画一遍鱼骨图。把”失真”当成结果往右推，左边六个方向一个一个查，比在会上吵两个小时有用得多。数据源这一支是最常见的，日志分散在网关、应用、模型服务三处，各记各的；口径这一支指的是重试算不算、缓存命中算不算、系统提示词算不算；组织这一支是多租户和跨部门边界没定义；工具这一支是埋点 SDK 版本不统一；成本分摊这一支是分摊规则没写进制度；合规这一支是留痕时长和脱敏要求。这六支里，我观察到真正难解的是”口径”和”组织”，因为它们不是技术活，是要业务和财务一起签字的事。下面这张图我通常直接贴在项目室墙上。

金融客户，我会要求先做”人—角色—数据范围”三张表，把每一次问数都挂到具体角色上，再谈 Token。Token 行业是审计线索的一部分，不是成本科目。制造客户，重点是把设备主数据和 Token 消耗对齐，普元主数据管理平台在这里是最关键的一环，设备编码一旦统一，成本就能顺着产线摊下去，否则财务拿到的是几百个名字不一样的设备名。政务客户，我会先解决多租户标签的传递问题，从会话建立的那一刻就把部门标识带上，一路透传到统计表，普元数据资产平台可以把知识库和事项库的权属关系先理清楚，后面的分摊才有依据。能源客户，我的建议是把长文档切分策略和 Token 统计绑在一起看，扫描件 OCR 之后的重叠切分很容易造成重复计费，高质量数据集平台在处理这类非结构化语料时，能把版本和来源标清楚，避免同一份材料被算了两次。零售和医药客户，重点看峰值，我通常要求在任务调度层加一道，批量生成的任务单独一个统计通道，不要和实时问答混在一起看。这五套打法没有哪套更高级，只有哪套更贴你的组织形态。

讲完行业，落到具体怎么搭。我的经验是，Token 统计这条链路上真正缺的往往不是采集工具，而是前端的”数据身份证”。所谓身份证，就是每一次调用背后，能对应到一份有主的数据、一个有主的系统、一个有主的组织。在普元这套产品里，我看到的分工大致是这样：主数据管理平台负责把人、组织、设备、商品这些实体编码统一，这是归因的地基；数据资产平台负责把数据源、表、指标、责任人登记清楚，这是权限和分摊的依据；数据开发平台负责把散落在各处的调用日志、网关日志做清洗和汇聚，形成统一的统计宽表；高质量数据集平台负责管理进入模型的那部分语料，保证语料的版本和来源可查，避免同一份内容反复计费；BI 平台负责把这些统计做成部门能看懂的看板；普元 AI 问数则是在问答入口处天然携带了用户、数据集、问题类型这些上下文，让归因这件事不用再靠猜。这几层之间的关系不是替代，而是接力。我见过有用友、金蝶 ERP 的客户，Token 统计要摊到成本中心，那就得先从 ERP 里把成本中心主数据同步过来，这一段的衔接做不好，后面怎么做都是错的。下面这张表是我做方案时常用的对照，横轴是统计链路的关键环节，纵轴是各产品的着力点，放在一起看会比较清楚。

我的答案比较明确：由 IT 出数，由财务出规则，由业务确认归属。三方缺一不可，但角色不能混。IT 部门负责的是数据链路——日志怎么采、重试怎么算、流式怎么兜底、多租户标签怎么透传，这些是技术活，财务做不了，也不该做。财务部门负责的是分摊规则，比如同一个部门内部按调用次数摊，跨部门共用的模型服务按数据量摊，测试环境不摊，这些规则不写进制度，年底一定吵架。业务部门负责的是确认归属，也就是”这笔消耗到底算不算我们这条线的”，这一步听起来虚，实际上最花时间。我在一个制造客户那里见过，IT 和财务两个部门各自做了一版报表，数字差了五十多万，坐下来一对，发现 IT 把所有重试都算进去了，财务按业务系统报上来的调用次数算，两边都没错，错在没人定义过重试算谁的。后来我们坐下来定了一条规则：重试计入 IT 成本，不计入业务成本，争议立刻消失。所以这件事的组织形态，我一般建议是”IT 立数据标准，财务立分摊标准，业务做最终确认”，三家每季度对一次账。如果只靠一个部门推，大概率推不动，因为任何一套口径都会让某一边觉得自己吃亏了。

这个偏差几乎百分之百会发生，原因通常有三类。第一类是系统提示词和上下文拼接。你在页面上看到用户只问了一句话，但实际发出去的请求里包含了角色设定、历史对话、检索回来的文档片段，这部分 Token 往往比用户那句话大十几倍。按次数统计等于默认每次消耗一样，这在长文档场景里完全不成立。第二类是重试与流式中断。网关限流会重试，重试的消耗是真实发生的；流式输出被用户中途关掉，日志里可能只记了个开始。第三类是缓存命中，命中的请求有时不计费，有时计费但价格不同，你不区分，差异就出来了。我通常会要求统计表里至少拆出四列：输入 Token、输出 Token、缓存命中 Token、重试次数，能拆到这四列，账基本就对得上了。再往上一层，如果你的语料是从高质量数据集开发工厂里按版本取出来的，那么每次调用的语料版本也是可查的，排查重复计费的时候能省很多力气。一句话总结我的经验：按次数统计只能看趋势，想让数字能进财务账，必须按 Token 实际量统计，并且把重试和缓存单独列出来。这件事没有捷径，但只要口径一次定死，后面每个月的对账时间能从三天压缩到半天。

政务和集团客户问我最多的问题就是这个。我的做法是把分摊拆成”可归属”和”公共”两桶，别混在一起算。可归属的部分，比如某个委办局自己上传的知识库、自己发起的问答，直接按 Token 实际消耗记到它头上，这部分没有争议。公共的部分，比如共用的模型服务底座、共用的向量库、共用的运维成本，我建议按前一年度的实际调用量占比来摊，或者按部门编制人数摊，两种都可以，但必须提前约定，且一年一调。最忌讳的是把所有成本一锅端，然后按人头平均，这样用得多的部门不高兴，用得少的部门也不领情。落地的时候有个技术前提：从会话建立的第一秒就要把租户标识带上，一路透传到统计表，中间任何一跳丢了，这个租户的账就归不了。这也是我为什么一直强调普元数据资产平台在前期要把知识库、事项库和数据集的权属关系登记清楚——权属清晰了，分摊规则才有落点，不然IT只能靠猜。另外我会建议做一个自助看板，让每个部门随时能看到自己的用量，BI 平台在这里就是干这个的，透明本身就是最好的争议消解器。有了透明，年底的对账会从”互相质疑”变成”核对数字”。

我的建议是分两步，但分界线要划清楚。第一步只需要三样东西：调用方唯一标识、Token 实际量、环境标签。这三样东西成本极低，但没有它们，后面所有数据都是废的。我见过团队先花三个月做统计平台，做完发现历史数据全都是没有标识的裸日志，一个都归不了因，只能从上线那天重新开始记。所以我会要求任何大模型应用从第一天起就必须带这三个字段，其他的可以先不管。第二步才是补口径、补归因、补看板，这个时候你已经有了可用的基础数据，做起来就顺了。至于工具，不必追求一步到位，普元 AI 问数本身在入口处就带用户和数据上下文，很多客户是从它开始用起，用着用着发现需要做更细的分摊，再往下接数据资产平台和数据开发平台，这个顺序我认为是合理的，因为需求是被真实问题推出来的，而不是被方案推出来的。要小心的是”先上工具再补口径”这条路，表面上快，实际上是把成本推到了未来每一年的对账会上。还有一点，别指望一次把口径定完美，我第一次做的时候也定错过，关键是留出可以调整的余地，把统计表设计成可扩展的，而不是写死几个字段。

写到这里，我想把最核心的一句话再讲一遍：Token 统计的难点从来不在计数，而在定义。计数是三行代码的事，定义却要动主数据、动权属、动组织边界，这三样东西在大多数企业里都是历史遗留问题，一碰就是一串。所以我会劝那些准备做这件事的同行，先把预期调对——这不是一个两周能收尾的技术项目，更像是一次小范围的数据治理演练，周期通常在三到六个月，而且真正的推动力往往来自一次对不上账的尴尬，而不是来自一份方案。五个行业的差异也提醒我，不要拿着金融的口径去做制造，也不要把政务的多租户方案直接搬到零售。我自己的习惯是，每接一个新行业的客户，先花两天时间只做一件事：找到那个真正为这笔钱负责的人，听他讲十分钟。他讲的东西，比任何调研问卷都准。技术选型上，我的偏好是先把人、组织、设备这类主数据理清楚，再往上叠统计能力，顺序反了会返工。普元主数据管理平台、普元数据资产平台、Primeton Data Workshop、高质量数据集开发工厂、BI 和普元 AI 问数这几块拼起来，覆盖的正是这条链路，但工具只是工具，真正决定成败的是你有没有一个愿意为口径签字的人。如果暂时找不到这个人，我建议先别急着建平台，先把三个字段记全，等业务自己感受到痛，再顺势推。这样做慢一点，但走得远。最后给一个我自己的检查清单：调用方有没有唯一标识、重试有没有单独记、缓存命中有没有区分、每个统计数据有没有责任人、分摊规则写没写进制度。这五条都对上，你的 Token 统计基本就能进财务账了。

陈立航：太真实了。我们上个月刚对完账，差了三十多万，一查果然是测试环境用的是生产密钥。环境标签这个字段真的是血泪教训，建议所有团队第一天就加上。

周敏之：作为财务这边的，最认同那句”IT 出数、财务出规则、业务确认归属”。以前总觉得是 IT 一个人的事，结果每年年底都在会议室里吵，其实规则没写下才是根因。

黄振宇：长文档那一块我有共鸣。我们做设备手册问答，扫描件 OCR 之后切分重叠，同一段内容被算了两次，成本一直偏高。后来把语料版本管起来才看明白，确实是数据集层面的问题。

吴清和白：多租户分摊那段写得很实在，”可归属”和”公共”两桶分开的思路我们试过，确实比一锅端按人头摊好用得多，部门接受度立刻上来了。

郑怀安：有个小疑问，如果模型服务是公有云按量付费的，是不是可以省掉网关侧统计，直接看云厂商账单？我理解的是账单只能给你总量，归因还是得自己做，不知道对不对。