如何使用 MiniMax H3：提示詞、本地運行與不垃圾的音頻

8月4日，Simon Willison 下載了約 115 GB 的權重，將一個非官方的、為MiniMax H3而設的 MLX 移植版指向他的 M5 Max MacBook Pro，並要求一隻彩虹色的臭鼬在超市裡跳過一根長滿苔蘚的木頭。不到45分鐘後，他得到了一段他形容為「確實令人印象深刻」的片段——配上他形容為「怪異、像語音般的雜訊」的音軌。他自己的診斷才是最有用的部分：他沒有給模型任何音訊指示，也沒有先閱讀提示指南。這就是開始使用 H3（亦以 Hailuo 3.0 之名銷售）時最簡短的體驗總結。畫面的生成幾乎是免費附贈的。其他一切——聲音、鏡頭時機、2K 畫質、必須在連續四槍中存活下來的角色——你都得明確要求，而且格式比當今幾乎任何其他影片模型都要嚴格。

這是一份使用指南，而非發布報導。文中貫穿三層資料來源，且每次都會標明：公司的官方文件（模型卡、儲存庫內附的兩份提示詞撰寫指南、平台 API 文件）；社群發現來自實際執行過的使用者——ComfyUI 的維護者、獨立評測者、經銷商文件以及 Hugging Face 討論串，日期介於 2026 年 7 月 31 日至 8 月 5 日之間；此外還有少數我們親自閱讀主要檔案並加以說明的部分。除非另有註明，社群數據皆為在未受控硬體上的單一報告。當實務工作者彼此意見分歧時，我們會呈現分歧而非逕行裁決。

首先：你很可能不是正在運行整個模型。

H3 發布第一週的大多數困惑，都追溯到一個被行銷文案模糊化的結構性事實：H3 並非單一模型。根據其模型卡，它是一個由三部分組成的系統，而且只有中間部分被開源。

• H3-Context-IR — 一個多模態指令預處理器。它會讀取你的文字、圖片、音訊和影片，推理它們之間的關聯，並輸出你所請求內容的結構化、語義增強表示。僅提供託管 API。它以獨立的任務類型形式提供，回傳增強的 prompt，且完全不回傳影片。

• H3-Base —— 真正能生成畫面和聲音的 33B 參數生成模型。這是開放權重的部分。

• H3-Regenerate-2K — 一種情境內重新生成流程，可將 768p 結果提升至 2K。僅限託管 API。

接著有兩個後果立刻浮現，它們決定了你整個工作流程。首先，本機生成的上限是 768p。H3 的原生畫布短邊為 768 像素，最高為 768×1344——16:9 約為 1344×768。如果你的 ComfyUI 輸出不是 2K，那並非壞了；你下載的套件是 H3-Base，其中不含升頻模組。其次，託管 API 會修正草率的提示詞，而你的本機安裝不會。Context-IR 在付費 API 呼叫中所做的一切——推斷結構、解析每個引用指的是什麼、補齊你遺漏含糊的部分——現在都成了你必須在 H3-Base 看到你的文字之前，親手或藉由另一個模型來執行的步驟。就這一項不對稱，解釋了大多數「同樣的提示詞在 Hailuo 上有效，在 ComfyUI 中卻看似壞掉」的回報。

儲存庫本身有幾點值得注意：這些權重帶有minimax-h3-community-license-agreement標籤，而非 Apache 或 MIT（這點稍後會詳細說明，因為它正是決定你能否出貨的關鍵）；該模型標示為 33B 參數（F32/BF16）；截至今日恰好有一家推論供應商——fal——被列為提供服務。在此基礎上已有二十三個微調版本、二十個量化版本和三十一個 Spaces，這充分顯示了社群的反應速度。

提示詞格式：鏡頭區塊，而非時間碼

這就是社群與文件公開衝突的所在，而此事比本文中任何其他單一內容都更為重要。

傳播最快的模板——透過 Reddit，再傳入多個已出版的指南——將影片片段切分為時間碼區間：[0s-2s]、[2s-5s]，以此類推，接著是六區塊結構：風格契約、時間軸、攝影、音訊、拼寫文字和負面清單。它是透過閱讀公司提供的45個範例提示逆向工程出來的，而且並非無稽之談：那些範例確實是附有音效提示表的拍攝清單，中位數長度約為130個中文字，最長則達到657和858個字。

但公司自己的VIDEO_PROMPT_WRITING_GUIDE_base_en.md，放在儲存庫的docs資料夾中，卻規定了不同的做法。它依鏡頭區塊，而非按時間範圍。我們直接閱讀它；它要求的結構是：

• 指令 — 影像對齊規則，用於關鍵影格模式（I2VA、FL2VA、L2VA），並在純文字轉影片時省略。

• integrated_multimodal_description — 主體內容，分為[Shot 1]、[Shot 2]，以此類推。

• 整體音景 — 以一至四句描述劇情內聲音。

• non_diegetic_music——一到三句配樂說明。

在那個框架裡，這些慣例具體到足以檢查。 [Shot 1] 完全不帶時間戳——後續鏡頭以絕對切換開場，寫法像是「在 00:03.500，鏡頭切到⋯⋯」。攝影機運動的記述方式是運動類型加上幅度與速度，融入自然的英文而非堆疊成標籤：一個小幅度的緩慢推近，而不是 camera: dolly-in, slow。可用的運動是常見的那一組——變焦、搖攝、俯仰、跟拍、弧線、POV，以及輕微或強烈的晃動變體。對話會包在標籤中：<d>[English] Get in the car.</d>，標點符號會原樣保留，絕不翻譯或改寫。說話者會獲得穩定的 ID——(S1)、(S2)，以及聯合台詞用的 (S1,S2)——並在首次出現時描述年齡、性別、音色與口音。旁白會標記為畫外音台詞，並加上明確的註記表示嘴巴保持閉合，這樣就能阻止模型把敘事對到臉部唇形上。交叉剪接的對話會使用一個 <scenetrans> 標記，加上一段連續性說明。

該指南的明文禁令與其規則一樣具有參考價值：不要為第一個鏡頭加上時間戳記，不要在 overall_soundscape 中重複對話、歌聲或畫面內的音樂，不要在 non_diegetic_music 中使用抽象的情緒詞語，而且絕不重寫任何一句台詞。還有一個值得注意的遺漏——官方指南完全沒有 negative-prompt 章節，這表示社群中流行的模板裡的「禁止轉場」清單是社群自行發明的，並非有文件記載的功能。

該如何認真看待這個衝突？在 Hugging Face 的 H3 儲存庫討論中，一位社群成員貼出時間碼風格的結構作為指南，另一位從業者則直率地回應說，他們用過類似的結構，那完全是錯的，大家應該改看隨附手冊。這是一個人反駁另一個人，並非維護者的裁定。我們對證據的解讀是：兩者透過託管 API 都能運作，因為 Context-IR 會正規化你傳送的任何內容；但若直接使用 H3-Base，只有文件記載的格式才可靠。如果你執行的是本機權重，請遵循儲存庫中的檔案。如果你使用 API，而時間碼提示詞能為你取得良好的剪輯片段，那是前處理器在替你完成這項工作，你不該因此斷定是該格式的功勞。

將一份隨意的簡報編譯成 H3 的方言

以 Willison 的十二字提示作為輸入——一隻彩虹色的臭鼬在超市裡躍過一根長滿青苔的原木。按照記載的方式撰寫，大致會變成：一個[Shot 1]區塊，開頭先點明風格（真人實拍、手持攝影、螢光燈照明）與畫面（超市走道、橫跨亞麻油地氈的長滿青苔的原木、向後退縮的貨架），接著依物理順序描述主體與動作——兩步墊步、一次蹲伏、躍起、落地——攝影機則是一段緩慢、低振幅的跟拍運鏡，結束在原木的另一側；一個overall_soundscape：爪子刮過亞麻油地氈、原木潮濕的摩擦聲、冷藏設備的嗡嗡聲，以及遠處手推車的輪子聲；以及一個non_diegetic_music：一段簡短、輕盈、沒有人聲的撥弦配樂。這裡面沒有任何天才創意。這是同一個想法，只是確實提供了 H3 要求的四樣東西——而這就是未經要求的環境音與你設計的配樂之間的差別。

這一步既機械、重複，又浪費人力；公司正是因此推出了一款工具，卻幾乎沒有媒體報導提及它。該儲存庫包含一個名為skills的目錄，內含九個代理技能，其中第一個——h3-prompt-writing——做的正是這件事：它會接受請求，並在全部五種生成模式下寫出結構化的 H3 提示詞，還包含音景與音樂章節。另外八個是類型配方（產品廣告、3D 動畫短片、紙藝解說、音樂錄影帶字幕、合作遊戲開場、手繪與真人實拍混合等），將相同的格式包裝成一個工作流程。

執行該技能需要的是文字模型，而非影片模型，而這正是路由器真正有用、而非只是插頭的地方。該公司自家的 LLM，MiniMax M3，是這項工作的明智選擇，也已上架於 OrcaRouter，價格為每百萬輸入 token 0.30 美元、每百萬輸出 token 1.20 美元——這是供應商牌價，因為我們以 0% 加成的方式轉售——並具備 100 萬 token 的上下文視窗，且罕見地接受影片作為輸入類型。最後這項細節正是它契合的原因：你可以在一次呼叫中，將官方提示詞指南、你的需求簡報，以及實際的參考片段交給它，然後取回[Shot N]區塊，該區塊會描述它。編譯提示詞只需不到一美分，相較於按秒計費的影片生成，因此完全沒有理由手寫這些。兩個誠實的提醒：H3 影片生成本身並不在 OrcaRouter 上運行——片段來自該公司的平台、fal，或你自己的 GPU——而編譯步驟只是便利措施，並非品質保證。路由器在此的價值在於，管線的文字部分位於單一金鑰之後，具備自動故障轉移，因此批次中途的供應商中斷不會讓渲染佇列卡住；而且將 M3 換成不同模型以比較編譯後的提示詞，只是改一行字串，而非重新簽訂合約。

第一天，每個人都會栽在音訊上。

第一週中最廣獲證實的失敗模式，就是 Willison 遇到的那種：沒有明確指定聲音，H3 就會自行編造出某種東西，而且弄得很糟。他從一個沒有音訊指示的提示詞中得到了近似語音的雜訊。官方範例的逆向工程解析以較輕微的形式報導了同類失敗——省略音訊區塊，模型便會產出未要求的環境音——並將這些視為未指定而非錯誤，這正是思考音訊-視訊聯合模型的正確方式。它總是在生成配樂。你唯一的選擇，就是是否明確指定它。

彙整官方提示指南中的指引，以及經銷商文件與評論者回報的實際有效做法：

• 對話是最難要求的事。將台詞控制在每五秒鐘的片段一到兩句。過長的台詞會導致急促的唸白、音訊超出最後一個影格，或嘴型對不上——多位審查者一致回報這種情況。

• 在台詞前描述說話者及其表達方式。依官方指南，在首次出現時標明年齡、性別、音色和口音；使用簡單、直接的傳達註記（清晰、溫暖、平淡），而非詳盡的表演指示，據說後者會降低同步性。

• 將每個效果綁定到一個可見的事件。「就在軟木塞飛出的同時，響起『啵』的一聲」而不是「音效：『啵』」。這些詞語「同時」、「當」和「然後」才是實現同步的關鍵。

• 依音樂類型、節奏、情緒與配器簡短描述音樂 — 絕不要提及藝人或歌曲。 當畫面應成為主導時，加上「no vocals」，這是經證實能保持混音乾淨的方式。

• 以單一子句層疊氛圍。 雨打玻璃、低聲交談的呢喃、偶爾的杯碰聲、柔和的背景爵士樂——全部堆疊於單一句子之中，而非逐項條列。

• 請勿在音景部分重述對話。官方指南對此有明確禁令；各區段本應互不重疊，在此重複台詞等於使其出現兩次。

• 若某個詞必須在螢幕上清晰可讀，請用引號輸入該詞。審查人員回報指出，指定明確的字串能正常呈現，而模糊的要求（如「HUD elements」、「a sign」）則會產生字母狀的雜訊。

多位評測者一致認為，此音訊真正出色之處在於具體的實體聲音——與可見事物相關的擬音及音效——以及環境音。在抽象或氛圍性的要求上則表現較弱。多說話者的場景經常需要編輯才能讓說話者順序正確，而且發音品質因語言而異，因此在投入專案前，請先用一個可丟棄的片段測試你的目標語言。幾位評測者也指出了誠實的上限：這些聲音足以用於社群媒體發布，但一般而言還不足以在不替換的情況下作為廣播或付費廣告混音出貨。這些都不是廠商的指導，而是從業者的實際回報。

參考資料：讓每個檔案各司其職

H3的參考系統是其最強的差異化優勢，也是設定錯誤最常見的地方。根據平台API文檔記載的限制：最多9張圖片、3個影片片段和3個音訊片段，總計最多12個檔案，其中每個參考影片或音訊的長度需在2到15秒之間，且這些參考內容的總長度不得超過15秒。參考轉影片需要至少一張圖片或一個影片；僅有音訊不被接受。

官方參考指南與社群報告一致認可的技巧是為每個輸入加上標籤，並指派一項任務。按照檔案附加的確切順序，以標籤引用——<Picture 1>、<Video 1>、<Audio 1>——然後在提示詞中說明哪個參考驅動哪個屬性：身份、風格、動作、鏡頭或語音。官方範例提示詞正是這樣開頭，宣告圖一是整體氛圍與風格參考，圖二是主角。實務使用者回報，明確指派的效果遠比丟出九張圖片然後碰運氣要好得多。

{{1}}兩個會讓人們損失渲染成果的細節：{{/1}}

• <Picture 1> 不是情緒板，而是字面上的第一個影格，位於 0.000 秒，且屬於 [Shot 1]。在描述隨之而來的動作之前，先描述其中的內容（風格、主體、構圖、場景錨點）。把它視為一張你正在動畫化的靜止畫面，而不是一個提示。

• 這裡有兩個不同的檢查點，用錯的那個會靜默失敗。 fl2va負責文字轉影片及首幀/末幀處理；ref2va負責參考影像轉影片。這是 ComfyUI 最常被回報的錯誤：R2V 工作流在仍選用 FL2VA 模型的情況下執行。另外值得一提的是，ComfyUI 公告中有位留言者指出，隨附的 R2V 範本只顯示了兩個影像參考插槽，儘管模型接受九個——這是範本的限制，而非模型的限制。

在代管端方面，經銷商文件中還有兩則實務注意事項：ratio參數在 ref2va 端點上為必填，不能將其保留為「adaptive」；此外，重疊的工作會因為任務並行而回傳 429，而非排入佇列——因此請依序批次處理，或自行建立佇列。在本機端，ref_image_size預設為match，速度較快；max則會保留參考圖上最多 2048 像素的短邊，但會耗費時間。

本地運行實際花費多少掛鐘時間

下載完整的官方儲存庫需要 498 GB，而 ComfyUI 重新打包的鏡像則是 343 GB。你不需要完整下載兩者。ComfyUI 官方教學列出的四個檔案，用於文字轉影片與圖片轉影片，合計約 42.5 GB：

• 擴散模型 — minimax_h3_fl2va_pruned_int8_convrot.safetensors，20.97 GB，放入models/diffusion_models。

• 文本編碼器 — qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors，15.69 GB，放入 models/text_encoders。

• Video VAE — minimax_h3_video_vae_fp16.safetensors，5.21 GB，放入 models/vae。

• Audio VAE — minimax_h3_audio_vae_fp32.safetensors，0.61 GB，也放入models/vae。

• 新增參考轉影片 — minimax_h3_ref2va_pruned_int8_convrot.safetensors，另外 20.97 GB。

那個42.5 GB不是VRAM數字——是磁碟，而且各部分會串流傳輸並卸載。這個模型之所以能放進消費級顯示卡，是因為ComfyUI記載的一項工程技巧：大約40%的參數位於AdaLN調製分支，其輸出可以預先計算並替換為功能等效的查找表，使載入的模型從33.12B降到約20.11B，而依ComfyUI所述，品質沒有損失。全精度會是123.6 GB。如果你要微調或追求最後幾個百分點的保真度，也有未修剪的int8檢查點（每個34.04 GB）和bf16檢查點（每個66.28 GB）。

需要 ComfyUI 0.30.0 或更新版本，它內建三個範本：T2V、I2V 與 R2V。所有指南與維護者一致認同的首次執行基準刻意保持得很小：16:9、0.4 MP（864×480）、5 秒、20 步、使用 simple 排程器的 res_multistep 取樣器、denoise 1.0、batch 1。在調整解析度或長度之前，先輸出一支同時包含影片與立體聲的 MP4。有個算術特性值得留意：時長會對齊到 17k+5 的影格網格，所以 5 秒的請求會變成 124 個影格——在 24 fps 下約為 5.17 秒——而 10 秒的請求則落在 243 個影格，即 10.125 秒。5 到 15 秒範圍內的請求是比較安全的區間。

實際時間成本為何？根據社群回報（皆為單次執行、未受控制、且設定不同——上圖在每個長條旁標示對應設定）：一台配備 12 GB RTX 3060、32 GB 系統記憶體與高速 NVMe 的機器，使用動態卸載在九分鐘內完成了 864×480 / 124 幀 / 20 步的基線。一台配備 16 GB RTX 4090 並啟用 SageAttention 的筆電，以 960×540、5 秒、20 步的設定在 182 秒內完成。在單張 RTX 5090 上的 NVFP4 建置，以 10 步在 175 秒內產出 243 幀（10.1 秒）的 864×480 片段，VRAM 峰值為 26.9 GiB，磁碟上檔案僅 31.7 GB。SGLang 自家 cookbook 的參考——雙 RTX 5090、1344×768、124 幀、50 步並啟用分層卸載——耗時 559.67 秒。而 Apple Silicon 路徑透過非官方 MLX 移植，單一片段花了將近 45 分鐘。

從這些報告中提煉的實用筆記：

• 系統 RAM 與磁碟速度是承重元件，而非選配。在 12 GB 顯示卡上，所選檔案刻意超過 VRAM 容量，因此卸載路徑會先經由 RAM，再進入 SSD。兩份成功的低 VRAM 報告中皆出現 32 GB RAM。目前不存在經證實的 8 GB 結果。

• SageAttention 是唯一免費的加速方案 — 依 ComfyUI 所述，約可獲得 2 倍加速；若你的執行過程主要受卸載傳輸影響，效果會較低。安裝與你確切的 PyTorch 和 CUDA 版本匹配的 wheel，以及 ComfyUI-KJNodes，然後將 Patch Sage Attention KJ 插入於 UNET 載入器與 guider 之間，並設為自動。預期會出現某些 H3 層不是 FP16/BF16 的警告；此回退行為已有文件記載，屬正常現象。

• 步數可以商議。 5090 基準跑了 10 步，ComfyUI 基線跑了 20 步，而 SGLang 參考配置用了 50 步。沒人發表過品質-步數曲線，所以在假設你需要 50 步之前，先找出你自己的下限。

• 一次只更改一個變數以擺脫 OOM。記載的恢復方式是降回 0.4 MP、5 秒、批次 1，並在每次嘗試時只移動一個旋鈕。

• 音訊無聲表示音訊 VAE 未連接到影片輸出節點。這與音訊不良是不同的失敗，且容易被誤讀為模型拒絕生成聲音。

• Apple Silicon 並非官方支援。Willison 的做法是使用PipeNetwork/minimax-h3-mlx（一個社群移植版本），並透過uv搭配 MLX 需求檔案來執行。該公司自己的材料提到 SGLang、vLLM、Diffusers 和 ComfyUI，典型部署為四顆 GPU 的 BF16 配置，但完全沒有提及 Metal 或 MPS。應將 Mac 支援視為社群維護。

本地與託管，附上具體數字

由於 2K 模組和提示詞預處理器僅限託管，所以這並非真正的二選一。此架構驅使你走向的模式是：在本地以 768p 反覆迭代，每次嘗試只要耗費電力和三分鐘，然後再購買最終成品。按秒計費對你保留的那個鏡頭來說很划算，但對你丟棄的那四十個鏡頭而言則代價慘重。

關於價格，請務必小心，因為價格會因供應商不同而有約 2× 的差異；供應商自己的部落格文章並未引述任何美元數字——只提到 2K 的價格不到主流型號的三分之一，768p 則不到競爭對手 720p 價格的一半。目前已明確公布的資訊是：fal——目前列於 Hugging Face 儲存庫上唯一的推論提供者——其收費為在 768p 下每秒 $0.16，在 2K 下每秒 $0.26。第三方追蹤器回報該公司的官方定價明顯較低——約為在 768p 下每秒 $0.09–$0.10，在 2K 下每秒 $0.13–$0.14——而且這些數字彼此間連一分錢都不一致，因此請將這些數字視為參考，並在編列預算前查看平台的定價頁面。另外也要將以下情況納入預算：參考影片會按其自身時長計費，生成的輸出影片也會計費。

用實際數字算一遍。一百個可用的片段，每個八秒，就是800秒生成量：以每個0.14美元的2K費率大約112美元，以fal的0.26美元大約208美元，如果用最低清單價以768p交付則約76美元。每個可用片段對應四十個被拒的片段，這些才決定帳單，而那些被拒的片段應該在本地生成。這也是為什麼要讓你所比較的價格保持誠實——在OrcaRouter上，該管線的文字端是以零加成、按供應商清單價傳遞，所以當廠商降價時，當天就會生效，而不是等利潤重新計算之後。影片生成，再說一次，不是我們的；重點只是在於編譯步驟不應該成為你需要操心的一個項目。

在您基於此建置產品之前，請先閱讀授權條款。

這正是大多數「如何使用」指南跳過的部分，而且對許多讀者來說，這是唯一能改變決定的部分。我們直接閱讀儲存庫中的 LICENSE 檔案。這些權重依據H3 Community License Agreement發布，而非採用開源許可證，且其中包含的條款相當不尋常，值得實質引用：

• 地區。授權條款將其「適用領域」定義為全球，但不包括歐盟、英國、韓國與美國。按字面解讀，這排除了目前發布本地生成結果的很大一部分使用者——而且該限制的措辭旨在涵蓋輸出內容，而不僅是權重。

• 署名。商業使用需要在產品介面上顯示「H3」；授權條款亦鼓勵加上「Powered by H3」的標示。

• 收入門檻。 每年從以該技術為基礎的產品或服務中賺取超過2000萬美元的組織，必須獲得該公司的單獨書面授權。

• 禁止蒸餾。您不得使用H3或其輸出內容來改進任何其他AI模型，H3衍生模型除外。這排除了標準的合成資料做法。

• 適用法律。香港特別行政區，並由香港法院專屬管轄。

• 一個真正開放的組件。 Qwen3-VL-32B 文字編碼器採用 Apache 2.0 授權；上述限制僅適用於 H3 權重。

我們不是你的律師，這也不是法律建議——請閱讀授權條款及公司隨附的問答文件；如果你在被排除的地區進行商業開發，請尋求律師意見，而非聽信部落格的解讀。實際的分歧點是：託管 API 是另一種交易，且條款也不同於權重上的社群授權，因此如果當地授權不適合你，API 路線可能仍然可用。請查閱你所購買平台的條款。

第一週測試計畫

只要依此順序執行五次，就足以判斷 H3 是否適合加入你的管線：

• 運行 1 — 驗證管線是否暢通。T2V 模板，864×480，5 秒，20 步，res_multistep/simple。成功標準是內含立體聲音訊的 MP4，而非優質片段。

• Run 2 — 證明格式很重要。 同一主題兩次：一次寫成鬆散的一行描述，一次寫成 [Shot 1] 加上 overall_soundscape 加上 non_diegetic_music。如果第二個沒有明顯比 H3-Base 更好，那就是你的設定有問題。

• Run 3 — 一句對白。 一位說話者、一個句子、語氣說明、五秒鐘。這是最快判斷音訊是否適合你的用途，以及目標語言發音效果的方式。

• 第4輪——參考紀律。R2V搭配ref2va檢查點，兩三個參考，每個都明確標記並分配任務，並將<圖片1>描述為實際第一幀。然後故意打破它：附加相同的參考但不分配任務，然後比較。

• 第 5 次執行——完成。將你最佳的本地 768p 提示詞以 2K 解析度提交到託管 API，看看 Context-IR 和重新生成階段能增添什麼效果。這個差異正是每秒價格所買到的東西，也是唯一能誠實地為混合工作流程定價的方式。

常見問題

我可以從本地權重中取得 2K 嗎？

不是。開源套件是 H3-Base，其原生畫布為 768 像素短邊（最高 768×1344）。2K 來自 H3-Regenerate-2K，這是公司保留在託管 API 上的獨立情境內重生模組。你可以使用任何通用放大工具在本機進行放大，但這與 H3 自身的重生處理是不同操作，結果不會與其一致。

為什麼相同的提示詞在 API 和 ComfyUI 中的表現會不同？

因為 API 會先執行 H3-Context-IR。它會讀取你的文字與參考資料，推理兩者之間的關聯，然後將結構化、更豐富的指令交給 H3-Base。本地端則沒有這樣的階段——H3-Base 接收到的是你的原始文字。一個模糊的提示詞之所以能透過 API 產出合格的片段，是因為背後有你並未安裝的前處理器在救援；這正是文件記載的提示詞格式對本地端使用者的重要性遠高於 API 使用者的原因。

這個 [0s-2s] 時間碼模板是錯的嗎？

這不是隨附指南所要求的內容。該公司的VIDEO_PROMPT_WRITING_GUIDE_base_en.md以 [Shot N] 區塊組織，不為 Shot 1 加上時間戳，並將後續剪輯點表示為絕對時間（「在 00:03.500，鏡頭切換至……」）。它也完全沒有負面提示（negative-prompt）章節，因此熱門範本中的「banned transitions（禁用轉場）」清單是社群新增的內容。話雖如此，實務使用者回報以時間碼格式使用 API 獲得了良好結果——這很可能是因為 Context-IR 會將它正規化。我們的解讀是：在本機權重上使用文件記載的格式，不要把 API 結果的功勞歸給時間碼括號，因為那些結果可能其實是前處理器的功勞。

美國或歐盟的公司能否將開放權重（open weights）用於商業用途？

我們所閱讀的授權條款將歐盟、英國、南韓與美國排除在適用區域之外，且此排除條款明確涵蓋輸出內容與權重。對於在這些地區進行商業部署而言，這是一項重大障礙，而且這是法律問題而非技術問題——請自行閱讀授權條款與問答檔案並尋求建議。託管式 API 受平台自身條款管轄，而非社群授權，因此值得單獨評估，而不應假設其受到同等限制。

提交前要檢查什麼

H3 對特定類型的工作來說是異常划算的選擇：短片、經過聲音設計、參考基準一致的片段，而且你願意寫出真正的分鏡表。它對你「怎麼問」特別挑剔。有三件事值得你親自查證，因為這幾項的變動速度最快：fal 之外是否會出現更多推論提供者（那才是能讓每秒價格下降的關鍵）、ComfyUI R2V 模板的參考槽是否會從兩個擴展到該模型的九個，以及一旦有人拿本地權重做過對照比較，社群的時間碼習慣與文件記載的鏡頭區塊格式哪一方會勝出。目前還沒有人發表過那種比較。在那之前，儲存庫裡的手冊是比較可靠的選擇——而且它就放在你已經花了 42 GB 下載的那份檔案裡。