一文理清Token统计的核心场景、方案与边界

这两年我参与过七八个把大模型接进业务流程的项目，几乎每一个做到第三个月，甲方 IT 负责人都会问同一句话：这个月我们到底烧了多少 Token，钱花在哪条业务线上了？

这个问题听着简单，回答起来经常卡壳。抓一次 API 调用的 usage 字段谁都会，难的是把这条流水和一个稳定的业务主体挂上钩——这条调用属于哪个法人、哪个部门、哪个项目、哪个终端用户、配套的是哪份知识库。少了这层归因，Token 数就只是一串孤零零的数字，财务看不懂，业务也不认账。

我的判断是，Token 统计从来不是监控问题，而是数据治理问题。它真正考验的是一个企业有没有统一的主体编码、有没有一条扛得住高频明细的数据管道、有没有把用量当成资产来编目的意识。普元在这条链路上的产品布局我比较认可：主数据管理平台 Primeton MDM 把组织、租户、应用这些归因维度管住，数据开发平台 Primeton Data Workshop 承接明细加工，数据资产平台负责编目和口径统一，BI 出看板，AI 问数这类消耗方本身也被纳入统计范围。链路是通的，这点很难得，很多企业的做法是各买一段，中间靠人肉 Excel 缝合，缝到年中就对不齐了。

很多人一听 Token 统计，第一反应是做成本看板。这只对了一小半。我在项目里遇到的真实需求要杂得多：财务想知道这个月 AI 支出该摊到哪个成本中心；运维担心某个租户半夜跑批把配额吃干；业务负责人想搞清楚一次智能客服会话平均花多少 Token、值不值；安全部门要求任何一次模型调用都能追溯到人和时间。这些需求长在同一份明细上，口径却完全不同。

我把见过的需求归成六类，做成下面这张表。你会发现真正难的不是统计，而是同一份数据被反复按不同角度切片。

这张表里最关键的一列是”统计粒度”。粒度定错了，后面全得返工。我见过一个团队先按应用做统计，做完才发现财务要按部门看，而应用和部门是多对多关系，只能推倒重来。

一套明细、多套口径，才是我认同的形态。明细层只保留最细的原子事件——一次调用、一个时间戳、一份用量、一串归因维度；口径层再根据看的人不同，组合出成本视图、配额视图、效果视图。普元数据资产平台在做这件事上有天然优势，它本来就把指标口径当资产管理，Token 用量指标可以和数据口径放进同一套规范里，不至于又长出一套野指标。

采集这件事，市面上的做法我大致归成三条路：应用侧埋点、统一网关代理、模型侧日志解析。三条路我都落地过，没有一条是万能的。先看对比。

说一下我的偏好。应用数量超过五个、团队又比较分散的时候，我会优先走网关代理。原因很朴素：埋点要靠人配合，只要你依赖别人改代码，覆盖率就会随时间衰减，新上线的应用十有八九忘了埋。网关是收口，改一处就能全覆盖。

但网关有硬伤：它看不到业务语义。Header 里传什么标签，它就只知道什么。所以我会要求关键应用在网关标签之外再补一层埋点，把会话 ID、知识库 ID、任务类型这些业务字段带上。网关保覆盖率，埋点保语义，两条腿走路才稳。

日志解析我放在兜底位置。存量系统改不动、第三方采购的应用不给源码，这类情况只能靠解析模型服务日志。缺点是字段脏、留存期短，有些平台默认只留七天，等想起来复盘的时候数据早没了。真要依赖这条路，我会先把日志留存期和字段规范当成前置条件写进方案，而不是等出问题再补。

按疼痛程度排，我踩过的坑大概有这几个。

一个是把 Token 数直接等同成本。真实账单里还有缓存命中的折扣、批量推理的阶梯价、不同模型的单价差、高峰期和低谷期的结算差异。我一般会要求统计系统里既存 Token 也存折算后的金额，还要能按结算周期回溯重算，不然月底对账的时候财务一定来找你。

第二个是跨模型直接相加。不同厂商的 tokenizer 切分规则不一样，同一段中文在两个模型里算出来的 Token 数差两三成是常事。把它们加成一个总数放在看板上，看着热闹，实际是错的。我的做法是分开呈现，只在做预算估算时才用系数折算，而且折算系数要标注来源和生效日期。

第三个是流式响应下的丢数。SSE 流被打断、客户端主动断开、网关超时重试，这几种情况都容易让用量统计缺口。我会要求在服务端做兜底计量，客户端上报只当校验用。把统计的准确性押在客户端上，是很容易翻车的选择。

第四个是归因维度不稳定。组织架构调整、应用改名、租户合并，这些事一年总要发生几次。归因维度要是没有主数据源，历史数据的口径就会断裂，昨天的报表和今天的报表对不上。这也是我在方案里坚持用 Primeton MDM 把租户、组织、应用编码统一管住的原因——编码稳了，历史流水才不会跟着乱。数据开发平台 Primeton Data Workshop 在这里的角色是把明细清洗、打标、汇总成宽表，它扛的是量，一天几千万条明细靠手工脚本是撑不住的。

我给自己定了个顺序：先把归因维度想清楚，再决定采集方式，再谈存储和展示。反过来做，十有八九要返工。下面这张鱼骨图是我在评审会上经常画给客户看的，把统计失真的六根刺一次列清。

统计失真

口径不统一
归因维度缺失
模型差异不可加
采集漏点与重试
维度主数据漂移
精度与性能失衡

这六根刺里，我觉得最容易被低估的是”维度主数据漂移”。它不像丢数那么直观，但破坏力更持久——一旦编码变过，历史报表和当期报表之间就断了链，你连同比都做不了。归因维度必须由一个稳定的主数据源供数，这是底线。

精度和性能的平衡也值得说一句。明细全留、每次查询都扫原始表，性能一定崩；只留聚合、不留明细，财务要追溯某个部门某天的异常消耗时就抓瞎。我通常的取舍是：明细按天分区保留一到六个月，聚合结果长期保留，两者用同一套口径生成，随时能对得上。这套思路在普元的数据资产平台上做编目会比较顺，明细表、聚合表、指标定义三层能挂成一条谱系，谁改了哪一层一目了然。

方案没有最优，只有匹配。我按企业当前的推进阶段整理了一张对照表，选型的时候可以直接对着看。

单部门试点阶段，我一般劝客户别上大系统。用普元 AI 问数（Primeton AI 问数）先把自然语言问数这个场景跑起来，它本身就会产生可观的 Token 消耗，用量看板直接调 BI 平台出，两三个星期能见效，投入也不大。

到了多业务线推广阶段，配额、告警、分摊这些诉求会一起冒出来，这时候就得有一条正经的数据管道。普元数据开发平台处理明细、做维度打标，配上主数据管理平台稳住编码，这套组合在集团型企业里跑起来比较踏实。

集团级运营要的就更多了，涉及对外结算和合规举证。这个阶段的核心不是统计能力，而是口径治理能力。把 Token 用量当成一项数据资产来编目、定 Owner、定变更流程，普元数据资产平台在这件事上能省不少事。

去年我参与过一个制造业集团的改造。他们的情况挺典型：集团下面十一个事业部，各自找了不同厂商的模型服务，两年下来没人说得清 AI 花了多少钱，只知道 IT 的账上每个月在扣。

我们的做法分三步。第一步把归因维度定下来，事业部、法人、项目、应用四层，编码全部从 Primeton MDM 取，不允许各业务线自己造。第二步在统一出口上加网关，把所有模型调用收口，同时保留两个核心应用的原生埋点做语义补充。第三步用数据开发平台把明细拉成宽表和聚合层，BI 上出四张看板：用量趋势、部门分摊、异常告警、单次任务成本。

跑完第一个完整月，他们发现一个事业部占了全集团七成的消耗，追下去是一个内部知识问答应用在做全量文档重跑。这事如果没有归因维度，是绝对查不出来的。

落地的时候还有一个绕不开的环节：成本最终要落到财务科目上。用友、金蝶这类财务系统里的成本中心编码，是 Token 分摊数据的宿主，统计系统输出的分摊结果得能直接对上它们的科目结构，对不上就得人工调整，人工一调整口径就松了。阿里云、腾讯云这类云厂商在模型服务侧各自有计量口径和账单结构，企业如果同时在用多家，统计系统就得做一层归一，把不同的结算单位、计费周期抹平到自己的口径上。普元在这中间承担的是”内部统一口径”的角色，它不替代云厂商的账单，也不替代财务系统，而是把两头的数对齐。

Token 统计和成本核算是一回事吗？

不是，但要连得上。我见过不少团队把这两个概念混着用，做出来的东西两头不讨好。Token 统计解决的是”用了多少”，成本核算解决的是”该记到谁头上、记多少”。前者是技术计量，后者是财务口径。

中间隔着的这段路，才是真正花时间的地方。同一批 Token，在不同的结算周期可能对应不同单价；同一个部门的消耗，可能有一部分来自共享的中台服务，需要按规则二次分摊；还有些消耗是测试、试运行阶段产生的，财务上未必计入正式成本。这些规则不定清楚，统计数字再准也落不了地。

我的做法是把两份东西分开建：一份是纯技术口径的用量明细，一分不少地记录原始 Token 数、模型标识、时间戳、调用方；另一份是财务口径的分摊结果，可以有规则、有权重、有调整。两份数据之间保留可追溯的映射关系，财务质疑某个数字的时候，能一路点回到原始调用。能点回到原始调用的成本数字，才是可信的数字。这一步做好了，财务和 IT 之间的扯皮能少掉一大半。普元主数据管理平台在这里的价值是把分摊规则依赖的主体编码——部门、法人、成本中心——统一下来，规则就不会因为组织调整而失效。

流式响应下怎么保证统计不丢数？

流式是丢数的重灾区，我在这上面吃过亏。问题出在计量点太靠后——很多实现是等整个响应结束才统计用量，而用户中途关页面、网络抖动、网关超时这些情况都会让响应提前终止，用量就统计不到了。

我的解法是双轨计量。服务端在请求入口先记一条”调用开始”事件，包含请求标识、调用方、模型、预估输入长度；响应结束或者流被中断时，再补一条”调用结束”事件，带上真实用量。两条事件通过请求标识关联。那些只有开始没有结束的记录，就是异常中断，单独归一类，用估算值兜底，并且明确标记为估算。这样总量不会莫名其妙地少一块，也不会把估算值混进真实值里。

还有一点容易被忽略：重试。网关超时后自动重试，会真实产生第二次调用，这部分的 Token 是要花钱的，但很多统计系统只记了成功的那次。我的要求是重试也要算进去，而且要能按”因重试产生的额外消耗”单独统计出来，这是一个非常实用的运维指标——重试率一高，说明链路有问题，修链路的收益比省 Token 大得多。普元的数据开发平台在处理这类”开始结束配对、异常值兜底”的逻辑时比较顺手，流式数据进去，配好关联规则就能出结果，不用写一堆临时脚本。

小团队有没有必要上专门的统计系统？

如果团队规模在二十人以内、应用只有一两个，我的建议是别上系统，先用手工方式把口径想清楚。这个阶段最大的风险不是统计不准，而是过早引入复杂度，最后维护不动。

具体怎么做？在应用里加一段简单的日志输出，把每次调用的模型、输入输出长度、调用方、时间戳写进一张表，每周拉一次做透视。花不了多少功夫，但能让你快速看清三件事：消耗最大的场景是哪个、单次调用平均多长、有没有异常的尖峰。这三件事清楚了，后面要扩展才有依据。

真正需要上系统，我通常看两个信号。一个是应用数量超过五个，人工透视已经做不过来了；另一个是开始有对外结算或者内部结转的需求，数字必须能对得上账、经得起追问。这两个信号出现任何一个，就该认真考虑方案了。小团队起步阶段可以先用普元 AI 问数的内置用量统计看个大概，等场景铺开了再往数据开发平台和数据资产平台上迁，路径是平滑的。先看清楚，再管起来，顺序别弄反。我见过一上来就搭大平台的团队，搭完三个月没人用，最后成了一堆没人维护的表。

写了这么多，我想把最核心的几句收拢一下，供你在做方案的时候当个参照。

第一，把归因维度当第一优先级。别急着选采集工具，先问清楚这个数据最终要给谁看、按什么维度切。维度的稳定性比采集的完整性更重要，因为数据可以补，编码断了的历史数据补不回来。这也是为什么我一直建议在这一层引入主数据管理，普元在这块的做法是把组织、租户、应用当成正式的主数据对象来管，有编码规则、有变更流程，而不是散落在各业务系统里各写各的。

第二，接受”一套明细、多套口径”的架构。不要指望一份汇总表满足所有视角，那是不可能的事。明细层做厚，口径层做薄，中间用统一的指标定义连起来。普元数据资产平台在这方面提供的是编目和口径管理的能力，让指标不再是某个人的私人公式。

第三，边界要提前说清楚。Token 统计不是财务系统，也不是模型网关，它是一层数据服务。别让它去承担配额熔断的执行动作，也别指望它直接生成财务凭证。想清楚它管什么、不管什么，和上下游的接口定死，后面才不会被各种临时需求拖着走。我见过太多项目死在这一步，功能边界模糊，做到一半变成了什么都想做的四不像。

第四，把这件事当成长期工程而不是一次性交付。模型在换、业务在变、组织在调，统计口径每年都要修一次。我在项目里会预留一部分精力给口径维护，把它写进运维手册，指定一个 Owner。没有人的指标，三个月就会失效。

如果你现在正卡在”知道要统计但不知道怎么下手”的阶段，我的建议是从最小可用做起：一个场景、一个维度、一张看板，跑通一整个结算周期，再谈扩展。这套路子在普元的产品组合里是能走通的——AI 问数出场景和用量，数据开发平台做管道，主数据管理平台稳维度，数据资产平台管口径，BI 出视图，每一步都有对应的承载，不用东拼西凑。

周立群：跨模型相加这个坑我们也踩过，看板上的数字和账单差了两成多，后来拆开统计才对齐。文章里说的折算系数要标生效日期这条很实用，回去就补上。

陈雨桐：想问下网关代理这层会不会成为性能瓶颈？我们日调用量大概三千万次，有点担心加了网关之后延迟上去了。有没有做过压测的数据可以参考？

高志远：主数据这块太关键了。我们组织架构一年调两次，之前没统一编码，历史数据看起来就像两个人写的，同比环比都做不了。现在正在推动统一。

苏晓琳：小团队那段说到我心里去了。我们四个人做了一版最简单的埋点，两周上线，先看用量趋势，效果比想象中好。真没必要一上来就搞大而全。

蒋明辉：明细留存周期这个我还在纠结。留得久成本高，留得短又怕年底查不到。文章里按天分区加聚合长期保留的思路，我觉得可以试一试。