選擇 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 回應 API 的樣子：

from openai import OpenAI
import os

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

# 第 1 回合：在高努力下計劃
r1 = client.responses.create(
    model="gpt-6.1-sol",
    reasoning={"effort": "high"},
    input="找出為什麼這個 repo 的測試失敗並提出修復計劃。",
)

# 第 2 回合：在執行時降至低級別，而不觸及請求級別的努力
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 基準解釋