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](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Adrian Corduneanu 2025-02-27 18:22:53 -10:00
parent a326079926
commit 7b58015ee8

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