Spectrum Apply Flux

FLUX is slow because every sampling step runs the whole transformer. Your usual escape hatches are distilled LoRAs (Turbo, Lightning - nice, but they trade away detail and need a different CFG style) or just cranking steps down and eating the quality loss. Spectrum Apply Flux is the third option: keep the full model, run real forwards on only some steps, and predict the rest. Training-free, no new model files, no CFG surgery. It's a faithful ComfyUI port of Spectrum (CVPR 2026, Stanford - "Adaptive Spectral Feature Forecasting for Diffusion Sampling Acceleration"), and the paper reports up to a 4.79x speedup on FLUX.1 at 14 network evaluations instead of 50. Your mileage varies, but that's the ballpark.

What it actually does

This isn't a sampler node and it isn't a distillation node. It's a patch on the MODEL path that hooks into FLUX's forward pass. On the steps you do run, it caches the final hidden image feature - the tensor right before FLUX's final_layer head, after the single-stream blocks. Then it fits a small online Chebyshev ridge regressor over step index and uses it to forecast that feature on skipped steps, running the normal final_layer on the prediction. That "predict the feature, not the output" choice is the whole game: it matches the official Spectrum FLUX integration point, and it's why this port exists.

The other ports floating around get dinged for real things: some forecast the whole UNet output (wrong target), some hard-code 50-step normalization, and some leak runtime state across model clones. This one installs a single generic wrapper on the inner model and looks up the active runtime from transformer_options per call, with a clean fallback to normal FLUX when Spectrum isn't active. It also normalizes the Chebyshev basis against the actual schedule length from sample_sigmas, because ComfyUI users rarely run exactly 50 steps.

The inputs that matter

The node takes one MODEL in and one MODEL out. Slap it on the FLUX model line after your LoRAs and before the guider/sampler - UNETLoader → LoRA stack → Spectrum Apply Flux → CFGGuider → sampler.

Of the ten knobs, most have sane defaults and can be ignored. The three you'll actually touch:

• blend_weight (default 0.5) - blends the spectral predictor with simple linear extrapolation. 1.0 is pure spectral, 0.0 is pure linear. The middle is more robust than the raw paper setting.
• flex_window (default 0.75) - how aggressively the forecast window grows after each real forward. 0.75 is paper-style moderate, 3.0 is "I need speed now."
• tail_actual_steps (default 3) - reserves the last N solver steps as real forwards. This is the safety knob the paper doesn't have, and the one I'd leave alone. Late-step forecast bias shows up as smooth, textureless microdetail, and reserving the tail keeps the refinement pass honest.

warmup_steps (5) and window_size (2.0) set how many real forwards happen before forecasting kicks in and how big the initial gap is. degree (4) and ridge_lambda (0.1) are the Chebyshev fit's order and regularization - defaults are fine. max_history (32) is just a memory cap, and there's an enabled toggle plus a debug flag that logs actual vs. forecasted steps per run for A/B testing.

Installing it

ComfyUI Manager: search "ComfyUI-Spectrum-Proper" and install. Or manually:

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

Then restart ComfyUI. That's it - no extra Python dependencies and no model downloads, which is a genuinely nice property for a speed node. If you want to sanity-check the math without launching ComfyUI:

cd ComfyUI/custom_nodes/ComfyUI-Spectrum-Proper
python tests/smoke_runtime.py   # prints "ok"

Where people get burned

• It's FLUX-only, deliberately. No SDXL, no SD3.5, no video. The author ships separate ports for SDXL and WAN rather than one half-working generic node. Don't plug this into a non-FLUX model line and expect anything.
• Forecasting only activates on a short allowlist of samplers - euler, euler ancestral/flow, LCM, DPM++ 2M/3M SDE, and Flux2JiT. Anything else silently falls back to native FLUX, and you won't necessarily notice.
• It depends on current ComfyUI FLUX internals. If an update changes forward_orig's signature, this breaks until the pack catches up. It also isn't guaranteed to compose with custom nodes that patch FLUX's forward_orig directly - standard transformer patch chains are fine, head-to-head forward replace-ers aren't.
• The speedup isn't a promise. Guidance, ControlNet residuals, resolution, and every wrapper in between change the real wall-clock ratio. And if you're chasing raw numbers, set tail_actual_steps = 0 - the default of 3 keeps the final steps actual-only, deliberately more conservative than the paper's benchmark config.

One tip: flip debug on for a run or two. Seeing "actual vs. forecasted steps" in the log tells you whether your sampler even qualified before you start tuning flex_window and wondering why nothing changed.