MiniMax H3 參考影片：一個角色、兩個鏡頭，以及悄悄拿走你錢的規則

所有關於這個模型的文章都在同一行停下來：九張圖片、三段影片、三段音訊、總共十二個檔案。讀起來就像一張保固卡。

所以我就把它當作保固卡來處理。我建立了一個角色、製作了一個道具、生成了一個夜景場景，將那個夜景場景作為參考影片回傳，切了八秒的爵士樂作為參考音軌，並透過單一請求送出所有三種參考類型。然後我開始故意打破規則，看看哪些是 API 實際上會防禦的。

其中有四項的防禦方式並不如你所預期。其中一項仍然會向你收取你並未要求的影片全額費用，而你期待看到的錯誤訊息從未出現。那項最值得讀到最後。

關鍵要點

• 三種參考類型，一個陣列。 最多可包含 9 張圖片、3 段影片片段和 3 段音訊片段，總共 12 個檔案。它們都放在同一個 refers 欄位中，而 type 是可選的，因為 API 會從檔案副檔名推斷。
• 音訊不能單獨使用。 僅音訊的請求會以具名錯誤被拒絕。它必須至少搭配一張圖片或一段影片。
• 參考影片與圖片轉影片互斥，但沒有任何事情會告訴你。 在 refers 旁邊送出一張「首幀」image，任務仍會完成。你的兩個輸入之一會無聲地被丟棄，但仍收取全額費用。已於 2026-08-12 在兩個端點上驗證兩次。
• 提交時不會驗證任何內容。 本文中每個錯誤的請求都回傳了 HTTP 200 和一個 ID。真正的判決會在兩到三分鐘後，在生成階段才揭曉。那裡的拒絕是免費的；完成則會收費。
• 額外的參考檔案是免費的。 一張參考圖片和十張參考圖片，在相同的片段長度下收取完全相同的費用。價格取決於輸出秒數，而非輸入數量。

以下是另一端輸出的結果。兩個鏡頭，同一張臉，兩個完全不同的地點，第二個鏡頭同時由一張圖片、一段影片和一個音訊檔案建構而成。

_鏡頭 A（雨、夜晚、霓虹小巷），然後鏡頭 B（隔天早上空無一人的有頂市場），僅靠銜接剪輯在一起，沒有添加任何其他東西。同一個女人，右眉上方同樣的疤痕，同樣的靛藍色夾克，同樣的毛巾。鏡頭 B 是同時從三個參考資料生成的：她的肖像照、鏡頭 A 片段本身，以及一段八秒的爵士樂切片。兩個鏡頭皆為 minimax/h3/reference-to-video，2K 解析度，2560x1440，24fps，並附帶原生 32kHz 立體聲軌道。值得在後半段開啟聲音，聽她說出那句台詞。

為什麼 MiniMax H3 Reference to Video 勝過任何你寫得出的提示詞

提示詞描述一個人。而參考資料就是那個人。這個差異就是這個端點存在的全部理由，也是為什麼 MiniMax H3 目前位居影片編輯排行榜首：Elo 1125 分，共 10280 票（Artificial Analysis，2026 年 8 月）。不過，這個數字值得精確了解：同一張表格將其排名範圍列為 1 到 2，在統計上與 Google Gemini Omni Flash 的 1122 分持平。第一名，但處於一個共享的信賴區間內。H3 也在文字轉影片和圖片轉影片中名列前三的相關說法，來自同一個實驗室的公告文章（Artificial Analysis on X，2026 年 8 月）。

排名很廉價。以下是實際行為：相同的提示詞，三種參考層級，其他所有條件完全相同。

在同一提示詞下的三次 MiniMax H3 reference to video 執行：無參考、一張角色參考圖、以及兩張參考圖

相同的提示詞，相同的 768P 4 秒設定，從左到右：完全無參考（文字轉影片）、一張角色參考圖、兩張參考圖（角色加上拉麵碗）。三者的提示詞都包含「參考圖片中的女人」。在左側面板中，這個片語指涉不到任何人，所以模型憑空創造了一個陌生人。使用 minimax/h3/text-to-video 和 minimax/h3/reference-to-video 生成。

對那條圖帶有兩種誠實的解讀。從第一格跳到第二格的差距巨大：沒有參考資料的話，「參考圖片中的女人」是一個指向空無一物的片語，模型會安靜地用一個與你的專案毫無關係的人來填補這個空洞。從第二格跳到第三格的差距小得多，因為我的提示詞也用文字描述了那個碗，而 H3 僅從文字就畫出了一個勉強可用的海軍藍色碗，上面有隻鶴。這才是實用的部分。一張參考圖片和一個好的名詞片語會爭奪同一項工作，所以把你的參考名額用在語言無法精確定義的事物上：一張特定的臉、一個特定的產品、一個特定的標誌。

這篇文章中幾乎所有失敗的模式都與第一格相同。沒有任何東西警告你，你的請求有一部分落空了。

參考資料實際上鎖定了什麼，以及它沒有鎖定什麼。 參考圖片鎖定身份：臉部結構、頭髮、區別性標記、服裝。它不鎖定光線，而這是最常見的意外。它還會拖曳參考照片的光線，這就是為什麼在陰鬱環境中拍攝的角色表，會產生一個無法承受場景變化的角色。拍攝你的參考資料時，要使用平坦且中性的光線。參考影片鎖定動態、色調和顆粒感，而不是身份。參考音訊鎖定音訊基底本身。如果你需要同一張臉、用同一個聲音、在連貫的場景中讀台詞，那麼參考堆疊正在做三項不同的工作，你必須說清楚哪個是哪個。實務指南通常建議在提示詞中按位置命名它們（「圖片 1 是角色，圖片 2 是產品」），這個慣例值得採用；我下面的提示詞改用簡單的描述性命名，當參考資料在視覺上沒有歧義時，同樣有效。

為什麼第一次呼叫通常會令人失望。 四件事，全部於 2026-08-12 測量：

1. 提交端點不驗證任何東西。錯誤的 MIME、164 秒的音訊、失效的 URL、互斥的欄位：所有這些都回傳 HTTP 200 和一個預測 ID。你稍後才會發現。
2. ratio 預設為 adaptive，文件說明是「讓模型選擇」。使用 16:9 的參考資料時，無論我將它保持在 adaptive 還是強制設為 16:9，我都得到 1344x768 的 768P 輸出，所以當你的輸入已經一致時，預設值是無害的。當輸入不一致時，結果就像擲硬幣，而這是唯一一個 H3 端點，你可以簡單地將決定權從模型手中拿走。
3. 首幀圖片加上參考資料不會報錯。它會安靜地丟棄其中之一並向你收費。
4. 如果模型沒有具體的東西可以抓住，它會自信地填補空白，而一個自信的錯誤臉孔看起來就跟一次成功的執行一模一樣。

關於提示詞撰寫這方面，MiniMax H3 提示詞指南比我能在這裡深入探討的措辭更詳細。

MiniMax H3 Reference to Video 規則手冊：三種類型，一個請求

所有三種參考類型共用一個陣列。以下是已發布的合約，以及當我對其施加壓力時，端點實際上的行為。

表 1：三種參考類型

檔案數量和時長限制是 MiniMax 發布的限制（Hailuo，2026 年 8 月），並與發布文章交叉比對，該文章列出了相同的參考影片時間窗：每個 2 到 15 秒，總共 15 秒（MarkTechPost，2026 年 8 月）。最後三行全部是我測量得出的。

規格表有兩件事沒告訴你。首先，每個條目上的 type 欄位是可選的，並會從 URL 副檔名推斷，這意味著 base64 data URL 或沒有副檔名的連結必須宣告其類型，否則請求會猜錯。其次，瀏覽器上傳器最多只能上傳九個檔案（步驟 5 截圖中的 Reference Materials (2/9)，MAX:9），低於 MiniMax 自己的十二個。我仍然透過 API 送出了十張參考圖片，任務正常完成，所以九是 UI 限制，不是模型限制。

表 2：reference-to-video 與 image-to-video 與 text-to-video 的比較

第四行是沒有人提到的差異。在 image-to-video 上，長寬比例枚舉只包含一個值 adaptive，因為第一幀決定了形狀。在 reference-to-video 上，你可以使用全部七種，這使得它成為唯一一個 H3 端點，可以在錨定角色的同時強制設定幀的形狀。如果你正在為這項工作選擇層級，MiniMax H3 的 2K 與 768P 比較涵蓋了額外像素能買到什麼。

最後一行是昂貴的那種。文件將兩個端點描述為互斥，而它們確實是互斥的，因為只有一個輸入路徑會被採用。但沒有錯誤訊息。我在 2026-08-12 以兩種方式運行了測試：一個帶有首幀 image 的 reference-to-video 呼叫在 115 秒內完成，並收取了 $0.40；一個帶有 refers 的 image-to-video 呼叫在 167 秒內完成，並收取了 $0.40。兩者都產生了一個影片。兩者都丟棄了我送出的一半內容，而回應中沒有任何欄位會說明是哪一半。

表 3：此工作流程使用的模型

以下所有內容都在 Atlas Cloud 的單一瀏覽器分頁中執行，價格和截圖也來自此處。費率於 2026-08-12 檢查。

本月三個 H3 端點皆無折扣活動。如果你只建立參考靜態圖，目前有兩個鄰近的方案更便宜：gpt-image-2-developer/text-to-image 打五折，從 $0.009 降至 2026 年 8 月的 $0.004。完整的每秒價格明細請見 MiniMax H3 API 定價指南。

MiniMax H3 Reference to Video，逐步操作

場景：一個女人經營拉麵攤。鏡頭 A 是一個夜晚的雨夜霓虹小巷。鏡頭 B 是同一個女人隔天早上在一個空無一人的有頂市場，不同的地點，不同的時間，不同的鏡頭。除了參考資料之外，兩次呼叫之間沒有任何東西傳遞，而這正是測試的重點。

步驟 1：建立角色參考，刻意使用平坦光線

這是人們常搞錯的步驟。角色參考不是你角色的漂亮照片，而是對他們臉部的測量。中性光線、簡單背景、沒有場景、沒有氛圍。H3 會連同光線一起學習臉部，所以一個有氛圍的參考會產生一個與該氛圍緊密相連的角色。

模型：openai/gpt-image-2/text-to-image。設定：品質 high，尺寸 2048x1152（16:9），格式 png。

textCopy
1一位三十出頭女性的編輯照片，是街頭小吃廚師。近距離四分之三肖像，中性表情，直視鏡頭。黑色短髮塞在耳後，右眉上方有個小疤痕，溫暖的橄欖色肌膚。她穿著一件褪色的靛藍色工作夾克，袖子捲到手肘，左肩上搭著一條折好的白色毛巾。淺灰色純色工作室背景，柔和均勻的關鍵光，沒有道具，臉部對焦清晰，自然的皮膚紋理，無修圖。擬真攝影風格，50mm 鏡頭。
2

Atlas Cloud 上的 GPT Image 2 遊樂場，載入了角色參考提示詞，輸出面板中顯示完成的肖像

Atlas Cloud 上的 GPT Image 2：品質設為高，16:9，角色表在右側渲染完成。

MiniMax H3 reference to video 的角色參考圖：拉麵師傅的正面工作室肖像，右眉上方有疤痕

參考圖片 1。右眉上方的疤痕和折好的白色毛巾是刻意為之：它們是便宜、無歧義的身份錨點，你可以在後續的每一幀中檢查它們是否出現。

步驟 2：建立道具參考

第二個參考插槽，第二項工作。物體在這裡比臉部表現得更好，這使得一個獨特的道具成為證明參考資料已被使用的最簡單方法。相同模型，相同設定。

textCopy
1一個深海軍藍色陶瓷拉麵碗的產品照片，碗側有手繪的白鶴，碗緣有缺口，裝滿了冒著熱氣的醬油拉麵。正面視角，淺灰色純色背景，柔和均勻的光線，對焦清晰，擬真攝影風格，50mm 鏡頭。
2

道具參考圖：深海軍藍色拉麵碗，帶有手繪白鶴和缺口碗緣

參考圖片 2。手繪的白鶴和碗緣的缺口是線索。如果它們在影片中出現，表示參考資料被讀取到了。

步驟 3：鏡頭 A，將兩張圖片送入 MiniMax H3 reference to video

兩張參考圖片，皆為 type: "image"，放入 refers。明確設定比例。預設值為 adaptive，當你的參考資料已經是 16:9 時，它通常會做出正確的決定，但它會替你決定，而在這個端點上，你不必讓它決定。

模型：minimax/h3/reference-to-video。設定：解析度 2K，時長 8，比例 16:9。

textCopy
1廣角建立鏡頭。夜晚，大雨，狹窄的霓虹小巷。參考圖片中的女人獨自在一個塑膠雨棚下小小的冒著熱氣的拉麵攤後面工作，將湯舀入參考圖片中帶有白鶴的海軍藍碗。蒸氣穿過粉紅色和綠色的霓虹燈反射，在濕漉漉的人行道上升起。緩慢推向攤位。環境音：雨打在塑膠上的聲音、沸騰的湯聲、遠處的車流聲。無對話。
2

這次呼叫的輸出是文章頂部展示影片的前半段。保留其 URL。它是步驟 5 的輸入。

步驟 4：剪輯一段八秒的參考音訊

參考音訊不是音軌插槽。它是模型用來比對自己混音的基底，也是這個端點上最挑剔的輸入。先產生一段音軌，然後將其剪短，因為一首完整的歌曲會被拒絕。

模型：minimax/music-2.6，設定 is_instrumental: true 和 format: "mp3"。

textCopy
1稀疏的深夜爵士樂，刷奏的小鼓、低音提琴、一支弱音小號，憂鬱，70 BPM，純器樂。
2

然後粗略地剪輯約八秒，並將其編碼為 data:audio/mp3 URL。我最初在這裡犯了三個錯誤，都附有精確的錯誤訊息文字：

• MIME 字串比位元組本身更重要。 宣告為 data:audio/mpeg，參考資料會被拒絕，錯誤訊息為 audio format ".mpeg" not allowed，即使檔案是一個完全普通的 MP3。請寫 audio/mp3。
• 每個片段 2 到 15 秒，並且會強制執行。 我生成的音軌是 164 秒。它回傳了 invalid param: audio duration 164258 ms, expected [2000, 15000] ms。將其剪輯到 8.05 秒解決了問題。兩次拒絕都沒有花費任何成本。
• 15 秒的合併上限有文件說明但未強制執行。 我在同一個請求中送出了兩個 8 秒的片段，總共 16.1 秒，預期會被拒絕。結果任務完成並正常收費。不要依賴這個行為：它被發布為限制，隨時可能開始像限制一樣運作。

Atlas Cloud 上的 MiniMax Music 2.6 遊樂場，顯示爵士樂提示詞和輸出面板中完成的音軌

Atlas Cloud 上的 MiniMax Music 2.6，每次執行 $0.15，完成的音軌在右側。從這個截圖中有一件事要複製，有一件事不要：價格和 mp3 格式是對的，但 Is Instrumental 仍然關閉，頁面的示範歌詞仍然在文字框中，所以這次特定執行回傳了一首帶有人聲的 1:35 歌曲。在執行之前，請打開該切換開關並清除歌詞欄位，否則你將需要剪輯一個有人唱歌的參考基底。我的 API 執行，設定 isinstrumental: true，在 209 秒內回傳了 2:44 的純器樂。

步驟 5：鏡頭 B，一次 MiniMax H3 reference to video 呼叫，包含所有三種類型

這是關鍵字真正涉及到的呼叫。三種參考類型，三項不同的工作，一個陣列：

1. 步驟 1 的角色肖像，type: "image"，用來保持她的臉
2. 步驟 3 的鏡頭 A mp4，type: "video"，用來跨剪輯攜帶色調和顆粒感
3. 步驟 4 的八秒爵士樂切片，type: "audio"，作為基底

平台上其他生成任務的輸出 URL 可以直接放入 refers 作為影片參考，這正是多鏡頭連續性的實際機制。不是「H3 記住了你的角色」。而是你把前一個鏡頭交還給它。

模型：minimax/h3/reference-to-video。設定：解析度 2K，時長 8，比例 16:9。

textCopy
1參考圖片中的同一個女人，隔天早上。明亮的空曠有頂市場，透過天窗灑落的冷冽乾淨日光，她身後的鐵門仍拉下。中特寫，靜止鏡頭。她用折好的白色毛巾擦拭檯面，抬頭看向鏡頭說了一句台詞，然後繼續工作。保持她的臉、頭髮、疤痕和靛藍色夾克與參考資料完全相同。攜帶參考片段的色調和顆粒感。使用參考音訊作為背景音樂。
2

Atlas Cloud 上的 MiniMax H3 reference to video 遊樂場，載入了圖片和音訊參考，輸出面板中顯示生成的片段

同一個呼叫在 MiniMax H3 Reference-to-Video 遊樂場中，設定為 2K 和 8 秒。在 Reference Materials (2/9) 中可以看到兩個不同類型的參考插槽：插槽 1 是 ref-audio-8s.mp3，插槽 2 是她的肖像。影片參考透過「Add via link」（該面板右上角）或透過 API 放入，因為它存在於 URL 而非硬碟上。從這個面板可以讀出三件事：上傳器顯示 MAX:9，即使 MiniMax 自己的上限是 12；Aspect Ratio 預設為 adaptive，除非你更改它；2K 8 秒的執行價格是 $1.12，這是每秒 $0.14 的費率。

步驟 6：驗證參考資料是否確實被使用

任務完成不等於任務成功。兩個檢查，都很便宜。

檢查臉部。 從每個鏡頭中取出一幀，並排放在一起。你要尋找你設置的錨點：疤痕、髮線、夾克、毛巾。

鏡頭 A 的一幀與鏡頭 B 的一幀並排，顯示同一個 MiniMax H3 reference to video 角色在兩個不同場景中

左：鏡頭 A，夜晚，霓虹，廣角。右：鏡頭 B，有頂市場，隔天早上，中特寫。同一張臉，右眉上方同樣的疤痕，同樣的夾克和毛巾，跨越場景和取景的變化，除了參考資料之外沒有任何共享的東西。

有一件事沒有按照我寫提示詞的方式進行。我要求「明亮的空曠有頂市場，冷冽乾淨的日光」以及「攜帶參考片段的色調和顆粒感」，而參考片段贏了。鏡頭 B 無疑是早晨，無疑是另一個地方，但它遠比「明亮」所暗示的更加陰鬱，因為夜晚的色調隨著影片參考一起傳了過來。你不能在同一個呼叫中要求相同的外觀和相反的光線。如果你需要改變光線，請省略色調指示，或者省略影片參考，僅用圖片來保持身份。

檢查音訊。 將你上傳的八秒切片的波形與 mp4 內回傳的音軌進行比較，並加入一個對照組：一個完全沒有音訊參考生成的片段。

上傳的八秒參考音訊的波形、生成片段內回傳的音訊軌道，以及沒有音訊參考的對照組

上：作為參考送出的 8.05 秒爵士樂切片。中：從回傳的鏡頭 B mp4 中提取的音軌，在約 5.5 秒處被對話台詞主導。下：鏡頭 A，相同工作流程，無音訊參考。

這就是我必須修正我最初相信的一個觀念的地方。參考音訊不會原封不動地回傳。我的切片和回傳音軌之間的包絡相關性為 0.25，而無參考的對照組為 -0.05，所以兩者相關，但遠非相同，而且回傳的形狀顯然是它自己的混音，而不是我的檔案加上其他東西。參考資料明確做到的是在底下放了些東西：鏡頭 B 的基底音軌在開始對話前的整個前五秒，比無音訊對照組高出約 7 dB。將參考音訊解讀為對混音的引導，而不是一個音樂插槽。如果你需要在畫面下使用你的確切音軌，請在之後再疊加上去。

如果你正在基於音訊方面進行建置，MiniMax H3 唇形同步與音訊和 MiniMax H3 音樂影片逐步教學都從相同的參考音訊行為開始。關於這一切相關的輪詢和重試程式碼，MiniMax H3 教學中有迴圈。

四個值得偷學的 MiniMax H3 Reference to Video 設定

重新設計你已有的片段。 將一個完成的片段放入 refers 作為影片參考，完全不使用圖片，並要求不同的媒介。動態、取景、推近和道具會保留下來；表面會改變。這就是 H3 影片編輯排名背後的機制，也是 MiniMax H3 與 Veo 3.1 動畫比較中動畫作品背後的相同機制。

使用鏡頭 A 片段作為 MiniMax H3 reference to video 參考生成的動畫重新設計

鏡頭 A 小巷作為唯一參考回傳，並搭配賽璐珞著色動畫提示詞。同一個攤位、同一個湯勺、同一個鶴碗、同一個推近，重新繪製。一個值得了解的細節：轉換在最初的幾幀最弱，一旦鏡頭決定移動後就最強。顯示為無聲 GIF。使用 minimax/h3/reference-to-video 於 768P、4 秒、$0.40 生成。

讓一張照片活起來。 一張肖像搭配一段人聲片段，在 2 到 15 秒的時間窗內，提示詞指定表演。比唇形同步管道更便宜，因為它是一個單一呼叫。

將產品鎖定在任何場景中。 參考圖片鎖定物體比鎖定臉部更強，因此一張真實的產品照片加上場景提示詞，是這個端點上最可靠的事情。在將其放入廣告之前，請先檢查你可以對結果做什麼。

建立一個系列，而不是一個片段。 串聯起來：鏡頭 N 的輸出變成鏡頭 N+1 的影片參考。每次呼叫仍然限制在 15 秒，所以連續性是你的工作，而不是模型的。MiniMax H3 影片可以多長涵蓋了這個上限在哪裡會造成問題。

在將系列作品投入某個引擎之前，想先比較看看？Seedance 2.5 與 MiniMax H3 比較和 MiniMax H3 替代方案是值得閱讀的兩篇。

一個雙鏡頭 MiniMax H3 Reference to Video 場景的實際成本

以下每一行都是 2026-08-12 的真實任務，金額取自 API 在每個完成的預測中回傳的 price 欄位。

表 4：實際帳單

誠實地拆分這個總額。文章頂部完成的雙鏡頭場景，包括參考資料和音訊，花費了其中的 $2.74。另外 $5.44 是調查費用：對照組、故意破壞，以及為了截圖而在瀏覽器中重新執行步驟。如果你已經知道規則，一個 16 秒的雙鏡頭 2K 序列比一個三明治還便宜。

從那張表中浮現出三件事。

參考資料是免費的。 十張圖片的對照組與在相同長度和解析度下的單張圖片階梯執行，花費完全相同的 $0.40。在這個平台上，計費表只追蹤輸出秒數和解析度，沒有其他東西。不過值得指出一個矛盾之處：MiniMax 自己的平台規則描述輸入影片會以輸出費率計費，而 OpenRouter 上的統一 schema 則帶有一個單獨的 reference_images 項目。這兩者都沒有出現在我這裡的發票上。如果你在其他地方編列預算，請自行測試價格，而不是假設。

失敗是免費的，而且來得很晚。 所有四次拒絕都沒有花費任何成本，這是好消息。壞消息是它們何時到達：純音訊規則在 7 毫秒，音訊長度、錯誤的 MIME 和失效的 URL 在 16 到 21 秒，而在提交時則完全沒有。本文中每個格式錯誤的請求都先得到了 HTTP 200 和一個預測 ID，所以請將提交回應視為收據，而不是驗證，並在相信任何東西之前先輪詢 status 欄位。

靜默成功是昂貴的失敗。 兩次混合對照組各花費了完整的 $0.40，並回傳了一個完全有效的影片，該影片僅由我一半的輸入建構而成。沒有錯誤，沒有警告欄位，也沒有辦法從回應中判斷有任何東西被丟棄。那是表格中唯一一行，錢從帳戶中消失，而我沒有得到任何我想要的東西。

關於最後一點，有一個誠實的更正，因為它在寫作過程中在我面前改變了。在八月初，一個回傳 404 的參考 URL 行為相同：任務完成，參考資料被靜默忽略，並收取全額費用。在 2026-08-12 重新執行時，端點現在會檢查可達性，並以一個具名錯誤 content[1].image_url: media not found (HTTP 404) 免費使任務失敗。那個特定的漏洞已經被補上了。但互斥輸入的漏洞還沒有。關於每個片段點數的計算，MiniMax H3 每個影片的點數有表格。

誰的臉，誰的聲音：在上傳參考資料之前請先檢查

這個端點與文字轉影片在一個法律相關的方面不同：你提供肖像。一個真實人物的參考圖片、某人電影中的參考片段、一個可辨識聲音中的參考人聲，所有這些都是你主張使用權利的素材。模型端的內容規則仍然會疊加在上面，而且它們對真實人物的限制比對虛構人物更嚴格。在客戶看到輸出之前，有兩篇指南值得一讀：MiniMax H3 內容限制和商業使用與授權明細，其中也涵蓋了 MiniMax 條款中的地域排除事項。

MiniMax H3 Reference to Video：常見問題

MiniMax H3 reference to video 可以在兩個不同的鏡頭中保持同一個角色嗎？

可以，而且我上面的雙鏡頭測試跨越了從夜晚到早晨的完全光線反轉，仍然保持住角色。但僅靠角色圖片是不夠的。可靠的模式是將前一個鏡頭的輸出 URL 作為參考影片，與角色圖片一起傳入，這樣第二個呼叫除了繼承身份之外，也會繼承色調和顆粒感。

我可以在同一個 MiniMax H3 reference to video 呼叫中同時使用首幀圖片和參考資料嗎？

不行，而且失敗模式才是問題所在。同時送出 image 和 refers 不會報錯。於 2026-08-12 測試，任務在 115 秒內完成，收取 $0.40，並靜默丟棄了兩個輸入中的一個。在 image-to-video 端點上，反過來的情況也會發生同樣的事情。每次呼叫選擇一條路徑。

我可以單獨將一個音訊檔案作為 MiniMax H3 reference to video 的參考送出嗎？

不行。音訊必須至少搭配一張參考圖片或影片一起傳送，而且端點會用一個明確的錯誤來強制執行：reference-to-video requires at least one reference image or video。它在生成階段（而非提交時）到達，而被拒絕的任務是免費的。音訊參考也必須在 2 到 15 秒內，總共 15 秒，並宣告為 audio/mp3 而非 audio/mpeg。

MiniMax H3 reference to video 會對每個參考檔案額外收費嗎？

在 Atlas Cloud 上不會。一個包含十張參考圖片的執行和一個包含一張參考圖片的執行，在 768P 和 4 秒設定下，收取完全相同的 $0.40，所以計費表只追蹤輸出秒數和解析度。不過要注意矛盾之處：MiniMax 自己的規則提到輸入影片會以輸出費率計費，而其他平台則會顯示一個單獨的參考圖片項目。請在你用來計費的任何平台上自行驗證。

如果我的一個 MiniMax H3 reference to video URL 失效了會怎樣？

截至 2026-08-12，端點會驗證可達性，並在約 21 秒後以 content[1].image_url: media not found (HTTP 404) 免費使整個任務失敗。這是一個變化：在八月初，同一個請求會完成，靜默忽略缺失的參考資料，並收取全額費用。不要假設較舊的行為報告仍然有效，並務必檢查 status 欄位，而不是假設提交時的 200 狀態碼有任何意義。

MiniMax H3 reference to video 真的是這個領域最好的模型嗎？

在唯一衡量它的公開對決中，是的，些微領先。MiniMax H3 以 Elo 1125 分、10280 票領先影片編輯排行榜，但其列出的排名範圍是 1 到 2，而 Gemini Omni Flash 以 1122 分緊隨其後，差距 3 分，且信賴區間重疊。將其視為「共同最佳可用選擇」，根據工作流程的其他部分來選擇，並如果這個平手對你很重要，請閱讀 MiniMax H3 替代方案。