The Cost of Listening Just Collapsed
Transcription has been the quiet tax on every audio product for a decade. Voice agents, podcast search, meeting notes, call analytics — all of them pay per minute of audio, and the meter never stops running. On Monday, IBM changed the math. It released a speech recognition model that transcribes 3.5 hours of audio using one second of GPU compute.
That number needs a second read. One second of processing on a single NVIDIA H200 chews through three and a half hours of speech. And the model doing it is small enough to run in a browser tab.
What shipped, what it costs in dollars, and where the catches are.
What IBM shipped
The Granite Speech 5.0 Turbo CTC family is a pair of compact English speech recognition models, each with 470 million parameters, built on a CTC architecture that trades scale for raw throughput. IBM announced the release on August 25 (full details are on the IBM Granite team’s post on the Hugging Face blog), with benchmark results on the OpenASR Leaderboard’s public English short-form test sets.
There are two variants, and the split matters if you’re building a product:
- granite-speech-5.0-470m-turboctc — the base model, Apache 2.0 licensed. Use it commercially, ship it, fork it, no phone call required.
- granite-speech-5.0-470m-turboctc-nc — trained on additional data, but licensed CC-BY-NC-SA-4.0. Non-commercial only.
IBM also shipped a WebGPU streaming demo that runs the model live in Chrome or Edge. A 470M-parameter model is small enough that your laptop browser can run inference on it. That alone tells you this isn’t a data-center-only artifact.
The math, translated
The benchmark figure is 12,600 RTFx on an H200 with batched inference. RTFx is real-time factor: how many seconds of audio get processed per second of compute. At 12,600x real time:
- One second of GPU time processes 3.5 hours of audio.
- One minute of GPU time processes roughly nine days of audio.
- One hour of GPU time processes about 525 days of audio.
Run the rental math. Even if an H200 costs you a few dollars an hour on a cloud GPU market, you’re looking at somewhere around a hundredth of a cent per hour of audio transcribed. The exact price doesn’t matter. The order of magnitude does: transcription cost just dropped from “line item on the invoice” to “rounding error.”
For comparison, the usual approach is per-minute API pricing. Every voice agent, podcast search engine, and meeting recorder built on transcription APIs is paying that rate on every second of audio it touches. Most teams ration audio accordingly. They transcribe on demand, cache aggressively, and treat full-archive indexing as a luxury.
That rationing is now optional.
What this changes
Voice agents
Every voice agent pays a transcription toll on every second of every call, twice if the pipeline re-transcribes for context. When transcription costs a hundredth of a cent per hour, the toll disappears. You can afford to keep full text of every call ever handled, indexed and searchable, and feed agents the entire history instead of a context window’s worth of scraps.
Podcast and video search
Full-archive transcription for a media library has always been a budget question. At these rates it’s a cron job. A back catalog of 10,000 podcast hours, which would take 10,000 hours to listen to, processes in under an hour of GPU time. Search over audio becomes a solved infrastructure problem instead of a premium feature.
Meeting intelligence
Meeting recorders have to choose between storing audio (cheap, unsearchable) or transcripts (searchable, metered). With near-free transcription the choice collapses. Keep both and index everything. The products that charged a premium for “AI meeting notes” are now competing with a utility that costs effectively nothing to run.
The catches
This isn’t a free lunch, and four things are worth knowing before you rebuild your stack around it.
First, it’s English-only. If your product runs in Bahasa Indonesia, Spanish, or Portuguese, this specific model doesn’t cover you yet.
Second, the benchmarks are on short-form test sets. Long-form audio, speaker diarization, heavy crosstalk — those are different problems, and IBM’s published numbers don’t claim to solve them.
Third, CTC models trade scale for speed. Raw accuracy on messy, real-world audio is where the bigger models earn their keep. For customer-facing transcripts you may still want a heavier model on the final pass, with Turbo CTC doing first-pass transcription at scale.
Fourth, the faster variant is non-commercial. The Apache 2.0 model is the one you can ship in a product; the -nc model with the extra training data is for research and evaluation.
What to do now
- Try the WebGPU demo. Open it in Chrome or Edge and point it at your own audio. Ten minutes gives you a feel for the quality on your actual data, not test sets.
- Run a cost audit. Pull last month’s transcription API invoice and re-price the same volume at GPU rental rates. The delta is your business case, and it’s probably large enough to justify a migration sprint.
- Prototype the archive play. Take your oldest, most-neglected audio archive and run it through the model overnight. Suddenly you own a searchable text corpus you never budgeted for.
- Plan a hybrid pipeline. Use Turbo CTC for bulk first-pass transcription, then route the slices that matter through your heavier model. Most products only need high accuracy on a fraction of their audio anyway.
The pattern here is the same one that hit image generation and then text: a capability priced as a premium API becomes an open model fast enough to be infrastructure. The teams that come out ahead are the ones building products around audio they previously couldn’t afford to hear. Cheap transcription alone is table stakes the day after it ships.
The meter hasn’t just slowed down. For English transcription, it effectively stopped.
