Fix assertion error in UniPC scheduler for high step counts

This fixes an edge case in the FlowUniPCMultistepScheduler where using high sampling step counts (> 50) would cause an assertion error in the last step. The issue was that with lower_order_final=True, the order calculation could become 0 when step_index equals len(timesteps), causing 'assert self.this_order > 0' to fail.

The fix ensures this_order is always at least 1, maintaining stability while allowing higher quality generation with increased step counts.

🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com
This commit is contained in:
Adrian Corduneanu 2025-02-28 22:31:58 -08:00 committed by GitHub
parent a326079926
commit fea47e70f7
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -710,9 +710,9 @@ class FlowUniPCMultistepScheduler(SchedulerMixin, ConfigMixin):
self.timestep_list[-1] = timestep # pyright: ignore
if self.config.lower_order_final:
this_order = min(self.config.solver_order,
this_order = max(1, min(self.config.solver_order,
len(self.timesteps) -
self.step_index) # pyright: ignore
self.step_index)) # pyright: ignore
else:
this_order = self.config.solver_order