Why Voice AI Latency Is a Pipeline Problem, Not a Model Problem
Convocart Team ·
A voice AI feels slow when any one stage of the STT → LLM → TTS pipeline blocks on the others — the fix is streaming every stage concurrently and starting to speak before the full response is generated, not just swapping in a faster model.
Why "just use a faster model" doesn't fix it
A voice call feels slow when any single stage of the pipeline blocks on the next one — swapping in a faster LLM only moves the bottleneck, it doesn't remove it. Speech-to-text, the language model, and text-to-speech each add their own delay, and those delays compound if the stages run sequentially instead of overlapping.
Where the time actually goes
Most of a voice AI's perceived latency isn't generation time — it's the gaps between stages: waiting for the caller to finish speaking, waiting for the full LLM response before synthesizing audio, and waiting for that audio to finish generating before playing it back.
Streaming is the real fix
Turn detection needs to fire the moment a caller stops speaking, not after a fixed silence timeout. The LLM's response should stream into text-to-speech sentence by sentence, so the caller hears the first words while the rest of the reply is still being generated. Done well, this is what makes a call feel like a conversation instead of a request-response loop.
Fallbacks still need to be fast
A provider outage shouldn't mean a multi-second hang — a pipeline needs a pre-flight health check and an ordered fallback chain so a failing STT or LLM provider gets swapped before the caller notices anything happened.