MiniMax H3 的影片長度為 15 秒。我在其中一部影片裡數到了十次剪接。

每个人在第一天都会做同样的事。你打开时长下拉选单，看到15，然后开始做除法。十分钟的影片？四十段生成。三分鐘的介紹片？十二段。接著你看著除法算出的數字，關掉分頁，心想這個模型還不適合處理任何有故事性的內容。

我也做了除法。然後我對九個真實的 H3 片段執行 ffmpeg，發現了讓整個計算顯得荒謬的東西。

其中一個片段長 15.10 秒。在內部，場景偵測器標記出十個乾淨的剪輯點。十個。不同的服裝、不同的構圖、不同的背景、全畫面類型的卡片，全部都在同一段生成中，只花了一段生成的費用。如果我按照除法暗示的方式來規劃那個片段，每次剪輯一次生成，我就會為了同樣的 15 秒付出十倍的代價。

除法是錯誤的。上限不是碼表，而是一個容器，而且幾乎沒有人真正填滿它。

一位滑板手的中段動作以頻閃序列捕捉，單一畫面中凍結了許多不同的位置姿態

一個畫面，多個瞬間。這就是時長下拉選單讓你忽略的心智模型。

重點摘要

• duration 參數只接受 4 到 15 的整數。預設值為 8。沒有 7.5，也沒有超過 15 的值。
• 每個片段回傳時為 24 FPS，最高原生 2K，並在與圖片相同的處理過程中生成立體聲音訊。
• 你的「15 秒」片段實際上是 362 幀，也就是 15.083 秒。時長會向上對齊到 17 幀的網格，只有 duration: 8 會落在整秒上。
• 一次生成可以容納多個鏡頭。在提示詞中寫入 SHOT 1 / CUT TO，模型就會自動為你剪輯，無需額外費用。
• API 中沒有 extend 參數。要超過 15 秒，你需要透過串聯來實現：上一段的最後一幀接下一段的第一幀，使用參考圖片保持外觀，然後進行硬拼接。

觀看由三個片段構成的 45 秒 MiniMax H3 影片長度

在討論任何理論之前，先看實際成果。一段 45 秒的拉麵攤廣告，名為《MIDNIGHT BOWL》。三段生成，每段 15 秒，每段內部包含三個鏡頭。總共九個鏡頭，一段連續的敘事片段，沒有疊化來隱藏接縫。

完整的 45 秒剪輯。三段 MiniMax H3 生成無轉場效果直接拼接。廚師、圍裙、燈泡和手繪招牌經歷了兩次交接仍然保持一致。

《MIDNIGHT BOWL》廣告的九個畫面，以 3x3 的接觸印樣排列，標示為 SHOT 1 到 SHOT 9，附帶時間碼

九個鏡頭，三段生成。每一行是一次生成，每一列是模型自行完成的剪輯。鏡頭 3 和 4 互相呼應，因為第二段生成是從第一段生成的末尾畫面開始的，這正是接縫隱形的原因。

三段生成，不是九段。這個差距正是本文的重點。

我沒有手動剪輯任何部分。我要求每次生成提供三個帶時間碼的鏡頭，而 ffmpeg 的場景偵測器發現剪輯點分別位於第一段的 4.9 秒和 9.1 秒、第二段的 4.9 秒和 9.0 秒、第三段的 5.3 秒和 11.0 秒。九個鏡頭，三張帳單。

為什麼 MiniMax H3 影片長度會破壞長片計劃

數字本身沒問題。在這一世代的模型中，15 秒的頂點範圍已經很慷慨，而且片段是 2K 解析度，附帶真實的立體聲。真正讓人困擾的是他們規劃的單位。

如果你以秒為單位來預算，一部一分鐘的影片就是「四個片段」，一部十分鐘的影片就是「四十個片段」，而四十個片段在連續性工作上是一場惡夢。如果你以鏡頭為單位來預算，一部一分鐘的影片是四段生成，大約容納十二個鏡頭，這對於一支廣告來說是正常的覆蓋量。同樣的模型，同樣的上限，完全不同的製作計劃。

復古平面海報插圖，一條 35mm 底片，連續三個畫面各自呈現完全不同的場景

以鏡頭為單位預算，而不是以秒為單位。一條付費的底片，內部包含三個不同的場景。

還有第二個會破壞長片計劃的因素，而且根本不是上限的問題。是接縫。單一片段幾乎不會在中間出問題。問題總是出在接合處，因為每次生成都會自行創造音訊背景，並在服裝和燈光上略有偏移。為接縫做好規劃，45 秒就很容易。忽略它們，四個完美的片段看起來仍然像是四個片段。

MiniMax H3 影片長度的真實面貌：在 17 幀網格上的 4 到 15 整秒

先從規格開始，因為目前流傳著兩個不同的數字。Atlas Cloud 上所有三個 H3 端點的真實 API schema 將 duration 列為精確的 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 列舉值，預設值為 8。整數，沒有小數，沒有超過 15。發佈報導也符合這個說法：2K 輸出，4 到 15 秒，僅限整數時長（MarkTechPost，2026 年 8 月）。MiniMax 自家的發佈文章描述為「最長 15 秒，2K 解析度，原生立體聲」（MiniMax，2026 年 8 月）。

你仍然會在各個個人簡介和快速入門指南中看到「5 到 15 秒」的寫法，包括某些平台上的說明文字。請以 schema 列舉值為準。下限是 4，我已經實際付費使用過 4 秒的片段來證明。

現在來談幾乎沒有人提到的那部分。你要求 15 秒，但並不會得到 360 幀。你會得到 362 幀。

H3 以 17 幀為區塊建立影片，並將你要求的時長向上對齊到 24 FPS 下 17k + 5 幀的下一個數值。這個網格在 ComfyUI 的官方 H3 教學中有所記載（ComfyUI Docs，2026 年），在 API 端也同樣適用。我使用 ffmpeg 對九個真實的 H3 檔案進行了幀數計數：

textCopy
1ffmpeg -i video-1.mp4 -map 0:v:0 -c copy -f null - 2>&1 | tail -1
2# frame=  362  ...
3#   Duration: 00:00:15.10, 1280x720, 24 fps
4

每個 15 秒的檔案回傳時都是 362 幀。每個 10 秒的檔案回傳時都是 243 幀。我為本文新生成的三個片段也都回傳 362 幀，而在步驟 5 中使用的 4 秒預演則回傳 107 幀。用網格公式驗算：362 是 17x21+5，243 是 17x14+5，107 是 17x6+5。這個公式精確預測了全部三個數值，這種一致性讓我信任表格中的其他項目。

從這個表格可以得出三件事。

duration: 8 是整個範圍內唯一一個給你乾淨整秒的值，而且它恰好是預設值。這不是巧合，因為 17x11+5 = 192 = 8 x 24 正好。

你要求 6 秒，但你會得到 6.583 秒，多出超過半秒的免費畫面。你要求 13 秒，你會得到 13.667 秒。網格總是向上取整，從不向下，所以你永遠不會少拿到畫面。

如果你正在剪輯音樂或匹配影格精確的編輯，永遠不要用 duration x 24 來計算你的時間軸。要以實際檔案為準。一個以整秒為假設的 40 片段專案，到最後會誤差將近四秒。

一段 15 秒的 MiniMax H3 生成內有十個剪輯點

這是我在文章開頭提到的片段。一次生成，362 幀，容器內 15.10 秒。這是一個時尚動態排版作品，行為模式更像一部剪輯過的音樂錄影帶，而不是一個連續鏡頭。

單一次 MiniMax H3 生成。服裝變化、構圖變化、分割畫面與全畫面類型卡片，全部都在一次 15 秒的任務中。

我使用 ffmpeg 的場景偵測器來分析，而不是用肉眼數：

textCopy
1ffmpeg -i video-5.mp4 -vf "select='gt(scene,0.6)',showinfo" -f null -
2# 18 breaks flagged, at 1.54 2.88 3.63 4.21 5.54 5.83 6.92 8.88 11.17 13.00 ...
3

其中十個是前十三秒內乾淨的鏡頭切換。結尾是一個在黑色背景上閃爍的標題卡，導致原始計數膨脹，所以十個是保守且誠實的數字。不管是哪種情況，它都不是一個鏡頭，也不是三個鏡頭。

現在來看對照組，因為「H3 總是把你的片段切碎」是另一種極端錯誤，同樣不正確。下一個檔案同樣是單次 15 秒生成，同樣 362 幀，但同一個偵測器在其中發現了零個剪輯點。

不同的單次生成，同樣 362 幀，零個偵測到的剪輯點。一個連續的鏡頭運動持續了整整十五秒。

所以上限不是「十五秒的素材」。它是十五秒的螢幕時間，你可以隨意細分，從一個不間斷的鏡頭到十個剪輯點。你透過提示詞來控制，而且無論哪種情況，你支付的費用都相同。

支援 MiniMax H3 影片長度的三個端點，都在一個頁籤中

要超過十五秒，需要三種不同的任務：一個用來建立錨定畫面，一個用來動畫化和串聯，一個用來移動鏡頭而不失去主體。在 Atlas Cloud 上，這三個端點都位於同一個目錄中，共享一個金鑰和一個餘額，這點很重要，因為下一節的串聯鏈會反覆在它們之間傳遞檔案。

目前所有三個 H3 端點都沒有折扣，所以價格就是價格。你可以在完整模型目錄上確認任何價格。

在寫第一個請求之前，有三個參數陷阱值得了解，全部來自即時 schema 而非文件論述：

1. ratio 在每個端點上的行為不同。 text-to-video 提供六種比例，預設為 1:1，如果你忘記設定，它會悄悄地給你一個正方形片段，而且它完全不接受 adaptive。image-to-video 只提供 adaptive，所以構圖會跟隨你的第一幀。reference-to-video 是唯一一個擁有完整選項集加上 adaptive 的端點。
2. resolution 是 768P 或 2K，預設為 2K。 兩個層級在目錄中均列於單一每秒價格下，所以降到 768P 並不會省錢。使用 2K。
3. image-to-video 也接受可選的 end_image。 你可以固定片段的兩端，而不只是開始。這使得下面的串聯技巧可以從兩個方向進行控制。

如何逐步突破 MiniMax H3 影片長度限制

這是完整的 MIDNIGHT BOWL 建置。以下每個提示詞都是我實際發送的，可以直接複製貼上。總執行時間為三段 H3 生成加上一張靜態影像，而且整個過程可以在瀏覽器頁籤中重現。

步驟 1：在一張錨定畫面中鎖定外觀

不要從影片開始。先從一張你真正喜歡的靜態影像開始，因為串聯鏈中的每個片段都會繼承它的光線、服裝和招牌。這個弄錯代價很高；弄對則只需幾美分。

模型：openai/gpt-image-2/text-to-image。設定：品質 high，比例 16:9。

textCopy
1Film still, 2am at a narrow Tokyo back-alley noodle stall. A 50-year-old chef in a navy apron and white bandana leans over a steaming stockpot behind a scratched wooden counter, sleeves rolled to the elbow, forearms lit hot orange by a single hanging bulb. Rain-slick asphalt reflects red and green signage; paper lanterns and a hand-painted wooden sign reading "MIDNIGHT BOWL" hang above the counter. Steam rolls across the frame from camera right. Shot on a 35mm lens at f/2, shallow depth of field, deep shadows, warm tungsten key against cool blue night, visible fine film grain, no text overlays.
2

Atlas Cloud 上的 GPT Image 2 遊樂場，填入了 MIDNIGHT BOWL 錨定提示詞，輸出面板中顯示完成的靜態影像

Atlas Cloud 上的 GPT Image 2：品質設為高，16:9，錨定畫面在右側呈現。

MIDNIGHT BOWL 錨定畫面：一位廚師穿著海軍藍圍裙，在雨中後巷的單一燈泡下，站在蒸氣騰騰的高湯鍋後面

錨定畫面。後續所有內容都繼承了這個燈泡、這條圍裙和這個招牌。

步驟 2：將三個鏡頭放入一段 15 秒的 MiniMax H3 生成中

這是改變預算的關鍵動作。與其要求一段連續的十五秒，不如給模型一個帶有明確時間碼和 CUT TO 字樣的鏡頭列表。它會自動為你剪輯，而且只算一次生成的費用。

模型：minimax/h3/image-to-video。設定：resolution 2K，duration 15，ratio adaptive（此處唯一選項，構圖跟隨你的第一幀），第一幀 = 步驟 1 的靜態影像。

textCopy
1SHOT 1 (0-5s): Locked-off wide of the stall. Steam billows; the chef ladles broth into a black bowl; rain drips off the awning edge. SHOT 2 (5-10s): CUT TO a macro close-up of the ladle breaking the broth surface, golden fat swirling, chopped scallion falling in slow arcs. SHOT 3 (10-15s): CUT TO a medium shot of the chef looking straight into the lens, wiping his hands on the apron, and saying in Japanese with a tired smile: "Ippai, dozo." He sets the bowl down on the counter and the shot holds on his face.
2Audio: heavy rain on the awning, broth simmering, the ladle knocking the pot rim, a distant train, low late-night city hum. One line of clear male Japanese dialogue, natural room tone, no music.
3Keep the same chef, apron, bandana, bulb and signage in all three shots. Hard cuts only, no dissolves, no camera whip transitions. Warm tungsten key, cool blue night, 35mm look, film grain.
4

三件事讓這個方法奏效：明確的秒數範圍、文字字串 CUT TO，以及結尾的連續性條款，列出了所有必須在剪輯中保持不變的元素。省略連續性條款，鏡頭 3 回傳時就會出現不同的圍裙。

Atlas Cloud 上的 MiniMax H3 image-to-video 遊樂場，載入了錨定畫面，選擇了時長 15 和 2K，輸出面板中正在播放完成的片段

Atlas Cloud 上的 MiniMax H3 image-to-video：錨定畫面作為第一幀載入，解析度 2K，右側是完成的片段。注意時長滑桿和隨之更新的價格。這次執行將時長留在預設的 8，這就是為什麼按鈕顯示 $1.12；設定為 15 時會顯示 $2.10。

生成 1。一次付費的任務，三個鏡頭（剪輯點測量在 4.92 秒和 9.13 秒），一段附帶唇形同步的對話，原生 2560x1440，以及同一檔案中的 32 kHz 立體聲音訊。

步驟 3：從上一段的最後一幀串聯下一段 15 秒

沒有 extend 參數。串聯是手動的，而且很簡單：取出生成 1 的最後一幀，作為生成 2 的第一幀重新輸入。

bashCopy
1ffmpeg -sseof -0.08 -i generation-1.mp4 -frames:v 1 -q:v 2 handoff-frame-01.jpg
2

模型：再次使用 minimax/h3/image-to-video。設定：第一幀 = handoff-frame-01.jpg，resolution 2K，duration 15，ratio adaptive。

這裡重要的紀律是你要省略什麼。不要再次描述廚師。他已經在你剛剛傳遞的像素中了，重新描述他會給模型重新詮釋他的權限。

textCopy
1Continue from this exact frame, same man, same apron, same light. SHOT 1 (0-5s): He slides the bowl across the counter with both hands toward camera. SHOT 2 (5-10s): CUT TO over-the-shoulder of a customer's hands lifting wooden chopsticks and splitting them, sleeve cuffs of a wet grey raincoat visible. SHOT 3 (10-15s): CUT TO an extreme macro noodle pull, steam curling up past the lens, broth dripping back into the bowl.
2Audio: continuous rain and simmering carried over from before, ceramic on wood, chopsticks snapping, a slurp, the same distant train. No music, no narration.
3Hard cuts only. Same tungsten key from the hanging bulb, same cool blue night behind, same 35mm shallow depth of field and film grain.
4

生成 2，從生成 1 的最後一幀開始。相同的廚師、相同的頭巾花紋、相同的海軍藍上衣、相同的背景廚房。又是三個鏡頭，剪輯點在 4.92 秒和 9.04 秒。

跨越生成 1 和生成 2 之間接縫的兩秒循環

接縫本身：生成 1 的最後一秒進入生成 2 的第一秒。沒有轉場效果，只是一個剪輯。

步驟 4：使用參考影像影片移動鏡頭

最後一幀串聯有一個內建的限制：它總是從前一幀的鏡頭位置繼續。要跳到一個全新的角度，同時保持相同的主體，你需要切換端點。

模型：minimax/h3/reference-to-video。設定：refers = 步驟 1 的錨定畫面加上生成 2 的最後一幀，resolution 2K，duration 15，並在此處明確設定 ratio 為 16:9，而不是保留在 adaptive。這個端點最多接受九張參考圖片、三段參考影片和三個音訊片段，參考影片總長度上限為 15 秒（MarkTechPost，2026 年 8 月）。

textCopy
1Wide low-angle shot from the middle of the wet street looking back at the same noodle stall, the same chef inside it. SHOT 1 (0-6s): Rain streaks through the frame; two silhouetted customers sit at the counter; the chef works under the single bulb. SHOT 2 (6-11s): CUT TO the hand-painted wooden sign as kinetic white type animates on beside it, letter by letter: "MIDNIGHT BOWL - OPEN TILL 4AM". Type stays razor-sharp and locked to the sign as the camera drifts. SHOT 3 (11-15s): CUT BACK to the wide as the chef looks up, raises one hand in a small wave, and the bulb flickers once.
2Audio: rain, street ambience, a scooter passing, the same faint train, a single low sub hit as the type lands. No dialogue.
3Same chef, same apron and bandana, same signage and lantern colours as the reference images. Hard cuts only, film grain, 35mm, warm tungsten against cool blue.
4

那個 ratio 指令不是多此一舉。以下是當你在此端點上保留下拉選單不變時會發生的事情：

Atlas Cloud 上的 MiniMax H3 reference-to-video 遊樂場，載入了兩張參考圖片，長寬比保留在 adaptive，輸出面板中顯示 400 驗證錯誤

Atlas Cloud 上的 MiniMax H3 reference-to-video：兩張參考圖片都已載入，解析度 2K，而「長寬比」仍停留在其 adaptive 預設值。執行回傳 400：「ratio is required for t2va (text-only) and cannot be 'adaptive'; allowed: 16:9/4:3/1:1/3:4/9:16/21:9」。明確設定它後，相同的請求就能通過，下面的片段就是這樣製作的。注意頁面上方的說明也寫著「768P/1080P/2K，5s/10s」，而 schema 說是 768P 或 2K 以及 4 到 15 秒。請以 schema 為準。

我嘗試了三次，都無法讓遊樂場的長寬比下拉選單保留腳本化的變更，所以下面成功的生成 3 是來自 API，在請求主體中設定了 ratio: "16:9"。失敗的執行沒有花費任何費用。

生成 3。從濕漉漉的街道對面全新的鏡頭位置，相同的廚師，招牌上的動態白色文字在鏡頭移動時保持銳利。剪輯點在 5.29 秒和 10.96 秒。

原始錨定畫面與生成 3 中一個畫面的並排比較，顯示在 41 秒和兩次交接後，相同的廚師和招牌

左：步驟 1 的錨定畫面。右：生成 3 在第 41 秒標記處，兩次交接之後。相同的廚師、相同的頭巾、相同的海軍藍上衣、相同的手繪招牌、相同的紅燈籠。

步驟 5：測量真實的 MiniMax H3 影片長度，然後拼接

最後養成兩個習慣。首先，在購買十五秒之前，先進行一次便宜的預演。相同的提示詞，duration 4，你就能以大約四分之一的價格知道模型是否理解你的鏡頭列表。

相同鏡頭列表的 4 秒預演。測量為 107 幀，即 4.458 秒，完全符合網格預測。足以在購買完整片段之前判斷模型是否理解場景。

第二，在剪輯之前測量每個檔案，因為它們的長度都不是你要求的長度：

bashCopy
1# 真實幀數和容器時長，不是 duration x 24
2ffmpeg -i generation-1.mp4 -map 0:v:0 -c copy -f null - 2>&1 | grep -o 'frame= *[0-9]*' | tail -1
3
4# 硬剪輯拼接，無轉場，無重新編碼
5printf "file 'generation-1.mp4'\nfile 'generation-2.mp4'\nfile 'generation-3.mp4'\n" > list.txt
6ffmpeg -f concat -safe 0 -i list.txt -c copy midnight-bowl-45s.mp4
7

三個檔案各 362 幀，總共 1086 幀，我在完成的拼接檔上測量得到：45.25 秒的畫面，而不是 45 秒。這個差異很小，直到你拼接四十個檔案時才會顯現出來。

變體：對話、垂直畫面與 4 秒預演

一旦串聯鏈運作起來，同樣的三個端點就能涵蓋人們實際要求的大部分內容。

正反打對話。 將對話的雙方放在一次生成內，而不是分散在兩次生成中。唇形同步和音訊背景在同一任務中是連續的，但在不同任務之間是獨立的，所以分散在兩次生成的對話會得到兩個不相關的房間音調。將對話交流保持在一個片段內。

兩名年輕演員在混凝土樓梯平台上爭論，硬窗光斜照在他們身上，越肩拍攝

正反打鏡頭可行，只要兩個角度都在同一次生成內。

垂直畫面。 在 image-to-video 上，你不是設定比例，而是設定第一幀。產生一個垂直的錨定畫面，adaptive 就會跟隨它。我測量的一個片段回傳時為 1280x2276，與其 16:9 的同類片段具有相同的 243 幀計數，所以幀網格不在乎你的長寬比。

將 4 秒預演作為標準做法。 以每秒 $0.14 計算，四秒是 $0.56，而完整片段是 $2.10。在九個鏡頭的建置中，在承諾花費之前預演每個生成，成本低於一段浪費的 15 秒任務。

上限真正造成困擾的地方。 任何需要超過十五秒不間斷表演的內容。一段連續的 30 秒獨白不是串聯問題，而是跨接縫的唇形同步問題，而沒有任何提示詞紀律可以解決它。

45 秒的 MiniMax H3 影片長度要花多少錢

以每秒 $0.14 計算，一個完整的 15 秒生成是 $2.10。這是你唯一需要的數字；其他都是乘法。有趣的欄位是最後一個。

看看每個鏡頭成本欄，關於上限的恐慌大多消失了。規劃每次生成一個鏡頭，每個鏡頭成本是 $2.10。將三個鏡頭打包進每次生成，每個鏡頭成本是 $0.70。同樣的模型，同樣的十五秒上限，帳單金額只有三分之一。

保留率欄是人們忘記的那個。沒有什麼東西能在第一次嘗試時每次都成功，而一個假設它會成功的計劃，會在第二分鐘就用完預算。

為了了解這個上限與目錄中其他項目的相對位置，以下是截至 2026 年 8 月 4 日的所有資訊：

兩個結論。H3 的十五秒位於當前世代的前端，而非落後；而 Veo 3.1 的上限只有八秒。如果你真正需要的是從單一端點獲得一個長檔案，則存在專用的延伸模型，但在串聯鏈中切換模型意味著切換臉孔。

關於音訊、權重與 MiniMax H3 影片長度的一點誠實說明

三個注意事項，沒有一個會改變上限。

音訊不會跨生成傳遞。 每個任務都會從頭開始建立自己的立體聲背景。三個串聯的片段意味著三個不相關的雨聲背景，即使畫面完美匹配，你也會聽到變化。兩個解決方法：在每個提示詞中撰寫完全相同的環境音條款，讓背景盡可能接近；或者將拼接後的剪輯靜音，然後在下方鋪設一條連續的音軌。對於對話，將交流保持在單次生成內。

左側幾個分開的短音訊波形片段，之間有可見的間隙；右側在淺色統一背景上，一個連續的單一波形

左：串聯實際給你的結果。右：你必須在底下建立的東西。

自架伺服器無法解鎖更長的片段。 開放權重於 2026 年 8 月 2 日發布（Hugging Face，2026 年 8 月），在本地執行時，根據 ComfyUI 的設定說明，會得到 768 像素的短邊，並四捨五入到 32 的倍數。17 幀網格和 15 秒上限是相同的。社群授權目前也並未涵蓋歐盟、英國、韓國或美國，因此對於大多數團隊來說，API 是實用的途徑。

模型可以悄悄地改寫你的內容。 我曾遇到 H3 回傳 completed 狀態，但任務中默默刪除了我要求的一個元素。從每個片段中提取幀，在拼接之前檢查它們。在一個九個鏡頭的串聯鏈中，一個未經檢查的片段就是一個浪費的接縫。

常見問題

MiniMax H3 影片的最大長度是多少？

十五秒。duration 參數是一個從 4 到 15 的整數列舉值，預設值為 8，所以 16 會被拒絕，而 7.5 不是有效值。每個片段為 24 FPS，最高原生 2K，並在生成畫面的同時生成立體聲音訊。

MiniMax H3 可以生成超過 15 秒的影片嗎？

無法在單次生成中完成，且 API 沒有 extend 參數。要超過 15 秒，你需要透過串聯：將一個片段的最後一幀作為下一個片段的開頭，當你需要新的鏡頭角度時使用 reference-to-video，然後用硬剪輯拼接起來。有些消費端的前端介面會在 H3 之上疊加自己的延伸功能，以達到約 30 秒，但那是產品在進行拼接，而不是模型生成更長的內容。

為什麼我的 15 秒 MiniMax H3 片段實際上是 15.08 秒？

因為時長會向上對齊到 17 幀的網格。要求 15 秒會回傳 362 幀，即 17x21+5，在 24 FPS 下是 15.083 秒。要求 10 秒會回傳 243 幀，即 10.125 秒。只有 duration: 8 會落在整秒上，正好是 192 幀。如果你的編輯是影格精確的，請測量每個檔案，而不是計算 duration x 24。

我可以在一次 MiniMax H3 生成中放入多個鏡頭嗎？

可以，而且這是最大的節省來源。在提示詞中撰寫明確的帶時間碼鏡頭，並使用文字 CUT TO，然後加上一個連續性條款，列出必須在剪輯中保持不變的元素。我在一個真實的 15 秒生成中測量到十個乾淨的剪輯點。每個生成三個鏡頭既舒適又可靠，這將一個 $2.10 的片段變成了三個 $0.70 的鏡頭。

較短的 MiniMax H3 影片長度會比較便宜嗎？

是的，線性計費。計費按秒計算，每秒 $0.14，所以一個 4 秒的預演是 $0.56，而一個完整的 15 秒片段是 $2.10。解析度則是另一回事：768P 和 2K 在目錄中列於同一價格下，所以降低解析度不會省錢。縮短片段長度，而不是降低像素。

我需要多少個 MiniMax H3 片段才能製作一部一分鐘的影片？

四個，如果你每次都填滿十五秒的話。但改用鏡頭來計算：四次生成，每次三個鏡頭，總共十二個鏡頭的覆蓋量，這對一部一分鐘的廣告來說是正常的數量。然後將你的預算乘以大約三，以考慮你丟棄的片段。