Cómo instalar LiteLLM para controlar en un solo lugar el gasto de tus modelos de IA, locales y de pago

Si sigues esta serie, probablemente ya tengas Ollama corriendo modelos locales, y quizás también una llave de API de un proveedor de pago para las tareas que exigen más capacidad. El problema con tener ambos por separado es que cada app que construyes termina hablándole directamente a uno o al otro, sin ningún lugar central donde ver cuánto estás gastando en total ni forma de cortarle el acceso a una sola app sin tocar las demás. LiteLLM resuelve exactamente eso: es un proxy de código abierto que expone un único endpoint compatible con el formato de OpenAI, y detrás de ese endpoint enruta cada solicitud al proveedor real que corresponda —tu Ollama local, o un proveedor de pago— según el modelo que le pidas.

Si todavía no tienes Docker instalado, instálalo primero — ya lo cubrimos en una guía anterior.

Crea un archivo de configuración donde defines qué modelos va a exponer LiteLLM y a dónde apunta cada uno realmente:

mkdir -p ~/litellm-config
nano ~/litellm-config/config.yaml

Con un contenido como este, que combina un modelo local con uno de pago bajo el mismo proxy:

model_list:
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1:8b
      api_base: http://host.docker.internal:11434

  - model_name: gpt-tareas-complejas
    litellm_params:
      model: gpt-4o
      api_key: TU_LLAVE_DE_API_AQUI

Cada entrada tiene un model_name (el alias que vas a usar desde tus apps) y el proveedor real detrás. Así, tus aplicaciones nunca necesitan saber si están hablando con tu servidor local o con un proveedor externo — solo piden local-llama o gpt-tareas-complejas, y LiteLLM decide a dónde mandarlo.

Levanta LiteLLM con Docker, montando ese archivo de configuración y definiendo una llave maestra propia (no la del proveedor externo, sino una que tú inventas para proteger tu propio proxy):

docker run -d --name litellm \
  -p 4000:4000 \
  -v ~/litellm-config/config.yaml:/app/config.yaml \
  -e LITELLM_MASTER_KEY="sk-tu-llave-maestra-aqui" \
  --add-host host.docker.internal:host-gateway \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

Confirma que está corriendo con una solicitud de prueba:

curl http://localhost:4000/chat/completions \
  -H "Authorization: Bearer sk-tu-llave-maestra-aqui" \
  -H "Content-Type: application/json" \
  -d '{"model": "local-llama", "messages": [{"role": "user", "content": "Responde solo: funciona"}]}'

Ahora crea una llave virtual con presupuesto limitado para cada app o equipo que vaya a usar el proxy, en vez de repartir tu llave maestra a todo el mundo:

curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-tu-llave-maestra-aqui" \
  -H "Content-Type: application/json" \
  -d '{"max_budget": 10, "duration": "30d"}'

Esto te devuelve una llave nueva con un límite de gasto de 10 dólares durante 30 días — cuando esa app llegue al límite, LiteLLM le corta el acceso automáticamente, sin que tengas que estar revisando facturas manualmente para darte cuenta de que algo se descontroló.

Apunta tus aplicaciones al proxy en vez de hablarle directo a cada proveedor. Cualquier app que ya use el formato de API de OpenAI solo necesita cambiar la URL base a http://IP-DE-TU-SERVIDOR:4000 y usar la llave virtual correspondiente — el resto del código no cambia.

No dejes el puerto 4000 abierto a internet sin protección, sobre todo porque ahí vive el control de acceso a tus proveedores de pago. Si necesitas acceso desde fuera de tu red, ponlo detrás de un proxy con autenticación real, como ya cubrimos con Cloudflare Tunnel y ZTNA en otra guía.

Correr un proxy que centraliza el tráfico de todas tus aplicaciones de IA merece un servidor con disponibilidad estable — si se cae, se caen con él todas las apps que dependen de sus modelos. En /planes/vds tienes los recursos dedicados para que ese punto central no se convierta en tu punto único de falla.