MiniMax-H3-Image 與 GPT Image 2.6：在每次請求中你實際能變更什麼

大多數影像模型比較都把篇幅花在分數上。這篇則把篇幅花在可調參數上，因為 MiniMax-H3-Image 與 GPT Image 2.6 Sunburst 並不是在同一個調節盤上較勁。MiniMax-H3-Image 是開放權重的 33.1B 擴散 Transformer，於 2026 年 11 月 10 日發布，採用固定的六步取樣器、不設引導尺度，最多接受十六張參考影像，並可原生生成最高 1600 萬像素。GPT Image 2.6 Sunburst——以及它更快的兄弟型號 GPT Image 2.6 Flare，兩者均於 2026 年 11 月 4 日推出——則是封閉式的託管模型，其近期進步主要體現在你能交給它什麼，以及它會交還什麼：重複使用參考影像、以標記引導的編輯、GIF 與 SVG 輸出。如果你的瓶頸是控制漫長的編輯鏈，其中一款顯然合適；如果你的瓶頸是解析度或帳單，那就是另一款。

兩者都值得認真看待。它們只是失敗的方向不同，而單從控制介面就能看出其失效模式。

取樣器一邊是旋鈕，另一邊是常數。

MiniMax-H3-Image 幾乎沒有可供調整的空間，並且在 API 邊界上強制執行這一點。該檢查點經過 CFG 蒸餾，降至六次函數評估，這意味著擴散工作中常見的兩個調節旋鈕——步數與引導尺度——已被壓縮進權重之中。以 num_inference_steps 設為六以外的任何值來呼叫它，請求就會以 HTTP 400 傳回。將 guidance_scale 設為一以外的任何值，也會以相同方式遭到拒絕。傳送 negative_prompt 則會直接被拒絕，因為沒有第二次前向傳遞可供其作用。

那聽起來很受限，而且大多只是一種簡化。六步很快、給定種子時具確定性，而且不可能設定錯誤——不會出現「我把步數調高，結果反而更糟」這種失敗。你失去的是在模型內部以品質換取延遲的能力，以及你累積的任何負向提示詞技巧。

G​PT Image 2.6 以自身的小型控制介面取代取樣器旋鈕：一個複雜度參數預設為高，這是兩款模型最接近「更用力思考」開關的設計。其 2.6 的已記載新增功能在於輸入與輸出，而非取樣——參考影像會在後續編輯中持續保留，讓你不再需要重新上傳；可在參考影像上繪製標記以指示編輯；以及上一代未提供的兩種輸出格式。

• 步數 — MiniMax-H3-Image 固定為六步，其他值一律拒絕；G​PT Image 2.6 則未提供可調整的步數控制。

• 引導 — MiniMax-H3-Image 會將 guidance_scale 固定為 1；而 G​PT Image 2.6 則改為提供 complexity（預設為高）。

• 負面提示詞 — 會被 MiniMax-H3-Image 以 400 拒絕；在 G​PT Image 2.6 上並非有文件記載的介面。

• 提示詞預算 — MiniMax-H3-Image 會在 4,096 個 token 時截斷；GPT Image 2.6 的提示詞上限並未公布於其模型頁面。

十六個參考槽位是兩款型號中任一款所提供的最寬廣控制。

功能上最大的差異，在於你可以在編輯前放入多少上下文。{{1}}MiniMax-H3-Image{{/1}} 在單次請求中最多可接受十六張參考影像，而模型卡將編輯模式描述為可達到與生成大致相同的保真度——vLLM-Omni 移植版在 2048² 編輯上，相對於其自身的單 GPU 參考結果，回報 0.985 SSIM 與約 35 dB PSNR；這是自我一致性檢查，而非品質分數，但這確實意味著平行化路徑不會悄悄降低你的輸出品質。

十六張參考圖與「一張圖加一句話」是不同層級的控制。六個角度的產品攝影、一份風格表、一份角色設定表和一份品牌指南，全都可以一次放進去。這種廣度的代價是，提示工程變成了上下文工程：當十六張圖片同時參與時，文字必須說明哪一張圖主宰哪一項屬性，而模型無從發問。

GPT Image 2.6 對同一問題的答案在於記憶，而非寬度。參考圖片會在一個工作階段內的後續編輯中持續保留，因此多輪修圖不必每次重新上傳原圖；而標註引導的編輯路徑讓你直接指向某個區域，而不必用文字描述。就單一圖片的迭代作業而言，這比十六個靜態槽位是更好的介面。但對於用十幾個素材製作的一次性合成作品，則不然。

什麼會回傳出來

輸出格式清單正是 GPT Image 2.6 領先所有開放權重圖像模型（包括這個模型）的地方。2.6 版在常見的點陣格式之外，新增了動畫 GIF 輸出與 SVG 輸出。SVG 結果的重要性比聽起來更高：它決定了圖像模型只是用來草擬標誌概念，還是能直接交給前端使用。MiniMax-H3-Image 回傳 PNG——其服務路徑是以逐位元相同的 PNG 比對來驗證——而 vLLM-Omni 管線或模型卡中沒有任何跡象顯示支援向量或動畫輸出。

解析度方面的情況正好相反，而且差距並不小。{{1}}MiniMax-H3-Image{{/1}} 原生可生成最高 {{2}}一千六百萬像素{{/2}}，涵蓋從正方形到超寬比例的每種長寬比，過程中不使用任何升頻器——{{3}}4096×4096{{/3}} 與 {{4}}6272×2688{{/4}} 都是原生輸出。可用範圍約為 {{5}}四百萬到兩千萬像素{{/5}}，品質在接近上限時達到高峰。{{6}}G​PT Image 2.6{{/6}} 的模型頁面記載了格式與參考處理方式，但未公布最大像素數，因此這場對決中的解析度論點，是 {{7}}M​iniMax{{/7}} 公布了數字，對上 {{8}}O​penAI{{/8}} 並未公布，而非經過實測的正面交鋒。

• 原生輸出 — MiniMax-H3-Image 在任何比例下最高可達 16 MP，無需升頻器；G​PT Image 2.6 未記載上限。

• 格式 — MiniMax-H3-Image 回傳 PNG；G​PT Image 2.6 額外支援 GIF 與 SVG。

• 長寬比 — MiniMax-H3-Image 接受任意寬度與高度組合；G​PT Image 2.6 的設定並未在各模型頁面公布。

• 編輯輸入 — MiniMax-H3-Image 每次請求最多接受 16 張參考圖像；G​PT Image 2.6 可跨回合保留參考圖像，並接受手繪標記。

該法案，依據各供應商自行提供的計算範例

兩家廠商都把圖片計量為 token，這讓標價看起來相當，但每張圖片的成本卻看起來完全不同。M​iniMax 在其定價頁面上公布了計算範例，所以這是對他們自家數字做算術，而不是推導：

• MiniMax-H3-Image 1024×1024，文字生成圖像 — 每張圖像 $0.02179，相較於每百萬輸出 token $3.80。

• MiniMax-H3-Image 2048×2048 — 每張圖片 $0.02333。像素加倍只需多花半美分，因為在此區間末端，token 數量的成長速度遠慢於面積。

MiniMax-H3-Image 4096×4096 — 每張圖片 $0.06879，在限時五折優惠下調降至 $0.03439；該優惠持續至 2026 年 11 月 17 日 16:00 UTC，且要求交付的圖片至少達 16,600,000 像素。

• MiniMax-H3-Image 編輯，一張 1024×1024 參考圖 — 每張圖片 $0.02654，輸入圖片以每百萬 tokens $1.50 計費，輸入文字則為每百萬 tokens $2.30。

{{1}}G​PT Image 2.6 — 每百萬個輸出 token 為 30 美元。以 O​penAI 自家文件對 1024×1024 結果所暗示的 token 數量計算，每張圖片約為 21 美分，大約是相同標稱尺寸下 M​iniMax 數字的十倍。{{/1}}

速度也不同，而這正是這兩款產品不再可互換的地方。根據 MiniMax 在 11 月 4 日發佈版本中公佈的數字，GPT Image 2.6 Flare 執行文字轉圖像請求的中位數約為 30 秒，低於上一代的約 55 秒；編輯約 32 秒，低於約 58 秒。Sunburst 是較慢、保真度較高的層級，而且變得更慢——約 135 秒，對比 113 秒。MiniMax-H3-Image 自身的延遲只有在你自己託管的地方才能測量：根據官方配方，在四張 H200 上，2048² 圖像為 0.88 秒，2048² 編輯為 1.35 秒。這些不是同一類數字——自託管節點延遲與託管端點包含排隊時間的中位數——若把它們放在同一句話裡當作同類數字，會是不誠實的。這個比較合理說明的是：託管的 2.6 請求需要數十秒，而本機 H3-Image 請求不到兩秒，前提是你已經擁有那四張 GPU。

公開證據涵蓋了什麼，以及它沒有涵蓋什麼

Artificial Analysis 在同樣的兩個排行榜上為兩者評分，這使得這成為這場對決中少數雙方可以直接比較、而非根據規格表爭論的地方之一。在 AA-Image-Editing v2.1 上，G​PT Image 2.6 Sunburst 以約 6,400 個樣本達到 1,210 Elo，Flare 以約 6,700 個樣本達到 1,206，而 MiniMax-H3-Image 以約 3,200 個樣本達到 1,138，排名區間為第八到第十七名。在 AA-Image-T2I v2.1 上，差距擴大：Sunburst 以 5,282 個樣本拿下 1,261 分、排名第一，而 MiniMax-H3-Image 為 1,066 分、排名第二十三。相同的投票池、相同的 Elo 量表，兩者在編輯上相差約七十分，在生成上相差近兩百分。

老實讀一遍，它同時道出兩件事。MiniMax-H3-Image 是影像編輯排行榜上排名最高的開放權重模型——領先得分 1,085 的 Fibo 2.0 與 1,084 的 Qwen-Image-2.1——因此它的品質主張不再是斷言，而是實測數字。但這個數字比 G​PT Image 2.6 Sunburst 低約七十 Elo，而且它的信賴區間橫跨十個名次，Sunburst 的前三名區間則沒有。在兩款模型最明顯共同的那個軸線上，G​PT Image 2.6 勝出，而且在 H3-Image 較弱的那個排行榜上，它贏得更多。1,600 萬像素解析度的論點與兩美分的價格依然站得住腳；只是它們不是品質論點。

兩邊的排行榜都沒告訴你的是：當任務正是本文所談的那一種——一條參照眾多、取樣器固定的長編輯鏈——GPT Image 2.6 的優勢還剩多少。Elo 是針對未知提示的人類偏好所做的彙總指標，而一個模型可能在這個彙總指標上領先七十分，卻在特定工作流程上落敗。唯一能查明的方法，就是把你自己的提示分別丟進兩邊跑一遍；這是本文結尾的建議，而不是文中隨口的一句保留話。

無需第二份合約即可並行運行它們

實務上的麻煩在於，對多數團隊來說，這兩個模型都不是呼叫一次 API 就能取得。MiniMax-H3-Image 首日可用的途徑是自架——整體是由 33.1B 的 transformer、33.4B 的 Qwen3-VL 文字編碼器（直接沿用影片模型、未經修改），以及 0.58B 的 VAE 組成，總計 67B；若要達到 1600 萬像素的最佳設定，全速運行需要四張資料中心 GPU。它也可透過廠商自家的 API 及數個第三方平台取得，價格依上述 token 計價。G​PT Image 2.6 則僅限 O​penAI。

如果你想用自己的提示詞對這兩者做 A/B 測試，對路由層的誠實描述是這樣：OrcaRouter 尚未支援 MiniMax-H3-Image，也尚未支援 GPT Image 2.6 Sunburst 或 Flare。它支援的是前一組 GPT Image 型號——gpt-image-2.5-sunburst 與 gpt-image-2.5-flare——以及 gpt-image-2 和 gpt-image-1.5，全部 以供應商牌價提供，且不額外加收轉嫁費用。這構成一個有用的中間測試：透過單一金鑰針對 2.5 建立測試框架，確認你的評估確實能區分 Sunburst 的保真度與 Flare 的速度，然後再決定你真正需要的是 2.6 的差異，還是自架式的開放權重模型。模型融合是這裡另一個值得了解的選項——讓一組模型回答同一個影像提示，就能針對每個提示獲得各種輸出，而不必自己寫三個用戶端。

順帶一提，反向的情況已經涵蓋了：minimax/minimax-h3，這款影片模型的 DiT 與文字編碼器正是 MiniMax-H3-Image 的建構基礎，而它今天已經可以路由。如果你之所以關注這個圖像模型，是因為你已經在跑 H3 影片，那麼這個系列早已能用同一把金鑰提供服務。

該選哪一個

當限制條件是像素、參考圖像或單位成本時，選擇 MiniMax-H3-Image：原生輸出 1600 萬像素、十六張輸入影像，以及每次 1024² 生成約兩美分。當限制條件是輸出形態或編輯迴圈的順暢度時，選擇 G​PT Image 2.6：輸出端提供 SVG 與 GIF，輸入端接受持續保留的參考圖像與手繪標註，並在編輯排行榜上領先七十 Elo，背後還有前三名的區間。

如果你真正需要的是針對你自己的提示詞的評分，那就放心兩者都不選。這兩個模型現在都有公開評分，而這兩個評分都是對別人提示詞的彙總結果；能決定你的情況的比較，是你自己跑的那一次，而且比較的兩邊都各自附帶帳單。排行榜能給你的是先驗——GPT Image 2.6 領先，而且在文生圖上領先幅度足夠大，你應該預期會看到這一點。它買不到的是：四百萬像素、使用十六張參考圖的產品合成圖的答案，因為沒有人發表過那項比較，Elo 排行榜也不衡量它。