Real-time factor explained: the ratio that turns audio length into processing time

Real-time factor, written RTF, is processing time divided by audio length. An RTF of 0.5 means one hour of audio takes 30 minutes to process. Anything below 1.0 outruns the recording. This page gives the formula and measured examples from speech and video. It names the two conventions that trip buyers up. It closes with a method you can run on your own audio.

Ask how long it takes to transcribe 30 minutes of audio and the ranking pages answer a different question. They time a person. Typist guides land near four hours of work per hour of audio. So 30 minutes of speech costs about two hours of typing. The machine answer needs one number and one multiply. This platform's Japanese-first speech lane, hayamimi-stt, measured an effective RTF of 0.39 on 29 August 2026. Thirty minutes of similar audio is 30 times 0.39. That is about 11.7 minutes of processing, serially. It runs roughly ten times faster than the typist figures, and it comes from a ratio you can check yourself.

The unit deserves a full explanation, because the market uses it badly. One vendor's RTF counts seconds of compute per second of audio. Lower is faster. Another vendor's RTF counts seconds of audio per second of compute. Higher is faster. The same three letters point in opposite directions. This page names both conventions and shows the conversion. It then does what no ranking page does. It measures one clip two ways, prices the difference, and says when the whole metric is wrong for your job.

The formula: processing time over audio length

The classic definition comes from speech engineering. An official vendor document states it cleanly. Microsoft's embedded speech guide defines RTF as "the ratio of the processing time to the audio length" (Azure Speech docs, read 2026-10-28). Its example: one minute of audio processed in 30 seconds has an RTF of 0.5.

Written as arithmetic:

RTF  =  processing time  /  audio length

Both times use the same unit. Seconds over seconds. Minutes over minutes. The ratio carries no unit of its own. That is what makes it portable. It puts a phone running a small model and a datacenter GPU running a large one on the same scale.

The formula also runs backwards, and that is its practical value. Multiply audio length by RTF and you get the processing time. An hour of audio at 0.25 is 60 times 0.25, or 15 minutes. A two-hour deposition at 0.6 is 120 times 0.6, or 72 minutes. Every "how long will my file take" question reduces to one multiply. You need a trusted RTF for the system and the audio.

The three regimes: faster, at pace, slower

RTF 1.0 is the boundary. The three regimes around it name three engineering situations.

Below 1.0, the system outruns the recording. Processing finishes before the audio would finish playing. RTF 0.39 means one second of audio needs 0.39 seconds of compute. The surplus is headroom. You can absorb bursts, queue retries, or serve several streams from one lane. The Azure guide states the operating rule: for real-time interactive speech, a device "should have an RTF of 1 or lower" (Azure Speech docs). Anything higher cannot keep up with arriving audio.

At exactly 1.0, the system runs at pace. One hour of audio takes one hour to process. That is useless for batch. For live work it is the exact boundary: each segment finishes just as the next arrives. There is no slack for a queue, a network wobble, or a hard passage of audio.

Above 1.0, the system falls behind. On live audio a backlog grows without bound. On finished files it only means waiting. An RTF of 2.0 on a 30-minute recording is an hour of processing. Batch jobs tolerate values far above 1.0. Live systems do not. Know which side of 1.0 your workload sits on before you shop for a number.

Two conventions share the RTF name

Here is the trap no ranking page untangles. The letters RTF carry two definitions in the wild. They are reciprocals of each other.

The speech-recognition convention is the one above. Compute over audio. Lower is faster. Most ASR engineering uses it, and so does this platform. The other convention flips the fraction and counts audio processed per unit of compute. Hugging Face's audio course teaches it as RTFx: audio duration divided by processing time, where values above 1.0 beat real time (HF audio course). The Open ASR Leaderboard paper pins the same formula for its tables: "RTFx = Total duration of audio / Transcription time" (arXiv 2510.06961, read 2026-10-28).

NVIDIA muddies the naming further. Its speech docs name the flipped form RTFX outright. The definition there: "duration of audio transcribed divided by computation time" (NVIDIA Speech NIM docs, updated 2026-10-07). Its older synthesis post calls the flipped form RTF, in plainer words: "the real-time factor (RTF) is the latency divided by the wall clock time, the number of seconds of audio generated per second" (NVIDIA developer blog, June 2020).

So a number labeled 61.4 and a number labeled 0.39 can describe equally fast systems. The conversion is one division. This platform's 0.39 pin, inverted, is 20.32 divided by 8.0. That is about 2.54 in the audio-per-compute convention. Read a speed claim and do this check before comparing it with anything. Which quantity sits on top? Which direction is better? A page that does not say is not comparable.

A measured example: one clip, 0.39, and the 30-minute answer

The numbers in this section are this platform's own. They were taken on 2026-08-29, on a 20.32-second clip of clean English speech. The clip went to the hayamimi-stt lane as fast as the connection allowed. The last final transcript arrived about 8.0 seconds after audio start. Eight seconds of wall time for 20.32 seconds of audio is 8.0 divided by 20.32. The effective RTF is about 0.39.

Run the planning arithmetic from there. Thirty minutes of audio at 0.39 is 30 times 0.39. That is about 11.7 minutes of processing on one request stream. A full hour is about 23.4 minutes. The typist ratio, four hours of work per hour of audio, is roughly ten times slower than this lane's figure on comparable audio.

Two qualifiers keep the number honest. First, the conditions were kind: clean audio, one clip, no queue. Dense crosstalk, strong accents, and concurrent requests all push RTF up. Treat any single figure, ours included, as a planning number. Re-measure on your own audio. Second, the pin belongs to the streaming-capable lane. The whisper batch lane on this platform has no published RTF pin. Whisper processes audio through a 30-second receptive field. Any long file is chunked and stitched inside, whatever host runs it (model card).

For scale, published leaderboards put whisper-large-v3 at an RTFx near 146 on short-form English. The hardware: one A100 at batch 64. That is an RTF near 0.007, roughly 25 seconds for a full hour (ASR Leaderboard paper). It is a datacenter batch result on clean benchmark audio. It is not what a phone does. It is not what a queued shared lane does. Hardware and conditions live inside every RTF number. The next section shows how much they move.

The same clip paced at real time: a different RTF

The 0.39 figure has a sibling from the same session, and the pair teaches the metric's most-ignored lesson. The same 20.32-second clip was sent again. This time it was paced at 1x, exactly as a live microphone delivers it. The last final arrived about 21.8 seconds after start. That is 21.8 divided by 20.32. The effective RTF is about 1.07.

Same model. Same audio. Same day. The ratio moved from 0.39 to 1.07. The difference is pacing. Push audio ahead of real time and the engine chews through it faster than it arrives. Deliver audio at speaking pace and the engine idles between words. Wall time then tracks the audio length almost exactly. The processing work did not slow down. The clock did.

The first-word numbers tell the same story. Pushed ahead of real time, the first partial transcript landed 342 ms after audio start. Paced at 1x, it landed 1284 ms after start. The engine cannot transcribe speech it has not yet received. Anyone comparing a batch RTF with a live product's budget is comparing those two legs without knowing it.

The practical rule: quote the pacing with the number. A batch RTF describes a finished file thrown at the engine. A paced RTF describes a live stream. It can never fall far below 1.0 end to end, because the audio itself takes real time to arrive. Microsoft's guide draws the same line from the measurement side: file-based RTF "shouldn't be analyzed in streaming input mode" (Azure Speech docs).

Why short files read slower: fixed overhead

Real jobs include more than inference. Upload takes time. Queues take time. Retries take time. None of it scales with audio length. It inflates the ratio on short files and vanishes on long ones.

A worked illustration with round numbers, labeled as such. Suppose a lane processes audio linearly at 0.39. Suppose it also carries 30 seconds of fixed overhead per request, upload and queue combined. A 5-minute clip costs 30 seconds plus 300 times 0.39. Total: 147 seconds. Its end-to-end RTF is 147 divided by 300, about 0.49. A 60-minute file costs 30 plus 3600 times 0.39, or 1434 seconds. End-to-end RTF: about 0.40. Same lane. Same linear speed. Two different published ratios.

This is why vendor speed numbers quarrel. A benchmark that measures pure inference prints one ratio. A product that measures request to response prints another. Short clips read worst. When two numbers for the same system disagree, look for the clock window first. Inference only, or end to end? Then look at clip length.

Parallel chunks change wall time, not the ratio

Serial processing is a choice, not a law. Split the file and run the pieces at once. Total compute stays the same. Wall time collapses.

Take the 30-minute file at RTF 0.39 again. Serially it costs about 11.7 minutes. Cut it into ten chunks of 3 minutes each and run ten requests at once. Each chunk costs 3 times 0.39, about 70 seconds. The finish line approaches the slowest chunk, not the sum. Ten parallel requests turn a 12-minute wait into roughly 70 seconds, plus each request's fixed overhead.

The ceiling on this trick is the longest chunk and its own RTF. One slow passage of audio holds the whole batch. The chunk count is also bounded by the lane's request limits and by your concurrency budget. The chunking itself has rules: cut on silence, overlap suspect boundaries, offset timestamps on merge. The full method, with a runnable client, is the long audio guide. The per-provider caps that force chunking are tabulated in long audio transcription limits.

RTF outside speech: synthesis and video

The ratio generalizes to any medium with a duration. Two neighboring fields use it with their own numbers.

Text to speech flips the stream's direction. The input is text. The output is audio with a duration. NVIDIA defines its real-time factor for synthesis as seconds of audio generated per second of compute. In 2020 it reported 61.4 on an A100: 7.3 seconds of speech in under 120 ms (NVIDIA developer blog). Note the convention again. Bigger is faster there. A lane that renders the whole request before the first audio byte makes RTF a waiting-time problem. A 300-second chapter at 61x costs about 5 seconds of compute. The listener hears nothing until those 5 seconds pass. This platform's speech lanes enforce first-byte walls for that reason. The numbers live in the TTS streaming and cloning limits guide.

Video and robot perception use the same math with frames. A 30 frame-per-second camera stream delivers 30 frames per second of real time. A vision model that processes 19 frames per second has an RTF of 30 divided by 19, about 1.58. It falls behind live video. The VLA-Perf study anchors the field's bars to ordinary cameras, which deliver 24 to 60 frames per second (VLA-Perf paper, February 2026). It measures one robot policy at 19.0 Hz on a Jetson module and 61.7 Hz on an A100. At 61.7 Hz, the same policy's RTF against a 30 fps stream is about 0.49. It keeps up, with headroom. The inference frequency guide carries that whole rate stack, control loops included.

When RTF is the wrong number

RTF is a throughput ratio. It answers "how long for the whole file." It does not answer "when does the first word appear." For live products, that second question is the product.

Streaming vendors make the point in their own docs. One major vendor's guide sets three separate targets. First partial text inside a few hundred milliseconds. RTF below 1.0, so the engine keeps pace. A complete spoken turn inside about one second. Another vendor's metrics article rates RTF's relevance to voice agents as basically none. For live audio you need it under 1.0. Beyond that, the numbers that matter are partial latency and final latency. Read together, the two positions give the table below.

The one-line version: batch planning is an RTF problem. Live experience is a latency problem. Capacity is a throughput problem. Pick the row before picking a vendor.

Measure it yourself: the clock discipline

Any RTF you did not measure is marketing. The method is short. The official guidance on it is specific.

Use file-based input, never a live microphone, for a pure ratio. Microsoft's measurement guide restricts file-based RTF to file mode. It says to collect multiple samples and read percentiles, because thermal throttling and background load move the number (Azure Speech docs). Fix what you can. One clip. One model. One hardware target. A stated clock window, from request start to last final. Run the clip enough times to see the spread. Report the percentile that matches your risk, not the best run.

A local example shows the arithmetic on published numbers. The faster-whisper benchmark transcribes 13 minutes of audio in 16 seconds. The setup: int8 batching on one consumer GPU (project README, read 2026-10-28). That is 16 divided by 780. The RTF is about 0.02, or about 49 times real time in the flipped convention. The same README's openai-whisper baseline on the same clip and card takes 2 minutes 23 seconds. That is an RTF of about 0.18. One division each. Two runtimes you can compare without trusting either's marketing page.

On this platform, here is a timed first call against the whisper batch lane. The ratio comes from the response's own reported duration:

# one timed batch call: RTF = wall seconds / audio seconds reported
wall=$(curl -sS $IRONSTRATUM_BASE_URL/v1/audio/transcriptions \
  -H "Authorization: Bearer $IRONSTRATUM_API_KEY" \
  -F file=@clip.wav \
  -F model=whisper \
  -w '%{time_total}' -o response.json)
audio=$(grep -o '"duration": *[0-9.]*' response.json | grep -o '[0-9.]*$')
awk -v w="$wall" -v a="$audio" \
  'BEGIN { printf "audio %.1f s, wall %.1f s, end-to-end RTF %.2f\n", a, w, w/a }'

Read the result as an end-to-end figure. The wall clock includes upload, queue, and processing. It reads slower than a pure inference ratio, exactly as the overhead section predicts. Run it on three clips of very different lengths. The fixed overhead shows up as the intercept. Rates for the lane render from the catalog in the fence below. A key from the signup page and a small wallet balance is all the setup the measurement needs.

What speed costs: RTF against the meter

Speed and price are separate axes. The metering unit decides whether RTF can touch your bill at all.

cost of a job        =  H x P_stt            (audio-second metering)
cost on wall clocks  =  H x RTF x P_wall     (open-connection metering)

H       =  audio hours in the job
P_stt   =  per-audio-hour rate from the fence above
P_wall  =  the vendor's per-clock-hour rate, where a clock meter applies
RTF     =  the measured ratio for your audio and load

Under audio-second metering, the formula has no RTF term. A lane at 0.2 and a lane at 0.8 bill identically for the same file. Making the engine faster saves waiting, not money. Under open-connection metering, the RTF term is the bill. Wall time is audio times RTF. Every 0.1 of ratio improvement cuts cost by the same fraction. One sensitivity line covers both. On clock meters, harder audio raises cost directly through the ratio. On audio meters it does not.

This platform meters speech lanes per audio second. The whisper and hayamimi-stt lanes sit on the first row. The billing-shape contrast across the vendor field, including who bills the time a connection stays open, is tabulated in the streaming session limits guide. The crossover math between renting a fast lane and owning a GPU is its own page: whisper local vs API break-even.

Decision rules

Frequently asked questions

What is a good real-time factor?

For live work, under 1.0 is the entry bar. The engine must finish each stretch of audio faster than it arrives. This platform's shared lane measured 0.39 on clean audio, which leaves headroom for queues and bursts. Batch benchmarks on single fast cards run far lower. The local example on this page computes to 0.02. For batch work there is no "good" value, only an acceptable wait. RTF 2.0 on an archive of old meetings may be fine if it runs overnight. A number means nothing without its conditions: audio difficulty, concurrency, pacing, and the hardware or lane that produced it.

Is a lower or higher RTF better?

It depends which convention the number uses. This is the most common trap in the field. In the speech-recognition convention, used on this platform, RTF is compute divided by audio. Lower is faster. 0.39 beats 0.8. In the flipped convention, often written RTFx, the number is audio per compute. Higher is faster. 146 beats 20. Hugging Face's leaderboard and NVIDIA's docs use the flipped form. Check which quantity sits on top of the fraction before comparing a claim with anything.

How long does it take to transcribe 30 minutes of audio?

With a machine, the answer is 30 minutes times the lane's RTF. On this platform's hayamimi-stt lane, that is about 11.7 minutes, serially, on one request stream. The basis: an effective RTF of 0.39, measured 2026-08-29. Run the file as parallel chunks and wall time approaches the longest chunk's processing time, not the total. Ten chunks of 3 minutes each finish in roughly 70 seconds at the same ratio. The typist answers that rank for this question, about four hours per hour of audio, describe a person, not a machine.

What is RTFx, and how do I convert it to RTF?

RTFx is the inverted real-time factor. Audio duration divided by processing time. Values above 1.0 beat real time. The Open ASR Leaderboard defines it as total audio duration over transcription time. To convert either way, divide one into the other. An RTF of 0.39 is an RTFx of about 2.54, from 20.32 divided by 8.0. An RTFx of 146 is an RTF of about 0.007. Carry the name with the number. A bare "RTF 60" from a synthesis vendor means faster than real time by their convention, not a system 60 times too slow.

Does RTF matter for streaming transcription?

Only as a floor. A live stream needs an effective RTF at or below 1.0, so the engine never falls behind the speaker. A paced stream pins the end-to-end ratio near 1.0 almost by definition, because the audio arrives in real time. What live products feel is first-partial latency and final latency: when the first words appear, and when a finished sentence is confirmed. Vendor docs themselves rank RTF's live relevance far below those two. Use RTF to check the engine can keep pace. Then buy on latency.

Does a faster RTF save money?

Only under one billing shape. If the vendor meters audio seconds, cost is audio length times the rate. RTF never enters the arithmetic. A fast lane and a slow lane bill the same for the same file. If the vendor meters wall-clock time, such as the whole time a connection stays open, cost is audio times RTF times the rate. The ratio is then a cost multiplier. Ask which meter applies before paying for speed. This platform's speech lanes meter audio seconds.

How do I measure RTF on my own audio?

Use a finished file, not a live microphone. Fix what you can: one clip, one model, one device. Clock from request start to the last final transcript. Divide by the clip's duration. Repeat enough runs to read a percentile, not a best case. Thermal throttling and background load move the number. State the clock window with the result. An end-to-end figure including upload and queue reads slower than a pure inference figure. The timed snippet above computes the end-to-end form against this platform's whisper lane in four lines of shell.

Is RTF the same as latency?

No. Latency is a delay at a point: the milliseconds until the first partial, or until a final lands after speech ends. RTF is a ratio over a whole file. A system can have excellent RTF and poor latency, by batching hard and answering late. The reverse shows up on short clips, where fixed overhead dominates. The two answer different questions. The decision table above maps each question to its metric.

Rates and metering units for every lane sit on the pricing page. To put a real clip through the arithmetic: sign up. Create a key, load a small wallet balance, and run the timed snippet on your own recording.

Last verified: 2026-10-28