Your voice agent probably isn't slow because of the LLM.

Reddit r/AI_Agents News

Summary

A developer debunks the common belief that LLM latency is the primary cause of slow voice agents, explaining that delays often stem from earlier stages like audio capture, VAD, and STT. They recommend logging specific latency metrics and testing various STT/TTS providers and orchestration frameworks to diagnose issues.

Hot take after debugging a few voice agent flows: Everyone blames the LLM first. But a lot of the “this voice agent feels slow” problem comes before the LLM even gets a stable transcript. The delay can be from: mic/audio capture WebRTC / SIP / telephony VAD STT first partial STT final transcript endpointing LLM first token tool call TTS first audio audio playback interruption handling If you only measure total response time, you learn nothing. I’d log: user_speech_start stt_first_partial stt_final llm_first_token tool_call_start tool_call_done tts_first_audio playback_start barge_in_detected For STT, I’d test Deepgram, AssemblyAI, Smallest AI Pulse, Speechmatics, Soniox, OpenAI realtime/transcribe. For TTS, ElevenLabs, Cartesia, Deepgram Aura, PlayHT. For orchestration, LiveKit/Pipecat/Vapi/Retell depending on how much control you want. The weird part is that the fastest demo stack is not always the best production stack. Under real calls, endpointing and partial stability matter a lot. How are you guys measuring latency? p50? p90? p95? Or just “does it feel human”?
Original Article

Similar Articles

6 months running a production voice agent for service businesses. The latency math is way harder than the demos suggest.

Reddit r/ArtificialInteligence

After 6 months running a voice AI agent for service businesses, the author reveals that real-world latency is bimodal (median ~800ms, p95 ~2.4s) and this p95 determines user perception. Issues like VAD misfires, function call degradation with long prompts, and TTS quality matter more than LLM choice, with multilingual support adding significant costs.