WeeLLM Generate

This is the node that actually makes the picture. WeeLLM Generate sits downstream of the WeeLLM Loader and turns its cached pipeline into images - on hardware that, by every rule of thumb you've read, shouldn't be able to run a 12B model at all. The Loader is the engine trick; this is the steering wheel.

It's really three nodes hiding behind one. Watch the image socket and the node changes personality on its own:

• no image connected → text-to-image
• image connected → image-to-image
• image + mask_image connected → inpainting

That auto-switching is the entire reason to reach for it. You get t2i, i2i, and repainting from the same three-node setup, all running under the layer-streaming engine so a 4 GB card can carry FLUX.1-schnell at full bf16 precision - no GGUF, no fp8, none of the usual low-VRAM ladder.

What you'll actually set

• prompt - the star. Multiline, so don't fight it.
• num_steps - defaults to 4, and that's not arbitrary: the default loader model, FLUX.1-schnell, is a distilled 4-step model, so more steps mostly buys you nothing but waiting. Slow node, short step count - respect the default.
• negative_prompt - the tooltip says it plainly: leave empty if the model doesn't support it (e.g. FLUX). Schnell is trained without negative guidance, so a long negative prompt is dead weight there. It only gets passed to the pipeline when it's non-empty, so an empty box costs nothing.
• guidance_scale and image_guidance_scale - both default to -1, which the code translates to "use the pipeline's own default." Handy because the right CFG differs wildly between architectures, and -1 means you never have to know. Only set them if you're chasing a specific look. image_guidance_scale exists for InstructPix2Pix-style edit models; ignore it otherwise.
• height / width - 1024×1024 default, step 8, up to 8192. Schnell is happiest at 1024; don't push a 4 GB card to the top of the range and expect speed.
• seed - for reproducibility. strength (default 0.8) only does anything when an image is connected - it's the i2i/inpaint denoise amount.

The output is a single IMAGE, wired straight into Save Image or anything downstream that takes a picture.

How it behaves in the workflow

Mechanically it's thin on purpose: it bundles your settings, hands them to the cached pipeline from the Loader, and returns the first generated frame as a ComfyUI tensor. Two touches worth knowing - it drives ComfyUI's real progress bar (so the cancel button actually stops a generation instead of just gray-screening you), and it converts between ComfyUI tensors and the PIL images the weellm engine expects. That conversion means masks must come in as ordinary IMAGE tensors, not as the mask tensors some ComfyUI nodes output natively - if your mask looks wrong, check you're feeding a grayscale image, not a mask channel.

Installing it

Same pack as the Loader - ComfyUI Manager, search ComfyUI-WeeLLM, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/Jit-Roy/ComfyUI-WeeLLM.git
cd ComfyUI-WeeLLM
pip install -r requirements.txt   # pulls the weellm library + a pinned diffusers

Where people get burned

The biggest trap is a mismatch between this node and the Loader's task setting. If the Loader was set to text-to-image but you connect an image here anyway, you're asking a t2i pipeline to do img2img and it can error or silently ignore the image. Keep them in sync: i2i/inpaint means the Loader should be on image-to-image.

The other thing to internalize: this is a slow path by design. Layer streaming trades VRAM for wall-clock time, so a generation that takes 20 seconds on a quantized 8 GB setup can take two minutes on a 4 GB card. It's for making the impossible possible, not for iteration. If you own the VRAM, GGUF Q8 is still faster. If you own a 4 GB card and nothing else, this is one of the few ways to see FLUX at all.