Token账单迷雾：当每百万Token多少钱变成「比价陷阱」

一家传统企业的财务总监第一次拿到Token账单时，通常只有两个感受：一是怎么这么贵，二是怎么算出来的。

第一个问题可以通过预算来回答；第二个问题，则要复杂得多，账单上的算法，不同厂商有不同的版本，但剥开来看，核心逻辑都长得很像——不过是“单价乘以用量”的某种变体。

变化就发生在这个乘法里。

2024年初，中国日均Token调用量是1000亿。到2026年3月，这个数字突破了140万亿——两年，超过1000倍。

Token不再只是工程师终端里一行灰色的日志，它正在印入预算表、损益表和季度财报。AI支出也从"研发预算"变成了"运营成本"，而且后者还在以季度为单位陡增。欢迎添加微信EATINGNTAE交流国内Token使用现状。

Token的出现，第一次让模型生成能力被压缩成一个可计量、可交易、可结算的单位。

AI产业的商业模式也正在随之改变。过去，企业采购的是GPU、算力卡，后来购买的是GPU小时、API调用；如今，越来越多厂商开始直接按Token计费、按Token结算。

你不再需要知道底层跑的是哪款GPU、花了多少机时，只需要关心最终产出了多少Token。这像极了电力时代的"度"——把复杂的发电、输电和配电过程，压缩成一个所有人都能理解的计量单位。

但计量单位统一之后，一个隐秘的裂缝也随之裂开：单位统一了，算法却没有统一。

表面上看，账单只有两个变量：价格和用量。但这两个数字都不是常量，模型怎么定价、缓存命中有没有折扣、长思考模式会不会额外消耗Token，甚至数据中心建在哪个省份，都在左右最终的数字。

看似清晰的一道乘法，实则是一张谁都读不透的网。

为什么同样是Token，价格差距却越来越大？

大模型API的价格战，让Token的单价看起来前所未有的透明，但恰恰是这种“一分钱一分货”的明码标价，将真正的成本结构藏进了黑箱。同一个数字背后，可能是技术效率的极致兑现，也可能是资本补贴的饮鸩止渴。

从事芯片行业的吴昊把这种成本的不可比，归结为三个互相纠缠的变量：设备成本、运营成本、合同周期。

设备端的差异，从采购那一刻就已经写进了初始成本——GPU的型号、采购量大小、是否搭售软件、配没配外部存储方案，每一项都会以不同方式影响最初的成本分摊。

吴昊描述，前一段时间行业的主流趋势是，大家都在拼算力峰值，比谁的卡算力值最高。

厂商在宣传时强调单卡有多强，实际销售时顶尖卡却几乎不单独租赁，都是以集群为单位出货。一台B300整机36P算力，一个集群至少32台，加起来就是千P级别。“全国能租得起这种集群的客户，可能也就几十个，大量中小客户根本用不起来。”吴昊指出。

而这些无法被充分利用的顶级算力，最终会以某种方式，摊进每一个Token的定价里。

运营端的变量同样复杂，而且拉开了一个更隐蔽的差距。

电价是其中最直观的一条线。吴昊提到，西北部分地区电价能做到两三毛，靠的是新能源补贴和体外循环资金补贴维持运营；东部地区则普遍在6毛以上，甚至到7、8毛。

两三毛和六七毛——两个价格区间，整整差出三倍，而大量算力中心正是依赖着这种补贴维持整体运营。吴昊坦言，这种现象在当前行业里占了多数。

也就是说，今天市场上看到的不少“低价Token”，未必是效率提升的结果，而是一场仍在持续的补贴战争的产物。一旦补贴退场，账单会反弹多少，仍是一个未知数。

如果说吴昊的账本算的是“过去的投入”，太初元碁首席产品官洪源则把视线投向了“未来的账单”。

“当行业真正进入Token经济时代，最重要的衡量指标可能会从单纯的算力速度，转向能源转化效率——每瓦电能能够产生多少Token。单纯关注每秒生成Token数而不考量能耗，在长期运营中存在显著局限。”

洪源认为，单卡的算力值或每秒生成Token数，从来不能反映真实的产出能力。生成Token是一整套系统工程：从单张卡到服务器，再到服务器之间的互联，涉及显存带宽、互联带宽、液冷系统、软硬件协同，最终才体现为集群每秒生成的Token数。

不同公司这套切分技术的精细程度，直接决定了同样标价的一个Token，背后真实占用的算力含量。

在设备、电价之外，合同周期是第三个变量，而且Token经济正在把它推入一种全新的复杂度。从签约年限到计费颗粒度，规则都在变：算力正在从整租变成散租。这一趋势将如何重塑算力市场的定价逻辑？欢迎添加微信EATINGNTAE探讨。

吴昊打了个比方：过去一个算力集群可能只服务一两个大客户，没什么运营问题，但Token让算力变成了可以按需切割的商品——不必整租一台机器，甚至可以像交电费一样，按Token消耗量结算。

“以后会变成像写字楼那样，从整租变成散租。每个客户的装修要求不同，档期不同，空置率也不同。恰恰是这种变化，倒逼着真正的运营能力要做起来。”吴昊这样形容未来可能的状况。

1年和5年的长期锁定合同，与按Token量结算的散租模式，背后是两套完全不同的运营逻辑和成本结构。

而一个Token的价格，始终是模型推理背后一整套基础设施效率的最终体现，它涵盖算力、能源、政策激励与商业契约的每一层博弈。

为什么「每百万Token多少钱」不能直接比较？

如果说成本的算法是“各家算各家的账”，那标价的算法就更进了一步——它挑战的是一个更基础的前提：Token的计费规则，本身就没有统一的标准。

云天励飞副总裁罗忆提到，目前主流模型已将输入和输出拆分为两个阶段分别计价，两个阶段的计算成本完全不同：Prefill（预填充）一次性并行处理全部输入，而Decode（解码）需逐字串行生成，每多生成一个Token就多走一遍计算，因此，输出Token的单价普遍比输入Token贵。

超长上下文会显著推高Prefill阶段的开销，长思考模式则让Decode部分“先打草稿再正式回答”，内部思考的Token消耗可达上万，整体开销接近翻倍。

此外，缓存机制还进一步拉大了实际计费的差距。如果本次请求的前缀内容与之前相同，平台可直接复用之前保存的中间结果，跳过重复的Prefill计算，缓存命中与缓存未命中之间的价格差距可达上百倍。大厂凭借更高的缓存命中率能有效降低用户的重复计费，而一些厂商缓存机制不完善，用户可能在毫不知情的情况下因缓存反复失效而重复付费。

另一个同样隐蔽的变量来自分词器（tokenizer）。不同模型对同一段文本的切分方式不同——GPT系列用BPE（字节对编码），Claude用BPE变体，Llama和DeepSeek用SentencePiece，各家的词表大小、中文覆盖度、子词策略都不一样，这就导致同样是100万Token，承载的信息量在不同模型之间可以差出不少。

当计费口径本身就不统一，“每百万Token X元”的比价，比的可能就不是同一把尺子。

从整个行业的角度看，价格的离散程度更让人意外。以输出价格为例，OpenAI GPT-5.5的高性能版本（Pro）每百万Token可以要到上百美元，Anthropic Claude Opus 4.8（标准模式）也要二三十美元，而国内厂商普遍只有个位数人民币——DeepSeek最新版本输出价格不过6元。

为什么价格差距这么大？

云天励飞副总裁罗忆坦言，当前Token定价体系尚处混沌期，不同模型、不同服务等级下，百万Token的标价千差万别，甚至不乏“挂羊头卖狗肉”的虚标乱象。现在的定价就好比卖牛肉——不同部位、不同品质对应不同价格，但最终仍以重量作为基本的计量单位。

迈富时CFO马进则把它比作护肤品市场，“消费者可以根据需求选择高端品牌还是中端品牌”。

两个比喻指向同一个结论：Token不是一个均质商品，不同模型能力、不同服务等级产出的Token，质量天然不同。

九章云极把这种分层描述得更结构化：未来的Token市场会形成"金字塔"——底层是海量、廉价的基础能力Token，中层是高可靠、特定场景优化的Token，顶层是极致性能、定制化的Token，三层Token背后的算力消耗和质量差异极大。

所有这些说法，最终都指向同一个事实：尽管Token顶着“统一计量单位”之名，背后的分词规则、计费口径、质量等级，却可能各不相同。

度量衡的意义，本应是放之四海而皆准，一公斤在哪里称，都是一公斤。但当下的Token，看起来是一个统一计价的基础单位，实际上更像是每家公司自己定义、自己解释、外部无法验证的内部货币。

所谓标准化，标准的只是这个名字，而不是它的质量与价值。

Token越用越贵，问题不在模型？

算力中心在建，模型在跑，Token在烧。但烧掉的那些Token，到底换回了什么——这个问题，正在成为每家企业IT负责人的日常拷问。

要回答它，得往回倒一步。“该买什么，以及买没买对”——这是很多企业迈入AI采购时遇到的第一道门槛。

芯片行业人士吴昊提到过一个案例：一家大型供应链企业，主营业务是物流调配，数据主要是结构化指令和判断数据，但对于“用谁的模型最合适，他不清楚；该规划多少Token用量才合理，他也不知道。”

许多公司在尚未明确自身需求时，习惯将行业头部作为参照，却常陷入错位。头部企业提出的需求类型、设备选型与部署规模，极易被同行直接照搬为标杆，而两者在业务复杂度、数据体量与预算层级上往往相差悬殊——前者或许需要高性能算力集群支撑核心业务，后者可能仅需一个小参数模型即可胜任。

照搬，性价比极低。

更大的挑战在于，这种认知短板不只存在于需求方一侧。一些过去只做英伟达产品的算力运营商，如今也在积极联系国产厂商进行测试——他们自己也需要先熟悉不同硬件的特性，才能形成有效的对比判断。

当供给端和需求端都在同步补课，“懂行”本身就成了一个相对的、暂时的状态——而买家的第一笔账，往往是在这种状态下算出来的。

采购只是第一步，当Token真正烧起来之后，数字的涨法往往超出预期。

以搭建一个股票分析workflow为例，前期调试消耗上千万Token，流程跑通后，每次运行再耗百万Token；一旦从单只股票扩展到批量分析，日总消耗立即骤增百倍。

Agent的调用逻辑不是线性的——它会反复迭代、自我对话、调用上下文。单次调试的成本看似可控，一旦规模化，消耗量就会以超出预期的方式膨胀，而大多数买家在做预算测算时，对这个拐点几乎没有感知。

规模化放大的，不只是消耗量本身，还有设计优劣之间的成本差距。

共绩科技联合创始人黄力昂发现，使用Token有高手和普通人之分，两者的差距远比想象中大。而且，很多高效使用Token的知识和技巧目前还只存在于团队和个人的脑子里，没有被固化到应用里。

这种差距具体从哪来？

Meta程序员程子的经验是，好的设计者从不放任Agent无限思考。真正高效的商业做法，是把Agent的行为框进“有限循环”里——拆步骤、定边界、限迭代。

“会写Prompt、会利用AI去设计Agent架构和优化交互流程的人，与从没深入做过这件事的人相比，他们之间产生的经济效益区别是巨大的。”程子说。

好的设计能把Token变成智慧，差的设计只能把Token变成成本。

Meta和亚马逊很早就撞上了这堵墙，两家公司一度把Token消耗量作为KPI考核指标，后来又叫停了。

程子透露，原因是“有点矫枉过正”，担心员工“无条件地刷Token”。但他也承认，公司内部仍在关注这个数字——因为Token消耗量和工作状态之间存在明显的相关性，当一个人一段时间内不那么忙，消耗量确实会明显下降。

换句话说，企业曾试图用最粗暴的指标——“消耗量”，去衡量那个真正想衡量却衡量不了的东西：“价值”。

迈富时CFO马进把这个过程描述为一种必然的调整。在他看来，这并非Token作为计量单位的根本缺陷暴露，而是企业考核机制从“推动习惯养成”到“回归经济理性”的必然过渡。

罗忆也看到了类似的阶段分化——只是他的视角从市场切了进去：国内目前仍处于“鼓励用量”的初期阶段，不管用得好不好，先养成使用习惯，抓量不抓质；而头部大厂已进入下一阶段，开始从“用量”转向“用精”，用更科学的指标来评估有效产出。

类似的情况，九章云极在互联网早期也见过。“这如同互联网早期，点击量和页面浏览量曾是核心指标，但后来大家更关注用户停留时长、转化率等有效指标。”Token的竞争，也必然会从“调用量”转向“有效Token价值”——只是截至目前，这套新的换算关系还没有成型。

当“烧多少”不能代表“值多少”，Token需要什么新标尺？

野蛮生长，在罗忆看来是这个阶段的必然。

整个行业的能力边界还在不断延伸，远未触达上限——技术会催生新的服务形态，服务落到场景里跑通了，质量体系才会跟着长出来。本质上，是技术在推着标准往前走。

罗忆认为，“一开始就过于规范，反而可能阻碍发展。”

而技术端的共识也已经正在冒头。共绩科技联合创始人黄力昂注意到，模型在收敛，训练范式在趋同——大家对什么是“好”的默契，比外界想象的要多。这些默契还没有写成标准，但它们已经在代码里、在架构选择里、在工程师的日常判断里悄悄生长。

但他也提醒，技术不是唯一在发力的力量。这次变革的体量不亚于一次工业革命，不可能只把话语权交给技术，不同文化和社会体制，会把各自的需求刻进Token的基因里。

迈富时CFO马进从商业端看到的图景，与技术侧的收敛遥相呼应：大模型市场正在逐渐收拢，未来全球能存活的大模型公司会越来越少——市场的无形之手，也在把玩家往同一个方向推。

共识在聚拢，但标准还没来。行业没有干等——云天励飞联合三十多家产业链企业签署“1001计划”，先把各方拉到一张桌子上，以行业共识为起点推动标准制定。

与此同时，各家厂商已经开始用自己的方式给出参照系：九章云极提出“按度计量”，作为算力端的统一标尺，让不同芯片、不同集群产出的Token可在同一把算力尺度下可比，Token工厂则在输出端负责智能的标准化封装与交付；迈富时区分“大模型Token”与“场景Token”，按词元消耗与任务效果分别计价，将价值的度量从“消耗端”迁移到“结果端”，全栈Token工厂的溢价权，最终取决于企业智能体能否在具体场景中交付可量化、可持续的业务成果；太初元碁率先发布高密液冷集群，在性能、功耗与建设成本间寻求最优平衡，为Token生产成本划出参照标尺。

从共识到标准，仍有距离。这条路径究竟由技术、商业还是更复杂的博弈主导，尚不明朗，但标尺已在打磨，刻度隐约浮现。

Token未必会成为AI时代最终的“度电”，但围绕它所构建的新价值尺度，终将左右下一代AI基础设施的话语权。

作者长期深耕AI算力与芯片领域，后续将推出Token系列专题文章，欢迎添加微信（EATINGNTAE）交流探讨。

注：吴昊、程子为化名。

雷峰网(公众号：雷峰网)雷峰网

雷峰网原创文章，未经授权禁止转载。详情见转载须知。