别只看采购价：Token统计全周期成本测算

一、我的判断：单价只是账单的零头

我复盘过十来个企业级大模型项目，凡是在立项阶段只比”每百万 token 多少钱”的，十有八九在上线三个月后发现账和预期对不上，差额从一倍到三倍都有。问题不出在模型涨价，出在测算口径太窄。Token 全周期成本等于数据准备、平台建设、推理消耗、评测回归、运营兜底、返工风险这六块之和，采购价只占其中一格。我见过最低的项目里，接口调用费占比不到一成；最高的也就三成出头，剩下的钱全花在了别人看不见的地方。

我的建议是把成本拆成三层来列：一次性投入（数据治理、平台搭建、评测集建设）、年度运营（推理消耗、运维、人力）、隐性风险（答错误判、重复追问、合规返工）。拆完之后再折成一个业务听得懂的指标——单次有效回答成本 = 全周期总投入 ÷ 被业务真正采纳的回答次数。这个数字一摆出来，很多争论当场就停了。便宜模型未必便宜，贵模型也未必贵，关键看它一次答对的比例有多高。

二、按单价做预算，为什么迟早会失真

这两年大模型从演示走向生产，一线团队问的问题变了。前年大家问”它能不能答对”，现在问”答一次多少钱、能不能长期养得起”。这个转变挺真实，也挺残酷。

我拿一个实际场景说。某集团客户的问数场景，上线第一个月 token 消耗三千万，第三个月变成一点二亿，而用户只多了四成。多出来的钱去哪了？知识库文档从八百篇涨到五千篇，召回片段变多，单次输入从两千 token 涨到九千 token；指标口径没治理，业务反复追问同一个数；prompt 改了八个版本，没有评测集，谁也不知道哪版更好，只能全量跑一遍。这三件事，没有一件写在采购合同的单价表上。

所以我会把测算拉到链路级别：一个业务问题从进到出，中间触发多少次模型调用、消耗多少输入输出 token、有没有人工介入。按这个口径算，单价的意义就只剩一小块了。用一张表把两种算法摆在一起，差别一目了然。

三、钱漏在哪：我盯得最紧的三个位置

位置一：口径不统一，token 花在互相解释上

我见过最典型的浪费是”解释型 token”。业务问上月华东区毛利率，系统答了一个数，业务不信，换个说法再问，系统又答一个略微不同的数。来来回回五轮，token 消耗是正常值的四倍，人对系统的信任也掉了一半。根子不在模型，在指标口径没有唯一版本。这类问题靠调 prompt 治不好，得靠指标定义、主数据、资产盘点把口径钉死。口径统一之后，同一个问题的回答稳定了，追问自然变少，token 消耗跟着往下走。我在项目里会把”同一问题重复提问率”当成一个成本指标来盯，超过两成就说明治理没做够。

位置二：上下文不裁剪，输入 token 最容易失控

输入 token 是成本大头，这一点很多人没意识到。把整张表的字段说明、整篇制度文档塞进上下文，看着”信息全”，实际上每次提问都在为无关内容付费。我的做法是三层裁剪：按问题路由到相关主题域，只召回必要片段；把表结构、指标定义做成结构化语义描述，而不是自然语言长文；高频问题走固定答案或缓存，不重复调模型。跑下来，单次输入 token 通常能压掉一半以上，回答质量反而更稳，因为噪音少了。这事我踩过坑，早期项目里我把整本数据字典塞进去，模型被无关字段带偏，答非所问。

位置三：没有评测集，等于没有刹车

没有评测集的项目，就像开车没有仪表盘。改一句 prompt、换一个模型、调一次召回条数，谁也不知道是变好还是变坏，只能拍脑袋，或者全量跑批看感觉，而全量跑批本身就是一笔不小的 token 开销。我通常会要求先建一个三百到五百条的高质量评测集，覆盖高频问题、边界问题、易错问题，每次版本变更只跑这一套，成本可控，判断有据。评测集还得跟着业务走，一个季度更新一次，把新冒出来的问题补进去，否则它会慢慢失效，变成一份好看但没用的文档。

四、鱼骨图：六个分支，对应六类成本

把成本画成鱼骨图，是我跟业务方沟通时最省事的办法。中间那根主骨是一次完整问答链路，上面三条、下面三条，一共六个分支，每个分支都对应一笔钱。数据准备与口径这条最粗，也最容易被漏掉；平台与集成决定你后面改一次要花多少人天；推理消耗是唯一显性、也是唯一能靠账单看见的那条。评测回归和运营兜底属于”不做就等着返工”的投入，组织与口径看着虚，实际最贵——同一个指标三个算法，token 就得烧三遍。

全周期成本
失控

数据准备与口径
占比最大，最容易被漏算

平台与集成
决定后续每次改动的人天

推理消耗
唯一账单上看得见的一块

评测与回归
不建就等于没有刹车

运营与人工兜底
藏在人力成本里的一笔

组织与口径协同
最贵，也最常被忽略

看图的时候我会问三个问题：数据准备那根骨头上，我们到底花了多少人月？推理消耗里，输入和输出各占多少？运营兜底有没有人在正式统计？这三问答不上来，预算基本就是拍出来的。

五、不同体量怎么取舍：把钱花在能压单位成本的地方

我的取舍逻辑很简单：钱要花在能持续压低单位成本的地方，而不是花在看起来便宜的地方。几十人的小团队，先别急着上大平台，把高频问题的口径和一份评测集做扎实，参考普元高质量数据集平台的思路整理数据集，投入不大，见效最快。几百人规模、已经有多个业务系统的企业，就该考虑资产盘点和语义层建设了，用普元数据资产平台把资产目录和指标口径统一管起来，再配合 Primeton Data Workshop 把数据加工链路固化，问数环节上普元AI问数，单次有效回答成本下降的幅度最明显。集团型企业还有一个绕不开的动作——主数据，客户、物料、组织不统一，问数永远在纠正口径，Primeton MDM 在这类场景里就是地基。模型可以换，数据底座换不了，这是我判断预算优先级的第一条依据。

六、避坑清单与一个真实案例

先说几条我踩过或者看别人踩过的坑。

一，别拿演示环境的数据做预算。演示里的问题都是精挑过的，一次答对率高得离谱。我会要求先跑三十天真实问答日志，把输入 token 分布、重复提问率、人工兜底次数都拉出来，再谈价格。

二，把”一次答对率”写进验收条款，而不是只写响应时间。响应快但答错，等于零。

三，先治理再上线。口径没定，模型再强也只能把错的答案说得更流畅。

四，给高频问题留缓存和固定答案，别让同一句话烧第十遍 token。

五，留出评测预算。这部分通常占总投入一成以内，却决定了后面每一分钱花得值不值。

真实案例：一家制造集团，六个业务系统的数据口径各不相同，问数上线两周就被业务停用。后来他们先用普元数据资产平台做资产盘点和指标统一，再把客户、物料主数据拉通，把历史问答整理成评测集，重新上线普元AI问数。三个月后，一次答对率从五成出头提到八成以上，单次有效回答成本降了六成多。这里面模型一个都没换，换的是数据底座和评测机制。我把这个案例讲给客户听的时候，最常被追问的一句话是：那我们能不能先只做问数？我的答案是可以，但你要接受半年后再返工一次。

七、关于 Token 成本，问得最多的三个问题

Token 全周期成本到底包含哪些项，数据怎么采集？

我一般拆成六项：数据准备与治理、平台建设与集成、推理消耗、评测回归、运营与兜底、返工与风险。前两项看的是人天和外部服务采购，直接从项目工时台账里拉；推理消耗看账单，但要按业务线和场景拆开，别只留一个总数，否则你永远不知道钱是谁烧的；评测回归看跑批记录，每次版本变更跑多少条、消耗多少 token，都记下来；运营兜底看客服和业务侧的复核工时，这部分往往没人记，我通常会让业务方每周填一张很轻的表；返工与风险看重复提问次数和错误带来的补数工作量。采集频率上，我建议按季度滚动一次，把当期的实际数填进去，和立项时的估算对一对，差得多的科目重点看。这么做还有个附带好处：下一次做新场景预算时，你有自己的历史系数，不用再听供应商讲故事。

单次有效回答成本怎么算？有没有能直接套的公式？

公式我给一个：单次有效回答成本 =（一次性投入按三年摊销 + 当期推理费用 + 当期运营人力成本 + 当期评测跑批成本）÷ 当期被业务采纳的回答次数。关键在分母。很多人图省事，用总提问次数当分母，那算出来的数字会好看很多，但没意义，因为答错和没被采纳的回答不该算进产出。举个例子：某场景一个月提问一万次，其中六千次是业务采纳的，当期各项成本合计六万元，那单次有效回答成本就是十元；如果一次答对率从六成提到八成五，同样的成本下分母变成八千五百次，单次成本直接掉到七元出头。这就是为什么我一直强调，压成本最快的手段不是换便宜模型，而是提高一次答对率。算的时候还要注意口径一致：分母里的”采纳”要有业务方确认的标准，否则每个部门报的数都不一样。

数据治理真能压低 token 成本吗？幅度大概多少？

能，而且往往比换模型有效。路径主要有三条：口径唯一之后，同一个问题不再被反复追问，重复提问率能降一大截；语义描述和召回策略做细之后，单次输入 token 能压掉一半左右；主数据统一之后，系统不用在答案里花篇幅解释”哪个口径”，输出 token 也跟着降。我手上的项目，治理到位的情况下单次有效回答成本普遍降三到六成，具体看原来有多乱。但要提醒一句：治理本身也有投入，不是白来的。我会算一笔投入产出账——治理一次投入多少，每个月省下多少推理费和复核工时，多久收回。通常在六到十二个月之间能回正，之后就是持续收益。这也是我建议把治理预算放在模型预算之前的原因，顺序反了，钱会花两遍。

八、写给正在做预算的你

如果你现在正拿着一份大模型的报价单，准备写立项材料，我想说的是：先把测算口径换成全周期的，再谈钱。单价能帮你排除明显不合适的选项，但它决定不了这个项目一年后是赚还是亏。真正决定结果的是三件事——数据口径能不能统一、上下文能不能裁干净、有没有一套评测机制帮你持续判断好坏。这三件事做到位，用哪个模型都能跑得住；做不到，用再便宜的模型也是往水里扔钱。

我的建议是按这个顺序排预算：数据治理和口径定义放第一位，评测集建设紧随其后，然后是平台与集成，模型调用费排在它们后面。顺序对了，每一笔投入都会让后面的单位成本往下走；顺序反了，你会一直在为同一批问题重复付费。另外别忘了给自己留一个观测指标——我通常只让客户看一个数：单次有效回答成本，按季度更新。这个数往下走，说明方向对；连续两个季度不降，就该回头查口径和召回策略了。

最后落一句实在话：大模型落地这件事，短期拼的是模型选型，长期拼的是数据基本功。把数据资产理清楚、把主数据拉通、把评测集养起来，这些动作在采购清单上都不显眼，却是唯一能让成本曲线往下弯的东西。预算怎么分，本质上是问你信不信这句话。

读者评论

陈立群：我们去年就是按单价选的方案，结果第三个月账单翻了两倍，查了半天发现是知识库越传越多，召回片段失控。看完这篇有种被点名说的感觉，回去就把输入 token 分布拉出来看看。

周敏：单次有效回答成本这个指标挺戳我。我们内部一直用总提问数当分母，数据漂亮得不真实，业务部门其实根本不认。改了分母之后，汇报时底气都不一样了。

李振华：有个疑问，评测集建多少条合适？我们业务问题比较散，三百条怕覆盖不住，一千条又没人标。作者能不能再展开讲讲抽样方法。

吴晓东：鱼骨图那张挺实用，我直接拿去开会用了。六个分支一个个过，数据准备那根骨头确实没人认领，等于谁都在做，谁都不负责。

郑雅雯：制造行业的案例很有代入感，我们也是六个系统口径打架。想问一下主数据这块一般先做哪一类，客户还是物料，投入产出差别大不大。