I just want to address this and your other comments as they are factually incorrect. While you can run FP16 fine, FP32 is not "filled with junk data" -- If you convert an FP16 to FP32 it will not increase anything but the size as the increased precision cannot be generated. With that said however if you are training FP32, and using FP32, it maintains actual used data. The reason this is FP32 is that it IS FP32. It can be converted to FP16 with loss, but it is not an FP16 model. You should avoid providing factually incorrect information as it will lead to propagation of misinformation.

@Disty0 Thanks for the clarification there -- I only had the original diffusers so didn't even know there was an FP16 release. With that said my training workflow is all switched to FP16 now, so v0.3 will be trained and released in FP16 exclusively. Also yes, I really should add an FP16 version for v0.2, just been preoccupied with training woes.

@MrNoir That gets even more complicated -- While the v0.1 and 0.2 are full FP32, v0.3 and onward are different. For unet I'm maintaining FP16 weights, for the text encoders (which I am actively training unlike, to my knowledge most others training at this time [with good reason, they're a pain]) I'm using FP32 weights (I may still pull this down to FP16 in future). With that said however, there's model weights and training precision, as well as more data types for each, all with their own tradeoffs. There's no one right answer, but frankly from my testing, if you use FP16 or BF16 you're going to be fine, you don't generally need the precision of FP32, and I am not seeing the value of it vs the overhead in time and vram required to use it. With that said, BF16 while possibly better is problematic with some optimizers.