ComfyUI Node

Spectrum Apply SDXL

Spectrum Apply SDXL

By xmarre·Created 6 months ago·Updated 5 months ago· 1
Spectrum Apply SDXL
  • model
  • model
enabledtrue
blend_weight0.50
degree4
ridge_lambda0.10
window_size2.00
flex_window0.75
warmup_steps5
tail_actual_steps3
min_fit_points6
debugfalse

You know the usual way to make SDXL faster: bolt on a Lightning, Turbo, or LCM LoRA and pray at 4 steps. Spectrum is the opposite of that. It's a training-free acceleration method from a 2026 paper (arXiv:2603.01623), and Spectrum Apply SDXL is a faithful ComfyUI port of it - no distillation, no new checkpoint, no low-CFG requirement. You drop it into your normal workflow, keep your favorite model and sampler, and skip a chunk of the expensive denoiser forwards. The author's own testing shows roughly 1.6x on SDXL with settings that look identical to the baseline, and up to ~2x if you push it harder.

How it works

The core trick: during a diffusion run, the denoiser's final hidden feature (the tensor right before the output head) changes smoothly across steps. So Spectrum runs real U-Net forwards for a while, caches those hidden features keyed by their sigma values, fits a small Chebyshev-polynomial + ridge regression model online, and then predicts the hidden feature on skipped steps - running only the cheap output head (self.out) on the prediction. Fewer full forwards, same-ish image.

That's the theory. The "Proper" in the pack name is the port fixing what earlier Spectrum ports got wrong: the wrong prediction target, hard-coded 50-step normalization that ignored your actual schedule, and runtimes leaking across model clones. This node patches the native UNetModel._forward, installs an outer-step controller at ComfyUI's sampler_calc_cond_batch_function hook, and stamps explicit step metadata (spectrum_run_id, spectrum_solver_step_id, spectrum_time_coord) so it knows exactly which solver step it's on. If that context is missing or malformed, it fails open and just runs a real forward - so a broken setup degrades to normal speed, never a crash.

The inputs that matter

There are ten inputs, but you can leave most at their defaults. The ones a beginner actually touches:

  • enabled - the on/off switch. Set to false and it returns the model untouched, which makes it painless to A/B.
  • warmup_steps (default 5) - the quality/speed dial. This is how many real forwards run before forecasting kicks in. More warmup = cleaner image, less speedup. The author found warmup_steps=8 on 20 steps looked basically identical to baseline while still giving ~1.6x.
  • tail_actual_steps (default 3) - reserves the last N solver steps for real forwards. This one earns its keep: late-step forecast errors show up first as softened microdetail and texture loss, because the tail is where the model does fine-grained refinement. Leave it at 3.
  • degree (default 4) and ridge_lambda (default 0.1) - the polynomial degree and regularization for the Chebyshev fit. Tinker only if you know what you're doing.
  • min_fit_points (default 6), window_size, flex_window, blend_weight, debug - defaults are fine. debug prints a shadow_compare log comparing predicted vs. actual features, useful if you're chasing artifacts.

The single output is a patched MODEL. Wire it like any model-patch node:

CheckpointLoaderSimple → LoRA / model patches → Spectrum Apply SDXL → sampler / guider

Install

Easiest via ComfyUI Manager - search "Spectrum Apply SDXL" and install. Or the manual route:

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

No extra Python dependencies beyond what ComfyUI already ships, and no model files to download. It's a patch, not a model.

Common issues

  • Mangled output at low warmup_steps. That's the speed dial pushed too far. The author's own warmup_steps=5 run was "slightly mangled" despite the 2x speedup. Crank warmup up, or raise tail_actual_steps, before you blame the node.
  • Speed LoRAs (Lightning, Turbo, LCM, DMD2) are a bad fit. They distill a compressed trajectory into the weights, which breaks the smooth feature dynamics Spectrum forecasts against. Not a hard crash - the node just can't forecast a trajectory that isn't there. If you want a fast low-step run, use the LoRA without Spectrum; if you want quality at 20+ steps, use Spectrum without the LoRA.
  • Sampler sensitivity. Spectrum relies on a strict one-denoiser-evaluation-per-solver-step contract. Euler with plain CFG is the tested sweet spot; samplers that break that contract fall back to real forwards. Community reports on the related ports suggest SDE/ancestral samplers work but need more steps.
  • It's SDXL-only. The node shape-checks for the native SDXL U-Net (input_blocks/output_blocks/time_embed). Don't feed it an SD1.5 or Flux model and expect magic.

Spectrum won't beat a 4-step Turbo run on raw speed - nothing will. What it gives you is a way to keep your full-quality model and still cut a third to half the generation time. For an SDXL-only pack, that's a genuinely good deal.

Categorysampling/spectrum

Inputs (11)

NameTypeDefaultDescription
modelMODEL
enabledBOOLEANtrue
blend_weightFLOAT0.500–1
degreeINT41–16
ridge_lambdaFLOAT0.100–10
window_sizeFLOAT2.001–32
flex_windowFLOAT0.750–16
warmup_stepsINT50–64
tail_actual_stepsINT30–64
min_fit_pointsINT61–64
debugBOOLEANfalse

Outputs (1)

NameTypeDescription
modelMODEL