LiteLLM vs gateways gestionadas: cuándo el self-host sale más caro en realidad
El coste fully-loaded de operar tu propia gateway LLM, sin maquillaje

LiteLLM es una gateway LLM OSS bien construida y muy usada. Es una buena pieza de software de verdad. Tampoco es la opción correcta para cualquier equipo, y el argumento "es gratis" esconde un conjunto de costes que solo se revelan tras tres meses de operación.

Esto no es un hit piece. Hemos usado LiteLLM. Volveríamos a usarlo para el tipo de equipo adecuado. La pregunta es: ¿cuándo gana de verdad el self-hosting, y cuándo gana una gateway gestionada?

Hagamos las cuentas honestamente.

Lo que te da LiteLLM realmente

La oferta core: una librería Python OSS y un proxy que exponen 100+ proveedores LLM detrás de una API compatible con OpenAI. Lo despliegas en Docker, Kubernetes o VM. Apuntas tu app ahí. Listo.

De base tienes:

• Abstracción de proveedor (un SDK, varios backends)
• Routing de fallback (intenta proveedor A, luego B si falla)
• Caching básico
• Logging de requests
• Gestión de claves
• Tracking de presupuesto (en el tier enterprise)

Es una lista real. Self-hosted, con cero coste por request que se vaya a un vendor.

Los costes ocultos del self-hosting

Aquí es donde el encuadre "es gratis" empieza a hacer aguas.

Coste 1: Tiempo de ops

Un despliegue realista de LiteLLM requiere, como mínimo:

• Docker o Kubernetes para hacerlo correr.
• Una instancia PostgreSQL (para logs, presupuestos, estado de claves).
• Redis (para cache y rate limiting).
• Monitoring (Prometheus/Grafana o equivalente).
• Agregación de logs.
• Secret management para las claves de proveedor.
• CI/CD para desplegar updates.

Si ya operas esta stack por otros motivos, el coste marginal es pequeño. Si no, aprovisionas y mantienes 3-5 piezas de infra que no tendrías de otra forma.

Estimación conservadora: 4-8 horas/semana de platform engineering para un despliegue no trivial. A un coste cargado de 100 €/hora para un ingeniero con experiencia, son 400-800 €/semana, o 1.600-3.200 €/mes.

Coste 2: On-call

Si tus llamadas LLM están en el camino crítico de una app en producción, que tu gateway caiga significa que tu producto cae. Alguien tiene que estar localizable.

Las rotaciones de on-call tienen un coste incluso cuando el pager no suena — es una restricción sobre la vida del ingeniero que el management suele negarse a reconocer como real. Para un equipo pequeño, añadir una nueva superficie de on-call para la gateway LLM no es gratis.

Si tu gateway tiene un incidente a las 2 de la madrugada, el coste del incidente es el sueño del ingeniero, el retraso en el backlog, el tiempo real de debug, y potencialmente el impacto al cliente. Una gateway gestionada saca ese incidente de tu plato — su rotación de on-call suena, no la tuya.

Coste 3: Lag de features

Los proveedores hacen ship constantemente de modelos nuevos. Nuevos campos de API (structured outputs, extended thinking, parámetros de prompt caching). Nuevos tiers de precios. Nuevos códigos de error. Nuevas semánticas de rate limit.

LiteLLM OSS sigue la mayor parte de eso, pero siempre hay un lag. El ciclo es: el proveedor hace ship de la feature → se abre issue en LiteLLM → se mergea PR → nueva release → upgradeas tu despliegue → testeas → despliegas.

Para nosotros, ese ciclo iba típicamente 1-4 semanas por detrás de una gateway gestionada que hace ship continuamente. En un espacio que se mueve rápido, cuatro semanas pesan.

Coste 4: Paridad de features

LiteLLM OSS tiene routing y fallback. No tiene (o no iguala la profundidad de las gateways gestionadas en):

• Routing basado en inteligencia que lee la complejidad del prompt en tiempo real
• Detección de burn-rate y alertas antes de que el presupuesto se queme
• Detección de zombie agents (actividad de agente fuera de horas)
• Detección de bucles (requests idénticos que vuelven en bucle)
• Presupuestos por endpoint granulares con auto-downgrade
• UI de observability pulida para no-ingenieros

Puedes construir cada una. Acabas construyéndolas todas. Cada una es una semana de ingeniería que no dedicas a tu producto real.

Coste 5: Carga de upgrade

Cada pocas semanas LiteLLM hace ship de una nueva versión. Generalmente menor, ocasionalmente breaking. Tienes que:

• Leer el changelog.
• Testear la nueva versión contra tu config.
• Upgradear en staging.
• Smoke-testear.
• Desplegar.

Cuando se rompe — y pasa ocasionalmente, es la naturaleza de un proyecto OSS que se mueve rápido — debugueas, a veces contra la comunidad OSS, a veces leyendo el código.

Es trabajo real, y es trabajo que escala linealmente con el número de despliegues que mantienes.

La comparación fully-loaded

Modelemos un escenario concreto: un equipo que hace 1M de requests LLM/mes con 3.000 €/mes de gasto en proveedor.

LiteLLM self-hosted

Gateway gestionada (estilo HiWay, flat por request)

La gestionada sale 2.781 €/mes más barata a esta escala, casi todo en el labor de ingeniería. Y eso es antes de contar el smart routing, que típicamente recorta 40-85% de los 3.000 € de gasto en proveedor adicionalmente — una palanca que LiteLLM self-hosted no te da de base.

Estos son números ilustrativos. Tu tarifa por hora de ingeniería puede ser de 80 € o 150 €. Tu overhead de ops puede ser de 3h/semana o 12h/semana. Pero la forma del cálculo es robusta: una vez que valoras el tiempo de ingeniería honestamente, el self-hosted deja de ser "gratis".

Cuándo gana de verdad el self-hosting

LiteLLM self-hosted gana cuando al menos una de estas condiciones es cierta:

Ya tienes la plataforma

Si tu equipo opera un cluster de Kubernetes, tiene PostgreSQL, Redis, Grafana, y rotaciones de on-call montadas por otros motivos, añadir LiteLLM está cerca de ser gratis. La infra ya está ahí; la carga operativa marginal es pequeña.

Tienes un platform engineer dedicado

Un equipo con alguien cuyo trabajo es el trabajo de plataforma — no una rotación ops a tiempo parcial — puede absorber LiteLLM limpiamente. Las 4-8 horas/semana de las que hablábamos antes están dentro de su carga existente, no son incrementales.

Tienes requisitos duros de residencia de datos

Si necesitas que tu gateway corra en una región concreta, sobre hardware concreto, con sub-procesadores concretos — y ningún servicio gestionado encaja en esas restricciones — el self-hosted es la única opción. Es raro pero real. Defensa, salud en ciertas jurisdicciones, gubernamental.

Eres sensible al coste y a la escala

A volúmenes de requests muy altos (10M+ requests/mes) donde los costes de suscripción de gateway se vuelven un line item real, el self-hosted puede ser más eficiente si tus costes de plataforma están amortizados sobre varios workloads. Pero "muy alto" significa lo bastante alto como para que el cálculo de platform-engineering también cambie — probablemente tienes el equipo para soportarlo.

Quieres la salida de emergencia OSS por principio

Algunos equipos no van a depender de un vendor closed-source para un componente del camino crítico, punto. Es una elección legítima. LiteLLM te da una opción OSS que un servicio gestionado closed-source no te da.

Cuándo gana una gateway gestionada

Eres un equipo pequeño que hace ship de producto

Si tu equipo de ingeniería tiene menos de 10 personas y tu trabajo es shippear features, dedicar 4-8 horas/semana a ops de gateway son 4-8 horas no dedicadas al producto. El ROI de externalizar eso es inmediato.

Quieres features que nunca construirías por tu cuenta

Detección de burn-rate. Bloqueo de zombie-agents. Routing basado en inteligencia. Auto-downgrade por endpoint. Cada una son 2-4 semanas de ingeniería. Para la mayoría de equipos, nunca llegarían — la roadmap de producto las aplasta. Una gateway gestionada las trae por defecto.

Quieres observability sin construirla

Una UI de observability pulida — desgloses de coste, percentiles de latencia, dashboards por endpoint — es un producto en sí mismo. La UI de LiteLLM es funcional. Las gateways gestionadas suelen ir por delante aquí porque ese es su producto.

Quieres la respuesta a incidentes en el pager de otro

El momento en que un incidente de gateway no es problema de tu equipo, te has quitado toda una categoría de preocupación de los hombros. Para equipos sin infra de on-call, es sustancial.

Quieres hosting UE sin operar un datacenter UE

Para equipos europeos que necesitan residencia de datos UE, usar una gateway gestionada ya UE-hosted (sobre OVH, sobre Scaleway, sobre un cloud europeo) es infinitamente más rápido que montar tu propio despliegue regionalmente compliant.

El cara a cara

El camino híbrido (que es real)

Algunos equipos operan LiteLLM en dev y test, y una gateway gestionada en prod. Otros lo hacen al revés. Los dos funcionan.

Si te resulta cómodo correr LiteLLM en local para que los ingenieros testeen contra él — sin carga ops, sin escala — y usar una gateway gestionada para la producción donde fiabilidad y profundidad de features pesan, tienes lo esencial de lo mejor de ambos. El coste principal es la deriva de config entre entornos.

La conclusión honesta

LiteLLM es una pieza de software estupenda. Tampoco es gratis. Cuando contabilizas honestamente el tiempo de ingeniería, la carga de on-call, el lag de features y la superficie operativa de una gateway en producción, LiteLLM self-hosted es más barato que un servicio gestionado solo en combinaciones precisas de forma de equipo y escala.

Para la mayoría de equipos — grupos de ingeniería pequeños, orientados a producto, sin platform engineer dedicado — una gateway gestionada es la elección más barata, más rápida y menos distractiva. Para equipos que ya operan infra de plataforma, tienen los efectivos, o necesitan OSS por principio, LiteLLM es la respuesta correcta.

No hay un ganador universal. Solo está el cálculo honesto para tu equipo concreto.

---

Próximo: los modelos de pricing de las gateways LLM explicados — por token, por request, BYOK, flat.