UltraFlux_SM_KSampler

UltraFlux is one of those "native 4K text-to-image" models that's real but quiet - a Flux-based derivative from W2GenAI-Lab (arXiv 2511.18050) that samples directly at up to 4096×4096 instead of upscaling. Its companion UltraFlux_SM_Model node loads the transformer and VAE and hands a pipeline to this node, which does the actual sampling. If you're used to KSamplers that cheerfully reject anything past 2K, this one's default of 4096×4096 tells you everything about what it's for. It will absolutely fill your VRAM, but that's the point - the whole design is about making 4K sampling not-ridiculous on consumer hardware.

How it works

This isn't ComfyUI's native sampler stack. The node takes the CONDITIONING you already produced (with a normal DualCLIPLoader → CLIPTextEncode, flux type), converts it into diffusers prompt_embeds, and runs a bundled FluxPipeline with a max sequence length of 512. The clever part is block-level offloading: it applies apply_group_offloading to the transformer, shuffling groups of blocks between GPU and CPU/RAM during sampling. That's why the README pushes the BF16 GGUF - when blocks live in system RAM half the time, memory size beats quantization cleverness.

Before sampling it also unpatchs whatever models ComfyUI currently has cached and empties the VRAM cache. Good for giving UltraFlux room, mildly rude to the rest of your workflow - anything you had loaded will be reloaded from scratch afterward, so don't slot this mid-pipeline next to other heavy generations and expect them to stay warm.

The inputs that matter

• pipeline - from UltraFlux_SM_Model. Non-negotiable, custom type.
• lora1 / lora2 + lora_scale1/2 - up to two LoRAs from ComfyUI/models/loras. Turbo LoRAs are basically expected here (that's why steps defaults to 8); the author warns style LoRAs can degrade output and recommends a hand-fix LoRA for characters.
• cond - your CLIPTextEncode output (T5 + CLIP-L, Flux flavor).
• width / height - default 4096 each. Both floor at 512, step by 16. This is the model's party trick; if you're OOM-ing, coming down to 2048 or using a narrow aspect ratio (it was explicitly trained across them) is the sane first move.
• steps - 8 default, turbo-style. guidance_scale - 4 default. seed - standard.
• block_num - the VRAM knob. It's how many transformer blocks stay resident per offload group. Default 10; on 8GB cards the author says drop it, on 4GB start from 1 and climb until it fits. Lower = slower, but it's the difference between running and not.
• noise - denoise strength when you feed a latent. That's the i2i mode ("加噪伪超分" in the README - a noise-based pseudo-upscale): drop an input image to ~512, VAEEncode it, plug it in here, and let UltraFlux re-render it big. The example workflow uses 0.55.

Output: a single image tensor, ready for SaveImage or whatever follows.

Installing it

Same as its sibling - one pack, two nodes. ComfyUI Manager → search "ComfyUI_UltraFlux", or:

cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_UltraFlux

Then restart. No meaningful extra Python dependencies (torch/transformers/accelerate/diffusers are already in ComfyUI). Models: the BF16 or Q8 GGUF from smthem/UltraFlux-v1-gguf into ComfyUI/models/gguf, the UltraFlux VAE from Owen777/UltraFlux-v1 into ComfyUI/models/vae, and stock t5xxl_fp8_e4m3fn + clip_l for the text encoder.

What trips people up

Besides VRAM (see block_num), the big gotcha is patience: first run loads and offloads a multi-gigabyte transformer and can look hung. If you get an error about a missing VAE, that's the UltraFlux_SM_Model node, not this one. And if your output comes out flat when a style LoRA is loaded, that's the known degradation issue - swap it for a turbo or hand-fix LoRA before you start blaming your prompt.