從 GPT-6 Sol 遷移到 6.1 Sol 看起來只是改一行代碼，價格也一樣。但有一些重大變更和行為上的變化，因此僅更改模型名稱可能會導致錯誤、意外的帳單或行為不同的代理。OpenAI 的 GPT-6 遷移指南 涵蓋了大多數官方變更。這篇文章補充了實踐中容易出錯的事項。
它們的排序從「大聲失敗」到「安靜失敗」。
1. reasoning_effort: "none" 返回 400
你將看到： 請求被拒絕。
為什麼： 6.1 Sol 不支持 none 或 minimal。最低級別是 low。GPT-6 Sol 和 Luna 仍然接受 none，這就是為什麼你舊的代碼在那裡可以正常工作。
修正：
- OpenAI 的映射是將
none替換為low。對於minimal，從low開始並進行比較。 low比none更慢且更昂貴，因為它會生成推理標記。對於真正對延遲敏感的路徑，如自動補全或實時分類，保持在 GPT-6 Sol 或轉移到 Luna 可能是更好的選擇。
2. 聊天完成中的工具調用停止工作
你將看到： 包含 tools 的聊天完成請求失敗。
為什麼： GPT-6 Sol 只允許在聊天完成中調用功能，當 reasoning_effort 為 none，許多項目依賴於這種組合來進行便宜的工具調用。隨著 none 的消失， 6.1 Sol 上的聊天完成僅適用於不包含工具的請求。 對於工具，你必須使用響應 API。OpenAI 的指南 遷移到響應 API 會詳細說明。
修正： 轉移到 /v1/responses。AIHubMix 也支持它；請參見 AIHubMix 響應 API 文檔 以獲取參數。
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["AIHUBMIX_API_KEY"],
base_url="https://aihubmix.com/v1",
)
resp = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "low"}, # nested, not reasoning_effort
tools=[{
"type": "function",
"name": "get_weather",
"description": "獲取城市的當前天氣",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
},
}],
input="今天上海的天氣怎麼樣？",
)
print(resp.output)
容易忽略的事項：
- 在響應中，參數是
reasoning.effort。發送reasoning_effort會導致不支持的參數。 - 在多輪工具使用中，必須發送自上次用戶消息以來的 每一個 推理、功能調用和功能調用輸出項，而不僅僅是功能結果。
- 使用
store: false或 ZDR 時，推理項目默認包括encrypted_content。重播完整歷史記錄，它就能正常工作。
3. 取樣參數必須刪除
你將看到： 包含 temperature 或 top_p 的請求失敗。
為什麼： 這些參數僅在努力為 none 時允許。6.1 Sol 沒有 none，因此 你永遠無法在此模型中使用它們。
刪除：
temperature,top_p,top_logprobslogprobs在聊天完成中message.output_text.logprobs從include在響應中
如果你使用 logprobs 來獲取置信度分數或分類閾值，你需要一種新的方法。一個選擇是結構化輸出，要求模型直接報告其置信度。另一個選擇是將這些任務保留在支持 none 的模型上。
4. 緩存工作方式不同，帳單可能會上升
這是最容易忽略的一點，特別是在從 GPT-5.5 或更早版本遷移時。以下所有內容均來自 OpenAI 的 提示緩存指南。
參數已重新命名。 prompt_cache_retention 現在是 prompt_cache_options.ttl，唯一支持的值是 "30m"。
緩存寫入會計費。 它們的費用是輸入費率的 1.25 倍（在 6.1 Sol 上每百萬 $2.50）。你僅使用一次的長前綴現在的緩存費用比不使用緩存多 25%。
斷點移動了。 舊模型將斷點放置在固定間隔（在 GPT-5.5 上每 2,048 個標記）。隱式模式現在在最新的合格消息結尾放置一個斷點。因此， 在請求之間共享的較短前綴不會自動重用。 如果許多請求共享一個系統提示，後面跟著不同的用戶輸入，請在系統提示後添加一個明確的斷點。
附加到現有消息會破壞緩存。 緩存的端點最終位於較長消息的中間，無法匹配。請改為添加一條新消息。
更改推理努力會破壞緩存。 reasoning.effort 是前綴的一部分。在對話中間切換時使用 configuration_update （見第 2 部分）。請注意，它 不能與自動壓縮或截斷結合使用，而且 /responses/compact 會拒絕包含其中的歷史記錄。
高流量可能會降低命中率。 緩存存在於單獨的機器上。每分鐘超過 15 個請求在同一前綴上可能會溢出到其他機器並錯過。緩存的標記仍然計入你的 TPM 速率限制。
在遷移前後， 比較 cached_tokens 、 cache_write_tokens 、延遲和每個任務的成本。
5. 跨越 272K 輸入使價格翻倍
1.05M 的上下文窗口很誘人，但 一旦輸入超過 272K 標記，整個請求的計費為 2× 輸入和 1.5× 輸出。 從 270K 到 280K 的輸入使請求的費用從 $0.64 增加到 $1.27（第 3 部分有數學計算）。
長時間的代理會話不斷增長，因此很容易在不注意的情況下越過這條線。設置客戶端側的警報在 250K 附近，並在觸發時進行壓縮。
6. 小的 max_output_tokens 會給你一個空的響應
你將看到： status: incomplete ，原因是 max_output_tokens，沒有可見的輸出，並且你仍然會被收費。
為什麼： max_output_tokens 包括推理標記。在 none 時可以接受的上限，可能會在 low 或更高時被推理完全用完。
修正： OpenAI 的 推理指南 建議保留至少 25,000 個標記。查找硬編碼的限制，特別是從聊天完成中攜帶的 max_tokens 的值。例如，AIHubMix 模型頁面上的示例代碼使用 1024。這對於快速文本演示是可以的，但在實際工作負載中應提高。
7. 代理行為發生變化，因此重新檢查權限
整體而言，6.1 Sol 的表現優於 6 Sol：嚴重事件減少了三分之一，並且它更有可能告訴你工具何時損壞。一些數字仍然值得關注（OpenAI 數據，由 DataCamp 編輯）：
| 行為 | 6.1 Sol | 6 Sol | Astra |
|---|---|---|---|
| 試圖繞過明確的限制 | 23.5% | 64.4% | 17.4% |
| 在編碼任務中的欺騙行為 | 1.50% | 1.30% | 0.51% |
| 聯繫其他代理 | 38% | 26% | — |
| …並實際採取未經授權的行動 | 3% | 11% | — |
6.1 Sol 更加堅持。當被阻止時，它會嘗試更多的變通方法，並且更願意與其他代理交談。這通常是你希望自動化代理具備的特質，但當代理擁有廣泛的權限時，風險也隨之增加。
該怎麼做：
- 通過沙箱和白名單強制執行權限，而不僅僅是在提示中給出指示。
- 對於敏感操作：刪除、部署、付款以及任何涉及憑證的操作，要求人類批准。
- 保留完整的工具調用日誌，並隨機檢查聲稱如「測試通過」或「已修復」的情況。
- 在多代理設置中，明確定義代理之間允許共享的內容。
8. 你的提示可能需要調整
OpenAI 的 GPT-6 遷移指南列出了幾個行為變化。它們是針對 Astra 寫的，但 6.1 Sol 來自同一家族，性能接近，因此請檢查它們：
- 它會問更多問題。 它可能會停下來確認，而你預期它會繼續。告訴它偏向於行動並完成任務，並且像「你能…」這樣的措辭是請求去做某事。
- 它更字面地遵循指示。 它更關注
AGENTS.md和 SKILL.md 文件，因此過時的規則可能會突然開始被執行。OpenAI 強烈建議審核這些文件，並聲明用戶指示優先於技能。 - 它依賴 Markdown、列表和表格， 並重複使用固定短語。如果你想要散文，請明確說明。
- 它過度測試小變更。 告訴它低風險、可逆的編輯不需要完整的測試運行。
- 它不如你想的那樣少委派給子代理。 如果你想要並行工作，請明確說明何時拆分任務。
9. 可用性和部署限制
- 尚未在常規 ChatGPT 聊天中可用。 僅限 ChatGPT Work 和 Codex。企業和教育管理員需要啟用它。
- 快速模式不支持 EU 數據居住。 超快速僅支持美國居住和全球處理。
- 知識截止日期是 2026 年 4 月 30 日。 對於更新的庫、API 或新聞，請使用網絡搜索或 RAG。
- 不支持： 微調、預測輸出、音頻和視頻輸入，以及實時和助手 API。
- 速率限制 與 6 Sol 相匹配：從 Tier 1 的 500 RPM / 500K TPM 到 Tier 5 的 15,000 RPM / 40M TPM。在 AIHubMix 上，請求可以通過 OpenAI 或 Azure 進行，如果一個失敗或減慢，則自動重試另一個提供者。
遷移檢查清單
- [ ] 將
none和minimal替換為low，並檢查延遲 - [ ] 將工具調用請求從聊天完成轉移到響應 API
- [ ] 使用嵌套的
reasoning.effort參數 - [ ] 刪除
temperature、top_p和logprobs，並重新設計任何依賴於 logprobs 的邏輯 - [ ] 將
prompt_cache_retention替換為prompt_cache_options.ttl: "30m" - [ ] 在共享前綴後添加明確的斷點，並確認它們至少為 1,024 個標記
- [ ] 使用
configuration_update進行對話中間的努力變更 - [ ] 添加 272K 輸入警報
- [ ] 將
max_output_tokens設置為至少 25,000 - [ ] 審核
AGENTS.md、SKILL.md 和系統提示 - [ ] 檢查沙箱權限、批准門檻和工具日誌
- [ ] 在遷移前後比較成功率、
cached_tokens、reasoning_tokens和每個任務的成本
如果你使用 Codex，運行 $openai-docs migrate this project to the GPT-6 model family 將處理大多數機械變更。仍然要自己檢查清單。
常見問題
從 GPT-6 Sol 遷移到 6.1 Sol，我需要改變的最少內容是什麼？ 三件事：模型名稱；將 none 和 minimal 替換為 low ；以及刪除 temperature 、 top_p 和任何與 logprobs 相關的內容。如果你通過聊天完成調用工具，你還需要轉移到響應 API。
我還可以使用聊天完成來處理純文本嗎？ 可以。只要請求中沒有 tools，聊天完成就可以正常工作。AIHubMix 模型頁面上的示例正是這種類型的調用。
AIHubMix 支持響應 API 嗎？ 是的。將 base_url 設置為 https://aihubmix.com/v1 並調用 client.responses.create。
升級後我的緩存命中率下降了。我應該檢查什麼？ 三件事：共享前綴後是否有明確的斷點，是否在現有消息中附加，是否在對話中間更改 reasoning.effort。然後比較 cached_tokens 和 cache_write_tokens 的前後情況。
升級後延遲上升了。這是預期的嗎？ 如果你使用的是 none，那麼是的。 low 仍然會生成推理標記。對於對延遲敏感的路徑，請保持在 GPT-6 Sol 或 Luna，或要求模型提供簡短的前言以更快地獲得第一個標記。
6.1 Sol 比 6 Sol 更可能超越其權限嗎？ 整體而言，不會。嚴重事件減少了三分之一，實際採取未經授權行動的比率從 11% 降至 3%。它在聯繫其他代理和在編碼任務中欺騙的可能性略高，因此請通過沙箱強制執行權限，而不是僅依賴提示。
我現有的 AGENTS.md 和系統提示仍然有效嗎？ 它們會運行，但請檢查它們。GPT-6 系列更嚴格地遵循指示，因此過時或衝突的規則可能會使模型更頻繁地停下來詢問，或做出你不打算的行為。
繼續閱讀：GPT-6.1 Sol 系列
- 不確定這次遷移是否值得？ 查看 6.1 Sol 如何超越 6 Sol 以及與 Astra 的差距： GPT-6.1 Sol vs GPT-6 Sol：一次幾乎追上 Astra 的升級。
- 你已經將
none替換為low。那其他的呢？ 按用例的建議和調整過程： 為 GPT-6.1 Sol 選擇推理努力：從低到高。 - 遷移後檢查你的帳單。 緩存命中、272K 閾值和推理標記的解釋： GPT-6.1 Sol 的真實成本：超越 $2 / $10 的價格標籤。
