LLM Router: The Three Things That Name Actually Means
.png)
Diseñado para la velocidad: ~ 10 ms de latencia, incluso bajo carga
¡Una forma increíblemente rápida de crear, rastrear e implementar sus modelos!
- Gestiona más de 350 RPS en solo 1 vCPU, sin necesidad de ajustes
- Listo para la producción con soporte empresarial completo
Why the term is confusing
Ask three teams what their LLM router does and you get three answers that do not overlap. One runs GPT-4o on both Azure and OpenAI and wants traffic to survive an outage. One got their bill and wants the easy 70% of requests served by something cheaper. One has a German subsidiary whose prompts must not leave the EU. All three need different configuration, and two of the three would get nothing from what the others built.
The taxonomy is worth stating precisely, because it is what most llm routing content skips:
The tell is what each reads to decide. Load balancing reads infrastructure state, model selection reads the request body, data routing reads metadata and identity. Three inputs, so three features — and they compose rather than compete.
Kind one: load balancing across interchangeable targets
This is the oldest and least interesting sense of the word, which is why it is also the most reliable. You have several ways to reach the same capability — azure/gpt-4o and openai/gpt-4o, or two deployments in different regions — and you want requests spread across them so no single failure is your failure.
The premise is that every target is equivalent for correctness. Any could serve the request; you are choosing on availability, capacity, and speed. That is what makes llm load balancing safe to automate. And provider latency is not stable enough to ignore — it varies by model, region, provider, and hour:

Chart of measured latency variance across several LLM providers over one month
TrueFoundry configures this on a virtual model — a name your application calls, like my-group/production-chat, with one routing strategy and a list of real targets behind it. Three strategies qualify as load balancing:
TrueFoundry AI Gateway ofrece una latencia de entre 3 y 4 ms, gestiona más de 350 RPS en una vCPU, se escala horizontalmente con facilidad y está listo para la producción, mientras que LitellM presenta una latencia alta, tiene dificultades para superar un RPS moderado, carece de escalado integrado y es ideal para cargas de trabajo ligeras o de prototipos.



Controle, implemente y rastree la IA en su propia infraestructura
Blogs recientes
Preguntas frecuentes
¿Qué es un LLM router?
Un LLM router se sitúa entre su aplicación y sus modelos y decide qué modelo o despliegue atiende cada solicitud. El término abarca tres tareas distintas: el balanceo de carga entre destinos intercambiables para obtener rendimiento y failover, la selección de modelo entre uno más barato y otro más potente, y el enrutamiento de datos, que restringe dónde puede procesarse una solicitud y dónde se guardan sus logs. Cada una lee entradas diferentes, así que la primera pregunta es cuál necesita.
¿Ahorra dinero un LLM router, y cuánto?
El enrutamiento por selección de modelo sí; el balanceo de carga y el enrutamiento de datos, por lo general, no. El Auto Routing de TrueFoundry obtuvo en pruebas un ahorro de costes del 69 % conservando el 98 % de la calidad en 550 prompts evaluados, y hasta un 80 % con tráfico similar al de producción. El ahorro depende de su mezcla de tráfico: desglose la métrica de decisiones de enrutamiento por nivel resuelto y multiplique la proporción de cada nivel por la diferencia de precio.
¿Cuál es la mejor configuración de LLM router para un equipo que acaba de empezar?
Enrutamiento basado en la complejidad sobre un único modelo virtual con el clasificador heurístico gratuito, porque no requiere cambios en la aplicación ni gasto en clasificador. Añada una cadena de prioridad entre dos proveedores cuando una caída le haya costado algo. Añada enrutamiento de datos cuando alguien pregunte adónde van los datos.
¿Puedo desplegar TrueFoundry en mi propia VPC o en on-prem?
Sí: en VPC, on-prem, entornos air-gapped, híbridos o en varias nubes, sin que ningún dato salga de su dominio.
¿Cuánto añade el gateway a la latencia de las solicitudes?
Aproximadamente 3-4 ms de sobrecarga, gestionando más de 350 RPS con una sola vCPU, en más de 1.000 LLM compatibles. La excepción es el clasificador LLM opcional, que añade una llamada real a un modelo antes de reenviar la solicitud.
¿Se integra con mi pila de observabilidad?
Sí. El gateway es compatible con OpenTelemetry y se conecta a Grafana, Datadog o Prometheus. Cada llamada al clasificador LLM genera su propio span, por lo que la latencia del clasificador se ve por separado de la del modelo servido.









.png)
.png)
.png)
.png)

.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.webp)
.webp)

.png)
.png)





