ZImageLoraModelOnly☀

Z-Image is Alibaba's 6B S3-DiT image model, Apache-2.0, small enough to run on a 12GB card, and the community's current pick for SDXL's successor. It's also the one model where your old LoRA habits quietly break: a plain LoraLoader grabs a Z-Image LoRA, finds no matching keys, and applies nothing while reporting success. ZImageLoraModelOnly is the fix for that specific trap, and it's worth keeping in every Z-Image pipeline.

Why Z-Image LoRAs don't just load

Z-Image uses fused QKV attention. Its checkpoints expect a LoRA keyed like .attention.qkv.lora_A.weight. But the standard Z-Image LoRA files that ai-toolkit and friends produce store the adapter the other way: separate .attention.to_q.lora_A.weight, .attention.to_k.lora_A.weight, and .attention.to_v.lora_A.weight entries. A generic loader looks for the fused key, finds nothing, and either errors out or - worse - runs with the LoRA doing nothing while the UI shows everything went fine.

This node, a subclass of ComfyUI's built-in LoraLoader, was rewritten from PGCRT/CRT-Nodes' LoraLoaderZImage.py to close that gap. When it runs it walks every key in the safetensors, groups the q/k/v pairs per attention block, concatenates the A matrices, and builds the fused B matrix as a block-diagonal so Q, K, and V land in the right slices. It also remaps .attention.to_out.0. to .attention.out. and passes everything else through. Then it applies the result with CLIP set to None and clip strength pinned at zero - model branch only.

That last part is a feature, not a limitation. Z-Image's text encoder is a frozen Qwen3-4B, so a text-encoder LoRA isn't a thing you want anyway. The node only exposes what it touches.

The inputs you actually set

• model - wire this from your Z-Image checkpoint or diffusion-model loader.
• lora_name - a dropdown that reads your loras folder, same as any loader.
• strength_model - default 1.0, and it's a wide range (-100 to 100) so you can push hard or go negative if you're experimenting.

Output is a single MODEL, which feeds straight into your sampler. There's no CLIP output, no strength_clip - the node's whole point is that it doesn't touch the text encoder.

Install and gotchas

Install is standard for this pack: ComfyUI Manager, search "DashuaiTools", or

cd ComfyUI/custom_nodes
git clone https://github.com/Hasasasa/ComfyUI_DashuaiTools

then restart ComfyUI. Dependencies are light - just scikit-image and google-genai from the pack's requirements, and neither is needed just to run this node. You'll see the pack's 🌞 DaShuai Tools banner on startup; the trailing ☀ in every node name is just branding.

Where people get burned:

• The LoRA still does nothing. First suspect is a Z-Image LoRA trained in a non-standard format, or a LoRA that isn't actually for Z-Image. This loader handles the common ai-toolkit format; it won't magically fix a mistrained adapter.
• Train vs. run mismatch. Community wisdom is to train on the undistilled Z-Image Base and run on Turbo - base-trained LoRAs keep skin texture on Turbo but underperform when run on Base itself. If the LoRA looks weak, check which checkpoint you trained against.
• This is Z-Image-only. Feed it an SDXL or Flux LoRA and the QKV fusion just passes keys through; it'll load but it's not the tool for that job.

For Z-Image work this is the dedicated LoRA entry point in this pack, and once you've hit the silent-failure case above, you'll never want to debug a generic loader again.