Part of AI Tools & Automation — automating real work with local AI models.
07_whisper_gpu_benchmark.py · 10 runs per model · whisper.cpp built with Vulkan (GPU) · AMD PRO W7900 48 GB · Windows 11.
Transcribing a YouTube video usually means uploading it to some service and hoping the audio stays private. It does not have to. With yt-dlp and Whisper running locally, you download the audio and transcribe it on your own GPU. This article builds that pipeline and, crucially, measures how fast and how accurate it really is across Whisper model sizes.
The measurements matter, because there is a catch on AMD hardware that most tutorials skip. Getting Whisper onto an AMD GPU takes a specific path, and this article shows the one that actually works.
- yt-dlp downloads audio; Whisper transcribes it — fully offline and private.
- On AMD, the GPU path is whisper.cpp with Vulkan, not faster-whisper.
- Every model size ran faster than real-time on a W7900, from 9.4× (tiny) to 2.0× (large-v3).
- Smaller models stayed within ~7% word error of large-v3, so they are viable for drafts.
Why transcribe locally?
Three reasons push transcription onto your own machine. Privacy comes first: interview recordings, internal meetings, and unpublished videos should not sit on a third-party server. Cost is second: cloud transcription bills per minute, while a local model is free after the hardware. Offline capability is third, because a local pipeline works on a plane or behind a firewall.
The trade-off is setup. You install two tools and, on AMD, pick the right GPU backend. Once that is done, the pipeline runs unattended over any number of files.
yt-dlp — downloading the audio
yt-dlp is the actively maintained fork of youtube-dl. It extracts audio from almost any video URL. Pull just the audio track and convert it to a 16 kHz mono WAV, which is exactly what Whisper expects:
pip install yt-dlp
# Download best audio and convert to 16 kHz mono WAV
yt-dlp -x --audio-format wav
--postprocessor-args "-ar 16000 -ac 1"
-o "audio.%(ext)s" "https://www.youtube.com/watch?v=VIDEO_ID"The 16 kHz mono step matters. Whisper resamples internally anyway, so feeding it the right format up front avoids wasted work and keeps the file small.
The GPU reality on AMD
Here is the catch. The popular faster-whisper library is built on CTranslate2, whose GPU backend is CUDA-only. On an AMD card it silently falls back to the CPU, so you never touch the GPU at all. Many “GPU transcription” guides quietly assume an NVIDIA card.
The path that actually uses an AMD GPU is whisper.cpp compiled with Vulkan. Vulkan is the same backend that drives local LLMs on this hardware, and it treats the Radeon PRO W7900 as a first-class device. Build it once:
git clone https://github.com/ggml-org/whisper.cpp
cd whisper.cpp
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release --target whisper-cliOn startup, the binary confirms the GPU it found:
Free ebook
Free AI Video, Generated Locally
Working scripts and measured benchmarks. Free.
No spam. Unsubscribe at any time.
ggml_vulkan: Found 1 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon PRO W7900 (AMD proprietary driver)
whisper_backend_init_gpu: using Vulkan0 backendThat single line is the difference between a real GPU run and an accidental CPU one. If you do not see it, the model is running on your processor.
Whisper model sizes
Whisper ships in a range of sizes, and the choice is a direct speed-versus-accuracy trade. The table lists the ggml models used in the benchmark.
| Model | Size on disk | Best for |
|---|---|---|
| tiny | ~75 MB | Rough drafts, real-time captions |
| base | ~150 MB | Fast, decent quality |
| small | ~490 MB | Good balance |
| medium | ~1.5 GB | High quality |
| large-v3 | ~3 GB | Best accuracy, the reference |
Benchmark methodology
The benchmark transcribes a fixed 30-second audio segment with each model, ten times per model. It records two numbers. The first is the real-time factor (RTF): audio seconds divided by wall-clock seconds, so higher is faster. The second is word error rate (WER) against the large-v3 transcript, which serves as the reference. That answers the practical question: how much accuracy do you give up for speed?
Speed results — all faster than real-time
| Model | RTF (× real-time) | Wall time (30 s clip) |
|---|---|---|
| tiny | 9.35× | 3.21 s |
| base | 8.14× | 3.68 s |
| small | 6.33× | 4.74 s |
| medium | 3.13× | 9.58 s |
| large-v3 | 1.97× | 15.23 s |
Even the largest model transcribed the clip in about half its duration, which means a one-hour recording finishes in roughly thirty minutes with large-v3, and in a few minutes with the smaller sizes. Each figure includes the model load, because the CLI reloads per call, so a persistent pipeline would run even faster.
Accuracy results — word error vs large-v3
| Model | WER vs large-v3 | Verdict |
|---|---|---|
| tiny | 9.7% | Rough but usable for search |
| base | 7.1% | Solid for drafts |
| small | 7.1% | Good balance |
| medium | 7.1% | Near-reference quality |
| large-v3 | 0% (reference) | Best accuracy |
The pattern is clear and slightly surprising. Base, small, and medium all landed at about 7% word error against large-v3, so they agree closely with each other while diverging from the reference on the same handful of words. Only tiny slipped further, to nearly 10%. For most uses — searchable archives, draft subtitles, meeting notes — that gap is easily worth the speed.
Which model should you pick?
Match the model to the job. For live captions or a searchable archive, tiny or base wins on speed and the errors barely matter. For published subtitles or anything a client reads, use large-v3 and accept the slower run. Small is the sensible default when you are unsure, because it is six times faster than real-time yet within 7% of the reference.
The complete pipeline
Putting it together, the pipeline is two commands: download, then transcribe on the GPU. Once the binary is built with Vulkan, it uses the GPU by default.
# 1. Download and convert audio
yt-dlp -x --audio-format wav --postprocessor-args "-ar 16000 -ac 1"
-o "audio.%(ext)s" "https://www.youtube.com/watch?v=VIDEO_ID"
# 2. Transcribe on the AMD GPU, export SRT subtitles
whisper-cli.exe -m models/ggml-large-v3.bin -f audio.wav -osrt -of transcriptThe -osrt flag writes a timestamped SRT subtitle file. Swap it for -otxt for plain text or -oj for JSON with word-level timings, depending on what the next step needs.
Downloading the Whisper models
whisper.cpp uses ggml-format models, which you pull once from Hugging Face. Grab only the sizes you need, since large-v3 alone is about 3 GB.
cd whisper.cpp/models
# each is a single file, no conversion needed
curl -L -o ggml-small.bin https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-small.bin
curl -L -o ggml-large-v3.bin https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-large-v3.binBecause the models are plain files, you can keep several sizes side by side and switch between them with the -m flag. That makes it trivial to run a fast draft with small, then a final pass with large-v3.
Segmentation and SRT export
Whisper already splits audio into timed segments, which is why SRT export is a single flag. Each subtitle line carries a start and end timestamp, so the output drops straight into a video editor or a web player. For long recordings, the segments also make the transcript skimmable, since you can jump to any moment by its timestamp.
Transcribing a whole channel unattended
The pipeline scales from one clip to a playlist. yt-dlp accepts a playlist or channel URL and downloads every video’s audio, and a short loop then transcribes each file. Because the GPU stays busy and the models stay on disk, an overnight run clears a large backlog.
# download audio for a whole playlist
yt-dlp -x --audio-format wav --postprocessor-args "-ar 16000 -ac 1"
-o "%(title)s.%(ext)s" "https://www.youtube.com/playlist?list=PLAYLIST_ID"
# transcribe every wav in the folder
for f in *.wav; do
whisper-cli.exe -m models/ggml-small.bin -f "$f" -osrt -of "${f%.wav}"
donePoint that at a conference channel or a podcast archive, and you wake up to a folder of searchable transcripts and subtitle files, all produced locally at no per-minute cost.
Frequently asked questions
Does faster-whisper use my AMD GPU?
No. Its CTranslate2 backend is CUDA-only, so on AMD it runs on the CPU. For GPU acceleration on AMD, build whisper.cpp with Vulkan and use whisper-cli.
How fast is transcription on a W7900?
Every model beat real-time. Tiny ran at 9.4× and large-v3 at about 2×, so a one-hour clip takes minutes on small models and roughly half an hour on large-v3.
Is a smaller model accurate enough?
For drafts, search, and notes, yes. Base, small, and medium stayed within about 7% word error of large-v3 in this test. Reserve large-v3 for published subtitles.
Can I transcribe non-English audio?
Yes. Whisper is multilingual and auto-detects the language. Accuracy is highest on well-represented languages, and large-v3 handles the widest range.
What audio format should I feed it?
A 16 kHz mono WAV is ideal. yt-dlp can output it directly with the post-processor arguments shown above, which avoids an extra conversion step.
Summary
A local yt-dlp plus Whisper pipeline transcribes YouTube audio privately and for free. On an AMD W7900, the working GPU path is whisper.cpp with Vulkan, and every model size beat real-time — from 9.4× on tiny to 2× on large-v3. Smaller models stayed within about 7% word error of large-v3, so they are perfectly usable for drafts and search. Reproduce every number with the script: 07_whisper_gpu_benchmark.py.
Companion code — every script and benchmark from this series lives in one repository: github.com/bestin-it/qwen-local-ai-scripts.
Free ebook
Free AI Video, Generated Locally
Run Wan 2.1 in ComfyUI on your own GPU — the scripts I use, measured times, sample clips. No cloud, no API keys.
No spam. Unsubscribe at any time.
Leave a Reply