1. 现象解读杰文斯悖论正在大模型定价里重演1.1 从 13.8 倍用量说起最近技术社区讨论热度很高的一组数据是“GPT 5.6 降价引爆 13.8 倍用量”。虽然不同渠道对统计口径的说明不太一致有的按 API 请求数统计有的按 Token 消耗总量统计但 13.8 倍这个量级放在一起对比已经足够说明一个趋势模型单价下降之后用户不但没有“省着用”反而把模型调用得更频繁、更深入。这组数据真正值得关注的地方不是“降价之后销量上涨”这种直觉而是用量涨幅远超降价幅度。按照一般商品逻辑价格下降 10%需求通常只会小幅增长但在大模型场景下价格一旦降到某个阈值会让大量原本“不经济”的用例变成“划算”的用例。也就是说需求结构本身发生了变化而不只是原有需求被价格刺激了一下。作为开发者我们最需要从这组数据里读出的信息是推理成本的下降正在让模型从“奢侈品”变成“水电煤”一样的基础资源。应用架构、成本模型、技术选型都必须围绕这个新现实来调整。否则别人在用量爆发时吃到产品增长的红利我们却可能在月底对账单感到头疼。1.2 杰文斯悖论的核心逻辑杰文斯悖论最早来源于英国经济学家威廉·斯坦利·杰文斯在 1865 年出版的《煤炭问题》一书。他观察到瓦特改良蒸汽机之后煤炭的利用效率大幅提升当时很多人预测煤炭消耗会因此减少但现实恰恰相反效率提升让蒸汽机被应用到更多工业场景煤炭总消耗量反而暴涨。后来经济学把这个现象概括为“杰文斯悖论”当某种资源的使用效率提高、单位成本下降时需求弹性会让资源的总消耗量上升甚至上升幅度超过效率提升幅度。这里的关键在于“需求弹性”——资源越便宜就会有越多原本不划算的用途变得划算于是整体需求曲线向右移动总量不降反升。在 IT 行业里这个悖论其实反复出现过。硬盘容量越来越大、单位存储成本越来越低但我们保存的数据量反而爆发式增长网络带宽单价持续下降但视频流量消耗越来越高GPU 算力单价下降模型训练参数量反而越来越大。每一次“效率提升”都没有让资源消耗减少而是打开了更大的应用市场。1.3 大模型场景下的“降价—放量”传导机制把杰文斯悖论套在 GPT 这轮降价事件上可以拆出四个传导环节。第一个环节是“单次调用成本下降”。模型推理价格降低意味着同样一笔预算可以完成更多次调用或者同样规模的业务可以承受更长的上下文输入。第二个环节是“开发者行为改变”。当调用成本从“每万次几美元”降到“每万次几毛钱”时开发者就不再手动优化每一条提示词而是倾向于在业务链路里大量嵌入模型调用。第三个环节是“应用场景扩张”。之前由于成本太高而不敢做的日志摘要、代码审查、自动补全、批量客服等场景现在都能进入产品方案。第四个环节是“总消耗上升”。单次成本下降和场景数量上升叠加最终呈现出来的就是 13.8 倍这样的用量曲线。这四个环节说明在 API 类产品里价格不是简单的“收入乘数”而是“需求开关”。价格降到哪个位置就会打开对应量级的场景池。这也是很多模型厂商愿意持续降价的原因——他们看中的不是单次调用的利润而是整个生态里被唤醒的调用总量。2. 为什么大模型能持续降价推理成本的底层变化2.1 推理优化技术的持续积累大模型之所以有底气降价前提是单位推理成本确实在快速下降。这背后不是某一项技术的功劳而是一系列工程优化的累加。首先是模型结构上的优化。混合专家模型MoE让模型在不增加每次推理计算量的前提下扩大参数量相当于用更少的算力获得更强的能力。其次是推理引擎层面的优化包括 KV Cache键值缓存复用、连续批处理Continuous Batching、投机采样Speculative Decoding等技术。这些技术本质上都在做同一件事让 GPU 在单位时间内处理更多请求摊薄单位 Token 的算力成本。还有硬件层面的因素更大规模的 GPU 集群提高了资源利用率自研芯片和更成熟的部署方案降低了单位算力采购成本。再加上量化技术把模型权重从高精度压缩到低精度在效果损失可控的范围内显著减少了显存占用和计算开销。这些因素叠加在一起使得推理成本每隔一段时间就会出现一次明显下降。2.2 Token 定价与成本构成在调用 GPT 这类大模型时计费单位是 Token而不是请求次数。Token 可以理解为模型处理文本的最小单元一段文本会被拆成若干个 Token 输入模型。英文中一个单词大约对应 1 到 1.3 个 Token中文场景下情况略有不同一个汉字通常会被拆成一到两个 Token。从成本构成上看一次 API 调用的主要开销在于 GPU 的显存占用和计算时长。输入 Token 需要走前向推理输出 Token 需要逐字生成后者的计算开销通常更高所以绝大多数模型都会把输入价格和输出价格分开设置输出价格一般是输入的 2 到 4 倍。这里需要特别提醒在估算成本时不要只看输入价格。Agent 类应用往往需要多轮交互每轮都会把历史对话重新发给模型输入 Token 会累积放大真正让账单膨胀的往往是那些被反复发送的上下文内容。2.3 模型版本迭代带来的价格体系变化模型厂商的定价策略有一个明显趋势新版本模型通常以“更强的能力、更低的价格”发布。因为新模型在算法结构、训练数据、推理优化上都有改进达到同样效果需要的计算量更少厂商也就有了让利空间。对开发者来说模型版本升级意味着两件事。第一要考虑迁移成本新模型的提示词格式、输出风格、能力边界可能和旧版本不同不能简单替换 API 参数就完事。第二要重新评估成本模型新版本往往提供更长的上下文窗口和更便宜的单位价格但长上下文如果使用不当Token 消耗反而会成倍增长。所以每次模型版本发布后我都建议做一次“成本回归测试”用同一批业务请求分别跑旧版本和新版本对比输出质量和 Token 消耗量。不要只看单价要看单位业务成本也就是完成同一个业务目标需要花多少钱。2.4 多模态与 Agent 场景扩展了用量边界除了文本推理成本的下降另一个推动用量爆发的因素是能力边界的扩展。从 GPT Image 2.0 这类图像生成能力的迭代到 Codex 这类编程 Agent 的产品化再到批处理 API 的开放模型的可用场景已经从“问答对话框”扩展到了“多模态生成 复杂任务自动化”。场景扩展直接拉高了 Token 消耗总量。一个文本对话请求可能只消耗几百个 Token但一个编程 Agent 完成一次自动化任务可能需要几十次模型调用累计消耗数万甚至数十万 Token。换句话说用量增长不仅仅是“更多人调用”更是“单次业务消耗的 Token 量级上升”。这种变化对后端架构提出了新要求单个请求的响应时间变长、并发模型实例变多、日志量和成本监控粒度都需要调整。很多团队在接入 Agent 类应用后第一反应是“模型效果不错”第二反应就是“账单涨得有点快”。这是用量爆发阶段的正常现象但它要求我们在一开始就把成本治理设计进架构里。3. 用量爆发背后的开发者行为变化3.1 从“省着用”到“放开用”在模型价格比较贵的阶段开发者普遍会做几件事尽量缩短提示词、减少不必要的模型调用、用规则引擎过滤掉简单请求。这些做法本质上都是在“省 Token”。价格下降之后很多团队的使用策略会发生明显改变能交给模型的就不写规则能调用的就不做缓存。短期内这种做法确实能提升开发效率和产品体验但如果完全不做任何约束“放开用”很快就会变成“账单失控”。我见过不少团队把成本治理放在“出了问题再说”的位置结果月底账单出来才去优化代码。正确的思路是开源让模型发挥更多价值和节流控制单位业务成本同时进行在用量增长的早期就把成本监控、配额管理、模型路由这些基础设施搭好。3.2 从单次调用到 Agent 循环代理Agent式应用是这一轮用量爆发的重要推手。传统调用方式是一次请求、一次回复调用方拿到结果后用代码做后续处理Agent 模式则是模型自己做计划、调用工具、观察结果、调整策略整个过程可能包含几十次甚至上百次模型调用。这意味着同一个业务目标Agent 模式下产生的 Token 消耗可能是传统模式的几十倍。好处是它能完成更复杂的任务比如自动写代码并执行测试、自动检索资料并生成分析报告、自动处理客服工单并回访。坏处是如果 Agent 的规划循环写得不好模型会在错误的路径上反复尝试Token 消耗像漏水一样止不住。所以在设计 Agent 应用时一定要给循环加上“刹车”设置最大迭代次数、增加人工确认节点、对工具调用结果做校验、记录每一步的 Token 消耗。Agent 越强大越需要约束机制这是工程上必须付出的代价。3.3 从对话界面到 API 集成用量爆发的另一个表现是调用方式从 C 端聊天界面转向 B 端 API 集成。开发者把模型能力封装进自己的产品再通过 API 提供给终端用户。这样做的结果是一次最终用户体验到的功能背后可能是多次模型调用。API 集成场景下开发者需要额外关注几个问题密钥如何安全管理和轮换、请求如何做身份认证和鉴权、调用量如何按用户或按租户计量、异常情况下如何降级。尤其是密钥管理很多安全事故都源于 API Key 被硬编码在代码里或者被误提交到公开仓库。这里要强调一个安全底线所有涉及模型调用的业务都应该遵循最小权限原则。API Key 只授予业务需要的权限生产环境使用独立的密钥和独立的配额并定期轮换。不要为了省事把管理密钥和业务密钥混用。3.4 用量增长带来的新问题用量增长不是免费的它会给系统带来一系列连锁压力。首先是延迟高并发下模型服务的排队时间变长接口 P95 延迟可能从 1 秒涨到 5 秒其次是限流API 提供方会对单账号的每分钟请求数做限制超过就会返回 429再次是成本使用量上升直接反映在账单上。解决这些问题的思路不是“少调用”而是“聪明地调用”用缓存减少重复请求用模型路由把简单任务分给轻量模型用异步队列削峰填谷用兜底结果保证核心功能在模型不可用时仍然可用。这些工程手段组合起来才能在用量增长的同时保持系统稳定和成本可控。4. API 成本核算一次调用到底花多少钱4.1 什么是 TokenToken 是模型处理文本的基本单位。在调用 GPT 系列模型时输入文本和输出文本都会先被切分成 Token再交给模型计算。一个 Token 可能是一个完整的英文单词也可能是单词的一部分或者是单个中文汉字以及标点符号。不同语言的 Token 切分差异比较大。英文通常 1 个单词约等于 1 到 1.3 个 Token中文一个汉字大约 1 到 2 个 Token具体取决于使用的分词算法。对开发者来说不需要精确掌握 Token 切分规则但需要有一个数量级概念因为在估算成本和多轮对话上下文长度时Token 数量是核心指标。4.2 输入与输出 Token 的不同计费逻辑绝大多数 GPT 类 API 会区分输入 Token 价格和输出 Token 价格输出价格显著高于输入价格。原因是输出 Token 需要逐字生成每一步都依赖前一步的结果计算耗时远高于并行处理输入。在实际业务中输入 Token 通常占绝对多数因为系统提示词、历史对话、检索到的文档都会被送入上下文。但输出 Token 的单价更高所以最终账单里输出部分的金额占比往往也不低。下面用一个表格直观对比两类 Token 的差异。维度输入 Token输出 Token来源用户问题、系统提示词、历史上下文模型生成的回复内容计算特点可并行处理逐字串行生成单价较低通常为输入价格的 2 到 4 倍控制手段压缩提示词、清理历史限制 max_tokens、设置停止词4.3 成本计算公式与代码示例一次 API 调用的成本可以按下面公式估算成本 输入 Token 数 × 输入单价 输出 Token 数 × 输出单价假设某个模型的演示价格为输入 1M Token 收费 0.5 元输出 1M Token 收费 1.5 元注意这只是演示数字实际价格以模型官方公布为准。那么一次“输入 2000 Token、输出 500 Token”的请求成本就是0.002 × 0.5 0.0005 × 1.5 0.001 0.00075 0.00175 元单次请求看起来非常便宜但乘以业务量之后就不是小数了。下面给一个成本估算函数方便在项目里直接复用。# 文件路径cost_estimator.py def estimate_cost(input_tokens: int, output_tokens: int, input_price_per_million: float, output_price_per_million: float) - float: 估算一次 API 调用的费用。 :param input_tokens: 输入 Token 数 :param output_tokens: 输出 Token 数 :param input_price_per_million: 每百万输入 Token 价格 :param output_price_per_million: 每百万输出 Token 价格 :return: 单次调用费用 cost (input_tokens / 1_000_000) * input_price_per_million \ (output_tokens / 1_000_000) * output_price_per_million return round(cost, 6) # 演示一次输入 2000、输出 500 的请求 print(estimate_cost(2000, 500, 0.5, 1.5)) # 输出 0.00175假设一个客服系统每天有 10 万次请求每次请求平均消耗 2500 Token按照上面的演示单价每天的成本大约是 175 元一个月就是 5250 元。这还只是一个中等体量的场景如果做 Agent 循环或批量文档处理成本会再上几个量级。4.4 典型场景的 Token 估算参考不同业务场景的 Token 消耗差异很大下面给出一组估算参考值。业务场景单次输入 Token单次输出 Token成本量级短文本分类50050很低客服问答带上下文3000300中等文档摘要长文档80001000较高Agent 多轮任务10000 以上5000 以上高代码审查60001500较高表格里的数字都是估算值实际消耗取决于提示词长短和业务复杂度。写这部分想强调的是任何 AI 功能上线前都应该先做一次 Token 成本估算并且把“上下文膨胀”的因素算进去。很多团队上线后才发现多轮对话把历史记录全部塞进上下文输入 Token 每轮都在翻倍成本远超预研阶段的估算。5. 开发实践如何在不降低效果的前提下控制成本5.1 提示词优化与 Token 压缩提示词优化是成本治理里性价比最高的一步。系统提示词里的每句话都在消耗输入 Token而且多轮对话中系统提示词会被重复发送累积量非常可观。几个常用的压缩方向第一删掉提示词里的冗余描述只保留约束模型行为的关键指令第二把 few-shot 示例压缩到最少能用一个示例说清楚就不用三个第三如果上下文窗口允许优先使用更短的指令句式第四把固定不变的提示词内容放到缓存前缀里利用服务端的缓存机制降低重复计算成本。但要注意提示词压缩不能牺牲效果。每次修改后都要用一批回归用例验证输出质量确保压缩后模型仍然能稳定完成任务。这里没有“银弹”只有结合业务反复测试。5.2 缓存层设计缓存是降低 Token 消耗最有效的工程手段之一。同一类请求如果结果可以复用就没必要重复调用模型。两种缓存思路值得重点考虑。第一种是精确前缀缓存针对系统提示词、固定模板这类不变内容服务端会自动缓存计算结果重复使用时只按增量 Token 计费第二种是语义缓存在 RAG 场景里把输入问题做向量化先检索缓存池如果命中相似问题就直接返回历史答案不再调用模型。缓存设计要特别关注“新鲜度”问题。业务数据更新之后旧缓存