TTS latency benchmark: 50 ms to first audio

On 18 August 2026 we measured four text-to-speech vendors from a single AWS instance in us-west-1, over one continuous 498-second window, with no parallelism, no retries and nothing discarded.

The headline: Gepard 1.0 returns its first audio byte in 49 to 50 milliseconds over WebSocket, and that number does not move when the text gets longer.

We built Gepard, so treat this as a vendor benchmark and check it. The corpus, the client code, the raw logs and a SHA-256 manifest are published precisely so that you can.

Which TTS API has the lowest time to first audio?#

Median time to first audio byte over WebSocket, in milliseconds, across three text-length buckets:

That is 2.1x faster than Cartesia, the next quickest, 3.7x faster than ElevenLabs Flash and 4.4x faster than Gradium.

The p95 holds up, which matters more than the median for anything user-facing: 55.4, 52.4 and 69.8 ms across the three buckets. A tail that stays inside 70 ms is the difference between a voice agent that always feels immediate and one that feels immediate most of the time.

Why does the flat line matter more than the low one?#

Because a latency figure that changes with input length is a latency figure you cannot design around.

Look at the shape rather than the ranking:

Gepard sits on 49-50 ms whether it is given 40 characters or 360. Cartesia moves from 94 to 123 ms depending on length. If your agent sometimes reads back a two-word confirmation and sometimes a full policy summary, a length-dependent vendor gives you a first-audio time that varies by a third between turns, and you have to budget for the worst case on every turn.

The reason is architectural. A model that buffers text before starting has to wait for more of it; a model that starts generating on the first tokens does not. Gepard is built to start speaking as text arrives, which is why the line is flat rather than merely low.

How fast is the complete response, not just the first byte?#

First audio is what makes a voice agent feel alive. Total delivery time is what determines whether the next turn can start.

Median end-to-end, WebSocket, in milliseconds:

On the long bucket the picture changes and we are going to say so: Gepard finishes in 674 ms and ElevenLabs Flash in 666 ms, which is a tie inside the noise. Cartesia takes 2,207 ms and Gradium 6,403 ms on the same text.

What exactly was measured?#

The method, in enough detail to argue with.

Four decisions did most of the work of making this fair.

True streaming endpoints only. Every vendor here also has a whole-file endpoint. Measuring time to first audio against an endpoint that returns a complete file is meaningless, so /tts/bytes, only_audio:true and their equivalents were deliberately not used.

Identical audio format. All four were asked for raw 22,050 Hz PCM, verified as clean PCM in the artifacts rather than assumed. 22,050 Hz happens to be Gepard's native rate, so we measured what that mandate costs the others: about 5.7 ms for Cartesia and nothing measurable for the rest. It does not account for the gap.

Each vendor at its own documented lowest-latency setting. Vendor defaults are not equivalent, so leaving them untouched would have measured their buffers rather than their models. ElevenLabs got auto_mode: true and flush: true. We left optimize_streaming_latency at 0 on purpose, because levels 1 to 4 progressively disable their text normaliser and using them would have flattered ElevenLabs unrealistically. Nothing that changes speaking rate or voice character was touched on any vendor.

Stock catalogue voices. No cloned or custom voice on any vendor.

What this measurement does not tell you#

A benchmark this narrow leaves real things out, and a few of them cut against us. Time to first byte is not time to first sound, and a stream that opens with a moment of silence wins the metric while the caller still hears nothing; measured to the first audible sample, our ranking is not first. Gepard also delivers audio in a handful of large chunks where others send many small ones, which costs nothing in playback but does commit more audio before the server can react, so barge-in responsiveness is a separate question from this one. Cold-start numbers that include connection setup narrow our lead over Cartesia considerably. And our real-time-factor figures are the best in every cell, which we mention only to say that RTF rewards slow speech and padding and we do not think it means much. All of this is quantified in the full report rather than left as a caveat.

None of it changes the WebSocket first-audio result, which is the number a voice agent actually feels.

Repeating this#

The point of publishing the manifest is that you should not have to believe us.

# 30-sentence corpus, frozen and checksummed
sha256sum corpus/corpus_v1.json
# rebuild and re-validate every statistic about the corpus
python corpus/build_corpus.py

Run it from your own region, with your own keys, against your own text. If your numbers disagree with ours, we would rather know. Benchmarks that only the vendor can reproduce are marketing with a table in it.

If you are choosing a vendor on more than speed, the pricing comparison covers the other axis, and how to choose a TTS covers the metrics this post deliberately ignores.