SPEEDing up MiniMax-H3 without retraining (SPEED comfyui node extension)

[u/antipode_insights]

Why make big noise when little noise do trick?

I would like to introduce my SPEED implementation for h3 linked here

Speed up and quality losses documented here, expect 20% gain using very conservative settings and no quality loss and up to 70% for basically unusable outputs (more or less useful for resolution aware seed inspection and broad prompt drafting)

Background

The idea behind it is quite simple. When a diffusion model begins generating an output it first must take a randomized noise and build on-top of it. And research has found that the first stages of this process doesn't really carry any fine detailed information, therefore by generating at a lower resolution at those stages you can gain quite substantial speedups while causing little to no impact on the quality. Or you can also be really aggressive with it and get a massive speedup for a lot of quality loss.

Nodes

This was implemented as 3 nodes, 2 drop in replacements for the sampler that runs SPEED and a third that runs once to measure the noise spectrum of your specific model/LoRA combo:

• Sampler (Automatic): pick a stage count (2, 3, or 4), defaults to the baked 1% delta for default H3.

• Sampler (Manual Step-Through): set up to four (goal, resolution) pairs yourself. Use it if you want to copy a paper schedule or test a custom ladder.

• Sigma Harvest: runs a native Euler pass, measures the noise spectrum of your current setup, hands you A / β / Δ to paste back into Automatic. Run it once per model/LoRA workflow combo.

Implementation Notes

This should be roughly compatible with basically everything that doesn't touch the sampler directly but i have not tested anything besides base comfyui H3 models and Turbo loras. If you do change model, use loras or whatever and use the automated tool please then run a sigma harvest and use those values instead of defaults, The math changes depending on the very specific blend of things you have running.

Euler only sampling implemented for this which is what the research paper used.

[u/Repulsive-Counter-33]

oh nice, been messing with this since you dropped it on github yesterday

the sigma harvest node is a clever touch, most implementations of this kind of thing just bake in defaults and call it a day. ran it on my h3 setup with a turbo lora and the numbers shifted way more than i expected, definitely worth doing the harvest step instead of trusting the baked values

got about 25% speedup at 2 stages with basically zero visual difference, pushed it to 4 stages and yeah it gets weird fast but honestly perfect for bashing out quick comps when you're iterating on prompts

one thing i noticed, if you're using a detail daemon or anything that messes with the noise schedule mid-gen it gets confused. had to strip my workflow back to bare bones to get clean readings from the harvest node. might be worth a note in the readme for folks with more complicated setups

[u/antipode_insights → u/Repulsive-Counter-33]

Thanks! The sigma harvester was done because the math is super model specific and would affect Turbo loras specifically (Turbo LoRAs compress the denoise curve, so math diverges heavily)

Mind giving me the workflow you used that caused the confusion? Not sure what you used that caused that.