Samplers and schedulers reference¶

Topics: generation

What the sampler_name and scheduler fields actually select, what separates the options, and which combinations are known to fail.

What each field does¶

A sampler is the numerical method that integrates the reverse diffusion process. A scheduler (a sigma schedule) decides where in the noise range the sampler's steps land. The scheduler does not change how many steps are taken, so it does not change cost: measured across all nine schedules, mean render time varied between 2.29s and 2.36s, which is noise.

Two consequences follow, and they explain most confusion about these fields:

Deterministic samplers agree with each other once converged. Most samplers integrate the same probability-flow ODE, so at sufficient steps they arrive at the same image. If two of them produce near-identical output at 25 steps, that is the correct result and not a defect. What separates them is how few steps they need to get there, not where they end up.

Only stochastic samplers produce genuinely different images. Ancestral (_a suffix) and SDE samplers inject fresh noise at each step, so they have no fixed point to converge to and will keep producing different output at any step count. This is why they look distinct in side-by-side comparisons while the deterministic ones do not.

Trajectory steps, estimated work, and execution ceilings are different units¶

The unit boundary is an architectural constraint recorded in ADR 11. The versioned registry and HTTP projection are recorded in ADR 12.

A second-order sampler evaluates the model twice per step, so comparing samplers at equal step counts charges them unequally. The correct comparison is at equal wall time: published guidance puts it as comparing Heun at 30 steps against Euler at 15

The SDK calls this relationship sampler work: one work unit approximates the marginal inference work of an ordinary first-order model evaluation at the same payload. Fixed samplers carry a one-, two-, or three-unit marginal rate. This is intentionally not called an exact evaluation count because terminal steps and solver reuse make exact NFE differ slightly, and it is not wall time because hardware and payload overhead still matter.

k_dpm_adaptive is excluded from the comparisons below because it chooses its own iteration count rather than following the schedule. AI-Horde uses a stable 40-work-unit request estimate for usage, TTL, and upfront policy. A backend may separately advertise sampler execution contract 1.0, which contains the atomic bounded_dpm_adaptive_v1 guarantee: at most ceil(1.25 * trajectory_steps) solver iterations. Each iteration costs the requested solver order (two or three work units), so a 20-step request has a hard ceiling of 50 or 75 work units respectively. An estimate and a ceiling answer different questions and are never substituted for one another.

The public sampler-constraints document is self-describing. Its schema_version identifies the JSON shape, while execution_contracts publishes each worker conformance version and the complete formulas behind its atomic guarantees. A worker reports only sampler_execution_contract_version; it does not need to assemble or interpret a list of individual guarantees.

Measured: cost per step and how quickly each sampler settles¶

Wall time per render is fixed overhead (text encode, VAE decode, model juggling) plus steps times per-step cost. Fitting time against step count separates the two, which matters because comparing raw wall time at one step count understates a higher-order sampler's real cost by diluting it with the fixed part. The cost figures below come from renders taken through the production pipeline at 10, 20, 30 and 40 steps, three repeats each with warmups discarded, seed and prompt and cfg scale held fixed, on both SD1.5 at 512x512 and SDXL at 1024x1024. Each ratio is that sampler's fitted slope over k_euler's slope on the same model. The fixed overhead the fit sets aside is around 0.29s at 512x512 and 1.40s at 1024x1024.

settled is the similarity between a pair's 24-step and 60-step renders. Higher means the sampler had more nearly stopped changing by 24 steps. It is a rate proxy, not an absolute quality score, and it is meaningless for stochastic samplers, which have no fixed point and cannot settle by construction. Their rows are retained for completeness rather than for comparison.

The two cost columns are wall-time fits on one card. Read them as evidence for the fixed marginal work families rather than as a price. The learned Kudos model consumes raw trajectory steps plus sampler identity and is not multiplied by these work rates.

The SDXL column is the one to read for what a sampler itself costs. At 1024x1024 the GPU work of a step swamps the host-side work of issuing it, and every sampler lands within a fifth of its evaluation count. At 512x512 a step takes around 50ms, so per-step host work is a visible fraction of it and inflates the one-evaluation samplers by up to a third; the same samplers are clean on SDXL, which is what identifies the effect as overhead rather than solver cost. Within the one-evaluation family the ordering of the SDXL column is inside measurement noise and is not worth reading as a ranking.

• Stochastic samplers do not converge by design, so their settled figures are meaningless. They are retained for completeness rather than for comparison.

k_dpm_adaptive publishes no ratio at all. It picks its own step count, so wall time per requested step is not a quantity it has: the fit lands near 0.6 r-squared on both baselines against better than 0.97 everywhere else, and attributes ten seconds of a 1024x1024 render to fixed overhead.

The ordering matches theory: one-evaluation solvers sit at the baseline, two-evaluation solvers between 1.9x and 2.2x on SDXL, and the one three-evaluation solver at 2.9x. The two highest settled figures belong to second-order solvers, which is the trade being made: they cost roughly double per step and reach their answer in fewer steps. Whether that is a net win depends on the step count, which is why the honest comparison is at equal time.

What this means for pricing¶

Kudos for an image request comes from a small trained model that predicts how long the job will take. It is given the raw requested step count and a one-hot slot for the sampler, so per-sampler cost is already learned rather than derived: k_heun is priced above k_euler because the model learned it takes longer, not because anything multiplies its step count.

Two consequences are worth stating, because both are easy to assume otherwise:

• A sampler the model was never trained on has no slot of its own. It is collapsed onto a trained slot with the same marginal work profile before the lookup (CANONICAL_KUDOS_SAMPLERS in horde/classes/stable/kudos.py), which is where every sampler added after the checkpoint was frozen gets its price. Adding samplers therefore reprices nothing that was already being served.
• The trained vocabulary tops out at two evaluations per step, so the three-evaluation solvers (heunpp2, seeds_3) take the most expensive slot available and are under-priced by roughly a third. Correcting that needs a retrained checkpoint rather than a multiplier.

Estimated work is used for quantities that scale with expected compute: job TTL, upfront policy, and usage totals. A worker opting into limit_max_steps instead uses maximum work: fixed samplers have a finite profile-derived ceiling, while adaptive work requires an explicitly advertised backend execution contract.

Why job TTL is longer than isolated inference¶

The lease policy and its alternatives are recorded in ADR 13.

The job TTL begins when a worker pops an assignment and ends when it submits the result. It is a lease, not a benchmark forecast. Workers are encouraged to keep a shallow local look-ahead queue so they can load a model or fetch LoRAs while inference for the preceding assignment is still running. Queue residence, storage and network variance, and inference all have to fit inside the same lease.

For an ordinary assignment the service starts with:

30 seconds + 2 seconds * estimated work * (width * height / 512^2)

The scalable term corresponds to 0.131072 megapixel-work units per second. The normal-speed worker classification uses 0.5 MPS, so the lease provides about 3.8 times the isolated compute time of a worker exactly at that threshold. Requests which opt into slow workers can still be served below it. If one equally expensive assignment is already ahead in the local queue, the normal-speed comparison becomes about 1.9 times their combined compute time. This is deliberately conservative: the difference is capacity for prefetching and runtime variance, not a claim that median hardware needs two seconds for a 512-square first-order step.

A 150-second minimum protects small jobs, for which fixed model and asset preparation can dominate. ControlNet doubles the computed lease; an assignment whose selected model has a Flux, Qwen Image, or Z-Image Turbo baseline triples it. Those factors compound before the minimum is applied. Each requested LoRA then adds a fixed download allowance of about 107 seconds (a 400 MB file at 30 Mbps) on top of the floored lease. A worker explicitly marked extra-slow receives three times the resulting lease. Consequently, combinations can produce intentionally large deadlines. This ordering is part of the worker pop contract and should not be rearranged as a mathematical simplification.

Sampler work is the proportional input, which is why fixed higher-order samplers receive two or three times the scalable allowance. k_dpm_adaptive instead uses the service's stable 40-work-unit estimate; its backend execution ceiling is a safety bound, not a runtime forecast, and is not substituted into TTL. Schedulers and solver presentation controls do not independently change the lease. Neither do source processing, post-processing, or hires-fix: their ordinary setup cost is covered by the shared fixed and queue allowances rather than by a separate per-feature multiplier. LoRAs are the exception, because a cache miss on several maximum-size files costs more than the whole floor.

Solver options¶

A sampler takes tuning arguments beyond its name and schedule. They reach the solver through comfy.samplers.ksampler(name, extra_options), which builds them into the KSAMPLER object the solver runs from. That is the mechanism the backend's own per-sampler nodes use: SamplerDPMPP_2M_SDE and its siblings each construct a sampler with its options already baked in. SamplerCustom is a different node that consumes an already-built sampler and passes no options of its own. The stock sampler node the horde's graphs are built around has no inputs for them, so they were therefore pinned at their defaults and unreachable from any horde request. hordelib now exposes them (sampler_eta, sampler_s_noise, sampler_s_churn, sampler_solver_type, sampler_order), all defaulting to unset so an existing request renders identically.

Why this matters for the request vocabulary: eta is the only controllable variation dial the stack has. Changing the seed varies everything at once and cannot be dialled; eta moves continuously from "give me exactly this image again" to "explore around this image". Options are filtered per sampler at the point the sampler is built, because handing sample_euler an eta raises TypeError from inside graph execution rather than being rejected as a bad argument.

Convergence is rarer than the folklore suggests¶

A step ladder that stops once two consecutive step counts agree above 0.98 (hordelib's extremely similar band) was run across 27 samplers on two of the nine schedules. 8 of 54 pairs settled at all, and 6 of those only at 48 steps, the ladder's ceiling. The single early stop was k_dpm_adaptive at 8 steps, which follows from it choosing its own iteration count rather than the schedule's.

That headline overstates the case in two ways worth correcting. The stochastic and ancestral samplers are counted in the 54 but cannot satisfy a two-in-a-row similarity bar at any step count: they inject fresh noise every step and have no fixed point, so their non-convergence is a definition rather than a finding, and including them inflates the ratio. The meaningful denominator is the deterministic pairs alone. Separately, only two of the nine schedules were laddered, so none of this is a statement about the schedule space.

Two readings are required rather than one because the ladder is not monotonic: changing the step count changes the sigma spacing, so a higher count is a different trajectory rather than a refinement of a lower one. k_euler reads 0.94 between 10 and 12 steps and then falls back to 0.87 between 12 and 16.

The practical consequence: at 512px on SD1.5, raising steps keeps changing the image well past the point most guidance implies it stops mattering, though the cost vs benefit of doing this is still questionable.

Schedules¶

Known failures and sharp edges¶

These are measured locally on SD1.5 unless stated.

Eliciting a specific effect¶

Recipes, in the order a requester is likely to want them. Each names the axis that actually controls the effect rather than the one that is conventionally fiddled with.

Two anti-recipes worth stating: do not reach for karras because the step count is low (it artefacts at 4 steps on most solvers), and do not reach for linear_quadratic on a non-flow model at all.

Choosing¶

• Default for quality: k_dpmpp_2m with karras, 25-30 steps. Converges quickly and is stable across step counts.
• Cheapest usable image: a first-order solver (k_euler, k_dpmpp_2m, ddim, deis) with simple or sgm_uniform, at 4-8 steps. uni_pc and uni_pc_bh2 are reported as strong at 10-15 steps and cost around 1.35x per step here.
• Fewest steps regardless of cost: a second-order solver (k_dpm_2, k_heun) or heunpp2. They settle soonest but cost 2.1x to 3.2x per step, so they only win if the step saving exceeds the ratio.
• Deliberate variation between runs: an ancestral or SDE sampler. These do not converge, which is the point.
• Reproducibility: a deterministic sampler. Note that the horde cannot promise bit-identical output across workers regardless of sampler, since workers differ in GPU and driver.
• Schedule: leave it alone unless you are working at low step counts, where simple and sgm_uniform were the most robust here. karras remains a good default at 20+ steps.