Repository navigation
fix: resolve the default device through torch.accelerator - #1327
Merged
SWivid merged 2 commits intoOct 14, 2026
Merged
Conversation
Each entry point selected its default device with a hand-rolled `"cuda" if torch.cuda.is_available() else "xpu" if ... else "cpu"` chain that only knows CUDA, XPU and MPS. On an Ascend NPU machine none of those probes is true, so inference (`utils_infer`), `speech_edit`, the `F5TTS` API, the socket server, `finetune_gradio` and the UTMOS evaluation all quietly fell back to the CPU even when the NPU was available. Add `f5_tts/device_utils.get_default_device()`, which asks `torch.accelerator` (PyTorch >= 2.6) for the accelerator that is actually registered and available, and keeps the explicit CUDA/NPU/XPU/MPS/CPU probes as a fallback for older builds. Route the six duplicated call sites through it. Behaviour on CUDA / XPU / MPS / CPU-only machines is unchanged; NPU machines now pick `npu` instead of `cpu`. Signed-off-by: li-lizhe <147392333@qq.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1326
What does this PR do?
Six entry points resolved their default device with their own copy of
which only knows CUDA / XPU / MPS. On an Ascend NPU machine none of those probes is true (
torch.cuda.is_available()isFalsethere), soutils_infer,speech_edit,api.F5TTS,socket_server,finetune_gradioandeval_utmosall silently fell back to the CPU even though an NPU was available.This PR adds
f5_tts/device_utils.get_default_device(), which askstorch.accelerator.current_accelerator()first (PyTorch >= 2.6 reports whichever backend is actually registered — CUDA, NPU, XPU, ...) and keeps explicit CUDA / NPU / XPU / MPS / CPU probes as a fallback for older builds, then routes the six call sites through it.torch_npuis imported lazily inside the NPU probe so the helper stays invisible on CUDA/XPU/MPS/CPU-only installs.Verification
Real Ascend 910B machine, container
npu-lizhe, 4 cards,torch 2.15.0.dev20260917+cpu+torch_npu:torch.accelerator.current_accelerator()get_default_device()npunpucputorch 2.14.0a0+cpu)Nonecpucputorch.randn(4, device=get_default_device())created the tensor onnpu:0in the NPU env.Not verified: end-to-end TTS synthesis on the NPU (the F5-TTS runtime deps are not installed in that container), and the CUDA / XPU / MPS branches were kept equivalent by inspection, not re-run.
Behaviour change
None on CUDA / XPU / MPS / CPU-only machines — the helper returns exactly what the six old chains returned there. Ascend NPU machines now resolve to
npuinstead ofcpu.ruff checkandruff formatare clean on the touched files.