Thanks — this is a great question. I’ll explain how region placement works for an agent deployed in ap-south (Mumbai) and what to expect for STT, TTS, and LLM inference providers. Short answer • Inference providers are not automatically guaranteed to run in the same region as your agent. They can be in different regions depending on the provider you choose. • Deepgram STT is an exception: Deepgram models are available co-located in Mumbai, so STT can be served from ap-south for supported models/languages. • Region pinning does not force third‑party inference to run locally; it only restricts developer application data and media to the pinned region if the provider supports that region. Detailed explanation 1) Agent region vs. inference provider region • Your agent’s deployment region (for example,

ap-south

) controls where LiveKit runs your application and media streams. • Inference (STT/TTS/LLM) is performed by model providers. Those providers host models on their own infrastructure, which may be in different geographic regions (often U.S. data centers by default for many providers). • Because providers run their own infrastructure, LiveKit cannot universally guarantee the provider will be in the same region as your agent. 2) Deepgram (STT) — co-location in ap-south • LiveKit includes an integrated deployment of Deepgram models in Mumbai. If you select a supported Deepgram model-language pair (for example

deepgram/nova-3-general:en

,

:hi

, or

:multi

), STT requests can be served from the Mumbai endpoint, giving much lower latency for users in India and nearby regions. • This routing to the Mumbai Deepgram endpoint happens automatically for supported models — no extra configuration is required. 3) LLMs and TTS (other providers) • Common LLM and TTS providers (OpenAI, Google, ElevenLabs, Baseten, etc.) typically host models in their own regional infrastructure and may not have endpoints in ap-south. That means inference requests may be routed to other regions (for example, U.S. data centers), which can increase round-trip latency. • If a provider offers regional endpoints, using those endpoints is the way to get inference nearer to your agent, but availability depends on that provider. 4) Region pinning and inference data • Region pinning restricts where Developer Application Data and User Content (media streams) are stored/processed for compliance. • Region pinning does NOT guarantee inference will be processed in that region unless the inference provider has servers in the pinned region. If the provider is outside the pinned region, inference data will be transmitted and processed where the provider operates. Practical guidance to minimize latency and meet compliance • Use Deepgram STT when you need low-latency STT in ap-south (supported models are already deployed in Mumbai). • For LLM or TTS needs, check whether the provider offers a regional endpoint near ap-south. If they do, choose that endpoint; if not, expect higher latency. • Measure actual latency (Time To First Token and turn latency) in a staging test with your chosen providers to see real-world performance. • If data residency or compliance is required for inference data, confirm with the provider whether they offer regional hosting in ap-south — region pinning in your LiveKit project alone will not force third-party providers to process data locally. If you'd like, I can: • Check specific provider-model combos you plan to use (name the STT/TTS/LLM providers and models) and tell you whether those models are available in ap-south. • Suggest a short test plan/commands to measure latency from your agent to the chosen providers. Which inference providers and models are you planning to use? Sources: Introducing LiveKit Inference: A unified model interface for voice AI | Liv... | Deepgram STT | LiveKit Documentation | Sub-processors | LiveKit | Data Processing Addendum | LiveKit | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit, with interactive elements