MiniMax H3
MiniMax H3 is an audio-video generation family from MiniMax. Mold can discover, download, verify, repair, inventory, and remove two task partitions across the compact tags listed below, plus two official BF16 qualification references. The files are downloaded directly from their pinned Hugging Face repositories; Mold does not bundle or mirror the weights.
Prompting
The released checkpoints train on a structured Context-IR, not a single caption: ordered integrated_multimodal_description, overall_soundscape, and non_diegetic_music fields, [Shot n] cuts, and <d>[English] …</d> dialogue tags. A bare one-line prompt under-fills that wiring and renders worse than the model deserves. mold expand, mold remix, mold run --expand, and every app's Expand render the same guide into the expander. See MiniMax H3 prompting for the field syntax and MiniMax H3 Ref2VA for the reference-conditioned variant.
Scripted sequences
Use mold run --script shot.toml --host HOST for durable H3 sequences on an H3-enabled server; local chains remain refused. Each stage retains its own prompt, seed and conditioning. FL2VA smooth continuation conditions on the previous clip’s final RGB frame; cuts and fades start fresh. Ref2VA stages use ordered typed generation_references and join independent clips, including when the transition is named smooth. Generated audio is stitched with video.
TOML Ref2VA references use [[stage.generation_references]] with kind (image, video, or audio) and path relative to the script. The CLI probes and inlines at most 32 MiB across the complete chain.
TOML FL2VA stages can name first_frame_path and last_frame_path, resolved relative to the script. A smooth continuation supplies the first frame, so use a cut or fade when authoring a new first frame. See Video sequences for the complete script and lifecycle workflow. Inspect mold list --json --host HOST and /api/capabilities/chain-limits?model=MODEL for the selected tier’s limits.
Generated Examples
Every clip contains synchronized audio generated with the video. Press play to hear the model output.
minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p: 992x992, 124 frames, 24 fps, seed 83009. The prompt uses H3's timed <d>[English] ...</d> dialogue grammar: "With Mold, your ideas render right here." Those delimiters are real tokens in H3's vocabulary, and mold hands each to the model as a single token rather than as the punctuation the surrounding text would otherwise merge them into.
minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p: 992x992, 124 frames, 24 fps, seed 83004. First-frame conditioning preserves the balloon layout and the word “MOLD” while adding camera motion and a generated soundscape.
minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p: 992x992, 345 frames, 24 fps, seed 83031. A 14.38-second continuous foundry pour with generated industrial sound, score, and prompted offscreen narration: "With Mold, raw ideas become living images."
minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p: 992x992, 175 frames, 24 fps, seed 83033. The conditioned greenhouse blooms around moving butterflies and a hummingbird with synchronized water, wings, foliage, chimes, and score.
CUDA and Apple Metal are supported runtimes
The compact FL2VA and Ref2VA variants run on H3-enabled SM89 CUDA builds and the shipped Apple Silicon Metal build. Metal admission checks the request's exact phase budget against live unified-memory headroom; support is not a promise that every shape fits every Mac. CPU remains unavailable. Unsupported weight layouts and request shapes are refused normally rather than reported as licensing or authorization failures.
mold run --local accepts one FL2VA request and prepares a single-use owned attempt with the same request, device, memory, and output checks as the server. Local H3 batches and chains are refused before preparation; use the server for those requests and for Ref2VA reference uploads. These limits also apply when a remote command falls back to local execution. This does not change the request limits below.
Apple Metal is supported, memory-gated, and intentionally portable
The Apple Silicon route uses family-scoped BF16, a folded audio-VAE reduction, bounded chunked dense attention, portable INT8 ConvRot, and streamed Qwen and DiT blocks. Fp8-scaled weights remain refused by name because candle has no qualified Metal fp8 widening kernel.
The final attention lifetime pass releases fused QKV before attention, transposes keys directly into their consumed layout, converts only the active query slice, caps each score matrix at 768 MiB, and uses fused last-dimension softmax so command buffers retain the one probability matrix the phase budget prices. A guarded 256×256, 107-frame FL2VA Turbo 4-step render with first-frame conditioning and stereo audio completed on a 48 GiB M4 Max under the exact 8 GiB native ceiling, normal memory pressure, and zero swap growth.
The compact stack's ~42.5 GB download size is not simultaneous residency. Admission sums host and device memory within each phase and selects the peak; larger requests may be refused when live headroom is insufficient. Use mold system metal-memory status to inspect this machine. The kernel setting it reports is not a process cap or an OOM guarantee. See Metal memory and the qualification record. Metal remains much slower than CUDA; it is a supported portability path, not a throughput claim.
Compact variants
| Model | Task | Total pull | Runtime status |
|---|---|---|---|
minimax-h3-fl2va:comfy-pruned-int8 | First/last-frame conditioning with audio | 42.482 GB | CUDA/Metal generation; boundary frames |
minimax-h3-fl2va:comfy-pruned-int8-turbo-8step | FL2VA + reviewed Turbo 8-step LoRA (9 steps) | 44.438 GB | CUDA/Metal generation; boundary frames |
minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p | FL2VA + reviewed Turbo 4-step 768p LoRA (5 steps) | 44.438 GB | CUDA/Metal generation; boundary frames |
minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p-v1.1 | FL2VA + reviewed Turbo 4-step 768p v1.1 LoRA (5 steps) | 44.438 GB | CUDA/Metal generation; boundary frames |
minimax-h3-fl2va:comfy-pruned-int8-turbo-8step-768p | FL2VA + reviewed Turbo 8-step 768p LoRA (9 steps) | 44.438 GB | CUDA/Metal generation; boundary frames |
minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p-r21 | FL2VA + reviewed Turbo 4-step 768p LoRA, rank 21 (5 steps) | 42.780 GB | CUDA/Metal generation; boundary frames |
minimax-h3-fl2va:comfy-pruned-int8-turbo-8step-r21 | FL2VA + reviewed Turbo 8-step LoRA, rank 21 (9 steps) | 42.809 GB | CUDA/Metal generation; boundary frames |
minimax-h3-fl2va:comfy-pruned-int8-dmad-4step | FL2VA + reviewed DMAD 4-step distill LoRA, rank-reduced (5 steps) | 42.849 GB | CUDA generation; Metal unvalidated |
minimax-h3-fl2va:comfy-pruned-int8-pdmd-2step | FL2VA + reviewed PDMD 2-step distill LoRA, rank-reduced (3 steps) | 42.863 GB | CUDA generation; Metal unvalidated |
minimax-h3-fl2va:comfy-pruned-int8-pdmd-4step | FL2VA + reviewed PDMD 4-step distill LoRA, rank-reduced (5 steps) | 43.041 GB | CUDA generation; Metal unvalidated |
minimax-h3-fl2va:fasth3-v2-int8 | FL2VA on FastVideo's FastH3 V2 distilled DiT (9 steps) | 43.640 GB | CUDA generation; Metal unvalidated |
minimax-h3-ref2va:comfy-pruned-int8-turbo-4step | Ref2VA + reviewed Turbo 4-step LoRA (5 steps) | 44.438 GB | CUDA/Metal generation; reference profile |
minimax-h3-ref2va:comfy-pruned-int8-turbo-4step-r21 | Ref2VA + reviewed Turbo 4-step LoRA, rank 21 (5 steps) | 42.809 GB | CUDA/Metal generation; reference profile |
minimax-h3-ref2va:comfy-pruned-int8 | Reference media to video with audio | 42.482 GB | CUDA/Metal generation; ordered references |
minimax-h3-fl2va:comfy-pruned-nvfp4 | First/last-frame conditioning with audio | 34.040 GB | Downloadable; execution unavailable |
minimax-h3-ref2va:comfy-pruned-nvfp4 | Reference media to video with audio | 34.040 GB | Downloadable; execution unavailable |
The official minimax-h3-fl2va:official-bf16 and minimax-h3-ref2va:official-bf16 identities are also visible downloads. They are large qualification references with no public execution arm, so their model rows report runtime_available: false before the pull.
The two NVFP4 rows pin a pruned NVFP4 transformer in place of the INT8 one. Mold has no engine arm that reads that weight layout yet, so they download, verify, appear in Models → Installed, and remove like any other model, while generation is refused up front (before any weights are loaded) and GET /api/models reports "runtime_available": false on the row. They share the whole rest of the compact stack with the INT8 variants, so if you already have one installed the pull is only the 12.529 GB transformer.
Which models this build can run
The H3 catalog rows ship on every release target; the H3 engine does not. The macOS and Linux sm89 artifacts are built with it; on an RTX 3090/A40 (sm86), a B200/B300 (sm100), an RTX 50-series card (sm120), or Windows, the H3 models download and verify normally and generate nothing. Both compact task partitions (FL2VA and Ref2VA) run wherever the engine is built.
Rather than let you discover that after a 21–42 GB pull, every H3 row carries its answer. GET /api/models reports:
runtime_available:falsewhen this server cannot execute the model, whatever the cause. Absent on servers that predate the field, which clients read as runnable.runtime_unavailable_reason: one sentence naming the obstacle, present exactly whenruntime_availableisfalse. There are three, and they have three different remedies:- no engine arm for this weight layout: the
official-bf16qualification references and the pruned NVFP4 tags. No build runs these. - no runtime for this task partition: the task, not the machine. A different artifact will not help. No released identity reports this today: both compact partitions execute, and the axis survives for a future task.
- this build was compiled without the H3 engine: use the macOS or Linux sm89 release, or build with the
h3feature.
- no engine arm for this weight layout: the
Mold Studio renders that on the model card before the pull: web, desktop, and the iPhone app show a Download only badge on the Discover row and the full sentence in the detail pane, with the Pull action still enabled; the model genuinely is downloadable. mold pull prints the same sentence in place of the mold run hint, and mold run --local refuses before opening a single checkpoint.
Submitting one anyway returns HTTP 501 with code MINIMAX_H3_RUNTIME_UNAVAILABLE and that same sentence; deliberately not the 451 licensing refusal, because none of these is a licensing problem.
Every H3 render carries synchronized generated audio, and no request can turn it off. GET /api/models says so directly: each H3 entry reports "supports_audio": true (including variants that are not downloaded yet) so a client reads the capability rather than inferring it from the family name.
Pull a variant from the CLI, or install it from Models → Discover in Mold Studio:
mold pull minimax-h3-fl2va:comfy-pruned-int8
mold pull minimax-h3-fl2va:comfy-pruned-nvfp4
mold pull minimax-h3-fl2va:comfy-pruned-int8-turbo-8step
mold pull minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p-v1.1
mold pull minimax-h3-fl2va:comfy-pruned-int8-turbo-8step-768p
mold pull minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p-r21
mold pull minimax-h3-fl2va:comfy-pruned-int8-turbo-8step-r21
mold pull minimax-h3-fl2va:comfy-pruned-int8-dmad-4step
mold pull minimax-h3-fl2va:comfy-pruned-int8-pdmd-2step
mold pull minimax-h3-fl2va:comfy-pruned-int8-pdmd-4step
mold pull minimax-h3-ref2va:comfy-pruned-int8
mold pull minimax-h3-ref2va:comfy-pruned-int8-turbo-4step-r21
mold pull minimax-h3-fl2va:fasth3-v2-int8The files are revision-pinned and SHA-256 verified before Mold marks the model complete. Raw repository IDs, custom manifests, configured aliases, and live catalog recipes cannot substitute for any registered graph.
Reviewed Turbo tiers
A Turbo tier is a reviewed LoRA adapter overlaid on the same compact INT8 checkpoint of its own task; nothing about the base artifact contract relaxes, and the only request axis a tier moves is its fixed step count. Each Turbo model tag pulls the complete base stack of its task plus one pinned adapter (1,956,193,000 bytes for FL2VA 8-step, Ref2VA 4-step, and FL2VA 8-step 768p, 1,956,192,992 bytes for FL2VA 4-step 768p and its v1.1 successor, and — for the three lossy SVD-resized rank-21 tiers below — 298,177,224 bytes, 327,035,608 bytes, and 326,935,264 bytes respectively, stored once under shared/minimax-h3/loras/ and shared by every tag that names one):
minimax-h3-fl2va:comfy-pruned-int8-turbo-8step: 9 terminal-inclusive sampler grid points (8 model evaluations)minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p: 5 terminal-inclusive sampler grid points (4 model evaluations)minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p-v1.1: 5 terminal-inclusive sampler grid points (4 model evaluations)minimax-h3-fl2va:comfy-pruned-int8-turbo-8step-768p: 9 terminal-inclusive sampler grid points (8 model evaluations)minimax-h3-fl2va:comfy-pruned-int8-turbo-4step-768p-r21: 5 terminal-inclusive sampler grid points (4 model evaluations) — a lossy low-rank approximation of the reviewed adapter; about 1.66 GB less to download, and measured 1.60-1.70 GB less resident VRAM on an L40S (2026-09-02), matching the about 1.66 GB (4-step 768p) derived from the adapter payload; 94.95% average Frobenius retention against the full-rank-turbo-4step-768padapter it was resized fromminimax-h3-fl2va:comfy-pruned-int8-turbo-8step-r21: 9 terminal-inclusive sampler grid points (8 model evaluations) — a lossy low-rank approximation of the reviewed adapter; about 1.63 GB less to download, and measured 1.60-1.70 GB less resident VRAM on an L40S (2026-09-02), matching the about 1.63 GB (8-step) derived from the adapter payload; 97.72% average Frobenius retention against the full-rank-turbo-8stepadapter it was resized fromminimax-h3-ref2va:comfy-pruned-int8-turbo-4step: 5 terminal-inclusive sampler grid points (4 model evaluations)minimax-h3-ref2va:comfy-pruned-int8-turbo-4step-r21: 5 terminal-inclusive sampler grid points (4 model evaluations) — a lossy low-rank approximation of the reviewed adapter; about 1.63 GB less to download, and measured 1.60-1.70 GB less resident VRAM on an L40S (2026-09-02), matching the about 1.63 GB (Ref2VA) derived from the adapter payload; 98.33% average Frobenius retention against the full-rank-turbo-4stepadapter it was resized from
An adapter is reviewed for exactly one task partition, so a ref2v adapter can never mint an FL2VA qualification and vice versa. Each -r21 tier carries pinned-identity evidence (size, SHA-256, and the full-rank adapter it was resized from) plus a measured A/B against that full-rank tier, run 2026-09-02 on an L40S: 1528-1622 MiB (1.60-1.70 GB) less VRAM measured at both 768x768 and 1344x768, with mean PSNR 21-29 dB on the FL2VA pairs (-4step-768p-r21, -8step-r21) and 16-17 dB on the two panning Ref2VA pairs (-4step-r21) against the full-rank source. All three tiers shipped on the maintainer's 2026-09-02 call (PR #1555) on visual parity and the measured VRAM saving, with the measured PSNR band recorded, along with the full measured evidence, in docs/qualification/minimax-h3.md, "The rank-21 Turbo tiers campaign (2026-09-02)".
Reviewed DMAD and PDMD distill tiers
Three further FL2VA tags overlay a DMAD or PDMD distillation LoRA on the same compact INT8 checkpoint, exactly as a Turbo tag does. Unlike the Turbo tiers, each distillation was published with its own sampler and audio shift, and mold runs the published recipe for each tag rather than the Turbo one:
| Tag | Steps (grid points) | Sampler | Video / audio shift | Upstream recipe |
|---|---|---|---|---|
minimax-h3-fl2va:comfy-pruned-int8-dmad-4step | 4 (5) | Comfy lcm on the simple grid (re-noise to each step's sigma) | 12 / 2 | ZhengmingYu/DMAD README: lcm + simple, shift 12/2, CFG 1 |
minimax-h3-fl2va:comfy-pruned-int8-pdmd-2step | 2 (3) | Euler on the simple grid | 12 / 6 | pdmd2026/pdmd_2NFE_lora README: Euler on shift(linspace(1, 0, nfe + 1)), audio shift 6 |
minimax-h3-fl2va:comfy-pruned-int8-pdmd-4step | 4 (5) | Euler on the simple grid | 12 / 3 | pdmd2026/pdmd_4NFE_lora README: same Euler schedule, shift 12/3 |
The lcm update predicts the clean latent at each step and re-noises it to the next step's sigma with fresh noise, separately for the video and audio streams at their own sigma. That noise is drawn deterministically from the request seed, so a DMAD render is reproducible from its seed like every other tier. PDMD's own reference sampler is plain Euler over the shifted linspace, which is exactly Comfy's simple grid with the Euler update.
The adapters are Kijai's rank-reduced builds of the upstream full-rank distillation LoRAs (average rank 39, 38, and 57 respectively), each with one alpha per module equal to that module's rank, so the effective scale is 1.0. Like the -r21 Turbo tiers they are a lossy low-rank approximation of the published distillation; the full-rank upstream files are not registered. The upstream DMAD and PDMD releases were distilled for text-only audio+video generation (T2VA); they run on the FL2VA compact stack like any other FL2VA tag, with the same boundary-frame and memory rules.
A Turbo tag stores its base stack in its own task's base checkpoint directory (minimax-h3-fl2va-comfy-pruned-int8/ or minimax-h3-ref2va-comfy-pruned-int8/, plus the shared family bucket), so a machine that already has that base tag installed downloads only the ~1.96 GB adapter, and pulling a Turbo tag first means a later base pull downloads nothing. Because the shared bytes genuinely constitute a complete base install, a Turbo-only pull also makes the base tag read as installed. Removal ref-counts every complete install: removing a Turbo tag deletes only its adapter while the base stack has another owner, and removing the base keeps every file a fully installed Turbo tag still uses (a Turbo tag missing its adapter owns nothing). Freeing everything is two removals (the Turbo tag, then the base) and each removal reports the kept files with the tags that still use them.
Selecting a Turbo model resolves the base INT8 transformer, the tier's pinned adapter, and the tier's reviewed step count with no extra configuration. The Create screen locks Steps at that count and prints the reason underneath it ("Fixed by the 8-step distilled tier: 9 terminal-inclusive sampler grid points (8 denoise intervals)."), so the 9 is not a surprise; Guidance is locked the same way, because H3 has no classifier-free branch and pins the scale at 0. Both sentences come from the server's generation profile, so the web, desktop, and iPhone apps show the same words. The MOLD_H3_TURBO_ADAPTER / MOLD_H3_TURBO_TIER environment pair is a capture-scope UAT override honored only by h3-private-uat builds; ordinary builds refuse a set pair rather than letting two selection authorities disagree.
FastH3 V2 distilled base tier
minimax-h3-fl2va:fasth3-v2-int8 (FastH3 V2 8-step (FastVideo)) is a distilled base tier, not a LoRA. FastVideo's FastH3 V2 is a full-weight DMD distillation of MiniMax H3, pruned from the text-to-audio-video partition into the same curve-AdaLN INT8 ConvRot layout as Comfy-Org's FL2VA transformer. The tag is the complete FL2VA compact stack with ONE substitution: the transformer file. The Qwen3-VL conditioner, both VAEs, the tokenizer, and every config are byte-identical to the base stack and share its on-disk copy.
It runs FastVideo's own operating point for this checkpoint, from the FastVideo-FastH3-8-Step-V2-NVFP4-Comfy README ("keep the template's sampler settings"), with no configuration:
- 8 steps of
res_multistepon thesimpleschedule: exactly 9 terminal-inclusive sampler grid points (8 denoise intervals). The Steps control is fixed and explains itself ("Fixed by the 8-step distilled tier: 9 terminal-inclusive sampler grid points (8 denoise intervals)."). MiniMaxH3SigmaShift10 for video and 3 for audio (the base tier uses 12/3)- cfg 1 upstream, which is Mold's guidance 0 (H3 has no classifier-free branch)
Text-only (T2VA, no frame attached) is FastH3's trained operating point, and first-frame, last-frame, and first+last-frame requests use the same FL2VA boundary-frame contract as every other FL2VA tag:
mold run minimax-h3-fl2va:fasth3-v2-int8 \
"a fishing boat crosses a stormy harbor at dawn, gulls calling" --seed 7The transformer is pinned at FastVideo/FastVideo-FastH3-Comfy revision ec1e3aa374a91c57b0b94a1623b7e657c0498cf2, diffusion_models/fastvideo_fasth3_8step_v2_pruned_int8_convrot.safetensors, 22,128,378,696 bytes, SHA-256 0922785978dc9bfe1adf27d8b291b0ca763f9f165f882e6cb297c72fbb6deda8, plus its exact header and tensor inventory. It is stored under the tag's own model directory, never over the Comfy-Org transformer, so a machine that already has any compact FL2VA tag installed downloads only those 22.128 GB. The MiniMax H3 Community License governs these weights like every other H3 artifact. An installed FastH3 model advertises its own runtime recipe, including optional boundary frames, fixed nine sampler grid points, and zero guidance. Its installation check uses its substituted transformer and the shared components; it does not require the ordinary FL2VA transformer as well.
The file carries two things Comfy-Org's does not. Its 50 video-sparse-attention gates (to_gate_compress, 1.928 GB) are authenticated with the rest of the file and never loaded, because Mold runs dense attention and ComfyUI's dense forward does not read them either. Its token refiner is INT8 ConvRot rather than BF16 (0.771 GB instead of 1.541 GB). So although the file is 1.158 GB larger, the weights Mold loads are about 0.77 GB smaller than the base transformer's, and there is no resident adapter as on a Turbo tag. Device memory is admitted with the same per-request estimate as every other compact FL2VA tag. On one L40S at 1344x768x124 text-only it denoised in about 395 s (8 evaluations) and the server process peaked at 31.1 GB of device memory (1 Hz nvidia-smi), against 21.3 GB for the DMAD 4-step tier on the same prompt; the qualification record holds the full campaign.
Veda sparse attention remains deferred: it needs a separate Rust predictor and attention implementation plus numerical and performance qualification. The FastH3 tag above does not enable that acceleration. PDD Acc is separate work tracked in #1540; the remaining packs and acceleration work are tracked in #1812.
Download size and sources
Each compact variant has the same component graph except for its task-specific transformer:
| Component | Bytes | Decimal size | Upstream source |
|---|---|---|---|
| Task transformer (INT8 ConvRot) | 20,970,379,616 | 20.970 GB | Comfy-Org/MiniMax-H3 |
| Task transformer (pruned NVFP4) | 12,528,636,865 | 12.529 GB | Abiray/Minimax-H3-nvfp4-INT4-INT8-Convrot |
| Task transformer (FastH3 V2 distilled INT8 ConvRot) | 22,128,378,696 | 22.128 GB | FastVideo/FastVideo-FastH3-Comfy |
| Qwen3-VL NVFP4-AWQ text encoder | 15,687,142,551 | 15.687 GB | Comfy-Org/MiniMax-H3 |
| FP16 video VAE | 5,207,808,496 | 5.208 GB | Comfy-Org/MiniMax-H3 |
| FP32 audio VAE | 605,254,808 | 0.605 GB | Comfy-Org/MiniMax-H3 |
| Tokenizer, processor, scheduler, and component configs | 11,504,847 | 0.012 GB | MiniMaxAI/MiniMax-H3 |
| One complete INT8 variant | 42,482,090,318 | 42.482 GB | Both pinned repositories |
| One complete NVFP4 variant | 34,040,347,567 | 34.040 GB | All three pinned repositories |
| One complete FastH3 V2 variant | 43,640,089,398 | 43.640 GB | FastVideo plus both pinned repositories |
A Turbo tag adds one adapter to this graph: Comfy-Org/MiniMax-H3loras/ at pinned revision dc559027db79c174125df4d827db55cd11178860 (1,956,193,000 bytes for -turbo-8step, 1,956,192,992 bytes for -turbo-4step-768p), bringing one complete Turbo variant to 44,438,283,318 or 44,438,283,310 bytes (44.438 GB).
The -turbo-4step-768p-v1.1 and -turbo-8step-768p tags pull their adapter from a second third-party source instead: lightx2v/Minimax-h3-Turbo at the repository ROOT (no loras/ directory) at pinned revision 05ef678438e84933c406131b59abbf86919b3aac — minimax_h3_fl2v_turbo_4step_v1.1_768p_comfyui_bf16.safetensors (1,956,192,992 bytes) and minimax_h3_fl2v_turbo_8step_v1.0_768p_comfyui_bf16.safetensors (1,956,193,000 bytes), bringing those Turbo variants to 44,438,283,310 and 44,438,283,318 bytes (44.438 GB) respectively. lightx2v declares apache-2.0 for the adapters themselves; the MiniMax H3 Community License still governs the base checkpoint each tag executes on. Every adapter, whichever source it comes from, lands at the same shared/minimax-h3/loras/ path keyed by its own basename.
The -turbo-4step-768p-r21, -turbo-8step-r21, and Ref2VA -turbo-4step-r21 tags pull a third, smaller adapter from a THIRD third-party source: drbaph/MiniMax-H3-Turbo-Lora-ComfyUI at the repository ROOT at pinned revision be8eb3ea3466cbb7def202ffec0d2fdc054256ac — minimax_h3_fl2v_turbo_4step_v1.0_768p_comfyui_resized_avg_rank_21_bf16.safetensors (298,177,224 bytes), minimax_h3_fl2v_turbo_8step_v1.0_comfyui_resized_avg_rank_21_bf16.safetensors (327,035,608 bytes), and minimax_h3_ref2v_turbo_4step_v0.1_comfyui_resized_avg_rank_21_bf16.safetensors (326,935,264 bytes), bringing those three Turbo variants to 42,780,267,542, 42,809,125,926, and 42,809,025,582 bytes (42.780 GB, 42.809 GB, and 42.809 GB) respectively — 1,658,015,768 bytes less to download for the 4-step 768p tier and 1,629,157,392 / 1,629,257,736 bytes less for the other two (about 1.66 GB and about 1.63 GB). Each is a lossy, per-module dynamic-rank SVD resize of one of the full-rank adapters above, published with a numeric baked_scale folded into the weights rather than an alpha/rank pair. drbaph declares apache-2.0 for these resized derivatives specifically; the MiniMax H3 Community License still governs the base checkpoint and the full-rank adapter each was resized from. Every adapter, whichever of the three sources it comes from, lands at the same shared/minimax-h3/loras/ path keyed by its own basename.
The -dmad-4step, -pdmd-2step, and -pdmd-4step tags pull their adapter from a FOURTH third-party source: Kijai/MiniMax-H3-experimental under loras/ at pinned revision d8023be02fefbb3633b0cd335c3879f91177299d — minimax_h3_DMAD_4step_full_lora_avg_rank_39_bf16.safetensors (366,647,000 bytes), minimax_h3_pdmd_2step_lora_avg_rank_38_bf16.safetensors (381,015,376 bytes), and minimax_h3_pdmd_4step_lora_avg_rank_57_bf16.safetensors (558,735,392 bytes), bringing those three variants to 42,848,737,318, 42,863,105,694, and 43,040,825,710 bytes (42.849 GB, 42.863 GB, and 43.041 GB) respectively. Each is a rank-reduced build of an upstream full-rank distillation LoRA (DMAD from ZhengmingYu/DMAD, PDMD from pdmd2026/pdmd_2NFE_lora and pdmd2026/pdmd_4NFE_lora) with a per-module rank and a per-module alpha equal to that rank; mold pins each file by size, SHA-256, and header identity. The MiniMax H3 Community License still governs the base checkpoint each tag executes on, and the same shared/minimax-h3/loras/ storage rule applies.
The encoder, VAEs, and common support files are shared between every compact variant, INT8 and NVFP4 alike. After one complete variant is installed, adding another downloads only its transformer (20.970 GB for an INT8 tag, 12.529 GB for an NVFP4 one) plus a 546-byte task config when the task differs. Removing one variant keeps the shared graph and names the variants still using it. Both variants together occupy 63.452 GB (63,452,470,480 bytes) of model payloads, excluding filesystem and Hugging Face cache overhead.
Sizes above are decimal gigabytes (1 GB = 1,000,000,000 bytes) and describe downloads and disk use, not peak VRAM. They come from Mold's registered, full-file manifest identities rather than estimates from repository listings.
Supported FL2VA request
The current compact implementation supports this request profile:
an SM89 CUDA or Apple Silicon Metal GPU with the H3 attention/runtime operators enabled; the exact request must pass live device and host-memory admission
any canvas the compact rule admits (both axes a multiple of 32, each at least 256 px, at most 1,032,192 pixels in total (the area of
1344x768), aspect between 1:4 and 4:1) batch size 1107 to 345 frames on the
17n+5grid at 24 fps (124 is the default)21 to 50 terminal-inclusive sampler grid points for the base model (21 is the default and the floor: below it the print flashes once per latent frame); a reviewed Turbo tag instead requires exactly its tier's own count (9 for
-turbo-8step,-turbo-8step-768p, and-turbo-8step-r21, 5 for-turbo-4step-768p,-turbo-4step-768p-v1.1,-turbo-4step-768p-r21,-dmad-4step, and-pdmd-4step, 3 for-pdmd-2step), because that count is the distilled adapter's own schedule length; the FastH3 V2 distilled base tier (fasth3-v2-int8) likewise requires exactly 9, its own distilled schedulezero, one, or two boundary images on every FL2VA tag, base and Turbo: text-only (T2VA — no frame, the prompt builds the whole clip), first frame, last frame, or both. Endpoint order is first then last, and each image contributes its own conditioning and memory charge; a text-only request charges no vision or condition rows. Ref2VA still requires at least one reference. This is a complete text-only command:
bashmold run minimax-h3-fl2va:comfy-pruned-int8-turbo-8step "a lighthouse keeper climbs the spiral stairs at dusk, wind howling" --seed 7web, desktop, mobile, and native apps follow the selected machine’s recipe for whether a start frame is optional or required. A saved draft from an older machine cannot override a newer recipe’s text-only support.
queued jobs retain exact first/last endpoint roles through durable storage and server restart; the same queue behavior applies to FL2VA Turbo tiers
MP4 output with synchronized generated audio
a prompt of roughly 1,000 tokens or fewer when a frame is attached: the reviewed conditioner sequence keeps the first-only 2,048-row budget and adds 1,040 rows for a second endpoint (1,008 vision pads plus label/delimiter allowance). Both frames therefore retain roughly 1,000 prompt tokens, and a text-only request, which carries no vision pads, gets the whole 2,048-row budget. The exact remaining budget is derived from the tokenized presentation; a longer prompt is refused before artifact verification. Two endpoints also increase the Qwen and denoise memory grants, so they still must pass live device and host admission
the prompt is optional once the request carries conditioning — a first or last frame here, a reference set for Ref2VA. What you attached already decides the shot, so a prompt refines it; expect near-static micro-motion when you leave it out, and with nothing attached the prompt is the whole render and stays required. The same rule covers LTX-2 and Wan. This is a complete command:
bashmold run minimax-h3-fl2va:comfy-pruned-int8 --first-frame presenter.png
A repeated prompt against the same first-frame (or, for Ref2VA, the same reference set and frame count) on the same conditioner route and device reuses the prior render's Qwen conditioning output instead of recomputing it. The reuse rule is keyed on the prompt, the endpoint or reference bytes (crop included), the Ref2VA frame count, the conditioner route and device, and the checkpoint/support artifact pins; any other change — or a different host, GPU, or artifact revision — is a miss, not a stale hit. For FL2VA, changing only the clip length (--frames) or the step count still hits: neither reaches the conditioner, whose input is the prompt and the endpoint pixels. The cache is process-local and is never persisted to disk, so it does not survive a server restart. A hit removes the conditioner load and the encode entirely. The load is the shape-independent half — 53.6 s in the measured CUDA row. The encode scales with how many patches were conditioned: that same row's single 2048-square Ref2VA reference (16,384 vision patches) encoded in 24.6 s on the CUDA route and 2,405.6 s on the host fallback route used when the conditioner cannot fit on the device, while a smaller conditioning set — an FL2VA endpoint is 4,032 patches — encodes proportionally faster. Measured directly on the FL2VA route, a repeated 4-step 768x768 render's hit saved about 30 s off a 199 s server-reported generation time. The output is bit-identical to a fresh encode, and mold run discloses the hit as prompt conditioning [cache hit].
mold run minimax-h3-fl2va:comfy-pruned-int8 \
"the camera drifts toward the illuminated pavilion" \
--first-frame pavilion.png --duration 5One H3 generation renders up to 14.4 seconds (345 frames), so --duration 14 --host HOST is a single clip. For a longer video, write one [[scene]] of at most 14 seconds per part in a scenes file and run --scenes scenes.toml --host HOST; each scene prompt (in the three-field grammar) describes only its own seconds. Mold opens every scene that continues from the previous clip's last frame with H3's upstream frame-alignment line, so do not write it yourself. A single prompt longer than one generation repeats its action in every clip, and the plan warns about it. Duration creates one durable parent on an updated H3 server and saves one MP4 with synchronized audio. Add --dry-run first for full read-only validation, the scene timeline, the planned clip count and the delivered length. The final movie trims grid padding on H3's 24 FPS clock. FL2VA carries motion between clips and accepts text-only prompts when no endpoints are attached. First and last frames belong to the outer boundaries of the whole movie. Ref2VA also supports Duration, using independent blended clips and retained ordered references rather than claiming motion continuity. Forced-local Duration remains one bounded H3 render. For explicit frame-level scripts, inspect the paired host's authored-chain bounds with mold chain limits MODEL --json --host HOST. Discover installed recipes with mold list --json --host HOST; raw HTTP cannot access a paired Secure host.
Canvas and duration
The checkpoint accepts any 32-aligned canvas between 1:4 and 4:1, and clip lengths from 107 to 345 frames. Mold admits that whole space and lets the memory estimate decide what actually fits, rather than pinning the shapes a hardware campaign happened to run.
The canvas rule is:
- both axes a multiple of 32 (one packed row is a 32x32 pixel cell)
- each axis at least 256 px
- at most 1,032,192 pixels in total; the area of
1344x768, which is what every memory measurement below was captured at, so a larger canvas would have to be priced by extrapolation - aspect between 1:4 and 4:1
1344x768 and 768x768 remain the recommended defaults because they have real hardware evidence. Measured on an RTX 4090 24 GB at 124 frames / 24 fps, wall clock from request to MP4 bytes on a cold process:
| Canvas | Aspect | Base tier (21 steps) | -turbo-8step (9 steps) |
|---|---|---|---|
1344x768 | 7:4 | 1216 s, 10.8 GB VRAM | 759.5 s, 13.5-14.6 GB |
768x768 | 1:1 | 937 s, 7.4 GB VRAM | 664 s, 9.2 GB VRAM |
The two 768p-native Turbo tiers added after that campaign, -turbo-4step-768p-v1.1 and -turbo-8step-768p, were measured separately on a workstation (NVIDIA L40S 46 GB, not the hal9000 RTX 4090 above) during the lightx2v Turbo tier UAT campaign (2026-09-02), same 124 frames / 24 fps, wall clock from request to MP4 bytes on a cold-to-warm process, VRAM peak from a 1 Hz nvidia-smi sampler, both tiers at their default shift 6:
| Canvas | Aspect | -turbo-4step-768p-v1.1 (5 steps) | -turbo-8step-768p (9 steps) |
|---|---|---|---|
1344x768 | 7:4 | 269.9 s, 12.6 GiB VRAM | 453.3 s, 12.7 GiB VRAM |
768x768 | 1:1 | 206.4 s, 9.3 GiB VRAM | 344.9 s, 9.2 GiB VRAM |
Full per-render evidence — host/driver/binary provenance, adapter pull facts, scheduler_estimates rows, and visual verification for these two tiers plus the shift-6-vs-shift-12 A/B on the v1.1 tier — is recorded in the qualification record.
Every other shape is priced by scaling those measurements: the denoise workspaces with the packed sequence, the audio decode with the clip length, and the video decode with the canvas area. A long clip therefore costs real VRAM: 345 frames at 1344x768 asks for a device floor of about 24.3 GB against 9.7 GB at the default, and a host that cannot supply it is refused with those numbers rather than by a rule.
Note that a Turbo tag costs slightly more VRAM than the base tier on the same canvas: it is the same compact stack plus a resident adapter, and the step count it moves buys time, not memory.
When a first-frame image is attached without explicit --width/--height, the CLI and Discord builders render the source's own aspect at the largest size the area ceiling allows; a 16:9 source gets 1312x736, a square one 992x992; and the engine fits the frame internally. The free-form aspect-derived short-edge canvas applies only to the download-only official BF16 references.
Create on web, desktop, and iPhone offers the recommended canvases as shape chips and a live frame slider, and a request outside the rule is still refused at submission instead of after the model loads.
Mold rejects rather than silently resizing, rerouting, changing steps, dropping the source image, or falling back to another backend. A downloaded checkpoint can remain stored on an unsupported host; Create and request routing become available only when that host advertises the matching runtime capability. The public runtime uses a source-controlled conservative memory profile; it does not require private authorization or qualification-record files.
Supported Ref2VA request
minimax-h3-ref2va:comfy-pruned-int8 conditions on an ordered set of references instead of a boundary frame. Everything about the generated side is FL2VA's (the same canvas rule, the same 17n+5 frame grid at 24 fps, the same 21-50 sampler grid points, MP4 with synchronized audio) and the conditioning side is the set:
- 1 to 12 references in total, at most 9 images, 3 videos, and 3 audio files
- each reference between 2 and 15 seconds where it has a duration; video and soundtrack references are truncated to the generated clip's own length
- images larger than a 2048 short edge are scaled down onto their own 2048-short-edge canvas and smaller ones keep their native geometry (never upscaled, matching ComfyUI); videos are likewise scaled down onto the reference canvas only when they exceed it; every soundtrack is resampled to 32 kHz stereo
- order is authority. The set is presented to the conditioner as
<Picture n>,<Video n>, and<Audio n>in the order you supply, and the frozen plan carries a reference fingerprint over that order. The same files in a different order are a different render, not the same one.
An image reference can be cropped before it is sent: the reference row's Crop action on web, desktop, and iPhone opens a drag rectangle with Free, 1:1, 4:3, 3:2, and 16:9 presets, a 64 px minimum per axis, and a live vision-pad cost hint (a 1:1 crop of a 1080p photograph is 1,156 pads instead of 2,040). The crop is applied at the photograph's original resolution before the reference is digested and uploaded, so the server only ever sees the cropped image; it is recorded in the print's metadata as references[].crop and Reuse settings restores it when you reattach the same original. This is a choice of which part of the photograph is the reference, never a fit to the output canvas; Mold still scales an oversized cropped image down onto its own 2048-short-edge canvas (never up), and the generated print's size is unchanged.
There is no reviewed list of reference sets. The runtime qualification is minted per request from the set's own preprocessing shapes: the conditioner sequence, the conditioning latents, and every memory bound scale with what you actually attached, and a set the device cannot hold is refused with the numbers rather than by a rule. A prompt still gets roughly a thousand tokens on top of the references' own vision pads.
From the CLI, each reference is a KIND=PATH pair and the kinds are image, video, and audio:
mold run minimax-h3-ref2va:comfy-pruned-int8 "a slow dolly through the scene" \
--reference image=hero.png \
--reference video=clip.mp4 \
--reference audio=score.wav \
--width 1344 --height 768 --frames 124 --fps 24 \
--steps 21 --guidance 0 --strength 1.0 --format mp4When MOLD_API_KEY is configured and the host advertises upload support, the CLI streams references through authenticated, request-bound upload sessions. Without that combination, it sends inline references up to 32 MiB decoded reference bytes combined across all batch siblings. This supports hosts with authentication disabled; an auth-enabled host still requires its valid key. Rejected uploads are never retried anonymously. During capability discovery, missing legacy routes retain inline compatibility, while authentication, server, malformed-response, and network failures surface before transfer.
The server seals retained reference bytes separately from the queue journal and saved metadata, which carry descriptors and digests. An upload session binds one request, so --batch N above 1 is refused with uploaded references — submit siblings one at a time. Inline references allow batches within that aggregate decoded-byte budget. License acceptance already recorded on the rendering server needs no duplicate client record; H3 has no separate acceptance gate.
License and support boundary
H3 model weights and upstream model assets use the MiniMax H3 Community License, at pinned revision bfc8ed0353f5a9733be73e6b2c98ec0948195b86, not Mold's MIT license. Review those terms for your intended use. Mold's source code and H3 integration remain under Mold's repository license. Mold downloads the weights directly from the pinned upstream repositories and verifies every file; it does not bundle or mirror the payloads in Mold releases. The project's license and integration record documents the completed governance decision.
The completed project review authorizes H3 use in every territory and across Mold's CLI, server/API, Discord, desktop, web, iPhone, gallery, remote-client, shared-server, and hosted paths. It also covers generated-output distribution and model distribution or redistribution. Technical availability remains limited to routes Mold has implemented and qualified; authorization does not make an unsupported task, device, or request shape runnable.
The license link and notice in this guide and Mold's README are the project's required user-facing license, attribution, disclosure, downstream-term, and acceptable-use delivery. Mold does not require a separate clickthrough, geolocation check, H3-specific generated-content label, downstream contract, or surface-specific acceptable-use control. Existing Mold authentication, validation, capability, safety, and operational controls continue to apply.
The official BF16 checkpoints remain download-only qualification references. Their much larger artifact graphs are visible to preserve exact acquisition and inventory authority, but no released build executes them.
Native authoring
Mold Studio on macOS and its iOS companion offer ordered Ref2VA image, MP4 and PCM WAV references, including replacement, ordering and retained-source reuse. FL2VA has first/last-frame wells. These controls use the generation profile and shared request policy; see the macOS guide or iOS companion guide for limits.