LaplaceScheduler
The sigma curve from a Laplace distribution
- SIGMAS
LaplaceScheduler builds a noise schedule from a Laplace (double-exponential) distribution, and its inputs - mu and beta - are the location and scale of that distribution. It's part of the same "compute sigmas from sigma_min/sigma_max" family as PolyexponentialScheduler and the Karras/Exponential schedulers, and it's been in ComfyUI core since 2023. If you're here, you're either deep in a noise-schedule rabbit hole or you inherited a workflow with one of these in it.
How it works
Where a normal scheduler spreads denoising effort by a simple formula, this one samples its sigma positions from a Laplace curve - a sharp peak in the middle with long tails. Concretely:
mu- the location of the distribution's peak, i.e. where in the schedule the densest cluster of steps sits. Default 0.beta- the scale / spread, default 0.5. Biggerbeta= fatter distribution = more steps pushed toward the tails.steps- how many sigma values to produce.sigma_max/sigma_min- the noise range, defaults at the standard 14.61 / 0.029.
The output is a SIGMAS tensor for SamplerCustomAdvanced.
The honest framing
This is one of the quietest nodes in the scheduler family, and there's a reason: a Laplace-shaped schedule is a taste, not a technique. Nobody's model card says "use LaplaceScheduler." The community conversation about schedules lives in named schedulers (karras, normal, beta, simple) and in model-specific ones like LTXVScheduler or Ideogram 4 Scheduler - not in tuning mu and beta by hand. Where this node still matters is the same place all the parametric schedulers live: when you want a specific, unusual distribution of denoising effort and you're willing to test it against a fixed seed.
Where people get burned
- The whole parametric-scheduler trap. You can spend an evening sliding
muandbetaaround and end up exactly where a named scheduler already was. Before tuning, know what you're chasing - usually it's "more effort in the middle steps," and the Karras scheduler exists for precisely that. - Flow-matching models. Same rule as everywhere else: reshaping the sigma curve aggressively on a straight-trajectory model (Flux, Z-Image, Klein, Anima) is a distortion. A weird Laplace shape is a bad idea there specifically.
- Reading
mulike CFG. It shifts where steps cluster, not prompt adherence. It won't fix a prompt-adherence problem.
If you don't already know why you need a Laplace-distributed schedule, you almost certainly don't - grab BasicScheduler and pick a named scheduler. If you do know, this is the node, and it does exactly what the parameters say.
For what it's worth, the sibling you'll actually meet in the wild is the plain KarrasScheduler - the Laplace and polyexponential variants are for the people who want the same family of ideas with different curves. If a downloaded workflow contains a LaplaceScheduler, read its mu and beta as intent: whoever built it wanted the densest cluster of steps somewhere specific, and changing them changes the whole character of the run.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| steps | INT | 201–10000 | — |
| sigma_max | FLOAT | 14.610–5000 | — |
| sigma_min | FLOAT | 0.030–5000 | — |
| mu | FLOAT | 0.0-10–10 | — |
| beta | FLOAT | 0.50–10 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| SIGMAS | SIGMAS | — |