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
MiniMax-H3 video decode only enables fp16 autocast on CUDA, so the block silently runs in fp32 on other accelerators #14882
MiniMaxH3VideoDecodeStep.__call__ (src/diffusers/modular_pipelines/minimax_h3/decoders.py, line ~187) wraps the VAE decode in an fp16 autocast whose gate is CUDA-only:
The block's own description states the intent - "the decode itself runs under float16 autocast even though the VAE weights are float32" - but with enabled=device.type == "cuda" that is only true on CUDA. On every other accelerator (Ascend NPU, Intel XPU, Apple MPS) autocast is silently disabled, so the same workflow decodes with the VAE's fp32 weights: slower, and numerically on a different path than the documented CUDA behaviour.
Suggested change - gate on "not CPU" instead of "CUDA only":
enabled=device.type!="cpu",
CPU keeps the current behaviour (autocast disabled).
Reproduction
On Ascend 910B2 NPU (torch 2.15.0.dev20260917+cpu + torch_npu), the enabled flag is the only thing keeping the NPU on the fp32 path:
End-to-end NPU decode speed-up of the change is not measured here - no A/B benchmark of the decode block was run, only the dtype-path check above. CUDA behaviour is unchanged by the linked PR.
Related but distinct
#14746 reports a trade-off in the opposite direction on CUDA (fp32 VAE weights + fp16 decode costs VRAM and forces a downcast). This issue is only about the device gate being CUDA-only; it does not argue about whether the fp16 autocast should exist at all.
System Info
diffusers: main
hardware: Ascend 910B2 NPU (torch 2.15.0.dev20260917+cpu + torch_npu); applies to any non-CUDA accelerator.
Resolved upstream by #14754 (commit 51a454b): the fix was to drop the fp16 autocast around the video decode block and run it at the dtype you pass, rather than enabling autocast on more accelerators — the PR's error table shows the previous fp32-weights + fp16-autocast path was the inaccurate one. The premise of this issue no longer holds, so I'm closing it.
Resolved upstream by #14754 (commit 51a454b): the fix was to drop the fp16 autocast around the video decode block and run it at the dtype you pass, rather than enabling autocast on more accelerators — the PR's error table shows the previous fp32-weights + fp16-autocast path was the inaccurate one. The premise of this issue no longer holds, so I'm closing it.
Activity
li-lizhe commentedon Sep 28, 2026
Resolved upstream by #14754 (commit 51a454b): the fix was to drop the fp16 autocast around the video decode block and run it at the dtype you pass, rather than enabling autocast on more accelerators — the PR's error table shows the previous fp32-weights + fp16-autocast path was the inaccurate one. The premise of this issue no longer holds, so I'm closing it.
li-lizhe commentedon Sep 28, 2026
Resolved upstream by #14754 (commit 51a454b): the fix was to drop the fp16 autocast around the video decode block and run it at the dtype you pass, rather than enabling autocast on more accelerators — the PR's error table shows the previous fp32-weights + fp16-autocast path was the inaccurate one. The premise of this issue no longer holds, so I'm closing it.