MiniMax-H3-Image 已在三個平台上推出：每個平台實際上為你提供什麼

本週關於 MiniMax-H3-Image 最簡短而真確的一句話是：它有三個取得管道——Hugging Face、MiniMax Code，以及 MiniMax 自家的 API。但買家真正需要的那句話更精確。這三者之中，有兩個給你請求端點和費率表；另一個則給你 135 GB 的權重、一份要你讀的授權條款，以及一個硬體決策。這並不是同一種存取方式的三種版本；若把它們當成可互換，團隊就會因此為某件事編列一週的預算，而那件事其實可以每張圖片兩美分買到。

這個模型本身是真正的發布，而非重新包裝。M​iniMax 將權重放進 Hugging Face 儲存庫MiniMaxAI/MiniMax-H3-Image，時間是 2026 年 11 月 10 日 14:50 UTC，並在同日下午 15:40 發文提及此事；該儲存庫本身可追溯至 11 月 3 日，這意味著權重在任何人能下載之前，已私下存在了一週。它是一個 331 億參數的擴散 Transformer，生成解析度約一千六百萬像素，也就是公告中所稱的「4K」，並且能從單一檢查點進行文字轉圖像與參考引導式編輯。以下內容將圍繞公告未解答的那個問題展開：你應該使用哪個介面。

三個入口，而其中只有一個是下載

先從每一扇門各自是什麼說起，因為差異是結構性的，而非表面上的。

這條API是常規途徑。模型列為 MiniMax-H3-Image，並有 Highspeed 同系列版本，於 MiniMax 的國際與中國大陸平台上提供，按輸入與輸出的每百萬個 token 計費，而非按每張圖片計費。這個介面的設計異常強勢——固定六個取樣步驟、沒有 guidance scale、沒有負向提示——而 MiniMax 自家的參考文件指出，任何要求其他設定的請求都會以 HTTP 400 回應。你買到的是一個可用的端點，內部搭載固定配方。

M​iniMax Code與Hailuo AI都是產品介面：同一個模型藏在提示框背後，取樣決策早已替你決定，你也無需自行做逐 token 的算術運算。適合用來評估輸出品質好不好；不適合用來建構任何東西，因為你真正要對接的對象並沒有被暴露出來。另外請注意，M​iniMax Code 是程式編碼代理產品，因此其中的圖像生成只是側門，而非主要功能——不要把「可在 M​iniMax Code 上使用」理解為一個包著程式碼外殼的圖像 API。

Hugging Face是第三扇門，也是唯一一扇屬於移轉而非服務的門。你會得到一個儲存庫、一份授權檔案，以及一組現在得由你設法跑起來的權重。自行託管正是多數團隊會考慮開放權重影像模型的原因；也正是在這裡，算數的重點不再落在模型上，而是開始落在你的機架上。

這個儲存庫比標題參數數量所暗示的還要沉重

BF16 下的 331 億個參數約為 66 GB，這還沒計入其他任何東西，而「其他任何東西」正是這個儲存庫讓人意外的地方。光是擴散 Transformer 就有 66.28 GB。完整下載為 68.65 GB，包含 Transformer 加上 VAE 與設定。文字編碼器不包含在該數字中：MiniMax-H3-Image 沿用 MiniMax-H3 影片儲存庫的 Qwen3-VL 文字編碼器，從其第 50 層讀取，而該編碼器是另外要拉取的 66.7 GB。換句話說，在生成第一張影像之前，請先在磁碟上預留約 135 GB 的成品，而且這還沒算上任何框架本身的快取。

這個架構值得用一段篇幅說明，因為它能告訴你這個模型是什麼。五十個 transformer 層、隱藏大小 5,376、56 個注意力頭、前饋寬度 14,336，並採用三維多模態旋轉位置嵌入。VAE 是卷積編碼器，搭配一個 24 層的二維 ViT 解碼器，具備 16× 空間降採樣與 24 個潛在通道——這個解碼器選擇在管線末端比單純的卷積解碼器花費更多運算，而且 4K 下的部分精細細節很可能就來自這裡。模型卡將此設計描述為 H3 架構減去音訊，這是個貼切的總結：這是影片模型的圖像分支，獨立發佈。

這會帶來兩個後果。首先，一個在 1600 萬像素下運作的 33B 級擴散 Transformer 並不是筆電能跑的模型，無論其參數量放在現代語言模型旁邊聽起來多麼像；活化記憶體會隨輸出面積而增加，而面積正是這次發布的全部重點。其次，由於文字編碼器與影片模型共用，已經在跑 MiniMax-H3 的商家，磁碟上早已有大部分的下載內容。那是實實在在的折扣，而這正是「可在 Hugging Face 上取得」這行字無法傳達的事。

四種供應方式，以及一個對不上的數字

模型卡列出四種途徑：SGLang、vLLM-Omni、diffusers 和 ComfyUI。vLLM 團隊在發布當日於 vLLM-Omni 中為 NVIDIA 與 AMD 硬體提供首日支援，原生輸出約一千六百萬像素，這比權重本身存在是更強烈的發布訊號——公告發布還不到一小時，MiniMax 外部就有人把它跑起來了。Diffusers 涵蓋參考路徑，ComfyUI 則涵蓋工作流程圖社群。

這個分歧值得標示出來，因為它總會讓某人踩坑。模型卡描述編輯時最多可使用 16 張參考影像，並依上傳順序以位置方式標示為 <Picture 1> 到 <Picture 16>。同一個模型的 vLLM-Omni 發佈配方則記載每個請求最多 9 張影像。這兩者可以同時成立——框架的服務上限和模型受訓容量是不同的數字，而服務堆疊中的批次或記憶體限制會先成為瓶頸——但如果你的工作流程需要十二張參考影像，今天誠實的答案是：能力確實存在，但文件記載的服務路徑可能無法承載。請在你的堆疊上實測這個數字，而不是信任任一份文件。

同樣的注意事項也適用於提示詞視窗。這張卡最多可接受 32,000 個字元，而模型實際上只會以其中約前 4,096 個 token 作為條件。過長的提示詞不會被拒絕，只是尾端根本沒有發揮作用。任何把語言模型的使用習慣搬過來、寫出詳細藝術指導提示詞的人，都會以昂貴的代價發現這一點。

取樣器是你繼承而來的限制，而不是你能調校的設定

六步，不啟用無分類器引導，不使用負向提示詞。這不是一個還留有上調空間的預設值；API 會直接拒絕其他步數與引導值。模型經過蒸餾，只須六次前向傳遞就能執行，而一個 33B 的 transformer 之所以能快到足以實用地回傳一張一千六百萬像素的影像，靠的正是這道蒸餾。

對 API 路徑來說，這點既不可見也無妨。對自架路徑來說，這則是規格表中最有用的單一數字，而且有兩重原因。它把每張影像的運算量上限壓在六次 Transformer 評估，而非非蒸餾模型所需的二十五到五十次，這正是讓一千六百萬像素在實務上可行的原因。同時也意味著這裡不存在慣常的自架調校迴圈——多試幾步、加入 guidance、加入負面提示詞、反覆迭代。如果輸出品質令人失望，可調整的槓桿是提示詞與參考圖，而不是取樣器。原本為「調校模型」編列一週預算的團隊，應該改把這週預算編給提示詞工程。

每條路徑的成本，以其實際計費的單位表示

API 以 token 計費，而卡片本身的計算範例是最清楚的解讀方式。1,024×1,024 的文字轉圖像請求為 $0.02179。2,048×2,048 的請求為 $0.02333——價格是 1.07 倍，像素卻是四倍，因為 token 數量的成長速度遠慢於面積。4,096×4,096 的請求牌價為 $0.06879，在限時 50% 折扣下則為 $0.03439；該優惠持續至 2026 年 11 月 17 日 16:00 UTC，且要求交付的影像至少達 16,600,000 像素。標準層級費率為每百萬輸入文字 token $2.30、每百萬輸入影像 token $1.50，以及每百萬輸出影像 token $3.80；Highspeed 層級維持相同輸入費率，輸出則收取 $7.60。

把這三個數字放在一起看，4K 的價格論點大致上就站不住腳了。在 2K 這一檔，用 1.07 倍的費用換到四倍像素，簡直是天上掉下來的禮物；從 2K 到 4K，同樣是四倍的面積增幅，成本卻要約三倍，只有折扣才把它拉回接近 2K 的費率。如果你的使用情境不需要單邊 4,096 像素，那麼 2K 這一檔才是這款機型便宜的地方。

OrcaRouter 不提供 MiniMax-H3-Image——這裡沒有它的路由，而本文的 CTA 指向影片版同系列模型 minimax/minimax-h3，我們確實有為它提供路由。我們目前提供的功能，會在這條路由存在的那天派上用場：0% 加成，並原樣傳遞供應商牌價，這表示像那筆 4K 折扣這樣的供應商價格變動，會在送達供應商頁面的同一天反映到你的帳單；若供應商路徑劣化，也會自動容錯切換。在那之前，真正重要的比較是 API 支出與自家硬體的成本對比，而任何路由層都改變不了這筆算術。

自架服務，誠實定價

在不知道你的 GPU 是什麼的情況下，沒有人能替你報出每張圖片的自架成本，因為主要變數在於 135 GB 的權重是能放進記憶體，還是必須卸載。能精確說的是：六步取樣器固定了運算量，一千六百萬像素的輸出固定了激活記憶體預算，而兩者都很大。單張 80 GB 顯卡放得下 transformer，但放不下全精度的 transformer 加上 Qwen3-VL 編碼器，因此現實可行的配置是多 GPU、卸載編碼器，或使用帶有品質疑慮的量化 transformer。再加上電力成本，加上讓 SGLang 或 vLLM-Omni 正常提供服務所需的工程師人週，相對於每張 2K 圖片 $0.02333 的損益兩平點，會是數十萬張圖片的量級，而不是幾十張。

在大多數情況下支持 API、在少數情況下支持權重的論據是：一家因資料因素而需要把模型留在自身邊界內的企業，或一家已在運行 MiniMax-H3 並持有編碼器的企業，或一家生成量已大到固定成本得以攤銷的企業。其他所有人都應先為 API 定價，只有在邊界確實要求時才自架。

在下載前先閱讀授權條款，而不是在下載後才讀

權重係依 MiniMax-H3-Image Community License Agreement 釋出，該授權並非 Apache 2.0，也非 MIT。{{1}}「開放權重」的說法準確；「開源」則是會讓團隊惹上麻煩的字眼，而這正是流程中應由律師閱讀實際文件、而非部落格文章（包括這篇）的時刻。實務問題在於大規模商業使用，以及該授權是否附帶會牽連到貴產品的條款；這個問題在儲存庫裡有答案，任何摘要都無法取代。{{/1}}

還有第二個較小、值得了解的產物：MiniMax 為該模型附帶了一個 Context-IR 元件，以及一個可選的提示詞擴展器模型 MiniMax-H3-Image-PE。擴展器部分解釋了該模型為何能容忍冗長而詳細的提示詞；它是可選的，與 68.65 GB 分開，而且它是你會在某個儲存庫清單中而非公告中看到的那類東西。

本週該檢查自己技術堆疊的哪些項目

• 參考資料 — 請以實際請求（而非只讀文件）確認您的服務路徑是支援 16 張圖片，還是 vLLM-Omni 配方文件所記載的 9 張。

• 有效面積 — 模型會在低於 1,600 萬像素的範圍內執行，而組態會提供一個預設為 4,194,304 像素的最小生成面積。如果你的使用情境是縮圖，請測試小尺寸的一端，因為這種規模的模型在 1K 時可能不是便宜的選項。

• 記憶體 — 購買硬體前，先測量 4,096×4,096 下的峰值 VRAM。六個步驟的運算成本很低；活化值則不然。

• 折扣倒數 — 若計畫採用 4K，50% 費率將於 2026 年 11 月 17 日 16:00 UTC 結束；而你使用的是 API 還是自己的硬體，將決定這個期限是否對你重要。

• 授權條款——讀一讀。下載檔案有 135 GB，而下載這個決定可以反悔；授權條款則不能。

這次發布有意思的地方，不在於出現了一個好的開放圖像模型——而在於這是好一陣子以來第一次，有一個模型出現時，權重、框架配方與託管端點全都在同一週內到位。這比基準測試圖表是更強烈的訊號，因為這意味著這東西真的能跑。你應該自己跑它，還是呼叫它，完全取決於你走進的是三扇門中的哪一扇，而這三扇門之間的距離，遠比公告聽起來的要大得多。