time-to-first-audio (TTFA) is critical for realtime voice applications. open source implementations (e.g. vLLM-Omni, SGLang-Omni) are often too slow for production and can have issues with realtime playback if you push for lower latency. we wanted to fix that.
we optimized qwen3-tts, a popular OSS TTS model, to achieve 34 ms p95 TTFA at 10 requests per second on 1 x H100. we open source the implementation and benchmark, as well as a breakdown of how it was done.
Hi there! I actually thought your Dia models were amazing and very natural sounding, I haven’t tried qwen 3 tts yet - has your focus shifted away from building your Dia models and shifted more towards hosting and infrastructure?
narrationbox•Aug 21, 2026
Haven't read the full report yet, just a quick question. Are your numbers for cold start without pre fill or is it after warmed cache?
dominotw•Aug 21, 2026
chatgpt responds super fast but says filler words like 'hmm..' 'let me think' and responds later with delay
zarmin•Aug 21, 2026
its backchanneling frequently makes me laugh to the point of forgetting what i wanted to say. i do like it, it just takes some getting used to, especially since i've been keeping things nice and simple and taking it one step at a time for so long.
jasonjmcghee•Aug 21, 2026
But even then, it's targeting like 300ms not 30ms, right?
wolfgangK•Aug 21, 2026
Isn't ChatGPT benchmaxxing, then ?
Responding "hmm…" isn't actually responding and latency should time to first relevant phoneme.
bellowsgulch•Aug 21, 2026
GPT‑Realtime‑2 is really weird. Perhaps just because it's bidirectional and now has the failure mode as a possibility, it responds too soon with filler at awkward times, and it's generally overeager. I feel like there was plenty of opportunity to just work on latency engineering like this effort.
nowittyusername•Aug 21, 2026
This is right up my alley as ive been building a local voice agent for a year now. Ive tried many different models and have a custom implementation for omni voice that ive tuned for over many months. Ive never been able to achieve faster then 200ms ttfa for that model at 24 steps, but the reason is .... quality. I find that there is a lot of room for improvement in many tts models out there by a huge margin. But there is also a quality hard wall that you eventually hit that the tradeoff of faster latency but lower quality is not worth it. When making a really well sounding voice agent quality of voice, cadence, expression, etc... matters a lot. It will be interesting to try this implementation and see if its quality outputs match my expectations, if so great job indeed.
armcat•Aug 21, 2026
Having built my own voice assistant (https://github.com/acatovic/ova) and having tried many other services and models, I feel the real win is when this is on-device, and by "on-device" I mean being very inexpensive to run on a phone, and not H100. I've now been using Pocket TTS which is super fast, and also Chatterbox and Fish Audio S2 Pro (on the Mac/PC), I feel we are so close, yet so far. The quality is amazing, but can we take this to the next level and make it run on mobile? What would it take?
zuzululu•Aug 21, 2026
this is cool but for agent scenarios unless an LLM bakes in the speech tokens directly, the latency is lost to inference, and this is what makes openai's voice model so interesting
also sweet spot is under 150ms so the remainder is inference latency turn around, a 50ms turnaround including tts-stt would ofc be the dream
that is "this ai agent is indistinguishably present and sentient" area
7 Comments
we optimized qwen3-tts, a popular OSS TTS model, to achieve 34 ms p95 TTFA at 10 requests per second on 1 x H100. we open source the implementation and benchmark, as well as a breakdown of how it was done.
github: https://github.com/nari-labs/nari-qwen3-tts
also sweet spot is under 150ms so the remainder is inference latency turn around, a 50ms turnaround including tts-stt would ofc be the dream
that is "this ai agent is indistinguishably present and sentient" area