Voice Design. Live today.

← Back to Blog

How a benchmark change produced a faster TTS model

5 min read
Scatter plot titled

Median TTFA against average word error rate per model, Coval TTS benchmark, 480 runs per model. The dotted line is the Pareto frontier; the dashed crosshair marks Gradium. Captured September 9, 2026. See the live leaderboard.

A joint post by Coval and Gradium.

On June 3, 2026, Gradium's time to first audio on the Coval TTS leaderboard moved from 171.9 ms to 429.6 ms. No model had shipped and no serving infrastructure had changed. Gradium's own instrumentation still reported 148 ms of network and synthesis latency, unchanged from the week before.

Coval had changed their measurement methodology, and had started counting the silence at the start of the stream.

Why Coval measures the full stack instead of isolating the model

Most latency benchmarks try to isolate the model from the servers around it. Coval takes the opposite position. A benchmark should reflect how the whole stack feels to a user, because that is what the customer experiences, so Coval includes the network round trip in the latency number. Coval then goes one step further and processes the returned audio to find when speech actually starts.

The change came from a pattern Coval kept seeing. Some models start sending audio back very quickly, and the audio opens with a second of silence. Because conventional benchmarks measure the time until any response, those models score well on them but feel slow in production.

The metric is perceived TTFA, the time an enqueue-and-play client waits before it hears sound:

formula
TTFA = (first audio chunk arrival - synthesis start)
       + leading silence inside the stream before the first audible sample

How the first audible sample is detected

Most latency benchmarks measure the time between sending a request and starting to receive streamed audio back. The clock stops irrespective of what that audio contains. Perceived TTFA also assembles the streamed audio into a single clip and processes that clip to find the moment that a response begins.

Conventionally this is done with a VAD model, trained to identify when speech starts or ends. But many TTS models start their response with an in-breath before beginning to speak. People perceive this breath as the start of a response but VAD models often don't.

To match the perception with the reality Coval instead uses an RMS threshold over a sliding window. RMS essentially asks "what was the average loudness?" After normalization any result below zero is inaudible and any result above is audible. The perceived onset of speech is then the first 10 ms window where RMS exceeds 0.01 on a normalized signal, everything before is leading silence. This leading silence is then added to the conventional TTFA measurement to give perceived TTFA. The full definition and an open-source implementation are published in Coval's benchmark methodology.

Coval shipped the change with an explicit warning about comparability. Adding the leading-silence term shifts every provider's reported TTFA upward by its own offset, near zero for models that emit audible audio immediately and several hundred milliseconds for models that front-load silence. Rows recorded before and after the change are not comparable, and are distinguished by the runner commit recorded on each run.

What the metric exposed in Gradium's model

Gradium's arrival time was competitive, contrary to its perceived latency. The model was emitting a median of 225 ms of inaudible samples before the first phoneme, and as much as 655 ms in the tail. Following the benchmark methodology evolution, Gradium prioritized reducing this and trained a new model to produce hearable audio from the very beginning of the sequence.

The model that came out of that work is now Gradium's default. Its leading silence measures 0 ms: the first 10 ms frame it returns is already above the audibility threshold, so nothing is added to its arrival time. On today's board its median TTFA is 214 ms, roughly 170 ms faster than the model it replaced.

That is the part worth looking at across the whole board. Median values, in milliseconds:

Median TTFA split into its parts, per model, ranked fastest first. Leading silence is the hatched portion of each bar and accounts for 28% of TTFA across the board. Gradium's bar has no hatched portion.

Median TTFA split into round trip and leading silence, per model. Coval TTS leaderboard, captured September 9, 2026 at 22:40 CEST.

Gradium's default model returns zero leading silence, so its first frame is already audible. Everyone else pays a silence tax on top of their network time, and for some it is most of the gap between them and the top: Cartesia Sonic 3.5 has the second-fastest round trip on the board at 151 ms and lands fourth on TTFA, because 134 ms of what a listener waits for is silence.

How evaluation design changes what labs optimize

Labs optimize what is scored. When the metric is time to first byte, the cheapest way to move it is to send something early, and the thing sent does not have to be audible. The metric improves and the product does not.

A benchmark that isolates the model from the stack tells you about the model. A benchmark that measures the stack the way a user hears it tells you about the product. The second is harder to build, because it requires processing the output rather than timing the response, and it returns worse numbers for everyone on the board. Coval's change cost comparability with a year of historical rows. It is also the change that produced a faster model.

Reproducing the benchmark

The benchmark is open source under the Apache 2.0 license. The runner, the pinned datasets, the provider matrix and the normalization pipeline are all in the repository, and every leaderboard row exposes the runner_sha it was produced at, so a single cell can be reproduced at the exact commit with your own provider API keys.

Gradium's current model is available through the API and in Studio, with Pipecat and LiveKit supported directly. If you find hard latency or pronunciation cases, we'll use them to improve our next models: send them on Discord.