ExponentialScheduler

Back in the SD 1.5 and early SDXL era, the scheduler conversation had basically two contestants: Karras and exponential. ExponentialScheduler is the latter, frozen as a node. It's still in the box because it's cheap, simple, and on the right model family it's a perfectly respectable alternative to Karras. But the honest headline for anyone working in 2026: this is a schedule you should actively avoid on flow-matching models, because the community's sweeps have found it failing across the board there - not underperforming, failing.

How it works

The exponential schedule is the geometric one: each step multiplies the current noise by a constant ratio, so the noise level drops by a fixed factor per step rather than a fixed amount. In practice that means it stays relatively high for the early steps and then plunges through the fine-detail range - a curve that concentrates a lot of denoising effort in the tail.

Its two parameters are the endpoints:

• sigma_max (FLOAT, default 14.614642) - the starting noise level. That default is essentially SD 1.5's native max.
• sigma_min (FLOAT, default 0.0291675) - the floor.

Plus steps (1–10000, default 20). One SIGMAS output. Nothing else - this is a pure formula scheduler, no model input needed.

Why the defaults look like that

Those odd default numbers (14.614642, 0.0291675) are the EDM/SD 1.5 noise range, hardcoded because the node is old and predates per-model scheduling. That's a quiet warning: on SDXL or especially on a flow-matching model, the native sigma range is different, and you'd be sampling at levels the model wasn't trained on unless you adjust. BasicScheduler, which derives its range from the model, is usually the safer default for that reason.

The real gotcha

The KB and community sweeps are consistent here: on flow-matching models (Flux, Wan, Z-Image), exponential is one of the two schedules that fails "across every sampler" - the mechanism being that aggressive redistribution of denoising effort breaks on a near-straight trajectory. If you load a workflow on a flow-matching checkpoint and the output is mush, check whether it's running exponential and swap it for beta or simple.

Where it's still fine

On SD 1.5 and SDXL finetunes, exponential is a legitimate Karras alternative - different texture, often a touch more "pop" at the cost of being less forgiving at low step counts. If a workflow you trust calls for it, it's not wrong there. Just treat it as a DDPM-family tool, the same way you'd treat Karras.

One line of practical advice: leave the two sigma endpoints alone unless you know the model's native range, and if a shared workflow on a new model looks broken, exponential (or Karras) is the first thing to suspect.