Apply FastH3 Patch

What it does, and why you'd want it

Apply FastH3 Patch rewrites a MiniMax-H3 model in memory so it behaves like FastVideo's FastH3 - the DMD2 8-step distillation that produces a video-and-audio clip in eight sampler steps instead of the base model's full schedule.

That matters because video is where step count hurts: 20-plus steps on a 33B transformer is a coffee break per clip. FastH3 already exists as a checkpoint, but it's 44 GB on top of the H3 weights you may already own. This node keeps the base and downloads a 4 GB difference - or 149 MB of it - instead.

Why the swap is legitimate

The author's tensor comparison is the reason this isn't a hack. All 532 shared tensors match in shape and dtype; the trunk (attention qkv/out, both MLP matrices, ~21.5B of the 22B parameters) differs by about one bf16 rounding step. Rebuilding FastH3 from "fl2va plus what changed" lands within 1.08e-4 relative Frobenius error.

Only two things really differ. The adaLN timestep path (adaln_proj.*, adaln_t_table) is reparameterised beyond recognition - relative delta ~3.1, negative cosine similarity - and that is the entire 8-step distillation, in ~149 MB. Notice where the speed-up lives: not in what the model computes, but in how it reads where it is in the schedule. The second difference is 50 attn.to_gate_compress layers, 3.85 GB, which fl2va never instantiated at all.

How the graft works

It clones the model patcher and hangs the patch on it as object patches - finished tensors and modules, not deltas to fold in. Three consequences:

• With a curve table present ComfyUI builds the adaLN linears in float32 while the checkpoint stores fp16, so the node casts to the dtype the module was built with, not the file's.
• The gates don't exist on fl2va: model_detection decides gate_compress from whether the key is in the checkpoint, and the normal patch path only touches keys already in the state dict. Which is why there is no LoRA version of this and never will be - a LoRA loader can't reach a layer that isn't there. The other reasons are just as fatal: adaln_proj.linear.weight is [96768, 8], already rank ≤ 8, so factoring it would make it bigger, and the trunk has nothing to extract.
• Gate modules are built on the meta device, so nothing allocates 3.85 GB of scratch, and the node corrects the patcher's size - the gates don't exist when ComfyUI budgets VRAM, so without that fix you'd be planning for a model 3.85 GB lighter than the one you run.

Inputs and outputs

Two inputs, no widgets:

• model - "a MiniMax-H3 model, normally minimax_h3_fl2va_pruned_bf16", per the author's own tooltip.
• fasth3_patch - the FASTH3_PATCH from Load FastH3 Patch.

One output: MODEL, wired on to your sparse-attention or sigma-shift node and then the sampler. If you took the two split patch files instead of the full one, chain a second Apply - order doesn't matter.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Nynxz/ComfyUI-FastH3Patcher

Manager search FastH3 Patcher does the same thing, and there are no dependencies either way. Then two downloads: the patch file(s) into models/model_patches/, and the base minimax_h3_fl2va_pruned_bf16.safetensors into models/diffusion_models/.

The shipped example workflow is a good wiring reference - UNET Loader → Apply → sigma shift → attention backend → sparse attention (vsa, keep 10) → an 8-step sampler. Its loader widget still names a FastH3 checkpoint, so read it for the wiring, not the download list.

Run it at 8 steps

The distillation is baked into that adaLN path, so 30 steps doesn't buy quality - it hands the model noise levels it was never trained for, the same trap as any Lightning or Turbo build. CFG ~1; the example graph uses BasicGuider, i.e. no CFG term at all.

The author recommends the full 4 GB patch, but that's only because the example runs VSA, and VSA is the one thing that reads the gates. If you're not running sparse attention, take the 149 MB adaLN file - same 8-step model, minus 3.85 GB of weights that would just sit in memory.

Where people get burned

• "A FastH3 patch only applies to a MiniMax-H3 model, but this MODEL holds …" - you wired the wrong loader. The node refuses outright instead of quietly no-op'ing.
• "matched nothing in this model" - the file isn't a FastH3 patch; a LoRA or another pack's safetensors lands you here. A warning that only some tensors matched means a partial graft, usually a file from a differently built H3 variant.
• VRAM: the 4 GB patch is 4 GB of system RAM on load plus 3.85 GB grafted onto the resident model. On a quantized int8-convrot fl2va build the gates can't be quantized - there's no scale to quantize them against - so they land as plain bf16 while the rest stays int8.
• A/B in one graph: nothing on disk is touched and the patch is undone on unpatch, so a patched and an unpatched branch off one load is legitimate.

Patching changes your step count, not your licence: MiniMax-H3's weights are geofenced out of the US, EU, UK and Korea. Nothing here gets you around that.