"Nan" in StableDiffusionXLPipeline's vae encoder

[tuning12]

When I use the vae encoder of StableDiffusionXLPipeline to encode an image of [B, 3, 1024, 1024], the latents output is "Nan" value. Is there any solutions?

        pipe = StableDiffusionXLPipeline.from_pretrained("stabilityai/stable-diffusion-xl-base-1.0", torch_dtype=torch.float16, use_safetensors=True, variant="fp16").to("cuda")
        vae = pipe.vae
        input_dtype = imgs.dtype
        imgs = imgs * 2.0 - 1.0
        posterior = vae.encode(imgs.to(weights_dtype)).latent_dist
        latents = posterior.sample() * self.vae.config.scaling_factor

[yiyixuxu]

hi!
you should upcast both your image and vae to full precision for the encoding

[tuning12]

hi! you should upcast both your image and vae to full precision for the encoding

Thank you for your reply!

[Vishawjeet-rmsl]

hi! you should upcast both your image and vae to full precision for the encoding

Hi, What do you mean? I've been trying to set up GLAD (https://github.com/hyao1/GLAD?tab=readme-ov-file) on my system, and I keep getting 'nan' values from the

latents = pipe.vae.encode(
            batch_image.to(dtype=weight_dtype)).latent_dist.sample() * pipe.vae.config.scaling_factor

the weight_dtype is torch.float16, the same as the code from GLAD authors. I don't understand why it won't work for me if it's working for them. The only difference is that I'm using a Windows system while GLAD authors have used Linux system.

[asomoza]

the SDXL VAE its the only one that has this problem, it is a know issue, other models don't have this problem. Don't know about what you're using but if you get NaNs with that software you should open an issue there.

[x2x5]

the SDXL VAE its the only one that has this problem, it is a know issue, other models don't have this problem. Don't know about what you're using but if you get NaNs with that software you should open an issue there.

Do you mean that SDXL's VAE encoder must use float32, while the decoder can use float16?

[asomoza]

Do you mean that SDXL's VAE encoder must use float32, while the decoder can use float16?

No, the original VAE for SDXL has this problem with encoding and decoding, it overflows, this is a known problem pretty much from release, so some people started using the 0.9 VAE, but later madebyollin created this one that is pretty much the standard nowadays, if you can generate in fp16 without NaNs (black images) pretty much means that the model has this VAE instead of the original one.

Diffusers has automatic upcasting for the original VAE when you use it for inference inside the pipelines but since you're using the encode manually you will need to upcast it yourself.

Why is it working for GLAD? probably because they use it in full precision but I don't really know and sadly I don't have the bandwidth right now to read other libraries code.

If you can reproduce the error with upcasting and using diffusers we will gladly help and try to fix the error.

[Vishawjeet-rmsl]

Do you mean that SDXL's VAE encoder must use float32, while the decoder can use float16?

No, the original VAE for SDXL has this problem with encoding and decoding, it overflows, this is a known problem pretty much from release, so some people started using the 0.9 VAE, but later madebyollin created this one that is pretty much the standard nowadays, if you can generate in fp16 without NaNs (black images) pretty much means that the model has this VAE instead of the original one.

Diffusers has automatic upcasting for the original VAE when you use it for inference inside the pipelines but since you're using the encode manually you will need to upcast it yourself.

Why is it working for GLAD? probably because they use it in full precision but I don't really know and sadly I don't have the bandwidth right now to read other libraries code.

If you can reproduce the error with upcasting and using diffusers we will gladly help and try to fix the error.

I changed the precision from float16 to float32 and GLAD started working for me on my windows system.