[BUG] FlowMatchEulerDiscreteScheduler.__init__ computes sigma_min/sigma_max after shift, causing duplicate shift in set_timesteps

[Xilluill]

Describe the bug

There is an initialization order issue in the FlowMatchEulerDiscreteScheduler class that causes set_timesteps to apply timestep shifting twice, resulting in different sigma values for the same timestep settings.

diffusers/src/diffusers/schedulers/scheduling_flow_match_euler_discrete.py

Lines 132 to 143 in 07a63e1

	sigmas = shift * sigmas / (1 + (shift - 1) * sigmas)
	self.timesteps = sigmas * num_train_timesteps
	self._step_index = None
	self._begin_index = None
	self._shift = shift
	self.sigmas = sigmas.to("cpu") # to avoid too much CPU/GPU communication
	self.sigma_min = self.sigmas[-1].item()
	self.sigma_max = self.sigmas[0].item()

Then in the set_timesteps method:

diffusers/src/diffusers/schedulers/scheduling_flow_match_euler_discrete.py

Lines 333 to 350 in 07a63e1

	if sigmas is None:
	if timesteps is None:
	timesteps = np.linspace(
	self._sigma_to_t(self.sigma_max),
	self._sigma_to_t(self.sigma_min),
	num_inference_steps,
	)
	sigmas = timesteps / self.config.num_train_timesteps
	else:
	sigmas = np.array(sigmas).astype(np.float32)
	num_inference_steps = len(sigmas)
	# 2. Perform timestep shifting. Either no shifting is applied, or resolution-dependent shifting of
	# "exponential" or "linear" type is applied
	if self.config.use_dynamic_shifting:
	sigmas = self.time_shift(mu, 1.0, sigmas)
	else:
	sigmas = self.shift * sigmas / (1 + (self.shift - 1) * sigmas)

sigma_min will be saved after shift and used to generate a new list of sigma, then there is another shift happening :).

Reproduction

scheduler = FlowMatchEulerDiscreteScheduler.from_pretrained(
os.path.join(model_path, "scheduler"),
)

default scheduler.num_train_timesteps=1000,shift=3.0

print(scheduler.sigmas)
scheduler.set_timesteps(1000)
print(scheduler.sigmas)

Logs

System Info

Environment
diffusers version
Python 3.13
Affected file: diffusers/schedulers/scheduling_flow_match_euler_discrete.py

Who can help?

No response

[bghira]

@yiyixux this one seems important

[yiyixuxu]

cc @dg845 — can you dig into this issue?

It's a weird behavior we inherited from the original SD3 implementation (the one that introduced the flow-match scheduler). Other than the double-shifting already pointed out in this issue, it also spreads the sigmas over [1, 1/num_training_steps] (vs. most other models, which use [1, 1/num_inference_steps]).

Because of this it wasn't directly usable for pretty much any newer flow-match model. as far as I know only auraflow uses the scheduler's set_timesteps (it deviates from the reference, but we compared outputs and found no quality difference, so we went with it). Every other flow-match model bypasses it by computing custom sigmas inside the pipeline (I think — we could do a more thorough sweep of the codebase to confirm).

Simply changing this would affect SD3 + AuraFlow, but we could avoid a breaking change with a config + deprecation. That said, I'm not sure fixing it alone makes the scheduler more usable (the sigma schedule would still deviate from the usual pattern). So before we touch anything, we'd like to know what real use cases we want to enable — to decide the right scope and best approach.