LCM Sampler (Advanced)

This is the plain LCM Sampler with the training wheels off in one specific way: instead of typing your prompt into a text box, you wire in a conditioning input - the same CONDITIONING type any CLIPTextEncode node produces - and instead of a finished image, you get back a raw LATENT. Same trick underneath (a diffusers pipeline running the LCM_Dreamshaper_v7 checkpoint in 4-8 steps instead of the usual 20-50), just plugged into the rest of a normal ComfyUI graph instead of standing alone.

Quick context if you're new to LCM: it's a distilled Stable Diffusion checkpoint, trained to predict a finished denoise in a handful of steps rather than iterating through dozens. This whole pack predates ComfyUI's native LCM scheduler - the README says so directly, and points you at the official implementation now that it exists. Even so, this is still the simplest way to get this exact behavior (one checkpoint, one diffusers pipeline, no LoRA to go find), and the Advanced variant is the one worth reaching for the moment you want to do anything beyond "prompt in, image out."

Why CONDITIONING instead of a string

The plain LCM_Sampler only takes raw text, which rules out conditioning combine, per-region prompting, prompt weighting - anything you'd normally build with ComfyUI's text-encoding nodes. This node takes a conditioning input instead, so you build your prompt the usual ComfyUI way - CLIPTextEncode, ConditioningCombine, whatever your workflow needs - and hand the result in here. You'll need a CLIP model loaded somewhere upstream to produce it; any SD1.5-family CLIP works, since LCM_Dreamshaper_v7 is SD1.5-based under the hood.

Why LATENT instead of IMAGE

Getting a LATENT back instead of a finished image means you can keep working in latent space before you commit to pixels - chain another sampler, latent-upscale it, whatever the workflow calls for - then decode with a VAEDecode node whenever you're ready to look at it. The plain LCM_Sampler decodes internally, which is convenient for a quick test but a dead end the moment you want to build something bigger around it.

The rest of the inputs

Same knobs as the base sampler: seed, steps (default 4, built for the 4-8 range - going past that doesn't buy quality, just artifacts), cfg (default 8 in the widget, but LCM's guidance is already baked in from distillation, so keep it around 1-2 or you'll get oversaturated, over-contrasty results), width/height (512-768, SD1.5-class), num_images for batching, and use_fp16 - leave it on for the low VRAM footprint this node is known for.

Installing it

git clone https://github.com/0xbitches/ComfyUI-LCM into custom_nodes/ and restart, or search "Latent Consistency Model for ComfyUI" in ComfyUI Manager. No manual model download needed - LCM_Dreamshaper_v7 pulls automatically from HuggingFace into your local cache on first run, so expect your first generation to pause while it fetches a few gigabytes.

Where people get stuck

The known tokenizer error from the README - Non-consecutive added token '<|startoftext|>'... - comes from a mismatched cached tokenizer version and is fixed by hand-editing added_tokens.json in the HF cache folder; the README has the exact replacement to paste in. If your conditioning input comes from a CLIP model that isn't SD1.5-compatible, expect a shape mismatch rather than a helpful error message - this node's internal pipeline is built around Dreamshaper v7's SD1.5 architecture, not whatever checkpoint you happen to have loaded elsewhere in the graph. And because this pack pulls in diffusers directly rather than reusing ComfyUI's model stack, a shared Python environment with other diffusers-based custom nodes is a real place for version conflicts to creep in - worth remembering if something that worked yesterday suddenly throws an import error after installing something unrelated.