为 GPT-6.1 Sol 选择推理努力级别：低到最高

GPT-6.1 Sol 有五个推理努力级别： low, medium (默认), high, xhigh 和 max。与 GPT-6 Sol 的一个重大变化是 none 和 minimal 已经消失，因此 low 现在是最低级别。

这个设置影响延迟和成本。你看不到推理令牌，但你需要按输出费率为它们付费（在 AIHubMix 上，6.1 Sol 每百万 $10），并且它们会占用上下文窗口的空间。选择错误的级别，你可能会支付几倍于实际需要的费用。

每个级别的用途

此表结合了 OpenAI 的描述和我们自己的建议：

OpenAI 将努力称为“调节旋钮，而不是恢复质量的主要方式。”当结果不佳时，首先查看提示、工具定义和上下文。只有在那之后才提高努力。

基准测试对每个级别的评价

这些是 OpenAI 自己的数据，由 Vellum 和 DataCamp 整理而成。将其视为指南，而非绝对真理。

对于编码，高通常就足够了。 在 DeepSWE v1.1 上，6.1 Sol 在高的得分为 75.2，匹配高的 Astra（74.8），每个任务约 $1.50。其成本曲线在每个任务 $0.50 到 $1.50 之间达到 72% 到 75%。GPT-6 Sol 的最高得分为 68.8，约 $2.60。

高于中并不总是有帮助。 在 AutomationBench 上，6.1 Sol 在中得分 35.4%，而在更高努力下仅约 36.0%。对于业务自动化，额外的推理令牌几乎没有带来任何好处。

将最高留给计算机使用和研究。 在 OSWorld 2.0 上，最高得分为 71.4，约 $1.30 每个任务。Terminal-Bench Science 在最高下运行 $5.47 每个任务：远低于 Astra 的 $23.80，但比大多数其他工作负载高一个数量级。

低级别也有所改善。 低级别的事实错误率从 6 Sol 的 11.4% 降至 7.7%。如果你在 6 Sol 上将任务提高到中，因为低级别不够准确，可以再试试低级别。

按用例的起始点

这些 none 和 minimal 的映射来自 OpenAI 的 GPT-6 迁移指南。

在对话中途更改努力级别

一个常见的模式是高计划、低执行，当出现问题时再切换回高。

注意：在请求中编辑 reasoning.effort 会破坏你的提示缓存。 努力是缓存前缀的一部分（参见 提示缓存指南）。在 6.1 Sol 上，缓存读取的成本为每百万令牌 $0.10，而重写缓存的成本为 $2.50。这是 25 倍的差异。

GPT-6 系列通过 configuration_update 输入项解决了这个问题。 保持请求级别的 reasoning.effort 不变 并在下一个用户消息之前插入更新。以下是通过 AIHubMix Responses API 的示例：

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["AIHUBMIX_API_KEY"],
    base_url="https://aihubmix.com/v1",
)

# 第一次：高努力进行计划
r1 = client.responses.create(
    model="gpt-6.1-sol",
    reasoning={"effort": "high"},
    input="找出这个仓库的测试失败的原因并提出修复计划。",
)

# 第二次：在执行时降到低，而不触及请求级别的努力
r2 = client.responses.create(
    model="gpt-6.1-sol",
    reasoning={"effort": "high"},           # 不变，因此缓存得以保留
    previous_response_id=r1.id,
    input=[
        {"type": "configuration_update", "reasoning": {"effort": "low"}},
        {"role": "user", "content": "执行计划的第 1 步。"},
    ],
)

上述 configuration_update 的结构仅供参考。请查看 OpenAI 的推理指南以获取确切的架构。AIHubMix 的响应文档目前列出了四个级别（从最小到高），因此发送一个小的测试请求以确认 xhigh 、 max 和 configuration_update 是否通过。

需要了解的一些限制：

• 它仅在标准单代理模式下工作，并且仅更改努力。
• 两个更新不能相邻。
• 它不与自动压缩或截断混合。显式压缩是可以的，但之后添加一个新的更新。
• 响应的 reasoning.effort 字段仍然显示请求级别的值，因此不要过于解读它。

与努力相关的设置

在 max_output_tokens 中留出空间。 上限包括推理令牌。设置得太低，模型可能会在生成任何可见文本之前停止。你会得到 status: incomplete ，并且仍需为输入和推理付费。OpenAI 建议至少保留 25,000 个令牌 作为起始值，对于超高或最高则需要更多。

跟踪推理令牌。 它们在 usage.output_tokens_details.reasoning_tokens 中。查看每个努力级别的分布比凭感觉调节更好。

如果需要可见性，请开启摘要。 reasoning.summary: "auto" 返回模型推理的摘要（你可能需要先验证你的组织）。原始推理不会被暴露。

专业模式是一个单独的开关。 它使模型做更多的工作，按标准费率计费，但总体令牌更多。将其用于额外延迟可接受的困难问题。

一个你可以实际运行的调优过程

1. 将 20 到 50 个真实任务拉入评估集。
2. 在 medium 下运行基线。记录成功率、平均推理令牌和 P95 延迟。
3. 尝试 low 。如果成功率几乎没有下降，就切换。
4. 尝试 high 。如果成功率明显提高，仅对该任务类型使用高。
5. 仅在高不足时才选择 xhigh 或 max ，并在此期间与高的 GPT-6 Astra 进行比较。有时更大的模型胜过更多的努力。在 AIHubMix 上，这只是对 model 参数的更改， 模型列表 显示可用的内容。
6. 按任务类型路由，而不是使用一个全局设置。

简而言之： 从中开始，使用低节省资金，编码时使用高，并让超高和最高在你的评估中证明自己。

接下来：$2 / $10 的价格标签在缓存、长上下文和计费乘数生效后真正意味着什么。

常见问题

GPT-6.1 Sol 的默认推理努力级别是什么？ medium。如果你不设置，它就是你得到的。

为什么 none 会返回错误？ 6.1 Sol 不支持 none 或 minimal 。OpenAI 建议切换到 low 。如果你真的需要 none ，请继续使用 GPT-6 Sol 或 GPT-6 Luna。

推理令牌是如何计费的？ 按输出费率计费（6.1 Sol 每百万 $10），并且它们计入上下文窗口。查看 usage.output_tokens_details.reasoning_tokens 以获取实际数字。

在聊天完成和响应中参数名称是否相同？ 不相同。聊天完成使用顶级 reasoning_effort 。响应使用嵌套的 reasoning: {"effort": ...} 。混淆它们会返回 Unsupported parameter。

更高的努力总是能带来更好的结果吗？ 不。在 AutomationBench 上，高于中仅将得分从 35.4% 提高到约 36.0%，而成本明显更高。请在自己的任务上进行测试。

我可以在对话中途更改努力吗？ 可以。使用 configuration_update 项，并保持请求级别的 reasoning.effort 不变，以便提示缓存保持有效。它不与自动压缩或截断一起工作。

为什么我会得到 status: incomplete 而没有输出？ 最有可能是 max_output_tokens 设置得太低，推理用尽了所有令牌。OpenAI 建议至少保留 25,000 个令牌。

继续阅读：GPT-6.1 Sol 系列

• 你的账单中有多少是推理费用？ 努力只是一个杠杆。缓存、272K 阈值和批量折扣都影响最终数字。请参见 GPT-6.1 Sol 的真实成本：超越 $2 / $10 的价格标签。
• 使用过 none 的代码？ 切换到 low 只是开始。工具调用、采样参数和缓存设置也需要更改： 迁移到 GPT-6.1 Sol：9 个可能出错的地方。
• 6.1 Sol 比 6 Sol 和 Astra 好多少？ 规格和基准并排比较在 GPT-6.1 Sol 与 GPT-6 Sol：几乎追赶 Astra 的一周升级。

来源

• OpenAI：推理指南
• OpenAI：GPT-6 迁移指南
• AIHubMix：GPT-6.1 Sol
• AIHubMix：响应 API 文档
• Vellum：GPT-6.1 Sol 基准测试解释