您的第一个 POST 在十秒內就回傳了一個 task_id,看起來像個勝利。
然後整整六分鐘什麼事都沒發生。您從某個教學複製了 while status != "Success",這個迴圈就這麼空轉,因為這個端點已經不再回傳 Success 這個字。於是你改用 webhook,結果一個推送都沒收到,系統也完全沒告訴你為什麼。隔天早上你回去找昨天的渲染結果,連結已經 404。
這四件事看起來不相關,沒有一件是模型的錯。這四件事全部都是非同步合約的內容,但幾乎沒有人把這份合約寫下來。以下是完整的合約,外加最後產出的一部真正雙鏡頭短片。
重點摘要
- 三個端點,一個迴圈:建立(create)回傳一個
task_id後就斷線,你輪詢,你下載。所有困難的部分都在建立呼叫之後。 - 五個真實狀態是
queued、running、succeeded、failed、cancelled。沒有expired這個狀態,不管哪篇部落格文章怎麼說。 - 有兩樣東西會過期,但都不是狀態:下載 URL 有時間限制,任務記錄本身只能查詢 7 天。
- 如果你使用回呼(callback),MiniMax 會先送出一個帶有
challenge欄位的驗證請求,你必須在 3 秒內原封不動地回傳它。失敗的話不會收到任何錯誤,只會永遠沉默。 - 純文字生成時,
ratio是必要的,且不能是adaptive。圖片轉影片時,第一幀決定畫面比例,你傳入的任何ratio都會被忽略。
先看成品
本教學的全部成果:兩個 MiniMax H3 鏡頭,2K 畫質,串接後 14.6 秒。鏡頭 A 是圖片轉影片,源自產生的第一幀;鏡頭 B 是文字轉影片。請開啟聲音。音訊不是後製疊加的配樂,H3 在生成時一併渲染了齒輪、雨聲和那句低語。
用了三次 API 呼叫完成。一個圖片模型產生第一幀,兩個 H3 端點負責鏡頭,一行 ffmpeg 指令串接。以下程式碼就是產生它的程式碼。
為什麼大多數 MiniMax H3 教學在第二個請求就壞掉
幾乎所有關於這個模型的指南都停在建立呼叫。那是簡單的一半。建立呼叫驗證你的承載、給你一個 task_id 然後斷線,接下來你就獨自面對一個需要數分鐘的任務,以及一套沒人告訴你的規則。
失敗的模式無聊地重複。我在一個下午就遇到了這六種中的五種。
| 症狀 | 你看到的狀況 | 實際原因 | 修正方式 |
|---|---|---|---|
| 輪詢迴圈永不結束 | 終端機永遠在印,任務早就完成 | 你的結束條件比對的是 v1 的單字如 Success / Fail。v2 查詢端點回傳的是小寫的 succeeded / failed | 比對 v2 的列舉值,遇到任何不認識的狀態就拋出例外 |
| 文字轉影片立即收到 400 | 請求在渲染開始前就被拒絕 | ratio 遺漏,或設為 adaptive,純文字模式不接受 | 傳入明確的比例,例如 16:9 |
| 你的比例被靜默忽略 | 輸出的畫面不是你要求的 | 圖片轉影片從第一幀圖片推導畫面,所以 ratio 在那裡無效 | 將第一幀裁切或產生在你想要的畫面比例 |
| Webhook 從未觸發,無錯誤 | 零推送,日誌乾淨,API 沒有抱怨 | 驗證握手失敗。MiniMax 送出了 challenge,你的端點沒有在 3 秒內原封不動回傳 | 同步回答 challenge,在任何認證或佇列中介軟體之前 |
| 昨天的 URL 404 | 下載連結失效,渲染似乎消失 | 下載 URL 有時間限制。渲染本身沒問題 | 再次查詢同一個 task_id 取得新 URL,在 7 天視窗內 |
| 隨機 429(負載高時) | 部分提交被拒絕,無佇列 | 並行數有上限,是硬上限,不是等待線 | 限制自己正在進行中的請求數量,並重試提交,而非渲染 |
第一行就是會吃掉整個晚上的那一種,值得精確說明。MiniMax 舊版的影片 API 使用大寫的單字回報進度,例如 Preparing / Queueing / Processing / Success / Fail。H3 使用的 v2 查詢端點回傳的是 queued、running、succeeded、failed、cancelled(MiniMax API 參考文件,2026 年 8 月)。許多第三方轉銷商的文件仍然印著舊版,或在一頁中混合兩種版本。如果你從其中一個繼承了迴圈,它永遠無法終止,因為它等待的字串永遠不會被送出。
MiniMax H3 教學工作流程:三個端點,五種狀態,一個迴圈
H3 於 2026-07-31 推出,是一個全模態影片模型:文字、圖片、影片和音訊都位於同一個上下文視窗中,最高可輸出 15 秒 2K 畫質,內建立體聲音訊(MarkTechPost,2026 年 8 月)。對 API 來說,這意味著一個建立端點,帶有 content 陣列,你在陣列中放入的內容決定了你處於哪個模式。
| 模式 | content 的內容 | 圖片項目的 role | ratio 的作用 | 使用時機 |
|---|---|---|---|---|
| 文字轉影片 | 一個文字項目 | 無 | 必要,且不接受 adaptive | 沒有來源圖片的鏡頭,完全控制畫面 |
| 圖片轉影片 | 文字項目加圖片項目 | first_frame(可選地也加 last_frame) | 被忽略,由第一幀決定 | 動畫化你已經設計好的靜態畫面 |
| 參考轉影片 | 文字項目加參考項目 | reference_image(也可 reference_video、reference_audio) | 必要,與純文字模式相同 | 保持角色或聲音在鏡頭間一致 |
而你的程式碼實際上必須處理的部分。五種狀態,五個不同分支。
| 狀態 | 意義 | 你的程式碼該做的事 |
|---|---|---|
| queued | 已接受,等待排程 | 繼續輪詢,退避 |
| running | 正在渲染 | 繼續輪詢,退避 |
| succeeded | 完成,content.url 已填入 | 立即下載,在此次迭代中 |
| failed | 渲染失敗 | 讀取錯誤內容,記錄日誌,不要盲目重試相同承載 |
| cancelled | 任務已取消 | 退出迴圈,視為終止狀態 |
| 其他任何值 | 不在列舉中 | 丟出例外。一個被你默默當作「繼續等待」的新狀態,就是上表中那個錯誤 |
沒有 expired 狀態。這個字經常被附加到這個 API,但它屬於另外兩件事:下載 URL(有時間限制且可重新整理)和任務記錄(僅可查詢最近 7 天)。這兩者都在步驟 4 中說明。
在程式碼之前還有一個數字。H3 的影片生成並行度是以連線數而非每分鐘請求數來限制的:免費方案 2 個並行任務,付費後 15 個(MiniMax 速率限制,2026 年 8 月)。超過上限會立即收到 429。系統不會為你排隊。我也曾透過路由閘道推送 20 個並行 H3 任務,且全部成功著陸;但同一個設定在不同日子也曾收到 429,所以請將任何超過文件上限的數字視為天氣,而非常數。
直接或透過閘道
兩種方式的三個步驟相同,但字串不同,這在凌晨除錯時很重要。
| MiniMax 直接 | 統一閘道(Atlas Cloud) | |
|---|---|---|
| 提交 | POST /v2/video_generation | POST /api/v1/model/generateVideo |
| 輪詢 | GET /v2/query/video_generation/{task_id} | GET /api/v1/model/prediction/{id} |
| 狀態字詞 | queued / running / succeeded / failed / cancelled | 成功時 completed,失敗時 failed |
| 推送通知 | 回呼 URL,需 3 秒內完成 challenge 握手 | 輪詢 prediction id |
| 並行度 | 免費 2,付費 15,硬 429 | 未公開為每模型上限,實際測量更寬 |
| 同一金鑰的第一幀圖片模型 | 否,需分開帳戶 | 是,GPT Image 2 和 H3 共用同一金鑰 |
| H3 價格 | 按解析度分級公佈 | 按輸出秒數計費,依解析度分級,提交前在「執行」按鈕上報價 |
我選擇在閘道上執行此教學的流程,純粹是因為倒數第二行:第一幀來自 OpenAI 的圖片模型,兩個鏡頭來自 MiniMax,我不想為了 14 秒的影片而管理兩個廠商、兩組金鑰和兩個計費頁面。如果你已經在 MiniMax 平台內,就留在那裡,以下迴圈除了路徑和狀態字詞外,完全適用。
Hailuo AI 影片產生器:在寫任何程式碼之前如何使用
如果你搜尋如何使用 Hailuo AI 影片產生器而來到這裡,你來對地方了,而且目前還不需要任何程式碼。Hailuo 是 MiniMax 面向消費者的應用程式,H3 是 API 使用的模型名稱。同樣的引擎,不同的入口。
三分鐘,無需終端機:
- 開啟一個模型頁面,例如 MiniMax H3 圖片轉影片。遊樂場在頁面的右側面板。
- 放入第一幀圖片,或切換到文字轉影片頁面,直接寫提示詞。大聲說出你想聽到的聲音,而不只是你想看到的畫面:H3 在同一輪中生成音訊,所以「雨滴打在玻璃上,微小的伺服馬達喀噠聲」是真正的指令,不是裝飾。
- 按下執行。按鈕在你提交之前,就會顯示你選擇的設定精確費用。等待,下載。
這就是完整的無程式碼路徑,對於一次性片段來說,這確實是更快的方式。當你想要十個變體,或者想要由另一個模型生成第一幀並直接輸入時,再回來看程式碼。接下來就是這部分。
MiniMax H3 教學:建立、輪詢、下載、重複
一個範例貫穿所有七個步驟:一位鐘錶匠修理一隻小型黃銅機械鳥,對牠低語了一句話,然後鳥兒飛出工坊。兩個鏡頭。鏡頭 A 是圖片轉影片,以便設計室內場景。鏡頭 B 是文字轉影片,因為沒有天空的來源畫面。
步驟 1:用 GPT Image 2 生成第一幀
圖片轉影片會忽略 ratio,所以第一幀就是你決定鏡頭 A 畫面的地方。以 16:9 和最高品質等級生成,因為 H3 會繼承其中的每一個缺陷,然後再加上動態模糊。
模型:openai/gpt-image-2/text-to-image。設定:品質 high,2048x1152,16:9,PNG。
text1黃昏時分雜亂的鐘錶匠工坊,暖色調的鎢絲燈照在斑駁的橡木工作台上。一位穿著皮革圍裙的老工匠彎腰靠近一隻躺在他捧著的手掌中的小型黃銅機械鳥,鳥的翅膀護板半開,露出細小的齒輪。雨水沿著身後豎框窗戶流下;左邊的煤爐發出琥珀色光芒。淺景深,35mm,光束中的體積灰塵,深琥珀與青綠色調,照片級真實,無文字。 2

Atlas Cloud 上的 GPT Image 2 遊樂場,顯示本教學的第一幀提示詞,以及輸出面板中渲染的鐘錶匠工坊
Atlas Cloud 上的 GPT Image 2,品質 high,2048x1152。執行按鈕在你提交之前,顯示你所選設定的精確費用,本次為 $0.1745。
保留回傳的 URL。步驟 2 將它直接餵給 H3,無需下載往返。
步驟 2:建立 MiniMax H3 任務並保留 task_id
建立呼叫做兩件事,然後就不再關心你:它驗證承載,並回傳一個 task_id。這裡出現 400 代表你的承載有問題,而不是暫時性失敗,所以不要把它放在重試迴圈後面。其他類型的問題會在稍後輪詢時出現。
一個能真正省錢的習慣:在做任何其他事之前,先將 task_id 持久化。任務只能查詢 7 天,如果你的程序在記憶體中帶著 id 當掉,你就付了錢卻再也無法取得渲染結果。
python1import os, json, time, requests 2 3BASE = "https://api.minimax.io" 4HEADERS = { 5 "Authorization": f"Bearer {os.environ['MINIMAX_API_KEY']}", 6 "Content-Type": "application/json", 7} 8 9def create_task(payload: dict) -> str: 10 r = requests.post(f"{BASE}/v2/video_generation", 11 headers=HEADERS, json=payload, timeout=60) 12 if r.status_code == 400: 13 # 你的承載有問題。重試只會再次得到錯誤。 14 raise ValueError(f"rejected: {r.text}") 15 r.raise_for_status() 16 task_id = r.json()["task_id"] 17 with open("tasks.jsonl", "a") as f: # 在任何其他事之前先持久化 18 f.write(json.dumps({"task_id": task_id, "at": int(time.time()), 19 "payload": payload}) + "\n") 20 return task_id 21 22SHOT_A_PROMPT = ( 23 "老工匠的雙手穩住那隻黃銅鳥。牠的玻璃眼睛一閃一閃地亮起," 24 "翅膀護板一片片喀噠打開。他靠近,對著麥克風低語:" 25 "「讓我們看看你是否還記得天空。」緩慢的 50mm 推近鏡頭,燈光斜照在黃銅上," 26 "雨滴打在窗上,煤爐劈啪作響,他的聲音下傳來微小的伺服馬達喀噠聲。" 27 "暖琥珀色主光,青綠色窗戶補光。無螢幕文字。" 28) 29 30shot_a = create_task({ 31 "model": "MiniMax-H3", 32 "resolution": "2K", 33 "duration": 8, 34 # 此處刻意不寫 "ratio":圖片轉影片從第一幀取得畫面比例 35 "content": [ 36 {"type": "text", "text": SHOT_A_PROMPT}, 37 {"type": "image_url", "role": "first_frame", 38 "image_url": {"url": FIRST_FRAME_URL}}, 39 ], 40}) 41print("shot A task:", shot_a) 42
以下是該精確提示詞和第一幀作為任務執行的情況,讓你可以從另一端看到健康的提交長什麼樣子:

Atlas Cloud 上的 MiniMax H3 圖片轉影片遊樂場,載入了工坊第一幀,輸出面板中顯示渲染完成的片段
MiniMax H3 圖片轉影片:左側載入第一幀,右側 OUTPUT 中顯示完成的 2K 片段。請注意長寬比欄位固定在 adaptive,以及 2K 8 秒的 $1.12 報價。
步驟 3:輪詢它,並處理所有五種 MiniMax H3 狀態
這就是每個人都會搞錯的迴圈,所以值得完整寫出來。四條規則:退避而非猛打,設定總等待時間上限,將 succeeded 視為「立即下載」,遇到列舉中沒有的狀態就拋出例外。
python1TERMINAL_OK = {"succeeded"} 2TERMINAL_BAD = {"failed", "cancelled"} 3IN_FLIGHT = {"queued", "running"} 4 5def poll(task_id: str, timeout_s: int = 900) -> dict: 6 delay, deadline = 3.0, time.time() + timeout_s 7 while time.time() < deadline: 8 r = requests.get(f"{BASE}/v2/query/video_generation/{task_id}", 9 headers=HEADERS, timeout=30) 10 r.raise_for_status() 11 task = r.json()["task"] 12 status = task["status"] 13 14 if status in TERMINAL_OK: 15 return task # content.url 現在有效 16 if status in TERMINAL_BAD: 17 raise RuntimeError(f"{status}: {json.dumps(r.json())[:400]}") 18 if status not in IN_FLIGHT: 19 # 列舉中沒有的狀態。不要落入「繼續等待」的邏輯。 20 raise RuntimeError(f"unknown status {status!r} -- 請查看變更日誌") 21 22 print(f" {status} ... 將在 {delay:.0f}s 後再次檢查") 23 time.sleep(delay) 24 delay = min(delay * 1.5, 15.0) # 3s -> 15s 上限 25 raise TimeoutError(f"{task_id} 在 {timeout_s}s 後仍未結束") 26
其中有三個地方是刻意設計的:
status not in IN_FLIGHT 會拋出例外而非繼續。如果 MiniMax 下一季新增第六個狀態,你需要一個響亮的當機,而不是一個等待永遠不會出現的字詞的迴圈。這一行就是錯誤教學與本教學的差別。
failed 不會重試。失敗的渲染通常表示提示詞觸發了過濾器,或承載中有不良組合,再次送出完全相同的承載只會花費全額費用得到相同的失敗。記錄內容,查看它,然後決定。
退避從 3 秒開始,最終停在 15 秒。2K 的 H3 需要數分鐘,而非數秒。每秒輪詢一次只會浪費你在查詢端點上的速率限制。
步驟 4:在 URL 過期前下載
當 succeeded 狀態抵達時,立即將檔案串流到磁碟。content.url 中的 URL 明確是一個有時效性的連結:「請及時下載或儲存;過期後再次查詢以取得新 URL」(MiniMax API 參考文件,2026 年 8 月)。它不是一個你可以放進資料庫然後忘記的 CDN 路徑。
後半段是好消息,也是你隔天早上遇到 404 的解答。渲染結果沒有消失。再次查詢同一個 task_id,你會得到一個新的 URL,最多可到建立後的 7 天。
python1def download(url: str, path: str) -> str: 2 with requests.get(url, stream=True, timeout=300) as r: 3 r.raise_for_status() 4 with open(path, "wb") as f: 5 for chunk in r.iter_content(1 << 20): 6 f.write(chunk) 7 return path 8 9def refresh_url(task_id: str) -> str: 10 """連結失效?渲染結果沒問題。在 7 天視窗內再次詢問。""" 11 r = requests.get(f"{BASE}/v2/query/video_generation/{task_id}", 12 headers=HEADERS, timeout=30) 13 r.raise_for_status() 14 return r.json()["task"]["content"]["url"] 15 16task = poll(shot_a) 17download(task["content"]["url"], "shot-a.mp4") 18
鏡頭 A 的回傳結果,與它起始的靜態圖片並排比較:

並排比較:左側是步驟 1 產生的第一幀靜態圖片,右側是完成的 MiniMax H3 片段中的一個畫面,顯示鳥的翅膀護板已打開,眼睛發亮
左:步驟 1 的 GPT Image 2 靜態圖片,完全如提交時所示。右:從 H3 回傳的 2K 片段中擷取的一個畫面。相同的場景,相同的光線,護板和眼睛是移動的部分。
步驟 5:使用 MiniMax H3 文字轉影片的鏡頭 B,此處 ratio 是必要的
沒有天空的來源畫面,所以鏡頭 B 是純文字。這將 ratio 的規則從「忽略」翻轉為「必要」:對於純文字提示詞,ratio 是必要的,且不能是 adaptive(MiniMax API 參考文件,2026 年 8 月)。遺漏它或送出 adaptive,你會立即收到 400,在任何渲染開始之前。
模型:minimax/h3/text-to-video。設定:2K,持續時間 6,比例 16:9。
text1黃銅鳥衝破工坊半開的天窗,飛入雨後的傍晚天空,翅膀在齒輪的嗡嗡聲中拍打,水滴從金屬羽毛上飛濺,牠爬升過潮濕的石板屋頂,朝向一縷金色雲層。攝影機在其後方升起,24mm,逆光從低角度太陽形成邊緣光。音效:翅膀伺服馬達嗡嗡作響,風聲漸強,遠處教堂鐘聲,雨聲淡出。無文字。 2
python1shot_b = create_task({ 2 "model": "MiniMax-H3", 3 "resolution": "2K", 4 "duration": 6, 5 "ratio": "16:9", # 此處必要。省略或傳入 "adaptive" 會得到 400 6 "content": [{"type": "text", "text": SHOT_B_PROMPT}], 7}) 8download(poll(shot_b)["content"]["url"], "shot-b.mp4") 9

Atlas Cloud 上的 MiniMax H3 文字轉影片遊樂場,顯示鳥起飛的提示詞,以及輸出面板中完成的片段
MiniMax H3 文字轉影片,使用鏡頭 B 的提示詞,長寬比明確設為 16:9。此執行使用了頁面預設的 8 秒,而非上方承載中的 6 秒。
步驟 6:使用回呼跳過輪詢,並在 3 秒內回應 challenge
如果你寧願被告知而非主動詢問,可以在建立呼叫時傳入 callback_url。只有一個陷阱,它在 API 參考文件中的一個括號內說明,而且是自託管回呼最常見的失敗原因。
在 MiniMax 推送任何內容給你之前,它會送出一個包含 challenge 欄位的驗證請求,而且「你必須在 3 秒內原封不動地回傳 challenge 以完成驗證」(MiniMax API 參考文件,2026 年 8 月)。錯過它,任何地方都不會有錯誤訊息。你的建立呼叫持續成功,你的渲染持續完成,但你永遠不會收到任何推送。任何日誌都不會告訴你原因。
十二行 FastAPI 程式碼,其中的順序是關鍵:
python1from fastapi import FastAPI, Request 2 3app = FastAPI() 4 5@app.post("/minimax/callback") 6async def callback(req: Request): 7 body = await req.json() 8 if "challenge" in body: # 驗證握手,先回答它 9 return {"challenge": body["challenge"]} # 原封不動,同步,無認證檢查 10 task_id = body.get("task_id") 11 status = body.get("status") 12 enqueue(task_id, status) # 真正的通知:移交,快速回傳 13 return {"ok": True} 14
導致它失敗的錯誤,依我見過的頻率排序:
- 驗證請求通過了你的認證中介軟體並收到 401 或重新導向。驗證在本質上是未經認證的。將該路徑加入白名單。
- 處理器將 challenge 推入佇列並非同步回答。太遲了。那個回覆必須在該請求的回應本體中。
- 值被重新序列化、修剪或包裝。逐位元組回傳它。
- 你透過隧道測試無伺服器開發伺服器,冷啟動時間就超過 3 秒。先預熱它,或針對已在執行的程序進行驗證。
順便一提,輪詢完全沒問題。如果你每小時只有少數幾個任務,步驟 3 的迴圈程式碼更少,也更不容易出錯。當你有許多任務且不想為每個任務都設一個輪詢器時,回呼才值得。
步驟 7:將兩個鏡頭串接成一部影片
兩個鏡頭都以 2560x1440 的 h264 格式回傳,24fps,AAC 立體聲音訊,32kHz。相同的容器,相同的所有東西,所以這是一個串流複製而非重新編碼。沒有品質損失,無需等待。
一個值得預期的小驚喜:要求 6 秒,結果得到了一個 6.58 秒的檔案。持續時間接近你要求的,但不會精確到幀,因此兩個鏡頭加起來是 14.62 秒,而不是整齊的 14 秒。
bash1printf "file 'shot-a.mp4'\nfile 'shot-b.mp4'\n" > list.txt 2ffmpeg -f concat -safe 0 -i list.txt -c copy brass-bird-two-shot.mp4 3
該輸出就是本文頂部的影片。如果 -c copy 報錯,表示你的兩個鏡頭有不同的解析度或幀率,這在 H3 上意味著你在兩次呼叫之間更改了 resolution。讓它們一致,或者放棄 -c copy 並接受一次重新編碼。
值得偷學的 MiniMax H3 教學變體
在上面的迴圈運作之後,有五件事值得一試,大致按它們能幫你省多少錢的順序排列。
先以 768P 草稿,再以 2K 完成。 兩個等級都是同一個模型,768P 每秒的費用約低 29%。以較短且便宜的方式渲染你的候選片段,觀看它們,然後只對獲勝者使用相同的提示詞以 2K 重新執行。這就是分鏡清單中大部分節省的所在。你實際需要哪個等級來交付是個獨立的問題,我在768P 對比 2K 中討論過。
持續時間可以是 4 到 15 之間的任意整數。 不是一組預設值。如果動作在 7 秒結束,就要求 7 秒,不要再為 8 秒付費。
第一幀加最後一幀。 送出第二個圖片項目,帶有 role: "last_frame",H3 會建立兩者之間的轉場。對於你已經設計好的鏡頭之間的過渡很有用。
參考轉影片以保持連續性。 role: "reference_image" 可以讓角色在鏡頭間保持一致,而不是每次生成都重新擲骰決定臉部。還有一個對應的 reference_audio 角色,參考片段時長為 2 到 15 秒,這是你如何保持語音一致的方法。請參閱參考轉影片。
垂直說話頭像。 使用 ratio: "9:16" 並在提示詞中加入對話台詞,是目前這個模型用量最高的用途,因為音訊從同一輪生成,且嘴型無需額外的唇形同步步驟即可對上。
提示詞技巧是與非同步管道不同的技能,如果你的鏡頭技術上沒問題但視覺上平淡,問題出在本文的上游。從 H3 提示詞指南 開始。
執行此 MiniMax H3 教學的成本
產生本文頂部影片的實際明細項目,由「執行」按鈕報價,並於 2026-08-12 驗證。H3 按輸出秒數計費,費率依解析度分級:2K 任務 8 秒報價 $1.12,即每秒 $0.14,目錄中的 $0.10 起始費率是 768P 等級。目前所有三個 H3 端點都是全價,沒有折扣。
| 步驟 | 模型 | 設定 | 費用 |
|---|---|---|---|
| 第一幀 | GPT Image 2 文字轉圖片 | 品質 high,2048x1152 | $0.1745 |
| 鏡頭 A | H3 圖片轉影片 | 2K,8s | $1.12 |
| 鏡頭 B | H3 文字轉影片 | 2K,16:9,6s | $0.84 |
| 完成的影片 | 14.6s,兩個鏡頭,2560x1440,立體聲音訊 | $2.13 | |
| 本文的截圖執行 | H3 i2v + t2v | 2K,各 8s | $2.24 |
值得注意的是,相同的兩個鏡頭以 768P 草稿,費用會是 $0.80 和 $0.60,而非 $1.12 和 $0.84,約省 29%,而這些畫面足以讓你判斷一個鏡頭的好壞。
兩個容易花冤枉錢學到的計費細節。在提交時被拒絕的請求不收費,所以因缺少 ratio 而出現的 400 是免費的。但渲染出無用內容的請求不是免費的:如果任務達到 succeeded,你就會被收費,即使輸出不是你想要的。這就是以 768P 草稿的真正理由。
每秒費率、768P 與 2K 比較,以及費用如何隨持續時間變化的詳細說明,請參閱本文的配套文章 MiniMax H3 API 定價。本文是程式碼,那篇是帳單。
出貨前的歸屬與區域
在將任何內容公開之前,有兩件事需要檢查。MiniMax 的 API 條款包含一項有條件辯護義務,涵蓋針對 API 輸出的專利和版權索賠,但該義務不延伸至商標或肖像,因此提示詞中出現可識別的標誌或真人仍然是你的問題。另外,H3 的開放權重授權包含一項排除區域條款,該條款管轄下載的權重及其輸出,而非託管 API,後者的條款指定了你可以選擇的美國服務區域。請閱讀你實際簽署的合約。並在你的 UI 中將 H3 輸出標示為 H3 輸出。
MiniMax H3 教學常見問題
MiniMax H3 任務狀態有哪些?有 expired 這個狀態嗎?
五個:queued、running、succeeded、failed、cancelled。沒有 expired 狀態。有兩樣東西會過期並被混淆為一個:content.url 中的下載 URL 有時間限制,任務記錄本身只能查詢最近 7 天。
我必須使用回呼嗎?還是輪詢對 MiniMax H3 來說也可以?
輪詢沒問題,而且程式碼更少。當你有足夠多的並行任務,以至於每個任務都設一個輪詢器顯得很蠢時,再使用回呼。如果使用回呼,端點必須在 3 秒內同步地將 challenge 欄位原封不動回傳,且在任何認證中介軟體之前。失敗的握手不會產生任何錯誤訊息,只會永遠沉默。
為什麼我的 MiniMax H3 文字轉影片請求得到 400,並顯示「ratio 是必要的,且不能是 adaptive」?
因為你處於純文字模式,該模式下沒有第一幀可以推斷畫面比例。請傳入一個明確的值:21:9、16:9、4:3、1:1、3:4 或 9:16。同樣的規則也解釋了為什麼 ratio 在圖片轉影片中看起來沒作用,因為第一幀決定了畫面,你傳入的任何比例都會被忽略。
我可以同時執行多少個 MiniMax H3 任務?
記錄的上限是基於連線數:免費方案 2 個並行任務,付費方案 15 個。超過上限你會立即收到 429,而非排隊位置,所以請限制你自己正在進行中的請求數量。路由閘道有時可以吸收更多,我曾有過 20 個並行任務全部完成,但同一個設定在其他日子也遇過 429。不要建立一個假設較高數字的排程器。
我的 MiniMax H3 影片 URL 一天後就 404 了。渲染結果消失了嗎?
沒有。URL 過期了,渲染結果沒有。再次查詢同一個 task_id,回應會攜帶一個新的 URL,在 7 天查詢視窗內任何時間都可以。7 天後任務記錄本身就不再可查詢,這就是為什麼步驟 2 在做任何其他事之前先將 task_id 持久化。
我搜尋「hailuo ai video generator how to use」然後來到了一個 MiniMax H3 教學。我來對地方了嗎?
是的。Hailuo 是消費端應用程式,H3 是 API 使用的模型名稱。同樣的引擎。如果你想要一個片段,使用上方工作流程區段的遊樂場路徑,無需程式碼。如果你想要十個變體,或想要將另一個模型的第一幀輸入進來,那麼七個步驟就是為你準備的。






