DPMSolverMultistep add rescale_betas_zero_snr#7097
DPMSolverMultistep add rescale_betas_zero_snr#7097yiyixuxu merged 7 commits intohuggingface:mainfrom
rescale_betas_zero_snr#7097Conversation
| self._init_step_index(timestep) | ||
|
|
||
| # store old dtype because model_output isn't always the same it seems | ||
| return_dtype = sample.dtype |
There was a problem hiding this comment.
do you mean model_output.dtype isn't always the same as sample.dtype before the upcast?
There was a problem hiding this comment.
Turns out that was because model_output = self.convert_model_output(model_output, sample=sample) ends up creating a shadowed tensor cast to the sample's dtype. I moved the sample upcast after this call so return_type is no longer needed. Outputs are the same.
yes separate issue please:) |
Avoids having to re-use the dtype.
|
can you fix the quality test? |
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
|
Alright I added a single newline. |
|
thank you! |
Have we created a separate issue for ZeroSNR + Karras? |
4 participants
Effectively identical to the implementation for EulerDiscrete in #6024
TL;DR:
rescale_zero_terminal_snrfunction copied from DDIM2**-24from0when using zsnr so it doesn't produce aninfsigmatorch.float32for the duration ofstep()because the zsnr sigmas are substantially less numerically stable and the performance hit is negligible.use_karras_sigmas=Truestill produces strange results as it does in EulerDiscrete. Might be worth investigating separately?Demo images
use_karras_sigmasalso seems to just generally produce bad/noisy results even without ZSNR so I might not have the config set up correctly?