LiteLLM

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

Normaliza peticiones y respuestas y ofrece un proxy para políticas transversales, observabilidad y enrutamiento. Puede centralizar límites y seguimiento de uso.

Ejemplo de uso

Configurar una ruta principal y una alternativa compatible. Registrar coste, latencia y motivo del fallback, y comprobar que ambos modelos respetan el contrato de salida requerido.

Dos formas de uso

Modo	Uso
SDK	Librería Python: misma interfaz para más de cien proveedores
Proxy	Gateway con API compatible con OpenAI, claves virtuales, presupuestos y registro centralizado

from litellm import completion

res = completion(
    model="anthropic/claude-sonnet-5-5",           # o "vertex_ai/gemini-2.5-flash", "ollama/llama3.1"
    messages=[{"role": "user", "content": "Resume esta política en 3 puntos"}],
)
print(res.choices[0].message.content)

Configuración del proxy

model_list:
  - model_name: principal
    litellm_params:
      model: anthropic/claude-sonnet-5-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: respaldo
    litellm_params:
      model: vertex_ai/gemini-2.5-flash
      vertex_project: krediya-ia
      vertex_location: us-east1
  - model_name: economico
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  fallbacks: [{ principal: [respaldo] }]
  num_retries: 2
  request_timeout: 30
  success_callback: [langfuse]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL # necesario para claves virtuales y gastos

Las aplicaciones usan el SDK de OpenAI apuntando al proxy y piden model="principal": cambiar de proveedor es un cambio de configuración.

Claves virtuales y presupuestos

curl -X POST http://litellm:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{"team_id": "cobranza", "models": ["principal", "economico"], "max_budget": 200, "budget_duration": "30d"}'

Cada equipo o aplicación recibe su propia clave con modelos permitidos, límites de gasto y de peticiones, y el coste queda atribuido.

Funciones del gateway

Función	Descripción
Enrutamiento	Balanceo entre despliegues, por latencia o por coste
Fallbacks	Modelo alternativo ante errores, límites o contexto excedido
Caché	Respuestas cacheadas (Redis) para peticiones repetidas
Guardrails	Integración con moderación, detección de PII o NeMo Guardrails
Observabilidad	Callbacks a Langfuse, LangSmith, Datadog, OpenTelemetry
Endpoints	Chat, embeddings, imágenes, audio, batch, MCP

Consideraciones

Un gateway central es un punto crítico: despliégalo con varias réplicas, base de datos gestionada y monitorización propia. Fija versiones y revisa los cambios de cada release, ya que el proyecto evoluciona muy rápido. Ten en cuenta que no todos los parámetros existen en todos los proveedores: prueba las funciones que usas (tool calling, structured output, caché de prompts) con cada modelo del enrutamiento.

Criterios de implementación

Proteger claves y registros; revisar qué parámetros se traducen, rechazan o descartan. Probar errores y evitar fallbacks silenciosos que cambien características esenciales.