ROCm H3 EasyCache

MiniMax H3 is fast for what it is - a 33B omni-modal video model ComfyUI runs natively - but a 4-step pipeline is still four full passes through a very large transformer. ROCm H3 EasyCache shaves one of those passes off when the denoising trajectory is smooth, and someone already tuned it so you don't have to. Drop it between your H3 model and your sampler, hit Queue, and get roughly a 25% speedup on the generation leg. That's the whole pitch.

First, the honest caveat about the name: nothing here calls out to ROCm. It's a thin wrapper over ComfyUI's core EasyCache node (the one that ships in comfy_extras.nodes_easycache), shipped inside the ROCm Ninodes pack and pre-tuned for the fast H3 + Spectrum pipeline the author builds around. If you're on an NVIDIA card you'll get the same behavior - the "ROCm" is where the pack lives and where it's tested, not a driver dependency. The thing you actually want it for is the tuning.

What it does under the hood

Step-caching works like this: during denoising, consecutive steps usually aren't that different. EasyCache runs the transformer, compares each new step against the cached result, and if the change falls below a threshold it reuses the cached output and skips the transformer forward pass entirely. With 4 steps it can skip one of the three middle steps - step 1 runs to build cache history, the middle steps get evaluated, the last always runs for quality.

The source shows exactly how it's wired: it clones your model, stuffs an EasyCacheHolder into transformer_options, and attaches three patcher-extension wrappers (sample, conditioning, and diffusion-model) that intercept the forward calls. The defaults - reuse threshold 0.2, caching between 15% and 95% of the schedule, subsample factor 8 - are the safe values for a short 4-step run, and that pre-tuning is the whole value. ComfyUI's raw EasyCache node makes you reason about all of this; this node is that reasoning, done once.

The inputs that matter

Only two of the five inputs deserve your attention on a first run:

• model - your MiniMax H3 model, after any LoRA and the Spectrum setup, right before the sampler. The node clones it and hands back a patched one; it doesn't touch the original.
• reuse_threshold (default 0.2) - how aggressive the skipping is. Higher skips more. 0.2 is the safe starting point for 4-step H3; the tooltip suggests trying 0.3+ if quality holds. This is the dial you actually turn.

The rest are set-and-forget: start_percent (0.15, skips the first step so there's cache history to compare against), end_percent (0.95, guarantees the final step always runs so you don't wreck the output), and verbose (per-step cache decisions in the log, useful when you're tuning the threshold). The single output, MODEL, wires straight into your sampler in place of the model you would have plugged in.

Installing it

It comes with the ROCm Ninodes pack, so install that, not this node alone:

cd ComfyUI/custom_nodes
git clone https://github.com/iGavroche/rocm-ninodes.git rocm-ninodes

Then restart ComfyUI and look under ROCm Ninodes → Optimization. ComfyUI Manager works too - search "ROCm Ninodes" - and the newer comfy node install rocm-ninodes CLI path is supported. Two version gotchas from the pack's own changelog: if you were on a v1.x install, run uv run python tools/upgrade_to_v2.py once to clean up the legacy layout, and if Manager ever refuses the install as "unsatisfiable," you're hitting the old requires-comfyui >= 1.0.0 bug - update the pack or your ComfyUI. No model files download for this node; it needs nothing beyond a recent ComfyUI that has core EasyCache and the patcher-extension API.

Where people get burned

The threshold default is tuned for a 4-step H3 run. Drag this onto a 30-step SD/Flux job and the "skip one of three" logic stops being a nice-to-have and starts costing you quality. And resist stacking it with TeaCache, MagCache, or other cache nodes - community reports of EasyCache are consistently "modest speedup, quality takes a hit on complex or high-motion content," and that's on top of one cache, not two. Check your output for flicker or ghosting on motion-heavy clips; if a scene is changing fast, the cached step genuinely doesn't match and the threshold is doing its job by skipping less. There's also a known cosmetic PyTorch warning about non-tuple indexing that EasyCache triggers in the console - harmless, still works.

Honest verdict: this is the rare caching node where the defaults are the point. On a fast H3 workflow it's a free ~25%, and the only meaningful decision is whether to push the threshold to 0.3. Start at 0.2, run a clip you know well, and only then decide if the extra speed is worth A/B-testing quality.