18 junio 2026

Cómo gestiono 27 agentes IA con un único router: LiteLLM + NVIDIA NIM + OpenRouter

Hace tres semanas me quedé sin créditos en el proveedor LLM que usaba para todos mis agentes. De la noche a la mañana, 27 agentes quedaron sin modelo. No es que no tuviera alternativas: tenía clave de NVIDIA NIM (40 RPM, gratis), una de OpenRouter con crédito sobrante, y otra de Together AI por si acaso. El problema era que cada agente apuntaba a un endpoint distinto, y cambiarlos uno a uno no era viable. Necesitaba un router unificado que decidiera automáticamente dónde enviar cada petición.

El problema real

Mi stack de agentes corre sobre Paperclip, una plataforma de orquestación multi-agente. Cada agente estaba configurado con su propio base_url apuntando al proveedor original. Cuando se agotó, tenía dos opciones: cambiar la URL de cada agente individualmente (lento y propenso a errores) o poner un proxy intermedio que decidiera por mí.

Elegí la segunda. LiteLLM Proxy actúa como un router transparente frente a múltiples proveedores. Recibe peticiones en formato OpenAI y las redirige al proveedor que tengas configurado, con rate limiting, fallback automático y métricas en tiempo real.

La arquitectura que monté

La idea es simple: todos los agentes apuntan al LiteLLM Proxy interno. Él decide, según el modelo solicitado y la disponibilidad, si envía la petición a NVIDIA NIM (gratis, 40 RPM) o a OpenRouter (de pago, fallback). Si NVIDIA devuelve un 429 por rate limit, LiteLLM reintenta automáticamente con el siguiente proveedor en la lista.

# docker-compose.yml — truco clave: configs.content

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    configs:
      - source: litellm_config
        target: /app/proxy_config.yaml
    ports:
      - "4000:4000"
    environment:
      - LITELLM_MODE=PROXY
configs:
  litellm_config:
    content: |
      model_list:
        - model_name: claude-sonnet-4-6
          litellm_params:
            model: anthropic/claude-sonnet-4-6-20251001
            api_key: os.environ/ANTHROPIC_API_KEY
            rpm: 18
            provider: anthropic
          model_info:
            mode: completion
        - model_name: claude-sonnet-4-6
          litellm_params:
            model: openrouter/anthropic/claude-sonnet-4-6
            api_key: os.environ/OPENROUTER_API_KEY
            provider: openrouter
          model_info:
            mode: completion

Fíjate en el truco: uso configs.content dentro del Docker Compose en lugar de un volumen bind-mount. Esto evita que si el archivo de configuración no existe en el host (o tiene permisos incorrectos) el contenedor falle. La config se embebe directamente en el compose, lo que la hace portátil y reproducible.

Rate limiting por tier y fallback automático

La clave está en el rpm: 18 del primer proveedor (NVIDIA). Con 27 agentes y algunos tándems (agente que llama a otro), esos 18 RPM se agotan rápido. Cuando llega el límite, LiteLLM detecta el 429 y reintenta con el siguiente proveedor configurado para el mismo modelo. En mi caso, OpenRouter como fallback. El agente ni sabe que ha cambiado de proveedor: todo es transparente.

Para Paperclip, la integración es trivial. Un solo environment variable apunta al proxy: OPENAI_BASE_URL=http://litellm:4000. Desde ahí, todos los agentes usan el mismo endpoint y el mismo modelo lógico (claude-sonnet-4-6), independientemente de quién lo sirva realmente.

Costes reales y decisiones tácticas

NVIDIA NIM ofrece 40 RPM gratuitos en su tier free. Eso equivale a unas 2.400 peticiones por hora, suficiente para desarrollo y staging. En producción, donde el volumen es más alto, el fallback a OpenRouter cubre el excedente. El coste medio es de ~0,003€ por 1K tokens con Claude Sonnet 4.6, lo que lo hace manejable incluso con 27 agentes activos.

La decisión táctica clave fue no intentar unificar todos los modelos, sino solo el que usa el 90% de los agentes (Claude Sonnet 4.6). El resto de modelos especializados ( embeddings, Whisper, etc.) siguen apuntando directamente a sus endpoints propios. No sobrecompliques lo que no necesitas unificar.

Errores que me ahorré al usar LiteLLM

• No tuve que tocar código de los agentes. Un cambio de variable de entorno fue suficiente.
• El rate limit por modelo me protegió de quemar créditos en OpenRouter por descuido.
• El fallback automático evitó downtime cuando NVIDIA devolvía 429 intermitentes.
• El logging unificado me permitió ver en tiempo real qué proveedor estaba sirviendo cada petición.

Conclusión: no gestiones 27 conexiones cuando puedes gestionar una sola

Si tienes más de dos proveedores LLM en tu stack, pon un proxy delante. LiteLLM no es la única opción, pero es la que mejor balance ofrece entre simplicidad y capacidades. El objetivo no es optimizar al milímetro, es no quedarte tirado cuando un proveedor falla. Y eso, con 27 agentes dependiendo de ti, no es opcional.

Si estás montando algo similar y quieres que le eche un ojo, escríbeme por LinkedIn价比:rgba.

— Ricardo Martínez
Barcelona, junio de 2026