You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DEIS coefficient precision causes increasing error as inference steps increase #15090
At 50 inference steps, DEIS returns about 0.01679 for an exact constant-predictor trajectory whose final value is about 0.01000. Increasing the step count makes the error much larger. I reproduced this with both float32 and float64 samples on current main.
Sample dtype
Steps
Expected
Current result
Same sigma values promoted to float64
float64
50
0.0100008295
0.0167921734
0.0100008295
float64
100
0.0100008295
0.0544108478
0.0100008297
float64
500
0.0100008295
4.4766635023
0.0100008292
float32
50
0.0099966395
0.0167866610
0.0100106206
float32
100
0.0099966395
0.0544000231
0.0100174602
float32
500
0.0099966395
4.4766407013
0.0100396425
The control casts scheduler.sigmasafterset_timesteps, so every noise-grid value stays identical. The predictor always returns one and the initial sample is about one. At 50 steps, the absolute error is about 0.00679, or 68% of the expected final value.
For constant epsilon, d(x / alpha) / d(rho) = 1, where rho is the stored sigma ratio and alpha = 1 / sqrt(1 + rho**2). The script evaluates that exact solution, including the rounding of the initial sample. Lagrange interpolation reproduces constants, so this trajectory has no truncation error in exact arithmetic.
The evidence points to cancellation in the float32 scalar antiderivative calculations. I also compared the third-order coefficients with 80-digit mpmath integrals for 1, log(rho) and log(rho)**2, at indices 5, n // 2 and n - 3 for n = 50, 100, 500. The largest relative errors at these selected nodes were 14.5%, 14.7% and 14.8% for degrees 0, 1 and 2; promoting the coefficient calculations reduced them below 8e-10.
A local candidate change promotes the reconstructed ratios before evaluating the second- and third-order coefficients. That reduces the 500-step trajectory error to 3.6e-5 for float64 samples and 8.9e-5 for float32 samples. This is narrower than the metadata-promotion control in the table and leaves other float32 scalar calculations in place. The remaining error has not been fully attributed. All 14 local tests pass with the change; 11 fail before it. The tests also assert that the output dtype stays unchanged. I'd be happy to work on a fix if this approach makes sense.
The default schedule here has distinct points and a positive final ratio, sigmas[-1] = 0.010001329705119133. This DEIS implementation has no final_sigmas_type option. Its lower-order-final fallback applies only below 15 steps, so it is inactive in these runs. Sigma metadata stays on CPU.
This is a scheduler correctness reproduction. I haven't measured generated-image quality, GPU behavior or performance.
I checked the existing DEIS issues, including the precision discussion in #4167. That discussion concerns differences in generated beta/sigma values; this reproduction keeps those values identical. I did not find a matching coefficient-cancellation report.
Hi! I'd like to pick this up. The plan is to compute the DEIS coefficients in float64 and cast back, and add a test that checks the error doesn't grow with more steps. OK if I take it?
Activity
ATS-AI-6278 commentedon Oct 21, 2026
Hi! I'd like to pick this up. The plan is to compute the DEIS coefficients in float64 and cast back, and add a test that checks the error doesn't grow with more steps. OK if I take it?