TiledK Sampler (Advanced)

This is the same tiled sampler as the plain Tiled KSampler node - same tile-based VRAM savings, same four tiling strategies, same underlying code - but it swaps the single denoise knob for the start_at_step / end_at_step pair you'll recognize from stock ComfyUI's KSampler (Advanced). That trade only matters if you need to split a run into multiple stages; if you just want to denoise a big latent in one pass, the plain Tiled KSampler is simpler and does the job.

Why you'd want the split version

The step-range version exists so you can chain samplers: run the first N steps with one sampler (or one set of conditioning, or before swapping models), hand the latent off mid-denoise, and finish the remaining steps in a second sampler node. That's the same pattern SDXL base→refiner workflows use, and the same reason people reach for KSampler (Advanced) generally - it's not really about matching a specific denoise value, it's about being able to pause and resume the same denoising trajectory across separate nodes. Applied to tiled sampling, it means you can do that staged handoff on a huge, tile-split latent instead of being locked into one KSampler-shaped node running start to finish.

One thing worth knowing going in: early denoising steps carry disproportionately more of the final image than late ones, so start_at_step/end_at_step isn't a linear stand-in for a denoise value - don't expect steps=20, start_at_step=10 to look identical to denoise=0.5 on the plain node. It's a real, commonly-hit confusion in the wider ComfyUI community, not specific to this pack. Treat the step range as "where in the trajectory this sampler picks up and hands off," not as denoise-strength arithmetic.

The inputs that matter

Most of it matches the plain Tiled KSampler: model, positive/negative, latent_image, tile_width/tile_height (default 512, same guidance as the base node - 512 is a reasonable start, bigger tiles cost more VRAM headroom, smaller tiles cost more runtime), tiling_strategy (random/random strict/padded/simple - same tradeoffs), steps, cfg, sampler_name, and scheduler.

What's different: noise_seed replaces the plain seed, and add_noise (enable/disable) controls whether fresh noise gets injected at start_at_step - disable it when this node is picking up a latent that's already partway denoised by an earlier sampler, so you don't re-noise it. start_at_step and end_at_step define the step range this call actually runs. return_with_leftover_noise (enable/disable) decides whether the output latent keeps its residual noise for a downstream sampler to continue, or gets fully resolved - enable it if this is the first stage of a chain, disable it on the final stage. There's also a preview toggle (enable/disable), unique to this node versus the plain version, for watching the tile-by-tile denoise as it runs. Output is a single LATENT, same as the plain node.

Installing it

Same pack, same install: search "Tiled sampling for ComfyUI" in ComfyUI Manager, or cd ComfyUI/custom_nodes && git clone https://github.com/BlenderNeko/ComfyUI_TiledKSampler and restart. No models to download, no heavy dependencies.

Common issues

Everything that applies to the plain Tiled KSampler applies here too, since it's the same tiling engine underneath: this pack hasn't been actively maintained, and there are real reports of it producing garbled output on Flux rather than a clean result - it was built for the SD 1.5/SDXL era and wasn't updated for flow-matching architectures, so don't reach for it there. Masks (latent noise masks, regional conditioning masks) also don't reliably crop per-tile - the whole mask gets applied to each tile rather than tiling along with the image, which will bite you if you're chaining this node into a masked or inpaint-driven pipeline. And the strategy incompatibilities carry over unchanged: "random" adds per-step overhead and skips uni samplers, "random strict" skips SDE samplers, "padded" costs up to 4x the tile count. If you only need one sampling stage, save yourself the extra wiring and use the plain Tiled KSampler instead - this one earns its complexity only when you're actually splitting the run.