LiteLLM: un proxy para unificar proveedores de modelos

javi
Router de fibra con cables conectados representando orquestación de tráfico entre proveedores

Toda organización que usa LLMs en producción se enfrenta pronto a la misma realidad: quieres usar varios proveedores. OpenAI para un caso, Claude para otro, Mistral self-hosted para sensitive data, Cohere para embeddings multilingüe. El código rápidamente se llena de adaptadores, cada SDK con sus peculiaridades, sin forma unificada de hacer rate limiting, fallbacks, o observabilidad.

LiteLLM resuelve este problema con una API unificada compatible con OpenAI, routing inteligente, y un proxy desplegable. Este artículo cubre qué hace, cuándo tiene sentido, y cómo desplegarlo sin complicar tu stack.

El problema que resuelve

Sin LiteLLM, una aplicación que usa 3 proveedores tiene:

# OpenAI
from openai import OpenAI
client_oai = OpenAI(api_key=...)

# Anthropic
from anthropic import Anthropic
client_ant = Anthropic(api_key=...)

# Ollama local
import requests
ollama_response = requests.post("http://localhost:11434/api/generate", ...)

Cada uno con payload y response shape distintos. Para añadir cache, rate limit, fallback si uno falla, tienes que envolver cada uno. Escala mal.

LiteLLM convierte esto en:

from litellm import completion

response = completion(model="gpt-4", messages=[...])
response = completion(model="claude-3-sonnet-20240229", messages=[...])
response = completion(model="ollama/llama2", messages=[...])

Mismo shape, misma abstracción.

Dos modos de uso

Modo librería: importar litellm en tu código. Simple para apps monolíticas.

Modo proxy: desplegar un servidor LiteLLM separado. Tu app habla con http://localhost:4000 via OpenAI SDK. Recomendado para:

  • Múltiples servicios compartiendo acceso a LLMs.
  • Necesidad de gestión central de keys, budgets, rate limits.
  • Observabilidad agregada.
  • Admin teams que no quieren modificar código de apps.

Para empresas serias, el modo proxy es casi siempre la opción correcta.

Proxy: deploy básico

# litellm_config.yaml
model_list:
  - model_name: gpt-4
    litellm_params:
      model: openai/gpt-4
      api_key: os.environ/OPENAI_API_KEY
  - model_name: claude-3-sonnet
    litellm_params:
      model: anthropic/claude-3-sonnet-20240229
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: mistral-local
    litellm_params:
      model: ollama/mistral
      api_base: http://ollama.internal:11434

general_settings:
  master_key: sk-master-123
  database_url: os.environ/DATABASE_URL  # para tracking de usage

Docker:

docker run -p 4000:4000 \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e OPENAI_API_KEY=... \
  -e ANTHROPIC_API_KEY=... \
  ghcr.io/berriai/litellm:main \
  --config /app/config.yaml

Apps consumen con:

from openai import OpenAI
client = OpenAI(base_url="http://litellm:4000", api_key="sk-user-123")
response = client.chat.completions.create(model="gpt-4", ...)

La app no sabe que hay LiteLLM en medio. Totalmente transparente.

Features que importan

Fallbacks automáticos

Si OpenAI cae o rate-limitea, fallback a Claude:

router_settings:
  fallbacks:
    - gpt-4: ["claude-3-sonnet"]
    - claude-3-sonnet: ["mistral-local"]

Apps ni se enteran. Para resilience en producción, crítico.

Rate limiting y budgets

Por usuario / key / modelo:

general_settings:
  master_key: sk-master-123

# Crear user key con budget via API
curl -X POST http://litellm:4000/key/generate \
  -H "Authorization: Bearer sk-master-123" \
  -d '{"models": ["gpt-4"], "max_budget": 100, "duration": "30d"}'

Evita que un equipo quemé el presupuesto corporativo.

Caching

Cache de respuestas semánticamente equivalentes:

cache:
  type: redis
  host: redis.internal
  ttl: 3600
  supported_call_types: ["completion", "embedding"]

Útil para patrones de consulta repetidos.

Observability

LiteLLM expone métricas Prometheus y logs estructurados. Integración con:

  • Langfuse
  • Helicone
  • Sentry
  • Prometheus / Grafana

Para trazar coste, latencia y errores por modelo/tenant.

Comparación con alternativas

LiteLLM no es único:

  • Portkey: SaaS con gateway similar, UI más pulida, comercial.
  • OpenRouter: SaaS que unifica APIs de LLMs, con billing consolidado.
  • Helicone: foco en observabilidad, puede proxy también.
  • Self-built: FastAPI + switch/case. Funciona para <3 proveedores.

LiteLLM es el OSS más completo; Portkey el comercial más pulido. Para empresas sensitivas a vendor lock-in, LiteLLM es la apuesta segura.

Limitaciones

Ser honesto:

  • Feature parity imperfecto: algunas features específicas de proveedor (structured output, function calling variaciones) pueden no traducir 1:1.
  • Latencia adicional: un hop extra añade 5-20ms. Despreciable para LLM, visible para embeddings.
  • Complejidad operativa: el proxy es otra pieza que mantener.
  • Ecosistema SDK: algunos clients nativos tienen features que el OpenAI client estándar no soporta.

Cuándo NO es necesario

Si tu uso es:

  • Un solo proveedor sin planes de cambiar.
  • Uso experimental o de prototipo.
  • Un solo desarrollador experimentando.

Una capa provider.py con if/else cubre. LiteLLM introduce complejidad no justificada.

Casos donde LiteLLM brilla

  • Empresa con múltiples teams: proxy central con keys/budgets por team.
  • Aplicación multi-proveedor que quiere seleccionar el mejor por tarea.
  • Resiliencia crítica: fallbacks automatizados.
  • Coste control: visibilidad y rate limiting centralizado.
  • Compliance: punto único para auditoría, redacción, compliance checks.

Patrones de routing

LiteLLM soporta routing avanzado:

  • By cost: preferir el modelo más barato capaz.
  • By latency: menor latencia percibida.
  • By availability: skip proveedores con alto error rate.
  • By specific tags (prod, dev, sensitive).
router_settings:
  routing_strategy: least-busy

Para apps con requirements específicos por request, esto es oro.

Seguridad

Checklist mínima:

  • Keys de proveedores solo en el proxy, nunca en apps.
  • Keys de usuario con budget limitado y duración corta.
  • TLS obligatorio al proxy.
  • Audit logs para compliance.
  • Rate limit agresivo contra abuso.

Deployment en Kubernetes

Para producción:

  • Deployment con 2+ réplicas detrás de service.
  • PostgreSQL o Redis backend para state (keys, budgets, cache).
  • Prometheus ServiceMonitor para scraping.
  • PodDisruptionBudget para upgrades sin downtime.
  • HPA basado en CPU/memory.

Chart de Helm oficial existe pero es básico; ajustar para producción.

Casos reales

Patrón que hemos visto funcionar:

  • Frontend web llama a /api/llm/chat en tu backend.
  • Backend hace ruta OpenAI-compat a LiteLLM proxy.
  • LiteLLM rutea según tags (user tier, request type) a GPT-4, Claude, o Mistral.
  • Si OpenAI falla, fallback automático.
  • Observability: cada request tiene tenant_id, modelo, tokens, coste en Prometheus.

30 líneas de código en backend, un binario corriendo, toda la complejidad de multi-LLM gestionada.

Conclusión

LiteLLM es de las herramientas más útiles que han salido en el ecosistema LLM durante 2023-2024. Para equipos que usan un solo proveedor, es overkill. Para equipos que usan dos o más, o que quieren preparar el terreno para hacerlo, es casi obligatorio. El proxy elimina fricción de integración, permite governance centralizada y facilita migraciones entre modelos. Adopción tiene coste operativo pero paga dividendos pronto. Si estás construyendo LLM seriamente, probablemente necesitas LiteLLM o equivalente — mejor adoptarlo pronto que integrarlo tras meses de código multi-SDK.

Síguenos en jacar.es para más sobre LLMs en producción, arquitecturas IA y proxys inteligentes.

Entradas relacionadas