KarrasScheduler

If you came up in the SD 1.5 / SDXL era, "Karras" isn't a scheduler - it's a personality trait. The Karras noise schedule, from NVIDIA's EDM paper, was so dominant that it got glued onto the end of sampler names ("DPM++ 2M Karras") and became the default answer to every "what settings?" question for years. KarrasScheduler is that schedule as a standalone node, and it's still here, still useful - on the right models.

How it works

The Karras schedule concentrates denoising effort in the middle of the run. Early steps stay relatively high, the middle steps do the heavy structural work, and the tail refines detail. That reshaping was a genuine correction for the curved noise trajectories of DDPM-style models - which is why, at lower step counts, it beat the plain linear schedule so reliably that the whole community adopted it.

Its parameters are the EDM three:

• sigma_max (FLOAT, default 14.614642) and sigma_min (FLOAT, default 0.0291675) - the start and floor of the curve. Those defaults are SD 1.5's native noise range.
• rho (FLOAT, default 7.0) - the curve shape. 7 is the classic EDM value; higher rho pushes more of the schedule into the middle steps.
• steps (INT, 1–10000, default 20).

One SIGMAS output. No model input - like exponential, it's a pure formula with hardcoded SD-1.5-era endpoints.

The part everyone learned the hard way

The don't-use-Karras-on-flow-matching rule started as Flux folklore and then generalized into one of the most consistently reproduced findings in the sampler literature: on flow-matching models (Flux, Wan, Z-Image), Karras and exponential fail across every sampler - not mildly underperform, fail. The mechanism is mechanical: those models train on a near-straight trajectory and want balanced sigma schedules; aggressively redistributing denoising effort breaks them.

So the honest rule of thumb: Karras on SD 1.5/SDXL and their finetunes (including the anime line) - yes, still the safe default. Karras on Flux/Wan/Z-Image - no, and if a shared workflow runs it there, swap in beta or simple before you change anything else.

Common issues

• Unchanged defaults on a different model. The sigma endpoints are SD 1.5 values. On SDXL or flow-matching, the model's native range differs, and sampling outside it is out-of-distribution. BasicScheduler derives the range from the model and is often the better generic choice for exactly this reason.
• Tuning rho blindly. It's a real knob, but 7 is where the community landed after years of sweeps. Wander off it without a reason and you'll mostly just get worse images.
• Carrying it to a new model "because it always worked." That's the trap the whole community fell into for a year. It worked because of the architecture, not because it's universally good.

Karras earned its reputation, and on SD-lineage models it's still the schedule I reach for. It just stopped being a universal default the day flow-matching arrived - and knowing that distinction is most of what this node has to teach.