MiniMax

ComfyUI_MiniMaxH3_Director：一次過生成多段影片的導演台

2026 年 8 月 11 日

想做長片、多段生成又唔想逐段接節點，這個項目把 MiniMax H3 的分鏡、取樣和輸出收在同一個 ComfyUI 工作流核心。

做長影片時，最麻煩往往唔係單段生成，而係分鏡、續接、音畫輸出要分開處理。AIMixer/ComfyUI_MiniMaxH3_Director 針對的正是這個卡位：它屬於 ComfyUI 的影片生成節點插件，將 MiniMax H3 的多段規劃、條件編碼、採樣解碼和匯出合併成一個導演台，讓長視頻與多段音視頻生成流程集中管理。

它的價值不只在於把功能堆在一起，而是把幾種常見工作流放進同一個操作面。無論是 t2v、i2v、fl2v、r2v、v2v 還是 rv2v，都可沿用同一套時間軸邏輯；當中首尾幀、參考素材組、源片改寫和選擇性重跑都已經整理好，對需要反覆改段落、補鏡頭或保留原聲的創作者會實用得多。

安裝方式也算直接，前提是 ComfyUI 要升級到 v0.30.0 或以上，並已具備官方 MiniMax H3 支援。之後可用 ComfyUI Manager 透過 Git URL 安裝，或手動放進 custom_nodes，再按需要補上 scenedetect、opencv-python-headless、imageio-ffmpeg 這些依賴；模型權重與示例工作流則需另外下載。要留意的是，CLIP Loader 的 type 必須設為 minimax，而 fl2va / ref2va UNET 亦要按任務類型配對。

跟一般把多個節點逐個串起來的做法相比，這個項目明顯偏向把影片導演流程封裝成一個較完整的工作台，代價是你仍然要跟官方 MiniMax H3 節點規格保持一致，並理解不同模式背後用的是 MiniMaxH3ImageToVideo、MiniMaxH3ReferenceToVideo、MiniMaxH3SigmaShift、KSampler 與 AV 分離解碼鏈路。重點放在長片分段銜接、段間運動延續與原生立體聲輸出，較適合已經在 ComfyUI 內做影片生成、希望減少手動接線和重複操作的團隊。

把多段時間軸、生成、解碼、匯出收進單一節點
支援 t2v、i2v、fl2v、r2v、v2v、rv2v 多種模式
可做選擇性重跑，未勾選片段可用快取或原片填補
依賴官方 MiniMax H3 節點，環境版本與模型配對要設好
原生輸出立體聲音頻，適合長片與多段音視頻工作流

GitHub

Categories: 開源, ComfyUI, MiniMax

MiniMax H3 人像寫實 LoRA，強化近鏡表情與電影感

2026 年 8 月 11 日

基於 MiniMax H3 的人像寫實 LoRA，重點唔係加花巧風格，而係令面部、皮膚同鏡頭動態更自然可信。

近鏡人像、多人同框對話、手部動作呢類鏡頭，最容易暴露影片生成模型嘅細節破綻。呢個 Hugging Face 項目明確係基於 MiniMaxAI/MiniMax-H3 嘅 LoRA adapter，針對真人角色畫面再微調，重點放喺面部穩定度、皮膚質感、微表情同帶少少手持感嘅電影式運鏡，亦保留 MiniMax H3 原生同步音訊能力。

頁面提供嘅核心資訊相當集中：它屬於 text-to-video，授權採用 minimax-h3-community-license，主要檔案是 h3-realism-people-t2v.safetensors。使用方法唔複雜，要先喺 prompt 開頭加入 trigger word r34l1sm，再透過 fal 的 MiniMax H3 LoRA 端點掛載，範例 scale 係 1.0；想保留多啲 base model 原本味道，可以降到 0.6 至 0.8。

同類 LoRA 最大分別，往往唔係畫面變得幾誇張，而係同一個 prompt、同一個 seed 之下，能否穩定改善人物可信度。呢個項目用 before/after 方式展示 19 組對照，強調唯一變數係 adapter 本身，連 trigger word 兩邊都有加，目的係證明提升主要來自微調權重，而唔係提示詞技巧。頁面亦講明它係前作 MiniMax-H3-Realism-LoRA 嘅後繼版本，並且改用更大、更加聚焦人物題材嘅資料集重新訓練。

基礎模型：MiniMaxAI/MiniMax-H3，關係標記為 adapter
主要用途：強化寫實人物、近鏡面部、群眾、手部與紀錄片感鏡頭
主要檔案：h3-realism-people-t2v.safetensors
推薦控制：trigger word r34l1sm，LoRA scale 以 1.0 為預設，可降至 0.6-0.8

要留意，項目本質上係影片生成用嘅 LoRA，唔係可直接本地量化部署嘅通用文字模型。換句話講，它嘅價值更接近一個針對 MiniMax H3 補強人物鏡頭表現嘅專用適配器，而唔係完整獨立模型；使用場景亦明顯偏向 fal 平台上的 text-to-video 工作流。

模型

Categories: 開源, Video, Audio, AI productions, 視頻模型, MiniMax

MiniMax H3 Turbo：4 步加速的影音生成 LoRA

2026 年 8 月 11 日

MiniMax H3 的 ComfyUI 加速 LoRA，把 10 秒影片生成壓到固定 4 步。它適合要在速度、畫質和可控性之間取平衡的 T2V 與 I2V 工作流。

MiniMax H3 Turbo 走的是 ComfyUI 用途的加速路線，核心價值在於把 MiniMax H3 的文本生成影片（Text-to-Video, T2V）和圖像轉影片（Image-to-Video, I2V）流程固定到 4-step Euler 推理。它不是獨立模型，而是要配合 Comfy-Org/MiniMax-H3 的 BF16 base model 使用；頁面未提供更完整的 base model 參數規模或訓練細節，所以不能再往下猜。

這種設計的取捨很直接：步數少，生成時間通常更短，但對動作細節和穩定性的容錯也會更窄。頁面列出的比較都在同一個 BF16 base model、同一輸入與 10 秒、約 0.9MP 解析度條件下做，LoRA strength 固定 1.0；不同場景下，時間大概落在 174 到 190 秒之間，速度提升存在，但不是壓倒性。

重點摘要：
– 支援 T2V 與 I2V，I2V 走第一幀路徑，亦可用最後一幀收尾
– 固定 4-step Euler，重點是縮短推理流程而非擴大模型能力
– 需要配對 Comfy-Org/MiniMax-H3 的 BF16 base model
– 頁面未列出 GGUF、mmproj、上下文長度或量化檔案資訊
– 與 lightx2v LoRA 的比較屬同級加速方案，差距主要體現在時間與輸出取向

從檔案描述看，這個項目是 LoRA，不是完整 diffusion checkpoint，所以它的定位比較像「推理策略補丁」而不是全新模型。頁面也沒有提供 llama.cpp、Ollama 或 LM Studio 的支援資訊，顯示它主要面向 ComfyUI 工作流，而不是通用本地推理框架。

檔案命名上，頁面強調這是 v2 類型的更新版本脈絡；因此可確認的只有它圍繞 H3 的 joint audio-video diffusion path，並以固定 4 步作為加速契約。若要和原始 base model 比，差別不在功能範圍，而在於把生成速度和步數控制收緊，換取更快的工作流回饋。

模型

Categories: 開源, ComfyUI, Video, Image, Audio, 數字人, 視覺模型, 視頻模型, MiniMax

ComfyUI-Spectrum-MiniMax-H3：為 H3 加速 33%

2026 年 8 月 9 日

將 1056x608 影片生成由 685 秒縮短至 464 秒，避開昂貴的 transformer 重算。它屬近似加速，但影片細節可能走樣。

Repository image for xmarre/ComfyUI-Spectrum-MiniMax-H3

每次跑 MiniMax H3 都要付出完整 transformer 計算成本，對要反覆試 prompt、鏡頭動作同參考音訊的人來說，等待本身就是工作流瓶頸。xmarre/ComfyUI-Spectrum-MiniMax-H3 針對的正是這一步：它屬於 ComfyUI 自訂節點工具，會在部分 solver steps 直接預測 post-transformer hidden features，減少原生 MiniMax H3 audio-video model 的重計算次數。

實測生成 1056×608 影片由 685 秒縮短至 464 秒。加入這 Node 後可惜仍未能解決「廣東話」問題！

它不是把整個模型 shortcut 掉，而是用 Chebyshev ridge model 去擬合已經算出的 hidden features，再對未來步數作 spectral forecasting；但當前步的 output heads、video reconstruction、audio reconstruction、sigma mapping 同回傳結構仍然照常執行。這個取捨很務實，因為它換到的是抽樣成本下降，不是完全無損加速，所以 README 已經講明輸出不會與原生 MiniMax H3 bit-identical。

作者後來把預設路徑改成 offline_smoothing_replay，核心原因不是追求更高畫質，而是先救回音訊品質。早期單次流程會令語音清晰度、自然度同穩定性下降，甚至出現 doubled syllables 同 stuttering；現時預設把 audio_blend_weight 維持在 0，並以第二次無 transformer 的 replay 處理 video blend，目的就是切斷後段 video-to-audio feedback 對聲音的干擾。不過，畫面軌跡仍可能改變，動作、視線、時間點，甚至眼睛、手指、四肢細節都有機會走樣。

安裝十分簡單，適合願意做 exact-seed A/B 比對的創作者、工作流調校者，或者已經在 ComfyUI 內使用 MiniMax H3 的團隊。README 也提到舊版 workflow 可能要手動開啟 offline_smoothing_replay，而且 broader checkpoints、prompts、samplers 同 reference inputs 仍未完成足夠驗證，現階段更像是一個有方向、有明確修正策略，但仍需按素材類型逐步確認的加速方案。

以 spectral forecasting 預測部分 future solver steps，重點是減少 MiniMax H3 最昂貴的 transformer evaluations。
保留當前步的原生輸出頭與音畫重建流程，因此屬於近似加速，不是無損複製原生結果。
預設改用 offline_smoothing_replay，主要是修正早期版本對語音自然度與穩定性的破壞。
音訊路線暫時較保守，但視覺結果仍可能出現 motion、pose 與細節結構偏移。
較適合已在 ComfyUI 工作流內做反覆測試、願意接受 A/B 驗證成本的使用情境。

GitHub

Categories: 開源, ComfyUI, Video, Audio, 視頻模型, MiniMax

ComfyUI-MiniMaxH3-Easy：幫 H3 補回可用性

2026 年 8 月 7 日

把 MiniMax H3 放進 ComfyUI 後，最麻煩的接線、引用同提示編排，被整理成較順手的一套介面。

做影片生成時，最阻手往往唔係模型能力，而係節點圖愈接愈亂、參考素材愈加愈難管理。ComfyUI-MiniMaxH3-Easy 屬於 ComfyUI 自訂節點工具，集中處理 MiniMax H3 的 text-to-video、image-to-video 同 reference-to-video 工作流，將原本分散嘅媒體接線、參考標記同提示編輯收埋到同一個操作面。

呢個項目最實際嘅改動，在於保留 ComfyUI 彈性之餘，減少你每次都要手動整理素材順序。主節點用一個 Media 輸入口同時接收圖片、影片同音訊，仲會分開追蹤各自次序；一張圖會走 image-to-video，兩張圖就可用作 first/last-frame generation。做 reference-to-video 時，提示編輯器支援 @ 揀選已連接素材，執行時再自動轉成 MiniMax 建議嘅 <Picture N>、<Video N>、<Audio N> 格式，唔使自己逐個標籤維護。

將多種媒體收進單一 Media 入口，節點圖會乾淨得多
@ 參考編輯器有預覽，較適合需要反覆改 prompt 嘅影片生成流程
# 對話區塊可直接寫成可編輯 block，送出時自動轉成 <d>...</d>
可接 model-only LoRA、Sage Attention patch，亦可直接連到模型相關節點

同類做法通常要求使用者自己記住引用格式、接線順序同素材對應，ComfyUI-MiniMaxH3-Easy 選擇用較重介面包裝，換來較低出錯率同較高可讀性。代價亦明顯：它改善嘅係 MiniMax H3 在 ComfyUI 入面嘅操作層，不是另起一個新模型，也未見提供生成品質、速度或資源佔用測試數字，因此價值主要落在工作流整理，而唔係模型性能突破。

較受惠嘅會係已經用開 ComfyUI、但又嫌 MiniMax H3 節點圖太碎太亂嘅創作者、影片實驗團隊同需要反覆比對參考素材嘅人。部署方式亦唔複雜，理解上可以當成安裝到 ComfyUI 內嘅一組工作流節點：接好模型或 LoRA、把圖片或影片餵入 Media、再用內建編輯器整理引用同對話內容，就可以直接進入生成流程。

GitHub

Categories: 開源, ComfyUI, Video, Image, Audio, 視頻模型, MiniMax

MiniMax-H3 Turbo LoRA 移植 ComfyUI，4 步生成同步聲畫

2026 年 8 月 6 日

呢個版本唔係重新訓練主模型，而係把 MiniMax-H3 Turbo LoRA 轉成 ComfyUI 可直接載入的格式。重點在於 4-step 加速生成，同時保留聲畫同步能力。

想用更少步數生成影片同音訊，呢個頁面最值得留意的地方，是它明確基於 Comfy-Org/MiniMax-H3，而且屬於 adapter 形式的 LoRA，不是完整基礎模型。它針對 ComfyUI 使用的 pruned/curve-form MiniMax-H3 checkpoint 做兼容轉換，目的是讓原本由 larryvrh 發佈的 MiniMax-H3 Turbo LoRA — 4-step audio-video generation preview，可以透過 ComfyUI 內建的 MiniMax-H3 LoRA 載入流程使用。

技術上，核心價值在於把原始 Turbo LoRA 的 four-step distillation 和 dual video/audio sampling 帶入 ComfyUI 工作流。4-step 代表生成步數大幅壓縮，推理延遲有機會下降；頁面同時指出 non-EMA 權重較銳利、較能保持快速動作，EMA 權重則較平滑，但因為當時 EMA 未完全成熟，畫面會較柔。呢種取捨直接影響你想要的觀感：動態表現優先，可先看 non-EMA；畫面過渡想更順，EMA 版本更值得比較。

檔案方面，頁面列出 4 個 .safetensors LoRA 權重，包括初始兼容轉換版，以及兩個 further-trained checkpoint-500 變體：minimax_h3_turbo_4step_pruned_comfyui.safetensors、minimax_h3_turbo_4step_ema_pruned_comfyui.safetensors、minimax_h3_turbo_4step_ckpt500_pruned_comfyui.safetensors，以及對應的 EMA checkpoint-500 版本。

基礎模型已明示為 Comfy-Org/MiniMax-H3，屬於 LoRA adapter 兼容轉換
主要能力是 text-to-video，並帶有 text-to-audio、audio-video、synchronized-audio 標籤
重點方法來自原作者的 four-step distillation，目標是加速推理
頁面提供 ComfyUI workflow 範例下載，定位很明確：直接服務 ComfyUI 用戶

這個 Hugging Face 頁面是第三方整理的 ComfyUI 相容版本，價值在於把原始 MiniMax-H3 Turbo LoRA 接入 ComfyUI 生態，方便直接測試 4-step 聲畫同步生成與 checkpoint-500 變體之間的差異。

項目主頁

Categories: 開源, ComfyUI, Video, Audio, 視頻模型, MiniMax

MiniMax H3：全模態影音生成說明書

2026 年 8 月 6 日

MiniMax H3 把文字、圖片、影片與聲音整合到同一套生成流程，並支援同步影音輸出。

MiniMax H3 面向需要由多種媒體素材生成影片的場景，輸入可包括文字、圖片、影片及聲音，輸出則涵蓋影片與同步音訊。它屬於通用 omni-modal generative system，並非只處理 text-to-video，亦標示支援 image-to-video、video-to-video、audio-to-audio-video 等流程。提供的內容未載明它基於哪個 base model，亦無法確認是否由其他模型 fine-tuned from。

這種統一處理方式適合將參考圖片、動態片段或聲音一併納入生成條件，減少工作流程需要分拆成多個模型的情況。metadata 指向 Diffusers，並列出 multimodal、synchronized-audio-video 及 reference-to-audio-video 等能力；不過目前資料未交代模型架構、參數規模、上下文長度、訓練方法或效能指標。

可留意的使用重點包括：
– 支援 text-to-video、image-to-video、image-text-to-video 及 video-to-video。
– 可處理文字、圖片、影片與音訊，並生成 audio-video 組合內容。
– 提供 Global 與中國地區的 Online API，以及 Hailuo AI 網頁和桌面 App。
– 標示使用 MiniMax H3 Community License Agreement，部署前應查閱 LICENSE。

項目主頁

Categories: 開源, Video, Image, Audio, 3D, Ollama, 多模態模型, 視頻模型, MiniMax

LongHorizon-Harness 解決代理在長任務時的錯誤

2026 年 8 月 4 日

代理能否跑足幾十小時，關鍵唔只在模型能力，仲在狀態有冇走樣。LongHorizon-Harness把驗證、執行同任務延續拆開處理。

Install and run LongHorizon-Harness from the command line

當代理要橫跨桌面程式同 command line 連續做事，最易出問題唔係單步操作，而係中途記錯狀態、判斷錯進度，結果愈做愈偏。LongHorizon-Harness 針對屬於長時程代理執行與驗證工具，目標係令複雜任務可以被保存、核實，再一路推進到完成。

它唔係新模型，它主要協助 Claude Code、Codex、OpenClaw 之類 agent backend 上面處理 execution、state management 同 result verification。核心做法是 Manage-Execute-Audit (MEA) loop，把規劃、執行、審核拆成不同路徑，並把可信狀態獨立保存，減少單一長對話愈滾愈亂的問題。

支援 Claude Code、Codex、OpenClaw，亦可配 Gemini CLI 與 mini-SWE-agent
以獨立 audited state 推動下一步，而唔係只靠 session 內記憶
可用單一指令啟動，每次執行會獨立保留 audit trail
針對 WeaveBench、OSWorld 2.0、Terminal-Bench 2.1 這類長任務基準有公開成績

它在 WeaveBench 取得 80.7% PassRate、OSWorld 2.0 有 35.2% partial score，Terminal-Bench 2.1 success rate 為 77.2%。官方亦強調在相同 backbone 下，只換 harness，三個 benchmark 都向上走，反映改進點主要來自流程控制同驗證機制，而唔係模型突然變強。

呢種設計較適合需要長時間自動化處理、多步驟交接、又要追蹤結果可信度的團隊，例如研究、軟件測試、系統操作同複雜 office workflow。代價是流程比單純聊天式代理更重，審核與狀態管理會增加結構與成本，但換來的是更穩定的延續能力，同較容易追查每一步點樣做出來。

項目主頁 · GitHub

Categories: 開源, Qwen, Gemini, DeepSeek, OpenAI, Agentic, Anthropic, OpenClaw, MiniMax, Skill 技能, Dataset 數據集, 框架

MiniMax H3 萬眾期待的開放多模態模型

2026 年 8 月 3 日

文字、圖片、影片同音訊都可混合輸入，再直接生成帶原生立體聲的短片。MiniMax H3把理解與生成放進同一套多模態系統，重點在跨模態一致性。

一段提示未必只得文字，亦可以連同圖片、影片甚至音訊一齊交畀模型處理；MiniMax H3就是朝住呢種工作流而設。頁面未提供 based on、base model 或 fine-tuned from 資訊，所以無法確認它係唔係建基於其他基礎模型微調而成，但已清楚標示為 image-text-to-video，而且屬於可同時理解同生成多模態內容的 generative system。

它處理的重點不只是由文字生片，而係把 text、images、video、audio 放入同一個上下文，再輸出最長 15 秒、最短 4 秒、可到 2K 的影片，並且附帶 native stereo audio。呢種設計的價值，在於畫面、聲音同指令可以一齊對齊，適合做 image-to-video、video-to-video、text-to-audio-video 以至 reference-to-audio-video 等任務，減少要分開串接多個模型的工序。

H3 是 task-generalization-oriented system，意思是模型在 pre-training 階段已經針對廣泛任務泛化而設計，唔係只為單一路徑生成。它強調 unified understanding of multimodal contexts，同時支援多種輸入來源與輸出規格；比例覆蓋 21:9、16:9、4:3、1:1、3:4、9:16 等常見格式，短邊預設 768 像素，最高可到 2K，反映它偏向面向內容製作與跨媒體生成，而不只是研究展示。

支援 text-to-video、image-to-video、video-to-video，同時覆蓋 audio-video-generation
可生成 4 至 15 秒影片，並輸出 native stereo audio
輸入上下文可混合 text、images、video、audio，屬於 omni-modal 路線
Hugging Face 頁面標示 library_name: diffusers，代表可沿用 diffusers 生態整合

現階段較能確定的是，它把多模態理解與帶聲影片生成放入同一模型體系，對需要一致視聽輸出的項目有直接吸引力，但部署細節仍要等更完整技術文件補足。

項目主頁 · 模型

Categories: 開源, Video, Image, Audio, 3D, 多模態模型, 影像模型, 影像處理, 視頻模型, MiniMax

MiniMax H3 頂級高清影片生成

2026 年 7 月 31 日

MiniMax H3 提供咗一套較完整的影片生成 API。它重點不只是出片，仲包括參考生成同影片編輯控制。

做影片內容時，最麻煩往往不只是「生成一段片」，而係點樣令角色、鏡頭起承轉合同參考素材保持一致。MiniMax H3 屬於多模態影片模型，處理的正正係呢類控制力需求：除咗 Text-to-Video，亦支援以首幀、尾幀、參考圖片、參考影片同音訊去引導生成結果。

對內容團隊、短片創作者同需要自動化出片流程的開發者而言，呢個項目的吸引力在於輸入方式夠彈性。你可以由一段 prompt 起步，也可以加入第一張或最後一張畫面去約束開場與收尾；當需要保留人物、動作、鏡頭風格、聲線或剪接節奏，則可改用 Reference Generation。

MiniMax Just Dropped a "Seedance Killer" with a Twist

Watch this video on YouTube

支援 Text-to-Video、First/Last-Frame Image-to-Video、Reference Generation
統一理解 text、image、video、audio，多種素材可混合輸入
輸出最高為 2K，片長 4 至 15 秒，只接受整數秒
參考輸入上限包括最多 9 張圖片、3 段影片、3 段音訊，混合檔案總數上限 12

規格上，MiniMax H3 支援常見長闊比，圖片、影片與音訊都有清晰的格式及大小限制，例如影片可用 H.264/AVC、H.265/HEVC，圖片可用 JPG、PNG、WEBP，音訊則支援 WAV、MP3。音訊不能單獨提交，必須配合圖片或影片一齊使用；而較大的素材更建議用 URL 方式傳入，避免 API request body 超出 64 MB。

現有資料集中在能力範圍、輸入限制同 API 使用方向，能夠幫你快速判斷適唔適合接入工作流。

項目主頁

Categories: API, Video, MCP, Image, Audio, 多模態模型, 視頻模型, 語音, MiniMax

Page 1 of 2

1 2 Next »