Cómo autoalojar LiteLLM en producción: arquitectura y seguridad para 2026

LiteLLM puede ofrecer a cada aplicación un endpoint compatible con OpenAI mientras el gateway gestiona credenciales de proveedores, claves virtuales, presupuestos, routing y observability. Su documentación oficial presenta el proxy como un servicio central para equipos de plataforma, separado del SDK de Python que vive dentro de una aplicación. Esta guía trata de operar ese proxy como infraestructura.

La pregunta desatendida ya no es «¿Puedo arrancar el contenedor?». Es «¿Puede mi equipo parchear, escalar y recuperar el gateway que ahora guarda todas las credenciales de modelos?». Una demo necesita un proceso. Producción necesita un responsable, una capa de datos privada, una política de releases y pruebas de que un fallo no detiene todas las funciones de IA a la vez.

¿Qué significa realmente autoalojar LiteLLM?

Autoalojar LiteLLM significa que operas el gateway dentro de infraestructura bajo tu control. Las peticiones siguen llegando a OpenAI, Anthropic, Bedrock u otro proveedor configurado, salvo que apuntes el gateway a un servidor de inferencia local como vLLM u Ollama. Controlas el proxy, las claves, los logs y la política de routing, no automáticamente la ejecución del modelo.

Esto separa el artículo de dos decisiones cercanas. Nuestra comparativa de gateways LLM ayuda a elegir entre LiteLLM, OpenRouter, Portkey o un framework de routing. La guía de costes para autoalojar LLM en la UE cubre pesos e inferencia con GPU. Aquí el producto es el plano de control entre tus aplicaciones y cualquier combinación de modelos alojados o locales.

¿Cuándo merece la pena autoalojar LiteLLM?

LiteLLM afirma que su gateway open source no tiene coste de licencia y enumera claves virtuales, presupuestos, límites, fallbacks, logging y métricas Prometheus en ese nivel. Enterprise añade gobierno y soporte, como SSO, SCIM y logs de auditoría. Comprueba el reparto actual en la página de precios de LiteLLM antes de comprar.

¿Qué arquitectura necesita LiteLLM en producción?

La guía actual de despliegue en producción de LiteLLM describe servicios stateless tras un balanceador, PostgreSQL para claves, equipos, logs de gasto y configuración, y Redis para límites compartidos, estado del router y caché. Recomienda dos o más réplicas y un job explícito de migraciones. Esa es la forma mínima creíble de producción, no un Compose de un contenedor expuesto a internet.

Empieza con la imagen monolítica salvo que escalar gateway, backend y UI por separado resuelva un cuello de botella medido. Una arquitectura pequeña se parchea y recupera mejor. Dividir componentes ayuda con tráfico alto o una separación administrativa estricta, pero aumenta la coordinación de releases.

¿Cómo se despliega LiteLLM de forma segura?

1. Define el contrato del gateway. Enumera alias de modelos permitidos, orden de fallback por proveedor y región, presupuestos por carga, endpoints admitidos, reglas de retención y responsable de cada alerta. Un endpoint unificado sin política solo centraliza el riesgo.
2. Demuestra el recorrido en staging. Ejecuta un contenedor fijado en un endpoint privado, monta un config.yaml versionado, inyecta credenciales desde el entorno y manda una petición con el cliente estándar de OpenAI. No expongas main-latest ni logging de debug detallado en producción.
3. Añade Postgres antes de emitir claves de equipo. Usa una base gestionada y privada, conexiones cifradas, backups automáticos y un job de migración independiente. Evita cambios de esquema en las réplicas que sirven tráfico para que un escalado no compita con una migración.
4. Añade Redis antes de la segunda réplica. La lista de producción recomienda Redis 7 o posterior cuando hay más de un proxy. Sin estado compartido, cada réplica aplica límites por separado y los aciertos de caché son locales. En Kubernetes escala con un worker por pod y CPU, no con memoria retenida por el proceso.
5. Emite una clave virtual distinta por carga. La documentación de claves virtuales exige Postgres y permite acceso por modelo, presupuestos y atribución de gasto. Define allowlists de modelos y rutas. Nunca entregues el master key a una aplicación ni supongas que una lista vacía significa acceso nulo.
6. Coloca el gateway en una red privada. Expón por TLS solo las rutas de petición necesarias. Pon la UI administrativa y las APIs de gestión tras acceso con identidad o una ruta administrativa separada. Limita el egress a proveedores y destinos de observability aprobados.
7. Haz reversibles los upgrades. Prueba imagen, configuración y migraciones contra una copia del esquema de producción, despliega un canary y reproduce peticiones representativas. Conserva la imagen anterior y un backup compatible para rollback.
8. Ejecuta simulacros de fallo. Desactiva por turnos un proveedor, una réplica, Redis y Postgres. Confirma fallback, readiness, alerta, objetivo de recuperación y error del cliente. Un fallback nunca probado es documentación, no resiliencia.

¿Qué cambió en la seguridad de LiteLLM durante 2026?

La seguridad debe definir la arquitectura porque el proxy puede contener credenciales de modelos, acceso a la base y contenido de peticiones. En marzo de 2026 se publicaron en PyPI las versiones maliciosas 1.82.7 y 1.82.8. La cronología del incidente indica que podían robar variables y credenciales cloud, mientras que las imágenes Docker del proxy no se vieron afectadas. Los equipos que instalaron esos paquetes deben seguir la guía del incidente y rotar credenciales expuestas.

Otras vulnerabilidades del proxy elevaron aún más el listón. Una inyección SQL crítica en la verificación de API keys afectó de 1.81.16 a 1.83.6. Una inyección de comandos en endpoints de prueba MCP afectó de 1.74.2 a 1.83.6. Una posterior escalada de privilegios mediante claves virtuales se corrigió en 1.83.14. Esas versiones corregidas son mínimos históricos, no objetivos recomendados hoy.

La respuesta práctica es clara: usa una release stable con soporte actual, no una prerelease ni un parche mínimo antiguo. El 13 de agosto de 2026, GitHub marcaba v1.96.2 como latest y publicaba un comando de verificación cosign en la página de releases de LiteLLM. Vuelve a comprobarla el día del despliegue, fija versión o digest exactos, verifica la firma, escanea la imagen y promociona el mismo digest entre entornos.

¿Qué debe cumplirse antes de salir a producción?

• El mínimo privilegio es explícito. Cada carga tiene su clave virtual, propietario, modelos, rutas, presupuesto y caducidad. El master key nunca llega a una aplicación.
• Los secretos están separados y se pueden recuperar. Credenciales de proveedores y master key viven en el gestor de secretos. El LITELLM_SALT_KEY permanente tiene backup separado porque cambiarlo después de guardar credenciales las vuelve ilegibles.
• La red falla cerrada. Las rutas de administración son privadas, la verificación TLS sigue activa, el egress está limitado y ni base ni Redis tienen dirección pública. Estos controles siguen las prácticas de seguridad de LiteLLM.
• Los logs tienen política de datos. Decide si se pueden registrar prompts y respuestas, redacta campos sensibles antes de exportar, fija retención, restringe el acceso y prueba el borrado. Nuestra guía de redacción de PII antes del LLM desarrolla ese límite.
• Las comprobaciones de salud tienen significados distintos. LiteLLM documenta endpoints de liveness y readiness sin autenticación que no llaman a modelos. El endpoint autenticado de salud de modelos sí envía peticiones reales. Configura sondas y checks sintéticos según el contrato de health checks.
• El gasto se reconcilia. Compara la atribución de LiteLLM con facturas del proveedor y prueba streaming, reintentos, caché y fallback. La estimación del dashboard ayuda, pero finanzas necesita reconciliación.
• Un responsable puede parchear rápido. Suscríbete a advisories, define un SLA de parcheo, mantén una suite de smoke tests en staging y documenta la rotación de credenciales tras una posible intrusión.

¿Cuánto trabajo exige LiteLLM autoalojado?

No hay un precio universal honesto porque el gateway hereda tu cloud, objetivo de disponibilidad, identidad y compliance. Los rangos siguientes son estimaciones de planificación de Wavect para scoping, no ofertas de LiteLLM ni promesas de precios cloud.

Con tráfico moderado, la factura de infraestructura rara vez decide. Decide el ownership. Si nadie puede asumir parcheo y recuperación, un gateway gestionado es más barato aunque su factura sea mayor. Si un equipo de plataforma ya opera Kubernetes, Postgres, Redis, secretos y observability, LiteLLM puede encajar en controles ya financiados.

¿Debes autoalojar LiteLLM o comprar un gateway gestionado?

Autoaloja LiteLLM cuando el control sea un requisito y la operación una capacidad existente. Compra un gateway gestionado cuando velocidad, soporte y menor carga de guardia valgan más que controlar la infraestructura. Mantén acceso directo al proveedor para un prototipo estrecho que aún no ha justificado el gateway.

Una prueba de compra útil calcula un año, no un contenedor. Incluye diseño, implementación, base y Redis, monitorización, backups, upgrades, revisión de seguridad, guardia y una migración de proveedor. Compara ese total con la opción gestionada y el coste de no actuar. Para optimizar una vez instalado el gateway, usa nuestro playbook para reducir costes de tokens LLM.