一、事件回顾：三大参数被正式弃用

2026年7月21日，Google在Gemini API官方文档中悄然发布了一条重磅更新：temperature、top_p和top_k三个经典的文本生成采样参数已被标记为「已弃用」（deprecated），在当前最新模型中被直接忽略。更关键的是，文档明确指出，在下一代模型中，如果用户继续传入这些参数，API将直接返回HTTP 400错误。

这意味着什么？对于无数开发者而言，temperature=0.7、top_p=0.9这些曾经写在每个LLM调用中的「标准配置」，正在被系统性地清除出API接口。Google建议的替代方案是：在system instruction中定义明确的规则来控制输出行为，而不是依赖底层采样参数。

几乎同一时间，Anthropic的Claude Sonnet 5也被发现移除了temperature参数支持（Sonnet 4版本仍保留），这表明弃用采样参数并非Google的孤立决策，而是整个行业正在形成的共识。

二、技术原理：为什么采样参数正在失效？

要理解这一变化，需要回到大语言模型的推理机制。Temperature控制的是概率分布的「锐度」——温度越低，模型越倾向于选择概率最高的token，输出越确定；温度越高，概率分布越平坦，输出越随机。Top_p（nucleus sampling）则截断概率累积达到p值的token集合。Top_k直接限制候选token数量。

然而，现代大模型的训练方式正在使这些参数失效。核心原因在于RLHF（基于人类反馈的强化学习）训练过程。在RLHF阶段，模型通过奖励模型学习什么样的输出是「好的」，这个过程隐式地塑造了模型的输出分布。当模型经过充分的RLHF训练后，其输出分布已经被精确校准——强行调整temperature会破坏这种校准，导致输出质量下降。

HN社区的讨论验证了这一推测。用户aesthesia指出：「RL训练使用的特定生成参数使模型对参数变化极其脆弱，这可能是我们看到各模型提供商纷纷做出此类改变的原因。」另一位用户salamo则提出了更深层的解释：Google可能在推理时动态调整这些参数——从低温度开始生成多个样本，逐步提高温度，直到某个样本通过质量门控。

三、推理时计算：新的范式正在崛起

弃用静态采样参数的背后，是「推理时计算」（inference-time compute）范式的崛起。传统的做法是用户设定一个固定的temperature，模型据此生成单一输出。但现代推理系统正在转向更复杂的策略。

以Best-of-N采样为例：模型内部可能生成N个候选回答（每个使用不同的隐式温度），然后通过奖励模型或验证器选择最优的一个。在这种模式下，temperature不再是用户需要关心的参数——它变成了推理系统内部的优化变量。Google建议用户使用system instruction来控制输出风格，本质上是将「如何生成」的决策权从采样参数层面上移到了语义层面。

这种转变也与推测解码（speculative decoding）技术有关。用户charcircuit在HN讨论中指出，采样参数会使推测解码的准确性降低，从而增加推理成本。当模型使用推测解码来加速推理时，固定的temperature值可能与草稿模型的分布不匹配，导致接受率下降。弃用这些参数可以让推理系统更自由地优化内部流程。

四、行业趋势：从「可调工具」到「黑箱系统」

Google和Anthropic的举措揭示了一个更大的趋势：大模型正在从「可调工具」演变为「黑箱系统」。在传统软件中，用户通过参数精确控制行为；而在新一代AI系统中，模型自身承担了更多的决策责任。

这并非孤例。OpenAI的GPT系列早已弱化了temperature的文档优先级，Anthropic的Claude在API中也建议开发者更多依赖system prompt而非采样参数。整个行业正在形成一种共识：经过充分训练的模型，其内部的生成策略已经优于用户手动设置的采样参数。

对于开发者而言，这意味着编程范式的转变。过去我们通过调整temperature来控制输出的创造性，通过top_p来过滤低概率token。现在，我们需要学会用自然语言（system instruction）来表达对输出的期望，让模型自己决定如何生成。这本质上是一种更高层次的抽象——从「控制生成过程」到「描述期望结果」。

五、对开发者的实际影响

这一变化对不同场景的影响各异。对于依赖低temperature获取确定性输出的场景（如代码生成、数据提取），开发者需要转向其他策略。Google建议的system instruction方法可以部分替代：在提示词中明确要求「输出确定性内容，不要使用创造性表达」，可能比设置temperature=0更有效。

对于需要多样性的场景（如创意写作、头脑风暴），新的方法可能是通过多次调用API并利用系统内部的多样性机制来实现，而不是手动调高temperature。一些第三方工具（如HN上刚发布的OpenCodex代理）正在尝试在代理层实现这种控制逻辑。

值得注意的是，这一变化也增加了API迁移的复杂度。现有的代码库中如果有大量基于temperature参数的逻辑，需要逐步迁移到基于system instruction的新范式。对于构建LLM应用的团队而言，这是一个需要认真规划的技术债务。

六、未来展望：模型自主性的边界在哪里？

弃用采样参数只是大模型自主性提升的一个缩影。随着模型能力的增强，越来越多的决策正在从人类开发者转移到模型自身。从temperature到stop sequences，从frequency penalty到presence penalty——这些曾经必要的API参数，正在一个接一个地变得过时。

这引发了一个深层问题：当模型完全接管了生成过程的控制权，我们还能在多大程度上「驾驭」它？如果模型内部的采样策略是不透明的，调试和可解释性将面临新的挑战。Google在文档中提到的「定义system instruction with explicit rules」听起来简单，但在实践中，自然语言指令的模糊性远大于数值参数的精确性。

无论如何，一个不可逆转的趋势已经形成：大模型正在从「被动工具」进化为「主动系统」。Temperature参数的弃用，标志着LLM推理从「用户控制」时代正式迈入「模型自治」时代。对于AI从业者而言，适应这一变化，学会与更自主的模型协作，将是未来几年的核心课题。