`FlowMatchEulerDiscreteScheduler.set_timesteps` silently ignores explicit `timesteps` since #14011 — intended semantics change or unreleased regression?

[codeAnqiang-ma]

Describe the bug

Since #14011 (merged 2026-07-07, not yet in any release — v0.39.0 predates it), FlowMatchEulerDiscreteScheduler.set_timesteps unconditionally recomputes timesteps from the shifted sigmas (scheduling_flow_match_euler_discrete.py#L367), so an explicitly passed custom timesteps list is silently discarded. The docstring still promises "Custom values for timesteps to be used for each diffusion step" (L305-L307), and FlowMatchLCMScheduler still honors the argument (scheduling_flow_match_lcm.py#L376-L379), so the two flow-match schedulers now disagree on the same argument.

Concrete impact inside the library: CogView4 / CogView4-Control / GLM-Image deliberately pass integer-cast timesteps plus paired sigmas (pipeline_cogview4.py#L587-L606 — a mechanism the model authors added in #10649) and feed scheduler.timesteps to the transformer as conditioning. With the official CogView4-6B scheduler config at 1024x1024, the conditioning timesteps now deviate from the passed values by up to 285.75 / 1000 (repro below). The #14011 discussion covered the SD3/Flux pattern (deriving timesteps when only sigmas are given) and did not mention these pipelines.

Question for the maintainers: is discarding explicit timesteps the intended new semantics after #14011?

• If intended: the docstring, the now-dead is_timesteps_provided variable (L329), FlowMatchLCMScheduler, and the now-ineffective integer-cast in the CogView4/GLM-Image pipelines should be aligned — I'm happy to submit that PR.
• If not intended: restoring the explicit-timesteps branch (while keeping fix rf time scheduler problem #14011's recomputation for the derived case) before v0.40 ships would avoid releasing a silent behavior change — I'm happy to submit that PR instead; a minimal fix plus regression test is already prepared on my fork.

Reproduction

Repro 1 — exactly what pipeline_cogview4.py passes (CogView4-6B config, 1024x1024, 10 steps):

import numpy as np
from diffusers import FlowMatchEulerDiscreteScheduler

# THUDM/CogView4-6B scheduler config; mu=3.25 is what calculate_shift() yields at 1024x1024
sched = FlowMatchEulerDiscreteScheduler(
    num_train_timesteps=1000, shift=1.0, use_dynamic_shifting=True,
    base_shift=0.25, max_shift=0.75, base_image_seq_len=256,
    max_image_seq_len=4096, time_shift_type="linear")
timesteps = np.linspace(1000, 1.0, 10).astype(np.int64).astype(np.float32)  # as pipeline_cogview4.py does
sched.set_timesteps(10, sigmas=(timesteps / 1000).tolist(), timesteps=timesteps.tolist(), mu=3.25)
print(sched.timesteps.tolist())  # expected: the passed values [1000.0, 889.0, ..., 1.0]

Output on main (614ae4b):

passed   : [1000.0, 889.0, 778.0, 667.0, 556.0, 445.0, 334.0, 223.0, 112.0, 1.0]
got      : [1000.0, 963.0, 919.29, 866.84, 802.75, 722.67, 619.75, 482.6, 290.73, 3.24]
max delta: 285.75

Before #14011 (all releases through v0.39.0), the output equals the passed values.

Repro 2 — divergence from FlowMatchLCMScheduler (same inputs, static shift=3.0)

from diffusers import FlowMatchEulerDiscreteScheduler
from diffusers.schedulers.scheduling_flow_match_lcm import FlowMatchLCMScheduler

ts = [1000.0, 750.0, 500.0, 250.0, 1.0]
sg = [t / 1000 for t in ts]
euler = FlowMatchEulerDiscreteScheduler(num_train_timesteps=1000, shift=3.0)
lcm = FlowMatchLCMScheduler(num_train_timesteps=1000, shift=3.0)
euler.set_timesteps(sigmas=sg, timesteps=ts)
lcm.set_timesteps(sigmas=sg, timesteps=ts)
print(euler.timesteps.tolist())  # [1000.0, 900.0, 750.0, 500.0, 2.99]  <- input ignored
print(lcm.timesteps.tolist())    # [1000.0, 750.0, 500.0, 250.0, 1.0]   <- input honored

(Both produce identical sigmas; only timesteps diverge.)

Logs

(see outputs inline above)

System Info

• 🤗 Diffusers version: 0.40.0.dev0 (main @ 614ae4b)
• Platform: macOS-26.5.2-arm64-arm-64bit-Mach-O
• Running on Google Colab?: No
• Python version: 3.13.3
• PyTorch version (GPU?): 2.13.0 (False)
• Huggingface_hub version: 1.27.0
• Transformers version: 5.15.0
• Accelerate version: not installed
• PEFT version: not installed
• Safetensors version: 0.8.0
• xFormers version: not installed
• Accelerator: Apple M4
• Using GPU in script?: No
• Using distributed or parallel set-up in script?: No

Who can help?

No response

---

Disclosure: this report was prepared with AI assistance following the "AI-assisted and agentic contributions" guide; I reproduced the issue locally at 614ae4b and reviewed every claim. Per the guide, I'm coordinating here first and will wait for maintainer acknowledgment before opening any PR.

[TheLovesOfLadyPurple]

I think you should also print the sigmas of the timeschedule.

Yes, the timesteps you print are different from the timesteps you input, but that is correct since you apply the sigma_shift to the sigmas you input. If you print the sigmas, you will also find that the sigmas you print are also different from the sigmas you input.

Why should you apply the sigma shift in some model? When the different-resolution latents have the same SNR, the information in the latents that has been destroyed by the noise is also different. So in different-resolution inference, you need a different schedule. You can check the paper on SD3 to get a precise deduction.

[codeAnqiang-ma]

Thanks — printing the sigmas was the right call, and you're right on both counts. CogView4-6B config, 1024x1024, mu=3.25, 10 steps:

sigmas + timesteps, in vs. out

input  sigmas   : [1.0000, 0.8890, 0.7780, 0.6670, 0.5560, 0.4450, 0.3340, 0.2230, 0.1120, 0.0010]
output sigmas   : [1.0000, 0.9630, 0.9193, 0.8668, 0.8028, 0.7227, 0.6198, 0.4826, 0.2907, 0.0032]
input  timesteps: [1000.00, 889.00, 778.00, 667.00, 556.00, 445.00, 334.00, 223.00, 112.00, 1.00]
output timesteps: [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]

output sigmas    == time_shift(mu, 1.0, input sigmas)  -> True
output timesteps == output sigmas * 1000               -> True

The sigmas do move, exactly by the shift, and the timesteps are just 1000 x shifted sigmas. No disagreement about the shift or about why it has to be resolution-dependent.

My question is narrower: when sigmas and timesteps are passed together, timesteps isn't shifted — it has no effect at all. The same sigmas with the pipeline's values, [0.0] * 10, a reversed list, or timesteps=None all give bit-identical output:

same sigmas, four different timesteps -> identical result

timesteps=[1000, 889, ..., 1] -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]
timesteps=[0, 0, ..., 0]      -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]
timesteps=[1, 112, ..., 1000] -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]
timesteps=None                -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]

With sigmas=None your description holds exactly — the passed timesteps seed the grid and come back shifted, which is the SD3/Flux case #14011 targeted. It's only the paired case (pipeline_cogview4.py / pipeline_glm_image.py: sigma grid for the ODE, integer labels for conditioning) that became a no-op, and FlowMatchLCMScheduler applies the same shift to the same sigmas yet still returns the passed values.

So the two-way question stands: if discarding them is intended, the docstring and FlowMatchLCMScheduler should be aligned with it; if not, it seems worth restoring before v0.40 ships. The patch I have keeps #14011 untouched for the timesteps-only case and preserves explicit values only when both are passed — happy to open it whenever a maintainer indicates which way to go.

[TheLovesOfLadyPurple]

Thanks — printing the sigmas was the right call, and you're right on both counts. CogView4-6B config, 1024x1024, mu=3.25, 10 steps:

sigmas + timesteps, in vs. out

input  sigmas   : [1.0000, 0.8890, 0.7780, 0.6670, 0.5560, 0.4450, 0.3340, 0.2230, 0.1120, 0.0010]
output sigmas   : [1.0000, 0.9630, 0.9193, 0.8668, 0.8028, 0.7227, 0.6198, 0.4826, 0.2907, 0.0032]
input  timesteps: [1000.00, 889.00, 778.00, 667.00, 556.00, 445.00, 334.00, 223.00, 112.00, 1.00]
output timesteps: [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]

output sigmas    == time_shift(mu, 1.0, input sigmas)  -> True
output timesteps == output sigmas * 1000               -> True

The sigmas do move, exactly by the shift, and the timesteps are just 1000 x shifted sigmas. No disagreement about the shift or about why it has to be resolution-dependent.

My question is narrower: when sigmas and timesteps are passed together, timesteps isn't shifted — it has no effect at all. The same sigmas with the pipeline's values, [0.0] * 10, a reversed list, or timesteps=None all give bit-identical output:

same sigmas, four different timesteps -> identical result

timesteps=[1000, 889, ..., 1] -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]
timesteps=[0, 0, ..., 0]      -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]
timesteps=[1, 112, ..., 1000] -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]
timesteps=None                -> [1000.00, 963.00, 919.29, 866.84, 802.75, 722.67, 619.75, 482.60, 290.73, 3.24]

With sigmas=None your description holds exactly — the passed timesteps seed the grid and come back shifted, which is the SD3/Flux case #14011 targeted. It's only the paired case (pipeline_cogview4.py / pipeline_glm_image.py: sigma grid for the ODE, integer labels for conditioning) that became a no-op, and FlowMatchLCMScheduler applies the same shift to the same sigmas yet still returns the passed values.

So the two-way question stands: if discarding them is intended, the docstring and FlowMatchLCMScheduler should be aligned with it; if not, it seems worth restoring before v0.40 ships. The patch I have keeps #14011 untouched for the timesteps-only case and preserves explicit values only when both are passed — happy to open it whenever a maintainer indicates which way to go.

The timesteps printed in the log are the conditional input of the neural network, and they don't affect the discretization behavior (the ODE describes a curve, and in the inference, we just give a series of noisy images that denote different lines). I am not familiar with GLM-Image; would it input a t label to the neural network that is different from the SNR of the latent? In the normal flow matching algorithm, during training, we have a non-causal ODE: x_t = (1 - t) x_0 + t \epsilon and SNR = (1-t)/t. If the inference input label should be aligned with the training input label, then I think this behavior is correct.

[TheLovesOfLadyPurple]

Another problem is which one should control the discretization behavior: timesteps or sigmas? Should we allow it to be input simultaneously?

[codeAnqiang-ma]

would it input a t label to the neural network that is different from the SNR of the latent?

Yes — that is exactly what the official pipelines have done in every release so far (v0.39.0 and earlier): the transformer receives the integer labels [1000, 889, 778, ...] while the ODE marches over the mu-shifted sigmas [1.0, 0.963, 0.919, ...]. And it isn't an accident of the scheduler: the CogView4 integration PR #10649, authored by the model authors themselves, added all three pieces at once — the integer cast in the pipeline, the is_timesteps_provided branch in the scheduler that preserved those values, and a pipeline-local retrieve_timesteps that accepts both arguments together (the stock helper in e.g. pipeline_flux.py raises ValueError for that combination). If the intended conditioning were the shifted sigmas, none of that machinery would have been needed — timesteps=None already gives exactly that behavior.

Whether the model was trained on integer labels or on sigma-aligned labels is the one thing I can't prove from the outside; only the model authors can. That's why the issue is framed as a question rather than a fix: either their inference-time contract has been wrong since integration (then the pipeline's integer cast should be removed and the docstring updated), or it was right (then #14011 shouldn't silently override it). The only state that seems clearly wrong is the current one, where the pipeline still carefully builds labels that the scheduler then discards.

which one should control the discretization behavior: timesteps or sigmas? Should we allow it to be input simultaneously?

As the API stands today: sigmas, when given, always control discretization — unchanged by #14011; timesteps alone seeds the grid and comes back shifted — the SD3/Flux case #14011 fixed, which my patch leaves untouched; and passing both is the combination #10649 deliberately enabled: sigmas for the grid, timesteps for the conditioning labels. Whether that combination stays supported or gets deprecated (with a warning instead of a silent override) is exactly the maintainer decision this issue asks for.

[TheLovesOfLadyPurple]

would it input a t label to the neural network that is different from the SNR of the latent?

Yes — that is exactly what the official pipelines have done in every release so far (v0.39.0 and earlier): the transformer receives the integer labels [1000, 889, 778, ...] while the ODE marches over the mu-shifted sigmas [1.0, 0.963, 0.919, ...]. And it isn't an accident of the scheduler: the CogView4 integration PR #10649, authored by the model authors themselves, added all three pieces at once — the integer cast in the pipeline, the is_timesteps_provided branch in the scheduler that preserved those values, and a pipeline-local retrieve_timesteps that accepts both arguments together (the stock helper in e.g. pipeline_flux.py raises ValueError for that combination). If the intended conditioning were the shifted sigmas, none of that machinery would have been needed — timesteps=None already gives exactly that behavior.

Whether the model was trained on integer labels or on sigma-aligned labels is the one thing I can't prove from the outside; only the model authors can. That's why the issue is framed as a question rather than a fix: either their inference-time contract has been wrong since integration (then the pipeline's integer cast should be removed and the docstring updated), or it was right (then #14011 shouldn't silently override it). The only state that seems clearly wrong is the current one, where the pipeline still carefully builds labels that the scheduler then discards.

which one should control the discretization behavior: timesteps or sigmas? Should we allow it to be input simultaneously?

As the API stands today: sigmas, when given, always control discretization — unchanged by #14011; timesteps alone seeds the grid and comes back shifted — the SD3/Flux case #14011 fixed, which my patch leaves untouched; and passing both is the combination #10649 deliberately enabled: sigmas for the grid, timesteps for the conditioning labels. Whether that combination stays supported or gets deprecated (with a warning instead of a silent override) is exactly the maintainer decision this issue asks for.

OK, I now watch the pipeline, and I know what you mean.
@zRzRzRzRzRzRzR I do think asking the author is all you need. Please check the mathematical detail on the #14011
Is it an intentional feature to let the input t label in the timesteps be different from the sigmas?