Gateways LLM Comparados 2026: LiteLLM vs OpenRouter vs Portkey vs RouteLLM

La mayoría de los equipos conecta su producto directamente al SDK de un solo proveedor. Funciona hasta que deja de funcionar. Entonces el proveedor tiene una caída y tu app cae con él. Entonces finanzas pregunta por qué un trabajo descontrolado quemó el presupuesto de un mes en una tarde. Entonces sale un modelo nuevo, más barato y mejor para la mitad de tu tráfico, y cambiar significa tocar cada punto de llamada. Así que el equipo empieza a atornillar reintentos, un límite de gasto, un segundo proveedor y una caché, y en un trimestre ha construido media capa de infraestructura de agentes mal, en su propio código, sin que nadie sea su dueño.

Esa capa que falta tiene nombre: el gateway LLM. Un endpoint por delante de varios proveedores, con fallback, caching, límites de gasto y routing gestionados en un solo sitio. Esta es una perspectiva de ingeniería, no un pitch de proveedor. Los datos de features y precios de abajo son orientativos, con fecha de junio de 2026, sacados de la documentación y las webs públicas de cada herramienta, así que vuelve a comprobarlos antes de comprometerte. Los puntos de referencia vienen del trabajo de Wavect en productos de IA, donde hemos puesto un gateway por delante de tráfico en producción y hemos vivido con los tradeoffs.

¿Qué hace de verdad un gateway LLM?

Un gateway es un proxy que se sitúa entre tu aplicación y los proveedores de modelos. Tu código llama a un endpoint, normalmente en el formato de petición de OpenAI, y el gateway traduce la llamada y la reenvía al proveedor que deba atenderla. Esa única costura es donde obtienes las features que de otro modo reconstruirías a mano:

• Un endpoint sobre muchos proveedores. Cambia Claude por GPT por Gemini por un modelo de pesos abiertos modificando un valor de configuración, no un punto de llamada. El lock-in del SDK del proveedor desaparece.
• Fallback. Cuando un proveedor devuelve un error o agota el tiempo, el gateway reintenta contra otro modelo u otro proveedor, para que una sola caída no se lleve por delante tu producto.
• Caching. Peticiones idénticas o semánticamente similares pueden devolver una respuesta guardada y saltarse la llamada al modelo entera, lo que recorta coste y latencia en el tráfico repetitivo.
• Límites de gasto y keys. Presupuestos y límites de tasa por key, por usuario o por equipo, para que un bucle malo no pueda vaciar la cuenta y para que puedas dar a cada equipo una virtual key acotada.
• Routing. Envía la mayoría fácil a un modelo barato y la minoría difícil a uno frontier, por reglas o por una política aprendida.
• Observability. Un sitio donde ves cada petición, su coste, su latencia y sus tokens, desglosados por modelo, key y feature.

El routing es la palanca de coste por la que viene la mayoría, y cubrimos su economía en cómo reducir los costes de tokens LLM en 2026. Este artículo va de las herramientas que te dan esa palanca más el resto de la capa.

¿En qué se diferencian LiteLLM, OpenRouter, Portkey y RouteLLM?

Estos cuatro nombres salen juntos, pero no son la misma clase de cosa. Dos son gateways completos, uno es un agregador hosteado, y uno es un framework de investigación de routing. Aquí la forma de cada uno, con capacidades verificadas contra la documentación de cada herramienta en junio de 2026. Trátalo como una foto y vuelve a comprobarlo antes de comprometerte.

LiteLLM es el caballo de batalla open source: un proxy que despliegas tú mismo, que normaliza 100+ proveedores tras un endpoint en formato OpenAI y centraliza virtual keys, presupuestos, límites de tasa, fallback y logging en un archivo de configuración que versionas en tu repo. OpenRouter es un agregador hosteado: una key, cientos de modelos, operado por ellos, con un modelo de marketplace que te deja alcanzar un modelo nuevo el día que sale sin tener cuenta en cada proveedor. Portkey es un gateway que lidera con observability y guardrails; liberó su core como open source en 2026 y además vende una tier cloud. RouteLLM es de otra clase: un framework de investigación de LMSYS y Berkeley para entrenar y servir la decisión de routing en sí, no el gateway que la rodea.

"Tres de estos son gateways y uno es un router. Comparar RouteLLM con LiteLLM es comparar el cerebro con el cuerpo. La mayoría de los equipos necesita ambos, y la mayoría va primero a por el cuerpo."

Self-host o hosteado: ¿cuál deberías elegir?

Esta es la primera decisión real, y normalmente decide la herramienta. El tradeoff es control y residencia de datos contra carga operativa.

• Hosteado (OpenRouter, Portkey cloud). Tienes la capa en una tarde, sin infraestructura que operar. El precio es una dependencia que no controlas y, en OpenRouter, datos que pasan por un tercero, algo que un equipo de la UE tiene que sopesar frente a su postura de residencia de datos. Las tarifas de catálogo de OpenRouter coinciden a grandes rasgos con las tarifas publicadas de cada proveedor, pero comprueba las comisiones de plataforma y de tarjeta, que pueden sumar un porcentaje notable en top-ups pequeños, y una comisión BYOK por encima de un umbral mensual de peticiones. Vuelve a verificar las comisiones actuales antes de presupuestar.
• Self-host (LiteLLM, core de Portkey, RouteLLM). Operas el proxy en tu propia infraestructura, así que la ruta de los datos y la cadencia de upgrades son tuyas. LiteLLM es gratis como open source sin comisiones de uso, pero operas el proxy más su Postgres y su Redis, y ese tiempo de ops es el coste real. Para un equipo con capacidad de DevOps y un requisito de compliance, suele ser la decisión correcta. Para un equipo de producto de dos personas con prisa, es overhead que aún no necesita.

El default honesto: empieza hosteado para demostrar que la capa se gana su sitio, y pasa a self-host cuando la residencia de datos, el coste a volumen o el control obliguen a la pregunta. Eso refleja la lógica de construir-o-comprar que aplicamos en los engagements de productos de IA, incluido trabajo como Twinsoft AI.

¿Qué tal el seguimiento de coste y la observability?

La razón por la que finanzas notó tu factura tarde es que el SDK del proveedor casi no te da visión del gasto por feature o equipo. Un gateway es donde vive esa visión, y las cuatro herramientas se sitúan a profundidades distintas.

• LiteLLM sigue el gasto por key, usuario y equipo, aplica presupuestos y límites de tasa, y manda logs a herramientas como Langfuse y OpenTelemetry. Es sólido, y como es tu despliegue, los datos se quedan contigo.
• Portkey lidera con observability. Logs, trazas y analítica son el producto, y factura por logs registrados en vez de por peticiones en bruto, así que el precio sigue cuánto observas. Si quieres el dashboard, los guardrails y el rastro de auditoría de fábrica, es el más profundo de los cuatro.
• OpenRouter te da un dashboard de uso y analítica de los modelos que llamas, suficiente para muchos equipos y con cero setup.
• RouteLLM no te da nada de esto. Es la decisión de routing, no la plataforma que la rodea, así que la observability es lo que envuelvas alrededor.

Una advertencia que siempre añadimos: los dashboards de gasto te dicen lo que pagaste, no si la calidad se mantuvo. Un router que en silencio manda las consultas más difíciles a un modelo más barato parecerá una victoria en el gráfico de coste y una derrota en producción. Necesitas un harness de evals junto al gateway para pillar eso, y ningún gateway lo trae. Esa disciplina corre de tu cuenta.

¿Dónde encaja RouteLLM, y son reales las cifras?

RouteLLM es el único de los cuatro centrado puramente en la decisión de routing: dada una consulta, mándala al modelo fuerte o al barato. Las cifras publicadas son genuinamente fuertes, y vale citarlas con cuidado. El equipo de LMSYS y Berkeley reporta que, con datos de entrenamiento aumentados, su router de factorización de matrices alcanza alrededor del 95 % del rendimiento de GPT-4 enviando solo el 14 % de las llamadas al modelo fuerte, lo que sitúan en torno a un 75 % más barato que una baseline aleatoria, y más del 85 % de reducción de coste en la evaluación MT Bench.

Lee esas cifras como orientativas y como las enmarca la fuente: vienen del paper original de RouteLLM, medidas sobre datasets concretos (MT Bench, MMLU, GSM8K) contra un modelo fuerte de clase GPT-4, publicado en 2024 y presentado en ICLR 2025. Tu tráfico no son esos benchmarks, así que el ahorro en tu workload será distinto. La conclusión honesta es la forma, no el porcentaje exacto: un router aprendido puede mantener la mayor parte de la calidad enviando una minoría de las llamadas al modelo caro. Aun así tienes que probarlo en tu propia eval antes de confiar en él.

En la práctica no eliges RouteLLM en lugar de un gateway. Puedes correr RouteLLM como el cerebro de routing y poner un gateway alrededor para fallback, keys, caching y observability, o usas las reglas de routing más simples de un gateway y te ahorras el framework. RouteLLM se gana su sitio cuando el routing es tu mayor palanca de coste y el routing por reglas está dejando ahorro sobre la mesa.

¿Cómo deberías elegir?

Mapea la herramienta a la restricción que de verdad te ata, no a la lista de features más larga:

1. Lo necesitas hoy, sin infra que operar. Tira de una opción hosteada. OpenRouter por amplitud de modelos tras una key, Portkey cloud si además quieres observability y guardrails desde el día uno.
2. La residencia de datos o el control total importan. Self-host. LiteLLM si quieres un proxy open source ligero y muy usado; el core open source de Portkey si la observability y los guardrails son requisitos de primera clase.
3. La observability y los guardrails son la prioridad. Portkey está construido alrededor de ellos. Los demás loguean; Portkey hace del log el producto.
4. El routing es tu mayor palanca de coste. Añade RouteLLM como cerebro de routing dentro del gateway que elijas, y prueba el ahorro en tu propia eval.
5. No lo tienes claro. Empieza con un gateway hosteado, instruméntalo, y deja que dos semanas de datos reales de gasto por feature te digan qué optimizar. Los datos responden la pregunta más rápido que la tabla comparativa.

Ninguna de estas es un compromiso permanente mientras mantengas tu aplicación hablando el formato de petición de OpenAI. Ese es el beneficio silencioso de todo el patrón: el gateway es lo que puedes cambiar, precisamente porque estandariza la costura de la que depende tu código.