Alojar LiteLLM en un VPS: su pasarela de API LLM privada

Por qué LiteLLM es la capa que falta en las pilas de IA autoalojadas

Lo que LiteLLM le aporta desde el primer momento

• API unificada y compatible con OpenAI: funciona con todos los SDK, bibliotecas y herramientas que apuntan a la API de OpenAI.
• Más de 100 integraciones de proveedores: Ollama, Anthropic, OpenAI, Azure OpenAI, Mistral, Cohere, Bedrock y muchos otros.
• Claves de API virtuales con límites de gasto y de tasa por clave: reparta claves entre los equipos y ponga topes a los costes mensuales.
• Panel integrado en /ui con análisis del gasto en tiempo real, desglose por modelo y registros de las peticiones.
• Reparto de carga y conmutación automática entre varios endpoints de proveedores o réplicas de modelos.
• Licencia Apache 2.0: sin telemetría, sin envío de información al exterior, totalmente compatible con entornos air-gap cuando se asocia a Ollama.

Requisitos

Desplegar LiteLLM en un VPS

1. 01

   Aprovisionar el VPS

   Contrate un VPS Start (2 vCPU, 4 GB, Ubuntu 22.04): LiteLLM se conforma con 1 GB y el plan más pequeño del catálogo sirve el doble. Conéctese por SSH e instale Docker: curl -fsSL https://get.docker.com | sh. El plugin Compose viene incluido.

2. 02

   Generar los secretos

   Ejecute openssl rand -hex 32 para generar LITELLM_MASTER_KEY: es la que desbloquea el panel y todos los endpoints de API de administración. Cree /opt/litellm/.env con: LITELLM_MASTER_KEY, UI_USERNAME, UI_PASSWORD, DB_NAME=litellm, DB_USER=litellm, DB_PASSWORD=<strong-password>.

3. 03

   Redactar docker-compose.yml

   Cree /opt/litellm/docker-compose.yml con dos servicios: db (postgres:16-alpine, variables de entorno procedentes del .env, volumen litellm_db) y litellm (imagen ghcr.io/berriai/litellm fijada a una versión explícita y a su resumen @sha256:, nunca a main-latest —véase «Cadena de suministro» más abajo—, puerto 4000:4000, depends_on db, DATABASE_URL + LITELLM_MASTER_KEY + UI_USERNAME + UI_PASSWORD, volumen litellm_config:/app/data). Ejecute docker compose up -d.

4. 04

   Abrir el panel

   Vaya a http://<vps-ip>:4000/ui y conéctese con sus UI_USERNAME / UI_PASSWORD. Llegará al panel de LiteLLM. Entre en Models para añadir su primer proveedor. Para una instancia de Ollama local en el mismo VPS, defina el nombre del modelo como ollama/llama3.1 y la API base como http://host.docker.internal:11434. Para Anthropic, pegue su clave de API y añada anthropic/claude-3-5-haiku-20241022.

5. 05

   Probar la pasarela

   Desde su puesto de trabajo, pruebe: curl http://<vps-ip>:4000/v1/chat/completions -H "Authorization: Bearer <LITELLM_MASTER_KEY>" -H 'Content-Type: application/json' -d '{"model": "ollama/llama3.1", "messages": [{"role": "user", "content": "Hello"}]}'. Debería recibir una respuesta en streaming, encaminada por LiteLLM hacia su Ollama.

6. 06

   Repartir claves de API entre los equipos

   En el panel, dentro de API Keys, haga clic en New Key. Póngale una descripción (por ejemplo «frontend-team»), defina max_budget: 50 (USD/mes) y un tpm_limit opcional. Comparta esa clave con el equipo: apuntará su SDK de OpenAI a http://<vps-ip>:4000 y usará esa clave. El gasto se sigue por clave en el panel.

7. 07

   Añadir el HTTPS con Caddy

   Instale Caddy: apt install -y caddy. Edite /etc/caddy/Caddyfile: llm.su-dominio.com { reverse_proxy localhost:4000 }. Recargue: systemctl reload caddy. Cierre el puerto 4000 en su firewall: todo el tráfico pasa ya por el 443 con TLS automático.

8. 08

   Conectarse por primera vez

   Abra la interfaz de administración en /ui: LiteLLM muestra un formulario de usuario y contraseña. Introduzca admin y la contraseña facilitada, y después cree sus claves virtuales desde el panel.

Cadena de suministro: fijar, verificar y rotar las claves

Saber qué se ejecuta de verdad en su servidor

1. 09

   Leer el resumen de la imagen

   Una etiqueta como main-latest no dice nada de lo que se ejecuta. Ejecute docker compose images y luego docker image inspect --format '{{index .RepoDigests 0}}' ghcr.io/berriai/litellm:main-latest (sustitúyala por la referencia de su archivo compose). Anote el sha256: obtenido y compárelo con el de una versión cuya procedencia haya verificado.

2. 10

   Buscar los archivos citados, sin lanzar Python

   En un entorno sospechoso, cada arranque de Python vuelve a ejecutar el código malicioso, pip incluido. Busque con una herramienta que no lo lance: docker compose exec litellm find / -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' -o -name 'litellm-1.107.0.dist-info' 2>/dev/null (si la imagen incluye find). Un sitecustomize.py aislado en otra parte del sistema puede ser legítimo; lo que debe alarmar es un cook.pth a su lado en site-packages, o una carpeta litellm-1.107.0.dist-info. Encontrar esos archivos confirma la exposición; no encontrar nada no prueba que el entorno esté limpio.

3. 11

   Leer la versión instalada

   Cuando nada resulte sospechoso, pip show litellm (en el entorno virtual de una instalación directa) o docker compose exec litellm pip show litellm indica la versión. Si es la 1.107.0, o si duda de una imagen descargada en aquel periodo, pase de inmediato a la rotación de claves más abajo.

4. 12

   Buscar rastros de ejecución

   El informe menciona un bloqueo /tmp/remote_code_loader.lock, un proceso python huérfano cuyo directorio actual es /, y un archivo testigo /tmp/.pc_once_* escrito solo tras un envío logrado. Su ausencia no prueba nada: un contenedor recreado borra /tmp. Úselo como indicio, no como veredicto.

Fijar por resumen en lugar de por etiqueta

Actualizar sin sorpresas

• Lea las notas de la versión y el estado del hilo de seguridad antes de cambiar de versión, en lugar de dejar que docker compose pull siga una etiqueta.
• Obtenga el nuevo resumen desde una máquina de pruebas, arranque la pasarela sin claves reales, compruebe su comportamiento y solo entonces lleve el resumen a producción.
• Cuando el editor publique atestaciones de procedencia, verifíquelas: indican de dónde viene una imagen, algo que un simple resumen no dice.
• Conserve el resumen anterior en su repositorio de configuración: volver atrás pasa a ser un cambio de una línea.
• Tras cualquier alerta de seguridad, reconstruya contenedores y entornos virtuales desde cero en lugar de limpiar sobre el sitio.

Si la 1.107.0 llegó a ejecutarse: rotar todas las claves

Qué hay que renovar

• Todas las claves de proveedores guardadas en la pasarela: Anthropic, OpenAI, Azure, Mistral, Bedrock y cada una de las demás.
• LITELLM_MASTER_KEY y todas las claves virtuales entregadas a los equipos.
• La contraseña de la base de datos (DB_PASSWORD y el DATABASE_URL que la incluye), así como UI_PASSWORD.
• Cualquier secreto presente en el entorno de un proceso del servidor: tokens de API, contraseñas de servicios vecinos, archivos .env.
• Las claves SSH, tokens de Git y credenciales de nube accesibles desde el VPS, si el servidor llevaba alguna.
• Tras la rotación, reconstruya el VPS o, como mínimo, los contenedores desde una imagen verificada: copiar secretos nuevos en un servidor comprometido los expone de nuevo.