Real-time factor (RTF): the glossary of speech speed terms

Real-time factor, written RTF, is processing time divided by audio length. Both times use the same unit. Below 1.0, the system outruns the recording. The flipped form, RTFx, divides the other way. There, higher is faster. This glossary defines both. It also defines the latency, throughput, pacing, and clock-window terms around them. Every entry carries one worked number and one link.

The letters RTF arrive with a collision attached. Search them and the first page of results mixes two unrelated meanings. One is the speed ratio this page defines. The other is Rich Text Format. That document file format shares the three letters and dominates generic searches. A reader who types rtf transcription meaning is usually separating the two. This page owns the speed meaning.

Each entry below stands alone. Read the one you met in a vendor table, or read the set. The full mechanism has its own page. The formula walk, the overhead arithmetic, chunking, and the measurement method live in real-time factor explained. This corner is the vocabulary layer.

The glossary in one table

Every row carries a dated source. The Azure, Deepgram, Google, Hugging Face, and NVIDIA rows cite vendor or primary documentation. The platform rows cite this platform's own dated measurements.

Real-time factor, the core entry

The real-time factor of a system is simple. It is the processing time divided by the length of the audio. Both times are named in the same unit. Microsoft's embedded speech guide states the definition. The RTF of a device "is the ratio of the processing time to the audio length" (Azure Speech docs, ms.date 2026-02-25, read 2026-10-28). Its worked example: one minute of audio processed in 30 seconds is an RTF of 0.5.

Lower is faster in this convention. An RTF of 0.5 finishes a 45-minute meeting in 22.5 minutes. The arithmetic is 45 times 0.5. The ratio carries no unit of its own. That is the point. A phone chip and a datacenter card land on one scale.

The ratio also runs backwards as a planning tool. Multiply audio length by RTF and you get the processing time: an hour of audio at an RTF of 0.1 takes 6 minutes, and a 30-minute file at that ratio takes 3 minutes.

The definition dates to speech engineering. It is the convention this platform prints. The companion explainer carries the full formula walk and the measurement method.

The three regimes: below 1.0, at 1.0, above 1.0

RTF 1.0 is the boundary, and the three bands around it are three different engineering situations.

The Azure guide sets the operating rule for live work. The device "should have an RTF of 1 or lower." A value above 1 "means that the device can't keep up with the audio input" (Azure Speech docs). Batch jobs tolerate values far above 1.0. A finished file only waits. Live systems do not. A backlog grows without bound. Know which side of 1.0 the workload sits on before quoting a number.

RTFx and the x notation: the same idea, flipped

RTFx is the inverted real-time factor. The formula divides audio length by processing time. Higher is faster. Hugging Face's audio course teaches it in the evaluation chapter. The course example: 100 seconds of audio handled in 10 seconds of compute. That is an RTFx of 100 divided by 10, which is 10 (HF audio course, read 2026-10-28). The Open ASR Leaderboard pins the same formula, "RTFx = Total duration of audio / Transcription time." Its bench runs one A100-SXM4-80GB at batch size 64. It reports whisper-large-v3 at 146 on short-form English and the faster Turbo variant at 200 (arXiv 2510.06961, paper dated 30 March 2026). A leaderboard 200 converts to an RTF of 1 divided by 200. That is 0.005.

NVIDIA prints the flipped form under the plain RTF name. Its speech performance docs measure "RTFX (duration of audio transcribed divided by computation time)" (NVIDIA Speech NIM docs, updated 2026-10-07). Its 2020 synthesis post does the same, reporting a "61.4x RTF" on an A100 (NVIDIA developer blog, June 2020). So a 61.4 and a 0.39 can describe equally fast systems. Convert with one division. Then compare. The companion explainer walks that conversion with worked numbers.

The x phrasing, as in 33.7x real time, is RTFx said aloud. The same post reports a V100 delivering 6.7 seconds of speech in 200 milliseconds. Their label: "33.7x faster than real-time" (NVIDIA developer blog, June 2020). Carry the name with the number. A bare RTF 60 from a synthesis vendor means faster than real time, by their convention.

First token, first byte, first partial

Latency terms answer a different question than RTF. The question is when output appears. First byte and first token name the delay from request start to first output. First partial names the first draft text on a live stream. A partial is draft text. Later finals confirm or replace it.

Microsoft names the lived version: user-perceived latency. Its definition is "the time between a word being spoken and the word being shown in the recognition results" (Azure Speech docs). Vendor bars in the wild are tight. Deepgram's latency docs target transcription latency at 300 milliseconds or less for streaming workloads. The same guide lists end-of-turn detection at 100 to 500 milliseconds (Deepgram docs, read 2026-10-28).

This platform's own pin: a 20.32-second clip, sent as fast as the connection allowed. The first partial transcript landed 342 milliseconds after audio start, measured 2026-08-29. The same clip, fed at speaking pace, pushed the first partial to 1,284 milliseconds. The engine cannot transcribe speech it has not received.

One caution travels with this entry. A September 2026 benchmark of 23 streaming models puts it flat: "The fastest transcript is not the fastest completed interaction," and a fast wrong answer makes the whole interaction slower (pipecat benchmark, dated 2026-09-24). A first-partial number means little without the accuracy of the words behind it. The live-side caps and failure shapes sit in the streaming session limits guide.

Final latency

Final latency is the delay from the end of speech to confirmed final text. It is the number a live product feels. Draft partials can arrive early. The user still waits for a stable sentence.

A September 2026 benchmark of 23 streaming models ranks on this clock. Its definition: "TTFS is Time To Final Segment: the gap between the caller finishing speaking and the stable transcript your LLM can act on" (pipecat benchmark, dated 2026-09-24). The reported medians ran from 221 to 392 milliseconds. The naming differs by vendor: final latency, time to final, time to final segment. All point at the same clock. Speech ends. Confirmed text lands.

This platform's pin, same 2026-08-29 session. The mean gap from a last partial to its final was 370 milliseconds pushed and 485 milliseconds paced. The first final landed 1,366 milliseconds after audio start, pushed leg. Both numbers describe one clip, one lane, one day. The failure shapes that stretch this number sit in the streaming session limits guide.

Throughput

Throughput is work units finished per unit of time. Examples: searches per second, clips per hour, audio hours per hour. It describes the whole lane. RTF describes one request. Throughput numbers answer capacity questions. Latency numbers answer experience questions.

This platform's classification lane, gliner-extract, measured a peak of 5.33 searches per second at 8 concurrent requests, on 2026-09-25. Run 1,000 searches at that peak. The arithmetic says 1,000 divided by 5.33, about 188 seconds of wall time. The lane bills per search. The count is also the meter: 1,000 inputs are 1,000 searches, at any speed.

Benchmark tables often print throughput in the RTFx unit. NVIDIA's performance page states it directly: "Throughput is measured in RTFX" (NVIDIA Speech NIM docs). Read such a table twice. A per-request ratio and a whole-lane figure are different quantities. The latency side of the same lane class is tabulated in the rerank pricing and latency guide.

Concurrency and percentiles

Concurrency is the count of requests in flight at once. It moves every other number on this page. More requests at once raises total throughput. It usually raises per-request latency too. The work shares one lane.

The platform's own pair of pins shows the move. The gliner-extract lane measured a median latency of 1,047 milliseconds at one concurrent request. At eight, the median was 2,202 milliseconds. Both pins are dated 2026-09-25. That is about 2.1 times slower per request at the higher load. A speed claim without its concurrency is a number with no context.

Percentiles say where in the spread a figure sits. p50 is the median. p95 is the point that 95 percent of runs beat. Microsoft's measurement law is explicit: "measure multiple samples and analyze the distribution across percentiles" (Azure Speech docs). The stated cause: thermal throttling and background load move the number. A best-run figure and a p95 figure can both be honest and far apart. Quote the percentile that matches the risk.

Streaming RTF and batch RTF: pacing changes the ratio

Pacing is how the audio was fed. Pushed audio is a finished file sent as fast as the connection allows. Paced audio arrives at speaking rate, like a live microphone. The same engine prints very different ratios under the two feedings. The clock changes, not the work.

Google's streaming law makes paced audio a requirement, not a choice. The rule: "the audio must be sent at a rate that approximates real time." A stream there can stay open for at most 5 minutes (Google Cloud STT v2 quotas, read 2026-10-28). Live protocols assume live pacing.

The platform pin, one line. The same 20.32-second clip measured an effective RTF of 0.39 pushed and 1.07 paced, on 2026-08-29. A paced stream cannot finish far ahead of its own audio. Its end-to-end ratio sits near 1.0 almost by definition. Quote the pacing with the number. Otherwise the number is incomplete. The full two-leg walk lives in the companion explainer.

Wall time, audio time, and the clock window

Wall time is elapsed clock time. Audio time is the duration of the recording. The clock window is the span the vendor actually measured. It is the quietest source of speed-claim disagreement.

Azure ships the cleanest exhibit: two official metrics that differ only by window. RealTimeFactor "includes audio loading time." StreamingRealTimeFactor "excludes audio loading time." Both are file-mode metrics. The guide says the value "shouldn't be analyzed in streaming input mode" (Azure Speech docs).

Audio time has its own hidden structure. Whisper processes sound through a "receptive field of 30-seconds," in the publisher's own words. A long file is chunked and stitched inside whatever host runs it (model card, read 2026-10-28). The card names two long-form algorithms, sequential and chunked. They trade speed against accuracy. An end-to-end figure you time yourself includes that stitching, plus upload and queue. A pure inference figure never does. When two numbers for one system disagree, look for the clock window first. Clip length is the second place to look. The long-file side is tabulated in long audio transcription.

One clip through every term

One real measurement, every entry at once. The clip: 20.32 seconds of clean speech. It was sent pushed to the platform's streaming speech lane on 2026-08-29.

The same clip paced at speaking rate took about 21.8 seconds of wall time. The effective RTF is 21.8 / 20.32 = 1.07. One recording, one day, one lane. Nine rows, nine distinct numbers. That is the vocabulary in action.

Read a speed claim in four questions

One claim can need all four rows. A live caption product quotes a first-partial latency to feel fast. It quotes an RTF under 1.0 to prove it keeps pace. It quotes a final latency to prove sentences settle. The companion explainer maps each question to its metric in full.

The vocabulary on this platform

As of 2026-10-28, the speech-to-text lanes are whisper, the batch lane, and hayamimi-stt, the streaming lane behind the 0.39 pin and the cadence numbers above. The whisper lane publishes no RTF figure. A ratio you time yourself against it is end to end. It is wall clock over reported audio seconds. The snippet below prints both conventions from one call.

Both speech lanes meter per audio second. The bill follows the length of the recording, not the processing time. The extraction lane gliner-extract meters per search, the input count. Its measured peak of 5.33 searches per second is dated 2026-09-25. Rates and metering units for every lane render on the pricing page.

# pip install requests
# one batch call; prints RTF and RTFx from the response's own duration field
import os, time, requests

url = os.environ["IRONSTRATUM_BASE_URL"] + "/v1/audio/transcriptions"
hdr = {"Authorization": "Bearer " + os.environ["IRONSTRATUM_API_KEY"]}
with open("clip.wav", "rb") as f:
    t0 = time.perf_counter()
    r = requests.post(url, headers=hdr, files={"file": f},
                      data={"model": "whisper"})
    wall = time.perf_counter() - t0
r.raise_for_status()
audio = r.json()["duration"]
print(f"audio {audio:.1f} s, wall {wall:.1f} s")
print(f"RTF {wall/audio:.2f} (lower is faster)")
print(f"RTFx {audio/wall:.1f} (higher is faster)")

Read the output as an end-to-end figure. Upload and queue sit inside the wall clock. Run it on three clips of very different lengths. The fixed overhead shows up as the intercept. A key from the signup page and a small wallet balance is the whole setup.

Frequently asked questions

What does RTF mean in transcription?

Real-time factor, the speed ratio: processing time divided by audio length. It is not the file format. The three letters RTF also name Rich Text Format, a document format that dominates generic searches. That collision is why the transcription meaning needs its own corner. In speech work, an RTF of 0.5 means one minute of audio processes in 30 seconds. The official definition and example come from Microsoft's embedded speech guide. Every vendor speed table descends from that same ratio.

Is a lower or higher RTF better?

It depends on which quantity sits on top of the fraction. In the speech-recognition convention, compute over audio, lower is faster. 0.39 beats 0.8 there. In the flipped convention, often written RTFx, audio over compute, higher is faster. 146 beats 20 there. NVIDIA's docs and the Hugging Face leaderboard use the flipped form. Convert with one division before comparing any two claims. A page that does not say which way its number points is not comparable.

What is a good RTF for speech-to-text?

For live work, under 1.0 is the entry bar. The engine then never falls behind the speaker. Microsoft states the rule as an RTF of 1 or lower for real-time interactive speech. For batch work there is no universal good value, only an acceptable wait. Harder audio and heavier load push the number up. This platform's streaming lane measured 0.39 on clean audio on 2026-08-29. Treat any single figure, ours included, as a planning number. Re-measure on your own recordings.

What is the difference between RTF and latency?

RTF is a ratio over a whole file. Latency is a delay at one point in time. On the same 20.32-second clip, the lane ran an RTF of 0.39. Its first partial still took 342 milliseconds to appear. A system can hold a strong RTF and answer late on short clips. A weak RTF can coexist with fast first words. Live products buy on latency after RTF clears the 1.0 bar.

What does x times real time mean?

It is the flipped convention said aloud. Thirty-three times real time means 33 seconds of audio handled per second of compute. NVIDIA's 2020 synthesis post reports a V100 generating 6.7 seconds of speech in 200 milliseconds. Their label: 33.7 times faster than real time. In RTF terms that system sits near 0.03. The x phrasing and RTFx name the same fraction. Higher is faster in both.

Does RTF change what I pay?

Only under one billing shape. Where a vendor meters audio seconds, cost follows the length of the recording. RTF never enters that arithmetic. A fast lane and a slow lane bill the same for the same file. Where a vendor meters open connection time, wall time is the bill. Wall time is audio length times RTF, so the ratio becomes a cost multiplier. Ask which meter applies before paying for speed. This platform's speech lanes meter audio seconds. Current rates sit on the pricing page.

Every speed number on this page carries its date and its source. The formula walk and the measurement method: real-time factor explained. Live-side caps and failure shapes: streaming session limits. Long files and chunking: long audio transcription. Rates for every lane: the pricing page. To put a real clip through the vocabulary: sign up, create a key, run the snippet.

Last verified: 2026-10-28