--- title: "Autoalojar LiteLLM en producción: guía 2026" canonical: https://wavect.io/es/blog/self-host-litellm-production-2026/ language: es description: "Autoaloja LiteLLM con seguridad en 2026: Docker o Kubernetes, Postgres, Redis, claves virtuales, monitorización, parches, coste y alternativas." image: "https://wavect.io/img/blog/headers/header_self-host-litellm-production-2026.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 min de lectura · 13 de agosto de 2026 [**Siguiente**](/es/blog/linux-for-ai-agents/) # Cómo autoalojar LiteLLM en producción: arquitectura y seguridad para 2026 Resumen Autoalojar LiteLLM significa operar el gateway de IA, no necesariamente los modelos que hay detrás. Un entorno de producción necesita al menos dos réplicas con versión exacta tras TLS, Postgres gestionado y privado, Redis para compartir límites y estado de routing, claves virtuales limitadas, gestión de secretos, sondas de salud, métricas, backups y una ruta de upgrade probada. LiteLLM OSS no cobra licencia, pero la infraestructura y la guardia operativa sí cuestan. El ataque a PyPI y las vulnerabilidades del proxy de 2026 convierten el pin de versión, la verificación de firma, la restricción de red y el parcheo rápido en requisitos de lanzamiento. Empieza con un contenedor de staging y adopta el stack resiliente cuando control, compliance o portabilidad justifiquen operarlo. 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](https://docs.litellm.ai/) 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](/es/blog/llm-gateway-router-comparison-2026/) ayuda a elegir entre LiteLLM, OpenRouter, Portkey o un framework de routing. La [guía de costes para autoalojar LLM en la UE](/es/blog/self-hosting-llms-eu-cost/) 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](https://www.litellm.ai/pricing) antes de comprar. | Situación | Default recomendado | Por qué | | --- | --- | --- | | Un prototipo, un proveedor, sin responsable de plataforma | Llamar al proveedor directamente | El gateway añade otra dependencia de producción antes de resolver un problema real. | | Varios productos o equipos comparten cuentas de proveedor | El autoalojamiento puede compensar | Claves acotadas, presupuestos centrales y una abstracción de proveedor crean un punto de control claro. | | La velocidad de entrega importa más que el control de infraestructura | Usar un gateway gestionado | Compras operaciones, upgrades y soporte en vez de construirlos. | | La red privada, el despliegue en la UE o controles propios son obligatorios | Evaluar autoalojamiento | Eliges red, región, logs, retención y cadencia de despliegue. | | También necesitas inferencia local | Separar gateway e inferencia | LiteLLM enruta peticiones. vLLM, Ollama u otro servidor ejecuta el modelo. | ## ¿Qué arquitectura necesita LiteLLM en producción? La [guía actual de despliegue en producción de LiteLLM](https://docs.litellm.ai/docs/proxy/deploy) 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. | Capa | Responsabilidad en producción | Pregunta de fallo | | --- | --- | --- | | Ingress TLS o balanceador | Terminar TLS, restringir rutas, limitar abuso y drenar réplicas | ¿Puede un cliente defectuoso alcanzar endpoints de gestión o agotar el servicio? | | Dos o más réplicas LiteLLM | Servir tráfico desde una versión exacta y firmada de la imagen | ¿Interrumpe un rollout o un pod caído los streams activos? | | PostgreSQL gestionado | Persistir claves, equipos, gasto y configuración con backups | ¿Puedes restaurar antes de que el gateway cause una caída para toda la empresa? | | Redis gestionado | Compartir límites, caché y estado de routing entre réplicas | ¿Siguen siendo correctos los límites cuando el tráfico cae en pods distintos? | | Gestor de secretos | Guardar credenciales de proveedor, master key y salt key permanente | ¿Puede una aplicación recuperar la credencial de proveedor de otra? | | Métricas, logs y trazas | Medir disponibilidad, latencia, gasto, errores y saturación sin filtrar prompts | ¿Sabrá la guardia si falló LiteLLM, la base de datos o el proveedor? | 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](https://docs.litellm.ai/docs/proxy/prod) 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](https://docs.litellm.ai/docs/proxy/virtual_keys) 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](https://github.com/BerriAI/litellm/issues/24518) 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](https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc) afectó de 1.81.16 a 1.83.6. Una [inyección de comandos en endpoints de prueba MCP](https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g) afectó de 1.74.2 a 1.83.6. Una posterior [escalada de privilegios mediante claves virtuales](https://github.com/advisories/GHSA-qrc4-49gv-mv9m) 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](https://github.com/BerriAI/litellm/releases). 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](https://docs.litellm.ai/docs/proxy/security_best_practices). - **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](/es/blog/pii-redaction-before-llm-prompts/) 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](https://docs.litellm.ai/docs/proxy/health). - **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. | Nivel | Esfuerzo habitual | Incluye | | --- | --- | --- | | Gateway privado de staging | 1 a 3 días de ingeniería | Contenedor fijado, dos proveedores, config, una clave virtual, logs básicos y smoke tests | | Base de producción en una región | 1 a 3 semanas de ingeniería | Réplicas, TLS, Postgres y Redis gestionados, secretos, presupuestos, métricas, backups, canary y runbook | | Plataforma regulada o multiequipo | 4 a 10 semanas de ingeniería | Identidad, política por tenant, evidencia de auditoría, privacidad, recuperación, carga y handover | | Propiedad continua | Capacidad mensual nombrada más guardia | Parches, cambios de proveedor, revisión del mapa de costes, incidentes, accesos y simulacros de restore | 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](/es/blog/reduce-llm-token-costs-2026/). ## Preguntas frecuentes ### ¿Es gratis autoalojar LiteLLM? El gateway open source no cobra licencia. Sigues pagando compute, PostgreSQL, Redis, tráfico, observability, backups, uso de modelos y los ingenieros que lo parchean y operan. El gobierno y soporte Enterprise tienen precio separado. ### ¿Autoalojar LiteLLM mantiene los prompts en mis servidores? El prompt pasa por tu gateway, pero sale hacia un proveedor alojado salvo que el modelo elegido corra en infraestructura bajo tu control. Revisa todo el recorrido, incluidos logs, callbacks, retención del proveedor y backups. ### ¿Puede LiteLLM ejecutarse en Docker sin Kubernetes? Sí. Docker sirve para desarrollo, staging y ciertos despliegues en VM. Producción todavía necesita varios procesos o réplicas, TLS, Postgres, Redis, health checks, backups, monitorización y un proceso de release seguro. Kubernetes es una forma de aportar controles, no el objetivo. ### ¿Necesita LiteLLM Postgres y Redis? Postgres es necesario para autenticación del proxy, claves virtuales y seguimiento de gasto. Redis es necesario cuando varias instancias comparten límites, estado de routing y caché. Un experimento stateless puede funcionar sin toda la capa de datos, pero no es el diseño de producción multiequipo. ### ¿Qué versión de LiteLLM debo desplegar? Usa la release stable con soporte actual, fija su tag o digest exacto, verifica la firma y pruébala antes de promocionar. No uses tags móviles ni trates un mínimo de parche antiguo como recomendación actual. ### ¿Cuándo conviene una alternativa gestionada? Elige gestionado cuando ningún equipo sea responsable de parches, recuperación y guardia, o cuando el time to market pese más que el control privado. Reconsidera autoalojar cuando compliance, red, portabilidad o escala creen un caso de negocio concreto. ## Reflexiones finales LiteLLM autoalojado es un servicio pequeño con un radio de impacto grande. El contenedor es fácil. Producción es la disciplina que lo rodea: red privada, releases firmadas y fijadas, claves acotadas, Postgres, Redis, métricas, backups, simulacros y un responsable que pueda parchear rápido. Usa LiteLLM cuando un gateway controlado simplifique varios productos y proveedores. Trata la inferencia como otra decisión arquitectónica. Si tu equipo no puede sostener el gateway durante un incidente y un restore, compra la operación como servicio gestionado. Si puede, empieza con un contrato estrecho en staging, demuestra resiliencia y amplía solo con evidencia. ## También te puede gustar.. [**Gateways LLM comparados en 2026** Elige entre LiteLLM, OpenRouter, Portkey y RouteLLM antes de comprometerte con un modelo operativo.](/es/blog/llm-gateway-router-comparison-2026/) [**Cuestionario de seguridad para proveedores de IA en la UE** Convierte promesas de seguridad, privacidad, retención e incidentes en solicitudes de evidencia.](/es/blog/ai-vendor-security-questionnaire-eu/) Modelos e infraestructura ## Continúa por este clúster Selección de modelos, economía de inferencia, despliegue local, compresión y serving. [Empieza por el artículo fundamental**Alojar LLMs en la UE: Cuándo Salen a Cuenta los Open Weights**](/es/blog/self-hosting-llms-eu-cost/) - [Wiki empresarial preparada para IA: arquitectura e implementación](/es/blog/ai-ready-company-wiki/) - [¿Claude añade marcas de agua al texto? Respuesta API 2026](/es/blog/claude-text-watermark-api-2026/) - [Review de OpenKB: compilador de conocimiento vs RAG](/es/blog/openkb-review-vs-rag/) - [Unsloth Desktop: ¿workstation privada de IA local?](/es/blog/unsloth-desktop-local-ai-workstation-review/) - [NeMo Switchyard 0.2: ¿routing de agentes sin entrenar?](/es/blog/nemo-switchyard-model-router/) Tu bandeja, sin ruido ## Sigue el trabajo que te importa Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan. [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 min de lectura · 13 de agosto de 2026 [**Siguiente**](/es/blog/linux-for-ai-agents/) Nuevos artículos por correo × × Recibe nuevos artículos por correo Un correo breve cuando publicamos. Gratis y sin seguimiento. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/self-host-litellm-production-2026/#webpage", "@type": "WebPage", "dateModified": "2026-08-13", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-13", "url": "https://wavect.io/es/blog/self-host-litellm-production-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Autoalojar LiteLLM significa operar el gateway de IA, no necesariamente los modelos que hay detrás. Un entorno de producción necesita al menos dos réplicas con versión exacta tras TLS, Postgres gestionado y privado, Redis para compartir límites y estado de routing, claves virtuales limitadas, gestión de secretos, sondas de salud, métricas, backups y una ruta de upgrade probada. LiteLLM OSS no cobra licencia, pero la infraestructura y la guardia operativa sí cuestan. El ataque a PyPI y las vulnerabilidades del proxy de 2026 convierten el pin de versión, la verificación de firma, la restricción de red y el parcheo rápido en requisitos de lanzamiento. Empieza con un contenedor de staging y adopta el stack resiliente cuando control, compliance o portabilidad justifiquen operarlo.", "articleBody": " Resumen del blog/IA y agentes/Modelos e infraestructura Cómo autoalojar LiteLLM en producción: arquitectura y seguridad para 2026 Resumen Autoalojar LiteLLM significa operar el gateway de IA, no necesariamente los modelos que hay detrás. Un entorno de producción necesita al menos dos réplicas con versión exacta tras TLS, Postgres gestionado y privado, Redis para compartir límites y estado de routing, claves virtuales limitadas, gestión de secretos, sondas de salud, métricas, backups y una ruta de upgrade probada. LiteLLM OSS no cobra licencia, pero la infraestructura y la guardia operativa sí cuestan. El ataque a PyPI y las vulnerabilidades del proxy de 2026 convierten el pin de versión, la verificación de firma, la restricción de red y el parcheo rápido en requisitos de lanzamiento. Empieza con un contenedor de staging y adopta el stack resiliente cuando control, compliance o portabilidad justifiquen operarlo. 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. SituaciónDefault recomendadoPor qué Un prototipo, un proveedor, sin responsable de plataformaLlamar al proveedor directamenteEl gateway añade otra dependencia de producción antes de resolver un problema real. Varios productos o equipos comparten cuentas de proveedorEl autoalojamiento puede compensarClaves acotadas, presupuestos centrales y una abstracción de proveedor crean un punto de control claro. La velocidad de entrega importa más que el control de infraestructuraUsar un gateway gestionadoCompras operaciones, upgrades y soporte en vez de construirlos. La red privada, el despliegue en la UE o controles propios son obligatoriosEvaluar autoalojamientoEliges red, región, logs, retención y cadencia de despliegue. También necesitas inferencia localSeparar gateway e inferenciaLiteLLM enruta peticiones. vLLM, Ollama u otro servidor ejecuta el modelo. ¿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. CapaResponsabilidad en producciónPregunta de fallo Ingress TLS o balanceadorTerminar TLS, restringir rutas, limitar abuso y drenar réplicas¿Puede un cliente defectuoso alcanzar endpoints de gestión o agotar el servicio? Dos o más réplicas LiteLLMServir tráfico desde una versión exacta y firmada de la imagen¿Interrumpe un rollout o un pod caído los streams activos? PostgreSQL gestionadoPersistir claves, equipos, gasto y configuración con backups¿Puedes restaurar antes de que el gateway cause una caída para toda la empresa? Redis gestionadoCompartir límites, caché y estado de routing entre réplicas¿Siguen siendo correctos los límites cuando el tráfico cae en pods distintos? Gestor de secretosGuardar credenciales de proveedor, master key y salt key permanente¿Puede una aplicación recuperar la credencial de proveedor de otra?", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "documentación oficial", "url": "https://docs.litellm.ai/" }, { "@type": "WebPage", "name": "página de precios de LiteLLM", "url": "https://www.litellm.ai/pricing" }, { "@type": "WebPage", "name": "guía actual de despliegue en producción de LiteLLM", "url": "https://docs.litellm.ai/docs/proxy/deploy" }, { "@type": "WebPage", "name": "lista de producción", "url": "https://docs.litellm.ai/docs/proxy/prod" }, { "@type": "WebPage", "name": "documentación de claves virtuales", "url": "https://docs.litellm.ai/docs/proxy/virtual_keys" }, { "@type": "WebPage", "name": "cronología del incidente", "url": "https://github.com/BerriAI/litellm/issues/24518" }, { "@type": "WebPage", "name": "inyección SQL crítica en la verificación de API keys", "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc" }, { "@type": "WebPage", "name": "inyección de comandos en endpoints de prueba MCP", "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g" }, { "@type": "WebPage", "name": "escalada de privilegios mediante claves virtuales", "url": "https://github.com/advisories/GHSA-qrc4-49gv-mv9m" }, { "@type": "WebPage", "name": "página de releases de LiteLLM", "url": "https://github.com/BerriAI/litellm/releases" }, { "@type": "WebPage", "name": "prácticas de seguridad de LiteLLM", "url": "https://docs.litellm.ai/docs/proxy/security_best_practices" }, { "@type": "WebPage", "name": "contrato de health checks", "url": "https://docs.litellm.ai/docs/proxy/health" } ], "dateModified": "2026-08-13", "datePublished": "2026-08-13", "description": "Autoalojar LiteLLM significa operar el gateway de IA, no necesariamente los modelos que hay detrás. Un entorno de producción necesita al menos dos réplicas con versión exacta tras TLS, Postgres gestionado y privado, Redis para compartir límites y estado de routing, claves virtuales limitadas, gestión de secretos, sondas de salud, métricas, backups y una ruta de upgrade probada. LiteLLM OSS no cobra licencia, pero la infraestructura y la guardia operativa sí cuestan. El ataque a PyPI y las vulnerabilidades del proxy de 2026 convierten el pin de versión, la verificación de firma, la restricción de red y el parcheo rápido en requisitos de lanzamiento. Empieza con un contenedor de staging y adopta el stack resiliente cuando control, compliance o portabilidad justifiquen operarlo.", "headline": "Cómo autoalojar LiteLLM en producción: guía 2026", "image": "https://wavect.io/img/blog/headers/header_self-host-litellm-production-2026.svg", "inLanguage": "es", "keywords": "LiteLLM, Infraestructura de IA, Gateway LLM, Autoalojamiento", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/self-host-litellm-production-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/self-host-litellm-production-2026/", "wordCount": 2548 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/ai-agents/", "name": "IA y agentes", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/models-infrastructure/", "name": "Modelos e infraestructura", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/self-host-litellm-production-2026/", "name": "Autoalojar LiteLLM en producción: guía 2026 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "El gateway open source no cobra licencia. Sigues pagando compute, PostgreSQL, Redis, tráfico, observability, backups, uso de modelos y los ingenieros que lo parchean y operan. El gobierno y soporte Enterprise tienen precio separado." }, "name": "¿Es gratis autoalojar LiteLLM?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "El prompt pasa por tu gateway, pero sale hacia un proveedor alojado salvo que el modelo elegido corra en infraestructura bajo tu control. Revisa todo el recorrido, incluidos logs, callbacks, retención del proveedor y backups." }, "name": "¿Autoalojar LiteLLM mantiene los prompts en mis servidores?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Sí. Docker sirve para desarrollo, staging y ciertos despliegues en VM. Producción todavía necesita varios procesos o réplicas, TLS, Postgres, Redis, health checks, backups, monitorización y un proceso de release seguro. Kubernetes es una forma de aportar controles, no el objetivo." }, "name": "¿Puede LiteLLM ejecutarse en Docker sin Kubernetes?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Postgres es necesario para autenticación del proxy, claves virtuales y seguimiento de gasto. Redis es necesario cuando varias instancias comparten límites, estado de routing y caché. Un experimento stateless puede funcionar sin toda la capa de datos, pero no es el diseño de producción multiequipo." }, "name": "¿Necesita LiteLLM Postgres y Redis?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Usa la release stable con soporte actual, fija su tag o digest exacto, verifica la firma y pruébala antes de promocionar. No uses tags móviles ni trates un mínimo de parche antiguo como recomendación actual." }, "name": "¿Qué versión de LiteLLM debo desplegar?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Elige gestionado cuando ningún equipo sea responsable de parches, recuperación y guardia, o cuando el time to market pese más que el control privado. Reconsidera autoalojar cuando compliance, red, portabilidad o escala creen un caso de negocio concreto." }, "name": "¿Cuándo conviene una alternativa gestionada?" } ] } ```