LucidFlux_SM_Model
This is where a photo becomes a restoration task
- cf_model
- model
What it is
LucidFlux_SM_Model is the first node in every LucidFlux workflow, and it's doing a lot more work than a normal "load model" node. It doesn't just load one checkpoint - it fuses your base FLUX.1 dit with the LucidFlux restoration weights and assembles the dual-condition machinery that makes the whole thing work. If you're here because you found this pack on GitHub and want to restore or upscale some damaged photos, this is where you start.
LucidFlux itself (W2GenAI Lab, arXiv 2509.22414) is a "caption-free universal image restoration" diffusion transformer. The caption-free part is the selling point: you don't write a prompt. You hand it a degraded image and it restores it, using a second condition branch that injects the low-quality input's structure at every denoising step. That's why the output of this node isn't a plain ComfyUI model - it's a bundle that carries both the transformer and the dual_condition_branch the custom sampler needs.
The inputs that matter
Here's the thing to understand before you start: the pack's author, smthemex, is a prolific researcher-to-ComfyUI porting machine, and the README is terse. The example workflow in the repo is your best friend, because the node layout is specific. The pieces you need to assemble:
- LucidFlux: the restoration checkpoint itself,
lucidflux.pth, sitting inmodels/LucidFlux/. This is where thecondition_lq,condition_ldr, and modulation weights live. - diffusion_models: any FLUX.1 dev dit - the official one, KJ's fp8, whatever you already run. The node reads the filename to decide whether you're on dev or schnell, so keep "dev" in the name. Name it
flux1-devand it runs the dev schedule; leave it out and it'll run the schnell schedule and look wrong. - block_offload: default on, and you probably want it on. It's a 12B transformer; keeping it on CPU and streaming blocks to the GPU is what makes this run at all on consumer cards. Flip it off only if you've got a 24GB+ card and want the speed.
- model_type:
bf16orf32. bf16 is the default and is what you want unless something's acting up. - cf_model (optional): a MODEL input - if you've already got a Flux loaded in your graph, feed it here instead of a file. The node detects dev vs schnell from the state dict keys, so this path skips the filename guessing game.
The output, model, feeds straight into LucidFlux_SM_Cond (if you're using the Turbo LoRA) and then LucidFlux_SM_KSampler. It's not the image, it's the engine.
Install
Install, the real way:
cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_LucidFlux
cd ComfyUI_LucidFlux
pip install -r requirements.txt
Or search "ComfyUI_LucidFlux" in ComfyUI Manager. Either way, restart ComfyUI afterwards. Then the model downloads - this pack eats bandwidth. You need lucidflux.pth, prompt_embeddings.pt, and lucid_connector.pth from Hugging Face (W2GenAI/LucidFlux, smthem/LucidFLUX-connector), a Flux dev dit, ae.safetensors from Comfy-Org, and the SigLIP vision encoder. That's before you touch the 4K PiD path.
Where people get burned
Where people get burned: the OOM reports. A user on a 5090 hit instant OOM when they wired a text encoder into the encode stage - the fix is to use the precomputed prompt_embeddings.pt and not connect a CLIP encoder, which the README warns about in Chinese and everyone skips. Keep block_offload on, use the precomputed embeddings, and the "runs on 8-12GB" claims start to hold up. This node is the least glamorous part of the pack, but it's also the one most likely to be the reason your workflow dies at step one.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| LucidFlux | COMBO | 1 options: none | |
| diffusion_models | COMBO | 1 options: none | |
| block_offload | BOOLEAN | true | — |
| model_type | COMBO | 2 options: bf16, f32 | |
| cf_modelopt | MODEL | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| model | MODEL | — |