Skip to main content
Regional infrastructure is where each part of a call runs: the edge that receives the caller’s audio, the worker, and every model service the worker waits on. Each one is its own setting. Where your models run matters as much as where you deploy your agent. A nearby worker still waits on distant speech and reasoning services. Review the whole path from the caller to STT, the LLM, and TTS, for every provider you use. On this page:

​
Quickstart

On LiveKit and Pipecat, set params.world_part on each SLNG listen or speak model to choose its gateway:
agent.yaml
That is the speech half. The worker has its own region, set in targets.yaml, and the two do not have to match. The rest of this page is which location each part of the call has, and how to choose it.

​
Why model proximity matters

A voice turn crosses several network boundaries: the caller sends audio through a media or telephony edge, the worker sends it to STT, the worker calls the LLM and tools, and TTS produces the audio that returns to the caller. Long trips between these services add delay throughout the conversation, even when the models themselves are fast. Start with where your users are. Keep the media edge, worker, and model services close to them and to one another where your providers offer that choice. Apply the same review to tools and other services the agent waits on. Moving only the worker leaves any long trips to remote models in place. Use geography as a starting point, then measure the time from the caller finishing a sentence to hearing the first reply from your users’ locations. Network routes, model availability, and load can change which choice is fastest. Compare both typical calls and slow calls; a regional endpoint does not change the model’s own processing time.

​
Choose a location for every model

The same review applies whether you use SLNG or bind a provider directly. Choose each model separately, including fallback models where configured: Unmute supports direct speech providers such as Deepgram, Cartesia, ElevenLabs, and Soniox, and reasoning providers such as OpenAI, Anthropic, and Mistral. The linked model pages list the providers supported by each target. Regional settings depend on the provider, model, account, and framework integration; there is no shared region parameter for all of them. For a direct provider, check its current documentation for regional endpoints or deployments, then use the settings supported by the selected integration. Do not copy another provider’s parameter names. Some services select their location automatically or offer no regional choice. Measure the route you actually use before deciding whether to change providers or model deployments.

​
Three region settings

SLNG speech, routing, and deployment now share region names. LiveKit keeps its own worker names. Each setting is still independent of the others. None alone guarantees data residency: model providers, media, tools, traces, and storage have their own locations. A nearby speech gateway does not prove where its model runs. LiveKit’s compute names come from its agent region list.
​
string
Accepts the speech gateway values in the table. Omit to use the plugin’s default endpoint. An empty or unknown value is refused. Do not combine it with params.base_url or params.slng_base_url.
​
string
required
Accepts the same 13 world parts as speech. Required on a Context Router think binding; omission is refused. It selects the router endpoint independently. The old world_part_override key is refused; use world_part.

​
Separate the regional settings

Each part of the call has its own location: Setting one row does not set the others. A gateway location also does not by itself guarantee where the underlying model processes data. Tools, tracing, and storage keep their own locations too. LiveKit configures realtime region pinning separately from agent deployment regions. For Pipecat Cloud WebSocket telephony, Unmute derives the regional endpoint from deployment_region; that endpoint must match the worker’s region. See Pipecat’s regions guide. Carrier routing remains a separate choice.

​
Choose a speech gateway

SLNG provides 13 regional speech gateways through one model setting. It is set per model, and it gives both speech roles the same configuration shape across the two frameworks.
​
world part code
The SLNG speech gateway an SLNG listen or speak model connects through. One of the 13 values below. Set it on each model separately. Omitting it keeps the existing default URL.
Unmute turns the value into the host {world_part}.api.slng.ai in generated services. For the eu-north in the quickstart above, it emits slng_base_url="eu-north.api.slng.ai" on LiveKit and base_url="eu-north.api.slng.ai" on Pipecat for both speech models. The plugin receives the host without a scheme or path; Unmute consumes world_part rather than passing it to the plugin. This setting changes generated SLNG speech services on LiveKit and Pipecat. Choose the worker’s deployment_region separately. The SLNG hosted target keeps its own deployment settings.

​
Available SLNG world parts

All 13 world parts below work for SLNG listen and speak models on LiveKit and Pipecat. Set the world part on each model separately. Omitting world_part keeps the existing default URL.

​
SLNG reasoning uses the same world parts

For a think model with provider: slng, the Context Router serves the same 13 world parts as the table above, under the same key: params.world_part. So eu-north on a speech binding and eu-north on a think binding are the same place, and a package can keep listening, thinking and speaking in one world part. The LLM behind the router keeps its own provider settings. SLNG deployment uses these same 13 region names. The location of each service is still chosen separately.

​
Place the worker near your users and models

Set the worker location in targets.yaml, using each platform’s own region names:
​
platform region name
Where the generated LiveKit or Pipecat worker runs. Written per target in targets.yaml, in that platform’s own region names. Pipecat accepts one. LiveKit accepts one region as a scalar or several as a list.
targets.yaml
The worker region and model gateway codes do not need to match. For example, a worker in eu-central can call SLNG speech through eu-north.api.slng.ai. Choose nearby locations from the platform’s current LiveKit or Pipecat region list, then measure the full call path.

​
One worker region or several

Pipecat accepts one deployment_region per target. A second Pipecat region is a second target and agent name. LiveKit accepts either one region as a scalar or several regions as a list:
targets.yaml
Unmute emits one LiveKit create command per listed region. The deployments keep one dispatch name, so LiveKit may send a caller to another declared region when the nearest deployment is at capacity. For strict worker locality, use separate agent names and explicit dispatch. See LiveKit’s multi-region deployment guidance. Adding worker regions leaves the model settings as authored. Review the model endpoints each deployment will call so that a nearby worker also has a short path to its STT, LLM, and TTS services.

​
Troubleshooting

​
The compiler refuses a world_part value

An empty, non-string, or unknown value is refused. The old speech values na, eu, and ap are refused too. There is no automatic mapping from the old broad areas. Fix: choose one of the 13 values in the table above explicitly.

​
The compiler refuses world_part next to a URL

params.base_url and params.slng_base_url cannot be combined with params.world_part. Fix: remove the explicit URL or the world part.

​
The router refuses a world_part_override

The router used to take four names of its own, eu, us, india and indonesia, under a key of its own. It takes the 13 world parts now, under params.world_part, like speech. Fix: rename the key and write a world part. See SLNG reasoning uses the same world parts.

​
A nearby worker is still slow

Setting one row of the table above does not set the others, and moving only the worker leaves any long trips to remote models in place. Fix: review the model endpoints each deployment calls, then measure the full call path rather than the worker’s own region.

​
Where to go next

Optimizing your agent

Measure what the caller waits for.

Reasoning model

Choose the model that decides what to say.

Speech to text

Choose the model that listens to the caller.

Text to speech

Choose the model that speaks to the caller.

LiveKit Cloud

Deploy one worker region or several.

Pipecat Cloud

Deploy one worker region per target.