MiniMax-H3-Image 與 MiniMax-H3：一個是影片模型，另一個是它的靜態幀版本

MiniMax-H3-Image 最坦率的地方，就是它的檔案清單。六十六 GB 的擴散 Transformer、2.34 GB 的 VAE、十二 MB 的逐步取樣頭——而整個儲存庫裡完全沒有文字編碼器。編碼器並沒有消失。它是借來的：model_index.json 會指向 MiniMax-H3，也就是 MiniMax 於 2026 年 7 月 31 日開源的 33B 全模態影片模型，並從那裡載入text_encoder/，即 66.7 GB 的 Qwen3-VL，原封不動。如果 MiniMax-H3 已經在你的磁碟上，這個圖像模型用於編碼提示詞就不需要額外成本。如果沒有，你的第一張靜止畫面就要付出 135 GB 的下載量，而這場比較中的第二個模型，正是在為第一個模型做真正的工作。

那一行設定就是兩個模型之間的關係，也說明了它們之間大多數的實際差異。MiniMax-H3-Image 是移除音訊分支的 MiniMax-H3，輸出頭從潛在影片重新定向為潛在圖像，並將整個模型蒸餾到六個取樣步。文字端完全沒有任何改變。DiT 甚至從同一個編碼器讀取相同的第 50 層隱藏狀態，這就是為什麼 tokenizer 和 processor 資料夾位元組完全相同，也是為什麼圖像模型繼承了 H3 的英文提示詞處理，而在該路徑上沒有進行任何新的訓練。

現在值得動筆的原因，在於這次發布的方式，而非其內容。M​iniMax 並未為這款圖像模型發表任何部落格文章。該公司的部落格與新聞索引中，完全沒有關於這款圖像模型的內容——那裡最新的條目是 19 日的 M3.1 Flash 文章——而模型頁面仍以 H3 作為影片系統掛帥。我們所能找到、唯一來自廠商方面的認可，是 API 文件模型發布清單中一張日期為 2026 年 11 月 10 日的卡片，上頭寫著「一款領先的開放權重圖像模型。從想法到新世界」——這句話沒有規格、沒有基準測試，也沒有自身的日期。Hugging Face 儲存庫建立於 11 月 3 日，權重則於 11 月 10 日 14:50 UTC 上線。一小時內又陸續出現兩次 README 修訂與一份 vLLM-Omni 部署指南。這是一次低調的發布：產物真實且可下載，公告則付之闕如。以下所有內容均讀自該儲存庫、授權檔案與 M​iniMax 自家文件；凡屬廠商自行提出、未經重現的數字，我們都會如實註明。

這兩個模型，各自依其實際推銷時所用的說法來呈現

MiniMax-H3 是通用的全模態生成器。它將文字、圖像、影片與音訊作為單一打包上下文，輸出 4 到 15 秒、每秒 24 幀、原生 32 kHz 立體聲音訊的影片，原生解析度為 768p，並透過獨立的重新生成階段 H3-Regenerate-2K，將結果與原始上下文送回模型以達到 2K。有兩種輸入變體很重要：H3-Base-FL2VA 接受零張、一張或兩張圖像作為首/末幀，而 H3-Base-Ref2VA 最多接受 9 張圖像、3 段影片與 3 段音訊，總檔案數上限為 12 個。名為 H3-Context-IR 的託管預處理器會解析混合輸入，並將其改寫為結構化形式；MiniMax 明確表示它不屬於開放發布的一部分，因為它依賴數個託管模型。

MiniMax-H3-Image 接收文字與最多 16 張參考圖片，並輸出一張圖片。其擴散 Transformer 為 33.1B 參數——採用密集單流設計、50 層、隱藏維度 5,376、56 個注意力頭、FFN 寬度 14,336、3D 多模態 RoPE，權重為 BF16，嵌入、時間步與輸出層則為 FP32。影像 VAE 是 CNN 編碼器，搭配 24 層 ViT 解碼器、16× 空間下採樣與 24 個潛在通道；DiT 會將該潛在表徵切分為 2×2 的 patch，因此每個 Transformer token 涵蓋 32×32 像素的區塊。透過 API 的輸出面積最高可達 2,000 萬像素，而這張卡最受矚目的宣稱是每種長寬比下約 1,600 萬像素——從 1:1 的 4096×4096，到 21:9 的 6272×2688，且不需使用放大器。

把那兩段並排讀一遍，分野就一目了然。影片模型把它的容量花在時間上，以及第二種模態上。圖像模型則把它花在空間上。同樣的主幹，不同的目標。

六步且不使用無分類器引導，這才是真正的工程。

MiniMax-H3-Image 中不單純只是減法的部分，是蒸餾，而且它是強制執行而非建議。此檢查點執行六個取樣步驟——六次 NFE——完全沒有無分類器引導。所提供的 API 不把這些視為預設值：num_inference_steps 必須省略或為 6，guidance_scale 必須省略或為 1，任何其他值都會回傳 HTTP 400。負面提示會被直接拒絕。另一個檔案，pdd_fused_heads.safetensors，帶有逐步輸出頭，會取代 transformer 的輸出層，其排程位於 pdd_config.json；那是總計 68.65 GB 中的 12 MB，卻承擔了不成比例的工作量。

這正是「能放上互動介面」與「不能」之間的差別。一個 16 百萬像素、需經引導的 30 步擴散模型，是一件批次作業；而在相同解析度下只需六個無引導步驟，則是一次請求。MiniMax 自己的說法——「以實用的運算成本產出 16 百萬像素影像」——講的是每像素的 FLOPs，而六步排程正是這個說法兌現的方式。至於它能否在展示圖所暗示的品質水準上成立，這個問題尚無第三方回答；截至 2026 年 11 月 10 日，兩個圖像排行榜上都查無 MiniMax-H3-Image 的 Artificial Analysis 收錄條目，模型卡中也没有廠商評測表。

就本地部署而言，對這麼年輕的模型來說，框架支援情況異常完整。SGLang 是參考路徑，附有文件化的 cookbook；vLLM-Omni 發布了一份 recipe，內含各硬體配置與實測延遲，並列出 NVIDIA H200、RTX PRO 6000 Blackwell 與 AMD Instinct MI350X；diffusers 與 ComfyUI 也都已支援。序列平行化只是一個旗標——--ulysses-degree 用於 SGLang，--usp 用於 vLLM-Omni——而且單張 GPU 就足以起步。真正的記憶體成本在於文字編碼器，而且它是影片模型的文字編碼器，這正是這整段比較的重點。

兩個儀表，而且這兩個都不是你能用肉眼估讀的 token 計數器

M​iniMax 以互不相容的計費單位對這兩個模型計費，這正是任何「哪個比較便宜」問題中的陷阱。H3 依解析度按生成輸出的秒數計費：768P 每秒 $0.08，2K 每秒 $0.13，且輸入素材還要在其上另行計費——基礎模型上前五張參考圖片免費，之後每張 $0.04，音訊輸入免費，參考影片則按其自身長度依輸出解析度計費。一支 10 秒的 2K 短片，在計入任何參考素材之前，輸出費用為 $1.30。

MiniMax-H3-Image 以 token 計量，並依影像輸出費率收費。在標準方案中，官方公布的價目表顯示：每百萬輸入文字 token 為 2.30 美元、每百萬輸入影像 token 為 1.50 美元，以及每百萬輸出影像 token 為 3.80 美元；而供應商自己的計算範例則將其歸結為：

• 1K（1024×1024）文字轉圖像 — 每張圖像 $0.02179。

• 2K（2048×2048）文字轉圖像 — 每張圖片 $0.02333。

• 4K（4096×4096）文字轉圖像 — 每張圖像 $0.06879，限時 50% 折扣價為 $0.03439。

• 1K 編輯（含一張參考圖）— $0.02654；2K — $0.02658；4K — $0.07312，折扣後為 $0.03656。

• 1K 編輯（含三張參考圖）— $0.03563；2K — $0.04177；4K — $0.07914，折扣後為 $0.03957。

那個階梯的形狀才是有意思的地方。十六倍的像素只多花略超過三倍的錢，因為計價單位是 token，而 token 數並不會像直覺所設想的那樣隨面積線性成長。高速版本 MiniMax-H3-Image-Highspeed 採用相同的參數與限制，每百萬輸出影像 token 收費 7.60 美元——1K 時為 0.03529 美元，4K 時為 0.13001 美元，且尚未套用同樣的折扣。此折扣適用於交付影像至少達 16,600,000 像素時，並持續至 2026 年 11 月 17 日 16:00 UTC，這是整份發布內容中唯一帶有日期的商業事實。

把兩個計價表並排放在一起，分岔就有了價碼。一秒 768P 影片是 $0.08；最便宜的 M​iniMax 靜態圖約是 $0.022。一段四秒短片——H3 能生成的最短長度——成本大約等於十五張 1K 圖像。這不是支持任一模型的論點。這正是為什麼在你說明自己要產出什麼之前，「哪個更便宜」沒有答案。

在真實部署中，分叉真正造成問題的地方

有三個不對稱之處比基準問題更為重要。

首先是輸入處理。H3-Image 在一次編輯中最多接受 16 張參考圖片，並依上傳順序以位置方式將它們稱為 <Picture 1>、<Picture 2> 等等；請求主體總大小上限為 64 MiB，而 Base64 會讓檔案膨脹約三分之一，因此 16 張圖片的請求必須使用 URL 或預先上傳的檔案參照，而非內嵌資料。H3 的參考模式則完全是另一回事——9 張圖片、3 段影片、3 段音訊片段、12 個檔案，全部打包進一個具有時間結構的序列中。兩個模型的參考處理方式互不構成對方的超集。

第二點是提示詞長度。H3-Image 的服務 API 最多接受 32,000 個字元，但在停用提示詞增強時，實際上只有大約前 4,096 個 token 會生效；本機 SGLang 路徑則在 4,096 個 token 處直接截斷，僅此為止。對於一個以細節指令遵循為賣點的模型來說，這樣的額度並不算大，而這也正是配套的提示詞擴展器存在的原因——MiniMax-H3-Image-PE，這是 Qwen3.8-27B 的 27B FP4 微調版本，會將簡短請求改寫成長篇描述，並附上長寬比建議，於 11 月 8 日發布，同樣採用相同的社群授權條款。其編輯功能那一半僅以提示詞形式發布；編輯端擴展所用的權重目前仍被描述為開發中。

第三項是授權條款，而這兩款模型只是名義上共用同一份授權。MiniMax-H3-Image 社群授權協議要求：若你的年化營收，或你的關係企業的年化營收，超過一百萬美元，或你向第三方提供代管服務，就必須另行取得 MiniMax 的事先書面授權。該協議要求你在任何使用它的商業產品介面上顯著展示“MiniMax-H3-Image”。它將使用範圍限制在所定義的適用地區，禁止使用輸出內容來改進任何其他 AI 模型，且不主張對輸出內容本身享有任何權利。H3 影片授權則是一份獨立協議，有其自身條款。如果你要同時以兩者為基礎打造產品，你持有的是兩份授權，而不是一份。

兩個模型都不做的事

MiniMax-H3-Image 無法製作影片。它沒有時間軸、沒有音訊分支、沒有時長參數——音訊 VAE 已從架構中移除，且每次請求輸出一張潛在影像，透過 API 每次呼叫最多十張。MiniMax-H3 無法製作 1600 萬像素的靜態影像。它預設生成 768p，並透過重新生成流程達到 2K；要求它輸出 4096×4096 的單一影格是不受支援的請求。如果你的工作流程需要同一視覺世界中的主視覺靜態影像，以及一段帶有同步對白的五秒循環影片，你就是在呼叫兩個模型，而在 MiniMax 的平台上，你就是在支付兩種不同的計費方式。

兩者確實有一個容易忽略的共同點：都不支援負向提示詞。H3-Image 會直接拒絕這個欄位。H3 的提示詞引導方式是透過正向描述與 Context-IR 來進行，而不是透過排除法。任何把 Stable Diffusion 工作流程移植到這兩個模型的人，第一天就會失去這個調控手段。

該打哪一個

誠實的分工取決於交付物，而不是品質。如果成品是靜態影像——產品渲染圖、關鍵影格、內含清晰可辨文字的 1600 萬像素底板——那麼 MiniMax-H3-Image 就是首選模型，而六步流程意味著你有餘裕反覆迭代。如果成品會動，H3 就是首選模型，而音訊分支正是它勝過將靜態影像拼接成序列的原因。

路由層在這裡改變的範圍比聽起來更窄，也值得直說：OrcaRouter 並不提供 MiniMax-H3-Image。該模型於 11 月 10 日釋出公開權重，而我們的目錄上並沒有它的路由，所以如果你今天就想用它，只能從 M​iniMax 自家的 API 取得，或自行跑那 68.65 GB 的檢出。我們確實有提供的是 minimax/minimax-h3，那個影片模型，按秒依定價計費、不加價——而對雙模型管線來說，好用的特性在於呼叫 H3 的那把金鑰，同時也能觸及平台上其他兩百多個模型。

值得注意的不是 H3-Image 好不好，而是 M​iniMax 有沒有對它發表任何說法。一個隨附權重、授權條款、定價卡與四項框架整合，卻沒有部落格文章、也沒有基準測試的模型，其宣稱仍完全只是廠商的一面之詞。首次在圖像榜單上取得獨立排名，或首次在相同解析度下與封閉模型正面對決，會比展示網格告訴你更多。在那之前，儲存庫就是紀錄，而儲存庫說的是：這就是把聲音關掉的 H3。