Windows 11 process-exit hang after ROCm Whisper inference with AMD GPU
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 4.7k
- Forks
- 536
- Avg merge
- 12h 12m
- Merged PRs (30d)
- 4
Description
Windows 11 process-exit hang after ROCm Whisper inference with AMD/ROCm backend
Description
I have encountered a reproducible process-exit hang when using CTranslate2 through faster-whisper with an AMD GPU / ROCm backend on Windows 11.
Whisper model loading and transcription both complete successfully. The Python process then hangs during normal interpreter shutdown when the native CTranslate2 Whisper object remains attached.
As a diagnostic workaround, explicitly detaching the native CTranslate2 object with:
model.model = None
allows the process to terminate normally.
This appears to point to an issue during destruction/finalization of the native CTranslate2 Whisper object or associated ROCm resources.
Environment
- OS: Windows 11 64-bit
- Python: CPython 3.14.4 64-bit
- faster-whisper: 1.2.1
- CTranslate2: 4.8.1
- GPU backend: ROCm / AMD
- faster-whisper model:
tiny - Device:
cuda - Compute type:
float32
The ROCm runtime DLL directory is explicitly added before importing CTranslate2:
import os
os.add_dll_directory(
r"<ROCM_DLL_DIR>"
)
The actual local filesystem path has intentionally been replaced with <ROCM_DLL_DIR> in this report.
What works
The following operations complete successfully:
- Importing CTranslate2
- Creating a
faster-whisperWhisperModel - Loading the
tinymodel - Running Whisper transcription
- Iterating over the generated segments
- Accessing the resulting transcription text
For example, model creation succeeds:
CREATE
READY
and transcription succeeds:
TRANSCRIBE DONE
TEXT LENGTH: 994
The native object is confirmed to be:
<class 'ctranslate2._ext.Whisper'>
Reproduction
The following is a minimal reproducer for the observed behavior:
import os
os.add_dll_directory(
r"<ROCM_DLL_DIR>"
)
from faster_whisper import WhisperModel
print("CREATE")
model = WhisperModel(
"tiny",
device="cuda",
compute_type="float32"
)
print("READY")
segments, info = model.transcribe(
r"<TEST_AUDIO_FILE>"
)
print("TRANSCRIBE DONE")
text = "".join(segment.text for segment in segments).strip()
print("TEXT LENGTH:", len(text))
print("PROCESS END")
Observed output:
CREATE
READY
TRANSCRIBE DONE
TEXT LENGTH: 994
PROCESS END
After PROCESS END, the Python process does not terminate normally and remains stuck.
The transcription itself is already complete at this point.
Important diagnostic observation
The following modification allows the process to terminate normally:
model.model = None
Complete test:
import os
import gc
os.add_dll_directory(
r"<ROCM_DLL_DIR>"
)
from faster_whisper import WhisperModel
print("CREATE")
model = WhisperModel(
"tiny",
device="cuda",
compute_type="float32"
)
print("READY")
segments, info = model.transcribe(
r"<TEST_AUDIO_FILE>"
)
text = "".join(segment.text for segment in segments).strip()
print("TEXT LENGTH:", len(text))
print("DETACH")
model.model = None
print("DETACHED")
gc.collect()
print("GC DONE")
print("NORMAL EXIT")
Observed output:
CREATE
READY
TEXT LENGTH: 994
DETACH
DETACHED
GC DONE
NORMAL EXIT
The process terminates normally.
Further isolation
The faster-whisper object hierarchy was inspected.
The relevant objects are:
MODEL TYPE:
<class 'faster_whisper.transcribe.WhisperModel'>
CT TYPE:
<class 'ctranslate2._ext.Whisper'>
The WhisperModel instance contains the native CTranslate2 Whisper object as:
model.model
Detaching exactly this native object is sufficient to avoid the shutdown hang.
CPU comparison
The same general model-loading operation using the CPU backend does not exhibit the shutdown hang.
For example:
from faster_whisper import WhisperModel
model = WhisperModel(
"tiny",
device="cpu",
compute_type="int8"
)
print("MODEL READY")
followed by normal interpreter termination works correctly.
This suggests that the issue is related to the GPU/ROCm configuration rather than to faster-whisper model creation itself.
CTranslate2 import isolation
Importing CTranslate2 alone also terminates normally:
import ctranslate2
print("CTRANSLATE2 IMPORTED")
Therefore, the issue does not appear to be caused simply by importing the CTranslate2 Python module.
The problematic behavior occurs after creating a native CTranslate2 Whisper object using the ROCm/AMD configuration.
Reproduction boundary
The observed sequence can therefore be summarized as:
Windows 11
+
Python 3.14.4
+
faster-whisper 1.2.1
+
CTranslate2 4.8.1
+
AMD / ROCm
+
WhisperModel("tiny", device="cuda", compute_type="float32")
|
+--> model creation succeeds
|
+--> transcription succeeds
|
+--> transcription result is fully available
|
+--> process shutdown
|
+--> HANG
Whereas:
model.model = None
|
+--> native CTranslate2 Whisper object detached
|
+--> normal interpreter shutdown
|
+--> EXIT
Expected behavior
After successful inference, the Python process should be able to terminate normally and the native CTranslate2/ROCm resources should be released during interpreter shutdown.
Actual behavior
With the AMD/ROCm configuration described above, the process hangs during shutdown while the native CTranslate2 Whisper object remains attached.
Explicitly detaching the native object before shutdown avoids the hang.
Current hypothesis
I do not know the exact root cause.
Based on the isolation tests, the current hypothesis is that the problem occurs during destruction/finalization of the native CTranslate2 Whisper object or associated ROCm resources on Windows.
Possible areas could include:
- GPU resource cleanup
- native worker threads
- synchronization during destruction
- ROCm runtime shutdown
- interaction between CTranslate2 native cleanup and the Windows process shutdown sequence
This is only a hypothesis. The purpose of this report is to provide the reproducible behavior and the minimal diagnostic information for investigation.
Versions
OS: Windows 11 64-bit
Python: 3.14.4 (CPython, 64-bit)
faster-whisper: 1.2.1
CTranslate2: 4.8.1
Model: tiny
Device: cuda
Compute type: float32
Backend: AMD / ROCm
Workaround
Until the underlying issue is identified, explicitly detaching the native CTranslate2 object before interpreter shutdown appears to work as a workaround:
model.model = None
This is currently only being used as a diagnostic/workaround and is not intended as a proposed permanent fix.
Request
Could you please investigate whether the CTranslate2 native Whisper object has a shutdown/destructor issue with the ROCm/AMD backend on Windows?
I can provide additional diagnostic output, package information, or a more minimal reproducer if required.
Thank you for your work on CTranslate2 and for taking the time to investigate this issue.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the posted minimal Python reproducer and the native CTranslate2 Whisper object held by model.model. Investigate destruction during Windows interpreter shutdown for the AMD/ROCm configuration, comparing it with the reported CPU case. Done means the reproducer exits normally without manually setting model.model to None.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, python
- Domain
- backend, machine-learning, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100