OpenNMT / OpenNMT/CTranslate2

Windows 11 process-exit hang after ROCm Whisper inference with AMD GPU

Open
#2,085 0 comments 0 reactions 0 assignees View on GitHub

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:

  1. Importing CTranslate2
  2. Creating a faster-whisper WhisperModel
  3. Loading the tiny model
  4. Running Whisper transcription
  5. Iterating over the generated segments
  6. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.