SamplerDPMAdaptative

Every other sampler in this category asks "how many steps?" SamplerDPMAdaptative asks a different question: "how good does each step have to be?" It's an adaptive solver - the DPM solver with error-controlled step sizing - which means the step count isn't something you set, it's something the sampler arrives at based on how much error your tolerances allow. That makes it the most intellectually interesting sampler in the box, and also the one people try once, find confusing, and never revisit.

How it works

It's built on the classic dpm_adaptive solver from the k-diffusion library. At each step it estimates the local error of its prediction and decides whether to accept the step, shrink it, or grow it - a numerical-ODE mindset applied to diffusion. The two numbers that matter most are rtol and atol (relative and absolute tolerance): looser tolerances mean bigger steps, fewer of them, faster; tighter means more, smaller steps, slower but more faithful to the ODE.

The rest of the knobs exist because this is a real adaptive integrator: order (2 or 3), h_init (initial step size), pcoeff/icoeff/dcoeff (PID controller gains - yes, it has a PID controller), accept_safety (a safety factor on step acceptance), plus eta and s_noise for stochastic behavior (eta 0 = deterministic).

The inputs and output

• The two to actually touch: rtol (default 0.05) and atol (default 0.0078). Lower both → more steps → higher quality but slower.
• Everything else, defaults are fine. This is the one node in the family where I'd actively discourage wandering the sliders.
• One SAMPLER output, into a sampler port.

Why it's a trap (and why it's interesting)

Here's the gotcha that catches everyone: you set "steps" on your scheduler, but the adaptive sampler ignores your step count as a hard limit - it treats the schedule as a suggestion and can take more evaluations than the schedule implies, especially on low-noise regions. So a workflow that looks like 20 steps can actually run 30+ forward passes. Slower than expected? That's why.

The community has mostly stopped using it - mention counts peaked around 2024 and trail off to near-nothing since. The honest summary is that adaptive error control sounds great on paper ("only as many steps as needed!") but in practice the fixed schedules from Karras or beta, with a converging sampler, hit the same quality with less surprise and better predictability. When every other sampler gets you there at a known cost, "it decides for itself" stops being a feature.

Common issues

• "Why is this slower than my normal sampler?" - adaptive means it may exceed your nominal step count. Check tolerances, don't blame the GPU.
• Non-deterministic timing - same seed, same settings, and the step count can vary run to run because acceptance depends on the error trajectory.
• Expecting it to be a speed hack. It isn't; tighter tolerances make it slower by design.

It's a curiosity with a great mechanism and a vanishingly small user base - the sampler equivalent of a vintage car. If you're exploring, it's worth one run to feel what adaptive control does. If you're trying to finish a project, pick something predictable.