SDNQ Sampler

The SDNQ Sampler is the one node in comfyui-sdnq you'll actually use, and it's a different beast from what you're used to in ComfyUI. Instead of the usual graph - checkpoint loader, CLIP, VAE, sampler, decode - it's a single box that loads a pre-quantized model, downloads it if you don't have it, runs the denoise loop, and hands you a finished image. Drop it in, pick a model, type a prompt, hit queue. That's the whole pitch, and it genuinely works.

Why would you want that? Because the model list is the draw. Thirty-plus pre-quantized builds of FLUX.1, FLUX.2, Qwen-Image, Z-Image, SD3.5, even LTX-2 video, all hosted by Disty0's SDNQ collection. The quantization is SDNQ, Disty0's own engine that registers itself into diffusers via an import side effect - the pack's own source literally calls from sdnq import SDNQConfig to hook in. The node then loads through DiffusionPipeline.from_pretrained, which is why it can swallow FLUX and Qwen and Z-Image alike without caring what architecture they are. This is diffusers running inside ComfyUI, not ComfyUI's native loaders.

That's also the catch, and you should know it before you fall in love: it's a walled garden. You can't wire your own VAE, CLIP, or ControlNet into it, and your LoRAs go through the node's own dropdowns, not the ComfyUI LoRA loader. What you get in return is VRAM relief - the advertised 50-75% saving is in the right ballpark for the uint4 builds - plus zero setup for models that would otherwise take you an afternoon of GGUF hunting. It's the "I just want to see what FLUX.2 looks like" node. There's a case to use it forever; there's also a case to treat it as a demo and graduate to a native workflow when you outgrow it.

The inputs that matter

The dropdown list is long, so start with the sensible defaults rather than reading everything:

• model_selection - 31 pre-configured models, each auto-downloaded from HuggingFace on first use. FLUX.1-dev-SDNQ-uint4 or Qwen-Image-SDNQ-uint4 are safe first picks. [Custom Path] plus custom_model_path lets you point at a local diffusers directory if you'd rather manage downloads yourself.
• prompt / negative_prompt - self-explanatory, but note the tooltip: FLUX-schnell runs at cfg 0 and ignores your negative prompt entirely. Don't be surprised when it does.
• scheduler - the one that bites. The tooltip is emphatic for a reason: FlowMatchEulerDiscreteScheduler for FLUX/SD3/Qwen/Z-Image, DPMSolverMultistepScheduler/Euler/UniPC for SDXL/SD1.5. Wrong family = broken, banded garbage. The default is DPM, so if you're on a flow-matching model, switch it before your first queue.
• memory_mode - gpu (24GB+), balanced (12-16GB, the default), or lowvram (8GB, sequential offload, slowest). Same logic as ComfyUI's own low-VRAM flags: only climb down as far as you need to.
• cfg, steps, seed, width, height, dtype - the usual knobs; bfloat16 is the right dtype for FLUX on a modern card.

Outputs are image (an IMAGE tensor, feed it to any preview/save node) and latent (LATENT, if you want to pass the result on). For LTX-2 video, set num_frames above 1 and you get a batch of frames out.

Install

ComfyUI Manager → search "comfyui-sdnq" → install → restart. Manual:

cd ComfyUI/custom_nodes/
git clone https://github.com/EnragedAntelope/comfyui-sdnq.git
cd comfyui-sdnq && pip install -r requirements.txt

The requirements pull in sdnq>=0.1.7, diffusers ≥0.36, huggingface-hub, safetensors, accelerate, and hf-xet for fast chunked downloads. First model fetch is 5-20GB and lands in ComfyUI/models/diffusers/sdnq/.

Where people get burned

The number-one troubleshooting section in the README is library versions, because it's the real problem. Newest models (FLUX.2-klein, GLM-Image, Qwen-Image-2512, LTX-2) need diffusers built from source:

pip install --upgrade transformers diffusers
pip install git+https://github.com/huggingface/diffusers.git

If you hit a Config has no attribute error, that's exactly this. Slow? Install Triton (pip install triton on Linux, triton-windows on Windows) to unlock the quantized matmul path - the node auto-disables it if Triton's missing. OOM at big resolutions? Toggle enable_vae_tiling and/or drop to a uint4 model. And remember the quantization rule from the broader ComfyUI world: it exists so models fit, not so they're faster - if the full model already fits your card, uint4 buys you little and costs quality in fine details like eyes. Use it when you need it.

It's opinionated, it's a one-shot convenience box, and for running bleeding-edge models on modest VRAM it's the fastest on-ramp there is.