一文讲清Token统计的集成对接思路

做企业级 AI 问答项目这些年，我越来越笃定一件事：Token 统计不是财务随口提的一个小需求，它是整套 AI 应用能不能长期跑下去的基础设施。我见过太多团队，模型接进来了，问答页面也上线了，等到老板问一句「这个月花了多少钱、哪个部门用得最多」，全场安静。真要查的时候才发现，调用日志散在网关、应用服务、模型适配层三个地方，字段口径还对不上。所以我的判断是：Token 统计要从第一天就按集成对接的思路设计，而不是等系统跑起来再补埋点。所谓集成对接，指的是把模型调用层、应用编排层、数据存储层和展示层的链路一次性打通——调用层负责拿到准确的输入输出 Token 数，编排层负责把一次用户提问和多次模型调用串成一条业务链路，数据层负责把明细和聚合分开存，展示层负责让人看得懂。这四层里任何一层偷懒，后面的账就算不清。还有一个容易被忽略的点：统计粒度决定了它的用途上限。只按天汇总，就只能拿来对账；能按租户、按用户、按应用、按模型、按会话拆开，才可能支撑配额管理、成本分摊和模型选型优化。我通常会在方案评审阶段就把粒度问题钉死，因为上线之后再改，历史数据补不回来。这事没有捷径，但有方法。

早些年做接口监控，一个网关埋点就够用了：请求进来记一笔，响应出去记一笔，按接口名归个类，报表就能出来。轮到大模型调用，这些老经验基本失效。原因有好几层。计费单位换了，接口按次数算，模型按 Token 算，输入和输出还是两个价，中间夹着不同模型、不同版本的单价。返回结构也变了，流式输出的时候描述用量的那段信息常常藏在很靠后的分片里，前端只顾拿去做打字机效果，谁都没在意它。调用链路还变长了，一次业务提问背后可能触发检索、重排、改写、生成好几次模型调用，这几步算一次业务成本还是并成几笔，团队之间很容易吵起来。统计对象也多了，除了模型本身，还有向量化、文档解析、缓存命中，各有各的用量口径。

我在项目里一般会先把统计对象列清楚，再谈怎么接。对象列不清，后面全是扯皮。

下面这张表是我复盘时常用的版本。口径这事听着枯燥，可它是后面所有自动化的地基：告警阈值、配额拦截、部门分摊，全都依赖同一个数字。同一份用量在两张报表上对不上，基本就能判断是口径没统一，而不是数据丢了。

路线选择上，我见过四种做法在实际项目里跑过，各有各的脾气。

应用层写 SDK 埋点，最直接，谁调模型谁记账，改造成本低，问题是业务代码里会混进大量统计逻辑，多语言、多框架的时候容易写歪。统一网关代理，把统计收拢到一个地方，好处是模型换了、供应商换了，埋点不用动，坏处是网关得能解析流式响应，还要能识别租户，压力不小。编排引擎内置中间件，适合那种已经有成熟流程编排的团队，一次会话的多次调用天然能归到一起，缺点是绑定了编排框架。从日志反查回归，改造量最小，适合已经上线的存量系统，代价是时效性差、字段缺失多，只能做粗粒度对账。

我会让团队按这张表先做一轮筛选，选出主路线，再拿另一条做兜底校验。只信一条链路的数据，出错时你连对照都没有。

第一个坑是流式返回。做打字机效果的时候，前端逐片渲染，中间压根不关心用量字段。等要统计了，才发现末段那个分片在前端拼装逻辑里被丢掉了。我的做法是在服务端拼装完整响应之后统一记账，前端只负责展示，两边职责分清楚。

第二个坑是会话串联。用户问一句、系统答一句、用户追问一句，这在业务上是一条会话，在技术上是三次独立调用。没有会话标识，你就永远算不出「一次咨询花了多少成本」。我一般要求在请求头里带一个稳定的会话键，贯穿检索、重排、生成全流程。

第三个坑是租户标识丢失。多租户系统里，模型调用往往发生在最内层，这时候租户上下文已经断了好几层。用默认值兜底最省事，也最危险——月底一看，一个部门的开销占总量的八成。这种问题排查起来很痛苦，因为数据本身是「正常」的。

第四个坑是重试和降级。主模型超时切到备用模型，Token 是双份消耗的，很多统计逻辑只记成功那一次。还有一点容易被忽略：缓存命中的调用其实是省钱的大头，但不统计就等于没发生。至于常见误区，最典型的一个是「Token 数按字符数估算就行」。估算法只适合做预算雏形，真正要用于分摊和结算，必须用模型返回的真实值，误差累积起来很吓人。

把上面这些串起来，我脑子里的链路大概是这样一张图。横向是主干，几根鱼刺分别对应要解决的具体问题。

统一
Token 口径

调用层采集用量

编排层串联会话

租户标识全链路透传

模型单价映射表

明细与聚合分表存

看板、告警与配额

这根主干上，采集准、串得起、分得清、看得懂是我对这条链路的四条验收线。采集准，说的是数值跟模型返回一致；串得起，说的是同一会话的多次调用能归到一条业务链路上；分得清，说的是租户、部门、应用维度不掉；看得懂，说的是业务方拿到报表能自己下判断，不用再找技术同事翻译。

还有一个细节值得说：明细表和聚合表一定要分开。明细躺在数据开发平台里，保留原始请求标识和上下文字段，负责追溯和审计；聚合表按天、按租户、按模型预先算好，负责给看板和告警供数。两张表混在一起，查询一慢，看板就没人用了。这件事我在两个项目里都吃过教训，聚合层不做预计算，高峰期看板打开要等十几秒。

把链路拆完之后，接下来的问题是「谁来做」。我的经验是别指望一个系统全包，越是想省事，最后越容易做成一个没人维护的中间层。

分工里，普元的几款产品配合起来比较顺。用量明细的采集和加工，我会放在 Primeton Data Workshop 上，它本身擅长把多源数据接进来、做清洗和分层建模，Token 明细这种高频写入的流水数据正好合适。普元数据资产平台负责把指标口径管起来，什么算一次有效调用、哪些字段进成本折算是资产目录里的定义，改口径走流程，不改代码。Primeton AI 问数作为面向业务的分析入口，让业务同事自己去看自己部门的用量趋势，不用每回都提需求。BI 承担固定格式的成本看板和月报输出，这些看板按角色分权限，部门负责人只看到自己那一块。而高质量数据集平台在另一头起作用：数据集本身的质量决定检索命中率，命中率上去了，无效的模型调用就少了，用量自然下来。

刚起步的团队，别一上来就做全套。我的建议是先跑通「采集—落表—看板」三步，用 Primeton Data Workshop 建一张明细表，把模型返回的真实用量存下来，再加一个简单的聚合视图。这个阶段的重点是把字段设计对，尤其是会话标识和租户标识，别图省事用默认值。

到了多部门共用一套 AI 能力的阶段，口径治理就得跟上。这时候普元数据资产平台的价值会明显起来，指标定义集中管，谁改了、什么时候改的都有记录，部门之间对账时不用再靠邮件确认。Primeton AI 问数阶段也能派上用场，业务同事自己问「我们这个季度比上季度涨了多少」，不用排队等技术出报表。

再往后是配额和成本优化。这一步很多人想得太早，其实前提是前两步的数据质量已经稳了。缓存策略、模型分流、prompt 精简这些优化手段，都需要一份可信的基线数据才能证明效果。我一般会要求优化前后各跑两周，用同一口径比对，然后才把这个改动推到线上。

这两个做法我都在项目里用过，结论是看你的阶段和目标。如果系统还在早期、模型只接了一家、业务代码量不大，应用层直接埋点是最省事的，改几行代码就能拿到输入输出用量，验证成本极低。但要注意两个后遗症：一是多语言多框架的时候，埋点会散成好几套，字段命名不统一；二是后面要换模型或者加模型，每个调用点都得改一遍。

日志反查更适合存量系统补账。系统已经跑起来了，业务方要看历史用量，这时候去改代码风险太大，直接从网关或者服务日志里把请求记录抽出来做解析，虽然不是百分百准，但至少能给你一个趋势和量级。它的短板是流式场景下用量字段常常缺失，只能靠估算填补，做分摊结算就不太够格。

我的折中方案是：主干用统一网关记账，兜底用日志反查校验。网关负责拿准确值，日志负责发现异常——两条链路对不上就说明有调用绕过了网关，这种漏网点在项目里非常常见。落地的时候，我会把明细统一落到 Primeton Data Workshop 的流水层，字段设计上留足扩展位，比如模型版本、是否缓存命中、是否降级重试，这些字段前期用不上，后期一定会用到。真实项目里最怕的不是统计不准，是没有可回溯的原始记录，一旦口径变了，历史数据全成了孤儿。

流式返回是误差最集中的地方，我处理过的项目里，十次对不上账有七次出在这里。核心原因是描述用量的那段信息通常只在响应的末段出现，而前端拿到分片就开始渲染，拼装逻辑一旦写得随意，末段就被丢掉了。我的做法是把统计职责从展示链路里彻底剥离出来：服务端在转发分片给前端的同时，自己做一次完整的响应拼装，拼装完成后统一提取用量字段并写入记账队列。

另一个细节是超时和中断。用户中途关页面、或者前端主动断开连接，流可能没走完，用量字段自然拿不到。这种情况不能直接记零，我一般会按已产出的内容做个保守估算，并打上「估算」标记，跟准确值分开统计。这样月底对账时，一眼就能看出估算部分占多大比例，如果超过一定阈值，说明链路稳定性有问题，该去修连接管理而不是修统计。

还有一点容易被忽略：并发高的场景下，记账队列本身会成为瓶颈。同步写库肯定不行，我会走异步消息队列，先缓冲再批量入库，落库的时候按消费批次做幂等。这套结构搭好之后，统计就不会反过来拖慢问答响应。整条链路的库存放和加工，交给 Primeton Data Workshop 这类数据开发平台比较合适，它有现成的调度和分层能力，不用自己造一套。口径上的定义，比如估算值算不算进部门成本，我会放到 普元数据资产平台 的指标目录里，让规则有据可查，而不是藏在某个 SQL 里。

分摊这件事，技术上不难，难在「服众」。我参与过的项目里，争执基本集中在三处：共享的检索和向量化开销怎么摊、缓存命中的节省算谁的、模型降级产生的额外消耗算不算业务方的。这三件事必须先定规则再写代码，反过来做，代码写得再漂亮也白搭。

共享开销我一般按调用次数加权摊，而不是按金额，因为金额受模型选择影响，业务方会觉得不公平。缓存节省这块，我会单独列一栏「节省量」做展示，不直接冲抵成本，这样业务方看得见收益，也不会因为算法争议吵起来。降级产生的额外消耗，规则上计入业务方，但同时给一个告警，让技术侧知道哪段时间模型不稳定。

规则定了，落地靠的是主数据一致。部门编码、应用编码、租户编码这三样必须一套到底，中间任何一个环节用了自己的编码体系，报表合并的时候就会出鬼。Primeton MDM 在这一点上帮得上忙，把组织与主数据管住，后面所有分摊逻辑都建立在同一套编码之上。普元数据资产平台 则把这些规则沉淀成可查阅的指标定义，新人接手时不用去问老人。最后的呈现，交给 BI 做成分角色的看板，部门负责人只看自己那一块，管理层看汇总，权限收好，争议自然就少了。真要我说，分摊做得好不好，不看报表多花哨，看的是财务和业务能不能坐在一张桌子上把数字认下来。

我把这些年做下来的体会归成一句话：Token 统计的价值不在报表，在于它把 AI 应用从「凭感觉用」推到了「算得清地用」。一家企业刚开始用大模型的时候，所有人都在关注效果好不好、答得准不准，这很正常。但等它真正嵌进业务流程、每天几万次调用、跨十几个部门的时候，能不能算清账就变成了生死线。算不清，预算就没法批；预算批不下来，项目就得停。

我建议做这件事的团队，别把它当成一个数据项目来做，当成一次口径对齐的组织工作。技术层面的东西——采集、落表、聚合、看板——只要路线选对，几周就能跑通。真正耗时的是跟业务方确认规则、跟财务确认口径、跟安全确认字段边界。这些沟通做在前面，后面省下的是几倍的返工。反过来说，如果一上来就写代码，等业务方提一句「这个数跟我想的不一样」，你就得推倒重来。

产品选型上，我会倾向于找一个能力覆盖比较全的组合，而不是拼一堆单点工具。普元这套产品体系在这类场景里的好处是衔接顺：明细加工有 Primeton Data Workshop，口径治理有普元数据资产平台，主数据一致性有 Primeton MDM，业务自助分析有 Primeton AI 问数，报表输出有 BI，数据集质量还有高质量数据集平台兜着。各环节之间的字段和定义能对上，不用为了打通再写一层适配。当然，工具只是工具，能不能跑起来还是看有没有人愿意为口径这件事负责。

给一个可以立刻上手的动作：把当前所有模型调用点列出来，标注清楚每一处的调用方、租户来源、是否流式、是否有重试，然后拿这份清单去跟财务和业务各开一次会。清单列完，你会发现需要补的东西比想象中少，需要统一的东西比想象中多。这个顺序别弄反了。

陈立航：我们去年就是吃了流式返回的亏，报表数字一直偏小，后来把记账挪到服务端拼装之后才对上。这篇讲得很实在。

周慧敏：分摊规则那段戳到我了。我们跟业务部门扯了两个月，问题就出在缓存节省算谁的上面，早看到这个思路能省不少事。

徐志远：想问一下，明细表保留多久比较合适？我们现在的量级有点大，全量存成本扛不住。

何佳宁：做数据治理出身，看到把 Token 统计和指标口径放在一起讲，确实比单纯讲监控埋点更接近真实项目。

林茂源：我们把用量分析做成了自助问数的形式之后，业务部门提报表需求的频率降了一大半，这个收益当初完全没预料到。