TL;DR: Could not locate cudnn_ops64_9.dll (Windows) and Unable to load any of {libcudnn_ops.so.9...} (Linux) mean one thing: your process can’t find the cuDNN 9 libraries that CTranslate2 4.5.0 and newer link against at runtime. Nothing is wrong with your GPU, your driver, or your model. The two fastest fixes: upgrade PyTorch to 2.4.0 or newer (it bundles cuDNN 9), or pip install nvidia-cudnn-cu12==9.* and put its library folder on your path. Your CUDA driver version is not the problem, and reinstalling the CUDA toolkit won’t fix it.

What you’ll be able to do:

• Decode which cuDNN version your CTranslate2 build wants from the error text alone (_9 vs _8 in the filename is the whole diagnosis)
• Fix the error in faster-whisper, WhisperX, whisper-diarization, Whisper-WebUI, or anything else built on CTranslate2 — with the fix that matches how your environment got broken
• Verify the fix with a one-liner before you re-run a 90-minute transcription job

Honest take: This error is a dependency-packaging problem, not a hardware or driver problem. CTranslate2 dynamic-links cuDNN instead of bundling it, and version 4.5.0 silently jumped from cuDNN 8 to cuDNN 9. Every hour spent reinstalling CUDA toolkits, rolling back GPU drivers, or re-downloading models is wasted. Match the cuDNN major version to your CTranslate2 version and the error disappears.

The error in all its costumes

The same failure surfaces under several names depending on OS and which cuDNN sub-library fails to load first. All of these are the same root cause:

What you see	OS	cuDNN wanted
Could not locate cudnn_ops64_9.dll. Please make sure it is in your library path!	Windows	9.x
Invalid handle. Cannot load symbol cudnnCreateTensorDescriptor	Windows/Linux (follows the line above)	9.x
Unable to load any of {libcudnn_ops.so.9.1.0, libcudnn_ops.so.9.1, libcudnn_ops.so.9, libcudnn_ops.so}	Linux	9.x
Unable to load any of {libcudnn_cnn.so.9.1.0, ...} Cannot load symbol cudnnCreateConvolutionDescriptor	Linux	9.x
Could not load library cudnn_ops_infer64_8.dll. Error code 126	Windows	8.x (older stack)

The reports span the whole CTranslate2 ecosystem: faster-whisper #1080, faster-whisper #1230, WhisperX #1100, whisper-diarization #259, Whisper-WebUI #485, the speech_recognition library #835, and WhisperLiveKit #286. If your transcription tool has “whisper” in the name and runs on an NVIDIA GPU, odds are it’s CTranslate2 underneath — and this is its signature failure.

The filename in the error is the entire diagnosis. cudnn_ops64_9.dll or libcudnn_ops.so.9 → the library wants cuDNN 9 and can’t find it. cudnn_ops_infer64_8.dll or libcudnn_ops_infer.so.8 → an older stack wants cuDNN 8. You never need to guess.

Why this broke: the CTranslate2 4.5.0 switch

CTranslate2 — the inference engine under faster-whisper — does not ship cuDNN inside its wheel. It loads NVIDIA’s libraries from your system at runtime. That worked quietly until CTranslate2 4.5.0 (October 22, 2024), whose release notes state it plainly: “The CTranslate2 Python package now supports CUDNN 9 and is no longer compatible with CUDNN 8.”

Meanwhile, most people had a working cuDNN 8 on their machine for one reason: PyTorch bundles its own cuDNN, and torch 2.3.1 and earlier bundled cuDNN 8. When pip install -U faster-whisper pulled in CTranslate2 ≥4.5.0 next to an older torch, the new engine went looking for cuDNN 9 in a process that only had cuDNN 8 to offer. Instant cudnn_ops64_9.dll error — which is exactly the mismatch documented in faster-whisper issue #1080: torch ≤2.3.1 plus the CTranslate2 4.5.0 update reproduces it; torch ≥2.4.0 (which bundles cuDNN 9) resolves it.

The compatibility matrix, straight from the faster-whisper README:

CTranslate2 version	CUDA	cuDNN
4.5.0 and newer (current)	12.x	9.x
4.4.0	12.x	8.x
3.24.0	11.x	8.x

Pin whichever row matches the libraries you can actually provide. Everything below is just five ways of satisfying that table.

The 60-second diagnosis

Run these three checks before changing anything:

pip show ctranslate2 | grep Version
python -c "import torch; print(torch.__version__, torch.backends.cudnn.version())"
python -c "import nvidia.cudnn; print(nvidia.cudnn.__file__)"

Expected output on a healthy cuDNN 9 stack looks like:

Version: 4.8.1
2.6.0+cu124 90100
/home/you/.venv/lib/python3.11/site-packages/nvidia/cudnn/__init__.py

• ctranslate2 ≥4.5.0 → you need cuDNN 9 visible to the process.
• torch prints 90xxx for the cuDNN version → torch is carrying cuDNN 9; fix is usually just path/import order or a torch upgrade finishing the job.
• torch prints 8xxx (torch ≤2.3.1) → confirmed mismatch; go to Fix 1.
• The third command throws ModuleNotFoundError and you don’t use torch → no pip-installed cuDNN at all; go to Fix 2.

If the second command itself fails because you never installed torch, that’s fine — faster-whisper doesn’t require torch. Fix 2 is your path.

Fix 1: Upgrade PyTorch to ≥2.4.0 (the common case)

If torch is in your environment at ≤2.3.1, upgrade it — torch 2.4.0+ bundles cuDNN 9, and CTranslate2 picks it up once torch loads. This is the fix confirmed in issue #1080:

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124 --force-reinstall --no-cache

Then verify:

python -c "import torch; print(torch.backends.cudnn.version())"
# 90100  ← any 9xxxx number means cuDNN 9 is now in-process

Two traps here:

1. Use the CUDA index URL, not bare PyPI. The same trap as ComfyUI’s “Torch not compiled with CUDA enabled” — the default PyPI wheel on Windows is CPU-only, and you’ll trade a cuDNN error for a slower, different one.
2. Import order can matter on Windows. Torch’s bundled DLLs get registered when torch is imported. If your script loads faster-whisper first and torch never, the DLLs may never enter the process. Importing torch at the top of your script before faster-whisper is a zero-cost insurance line.

Fix 2: Install cuDNN 9 with pip (no torch required)

The faster-whisper README’s official recipe — install NVIDIA’s libraries as pip packages and point your loader path at them:

pip install nvidia-cublas-cu12 "nvidia-cudnn-cu12==9.*"

export LD_LIBRARY_PATH=`python3 -c 'import os; import nvidia.cublas.lib; import nvidia.cudnn.lib; print(os.path.dirname(nvidia.cublas.lib.__file__) + ":" + os.path.dirname(nvidia.cudnn.lib.__file__))'`

That export lasts one shell session. Put it in your virtualenv’s activate script, your systemd unit’s Environment= line, or your ~/.bashrc — whichever matches how you run the server. If you followed our self-hosted Whisper transcription server guide, the systemd unit is the right home for it.

Windows equivalent: the same pip install drops the DLLs into site-packages\nvidia\cudnn\bin. Windows doesn’t read LD_LIBRARY_PATH, so either add that folder to your PATH, or register it in Python before importing faster-whisper:

import os, nvidia.cudnn
os.add_dll_directory(os.path.join(os.path.dirname(nvidia.cudnn.__file__), "bin"))
from faster_whisper import WhisperModel

Fix 3: System-wide cuDNN 9 on Windows

If you’d rather fix the machine than the environment — useful when several tools (Subtitle Edit’s Whisper integration, standalone builds, multiple venvs) all hit the same wall — install cuDNN 9 once, system-wide:

1. Download cuDNN 9 for CUDA 12 from NVIDIA’s cuDNN page (free developer account required).
2. Either run the installer and add its bin directory to PATH, or copy the DLLs into your CUDA toolkit’s bin folder — community-confirmed target: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.x\bin.
3. Open a new terminal (PATH changes don’t reach already-open shells) and re-run.

Copy the whole DLL set, not just the one file the error names. cudnn_ops64_9.dll is merely the first library CTranslate2 tries; behind it are cudnn_cnn64_9.dll, cudnn_graph64_9.dll, and friends, and you’ll play whack-a-mole if you move them one at a time — the follow-up Cannot load symbol line in Whisper-WebUI #485 is what a partial copy looks like.

Fix 4: Pin CTranslate2 down instead

Sometimes upgrading the environment is the wrong move — a shared box you can’t touch, a driver stuck on CUDA 11, or a downstream tool that pins old torch. Then move CTranslate2 to match what you have, per the version matrix:

# You have cuDNN 8 + CUDA 12 (e.g. torch 2.1–2.3 stack you can't change):
pip install "ctranslate2==4.4.0"

# You're stuck on CUDA 11:
pip install "ctranslate2==3.24.0"

Caveats, honestly stated: 4.4.0 predates later Whisper fixes and model support in newer releases (CTranslate2 was at 4.8.1 as of July 2025, per the releases page), and users in faster-whisper discussion #1114 report the pin fights with up-to-date dependency trees. Treat it as a bridge, not a destination.

Docker: the same error in a container

Containers hit this when the base image lacks cuDNN 9. The canonical example: linuxserver/faster-whisper 2.4.0-gpu shipped broken with exactly this error, and users fixed it by rolling back to 2.3.0-gpu until the image was rebuilt.

If you build your own image, base it on a cuDNN runtime tag — nvidia/cuda:12.4.1-cudnn-runtime-ubuntu22.04 — rather than the bare -runtime image, or bake Fix 2 into the Dockerfile:

RUN pip install nvidia-cublas-cu12 "nvidia-cudnn-cu12==9.*"
ENV LD_LIBRARY_PATH=/usr/local/lib/python3.11/dist-packages/nvidia/cublas/lib:/usr/local/lib/python3.11/dist-packages/nvidia/cudnn/lib

Adjust the Python version in the path to match the image. The nvidia-smi-works-but-transcription-crashes pattern almost always means the driver passthrough is fine and the library layer is missing — same diagnosis as bare metal.

While you debug: the CPU escape hatch

To confirm everything else in your pipeline works while you sort out cuDNN:

from faster_whisper import WhisperModel
model = WhisperModel("large-v3", device="cpu", compute_type="int8")

CPU int8 is genuinely usable for short clips and completely sidesteps CUDA and cuDNN. It is not a place to live — here’s what you get back by fixing the GPU path, from the faster-whisper benchmark (13-minute audio, large-v2, RTX 3070 Ti 8GB, CUDA 12.4):

Configuration	Time for 13 min of audio	Peak VRAM
fp16, sequential	1m03s	4,525 MB
fp16, batch_size=8	17s	6,090 MB
int8, sequential	59s	2,926 MB
int8, batch_size=8	16s	4,500 MB

Two practical reads on that table: int8 cuts VRAM by roughly a third (2.9GB vs 4.5GB) so large-v3 fits comfortably on 6GB and 8GB cards — pair it with our 8GB VRAM model guide if that’s your tier — and batched inference is where the real speed lives (17 seconds for 13 minutes of audio is ~46× real-time). A working cuDNN setup is the difference between transcribing a podcast backlog overnight and babysitting it for a week. GPU-side audio is having a moment beyond Whisper too — see audio.cpp’s 20-model local audio engine — and every one of those stacks leans on the same CUDA/cuDNN plumbing you just fixed.

If you hit an out-of-memory error the moment cuDNN starts working (it happens — the GPU path finally executes), the fixes are the usual suspects: smaller batch size, int8, or the full playbook in CUDA out of memory: every fix that works.

FAQ

Do I need to install the CUDA toolkit to fix this? No. CTranslate2 needs the CUDA runtime libraries and cuDNN, both of which ship as pip wheels (nvidia-cublas-cu12, nvidia-cudnn-cu12). Your NVIDIA driver must simply be new enough for CUDA 12 — check with nvidia-smi. The full multi-gigabyte toolkit install is unnecessary for inference.

Why did this start after I upgraded faster-whisper? Upgrading faster-whisper pulled CTranslate2 past 4.5.0, which dropped cuDNN 8 for cuDNN 9. If your torch was ≤2.3.1 (bundling cuDNN 8), the versions crossed. It’s the single most common way this error appears on a previously working machine.

I installed cuDNN but the error persists. Why? Three usual causes: you installed cuDNN for the wrong CUDA major version (cuDNN 9 comes in CUDA 11 and CUDA 12 flavors — you want 12), the folder isn’t actually on PATH/LD_LIBRARY_PATH for the process that runs the model (shell exports don’t reach systemd services or Task Scheduler jobs), or you copied only the single DLL named in the error instead of the full set.

Does this affect Ollama, llama.cpp, or ComfyUI? No — those don’t use CTranslate2 or cuDNN for LLM inference (llama.cpp uses its own CUDA kernels). This error family is specific to CTranslate2-based tools: faster-whisper, WhisperX, whisper-diarization, Whisper-WebUI, wyoming-faster-whisper, and various translation servers.

Is cudnn_ops_infer64_8.dll the same problem? Same mechanism, older generation: a pre-4.5.0 CTranslate2 (or another cuDNN 8 consumer) can’t find cuDNN 8. Either supply cuDNN 8 (pip install nvidia-cudnn-cu12==8.* with ctranslate2 4.4.0) or upgrade the whole stack to current CTranslate2 + torch ≥2.4 and standardize on cuDNN 9. The long-running NVIDIA forum thread on error code 126 is this exact issue.

Sources

• faster-whisper README — GPU requirements, version matrix, and benchmarks — SYSTRAN/GitHub
• cudnn_ops64_9.dll is not found (torch ≤2.3.1 mismatch, fix confirmed) — faster-whisper issue #1080
• Could not locate cudnn_ops64_9.dll — faster-whisper issue #1230
• Unable to load any of {libcudnn_ops.so.9…} — faster-whisper discussion #1114
• CTranslate2 releases — 4.5.0 cuDNN 9 switch, October 22 2024 — OpenNMT/GitHub
• CUDNN 9 support — CTranslate2 issue #1780
• libcudnn_cnn.so.9 load failure in WhisperX — m-bain/whisperX issue #1100
• 2.4.0-gpu is broken, can’t load libcudnn_ops — linuxserver/docker-faster-whisper issue #42
• Could not locate cudnn_ops64_9.dll in Whisper-WebUI — jhj0517/Whisper-WebUI issue #485
• Could not load library cudnn_ops_infer64_8.dll, error code 126 — NVIDIA Developer Forums
• cudnn_ops64_9.dll error via speech_recognition — Uberi/speech_recognition issue #835

Last updated August 6, 2026. Library versions and wheel URLs change; check the faster-whisper README for the current compatibility matrix before pinning.