Open bananasss00 opened 3 months ago
Your torch version is cu121. Update it to cu124 version.
Your torch version is cu121. Update it to cu124 version.
same problem with cu124. First generation SD15 - ok, second SDXL,
I attempted to download the latest ComfyUI from https://github.com/comfyanonymous/ComfyUI/releases/tag/v0.1.2. Afterward, I updated ComfyUI and torch+cu124. However, the issue with the SDXL model persists.
I attempted to download the latest ComfyUI from https://github.com/comfyanonymous/ComfyUI/releases/tag/v0.1.2. Afterward, I updated ComfyUI and torch+cu124. However, the issue with the SDXL model persists.
--fp8_e4m3fn-unet
This option is the problem.
I attempted to download the latest ComfyUI from https://github.com/comfyanonymous/ComfyUI/releases/tag/v0.1.2. Afterward, I updated ComfyUI and torch+cu124. However, the issue with the SDXL model persists.
--fp8_e4m3fn-unet
This option is the problem.
The --fast optimization is specifically designed for fp8_e4m3fn. If I disable it, there will be no optimization
I attempted to download the latest ComfyUI from https://github.com/comfyanonymous/ComfyUI/releases/tag/v0.1.2. Afterward, I updated ComfyUI and torch+cu124. However, the issue with the SDXL model persists.
--fp8_e4m3fn-unet
This option is the problem.The --fast optimization is specifically designed for fp8_e4m3fn. If I disable it, there will be no optimization
In fact, the background for introducing that option was to help when loading and using FLUX.1 through the Load Diffusion Model
function. It seems that the CLI option in question had not been tested.
I have already communicated this issue to comfy.
Understood, thank you. It's strange that with this option, SD15 and Flux work normally.
I found that the pony base model works fine with --fp8_e4m3fn-unet
, however other SDXL variants do not.
any updates?
Any updates??
Does the issue persist after using the fixed SDXL vae model?
yes it persists, preview image is already black when the ksampler is running. It does not seem to have to do with the vae, vae encode/decode is running fine with fp8, otherwise pony would have the same problem. I am using the regular fp16 fixed vanilla sdxl vae
If you remove --fast from your Comfyui startup instructions does the issue persist?
No, but the point of this issue is that SDXL is not working with --fast
. Without --fast
things work as normal.
Currently, only pony models seem to work with --fast
, older SDXL derivatives like Juggernaut or StarlightXL do not.
I did some digging and the problem seems related to this function used in forward_comfy_cast_weights
. With only super-limited knowledge of what is going on under the hood I can only speculate we are getting some kind of "out of bounds" error where the available range covered by e4m3 float is not enough to support the range the forward step needs, causing the latent values to be corrupted.
I was hoping to try with e5m2 but this is not supported by cublast as pointed out by knowlegeable people here (thus, it is also not eligible for fp8_linear
and comfyui won't execute the fast path when this dtype is chosen.
I would imagine that, if my speculation is true, we could mitigate the problem by applying some smarter kind of value scaling or maybe just use the possible min/max values should the function yield values exceeding the range covered by e4m3.
I would be happy to help developing / testing this further but I would need some pointers where to look next from someone with deeper knowledge of this context.
Expected Behavior
-
Actual Behavior
SD15 and Flux work fine, the problem is only with SDXL
Comfyu version: https://github.com/comfyanonymous/ComfyUI/commit/bb4416dd5b2d7c2f34dc17e18761dd6b3d8b6ead
Steps to Reproduce
default workflow with SDXL model
Debug Logs
Other
No response