FL MiniMax H3 LoRA Block Loader

Every normal LoRA loader gives you exactly one knob: strength_model. This node gives you that knob plus three group multipliers and a free-text list of per-block overrides, so you can turn down the first ten transformer blocks of a MiniMax H3 adapter without touching the rest of it. That's a real capability and a real trap, and the README is unusually honest about which is which.

What it actually does

You'd reach for it in two situations. First, an H3 LoRA that's doing too much: a style adapter that eats your reference image's identity at 1.0, or a speed/distillation LoRA where you want the step reduction but not every layer's contribution. Second - the traditional reason blocks. overrides exist - you want to test whether a behaviour comes from early layers (structure, motion feel) or late ones (texture, finish) without retraining anything.

It only touches the adapter you selected. Existing patches stay as they are, and it doesn't stack with your upstream loader: load the same file in both places and you get the adapter twice.

The mechanism, and why "block" means what it does here

The node refuses anything that isn't a native MiniMax H3 model - feed it a different architecture or a non-H3 wrapper and it errors rather than silently doing nothing. Then it runs the adapter through ComfyUI's standard LoRA path (convert_lora → model_lora_keys_unet → load_lora), which is what makes it accept the same files the regular loader does.

The interesting part is classification. Each patched target key is sorted by name into one of three groups:

• blocks.N - the main transformer stack, from keys like diffusion_model.blocks.12.…
• refiner.N - the token-refiner stack, diffusion_model.token_refiner.blocks.N.…. That's part of H3 itself, not the external Qwen3-VL text encoder, which is worth remembering when you're hunting for where a LoRA landed.
• other - projections, time embedding, the final layer. Everything outside both stacks.

Each group gets its multiplier; the effective strength is strength_model × multiplier. Patches are then batched by their computed strength and applied in one add_patches call per distinct value.

The inputs that matter

model, lora_name, strength_model (the overall scale, same convention as ComfyUI's model-only loader). Then blocks_strength, refiner_strength, other_strength, all defaulting to 1.

The one you'll actually edit is block_overrides. One rule per line, zero-based and inclusive, ranges allowed, # starts a comment:

blocks.0-9=0.5
blocks.25=0
refiner.0-1=0.8

An override replaces the group multiplier, and the overall strength_model still multiplies on top. Later rules win, so you can set a wide range and narrow it on the next line. Zero switches that target off entirely; negative inverts it. Out-of-range indices raise a line-numbered error instead of quietly doing nothing.

Two outputs: model goes into your sampler as usual, and block_report is a plain string listing the effective strength of every block and how many adapter targets matched each one - blocks.0: 0.5; 3 adapter targets and so on. Wire it to Preview Any (or a text node) before you trust a strength that looks suspicious.

Install

ComfyUI Manager, search FL MiniMax H3 and install from the Comfy Registry, or:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI-FL-MiniMaxH3.git

Restart ComfyUI. The pack's only requirement is huggingface_hub>=0.25.0, and that's for the VDN node's on-demand weight download, not this one. You still need a real H3 install: the ref2va diffusion model, a MiniMax-compatible Qwen3-VL text encoder, the fp16 video VAE and the fp32 audio VAE.

One migration note: these nodes used to ship inside ComfyUI_Fill-Nodes. Update Fill Nodes to a build where the MiniMax nodes are gone before installing this pack, or you'll get duplicate registrations.

Where people get burned

• "Requires a native MiniMax H3 model." You're on the wrong architecture, or on a model that's already been wrapped by something else.
• "No compatible H3 adapter weights found." The file isn't an H3 adapter. Same rule as any loader: the LoRA has to target the model you loaded. Unmatched checkpoint keys are logged by ComfyUI, so check the console before blaming the block math.
• Don't gut a Turbo or step-distillation LoRA. Its low-step behaviour is distributed across the adapter; zeroing a range because it "looked like the style part" is how people end up with mush at 4 steps. The author says this plainly, and the distillation literature agrees - these adapters are fragile when you start surgically removing pieces.
• Blocks don't have guaranteed roles. There is no block that owns "motion." Change one range at a time, same seed, same prompt, and compare. Fixed seed, one variable - the oldest advice in this ecosystem, and it's the only way block tuning produces information instead of vibes.
• It's not a speedup. This changes adapter weights, not the sampler or the architecture. Nothing here makes inference faster.

There's no speed LoRA that fits your card better because of this node, and no clip-strength equivalent either - it's model-only, by design.