Library cublas64_12.dll Is Not Found: faster-whisper Loads, Then Dies on the First Transcribe

If you are here from the error message, the short version is this. Your PyTorch build and your CTranslate2 build disagree about which CUDA they want, and nothing tells you until the first audio frame hits the encoder.

The full error I got:

The part that wasted my afternoon

The model loads. It loads cleanly, in about two seconds, and the log says the model is ready. If you have a startup check that loads the model and calls it healthy, that check passes.

The failure arrives later, on the first real
call, inside the encode step. So the shape of the bug is "GPU works, then suddenly does not", which sends you looking at your audio pipeline instead of your install.

Why the versions disagree

I had PyTorch installed from the cu130 wheels. That is fine on its own. But faster-whisper does not use PyTorch for inference, it uses CTranslate2, and CTranslate2 ships its own expectations. The CTranslate2 installation docs say the published Python wheels are built for CUDA 12.x, and that models with convolutional layers, which includes speech recognition, also want a cuDNN 8 build compatible with CUDA 12.x.

So the DLL it wants is literally named after the major version:
. A CUDA 13 runtime on the machine does not satisfy it. There is no fallback and no warning, only a missing library at the moment of use.

The fix, including the half that is not obvious

Install the CUDA 12 libraries from pip:

Then, before
is imported, point the process at the
folders under
. Here is the part I got wrong the first time. You have to do both of these for each folder:

• 
  
• prepend the same folder to
  

Adding the DLL directory alone did not work for me, and I expected it to. Python 3.8 changed how extension modules resolve their native dependencies on Windows: the docs describe loading dependencies only from trusted locations, which includes paths registered with
. That covers the import.

It does not cover what CTranslate2 does later. cuBLAS is opened at encode time through its own library load, and that call goes through the ordinary Windows search order, which still reads PATH. One mechanism serves the import, the other serves the runtime load, and you need both. That is why the error can appear after a successful import.

What it does once it runs

large-v3-turbo at float16 on an RTX 4090 transcribes at roughly 61 times real time. I measured that over an archive of about 1,400 voice recordings, so it includes file handling and model warm-up, not just the kernel.

That number is the reason to fight with the DLLs rather than fall back to CPU. On CPU the same job is a different kind of project.

If you are debugging this now

Check the CUDA major version your CTranslate2 wheel expects before you check anything in your own code. Then confirm the load actually happened rather than assuming it did, by running one short file through
at startup instead of only constructing the model. A health check that stops at model construction will report green on a machine that cannot transcribe a single second of audio.