模型定价趋势与其影响

过去讨论模型价格，常用“每百万 token 多少钱”做一维比较。现在这张表仍有用，却越来越不足以解释真实账单。同一个模型的输入、缓存输入、输出可能采用不同费率；离线 Batch、低优先级处理、标准实时和高优先级服务，也可能对应不同价格与延迟承诺。再加上搜索、代码执行、图片与音频等工具费用，模型定价正在从单价表变成一套资源调度规则。

本文基于 2026 年 9 月各厂商公开价格页与开发文档做结构性观察，不预测下一次降价，也不罗列容易过期的具体数字。所有价格在采购前都应回到厂商当日页面核对。

一、趋势一：输入、缓存与输出被拆成不同商品

主流 API 已普遍把 token 分成至少三类：普通输入、缓存输入和输出。这样定价背后的逻辑很直接：重复处理同一段长上下文，与首次计算的成本不同；生成 token 通常又比读取输入占用更多推理资源。

计费项	典型来源	开发者可控制程度	优化重点
普通输入	用户消息、RAG 文档、工具定义	高	去重、裁剪、检索
缓存输入	稳定系统提示、重复前缀	中到高	提高命中率、稳定前缀
输出	模型回复、推理与结构化结果	高	限制长度、减少无效重试
工具调用	搜索、执行、媒体处理	中	按任务启用、限制循环

这意味着“上下文越长越贵”的说法需要更精确：长上下文若被高频复用并稳定命中缓存，边际成本可能明显下降；若每次都在前缀中插入时间戳或动态字段，缓存失效，账单仍按普通输入累积。缓存不是一个开关，而是一种 Prompt 结构能力。

二、趋势二：延迟正在成为可定价的服务等级

公开文档中可以看到更多处理等级：实时标准、可延迟的 Batch、best-effort 或 flex 类型，以及面向稳定吞吐的 priority / provisioned capacity。厂商不再只卖“某个模型”，还在卖请求何时被调度、是否可以等待、吞吐是否预留。

以前选择题是“用大模型还是小模型”，现在还要问：这项任务是否面向正在等待的用户？能否几分钟后返回？能否凑成批次？高峰期失败是否可以重排？

可以按业务时效分层：

对话首轮、交互式编程和实时客服走标准或高优先级通道；
夜间评测、内容分类、数据清洗走 Batch；
可排队但不适合等一整天的内部任务走低优先级通道；
有硬吞吐要求的核心业务再评估预留容量。

延迟分级后，成本优化从“换便宜模型”变成“把任务放到合适队列”。具体取舍可参考批处理与实时调用的成本差：账单之外还要算什么，本文不重复 Batch 接口细节。

三、趋势三：模型梯度比单模型降价更重要

厂商通常同时提供高能力、中档和轻量模型。价格表上的最低单价持续吸引眼球，但真正影响团队支出的，是能否把任务稳定路由到合适梯度。简单分类、抽取和改写不必默认使用最高能力模型；复杂规划、代码修改或高风险判断也不应只因单价低就强行降级。

模型梯度带来一个反直觉结果：更便宜的 token 未必产生更便宜的任务。如果轻量模型需要更多轮重试、输出更长，或让人工复核时间上升，总成本可能更高。OpenAI 的官方 token 说明也提醒，不同模型的分词与输出长度不同，不能只比较展示的每百万 token 单价。

因此选型指标应从 price_per_token 升级为 cost_per_accepted_result：

单个有效结果成本 =
  全部模型调用费用
  + 工具调用费用
  + 重试与失败任务费用
  + 人工复核时间成本
  --------------------------------
  通过业务验收的结果数量

只有用相同 Golden Set 和验收标准，模型梯度才可以比较。关于自动路由的落地方式，可继续看多模型成本智能路由方案。

四、趋势四：缓存从优化项变成架构项

OpenAI、Anthropic 和 Google 的公开文档都把 Prompt / Context Caching 放在成本优化的重要位置，但实现细节并不相同：有的自动识别公共前缀，有的允许显式缓存点或 TTL，有的还会收取缓存写入与存储费用。

这会反向影响应用架构。为了提高命中率，系统提示、工具定义和共享知识应放在稳定前缀；每次变化的用户问题、时间和会话状态放到后部。团队还要记录缓存读写 token，而不是只看总输入 token。

缓存的经济性取决于复用次数。只调用一次的长文档，写缓存可能没有收益；同一知识库被持续问答，或 Agent 多轮重复携带工具定义，缓存更可能有效。不要把厂商宣传的最大折扣直接乘以总账单，应使用自己的命中率计算。需要更细的比较时，可阅读 OpenAI 与 Anthropic 缓存机制对比。

五、趋势五：token 之外的计费项会增加

模型逐渐从纯文本生成器变成带工具的执行环境。搜索、文件处理、代码执行、音视频、图片生成和托管检索可能采用按调用、按时长、按存储或按媒体 token 计费。此时只记录模型输入输出，会低估 Agent 的真实成本。

尤其要警惕循环：一次用户请求触发多轮搜索、工具调用和模型总结，每一步单价都不高，但调用次数没有上限时总额会快速放大。应把 Trace 中的模型、工具、缓存和失败重试统一归因到同一个业务请求。

财务报表也要从“供应商月账单”拆到产品功能。推荐至少保存：用户或租户、功能名、模型、服务等级、输入/缓存/输出 token、工具类型、调用次数、最终业务状态。具体实施可以参考按功能核算 AI 成本。

六、对开发者选型的直接影响

第一，价格比较器必须记录查询日期和来源，不能把旧表格当成常量写进代码。第二，网关需要保留原始 usage 字段，不要过早压成一个 total_tokens。第三，预算策略要能按模型、功能、租户和服务等级限额。

更实用的选型顺序是：先定义质量门槛和延迟上限，再比较满足条件的方案；然后用真实流量分布计算缓存、Batch 和路由收益；最后做小流量运行，核对厂商账单与内部账本。若两者长期无法对账，任何“节省百分比”都不可信。

对于通过中转或统一网关接入的团队，还要确认上游价格变化如何传导、usage 字段是否完整、缓存折扣是否可见，以及异常时能否导出请求级账单。统一接口的价值不只是少改 SDK，更是让不同厂商的成本字段进入同一套核算逻辑。

七、下一阶段更值得关注什么

未来最值得关注的不是谁再次下调基础输入单价，而是四个结构问题：缓存和 Batch 折扣能否稳定获得；不同服务等级的延迟与可用性是否可测；工具计费是否透明；模型升级后单位有效结果成本是否真的下降。

本文的判断是，模型能力仍会进步，基础推理成本也可能继续变化，但开发者账单不会因此自动变简单。价格维度越多，工程团队越需要任务分层、可观测性和成本归因。能把工作负载送到正确模型、正确队列和正确缓存策略的系统，往往比只追逐最低 token 单价更有韧性。