We have been using google/gemma-4-31b-it through LiveKit Inference successfully from our EU workload.
Today (September 1), the same project/model was working normally until at least 17:33 UTC. Starting at approximately 18:08 UTC, requests suddenly began returning:
HTTP 403
type=inference_region_restricted
retryable=false
region=eu
model google/gemma-4-31b-it is not available in the data region
serving this request (eu)
We made no changes to the model, project, region, or inference configuration.
To rule out our voice/PSTN pipeline, we reproduced the issue with a minimal standalone request directly through livekit.agents.inference.LLM.chat() using:
model: google/gemma-4-31b-it
prompt: Responde únicamente OK.
no tools
We repeated the probe about 11 minutes later and received the exact same 403.
LiveKit’s documentation currently lists Gemma 4 31B as available through LiveKit Inference, while the status page shows Global Inference as operational.
Has the availability or regional routing policy for google/gemma-4-31b-it in EU changed today, or is there currently an issue affecting this model in the EU data region?
I have also submitted a Service Outage report with the relevant session IDs.
@proyecto.reservasia, This is server-side, not your config. The docs list google/gemma-4-31b-it as the default Inference LLM with no region caveat and the model ID is valid, so a 403 inference_region_restricted is the gateway refusing the model in your data region (Inference LLMs). It is also not just you: another user in this thread reports the same EU 403 today, with Deepgram down too, so it reads as a broader EU Inference event.
Inference serves US-hosted models first and is still expanding coverage, so a model can be US-served but not EU (regional deployments). Whether EU availability actually changed today is Cloud-internal, so the team must confirm it. Your outage report is the right channel; since the status page still shows Inference operational and no GitHub issue tracks this, make sure it landed.
While you wait, retrying will not help a hard region 403. Fail over to your own provider key, which calls the provider directly and skips the Inference gateway:
import os
from livekit.agents import AgentSession, inference, llm
from livekit.plugins import google
session = AgentSession(
llm=llm.FallbackAdapter([
inference.LLM(model="google/gemma-4-31b-it"),
google.LLM(model="gemini-2.5-flash", api_key=os.environ["GOOGLE_API_KEY"]), # bypasses the gateway
]),
)
The fallback must be a direct-provider plugin, not a second inference.LLM, since another Inference model can hit the same region gate. Same for STT: deepgram.STT(model="nova-3", api_key=...) with your own key…
We completed a rollout of stricter data-region enforcement in LiveKit Inference. Gemma 4 31B is served from an EU deployment, but that deployment was missing the region label the check looks for, so the gateway saw no eligible EU backends.
@Adrian_Cowham shall we expect a fix soon? I migrated my cloud agent to a U.S. region, but my local dev environment remains broken as I’m located outside north america.
there might be a bug then because I’m continuing to get this with with deepgram/nova-3
‘message’: ‘failed to create session: failed to create provider instance for session 461bd617-0efa-4544-a182-a51c60bad46b: STT model deepgram/nova-3 is not available in the data region serving this request (eu)’, ‘code’: 2006}
but this confirms I should move away from xai tts. thanks. Please let me know about deepgram nova 3
@n do you have Inference Region Restrictions enabled in settings? that is whats causing the filter to happen. if you don’t intend to use it you can disable
The same minimal EU probe that was consistently returning 403 inference_region_restricted is now succeeding again with 200 OK, with no configuration changes on our side.
Thanks, really appreciate the detailed explanation and the fallback suggestion.
Gemma is working again on our side after LiveKit rolled out the fix. We repeated the exact same minimal EU probe with no configuration changes and it now returns 200 OK.
The direct-provider fallback is a very useful point as well — especially to avoid having LiveKit Inference itself as a single point of failure. We’ll definitely take that into account for production.
How can we pin an EU region for a specific model? Or does it automatically happen based on caller/user location/region? And it chooses the closest model?
