KSampler Advanced (Partial Sigmas)

Wan 2.2 is a MoE model: a high-noise expert that does motion and composition, and a low-noise expert that does detail. The usual speed workflow splits the denoising into two passes - a few steps without the lightx2v LoRA, then the rest with it - and a plain KSampler can't do that cleanly because it can't take an explicit sigma schedule. That's the gap KSamplerAdvancedPartialSigmas fills: it's a KSampler that consumes a SIGMAS tensor and only runs the first steps of it, handing you back the remainder to chain into the next pass.

How it works

Where a stock KSampler picks its own sampler/scheduler pair and does all the steps, this one does comfy.sample.sample_custom against the sigmas you feed it. It splits your schedule in two:

• current_sigmas = sigmas[:steps+1] - the denoising steps this pass actually runs
• next_sigmas = sigmas[steps:] - everything left, returned as an output

Run a 20-step schedule with steps=4 and you get a 4-step high-noise pass plus a 16-step schedule for the low-noise pass, all sharing the same trajectory. That overlap at the boundary is deliberate - the next pass continues from the exact sigma level the previous one ended at, which is what keeps lighting consistent instead of jumping.

Inputs that matter

Most are familiar KSampler territory: model, positive, negative, latent_image, cfg (default 1.0 - and with lightx2v it needs to stay there), add_noise, noise_seed. Two are this node's whole personality:

• sampler_name - any of ComfyUI's built-in samplers. Euler is the usual pick for distilled Wan; the euler_ancestral and cfg_pp variants are there if you're feeling spicy.
• sigmas - the schedule, typically from WanLightx2vSchedulerBasic in this pack, though it accepts any SIGMAS tensor from anywhere.
• steps - how many denoising steps this pass executes. It's clamped to the schedule length, so you can't overrun.

Three outputs: output (the sampled latent - wire to the decoder), denoised_output (the clean predicted-x0 latent, populated when ComfyUI captures it during sampling), and - the important one - sigmas, the un-run remainder for your next pass.

The split-pass pattern

For Wan 2.2 + lightx2v, the rhythm is: first pass high-noise, add_noise=true, no lightx2v LoRA or low strength; second pass low-noise with the LoRA at full strength, add_noise=false so you don't re-roll noise on top of a half-denoisened latent. Community best practice keeps the high-noise pass clean and applies speed LoRAs to the low-noise pass at 0.4–0.6 strength - this node makes that structure explicit instead of bolting it together with bypass nodes.

Install

ComfyUI Manager (search "Wan2.2 Lightx2v Scheduler") or:

cd ComfyUI/custom_nodes/
git clone https://github.com/opparco/ComfyUI-WanLightx2vScheduler

Restart after. No dependencies, no model files - it's pure ComfyUI internals.

Gotchas

• It needs a SIGMAS input; there's no scheduler dropdown. Drop it into a workflow that expects a plain KSampler and it won't know what to do.
• Forget add_noise=false on a continuation pass and you'll get noise injected into an already-progressed latent - a common source of "why is this suddenly garbage" moments.
• denoised_output isn't always populated; the README says "when available," and when it isn't, the node falls back to copying the regular output.
• Standard KSamplers won't accept custom sigmas, which is exactly why the pack pairs this with its own scheduler nodes. If you use it standalone with a third-party SIGMAS source, it still works - it's the general-purpose piece of an otherwise niche pack.