Early support for LoRA training (Turbo) | Prompt Guide
If you're already using SDXL, Flux, or Qwen-based generators, here's the simple version of what Z-Image-Turbo is:
It's a super-fast text-to-image model from Alibaba that spits out 1024×1024 pictures in less than a second on a single high-end card (or a couple of seconds on a 3090/4090). Speed comes from heavy distillation , it’s basically a 6B model taught by much bigger internal beasts, so it feels closer to closed top-tier models than most open-source stuff.
Compared to what you know:
Faster than Flux and SDXL (the SD3.5 Turbo is a bit faster in my testing.)
Better prompt following and prettier results than most current open models
Renders English and Chinese text in images almost perfectly
Currently sitting at #1 on the public human-voted leaderboard (AI Arena Elo)
The model is mirrored here for convenience.
Description
FAQ
Comments (20)
does it work on forge? is text encoder backed in?
I don't know, no, text encoder, vae download links are in the model description, first line
On the fork of Forge called Forge-Neo, a pull request has been submitted by the author. Whilst it's not yet attached on the official update, you can compile the file/code changes and start using it. I had to dust off and update my ComfyUI (not updated since August) and got it working right away and let me tell you, Z image Turbo is legit! Amazing prompt adherence and in only 8 steps.
@PhatSwayze the creator made a branch "Forge-z" https://github.com/Haoming02/sd-webui-forge-classic/tree/z
@PhatSwayze I'm pretty excited for community models, this model seems ways faster than anything I have currently. I'm primarily using flux, illustrious and other sdxl models.
@mphobbit under that path the only branches I see are classic and neo - nothing for z - the url returns a 404 page not found
@JazConPlay178 he merged z with neo.
If you need a model with a built-in VAE and encoder, look for the Z-Image-Turbo-AIO (all in one), they are on the website and work like regular SDXL models.
first time having to ask this, lol:
This scaled fp8 version or BF16, if VRAM isn't an issue?
BF16 => sniper, FP8 => shotgun, precision vs efficiency. if storage is not an issue, consider using both formats. however, keep in mind that text encoders also need to be in BF16 for maximum precision
@sweetmax797 thanks for the explanation :)
Can i chain two advance samplers together and use this zit as the second sampler's model?
yes like refiners uses 2 ksamplers. they need to be compatible tho, i'm not sure if Z is compatible with flux or the rest despite similarity in the architect,
You can, but you have to load in the text encoder and separate CLIP text nodes as well. It will use the same VAE as Flux and SD3 latent.
use bong sampler res_3s_sde with ZiT Schedular , followed by z-image turbo refiner set at defaults
FP8 of Qwen3 text encoder (if vanilla 8 gigs TE freezes your PC) .
https://huggingface.co/jiangchengchengNLP/qwen3-4b-fp8-scaled
will this perform better then the Q6 Gguf?
I read that fp8 is faster then most gguf
@purplelady I compared it with full-size TE. The full-size freezed my VRAM for a while, fp8 is much better.
As I know, in general GGUF slower: it adds steps to ungguf the model before generation. If you have ggufed checkpoint with ggufed TE your pc can freeze for a while (I experimented with FLUX). I'm not a technical specialist and can't give you details, but personally I prefer .safetensors (FP8/NF4) rather than equivalent ggufs.
@mphobbit cool yeah i am noticing something like that i jus thought i was offloading or something, i only have 6 gigs, ill give this a go thanks :D
For those interested in what those numbers are.
They are the floating point format used.
The E4M3FN should be the one used.
At FP8, the floating point only has 256 distinct values
to work with, so that's quite little and one bit is taken by the minus sign. Leaving 128 different values you can store in positive or negative.
So the tradeoff is with bits used as the actual number value, Such as 432 or 112 (called mantissa bits) and bits used to store the place of the decimal point (called exponent bits).
Giving more bits to the exponent means you can output a larger range of values at a loss of numerical precision.
E4M3 means 3 bits are left for the "actual number" and 4 bits for the exponent or position of the decimal
E5M2 means only 2 bits are left for the number and 5 bits for the decimal position to give a higher ranger of final values.
FN means the representation of infinity and Not-a-number were altered to save space.
Therefore, using E5M2 is a serious loss of precision, which is not good for this.
with 2 bits given to the "actual number" it can contain only 4 distinct values as opposed to 8 if you give it three bits. While models will deal with that, the community consensus is the E4M3 is the proper balance and the vast majority of checkpoint authors convert it to that.
The E4M3FN should be the one used.
The only reason you'd ever want the E5M2 is if you already knew this fully and need that one for some technical reason.
Details
Files
zImageTurboFP8Kijai_fp8ScaledE4m3fn.safetensors
Mirrors
z-image-turbo_fp8_scaled_e4m3fn_KJ.safetensors
z-image-turbo_fp8_scaled_e4m3fn_KJ.safetensors
z-image-turbo_fp8_scaled_e4m3fn_KJ.safetensors
z-image-turbo_fp8_scaled_e4m3fn_KJ.safetensors
z-image-turbo_fp8_scaled_e4m3fn_KJ.safetensors
zImageTurboQuantized_fp8ScaledE4m3fnKJ.safetensors
zImageTurboQuantized_fp8ScaledE4m3fnKJ.safetensors
zImageTurboQuantized_fp8ScaledE4m3fnKJ.safetensors
zImageTurboQuantized_fp8ScaledE4m3fnKJ.safetensors