KSampler DF (with Refiner & Upscale)

You know that four-node tail that every high-res workflow has - a KSampler, a second KSampler at low denoise, a latent upscale in between, then an upscale model bolted on the end? KSampler DF is that whole chain collapsed into one node. Feed it a model, conditioning, and a latent, and it runs the main pass, switches samplers mid-generation, upscales the latent, then decodes and upscales the image. If you build the same two-pass setup constantly, it's genuinely fewer wires. Just understand what the name is selling you before you trust it.

"Refiner" here does not mean the SDXL refiner. The SDXL refiner was a second, separate model (the ~2.6B checkpoint Stability shipped to pair with the 3.5B base), which the community tested, decided added skin texture nobody asked for, and quietly dropped. This node takes one model and runs it in two phases with different settings: different sampler, scheduler, CFG, denoise. That's a legitimately useful trick (it's how a cheap converging sampler explores and a higher-order one finishes), but if you clicked in expecting the old base-plus-refiner pipeline, adjust expectations. The source clamps refiner_at_step to the 0–steps range, then runs main_steps = refiner_at_step and refiner_steps = steps - refiner_at_step, in that order, with a latent upscale wedged between the two phases when it's enabled.

The inputs that actually matter - most of the 24-odd fields are plain KSampler territory:

• steps and refiner_at_step - the pair that defines the split. steps is the total, so 20 steps with refiner_at_step at 12 means 12 main + 8 refiner. Crank refiner_at_step to steps and the refiner phase never runs; drop it to 0 and everything is "refiner."
• denoise_refiner - the trap. At 1.0 the refiner phase re-noises the latent from scratch and effectively draws a new picture. That's the classic "why does my refiner change the image so much?" failure. Keep it around 0.3 and drop the refiner steps way down; the tooltip spells it out - 0.0 = no effect, 1.0 = full effect.
• latent_upscale_enabled / latent_upscale_method / latent_upscale_factor - a latent upscale between the two phases, i.e. a hires-fix mid-flight. bislerp is the default and is fine; factor 1.5–2 is the usual sweet spot (the KB's hi-res fix guidance).
• upscale_model_name - a dropdown populated from your models/upscale_models/ folder (ESRGAN, RealESRGAN, SwinIR, anything Spandrel can load), or none.

Outputs: LATENT (the denoised latent) and IMAGE (the decoded/upscaled image). VAE is a required input and it's the only decoding path - no VAE, no image.

Install

Via ComfyUI Manager, search KsamplerDF. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/DevDuckFace/KsamplerDF

then restart ComfyUI. Two real gotchas here. First, the README's own clone command is copy-pasted from a template and points at https://github.com/YOUR_USERNAME/... - that URL doesn't exist, so use the one above. Second, the README claims "no additional dependencies," which is almost true: the node imports spandrel for its upscale step, but modern ComfyUI bundles spandrel already, so it loads out of the box. If the upscale dropdown shows nothing but none, drop a .safetensors ESRGAN model into ComfyUI/models/upscale_models/ and refresh.

Troubleshooting

• "My image changed completely" - denoise_refiner is too high. The refiner phase adds fresh noise; treat it like any img2img pass. Also remember it's the same model running twice - if you wanted a true second model, this isn't that.
• VAE required - the changelog made it mandatory in v1.0.2. Missing it errors before sampling.
• The latent upscale does nothing - it only runs when latent_upscale_enabled is enable and there's a refiner phase to upscale into (refiner_steps > 0).
• VRAM - the model upscale is tiled (512px tiles, 32px overlap) and auto-halves its tile size on OOM, so it's slow rather than crashing. On big images that's a patience problem, not a config one.

The honest verdict: it's a thin convenience wrapper around ComfyUI's built-ins, useful if you want the two-phase pattern as one movable node in a workflow you rebuild a lot. It's not a speedup and it adds no new capability - just fewer wires.