cuddly-vr-85751
02/15/2026, 3:58 PMtall-airline-16756
02/15/2026, 3:58 PMcuddly-vr-85751
02/15/2026, 3:58 PMtall-airline-16756
02/15/2026, 3:58 PMtall-airline-16756
02/15/2026, 3:59 PMCPUCreditBalance. If it’s at or near zero, switch to a fixed-performance instance (examples: c6i.large, m5.large, c5.large).
• Local inference / heavy CPU work
◦ VAD, STT, LLM or TTS models can be CPU/memory intensive. If you run heavy models locally on a small instance, inference will be slow. Consider moving inference to a stronger instance or offloading to managed inference (see LiveKit Inference below).
• Network & region mismatches
◦ If your VM is in a different region than the STT/LLM/TTS providers, network round trips add latency. Ensure your VM region is close to your provider endpoints and users.
• Synchronous vs streaming model configuration
◦ If STT/LLM/TTS are used in blocking mode instead of streaming, the pipeline waits for full results, increasing turn latency. Enable streaming where available.
• Session / agent configuration
◦ You currently set preemptive_generation=False. Enabling preemptive_generation=True reduces perceived latency by starting generation earlier (tradeoff: more compute spent if user interrupts).
• Extra CPU load from optional features
◦ Krisp noise cancellation and other processing increase CPU usage—disable if the instance is underpowered.
Quick code/config recommendations you can apply immediately
1. Enable preemptive generation:
session = AgentSession(
vad=ctx.proc.userdata.get("vad"),
preemptive_generation=True, # reduces perceived latency
min_interruption_duration=min_interruption_duration,
false_interruption_timeout=false_interruption_timeout,
)
1. Confirm STT/LLM/TTS are using streaming endpoints (provider-specific) so you can stream partial results rather than waiting for full responses.
2. If using Krisp and you’re on a low-powered instance, try disabling krisp_enabled=True in the SIP participant creation to reduce CPU load.
3. Run a simple latency test locally vs on the VM: if local is fast and VM is slow, it’s infrastructure-related (instance or network).
Observability and metrics to collect (these will pinpoint where latency happens)
• Measure Time-To-First-Token (TTFT) for LLM responses.
• Measure Time-To-First-Byte (TTFB) for TTS audio output.
• Measure VAD / turn-detection latency.
• Check EC2 CloudWatch: CPU, CPUCreditBalance, network I/O, and disk I/O.
• Enable Agent Observability traces so you can see per-session timing for STT → LLM → TTS.
Longer-term / higher-impact options
• Upgrade EC2 instance family to a non-burstable instance (c5, c6i, m5 families).
• Use LiveKit Inference to co-locate inference closer to your workers and reduce public internet hops (reduces TTFT/TTFB and queuing).
• If you need predictable, low-latency inference, use provisioned model capacity from a managed provider or LiveKit Inference.
Helpful diagnostic questions
• What EC2 instance type are you running (example: t3.small, c5.large)?
• Are you using local models for STT/LLM/TTS or external hosted providers (please name them and region)?
• Do you see any CloudWatch alerts or is CPUCreditBalance near zero?
• Is the latency consistent (always high) or intermittent?
• Which step feels slow: detecting end of user speech, LLM response generation, or TTS playback?
If you share the instance type, your STT/LLM/TTS providers and regions, and whether CPUCreditBalance is low, I’ll give a precise, prioritized plan (exact instance choices, config tweaks, and tests) to reduce latency quickly.
Sources: Troubleshooting Latency and Timeout Errors with Turn Detection on AWS | Streamline troubleshooting with Agent Observability | Agent session | LiveKit Documentation | How can I reduce latency in voice agents using STT, TTS and LLM? | LiveKit | Introducing LiveKit Inference: A unified model interface for voice AIcuddly-vr-85751
02/15/2026, 3:59 PMtall-airline-16756
02/15/2026, 4:00 PMCPUCreditBalance metric for your instance. If it’s near zero, the instance is being throttled.
• Check CPU utilization, network I/O, and any spikes around call time to confirm load patterns.
Quick fixes you can apply now
1. Temporarily scale up to a non-burstable instance to confirm the cause:
◦ Recommended: c6i.large, m5.large, or c5.large (start with one of these and test).
1. If you can’t change instance immediately, stop nonessential CPU-heavy features:
◦ Disable Krisp (krisp_enabled=False) to reduce CPU load.
◦ Set preemptive_generation=True in AgentSession to reduce perceived latency (tradeoff: more compute if interrupted).
1. Ensure STT/LLM/TTS providers are in the same region as your EC2 instance to reduce network RTT.
Medium-term improvements
• Move inference off the VM or use LiveKit Inference / provisioned model capacity to reduce queuing and network hops.
• Run multiple worker instances on appropriately sized machines for load balancing.
• Enable streaming STT/LLM/TTS so audio/text are sent/played incrementally instead of waiting for full responses.
Testing checklist after changes
1. Verify CPUCreditBalance rises or throttling stops after switching instance.
2. Measure time breakdown: VAD → STT → LLM TTFT → TTS TTFB.
3. Compare latency on t3.medium vs upgraded instance. If latency drops significantly on the upgraded instance, the t3 throttling was the root cause.
If you want, tell me:
• whether you can switch instance types now,
• which STT/LLM/TTS providers and regions you’re using,
and I’ll recommend an exact instance size and a short test plan to validate the fix.cuddly-vr-85751
02/15/2026, 4:09 PMtall-airline-16756
02/15/2026, 4:09 PMCPUCreditBalance.
◦ If local device is CPU-starved (e.g., laptop fan ramps up), that will slow inference.
Immediate, high-impact fixes to try now
• Enable streaming for STT/LLM/TTS if available so you get incremental results instead of waiting for full outputs.
• Set preemptive_generation=True in AgentSession to reduce perceived response time.
• Disable optional CPU-heavy features while testing (e.g., Krisp noise cancellation).
• If local machine is weak, test on a stronger machine or a non-burstable cloud VM (c5/c6i/m5) to compare.
If logs show LLM or TTS is slow
• Use a provider endpoint in the same region as your agent.
• Consider switching to LiveKit Inference or a provisioned model endpoint to reduce queuing and network hops.
If logs show STT or VAD delays
• Ensure VAD is tuned correctly (not waiting too long for end of speech).
• Use streaming STT and verify packet sizes / buffer settings aren’t adding artificial delay.
Short tests you can run (5–10 minutes)
1. Local stub test: Run the agent but stub STT/LLM/TTS. If latency disappears, external providers are the issue.
2. Cloud vs local compare: Run the same test on a c5.large or m5.large VM for comparison. If cloud is faster, your local device is the limit.
3. Single-step timing: Make a call that causes exactly one STT->LLM->TTS cycle and inspect the timestamps.
Data I need from you to give exact next steps
• When local is slow, what machine are you using? (CPU model, RAM)
• Which STT / LLM / TTS providers are you using and which regions? (e.g., OpenAI us-east-1, Deepgram eu-west-1)
• From your timestamp logs (if you can add a few) which step had the highest delay? If you haven’t instrumented yet, I can show exactly where to add 3-4 logging lines in your code.
• Do you have the agent running with preemptive_generation=False now? (I saw False in your code)
If you want, I can:
• Provide the exact logging snippets to insert around VAD/STT/LLM/TTS calls.
• Recommend an EC2 instance size based on your provider choices and expected concurrency.
• Give a short test script to simulate a call and produce the timing breakdown automatically.
Pick one: share the provider/region details or say “send logging snippets” and I’ll give the minimal code to time the pipeline.
Sources: How can I reduce latency in voice agents using STT, TTS and LLM? | LiveKit | Introducing LiveKit Inference: A unified model interface for voice AI | Troubleshooting Latency and Timeout Errors with Turn Detection on AWS | examples/frontdesk | livekit/livekit_composite | DeepWiki | Playing Audio | LiveKit Documentation