MiniMax H3 Spectrum Patch

MiniMax H3 is a 33B omni-modal transformer generating video and audio from one context, and every denoising step runs the whole thing. Drop the step count and you lose what you wanted. So this node pulls a different lever: after a few normal steps it stops calling the H3 blocks and predicts what they would have produced. Nothing to train, nothing to download - on a default 8-step run that's 5 real H3 forwards instead of 8.

What it actually is

Not a sampler, not a speed LoRA - a model patch: MODEL in, MODEL out. Your sigma schedule and the sampler's latent update are untouched; what disappears is the expensive part, the stack of H3 blocks.

That's a different lever from the usual ones. TeaCache-style caching and SageAttention cut the cost of each step; this cuts how many steps pay full price. They stack, but tune one at a time or you'll never know which one ate your motion quality.

It's an engineering port of Spectrum, the training-free adaptive spectral feature forecasting method (FLUX/SDXL/Wan ports landed around March 2026). The paper claims up to 4.79× on FLUX - but that's 50 real steps against 10–15, and people running the SDXL port in practice reported about 2×. Take the headline with salt.

How the forecast works

In residual mode (the default) each real forward stores final hidden state minus input hidden state. In hidden mode it stores the final hidden state itself. Either way the node fits a Chebyshev polynomial over denoising time with ridge regression, then predicts the feature for the next step. blend_w mixes that global polynomial fit with a local first-order Taylor extrapolation taken from the last two observations - 0.5 is an even split. cheby_degree sets the polynomial order, ridge_lambda the regularization on the fit.

Then it rebuilds the lightweight H3 input embeddings and runs only the decode head - final layer, unpatchify, audio unpack - and returns that as if the blocks had run. That head is why a forecast isn't free, and why your wall-clock win is always a bit less than skipped-forwards-over-total-forwards suggests.

warmup_steps (3) real forwards fit the predictor before the first guess. tail_actual_steps (1) forces the final step to be real, because that's the step most likely to be judged. Defaults on 8 steps give exactly the log line in the README: real=5 forecast=3 total=8.

The settings worth touching

• steps - must equal the downstream sampler's step count exactly. This is mistake number one, and the README says so twice.
• forecasts_per_refresh - 1 means alternate real/forecast. 0 disables forecasting without you unplugging anything; 2+ chases more speed and accumulates error on complex motion.
• history_size - the code ships a default of 8, the README's recommended config says 0 (keep everything). Both fine, but if you set a number it must be 0 or >= cheby_degree + 2 or the node raises.
• enabled - clean bypass for A/B testing.

Leave the rest alone until you've measured. The one exception is adaptive_guard, which is worth turning on while you validate: it probes the real features at each refresh (probe_size elements) and stops forecasting for that sampler if the sampled error beats max_probe_error, instead of drifting quietly. history_device and pinned_history only matter if VRAM is tight. Keep verbose on - the "completed" line is your only proof forecasts actually fired.

Installing it

ComfyUI Manager, search MiniMax H3 Spectrum. Or the manual route the README gives:

cd ComfyUI/custom_nodes
git clone https://github.com/Singularity-baakaka/ComfyUI-MiniMaxH3-Spectrum

Restart ComfyUI. There are no pip dependencies - the pack imports its H3 helpers (MiniMaxH3Model, pack_audio, patchify_video, PackedLayout, …) straight from your ComfyUI install, which is also the fragility: it copies H3's current internal forward behaviour, so a ComfyUI refactor of MiniMax support can break it at import. GPL-3.0-or-later, because it derives from ComfyUI's own H3 forward path.

Wiring it

UNETLoader → LoRA / attention patches → MiniMax H3 Spectrum Patch → H3 generator or KSampler. It goes after LoRAs, since it's a model-level patch. On a two-branch setup, use one patch node per branch with the same scheduler steps, and leave one_sampler_only on so predictor state can't leak between samplers. Shape, context, refs or keyframes changing resets the forecaster automatically.

What actually goes wrong

The failure the Spectrum family is known for is washed-out output - desaturation and lost contrast. The SDXL port shipped a whole calibration step to fix exactly that; this node has no calibration knob. So if clips come out grey and flat, go conservative: forecasts_per_refresh=1, higher cheby_degree, adaptive_guard on.

The code also raises, loudly and clearly: "must wrap a MiniMaxH3Model" (you patched something that isn't H3), "supports batch size 1", and the history_size rule above.

And the last trap is judging it wrong. Reports on the sibling ports agree the output stays sharp but the trajectory wanders - you get a different take, not a blurrier one. Compare fixed-seed outputs, wall time and peak VRAM, not the sampler's it/s, which this node flatters because the decode head still runs.

If your H3 clips take ten minutes, this is the cheapest real win on the table. If you're quality-critical at 8 steps, leave enabled false and spend the time elsewhere.