Z-Engineer LFM2.5 Enhancer Loader (GGUF / Safetensors)

Don't let the name fool you

Z-Engineer LFM2.5 Enhancer Loader loads a small language model that writes prompts. It does not, under any circumstances, encode them. Z-Image Turbo's text encoder is Qwen3-4B - that's the thing that turns your finished prompt into conditioning during generation. This node loads LFM2.5-1.2B-Z-Image-Engineer, a 1.2B "prompt engineer" model, so a second LLM sits in your graph and rewrites your rough idea into a polished Z-Image prompt before the real encoder ever sees it.

The community's old habit - host a model in LM Studio, talk to it over an API - was exactly what Z-Engineer existed to kill. This is the local, in-graph version, and this loader is its fast path: the 1.2B LiquidAI-based model is roughly 3x faster than the pack's Qwen3-4B engineer, which matters when you're batch-expanding prompts or living on a 6-8GB card.

Why you'd reach for it

Z-Image rewards a long, structured prompt the way Flux does - natural language, lots of detail, sensible staging and lighting. Writing those by hand every generation is the blank-page problem the KB's LLM-in-the-graph pattern exists to solve. The loader's job is to get a dedicated prompt-writer model into your workflow without an external server, a second process, or a llama.cpp build. It's the machine behind the Z-Engineer Prompt Enhancer (LFM2.5 Local) node.

How it actually works

The source is refreshingly honest about this. The GGUF gets dequantized to FP16 at load (~2.5GB for the 1.2B model) and run through plain torch + HuggingFace transformers - Lfm2ForCausalLM specifically. The pack remaps llama.cpp's tensor names into the HF layout (LFM2 uses the Liquid architecture: shortconv/depthwise-conv blocks, q/k norms, no permutation involved - they verified it numerically), then wraps the result in ComfyUI's own ModelPatcher. That last part is the good bit: the model unloads like any other ComfyUI model, so it doesn't squat on your VRAM between generations. And because it's plain torch, it runs on CUDA, ROCm, MPS, or CPU. AMD and APU folks get the fast path without fighting llama.cpp builds.

The two inputs that matter

The node is nearly empty on purpose. model_name is a dropdown of everything it found under ComfyUI/models/text_encoders/ (or clip/): any GGUF quant of the LFM2.5 engineer, or the HF safetensors folder. That's it, plus an advanced device toggle (default vs cpu) for pushing the writer off your GPU. It has one output, llm, which is a custom ZE_LLM type - it only plugs into the LFM2.5 enhancer node, and that's by design.

Install

Same as the whole pack - 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 grab a quant from BennyDaBall/LFM2.5-1.2B-Z-Image-Engineer-V4 (Q4_K_M is fine) and drop it in:

mkdir -p ComfyUI/models/text_encoders
# ...move your .gguf here

Where people get burned

• The #1 trap: trying to use this as Z-Image's encoder. ComfyUI has no lfm2 encoder path, so the output would be garbage (or a cryptic Unexpected text model architecture type in GGUF file: 'lfm2' from ComfyUI-GGUF). Keep a Qwen3-4B model - the pack's Z-Engineer CLIP loaders, or stock - as your actual CLIP.
• Old transformers: the loader needs transformers>=4.54 for LFM2 support. If it throws, pip install -U "transformers>=4.54" in your ComfyUI venv.
• Not in the dropdown: it only scans text_encoders and clip folders; for the safetensors path it specifically wants a folder whose config.json declares model_type: lfm2. Drop a Qwen3 GGUF in here and it'll refuse with a clear "wrong architecture" message - annoying, but better than silent garbage.