Real-time factor
In one sentence
Real-time factor (RTF) is how long a system takes to process audio divided by the duration of that audio, so a value below 1 is faster than real time and a value above 1 is falling behind, and it governs cost and concurrency rather than conversational responsiveness.
Definition
Real-time factor is how long a system takes to process audio compared with the length of that audio.
An RTF of 0.5 means processing ten seconds of audio takes five seconds, which is twice as fast as real time. Lower is better.
Real-time factor is the standard efficiency metric for speech processing, and it answers a different question from latency. The useful comparison is against 1, not against zero.
How to read it
- Below 1 means faster than real time. Processing keeps up with incoming audio.
- Equal to 1 means exactly keeping pace, with no margin.
- Above 1 means falling behind, which is fatal for streaming and merely slow for batch.
Why it is not the same as latency
- A system can have excellent real-time factor and poor latency, if it processes quickly but only starts after receiving a large chunk of audio.
- Real-time factor measures throughput efficiency; latency measures responsiveness.
- For conversational voice, latency is the metric that decides the experience and real-time factor is the metric that decides cost and capacity.
Where it actually matters commercially
- Capacity planning. Real-time factor sets how many concurrent streams a given amount of compute can carry. An RTF of 0.1 supports roughly ten times the concurrency of an RTF of 1.0 on the same hardware.
- Cost per minute. Compute time is billable, and real-time factor is directly proportional to it.
- Batch throughput, such as transcribing an archive of recordings.
The margin requirement for streaming
- A streaming system needs real-time factor comfortably below 1, not merely below it.
- Load spikes, garbage-collection pauses and competing processes all eat margin.
- A system operating at RTF 0.9 will fall behind under stress and never recover within a session, because it has no capacity to catch up.
Hardware dependence
- Real-time factor is a property of the model and the hardware together. A figure quoted without a hardware specification is not meaningful.
- This is a common gap in published figures.
Common misconception
That good real-time factor implies good latency. They are related and distinct. A batch system with an excellent real-time factor is useless for conversation, because it does not start until the audio has ended.
Why it matters commercially
Real-time factor drives infrastructure cost and concurrency capacity, which are the numbers that decide unit economics. For a buyer it is largely invisible; for a platform operator it is a primary constraint.
In voice specifically
A person speaks in real time, so a live agent has to process at least as fast as the words arrive and hold spare capacity for the moment traffic spikes. A batch transcriber can take its time because nobody is waiting, which is exactly why a great batch real-time factor says nothing about whether a conversation will feel responsive.
Where AsqVox fits
Real-time factor is invisible to a visitor and real to the economics. Processing efficiency is one contributor to per-minute cost, which is the denominator in voice unit economics, so it sits under the pricing rather than being anything a visitor to an AsqVox-powered site ever sees.
Visual
Faster than real time, or falling behind
Compare against 1, not against zero. And leave margin.
Statistics
Every figure carries its source and year. Vendor numbers are labelled as vendor numbers, and where no reliable figure exists this page says so rather than borrowing one.
Real-time factor is processing time divided by audio duration: below 1 is faster than real time and above 1 is falling behind. It is a standard, hardware-dependent efficiency metric in speech processing.
Processing time / audio durationindustry rangeStandard speech-processing efficiency metric, 2026 - A definition rather than a measurement. The two facts that matter when reading it are that the useful comparison is against 1, not zero, and that it is a property of the model and hardware together.
All-in production voice cost lands around USD 0.11 to USD 0.33 per minute, and processing efficiency is one of the contributors to that figure.
$0.11 to $0.33 per minuteindustry rangeReported all-in production voice cost, 2026 - An industry-reported band rather than a single measured price. Real-time factor moves the compute portion of it, not the whole.
Platform base rates run around USD 0.05 per minute for Vapi, USD 0.07 for Retell and USD 0.09 for Bland.
Vapi $0.05, Retell $0.07, Bland $0.09 per minvendor claimPlatform published base rates, 2026 - Published by the platforms themselves and covering the base rate only, before the model, recognition and synthesis costs that make up the all-in figure.
The 2026 Coval and Gradium benchmark found a speed against accuracy tradeoff across speech providers, with no single leader.
No single leaderindependentCoval and Gradium benchmark, 2026 - The closest available evidence that real-time factor and accuracy trade against each other, which is why an efficiency number read without an accuracy number is only half the picture.
Published real-time factor figures frequently omit the hardware configuration, which makes them non-comparable, because the metric is a property of the model and the hardware together.
-no reliable figureA figure without a hardware specification is not so much wrong as meaningless, and it is the most common defect in a quoted real-time factor.
There is no standard benchmark reporting real-time factor alongside accuracy for speech recognition providers, despite the two trading against each other.
-no reliable figureSo the efficiency-versus-accuracy tradeoff has to be measured on your own stack and your own hardware, because no published table lines the two up under matched conditions.
Examples
In practice
A platform running at RTF 0.85 handles normal load and degrades under traffic spikes, with sessions falling progressively behind and never recovering. Profiling shows no single bottleneck, simply insufficient margin. Moving to a smaller model at RTF 0.3 costs a small amount of accuracy and eliminates the failure mode entirely, while roughly tripling concurrency on the same hardware.
The everyday version
Real-time factor is whether the system can process speech faster than people can speak it. If it can, it keeps up. If it only just keeps up, it will fall behind the moment things get busy and will not catch up again. It mostly matters for what the service costs to run, rather than for how it feels.
Usage
Who says it
- Speech engineers and infrastructure teams.
- It appears in model documentation and capacity planning, and is rarely a buyer term.
Where it turns up
- In a spec sheet, next to throughput, concurrency limits, hardware requirements and cost per minute.
Common misuse
- Quoting real-time factor without a hardware specification.
- Treating good real-time factor as evidence of good latency.
- Operating close to RTF 1 without margin for load variation.
Questions people ask
What does a real-time factor of 0.5 mean?
It means the system processes ten seconds of audio in five seconds, which is twice as fast as real time. Below 1 is faster than real time and the system keeps up with incoming audio; equal to 1 is exactly keeping pace with no margin; above 1 is falling behind, which is fatal for a streaming conversation and merely slow for batch work. Lower is better, and the useful comparison is against 1, not against zero.
Is real-time factor the same as latency?
No. Real-time factor measures throughput efficiency and latency measures responsiveness. A system can post an excellent real-time factor and poor latency if it processes quickly but only starts after receiving a large chunk of audio. For conversation, latency decides the experience and real-time factor decides the cost and the concurrency. A batch transcriber with a great real-time factor is useless for a live call, because it does not start until the audio has ended.
Why does a streaming voice system need real-time factor well below 1?
Because it needs margin. A system running at real-time factor 0.9 keeps up until a load spike, a garbage-collection pause or a competing process eats the little headroom it has, and then it falls behind and never catches up inside the session. Comfortably below 1, around 0.2 to 0.3, leaves room to absorb those spikes. Operating close to 1 without margin is a failure waiting for the first busy moment.
Why is a real-time factor figure meaningless without hardware?
Because real-time factor is a property of the model and the hardware together, not of the model alone. The same model posts a different figure on a faster or slower processor, so a number quoted with no hardware specified cannot be compared with another. It is the most common defect in a published real-time factor, and the first thing to ask for when one is quoted.
Last reviewed 31 July 2026. Written and reviewed by Dhruv Dholakia, founder of AsqVox.