为什么大模型 Token 越来越便宜，实际使用成本却未必下降？

大模型 Token 单价持续下降，企业的实际使用成本却未必同步下降。原因并不矛盾：单价只是总成本公式中的一个变量，任务数量、每次任务消耗、模型档位、重试次数和配套系统成本都可能同时增长。更便宜的推理还会催生原本不经济的新用法，使总需求快速扩张。

先区分单价、任务成本和总支出

模型可以粗略表示为输入 Token 数乘输入单价，加上输出 Token 数乘输出单价，再加缓存、工具和其他服务费用。单个任务成本还要计入失败重试、检索、代码执行、图像处理与人工复核。企业总支出则等于任务成本乘以任务数量，并叠加平台、网络、坚控和运维成本。

假设 Token 单价下降 80%，但一个任务从单轮问答变成十步代理流程，每步还重复发送上下文，总 Token 变为原来的十倍。忽略其他费用时，单任务模型成本反而会成为原来的两倍。如果用户量也增长，总会进一步放大。

因此，“每百万 Token 更便宜”只能证明单位计价改善，不能证明每个结果更便宜，更不能证明年度预算下降。管理者需要同时观察价格、用量和任务成功率。

为什么 Token 单价会下降

一部分来自真实效率提升。量化、投机解码、连续批处理、KV 缓存和模型专用内核减少了每个 Token 所需的计算与内存。新硬件提供更高低精度算力、更大带宽和更低单位能耗，服务商也通过提高集群利用率摊薄固定成本。

另一部分来自市场竞争。强大的开源权重模型让更多云厂商和推理服务商能够供应相近能力，低价模型获得更多流量后，闭源厂商也会调整价格。路由平台把调用迁移到更便宜的选项，使市场实际支付的混合价格继续下降。

KuCoin 的相关文章引用 2026 年 9 月初的用量加权指数，称有效市场价格触及每百万 Token 0.97 美元，并较当年夏季高点下降超过一半。这类指数能反映市场组合变化，但不是某个固定模型的报价，也不能直接代表企业自己的输入输出比例和折扣。

Agent 是最大的用量放大器

传统聊天通常是一问一答，Agent 则要读取目标、制定计划、选择工具、发送参数、检查结果并决定下一步。失败时还会重试、修正和重新验证。中间推理、工具输出和历史上下文都可能再次进入后续请求。

原文援引的行业分析认为，代理式系统完成同类任务可能需要普通交互约 5 至 30 倍 Token。这个范围不是所有 Agent 的固定倍率，但很好地说明了多步骤工作流的成本结构：步骤数、上下文长度和重试概率相乘后，很容易抵消单价降幅。

编程 Agent 尤其明显。它可能读取大量仓库文件、搜索引用、修改代码、运行测试，再根据错误日志继续迭代。一次持续一小时的任务可能处理数百万 Token，而普通聊天只使用数万 Token。若没有预算上限，一个错误方向还会触发重复搜索和修复循环。

更便宜会诱发更多需求

当单位资源变便宜，使用范围扩大，总消费反而可能增长，这与杰文斯悖论描述的需求反弹相似。低价 Token 让后台分类、持续坚控、个性化生成和批量数据处理具备经济性，过去每天调用一次的功能可能变成每个事件都调用。

产品团队也会把模型嵌入更多环节。一个客服请求可能先分类，再检索知识、生成答案、审核风险和总结工单；一个营销任务可能生成几十个候选版本并自动评测。每一步单价很低，但整体调用链显著变长。

用户规模也会增长。免费额度和低价套餐吸引更多个人与中小企业，服务商为了提高体验又提供更长上下文、更快模式和持续后台 Agent。单价下降正是规模化采用的原因，因此不能期待用量保持不变。

模型能力升级也会抬高

市场平均价格下降，不代表所有流量都迁移到最便宜模型。复杂任务往往需要更强的推理模型，而强模型的输出价格、思考 Token 和低延迟模式仍可能有明显溢价。企业若在升级后让所有请求默认使用旗舰模型，能力提升会带来新的成本层级。

测试时计算能力调整后的价格很重要，因为同样一美元可以买到更高质量；做预算时却仍需使用实际价格。一个更强模型如果显著减少错误和人工返工，尽管 Token 费用增加，每个成功任务成本仍可能下降。反之，能力提升没有业务价值时，额外支出就是浪费。

隐藏成本不在 Token 报价里

企业级应用还需要向量数据库、对象存储、日志、评测、内容安全、权限管理和可观测性。Agent 调用搜索、浏览器、代码沙箱或第三方 API 时，这些工具也会计费。模型输出错误造成的人工复核与业务损失，更不会出现在 Token 中。

长上下文增加的不只是输入费。检索结果过多会降低注意力质量，导致回答失败和重试；大量缓存占用内存和存储；实时应用为峰值延迟预留容量，也会产生闲置成本。自建部署还要计算设备折旧、电力、运维和升级。

供应商价格结构同样复杂。输入与输出可能差价明显，缓存读取、批量模式和高峰服务有不同折扣，快速通道可能额外收费。只拿宣传页上的最低数字乘总 Token，通常会低估真实支出。

怎样判断成本是否真正下降

最有用的指标是每个成功任务成本。它将模型、工具、基础设施和人工复核汇总，并以达到业务质量门槛的结果作为分母。客服可以计算每个有效解决工单的成本，编程 Agent 可以计算每个通过测试并被接受的变更成本。

还要分解输入、输出、缓存命中、重试和工具调用。只看总额无法判断问题来自用户增长、上下文膨胀还是模型选择错误。按团队、产品、功能和工作流标记用量，才能把异常支出追溯到具体决策。

预算比较应固定服务等级。更便宜的方案如果尾延迟变差、失败率提高或人工接管增加，并没有真正节省成本。相同质量、相同延迟和相同可用性下的成本才具有可比性。

控制总成本的工程手段

• 按任务难度路由模型，把高频简单步骤交给低成本模型。
• 缓存稳定前缀和重复查询，避免反复计算相同内容。
• 压缩上下文，只传递当前步骤真正需要的证据。
• 为 Agent 设置最大步骤、重试、运行时间和 Token 预算。
• 对非实时任务使用批量或较慢的低价服务模式。
• 检测循环、重复工具调用和异常输出长度并自动终止。
• 持续评测不同模型的质量价格比，而不是固定单一供应商。

模型级联通常比全面换成最便宜模型更稳妥。先用小模型处理分类、抽取和路由，仅在置信度不足或错误代价较高时升级。关键步骤可由强模型完成，验证步骤则使用规则或便宜模型，既控制成本又保持整体质量。

管理上需要哪些变化

低单价时代不适合逐次审批调用，因为审批成本可能高于模型费用。更有效的做法是建立默认限额、异常告警和自动降级，让正常实验快速进行，同时阻止失控 Agent 持续消耗。

财务预算也应从固定 Token 数转向场景预算。团队先定义业务结果和可接受成本，再反推模型、步骤和容量配置。每次模型降价后，不应自动放宽所有限制，而要决定节省额是用于降低预算、扩大覆盖，还是提高任务质量。

结论

Token 越来越便宜而实际成本不降，主要因为每个任务消耗更多 Token、Agent 引入多步骤与重试、使用场景和用户数量扩大，以及强模型、工具和治理系统产生额外费用。单位成本下降释放了需求，整体支出增长并不意味着降本技术失效。

企业应从每百万 Token 标价转向每个成功任务成本，并持续拆解模型、上下文、重试和工具用量。通过路由、缓存、级联和 Agent 预算限制，才能把价格下降真正转化为业务降本。否则，便宜的单位智能只会让系统更容易消费更多智能。