我最近在一个AI项目里，碰到一个以前做软件时很少需要解释的问题。
甲方对开发费用本身没有太大疑问，需求、开发、测试、上线，这套流程大家都熟悉。真正卡住的是上线以后：为什么系统已经开发完成，后面每个月还会继续产生Token费用？在传统项目的理解里，一套软件花钱做完、验收、交付，项目基本也就结束了。现在却变成系统用得越多，后面还有一笔持续增加的费用，这很容易被理解成“项目之外又多收了一笔钱”。
仔细想了一下，甲方有这个疑问其实很正常。过去二三十年，大部分企业就是按照“建设一个系统”的方式采购软件，预算也围绕功能范围、开发周期和人力成本来做。AI带来的变化，是在这套大家熟悉的成本结构上，又增加了一层以前没有这么明显的东西：智能本身也开始按使用量计费。
项目做完了，为什么费用没有结束
传统软件当然也不是只花一次钱。服务器、数据库、云存储、CDN、短信、许可证、运维，都可能是持续成本。企业其实早就在接受按量付费。
AI不一样的地方，是这种持续成本开始进入软件最核心的能力。过去做一个订单系统，计算金额、查询库存、生成报表，这些业务逻辑已经写在代码里。用户执行一次还是十次，会增加服务器负载，但通常不会因为每点一次按钮，就再向一个“订单计算服务商”支付一笔费用。
大模型不是这样。用户问AI一个问题，需要调用一次模型；让AI总结一份合同，要把合同内容送给模型处理；让Agent查资料、分析数据、调用工具再给出答案，背后可能发生多轮模型调用。每一次模型处理输入和生成输出，都在消耗计算资源。
Token就是模型厂商对这种消耗最常用的计量单位。DeepSeek官方文档把它定义为模型表示自然语言文本的基本单位，也是计费单元，费用根据输入和输出Token数量计算。不同模型的分词方式并不完全相同，所以企业不用纠结“一个Token到底等于几个汉字”，把它理解成“AI处理了多少信息”的计量单位就可以了。
如果一定要找一个甲方更熟悉的类比，我觉得它更接近电费。项目开发费相当于把设备和线路建起来，而Token是设备运行以后持续消耗的电。这个比喻并不完全准确，但至少能解释为什么“系统已经交付”和“以后仍然有使用成本”并不矛盾。
Token不是一个固定价格，它会随着AI怎么用而变化
以现在国内模型的API价格看，这件事情已经相当明显。DeepSeek目前的V4 Flash在工作日高峰时段，100万Token缓存未命中的输入价格是3元，输出9元；如果输入命中缓存，同样100万Token只要0.1元。V4 Pro对应的高峰价格则是输入9元、输出27元，而且空闲时段价格还是高峰的一半。
Kimi也是类似的结构。目前Kimi K2.6官方价格是缓存命中1.1元/百万Token、普通输入6.5元、输出27元；K2.5则是0.7元、4元和21元。 这里值得甲方注意的并不是哪家便宜几块钱，而是AI系统的成本已经和“用了哪个模型、一次塞进去多少资料、生成多长的答案、缓存有没有利用起来”直接相关。
举一个简单的例子。假设一个AI客服系统每天处理1万次请求，每次平均输入3000 Token、输出500 Token。按DeepSeek V4 Flash高峰期、缓存未命中的价格估算，一天大约消耗30M输入Token和5M输出Token，模型费用约135元，一个月大约4050元。如果业务增长到每天10万次，在其他条件不变的情况下，这一项就会变成每月约4万元。
这还只是一次问答。如果是Agent，一个任务内部可能需要反复读上下文、调用工具、检查结果再继续执行，成本会更复杂。所以同样一个已经开发完成的AI系统，100个人用和10万人用，后续费用显然不可能完全一样。
以前谈项目预算，我们主要是在估算“把东西做出来要多少钱”；AI项目上线以后，还需要多问一句：“这套智能以后被使用起来，一个月大概多少钱？”
理解Token，不等于接受一张没有上限的账单
说到这里，很容易走向另一个极端：既然AI按使用收费，那甲方是不是只能接受每个月用了多少Token就付多少钱？
我并不认为应该这样。Token是模型厂商的技术计量单位，但它不应该成为企业管理AI项目的最终单位。企业真正应该知道的是，这笔费用能不能预测，超过多少会预警，以及它对应了多少业务价值。
这也是为什么AI项目在设计阶段就应该把成本控制做进去。比如简单任务用便宜模型，复杂问题才切到更强的模型；重复出现的大段上下文尽量使用缓存；限制Agent一次任务最多执行多少轮；对不同部门设置调用额度；当月度成本接近预算时主动告警。DeepSeek同一款V4 Flash，高峰期缓存命中的输入价格只有未命中的三十分之一，这已经足以说明，Token成本本身也是产品和架构设计的一部分。
实际商务上也不一定非要把一张Token明细表直接扔给客户。可以是开发费加实际模型费用，也可以是每月固定费用包含一定使用额度；大型企业还可以自己持有模型厂商账户。形式有很多种，关键是双方先承认这笔成本客观存在，再决定谁来承担波动风险。
企业最后要算的，其实不是Token，而是一件事情多少钱
我最近又看了一下FinOps Foundation今年关于AI Token Economics的资料，他们在调研中把SaaS模型Token的成本和使用管理列为从业者当前面对的首要挑战。原因也很现实：Token是很多财务和业务人员以前没有接触过的单位，模型之间价格差异又很大，用传统预算工具并不好管理。
今年8月，Linux Foundation专门成立了Tokenomics Foundation，首批有30家机构参与，包括Accenture、IBM、JPMorgan Chase、Oracle、SAP和ServiceNow等。它要解决的问题已经不只是“Token怎么算”，而是希望建立AI总成本、Cost to Serve以及ROI的共同衡量方法。
这说明我们在项目现场碰到的问题，并不是某一家甲方“不懂AI”，整个行业都还在学习怎么给“智能”算账。
而且再往前一步，企业最后也不应该长期盯着100万Token多少钱。真正有意义的指标应该是：AI处理一份合同多少钱，完成一次客服多少钱，一个Agent跑完一项业务任务多少钱。
假设人工审核一份材料需要30元，AI平均成本是1元，那么即使企业每个月因此产生几十万元Token费用，这个项目仍然可能非常划算。反过来，如果一个AI功能完成一次任务花50元，人工只需要10元，那么模型单价再便宜，也很难证明它有商业价值。
我现在再回头看最开始甲方提出的那个问题——项目费用已经付了，为什么以后使用AI还要继续付Token——答案其实没有那么复杂。
过去我们采购软件，主要是在购买一套已经写好的业务逻辑；现在做AI项目，除了购买这套系统，还在持续调用模型提供的智能计算能力。开发完成以后，前一笔成本基本确定了，但后一笔成本才刚刚随着实际使用发生。
甲方并不需要成为Token专家，也不应该接受无法预测的费用。但如果还希望像过去那样，只问“这个项目一共多少钱”，然后认为验收以后所有成本都应该结束，那么很多AI项目确实会越来越难算清楚。
更合适的问题可能已经变成了：这套AI一年总共要花多少钱，以及它每帮我完成一件事情，到底值不值这笔钱。
