GPT-Image-2.6 對上 GPT-Image-2.5：切換只是一個字串，帳單可不是

從 GPT-Image-2.5 遷移到 GPT-Image-2.6，就 API 層面而言，是 OpenAI 今年推出最不戲劇化的升級。同樣兩個端點、同樣的費率表、同樣的 Flare 對 Sunburst 的區分。模型字串改了，其他都不必動。這也是陷阱所在。GPT-Image-2.6 新增了一個 GPT-Image-2.5 從未有過的參數——複雜度旋鈕——而省略它並不會把它關掉。它預設為高。一條管線若只是換掉字串就上線，並不是用同樣的錢買到同樣的工作量；而是買到更多工作量，這就是為什麼遷移後的第一份成本報告可能出現變化，即使公告費率並沒有變。

兩個模型都以相同的商業條款正式全面推出，這正是這項比較不同尋常的原因。價格上沒什麼好爭的。爭論完全在於新增的工作量花在哪裡，以及你的流量型態是否正好能從中受益。

API 介面確實可以直接替換——只是其中有一個缺口。

OpenAI 於 2026 年 11 月 4 日推出 GPT-Image-2.6，且是以兩個 API 模型而非單一模型的形式發布，延續了它在 2.5 版所建立的結構。偏向細節與一致性的等級是 GPT-Image-2.6 Sunburst；速度等級則是 GPT-Image-2.6 Flare。它們的前代 GPT-Image-2.5 Sunburst 與 GPT-Image-2.5 Flare 維持相同名稱，彼此之間的關係也相同。

• 模型字串 — gpt-image-2.6-flare 與 gpt-image-2.6-sunburst 取代 gpt-image-2.5-flare 與 gpt-image-2.5-sunburst，命名邏輯相同，一個著重延遲、一個著重細節。

• 端點 — /v1/images/generations 與 /v1/images/edits，維持不變。沒有需要整合的新端點。

• 費率 — 每百萬文字輸入 token 為 $5，每百萬圖片輸入 token 為 $8，每百萬圖片輸出 token 為 $30，快取輸入則分別為 $1.25 與 $2.00。與 2.5 逐位元組完全相同。

• 品質層級 — 低、中、高、xhigh、最高與自動。同樣的階梯。

• 建議尺寸 — 1024×1024、1536×1024 與 1024×1536 依然是文件中的主要規格，同時也接受 16 的倍數的自訂尺寸，以及 1:3 至 3:1 的長寬比。

• 缺口——2.6 無法透過 Batch API 使用。如果你的圖片支出是靠半價的夜間作業來運作，那個作業目前還不會轉移過去。

最後那一行才是真正會出問題的地方。它上面的全部內容都只是字串替換和回歸測試執行。批次缺口對正是這類工作負載而言是架構層面的阻礙——大量目錄、夜間回填、大規模 A/B 生成——而 50% 折扣正是這些工作負載存在的根本原因。

複雜度旋鈕才是真正的功能，而它的預設值才是令人意外之處。

複雜度是一條新的軸線，它與品質並列，而不是包含在品質之中，而這個區別的重要性比聽起來更高。品質控制渲染：有多少輸出 token 投入圖像。複雜度控制規劃：模型在開始渲染前進行多少推理。你可以要求一張複雜場景的低品質圖像，或一張簡單場景的高品質圖像，而在 2.6 中，這些是真正彼此獨立的請求。

文件明確指出，省略該參數時會預設為 high。因此，呼叫端若只把模型名稱改成 2.6、其餘不動來移植 2.5 的請求，就等於在每次呼叫時都默默選用了最高的規劃預算。這不是 bug——對一個賣點是「能思考更多」的模型來說，這是合理的預設值——但這也確實意味著，2.6 流量的第一個月並不是與 2.5 流量最後一個月站在同一基準上的比較。

至少有一個公開數據點指向相同方向。11 月 4 日發布的一項三張圖像實測指出，2.6 輸出為 $0.1245，而相同靜態圖像在 2.5 上為 $0.0446——約為三倍，且費率表並未改變。三張圖像不是基準測試，也不應被當作基準測試引用；樣本規模太小，無法確立倍率。它確實能做到的是展示其機制，而該機制已有文件記載：每次請求有更多規劃 token，預設開啟，並以每百萬 $30 計費。

如果你只從本文採取一個操作步驟，就採取這一個。明確設定複雜度——medium 是對應 2.5 時代行為的合理初步猜測——然後測量前後的每次請求輸出 token 數。不要測量每次請求的美元成本。每次請求的美元成本只會告訴你費率卡沒變，這你早就知道。每次請求的 token 數則會告訴你，模型是否做了比你要求更多的工作。

宣稱的 50% 加速實際上落在何處

OpenAI 將 GPT-Image-2.6 描述為整體速度約提升 50%，但各層級的數據遠比這個標題數字更值得玩味，而且這些都是供應商自家的數據，並非經獨立實測。據稱 Flare 約為前代的 2.6 倍，低品質渲染最快六秒即可完成。據稱 Sunburst 約為 1.15 倍。

這兩個數字描述的是兩種完全不同的升級。如果你的 pipeline 是在迭代時執行 Flare——縮圖探索、提示詞調校，任何有人正在等待結果的情況——2.6 是階躍式的改變，單就注意力而言，遷移就值得了。如果你的 pipeline 是為了最終輸出品質而執行 Sunburst，15% 的延遲改善在大多數託管環境中屬於每次執行之間的雜訊範圍，速度根本不是遷移的理由。

值得誠實指出：同一個回報 token 膨脹的小型實測，也回報 2.6 在其三張圖像上比 2.5 更慢，這與廠商說法相矛盾。以 n=3 來說，那只是雜訊，不是反駁。但這提醒我們，「快 50%」是發表簡報中跨品質層級的彙總數字，而真實管線只會看到某一個品質層級、某一種品質設定。

還沒有人拿到 2.6 分，而 2.5 仍排名第一

這是大多數報導在比較中刻意輕描淡寫的部分。Artificial Analysis 在其 AA-Image-T2I v2.1 與編輯排行榜中，於 2026 年 11 月 5 日查閱時，根本沒有 GPT-Image-2.6 的列。不是分數低——是根本沒有列。

那些排行榜確實顯示出，被取代的模型仍在這些榜單上勝出：

• 文字轉圖像 — GPT-Image-2.5 Sunburst（max）以 13,153 票獲得 1,224 Elo，排名第一。GPT-Image-2.5 Flare（max）以 12,498 票獲得 1,207，排名第二。GPT Image 2（high）1,188，排名第三。

• 圖像編輯 — {{1}}GPT-Image-2.5 Sunburst (max){{/1}} 以 18,370 票中的 1,200 票位居第一。{{2}}GPT-Image-2.5 Flare (max){{/2}} 則以 19,259 票中的 1,183 票排名第三，落後於獲得 1,197 票的 {{3}}MAI-Image-2.7-Preview{{/3}}。

OpenAI 的發布資料引用 Design Arena，聲稱 2.6 Sunburst 拿下第一名。這是在真實榜單上的真實說法，但那是不同評分者池、不同量表，而供應商挑一個對自家發布最有利的榜單，對買家來說不構成任何可用的證據。2.6 目前還沒有可比的第三方投票數字。在出現之前，站得住腳的立場是：2.5 是兩大主要榜單上獨立評分最高的圖像模型，而 2.6 尚未獲得驗證——它在 OpenAI 所稱的那些特定面向確實更好，但在其他所有地方都未經測量。

一場一個下午就能完成的遷移

這種替換的成本夠低，所以明智的做法不是一次性全面遷移，而是循序漸進地進行，並且要用你自己的提示詞來跑，而不是用任何人的基準提示詞集。

先把複雜度固定在你選擇的數值上，這樣這項變更就是你主動做出的，而不是預設帶來的。接著重新執行生產日誌中幾百個真實提示詞——不是測試樣本裡那些乾淨的提示詞，而是有錯字、長寬比彆扭的凌亂提示詞。比較兩個數字：每張獲接受影像的輸出 token 數，以及每百次嘗試中獲接受的影像數。第二個數字才是一致性改善會顯現的地方，也是真正決定升級是否省錢的數字，因為你丟棄的影像會耗掉完整的 token 預算，卻毫無回報。

請為批次工作保留一條通往 2.5 的備援路徑，因為 2.6 目前尚無法支援這類工作。並且，請把任何 Sunburst 流量視為品質問題，而不是速度問題——如果接受率沒有提升，你換來的只是 15% 的延遲改善，以及更高的規劃成本。

當繼續使用 2.5 才是正確答案時

有三種情況已經夠明確，可以直接點名。批次工作負載應該維持不變，因為 2.6 不在 Batch API 上，而 2.5 在。Sunburst 品質管線應該維持不變，除非接受率測試顯示並非如此，因為 1.15 倍的加速不足以合理化成本模型的變更。而任何目前接受率已經可接受的人，都應該維持不變，因為新能力——SVG 匯出、動畫 GIF、標記引導編輯——是附加功能，不是品質改善，只有當你有需要這些能力的交付項目時，才需要它們。

這次升級確實是真的。只是它集中體現在 Flare 延遲與新的輸出格式上，而這些範圍比「一個新模型」所暗示的要窄。

可用性，以及分裂式遷移的棘手形態

OrcaRouter 今日以牌價、0% 加價提供 GPT-Image-2.5 Flare 與 GPT-Image-2.5 Sunburst，因此供應商的費率就是你實付的費率，上頭沒有再疊加任何利潤。截至 2026 年 11 月 5 日——亦即發布後翌日——GPT-Image-2.6 仍未收錄於目錄中，這使得眼前實際的問題在於路由，而非模型：在評測比拼期間，2.5 的流量透過單一金鑰運行並具備自動容錯移轉，而 2.6 的流量則依第二份合約、第二張帳單直接送往 OpenAI。

這個落差值得事先規劃，而不是等發現了才處理。在把正式生產路徑押在 2.6 之前，先查看型錄，因為對一個才問世二十四小時的模型，上線首日的一致性不是任何路由器能保證的。等它真的上線時，直通規則意味著當天你付的就是供應商的費率——OpenAI 那邊若調價，我們這邊不會重新協商就隨之生效——但在那之前，對情況最誠實的解讀是：2.5 可路由，2.6 還不行。

這是支持採行午後規模遷移、而非週末規模遷移的另一個理由。讓 2.5 走路由器，保持成本基準穩定，並在你衡量過複雜度預設值對 token 數量造成的影響後，再把 2.6 放在功能旗標後方加入。模型不會消失，而批次端點會在你的下一個季度規劃週期到來之前推出。