LucidFlux_SM_KSampler

What it is

LucidFlux_SM_KSampler is the node with the most work per frame in the whole pack: it runs the actual restoration denoise. Despite the familiar name it is not a wrapper around ComfyUI's stock KSampler - it's a hand-rolled flow-matching sampling loop from the LucidFlux source, tuned for the dual-condition model the Model node built. You can't drop the pack's conditioning into a normal KSampler and expect results, and you can't run this node on a stock Flux latent either. They're a matched set.

How it works

Here's what happens, mechanically. The sampler takes the condition bundle from LucidFlux_SM_Encode, which contains the LQ and LDR image conditions, the SigLIP/Redux image embeddings, and the precomputed prompt embeddings. At each step of the denoise it calls denoise_lucidflux, which runs the Flux transformer with the dual condition branch injecting the restoration conditions alongside the normal img/txt/img_ids/vec inputs. The schedule is the standard Flux shifted flow-matching schedule, and the shift flips depending on whether the base is dev or schnell - which is exactly why the Model node is so insistent about "dev" being in your dit's filename. Get that wrong and you'll be sampling a shifted schedule against a model that wasn't built for it, and output quality quietly falls apart.

The inputs

The inputs:

• model: the bundle from LucidFlux_SM_Model (transformer + dual condition branch). This is why the output of the Model node is a dictionary, not a plain model.
• steps: default 20. With the turbo LoRA applied upstream you can head toward 8; without it, 20-30 is the sane range.
• seed: standard. Set it and keep it if you want reproducible restores.
• cfg: default 4.0. This is guidance for the dual-condition branch, not classic CFG - Flux dev is guidance-distilled, so this is the distilled-guidance scale, and the default is where the author tuned it. If output looks overcooked, this is the knob.
• condition: from LucidFlux_SM_Encode.

Output: Latent. But read the fine print - this is a latent with baggage. The node tucks the source images and the infer_2k flag into it so the decoder knows what to color-align against and whether to expect the 2K layout. So it must go to LucidFlux_SM_Decoder (1K/2K) or LucidFlux_SM_Pid_Decoder (4K) - never a stock VAE Decode. The 4K example runs this node with 9 steps and feeds the PiD path; the 1K example runs 20 steps into the normal decoder.

Install and VRAM

Install is the pack's shared story: git clone https://github.com/smthemex/ComfyUI_LucidFlux into custom_nodes, pip install -r requirements.txt, restart (or use ComfyUI Manager). No per-node downloads - everything this node needs arrives through the Model and Encode nodes ahead of it. It's also the node with the real VRAM footprint: when block_offload is off, this is where the 12B model gets moved onto the GPU wholesale, and on a 12GB card that's the moment of truth.

Practical notes

Practical notes from running the pack: this sampler is the slow part, so the turbo LoRA (via LucidFlux_SM_Cond) is how you make iteration tolerable. And if your restore comes out with weird colors, that's not this node's fault - check the decode stage's wavelet setting before you blame the sampler. The sampler's job is only to denoise; the color lock happens at the door.