Spectrum Apply WAN

Wan video is the last great open base model, and it is slow. Full-quality 720p on a 5090 runs about 25 minutes a clip; on a 4090 it's 40 minutes for 81 frames. The usual escape hatches - Lightx2v or CausVid speed LoRAs, TeaCache, Self-Forcing - either trade away detail or come with an 800-line install saga. Spectrum Apply WAN is another way in: a training-free acceleration node that lets you run fewer denoiser steps by forecasting the features you'd otherwise compute. No distillation, no LoRA, no API, no key. It's the Wan-native port of the Spectrum paper, and it's aimed squarely at the 14B backends people actually run.

What it actually does

Inside every sampling step, the model runs its whole transformer stack to produce a hidden feature, then a head converts that into the denoised latent. Spectrum's trick: cache the final feature from the last WAN block after each real forward, fit a small online forecaster to how it's evolving, and on the steps you choose to skip, predict that feature instead of burning the expensive network. Chebyshev polynomials plus a ridge regression, in plain terms - cheap math on a few dozen history points, standing in for billions of parameters.

So the name is a lie in the best way: it calls no service and downloads nothing. It's a sibling of TeaCache - cache-and-skip acceleration - but where TeaCache reuses a stale feature, Spectrum forecasts a fresh one. The author's README is upfront that this is a practical approximation of the paper: a 16-point history cap and a tail_actual_steps = 1 guard that keeps the final refinement step on the real path, where forecast bias would show up as softened microdetail.

Wan 2.2 is the interesting case

The 14B expert split is what makes this node worth a second look. Wan 2.2 runs separate high-noise and low-noise experts, so this repo treats them as separate Spectrum targets - each expert gets its own runtime, its own feature history, its own forecaster. You place one node after each expert loader and wire the patched models into your existing workflow. There's also an experimental transition_mode = bias_shift that hands the high-noise predictor off to the low-noise expert instead of cold-starting it. Cool idea, explicitly experimental, and the code falls back to normal per-expert fitting if the handoff doesn't line up - so you can try it without much risk.

The inputs that matter

The defaults are sane and the README documents them well, so don't touch everything. You'll actually set three things:

• backend - auto usually works, but for Wan 2.2 14B set it explicitly per expert (wan22_high_noise / wan22_low_noise) so there's no guesswork about which handler patches what.
• enabled - a pass-through toggle; handy for A/B testing speed against quality without rewiring the graph.
• forecaster_cache_mode - low_vram_exact (default) avoids caching a dense coefficient tensor on the GPU; switch to legacy_dense_coeff only if you have VRAM to burn.

Beyond that, blend_weight, degree, ridge_lambda, window_size, flex_window, warmup_steps, history_size, and tail_actual_steps are the forecaster's tuning knobs - the defaults in the README are a good starting point, and debug prints every step decision to stderr so you can see which steps it actually skipped. Output is a single patched model that replaces the loader's output going into your sampler.

Install

ComfyUI Manager (search "ComfyUI-Spectrum-WAN-Proper"), or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/xmarre/ComfyUI-Spectrum-WAN-Proper

Then restart ComfyUI. That's it - no extra dependencies beyond stock ComfyUI, no model downloads.

Where people get burned

• Forgetting the expert split. One node on a Wan 2.2 workflow does nothing useful; you need one on each expert model.
• VRAM. WAN features are huge. The history_size = 16 default and low_vram_exact mode exist precisely because a naive port blows up the GPU - if you raise history, watch your memory.
• It's riding on ComfyUI internals. The patch targets WanModel.forward_orig(...), which is not a public API. If ComfyUI reshuffles the WAN backend, this node may need a maintenance update - that's the price of training-free speed.
• Block-level side effects vanish on skipped steps. Any custom node that needs internal WAN blocks to execute every step won't see them on forecasted steps. By design.

If you're on Wan 2.1 or the 5B, it's a plug-and-play speedup in the same spirit as TeaCache. If you're grinding out 14B clips, the expert handling alone makes it worth a run.