MiniMax H3 Block Cache (T8)

MiniMax H3 is the 33B open-weights video model with native stereo audio that everyone got excited about in August 2026 - and then most people tried to run it and went quiet. Full-precision weights are around 42.5 GB, and even at a tiny 256×160 the author's own bench shows a single denoise step taking 24–39 seconds on an RTX 4060 Ti. A real 124-frame clip is a different universe of compute. This node, MiniMax H3 Block Cache (T8), claws some of that back: an experimental block cache in the EasyCache/TeaCache spirit, purpose-built for H3's double_block stack.

It's an honest footnote up front: this is an approximate cache, not a magic 2× button. On the author's own smoke test it skipped 7 of 20 steps for a 1.09× wall-clock gain. Think "cheap win if your content is stable," not "go re-render your whole film reel."

How the F1B0 trick works

H3 runs a stack of 50 transformer double_block layers on every model forward. Consecutive sampling steps denoise the same latents, so most of what those blocks compute is nearly identical from one step to the next. The node exploits that the same way TeaCache does, but with stricter bookkeeping:

• It always runs block 0 fully, then compares block 0's audio and video residual outputs against the previous step.
• If the max relative difference of both stays under residual_diff_threshold, it declares a hit: blocks 1–48 are skipped, the cached residual "tail" for the target audio/video segments is re-added, and the model jumps straight to H3's native final layer and unpatchify.
• If either the audio or video residual moved too much, it runs all 50 blocks and stores a fresh tail for next time.

That's the "F1B0" in the name: full block 0, cached blocks 1–49. The cache is execution-scoped - it lives for one sampling run, is keyed by uuid/shape/sigma so it never serves stale geometry, and is cleared on finish, error, or cancel. It also caches only the target audio/video segments, not the text/conditioning/reference rows. It returns a cloned model, never mutates your input, and refuses to attach to anything that isn't a native MiniMaxH3Model - wrappers like EasyCache, LazyCache, or Spectrum Apply MiniMax H3 hard-error rather than quietly misbehaving.

The inputs that matter

Most of the inputs have sensible defaults. A beginner sets these:

• model (MODEL) - a native ComfyUI MiniMax H3 model from Load Diffusion Model.
• residual_diff_threshold (default 0.12) - the whole speed/quality dial. Higher caches more forwards and is more likely to change the result; lower is safer and slower.
• cache_device (default cpu) - CPU keeps tensors in system RAM and saves VRAM; GPU avoids transfers but eats VRAM. Start with CPU.

The rest - start_percent/end_percent (the warmup and disable window), max_consecutive_hits, metric_stride, verbose - you can leave alone until you're tuning. verbose is genuinely handy for that: it logs per-forward audio/video diff scores so you can see why a step missed.

The single MODEL output is the patched clone. Wire it into your Basic Scheduler and Basic Guider exactly as you would the raw model.

Installing it

You need ComfyUI 0.30.0 or newer with native MiniMax H3 support, and nothing else - there are no extra Python dependencies and no API keys (the MiniMax name might make you check; you don't need one, H3 runs locally).

• ComfyUI Manager: search minimax-h3-block-cache-t8 or MiniMax H3 Block Cache (T8) and install, then restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/T8mars/comfyui-minimax-h3-blockcache-T8.git, restart.

The node lives in advanced/model_patches. Add it between Load Diffusion Model and your scheduler/guider. It's marked experimental, so treat it like a tuning knob rather than a foundation block.

Gotchas that will actually bite you

• It refuses to combine with other acceleration. If you have EasyCache, LazyCache, Spectrum Apply MiniMax H3, or any existing double_block patch in the workflow, the node raises rather than stacking. Use one accelerator.
• Same seed ≠ lossless. It's an approximation; change prompt, resolution, frame count, steps, or scheduler and hit rate and quality both shift. The README says as much, and the author's own stride-9 probe (1.20×) isn't the default precisely because it changes the boundary judgement.
• Hits aren't guaranteed. Short, low-step runs may land almost no hits - the warmup window alone eats the first 8% of sampling. If you see cached 0/1 model forwards in the log, the cache never triggered.
• A weird SaveLatent/NestedTensor.contiguous crash at the end of sampling is a core ComfyUI bug, not this node - the README flags it as unrelated.

Is it worth installing? If you're rendering long H3 video and your shots are visually stable, a cache that skips most of the transformer for free is a no-brainer. If you're doing 1–2 step quick drafts, it'll just sit there.