H3 MiniMax Cache

Every sampling step on MiniMax-H3 is the whole 33B transformer block stack grinding over a packed sequence of video, audio and text tokens. At 4–15 second clips and dozens of steps, that's why an H3 render is something you start and walk away from. H3 MiniMax Cache is the speed hack that simply refuses to run that entire block stack on steps where the features haven't moved enough to matter - reusing the last real run's result instead.

It doesn't skip sampling steps - it skips the expensive part of them, which is more honest: the model still advances its timestep every iteration, it just doesn't always pay full price. Yes, that's approximate. The node is flagged experimental with conservative defaults and a dial for exactly how much approximation you'll tolerate.

How it works

ComfyUI's core exposes per-block replacements for H3 but no hook around the whole block stack, so this node fakes one. Running it clones the model patcher and, on the clone only, swaps in a reimplementation of H3's _forward that adds a "block loop" boundary around every transformer block. Nothing about the shared model class is touched globally - if the cache misbehaves, only the sampler wired to this clone feels it.

Inside that boundary lives a small state machine:

• On a full run it stores the block stack's residual (output minus input) plus a cheap fingerprint of the features entering the stack - a few dozen sampled dimensions, not the whole tensor.
• On later steps it measures how far those features have drifted since the last real run (accumulated relative L1 change).
• If that drift is below reuse_threshold, you're inside the caching window, and you haven't already skipped too many in a row - it skips the block stack entirely and just adds the stored residual to the current hidden states.
• Any real run refreshes both, so the cache never goes stale.

It's a port of silveroxides' UC_MiniMaxH3Cache from ComfyUI-UtilsCollection (MIT), traded author-to-author for this pack's H3 SLA Attention node. Both compose - the reimplemented block loop preserves core block replacements, so SLA's per-block patches still fire on the steps that do run.

The inputs that matter

• reuse_threshold (0.05 default) - how much feature drift you'll excuse before a skip is refused. This is your quality dial. Lower runs more real steps; raise it only after confirming output quality holds.
• start_percent / end_percent (0.15 / 0.9) - the sampling window where caching is even allowed. Early steps set structure, late steps polish detail, so both ends run dense by default.
• max_steps (2 default) - the cap on consecutive skips, so the sampler can't coast even when features look frozen.
• device (auto / cuda / cpu) - where the cached residual lives. cpu offloads it to system RAM, which matters on tight VRAM because that residual is a full-size hidden state, not a thumbnail.
• verbose - logs every skip decision and a final summary. Turn it on the first time you try this.

One MODEL goes in, one patched MODEL comes out. Wire it between your H3 loader (and any LoRA stack) and the sampler - the patch wraps the sampler's sigma schedule, so it sits on the MODEL feed of a normal KSampler or SamplerCustom.

Install

ComfyUI Manager (search "PlagueKind-Nodes") or:

cd ComfyUI/custom_nodes
git clone https://github.com/PlagueKind/ComfyUI-PlagueKind-Nodes.git

Then restart ComfyUI. No extra dependencies - the README lists only torch and ComfyUI's own utils, and unlike the pack's SLA Attention node this one doesn't need Triton or a particular GPU. Worth knowing: H3 itself ships under a community licence that geofences out the US, EU, UK and Korea - check you're licensed to run the weights before spending time on speed.

Where people get burned

The README doesn't document this node at all - it's one of the pack's H3 patch tools that never got a section, so the code and verbose log are your docs.

The biggest trap is the fail-safe. If the patch fails - you fed it a non-H3 model, forced device: cuda on a non-CUDA run, or set start_percent above end_percent - it catches the error, logs "[H3Utils] MiniMax Cache patch failed" to the console, and passes the model through unchanged. No crash, no caching, no obvious sign. If no skips show in your log, that's what happened.

Set expectations honestly: the pack publishes no benchmark for this node, and the verbose summary reports a block-stack speedup, not your end-to-end number. With the conservative defaults you might skip a fifth to a third of middle-schedule steps - enough to notice on a model this size, not magic. Turn on verbose, read the real skip count, and compare a cached render against a dense one before you trust it for finals.