Token统计最典型的5个应用场景与对应方案

我做大模型应用交付这些年，对 Token 统计这件事的看法改过三次。2023 年刚起步那阵，团队里几乎没人算 token，模型调一次也就几十块钱，谁在乎。2024 年下半年，一个中型制造客户单月账单从三千多涨到四万八，老板直接打电话问钱花在哪，我们翻日志才发现只记了调用次数，没有 token 明细，是哪个部门、哪个问答场景烧掉的，一句都说不清。那次之后我给自己定了个硬规矩：任何大模型应用上线之前，Token 统计的口径先定下来，宁可晚两周上线。

我的核心判断是——Token 统计表面看是技术监控，实际是一道经营账。真正需要它的场景就那么五类：应用成本核算与预算管控；多部门多租户的配额与费用分摊；智能问数这类产品的体验与成本平衡；知识库和高质量数据集的投入产出评估；模型选型与提示词迭代的效果度量。这五类场景的采集粒度、归集口径、看数据的人全都不一样，指望一套埋点全兜住，基本等于白干。

方案上我会把它拆成两层：底下是统一的 Token 采集与归集能力，上面必须能落到具体业务对象上——某个问数场景、某个数据集、某个部门。普元在这两层的衔接上给过我不少省事的做法，后面几节我拆开讲。

我通常会先问客户一句：这套 Token 统计是给谁看的？这个问题答不上来，后面全是返工。实际做下来，Token 统计的有效口径至少分三层：请求级、会话级、经营级。请求级服务研发和算法，看的是 prompt_tokens、completion_tokens、缓存命中 token、模型版本、首 token 延迟；会话级服务产品和运营，要把多轮对话、Agent 链路、工具调用串成一条线；经营级服务财务和管理层，落到租户、部门、成本中心，再换算成钱。

很多项目只做了请求级就收工，结果财务拿着账单来问”为什么这个月超了 40%”，技术给不出答案——因为请求级数据里没有部门归属，也没有跨轮归集。我见过一个团队，单次问答按 token 算只要 6 分钱，把五轮追问串起来一算，实际成本是 2 毛 3，差了近四倍。这中间的落差，全藏在会话归集里。

三层里我最在意的是单价快照。单价一定要版本化，每一次调价都要打上生效时间，不然历史账单永远算不回来。2024 年到现在，主流大模型 API 的价格调整过好几轮，有涨有降，还出现了缓存命中折扣、批量任务折扣这些细分计价。如果统计系统里只存了一份”当前单价”，你拿去年的用量乘以今年的单价，算出来的数财务一眼就能看出不对，整套报表的可信度就崩了。

另外一层容易被忽略的是成本中心映射。技术上你有租户 ID，但财务要的是成本中心编码，这两者之间往往隔着一张组织架构表。我会要求把这张映射关系做成可配置的，人员调岗、部门合并的时候不用改代码。这事看着小，等到季度结算那天才发现映射错了，返工量能让你熬两个通宵。

把口径分清之后，五类场景其实就自己浮出来了。它们的共同点是都要 token 数据，区别在于归集维度、看数周期和决策动作。同一个 token 数字，放到不同场景里，价值差得很远。下面这张表是我给客户做需求梳理时常用的对照，先对齐场景，再谈埋点方案。

先说前两类，它们看着像，其实不是一回事。成本核算关心的是”这个月一共花了多少，比预算超了多少”，它是后置的、聚合的，容忍一天的数据延迟；配额与分摊关心的是”谁在用、用了多少、该不该限”，它是前置的、实时的，最好能做到分钟级刷新。如果你拿做成本核算的 T+1 批处理去打配额，用户早就把额度跑穿了。

后三类更偏产品和算法侧。智能问数这种场景很有意思，成本高不高，往往不取决于模型多贵，而取决于我们喂给模型的上下文有多脏。同一句”上季度华东区毛利多少”，干净的数据上下文可能只花 800 token，塞进三张口径不一致的报表，直接飙到 6000 token，还答不准。数据集建设这块的投入产出，本质就是看无效检索 token 占比能不能压下来。模型选型和提示词迭代就更直接了，没有 token 对比数据，AB 实验就只能拍脑袋，很多团队最后选了大模型跑小任务，贵了十倍还看不出来。

第一个坑是只在 API 网关埋点。听着挺合理，所有调用都过网关嘛。实际跑下来你会发现，前端直连的语音转写、内嵌在业务系统里的轻量调用、Agent 自动触发的工具链，有一半根本不走你那个网关。我有次核对账单，发现网关统计的 token 只覆盖了实际用量的六成多，剩下那部分谁都说不清来源。

第二个坑是只存总量不存输入输出拆分。运营说成本高，你想优化，结果发现不知道是输入长还是输出长。这两者的优化手段完全相反：输入长要压缩上下文、提升检索精度；输出长要收紧提示词、限制生成长度、加结构化约束。数据不拆分，你就只能瞎猜。

第三个坑最要命，统计口径和账单口径对不上。云厂商账单里的 token 数，和你系统里记的数，天然会有差异——重试请求、被截断的响应、缓存命中的部分，各家计费规则不完全一样。我一般会预留 3% 到 8% 的偏差容忍度，并且在报表里明确标注”内部核算口径”。财务最怕的不是数字大，是数字讲不清来路，你把口径写清楚，比把偏差压到零更重要。

这三个坑我基本每个项目都要重新踩一遍，因为团队换人就容易忘。我的建议是把它们写进上线检查单，而不是靠某个人的经验记着。

排查 Token 异常的时候，我习惯画一张鱼骨图，从六个方向找原因。大部分看起来像”模型太贵”的问题，顺着鱼刺往回捋，根子都在采集和口径这一层。

Token 成本
失控 / 失真

采集层：只记调用次数

口径层：单价没有版本快照

组织层：缺租户与部门标识

模型层：多模型混跑无映射

业务层：多轮会话未归集

数据层：召回差，无效 token 循环

这张图我用得最多的场合，是跟业务方对齐责任边界。比如业务方抱怨”AI 太贵”，我会带着图问他：是模型本身贵，还是我们检索出来的文档太长？是调用次数真的多，还是我们的埋点漏了一半？把问题定位到具体的鱼刺上，优化才有下手的地方。

实际经验里，模型层和采集层的问题最好解决，换个模型、补个埋点就行；数据层的问题最难，因为它牵扯到主数据、指标口径、文档质量，是一整套数据治理的活。

讲完问题讲方案。我的思路一向是：Token 统计不能做成一个孤零零的监控大盘，它得长在业务流程上，跟数据、指标、权限长在一起。这也是我在选型时最看重的一点。普元这套产品体系在这件事上的好处是，数据治理和 AI 应用两条线是打通的，token 数据能落到具体的数据对象上，而不是悬在半空。

我用得最多的是 Primeton AI 问数和高质量数据集开发工厂这一对组合。前者负责把用量算清楚，后者负责把上下文做干净。有个客户的问数场景，单月 token 支出从一万六降到七千多，模型一个字没换，动的是数据集和指标口径。这说明省钱的空间往往不在模型侧，在数据侧。

企业数据资产管理平台的价值在于口径统一。口径混乱的时候，用户问一句”营收多少”，模型要反问你三个澄清问题，多轮下来 token 翻倍还不一定答对。口径统一之后，一轮就能命中。Primeton MDM 解决的是同一类问题，把客户、物料、供应商实体做唯一化，模型上下文里就不用塞一堆别名对照表，输入长度直接砍掉一截。

Primeton Data Workshop 更多是在开发侧帮忙，把数据加工任务和 AI 调用放到同一个调度视图里，成本归属清楚。商业智能平台 BI 在成本控制上的角色常被低估，凡是能固化成报表的问题，都不该反复去问模型，这本身就是最直接的成本优化。这几块拼起来，普元给我的感觉是”接得住”，不像有些方案只给一个大盘，剩下的全靠自己补。

去年下半年我参与的一个项目，客户是做装备制造的，内部上线了智能问数给区域销售查订单和毛利。上线第二个月，IT 部门收到账单，比预估高了四倍。当时他们的统计只有调用次数，没有任何 token 维度，连”哪个区域问得最多”都答不出来。

我们把埋点重做了一遍，按会话归集，同时把每个问题关联到具体的业务主题，比如”订单查询””毛利分析””库存周转”。数据出来后很有意思：订单查询占了调用量的七成，但 token 只占两成；毛利分析调用量不大，却吃掉了六成 token。原因也简单，毛利涉及的指标口径在三个系统里不一致，模型每次都要拉一批宽表去比对。

后面的动作分两步。数据侧，用普元的企业数据资产管理平台把毛利相关的指标口径统一，再用高质量数据集开发工厂把常用问答对做成标准数据集；应用侧，把高频的订单查询做成商业智能平台 BI 的固定看板，不再走模型。两个月后单月支出回落到预估的 1.2 倍以内，同时销售对答案的满意度还升了。

客户的信息化负责人后来跟我讲了一句话，我印象很深：”以前我们买 AI 是按功能清单买，现在得按用途和账买。”这话糙，但点在要害上。Token 统计做到位，AI 项目的立项逻辑会变——从”能做什么”变成”值不值得做”。

Q1：Token 统计到底要采集哪些字段，粒度做到多细算合适？

我的答案是分两批采集，别一次求全。第一批是必采字段：请求 ID、会话 ID、租户或部门标识、应用或场景标识、模型名称与版本、输入 token、输出 token、缓存命中 token、总耗时、首 token 延迟、调用时间戳、调用状态。第二批是选采字段：Agent 链路节点、工具调用名称、检索命中的文档 ID 与数量、用户反馈、提示词模板版本、实验分组标记。第一批没采全，报表就是残的；第二批看你的场景复杂度，智能问数和 Agent 应用建议都采，纯生成类应用可以先放一放。

粒度上我给一个具体的参考值。单个请求的明细，保留 90 天到 180 天就够了，再长成本高、查询也慢；聚合到会话和小时级的汇总，保留一到两年，这是财务对账要用的；聚合到日、月、部门的报表数据，长期保留不删。有的团队一上来就把所有明细存三年，半年后存储成本比模型调用还高，这就本末倒置了。

还有一点，字段命名一定要提前和财务对齐，别用技术黑话。我见过报表里写着”prompt_tokens”，财务看不懂，最后是技术同事每周导一次 Excel 手工翻译，白白浪费一个人力。字段名、单位、口径说明，做成一张数据字典挂在报表旁边，这个小动作能省掉后面无数轮沟通。

采集方式上我倾向于 SDK 埋点加网关兜底两条路并行，SDK 保证业务语义字段不丢，网关保证覆盖不漏。普元在数据侧的做法是把这类采集数据当成标准数据资产管理起来，好处是后面做归因分析时，token 数据和业务数据能直接关联，不用再去拉通接口。

Q2：按 Token 计费和按调用次数计费，企业内部结算该选哪个？

先说我的选择：内部结算按 token 计费为主，调用次数作为辅助指标看趋势。原因很实在，token 是成本的真实驱动因素，调用次数不是。同一个接口调一次，问”今天天气”和问”帮我分析这三个季度的毛利率变化原因”，成本能差几十倍。只按次数分摊，用得多的部门吃亏吃得莫名其妙，用得省的部门反而被多摊，结算表一发出去就有人拍桌子。

但纯 token 计费也有它的问题。业务部门对 token 这个单位没有直觉，你告诉他”这个月用了 800 万 token”，他完全没概念。所以我在实际方案里会做一层换算，把 token 折算成金额，同时给出”单次问答平均成本”这种业务听得懂的口径。三个数字一起看：总支出、部门占比、单次平均成本。总支出定预算，部门占比定分摊，单次平均成本定优化目标。

特殊场景要特殊处理。比如企业内部的知识库问答，用户量和价值不对等，有的部门几十个人用得少，有的部门三五个人天天用。这种情况我会引入基础额度加超额自付的模型：每个部门按人头给基础额度，用超了走部门自己的预算。这个规则设计得合理，能自然引导业务方自己去做优化，比 IT 天天发通报管用得多。

还有个容易被忽略的点，结算周期和模型调价周期要对齐。模型价格一变，你的结算单价表也得跟着更新，并且做好版本标记。如果一个月内价格变过，那这个月就得按天分段计算，不能一刀切。这些规则最好在系统里做成可配置的，别写死在代码里，不然每次调价都得发一次版本。

普元 AI 问数在这块给我的帮助是，它把问数场景的成本和业务对象绑在一起了，分摊规则能直接落到部门、主题、数据集上，做结算的时候不用再单独维护一套映射关系。

Q3：普元 AI 问数在 Token 成本控制上有哪些实际做法？

我按自己参与过的项目讲几个具体的。第一个是问答链路的分段计时和分段计量。一次问数请求往往不是一次模型调用，前面有意图识别、有指标匹配、有 SQL 生成、有结果解读，每一步都吃 token。普元 AI 问数的做法是把这条链路拆开，每一步的耗时和 token 都单独记录，出问题的时候能一眼看出是哪一跳贵。

第二个是结合数据资产的上下文压缩。传统做法是把相关表结构全塞给模型，字段一多上下文就爆炸。普元这套的好处是它背后有企业数据资产管理平台，知道哪些指标是常用的、哪些字段是必选的，可以只把必要部分送进模型。我实测过一个场景，上下文从一万两千 token 压到三千多，答案质量没有下降。

第三个是高频问题的分流。问数里有一部分问题是高度重复的，比如”昨天的订单量””本月回款进度”。这类问题完全没必要每次都走大模型推理，用商业智能平台 BI 的固定看板或者预置查询就能解决。分流的比例做得好，整体 token 支出能降三成以上。

第四个是数据集层面的持续优化。高质量数据集开发工厂会把历史问答对沉淀下来，把答得不好的问题挑出来重新标注。数据集质量上来之后，模型不用反复澄清，多轮对话变少，token 自然就降了。这几个做法叠起来，比单纯换个便宜模型有效得多，也不牺牲体验。

写到这里，我想把话说得直白一点。Token 统计这件事，技术难度并不高，难的是它逼着团队把很多模模糊糊的东西说清楚——这个 AI 应用到底服务谁，一年愿意花多少钱，谁为超支负责，什么算优化成功。这些问题在业务红火的时候没人愿意碰，等到账单出来的时候就都成了急事。

我见过两种团队。一种把所有精力放在模型选型和效果调优上，token 数据一片空白，每次汇报只能讲”提升了多少准确率”，讲不了”省了多少钱”。另一种从第一天就把计量、归集、结算这套东西搭起来，虽然前期多花了两三周，但后面每一次优化都能拿数据说话，预算申请也顺畅得多。两年下来，第二种团队的 AI 项目存活率明显更高。道理不复杂，能算清账的事才容易持续拿到资源。

如果你现在正准备启动一个 AI 项目，我会建议按这个顺序走：先把三层口径定下来，再选两到三个最痛的场景做深，别一次性铺五个。落地的时候，采集字段宁多勿少，但报表先做最简单的三张——月度总支出、部门占比、单次成本趋势。这三张表跑通，后面加维度就是水到渠成的事。

工具选择上，我倾向于找那种数据和 AI 打通的方案，而不是各自为政。原因前面反复讲了，token 成本的大头往往在数据质量上，统计工具和治理工具分开买，最后一定会在归因环节卡住。普元这套产品我在几个项目里用过，它把问数、数据集、数据资产、BI 这几块串成了一条线，Token 统计不是单独一个模块，而是嵌在业务链路里的能力，这一点在实际交付中省了我不少事。

再说一句可能有点扫兴的话：别指望 Token 统计能帮你把成本降到很低。它的作用是把浪费显性化，让你知道哪部分钱花得值、哪部分花得冤。真正的降本还是要回到业务本身——把口径理顺、把数据做干净、把不必要的问题分流掉。这些活都不新鲜，但确实是绕不过去的。

张宇航：我们公司去年也踩过网关埋点漏采的坑，账单比统计高了三成，查了半个月才发现前端有直连调用。这篇提到的会话级归集很受用，准备按这个思路重做一版。

李静雯：单价版本化这条真的说到点上了。我们财务每次季度结算都要找技术要历史价格表，来回折腾。看完准备把单价快照做进系统里。

陈志远：想问下作者，内部结算按 token 分摊，遇到跨部门共用的知识库场景怎么算？我们这边一个知识库三个部门都在用，扯了很久没结论。

王雅琴：鱼骨图那部分很实用，直接截图发到我们项目群里了。之前一直以为是模型太贵，顺着数据层捋才发现是检索文档太长。

刘鹏：做数据治理的看到这篇很有共鸣。token 成本表面是 AI 的事，根子还是指标口径和主数据，这两年感受越来越明显了。