Z-Engineer CLIP Loader (GGUF)

Z-Image-Engineer isn't the checkpoint - it's the prompt model that stands in front of Z-Image, a Qwen3-4B that doubles as the text encoder. And like every text encoder since Flux's T5, you don't have to run it at full precision. This loader is how you run it as a GGUF quant and leave VRAM for the part that actually draws.

The Z-Engineer CLIP Loader (GGUF) takes a llama.cpp-style GGUF of Z-Image-Engineer-V6 from models/text_encoders and hands you a plain clip output that plugs into your normal CLIP Text Encode. The whole point of the pack is that the same model does two jobs - encode your prompt and write a better one first - and this is the low-VRAM half of that story.

How it works

Pick the file from the gguf_name dropdown, and the loader does the rest. If you have ComfyUI-GGUF installed (city96's node pack, the standard for quantized diffusion), it loads through that for on-the-fly dequantization - the quant stays quantized in VRAM, roughly 3–4 GB for Q4_K_M. If ComfyUI-GGUF isn't there, it falls back to dequantizing the whole thing to FP16 at load time via its own gguf_fallback path, which remaps llama.cpp tensor names to the HuggingFace layout ComfyUI expects. That fallback works, but it's the trap: you've loaded a quantized file and ended up with the full ~9 GB FP16 footprint anyway. You saved disk space, not RAM.

The device input (default or cpu) is an advanced setting - leave it alone unless you're explicitly forcing CPU. Weights start on the offload device and only move to GPU on first use, so loading never spikes VRAM, and the model joins ComfyUI's normal model management (it unloads like any other model).

The one choice that matters: which quant

Only one required input, so the real decision is the file. The README's guidance matches the usual GGUF ladder: Q4_K_M is the sensible default, F16 is maximum fidelity. This encoder feeds the prompt, not the pixels, and the community consensus on GGUF holds here too - Q8 is basically fp16 at half the size, Q4_K_M is the accepted compromise for a 12 GB card. If it fits, take a higher quant; if VRAM is tight, Q4_K_M won't be what's limiting your image.

Install

The pack itself is a quick install - Manager search "ComfyUI Z-Engineer," or:

cd ComfyUI/custom_nodes
git clone https://github.com/BennyDaBall930/ComfyUI-Z-Engineer.git
pip install -r ComfyUI-Z-Engineer/requirements.txt

Restart ComfyUI. Then you need two more things: the model file (any quant from BennyDaBall/Z-Image-Engineer-V6-GGUF) dropped into ComfyUI/models/text_encoders/, and ComfyUI-GGUF installed via Manager. You also need a ComfyUI new enough to have native Z-Image support (v0.3.75+).

Where people get burned

• Empty dropdown. The loader scans models/text_encoders (plus clip and clip_gguf) for .gguf files. Wrong folder, or you haven't refreshed, and the list is bare.
• The "requires the gguf package" error. That's the fallback path firing with no ComfyUI-GGUF and no gguf installed. pip install gguf patches it, but installing ComfyUI-GGUF is the real fix.
• Fallback mode eats VRAM. If you skip ComfyUI-GGUF, expect the FP16 footprint. At that point you'd get the same from the Safetensors/Shards loader, so there's no reason to go GGUF without it.
• ComfyUI too old. A loader that works but a CLIP Text Encode that won't take a Z-Image model usually means your ComfyUI predates native Z-Image support. Update.

Wire clip into CLIP Text Encode for the Turbo pipeline - and if you want the same model to write your prompt first, run that same clip into the Z-Engineer Prompt Enhancer (Local). One model, both jobs.