BetaSamplingScheduler

Here's a sampler-theory fact that flipped the community's advice upside down: the schedules everyone used for years - Karras, exponential - are actively harmful on flow-matching models like Flux and Wan. What those models want is a schedule that redistributes denoising effort as little as possible, and the beta schedule is one of the two names everyone keeps landing on (the other being "simple"). This node is that schedule, given its own slider set.

BetaSamplingScheduler draws its noise curve from a Beta distribution - the same shape family that gives you a smooth, unimodal probability curve - controlled by two parameters, alpha and beta. Tune them and you reshape how quickly the schedule drops through the noise levels: how much effort goes to the coarse structure-forming steps versus the fine detail steps.

How it works

It computes sigmas through ComfyUI's beta_scheduler, using your model's own model-sampling object - which is why, unlike most schedulers in this box, it takes a model input. It needs to know the model's native noise range to build the schedule in the right units. Given alpha and beta, the curve leans one way or the other; equal values (the default 0.6 / 0.6) give a symmetric, middle-weighted drop.

The inputs that matter

• model (MODEL) - determines the schedule's units and range. Must match the model you'll sample.
• steps (INT, 1–10000, default 20).
• alpha (FLOAT, 0–50, default 0.6) and beta (FLOAT, 0–50, default 0.6) - the shape knobs.

One SIGMAS output. It's a drop-in replacement for BasicScheduler in any custom-sampler graph.

Why you'd pick it

If you're on an SD 1.5/SDXL checkpoint, you probably don't need this - Karras was doing fine and the community said so for years. Beta became a workhorse when flow-matching took over, because a near-straight trajectory punishes aggressive schedule reshaping and rewards exactly this kind of conservative curve. The distilled models are pickier still: their schedulers must match what they trained on, and beta-family curves are what many of them expect.

You'll also hear about beta57 - that's the beta schedule pinned to alpha 0.5, beta 0.7, popularized by the RES4LYF sampler pack and frequently the specific recipe named on model cards. If a card says "beta57," you can approximate it here with those exact alpha/beta values, though the pack's version is built into its own scheduler node.

Common issues

• Tuning alpha/beta when you don't need to. The defaults are sane for most flow-matching work. These sliders are for when the model card or a workflow explicitly names values - wandering off them blindly usually just makes images different, rarely better.
• Forgetting the model input. This is the one scheduler in the group that needs the model plugged in. Grab the wrong model and the schedule will be in the wrong units.
• Expecting it to fix a sampler problem. The scheduler shapes the noise curve; if the image is oversaturated or muddy, check your sampler and CFG too - beta won't compensate for a fundamentally wrong pairing.

It's the quiet, unglamorous node that a huge share of current Flux/Wan workflows are secretly built on. Nothing flashy, just the right curve for the architecture.