L2P Z-Image Pipeline Loader

Every pixel-space workflow in ComfyUI looks broken on first sight. You open it, scan the graph for a VAE loader and a CLIP loader, find neither, and assume the author forgot half the nodes. They didn't. A no-VAE model has nothing for those loaders to load, and this node - L2P Z-Image Pipeline Loader - is the one loader that does exist. Point it at three model files and it builds the entire L2P Z-Image pipeline, then hands it to L2P Z-Image Generate as a single pipeline wire.

What it's loading: the L2P checkpoint itself (a pixel-space conversion of Alibaba's 6B Z-Image Base - no VAE, the DiT predicts pixels directly), the Qwen3-4B text encoder, and the Z-Image-Turbo tokenizer. It uses a bundled diffsynth runtime adapted from the public L2P Hugging Face Space, so this isn't ComfyUI-native support - it's a self-contained copy of the model's own inference code. That's also why the first load is slow: the checkpoint alone is around 20GB on disk, and the loader pins the whole thing together before generation can start.

The dropdowns that matter:

• model_name - lists models/diffusion_models. The workflow expects the file named Z-image-6b-no-VAE.safetensors; the Hugging Face file is actually called model-1k-merge.safetensors, so follow the README's rename step or the name mismatch will bite you.
• text_encoder_name - lists models/text_encoders; pick qwen_3_4b.safetensors.
• tokenizer_name - the one that trips people up. The loader scans models/text_encoders for folders containing tokenizer_config.json and shows them as relative names like Z-Image-Turbo-tokenizer/tokenizer. Put the four tokenizer files in the right subfolder or this dropdown has nothing to offer.
• device (cuda/cpu) and dtype (bf16/fp32) - leave both on the defaults (cuda, bf16) unless you're CPU-bound, in which case fp32 is the safer bet.

Under the hood it calls the pipeline's from_pretrained with those three paths and then forces text-encoder offload on, which is how a ~20GB stack stays runnable on a 16GB card. It also caches the built pipeline keyed by the exact model, encoder, tokenizer, device, and dtype - so if you re-run or change only the prompt, you skip the whole re-load. If you change any dropdown, you eat it again.

The single output is a custom L2P_ZIMAGE_PIPELINE type, which means it only plugs into L2P Z-Image Generate. You can't feed it to a KSampler or anything standard - the pack's workflow is loader → generate → preview, and that's the whole envelope.

Install and models

The pack installs once for both nodes:

cd <ComfyUI>\custom_nodes
git clone https://github.com/gjnave/ggf-ltp-zimage.git
cd ggf-ltp-zimage
<ComfyUI>\venv\Scripts\python.exe -m pip install -r requirements.txt

Then restart ComfyUI. ComfyUI Manager finds it by searching "ggf-ltp-zimage" if you'd rather click than type. The requirements pull in transformers, accelerate, safetensors, peft, sentencepiece, and friends - plus huggingface_hub, which is what gives you the hf download CLI the README uses. This is one pack where the README's model-download section isn't optional reading: you need all three pieces in the exact folders it names, or the dropdowns come up empty. The repo includes a starter workflow (ggf_l2p_zimage_6b_no_vae.json) pre-wired with the expected file names, so if you follow the renames you can just hit Run.

Troubleshooting

• tokenizer_name is empty or shows machine paths - you placed the tokenizer files outside models/text_encoders, or the loader is showing a relative path you need to match. The dropdown only scans that one folder tree.
• First run "hangs" for minutes - that's the 20GB checkpoint loading, not a dead node. The loader is doing a lot; be patient once.
• Generation crawls even after loading - expected. Pixel-space models pay compute proportional to pixel count, and the L2P conversion is a research model, not a speed demon. On 8GB cards with offloading, community reports put generations in the tens of minutes even at 512×512. If you came here expecting Z-Image Turbo's 30-second gens, this pack is the wrong tool - Turbo is the fast, latent, VAE'd one; this is the "no VAE at all" one.

That last point is the real thing to internalize: this loader exists because someone wanted the pure pixel-space experiment in ComfyUI, and gjnave (the GetGoingFast packaging behind getgoingfast.pro) wrapped it for the rest of us. It works. It's just not quick about it.