VELVET VICE MiniMax H3 — Turbo / Distilled LoRA

MiniMax H3 in its base form wants around 20 sampling steps per frame at serious resolution, which on a consumer card is the difference between a render that finishes and one that's a screensaver for the afternoon. A compatible Turbo / Distilled LoRA is the standard escape hatch - it collapses that 20-step trajectory into about 8 - and the VELVET VICE MiniMax H3 Turbo Director is the node that makes flipping between the two a single checkbox instead of a wiring ceremony.

The mechanism is the distilled-LoRA trick that's been around since LCM-LoRA on SDXL: a model was trained to reach the same endpoint in far fewer steps, and that capability ships as a LoRA you patch onto the base weights at sampling time. Nothing changes about the base model; you just apply the adapter and feed the sampler a lower step count. This node wraps exactly that in a safe toggle.

Here's how configure thinks, because it's the part that keeps you out of trouble:

• turbo_enabled = false → the model is passed through completely untouched and you get base_steps (default 20). The LoRA is not applied.
• turbo_enabled = true → it hunts for the turbo LoRA in your loras folder (AUTO matches minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors or anything you pick from the list). If the file is missing and bypass_on_missing is on, it quietly falls back to base at 20 steps instead of erroring - which means a missing LoRA degrades to slow-but-correct, not a crash. If strict_h3_compatibility is on and the file doesn't look like a real H3 turbo LoRA, same graceful bypass. If everything checks out, it patches the model with LoraLoaderModelOnly at model_strength (default 1.0) and switches you to turbo_steps (default 8).

The outputs make the switch explicit and wireable:

• model (MODEL) - either the base model or the LoRA-patched one.
• steps (INT) - the killer feature. It emits 8 when turbo is active and 20 when it isn't, so you can wire this straight into your sampler's step input and the graph changes step count for you. Never desync the sampler from the LoRA again.
• status (STRING) - tells you exactly which branch it took, including a WARNING line when it bypassed.
• turbo_active (BOOLEAN) - for downstream logic.

There's also an optional turbo_config input: feed it the turbo_config output from the System Hub and the hub's choices (LoRA, strength, step pair, compatibility policy) override whatever's set locally. That's how the big workflow drives this node from one control surface.

Install and the LoRA file

cd ComfyUI/custom_nodes
git clone https://github.com/Velvet-Vice/velvet-vice-minimax-h3

Restart ComfyUI (or install via Manager, searching "velvet-vice-minimax-h3"). No pip dependencies. The LoRA itself you grab from Civitai - the pack README links the H3 Turbo LoRA collection and is blunt that running H3 in base mode works but a turbo LoRA is strongly recommended. Put it in ComfyUI/models/loras/, any subfolder is fine.

Where people get burned

The author's own advice: match your turbo step count to the LoRA you actually downloaded. An 8-step LoRA run at 20 steps, or a 4-step LoRA run at 8, both give you muddy output - the LoRA was trained for its specific cadence. And remember the bypass cuts both ways: if you expected turbo speed and you're getting base-model slowness with no error, the node has quietly bypassed, so read the status output or console. Missing file and incompatible file both land you there.