温度与种子：LLM提取成本翻倍的隐藏开关

同一批10万次JSON提取任务，账单可能是667美元，也可能是1100美元——而每token的价格纹丝未动。差价不在供应商的价目表上，而在你代码里那两个从教程里抄来就再没碰过的参数：temperature和seed。

为什么单次调用的价格不变，总账单却能翻倍

先厘清几个基础概念。token大约是¾个单词，API按百万token计费，输入和输出分开定价。temperature控制模型挑选下一个token时的冒险程度：0意味着几乎总是选概率最高的那个，1以上则把赌注撒开。seed是一个让随机选择可复现的数字——相同的seed、相同的输入，通常得到相同的答案。validation是你的代码在使用答案前的检查：它能解析成JSON吗？必需字段都在吗？

这两个旋钮都不在发票上。temperature 0和1.2的同一个请求，计费完全相同——输入token数乘以输入单价，加上输出token数乘以输出单价。

以一个具体任务为例：从客服工单中提取五个字段并以JSON返回。假设1500个输入token（指令加工单）和300个输出token。按GPT-5.6官方定价每百万输入2美元、每百万输出12美元计算：

1,500 × $2 / 1M + 300 × $12 / 1M = $0.0030 + $0.0036 = 每次调用0.0066美元。

任何temperature下都是这个数。变化的是你为它付多少次钱。

一次失败的回答到底让你多花了多少

API返回了200 OK，你被计费了，但答案长这样：{"priority": "high", "summary": "Customer says "refund" ...——一个未转义的引号，一条尾随注释，或者前面来一句友好的“Sure! Here's your JSON:”。解析器抛出异常，代码重试，你再付一次钱。

高温会提高这种失败的概率，原因很朴素：合法的JSON是一条窄路，每一个偏离最可能token的采样都是一次踏出这条路的机会。设p为通过验证的答案比例。如果你一直重试到有一个通过，期望尝试次数是1/p，因此完成一个任务的成本是单次调用价格 ÷ p。

原文给出的代码示例清晰地展示了这一点：

CALL = 1_500 * 2.00 / 1e6 + 300 * 12.00 / 1e6   # $0.0066, GPT-5.6 official
TASKS = 100_000

for p in (0.99, 0.90, 0.75, 0.60):
    attempts = 1 / p
    print(f"p={p:.2f}  attempts={attempts:.2f}  bill=${CALL / p * TASKS:,.0f}")

结果如下表：

有效比例p	每任务尝试次数	10万任务总账单
0.99	1.01	$667
0.90	1.11	$733
0.75	1.33	$880
0.60	1.67	$1,100

需要明确的是：这些p值是示意性的，而非实测的。原作者并未为这篇文章跑温度扫描，你的p取决于模型、提示词和schema。算术是精确的，但输入是模型设定的。把每次验证失败和当时使用的temperature一起记录下来，一天之内你就能得到自己的p。

期望尝试次数的推导：设每次调用通过验证的概率为p，且各次调用相互独立，那么直到首次成功所需的尝试次数服从几何分布，其期望值为1/p。这是几何分布的经典结论——例如p=0.75时，期望尝试次数为1.33次，即平均每个任务需要1.33次计费调用。这里隐含一个前提：每次重试都是独立同分布的采样。如果重试时seed和temperature完全不变，独立性假设就被破坏，模型会复现相同的输出，此时1/p的公式不再成立，成本可能趋向无穷。因此"单次价格除以p"的算术只有在每次尝试真正引入新随机性时才可靠。

种子设置不当，重试可能完全白费

这里有一个把1/p变成无穷大的陷阱。如果你为了可复现性固定了seed——这在测试中是良好习惯——然后用相同的seed、相同的temperature和相同的提示词重试，你是在要求模型重复自己。它会照做，连那个坏掉的逗号一起。每次重试都被计费，但没有一次获得新的通过机会。（seed的确定性是“尽力而为”，所以你也许能撞上好运，但不要建立在这种运气上。）

所以重试必须改变某些东西。去掉或调整seed，在重试时降低temperature，或者把解析错误追加到提示词中让模型知道要修复什么。最后一种方法会给每次重试增加输入token——那300个token的坏答案加上错误消息——所以重试比首次调用略贵，上面的表格是下限而非上限。

同时要限制循环次数。最多3次尝试、p=0.75时，平均尝试1.31次而非1.33次，但有1.6%的任务（0.25³）会永久失败——你宁愿知道这一点，也不愿为第十一次尝试付费。

structured output（结构化输出） 是主流LLM供应商提供的一种约束解码机制。普通的JSON mode只保证输出是合法JSON，但不保证字段符合你的schema；而structured output允许你在请求中附带一个JSON Schema（如字段名、类型、枚举值、必填项），推理时模型被约束为只能生成符合该schema的token序列。实现方式通常是在解码阶段对不符合schema的token施加屏蔽（grammar-constrained decoding），因此理论上可以让"能否解析"这一部分的通过率接近1。它无法保证字段值的语义正确性，也无法覆盖schema未声明的约束，但对消除格式类失败极为有效。使用前需确认所用模型和API版本是否支持，并注意首次使用schema可能带来的少量延迟开销。

周一上班就能做的三件事

把temperature设为0，适用于任何需要解析器读取的输出。然后如果供应商支持，使用结构化输出模式——请求携带JSON schema，模型被约束为生成匹配该schema的文本，这会把“能否解析”部分的p推向接近1。最后，开始计数。一个简单的计数器validation_failures / calls就是你的p，而价格 ÷ p才是你每个任务的实际花费。

原文还提到了成本优化的另一个杠杆：同样的GPT-5.6，官方价每百万输入2美元、输出12美元，批量渠道可以做到1.70/10.20，即15%折扣。在p=0.60时，这把1100美元变成935美元。而把p修复到0.99、用官方价，则能到667美元。折扣只是把账单乘以一个固定数字，而1/p可以乘以任何数字。先做便宜的事。

批量API（Batch API） 是多家供应商提供的异步折扣通道：你把大量请求打包成一个文件提交，供应商在承诺的时间窗口内（如24小时）处理完成，价格通常是同步接口的50%左右，本文中GPT-5.6的15%折扣即属此类。它适合离线、非实时、可延迟的任务，例如本文的10万次JSON提取——这类任务没有用户在前台等待，完全可以走批量渠道。需要注意，批量渠道的折扣是乘在单价上的固定系数，它不会改变验证通过率p，因此与降低temperature、启用structured output是正交的优化手段：前者缩小每次调用的价格，后者减少需要计费的调用次数。两者叠加时，总成本为 单次价格 × 折扣系数 ÷ p × 任务数。

这套方法解决不了什么

合法的JSON不等于正确的JSON。schema能保证priority字段存在，但阻止不了模型填错优先级，而且这类失败根本不会触发重试——它们直接溜进你的数据库。低温也不是对所有任务都合适：头脑风暴时它产出扁平、重复的文本，而且那里本来就没有什么可验证的。网络错误或超时是另一套重试预算，有它自己的算术。

去翻翻你提取代码里的temperature设置。如果它写着0.7是因为某个快速入门教程这么说的，你现在已经知道部分账单花在哪里了。