KSampler With Restarts (Advanced)

The plain KRestartSampler gives you the full restart toolkit but denoises the whole schedule. This Advanced variant is the same machine with the training wheels removed: it adds add_noise, noise_seed, start_at_step, end_at_step, and return_with_leftover_noise - the exact input set of an Advanced KSampler - on top of segments, restart_scheduler, and chunked_mode.

You reach for this when you want restart sampling but only on a slice of the denoising range. The classic case is the two-pass workflow: run a cheap normal pass, then come back and only denoise the tail (high start_at_step, end_at_step near the end) to refine detail - the same pattern people use for hires-fix-ish refinements and latent upscaling. Restart sampling's whole point is revisiting higher noise levels, which makes it a natural fit for that "refine the second half" move.

The inputs that matter

start_at_step and end_at_step define the slice of the noise schedule you sample, exactly like the built-in Advanced KSampler. add_noise and noise_seed control whether fresh noise is injected at the start of that slice (for a standalone second pass you usually keep noise enabled with a fixed seed so it's reproducible); return_with_leftover_noise decides whether the latent comes back fully denoised or with some noise left in for chaining. Then the restart trio: segments (the [N_Restart, K, t_min, t_max] string, prefilled with the pack default), restart_scheduler (the schedule used inside restart segments - karras is the paper's choice), and chunked_mode (call the sampler in whole chunks up to each restart, or one step at a time; leave it on).

The output is a single LATENT, and it's honest about what it isn't - like its parent nodes it's built for ODE samplers. SDE or ancestral samplers won't blow up your machine, but the author explicitly says they're not what restart sampling is for, and won't improve on normal sampling.

The trap this node is known for

Because you're slicing the schedule, you can end up with restart segments that don't fit your slice. The README spells it out: end the denoising early or start it late (e.g. 20 steps, start_at_step 0, end_at_step 10) and a segment's t_min can land above its t_max in your slice - meaning the "restart" would push the latent to a higher noise level than it started at and destroy the sample. The pack doesn't crash; invalid segments are silently ignored, with a console warning like [Restart Sampling] nearest neighbor of segment t_min ... is greater than t_max ..., ignoring segment....

So the debugging rule is simple: if you trimmed the schedule and nothing seems to be restarting, check the console for ignored-segment warnings, and shorten or drop the segments that fall outside your slice. Setting COMFYUI_VERBOSE_RESTART_SAMPLING=1 shows the node's full plan of steps and restarts, which makes this a ten-second diagnosis instead of a mystery.

Install

Nothing special - it's one node among six in the pack, with no dependencies and no model files:

cd ComfyUI/custom_nodes
git clone https://github.com/ssitu/ComfyUI_restart_sampling

Restart ComfyUI (or install "Restart Sampling" through Manager), and find it under sampling. If you don't actually need to slice the schedule, use the plain KSampler With Restarts instead - it's the same technique with one less way to shoot yourself in the foot.