LiteLLM frente a OpenRouter: costes, control y conmutación por error

Elegir una pasarela para LLM no consiste tanto en saber si LiteLLM y OpenRouter hablan una API compatible con OpenAI, sino en decidir quién opera la capa de enrutamiento. OpenRouter suele ser el punto de partida con menos fricción cuando el equipo no mantiene ya infraestructura de pasarela en producción; LiteLLM compensa su sobrecoste cuando la red privada, las políticas personalizadas o un uso sostenido hacen que el control merezca el esfuerzo operativo.

La decisión gira en torno al modelo operativo, no al formato de la API

LiteLLM es software de código abierto que puede ejecutarse como SDK de Python o como proxy autoalojado. OpenRouter es una API gestionada y un catálogo de modelos: OpenRouter opera la pasarela, agrupa el acceso a distintos proveedores y ofrece una única cuenta para usar modelos.

Ambos pueden ofrecer una interfaz compatible con OpenAI, pero reparten las responsabilidades de forma diferente:

Esta diferencia también hace viable una arquitectura combinada: LiteLLM puede encargarse de las políticas internas y de la contabilidad, mientras OpenRouter gestiona el acceso a determinados modelos.

Elige según la restricción que vaya a doler antes

La elección correcta depende del primer requisito que el equipo no esté dispuesto a negociar.

Sigue el dinero: de la factura de tokens a la factura de ingeniería

LiteLLM y OpenRouter cobran por capas diferentes. OpenRouter repercute el precio subyacente de los modelos sin aplicar un recargo de inferencia y después cobra una tarifa del 5,5% al comprar créditos. El proxy de código abierto de LiteLLM no cobra una tarifa por token, pero tendrás que pagar la infraestructura y las personas necesarias para operarlo.

La página de precios de OpenRouter es la referencia actual para las condiciones de las tarifas. El cargo está asociado a la compra de créditos, no a un recargo simple del 5% sobre el precio por token de cada modelo.

Cuándo la tarifa de OpenRouter es la partida más barata

Si un equipo compra suficientes créditos de OpenRouter para cubrir su factura mensual de inferencia:

• Con un uso mensual de $500, una tarifa del 5,5% por la compra de créditos equivale a $27.50.
• Con $20,000, el mismo porcentaje asciende a $1,100.
• Con $50,000, son $2,750.

Estas cifras muestran cuánto tendría que ahorrar LiteLLM después de contar el alojamiento, los despliegues, los parches, las alertas, las copias de seguridad y el tiempo de ingeniería. Con $500 al mes, OpenRouter suele ser la opción con menor esfuerzo operativo para un equipo que no mantiene ya una pasarela, salvo que la red privada sea obligatoria. Con $20,000, cualquier equipo con responsabilidades de plataforma debería calcular seriamente el coste de LiteLLM.

Cuándo la tarifa cero de LiteLLM resulta realmente más barata

LiteLLM resulta atractivo económicamente cuando el coste operativo fijo ya está cubierto por el equipo de plataforma o cuando la tarifa porcentual que se evita supera el coste incremental de ejecutar el proxy.

La guía oficial de inicio rápido con Docker separa un proxy sencillo sin base de datos de un despliegue respaldado por una base de datos. En el flujo con Compose se utiliza PostgreSQL para los modelos, las claves y los registros de gasto. Sin base de datos, LiteLLM indica que las claves virtuales, el seguimiento del gasto y la aplicación efectiva de presupuestos no están disponibles; un max_budget configurado no constituye un límite estricto fiable.

Redis marca otro umbral de producción. Los requisitos de Redis de LiteLLM recomiendan compartir el estado de Redis cuando el proxy funciona con más de un worker o réplica. Sin él, los límites de velocidad, presupuestos, periodos de enfriamiento, entradas de caché y observaciones de enrutamiento quedan repartidos entre los workers. Una prueba con un único worker es barata; una pasarela de producción escalada horizontalmente es un sistema bastante mayor.

Usa esta comparación en lugar de fijarte solo en el precio de los tokens:

Coste total de LiteLLM = facturas de proveedores + infraestructura + operaciones + responsabilidad sobre la seguridad
Coste total de OpenRouter = inferencia del proveedor + tarifa por compra de créditos

No existe un punto de equilibrio universal. Los datos útiles son el gasto mensual en inferencia, el alojamiento, las horas de ingeniería, la cobertura de guardias y cualquier sobrecoste asociado al cumplimiento normativo.

Compara el plano de control que tendrás que operar

LiteLLM ofrece más control al equipo de plataforma, pero no te proporciona acceso a los proveedores. OpenRouter simplifica el descubrimiento de modelos y la facturación unificada, aunque su catálogo alojado no equivale a tener una relación directa con cada proveedor.

En fiabilidad es donde los productos dejan de parecerse

Ambos productos pueden reintentar solicitudes o activar una conmutación por error, pero lo hacen bajo modelos de responsabilidad diferentes. OpenRouter gestiona el conjunto de proveedores; LiteLLM te permite definirlo, pero debe operarse como parte de tu propia arquitectura de fiabilidad.

La documentación de enrutamiento entre proveedores de OpenRouter indica que su comportamiento predeterminado distribuye la carga entre los proveedores disponibles teniendo en cuenta el precio y las interrupciones recientes. Puedes solicitar un orden de proveedores, permitir o desactivar alternativas, exigir parámetros concretos, filtrar por política de datos u ordenar por precio, rendimiento o latencia. Su guía de alternativas de modelos describe una lista ordenada de models; la facturación utiliza el modelo que acaba atendiendo la solicitud.

La documentación de enrutamiento de LiteLLM describe la selección ponderada o aleatoria, el enrutamiento basado en uso, latencia o carga, el enrutamiento por coste y las estrategias personalizadas. También admite prioridades de despliegue, periodos de enfriamiento, reintentos y grupos alternativos. Estos controles son más programables, pero su funcionamiento correcto depende de la configuración, las comprobaciones de salud, el estado compartido y la respuesta ante incidentes.

Latencia de agentes, caché y cambios en los proveedores

Un salto de red adicional puede ser irrelevante en una respuesta larga transmitida por streaming. Importa mucho más cuando un agente realiza decenas de llamadas breves al modelo, porque las demoras de la pasarela, la red y los reintentos se acumulan entre turnos. Un proxy de LiteLLM autoalojado puede situarse cerca de la aplicación; OpenRouter añade un salto a través de un servicio gestionado antes de llegar al proveedor seleccionado. La documentación genérica de ninguno de los dos sustituye una prueba con tu región, modelo, modo de streaming y concurrencia.

El enrutamiento también puede cambiar la economía de la caché. OpenRouter puede seleccionar entre distintos endpoints de proveedor para el mismo modelo, mientras que LiteLLM puede distribuir las solicitudes entre los despliegues configurados. Si un flujo depende de la caché de prompts del proveedor, un cambio de ruta puede modificar la localidad de la caché y el coste de los tokens. Considera el comportamiento de la caché como parte de las pruebas de carga.

Compartir un identificador de modelo tampoco garantiza un comportamiento idéntico. Las implementaciones de cada proveedor pueden diferir en límites de contexto, compatibilidad con llamadas a herramientas, latencia, cuantización, caché y parámetros específicos. OpenRouter expone filtros de proveedores como require_parameters, mientras LiteLLM normaliza las llamadas de los proveedores mediante una interfaz común. Prueba exactamente los esquemas de herramientas y los parámetros de modelo que utiliza tu agente.

Modos de fallo que debes contemplar

OpenRouter convierte los incidentes de infraestructura en una dependencia del proveedor. LiteLLM los convierte en incidentes que tu equipo de plataforma puede inspeccionar y modificar.

La observabilidad y la privacidad tienen fronteras diferentes

“Autoalojado” y “privado” no son sinónimos, del mismo modo que “gestionado” no significa “registra cada prompt”. La pregunta importante es qué capa almacena el contenido, cuál conserva los metadatos y qué proveedores reciben la solicitud.

La documentación de Zero Data Retention de OpenRouter indica que ZDR puede aplicarse a toda la cuenta, a un grupo de modelos, a una barrera de seguridad o a una solicitud. Distingue los endpoints sin retención de los proveedores que no entrenan con los datos, pero pueden conservarlos temporalmente. ZDR se aplica al enrutamiento de inferencia; las herramientas y plugins activados requieren una revisión independiente.

LiteLLM te da más control sobre la red, la base de datos, la autenticación y los registros de la pasarela, pero la responsabilidad es tuya. Protege el proxy, aplica parches al software, restringe las rutas administrativas, guarda las claves de los proveedores y verifica las condiciones de retención y entrenamiento de cada proveedor ascendente.

El patrón híbrido suele ser la respuesta más práctica

Usa LiteLLM delante de OpenRouter cuando necesites un endpoint interno estable y gobernanza, pero no quieras abrir una cuenta directa para cada modelo o proveedor. Envía el tráfico sensible o predecible directamente a proveedores aprobados y utiliza OpenRouter para el tráfico exploratorio o dependiente del catálogo.

Un patrón de configuración simplificado sería el siguiente:

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

Así LiteLLM se convierte en el lugar donde aplicar claves internas, presupuestos, etiquetas y registros. Eso no elimina la tarifa de OpenRouter, el tránsito alojado ni la frontera de política del proveedor para las solicitudes que circulen por esa ruta. También añade otro salto y otro dominio de fallo, así que no envíes automáticamente todas las solicitudes por ambas capas.

Una división sensata sería:

1. Rutas directas al proveedor para datos sensibles, modelos de producción estables o contratos negociados con proveedores.
2. Rutas de OpenRouter para descubrir modelos, acceder a proveedores minoritarios y usar la conmutación por error gestionada entre proveedores.
3. Controles de LiteLLM para las claves de aplicaciones, equipos, presupuestos y atribución interna de costes.
4. Paneles y alertas separados para el tráfico directo a proveedores y el tráfico de OpenRouter.

Esfuerzo de migración: qué cambia y qué no

Mover un cliente compatible con OpenAI entre ambas pasarelas puede ser sencillo. Trasladar una carga de trabajo en producción no se reduce a cambiar la URL base.

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter suele utilizar https://openrouter.ai/api/v1 (referencia de la API); un proxy de LiteLLM suele exponer un endpoint privado como http://localhost:4000 (guía rápida del proxy). Aun así, los identificadores de modelos, los prefijos de proveedores, la autenticación y los parámetros opcionales pueden variar.

Antes de cambiar el tráfico de producción, prueba:

1. El comportamiento del streaming y los tiempos de espera.
2. Las llamadas a herramientas con tus esquemas JSON exactos.
3. Las salidas estructuradas y el tratamiento estricto de JSON.
4. El razonamiento, la caché y los parámetros específicos del proveedor.
5. El comportamiento de las alternativas cuando el modelo principal devuelve 429, 5xx o un error de validación.
6. La atribución de costes, porque el evento de facturación puede producirse en una capa distinta de la solicitud de la aplicación.

La compatibilidad de la API resuelve la primera integración. No garantiza resultados, latencia, selección de proveedor ni semántica de facturación idénticos.

Preguntas habituales antes de elegir

¿Se pueden usar LiteLLM y OpenRouter juntos?

Sí. LiteLLM puede utilizar OpenRouter como ruta ascendente, de modo que LiteLLM gestione las claves internas, los presupuestos, los registros o las políticas mientras OpenRouter proporciona acceso a determinados modelos y enrutamiento entre proveedores. La ruta combinada añade un salto y mantiene la tarifa de OpenRouter y su frontera de datos alojados para ese tráfico.

¿Cuál es más barato para una API en producción?

OpenRouter suele requerir menos esfuerzo operativo para un equipo pequeño que no mantiene ya infraestructura de pasarela. LiteLLM puede salir más barato con un uso elevado si tu equipo ya opera la infraestructura necesaria y quiere evitar tarifas porcentuales de pasarela; compara el coste total, no solo el precio de los tokens.

¿LiteLLM proporciona acceso a todo el catálogo de OpenRouter?

No por sí solo. LiteLLM documenta compatibilidad con más de 100 LLM y un amplio conjunto de proveedores en su guía rápida del proxy, pero solo llega a los proveedores y credenciales que configures. Añadir OpenRouter como ruta ascendente puede ampliar el catálogo accesible, aunque esas solicitudes seguirán dependiendo de la disponibilidad de modelos y proveedores de OpenRouter.

¿Cuál es mejor para privacidad y cumplimiento normativo?

El LiteLLM autoalojado ofrece más control sobre el despliegue de la pasarela, los registros, las credenciales y la frontera de red. OpenRouter ofrece controles sobre el registro de contenido, filtros de política de proveedores, enrutamiento ZDR y opciones regionales para la UE o EE. UU. en Enterprise, pero sigue formando parte del recorrido de la solicitud; verifica el proveedor exacto y el requisito contractual antes de decidir.

Elige la frontera que puedas mantener: compara la tarifa porcentual con el coste operativo real de tu pasarela, clasifica qué solicitudes pueden pasar por un intermediario alojado y prueba los fallos de acuerdo con el comportamiento de enrutamiento y llamadas a herramientas que necesita tu aplicación. Si no puedes asumir la responsabilidad de la base de datos, Redis, las actualizaciones y las guardias de LiteLLM, OpenRouter es la opción por defecto más honesta; si ya cuentas con esa capacidad de plataforma, LiteLLM o una ruta híbrida pueden devolverte el control y reducir las tarifas recurrentes de la pasarela.

Para consultar más alternativas a OpenRouter, visita alternativas a OpenRouter; esta comparativa es deliberadamente más específica y se centra en la decisión sobre el modelo operativo de LiteLLM.