LFM2.5 error

#2
by pyspilf - opened

Hi Benny! Huge fan of Z-Engineer. I’m running AMD ROCm (Ryzen AI HX470 + 28GB GTT) and just cloned both ComfyUI-Z-Engineer and ComfyUI-GGUF fresh today as suggested in your docs.
When loading LFM2.5-1.2B-Z-Image-Engineer-V4-Q4_K_M.gguf via the Z-Engineer Prompt Enhancer (Local) node, I get this error:
ValueError: Unexpected text model architecture type in GGUF file: 'lfm2'
The stack trace shows it's failing inside ComfyUI-GGUF/loader.py at the architecture check, even though I'm using your dedicated Z-Engineer loader node. It seems the lfm2 arch isn't mapped yet in the underlying GGUF loader?
Is there a working branch or patch I can test on AMD hardware? Happy to validate any fixes!

oh i added that just for you πŸ™‚ fixed up!

just pushed v2.2.0 of ComfyUI-Z-Engineer with proper LFM2.5 support β€” git pull in custom_nodes/ComfyUI-Z-Engineer (or reinstall from GitHub) and restart. two new nodes:

  • Z-Engineer LFM2.5 Enhancer Loader (GGUF / Safetensors) β€” point it at your Q4_K_M (any quant works, or the repo's safetensors/ folder)
  • Z-Engineer Prompt Enhancer (LFM2.5 Local) β€” wire the loader's llm output in, the V4 system prompt is already the default

good news for your setup: this path doesn't go through ComfyUI-GGUF (or llama.cpp) at all β€” the GGUF gets dequanted straight into transformers and runs on plain torch, so ROCm works out of the box. only requirement is transformers>=4.54 in your ComfyUI venv (that's when LFM2 support landed). ~2.5GB in fp16, easy fit in your 28GB GTT.

one thing to be clear about: LFM2.5 can't be used as the text encoder. Z-Image Turbo's conditioning comes from Qwen3-4B and ComfyUI has no lfm2 encoder path β€” that's the real reason you hit that ValueError. so this model writes the prompt, and the CLIP stays a Qwen3-4B model (my Z-Image-Engineer via the Z-Engineer CLIP loaders, or the stock encoder). the CLIP loaders now tell you exactly that if you point them at an lfm2 file, instead of throwing the cryptic arch error.

would love to hear how it runs on your Ryzen AI box β€” V4 was trained on an AMD Strix Halo, so it's practically home turf πŸ˜„ (registry/Manager version will catch up shortly)

update: dropped a ready-made workflow in the repo so you don't have to wire anything β€” example_workflows/z_image_turbo_lfm25_enhancer.json (after updating, it also shows up in ComfyUI's template browser under Workflows β†’ Browse Templates β†’ ComfyUI-Z-Engineer).

LFM2.5 writes the prompt β†’ Z-Image-Engineer-V6 GGUF encodes β†’ Z-Image Turbo renders. just ran it end to end on my box to make sure πŸ‘

Wow, Benny, thanks so much! I will update, test and let you know.

The machine is 32GB LPDDDR5X. The OS on my HX470 is Ubuntu. I optimized it as much as I could (including GTT and IOMMU in grub) to run llama.cpp with Vulkan decently. I was able to get Qwen3.6-35B-A3B running with 128k context at 30+ t/s and really making use of the GTT pool... when running it sits stable at 3.8 of 4 GB VRAM and 22 of 28GB GTT used... all nice. I expected good performance from ComfyUI too.

I run ComfyUI in a docker to avoid polluting my main OS and filesystem... man, what a journey... little did I know. I had no idea the ROCM backend would behave like that. After uncountable OOMs, crashes, dmesg logs showing extreme memory pressure, cpu hogging, SVM, HIP... I learned so much more than I ever wanted...

So, conclusion, for ComfyUI to be happy, I need to run models at fp8. No amount of flags or environment settings could contain the unbound aggressive memory allocations happening with mixed precision operations.

All this was just so you could imagine my reaction when I saw the Z Image Engineer v6 GGUF take like 20 minutes in ComfyUI to generate a prompt... I can run the same model on a puny Intel N150 with llama.cpp and get 4-5 t/s... very slow yes, but with your API node I was getting my prompt back in ~70-75" instead of 20', and that was excellent. I know all this is down to how ROCM handles the UMA pool on this machine, so none of this is any criticism to you at all. Quite the contrary, I am very grateful for being able to use what you built.

As mentioned, I will try it and let you know.

One thing I was meaning to ask: both with the LFM and Qwen GGUFs from you repo (on llama.cpp for now), the response very frequently ends with 'the composition explicitly mentions...' - is this intended behavior? And it sometimes hallucinates things, but I do acknowledge it is a 4B model, and indeed the prompt gets expanded very nicely. A few minor manual adjustments are very OK when the prompt comes back.

Example: my prompt in the Z Engineer API node against V6 running on llama.cpp with node at default settings

PROMPT: A black cat is sleeping curled in a basket in an old english cottage living room by a fireplace, while it is snowing outside

RESPONSE: A black cat is sleeping curled in a basket in an old english cottage living room by a fireplace, while it is snowing outside. The scene is lit by warm candlelight and the glow of the hearth fire, casting long shadows across the wooden floor. Snowflakes gently drift through the air, catching the light as they fall from the high window. The foreground features a plush velvet armchair with intricate carvings, while the midground reveals the cozy interior with antique furniture and framed photographs on the walls. In the background, snow-covered evergreen trees stand outside the large glass panes, adding a serene winter atmosphere to the intimate setting. The composition emphasizes the quiet stillness of the moment, with the cat as the central subject, its soft fur contrasting against the textured wood and warm tones of the room. The lighting creates a rich contrast between the dark interior and the bright, sparkling snow outside, enhancing the sense of warmth and tranquility. The overall mood is peaceful and nostalgic, evoking a sense of comfort and solitude during a quiet winter evening.

This results in an image generation with snow inside the room. I think it is down to me needing to be a bit more specific, once I understand how the model behaves. I will try the LFM2.5 one locally now

Also, when testing against a local llama.cpp instance on a separate machine in my LAN, using a different llama server client comfyui node, returns the prompt generally in 40-50" as opposed to 70-75" when using the Z Engineer API node. Perhaps the way the request is sent negates some of the caching? I am happy to test further if I can be of help.

Cheers and thanks again

Hi again Benny, it works :))) but unfortunately this machine, despite any and all attempts to optimize its performance, is very poor (at least in my case with Ubuntu and ROCM) - while I can even get a fast-ish response from LFM on a tiny Intel N150, the same model running with ComfyUI for inference is very very slow... I suppose until ROCM gets better this is just the way it is. Your Strix Halo should be 2-3x the speed of mine, yes? so if for me it is super slow, how does it work for you? What OS are you using?

Sign up or log in to comment