JSON 模式与模式定义的 token 成本
更新于 September 1, 2026 · 首次发布 September 1, 2026
请求结构化输出看起来像是格式上的选择。在账单上，它却是一个用量选择，并且同时落在三个地方。
模式是每次请求都要付的输入成本
响应格式或工具定义会被序列化进请求。一个中等规模的模式（十几个字段、每个字段都有描述、若干嵌套对象）大约是几百个 token。每次调用、每一轮、在功能的整个生命周期里都要乘上去，这个数字就不小了。一个 400 token 的模式乘以一百万次调用（400 × 1,000,000），就是 4 亿个输入 token，只为描述一个从不变化的结构。
更糟的是，在朴素实现中，模式通常位于提示词易变部分之后，这会破坏缓存前缀。于是模式每次都按全价计费，还会抵消它前面所有内容的折扣。
语法是输出成本
响应中的每一个大括号、引号、逗号和字段名，都是按输出单价计费的生成 token。冗长的字段名是一笔持续的固定开销：customer_shipping_address_line_one 永远比 addr1 贵。深层嵌套对象自身的骨架也要付费。对于包在大信封里的短答案，结构部分甚至可能超过内容本身。
重试才是真正昂贵的部分
主流提供商的约束解码让模式违规变得罕见，但校验失败依然会发生：模型无法诚实填写的字段、没有正确答案的枚举、对读者来说有歧义的模式。每次失败都要付出一次完整重试：所有输入 token 再来一遍，所有输出 token 再来一遍，外加延迟。在高流量端点上，2% 的无效率就意味着成本增加 2%，却没有任何回报。
实际该怎么做
把模式放进稳定前缀以便缓存，并在各次调用之间保持完全一致。只请求你实际消费的字段，因为多余字段要付两次费：一次在模式里，一次在响应里。优先使用短字段名和扁平结构。如果输出只是单个值，就不要把它包进对象。最后，测量你的校验失败率，这是其中唯一纯粹的浪费。
相关
相关文章
想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 →