DPMSolverSinglestepScheduler Step ValueError in SDXL Pipeline
Describe the bug
The DPMSolverSinglestepScheduler throws a value error "step must be greater than zero" in terminal. No other scheduler had this issue. When I set clipped_idx to be a small value like 0.01, the error goes away.
Reproduction
import torch, random, os
from diffusers import (StableDiffusionXLPipeline, DPMSolverSinglestepScheduler)
model = "JuggernautXL-V11.safetensors"
prompt = "A beautiful sunrise over a mountain range in oregon during winter, high resolution photograph"
negative_prompt = "cartoon, anime, unrealistic, low resolution, low quality"
num_inference_steps = 20
guidance_scale = 7
width = 768
height = 1024
seed = None
scheduler = DPMSolverSinglestepScheduler
pipeline = StableDiffusionXLPipeline.from_single_file(f"models/{model}")
pipeline.scheduler = scheduler.from_config(pipeline.scheduler.config)
device = "cuda" if torch.cuda.is_available() else "cpu"
precision = torch.float16 if device == "cuda" else torch.float32
pipeline = pipeline.to(device=device, dtype=precision)
if seed is None:
seed = random.randint(0, 2**32 - 1)
generator = torch.Generator().manual_seed(seed)
output = pipeline(
prompt=prompt,
negative_prompt=negative_prompt,
num_inference_steps=num_inference_steps,
guidance_scale=guidance_scale,
width=width,
height=height,
generator=generator
)
os.makedirs("outputs", exist_ok=True)
filename = next(
(f"outputs/{seed}-{i}.png" for i in range(1, 1000)
if not os.path.exists(f"outputs/{seed}-{i}.png")),
f"outputs/{seed}.png"
)
output.images[0].save(filename)
print(f"Image saved to {filename}")
Logs
Values I printed from the scheduler out of curiosity:
Scheduler: DPMSolverSinglestepScheduler
num_inference_steps: 20
self.lambda_t values: [3.5346992015838623, 3.186542272567749, 2.982215166091919, 2.8367769718170166, 2.72361421585083, 2.630859851837158, 2.552189826965332, 2.483828544616699, 2.423344850540161, 2.3690710067749023 (AND MANY MANY MORE)
self.config.lambda_min_clipped: -inf
Clipping threshold index: 0
Error source:
File "/.venv/lib/python3.12/site-packages/diffusers/schedulers/scheduling_dpmsolver_singlestep.py", line 321, in set_timesteps
np.linspace(0, self.config.num_train_timesteps - 1 - clipped_idx, num_inference_steps + 1)
ValueError: step must be greater than zero
System Info
diffusers==0.30.2, StableDiffusionXLPipeline on M1 iMac
Who can help?
@yiyixuxu @sayakpaul
I am getting the same issue on linux ubuntu 24.04. Its an issue only with the DPMSolverSinglestepScheduler .
I'm having the same issue on Windows 11 with Python 3.12. I'm a beginner at this, but comparing the code to the multistep scheduler, it seems like torch.searchsorted() returns a Tensor, while np.linspace() expects an ArrayLike structure.
Adding .numpy() and .item() to the assignment of clipped_idx:
clipped_idx = (torch.searchsorted(torch.flip(self.lambda_t, [0]), self.config.lambda_min_clipped).numpy()).item()
solves the issue... I don't know if this helps and if is the right way to do it. Using only numpy() also works
oh thanks! for everyone has this issue - are you all on python 3.12?
Getting this error on Python 3.10
I'm on Python 3.11
cc @DN6 - I cant reproduce but we are seeing test failures here too https://github.com/huggingface/diffusers/actions/runs/11356524049/job/31587859126#step:6:3811
I just ran into this issue on a new deployment. I had another deployment that was working, and the main difference between them seemed to be the numpy versions. The working version used numpy-1.22.4, whereas the latest one had pulled in numpy-2.1.2 (from diffusers). Uninstalling numpy and installing version 1.22.4 worked.
ohh thanks that's really helpful! @gfaires
This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.
Please note that issues that do not follow the contributing guidelines are likely to be ignored.
closing since we already fixed it!
let me know if anyone still experience the issue and we will reopen it but #9716 should fix it
i have the same bug, they using numpy == 1.24 fixed it.