Cuando integras a la vez OpenAI, Claude, DeepSeek y Gemini, lo más engorroso no suele ser elegir el modelo, sino que cada SDK tiene un formato de petición, una clave y unos criterios de facturación distintos. LiteLLM es un proyecto de código abierto creado precisamente para resolver esto: unifica varios proveedores bajo una interfaz compatible con OpenAI y ofrece una pasarela que puedes alojar por tu cuenta.

Este artículo explica qué es LiteLLM, la configuración mínima viable, la gestión de rutas y claves, las formas de despliegue y cuándo conviene construirlo uno mismo frente a usar directamente una pasarela gestionada.

Nota: LiteLLM es un proyecto de código abierto de su titular; OpenAI, Anthropic, DeepSeek y otros nombres son marcas de sus respectivos titulares. Este artículo toma como referencia las versiones habituales de octubre de 2026; los parámetros concretos se rigen por la documentación oficial.

1. Qué es exactamente LiteLLM

LiteLLM tiene dos formas:

  • SDK de Python: usar una función completion unificada en el código para llamar a modelos de distintos proveedores.
  • Pasarela proxy: un servicio independiente que expone /v1/chat/completions compatible con OpenAI, al que puede conectarse cualquier cliente que admita una Base URL personalizada.

Resuelve tres cosas: adaptación de protocolos, enrutamiento y contabilidad. No resuelve si el modelo es bueno o malo. En otras palabras, es una tubería, no un modelo.

Sus capacidades principales incluyen:

Capacidad Función
Protocolo unificado Los modelos de varios proveedores usan el formato de OpenAI
Enrutamiento y equilibrio de carga Un mismo nombre de modelo se reparte entre varios despliegues
Conmutación por error Si falla el modelo principal, se pasa al de respaldo
Claves virtuales Claves y presupuestos independientes por equipo o proyecto
Consumo y coste Registra peticiones, tokens y gasto
Callbacks de registro Integración con Langfuse, OpenTelemetry y otros sistemas

2. Mínimo viable: arranque con pip

Crea primero un entorno virtual e instala el paquete con proxy:

python3 -m venv .venv
source .venv/bin/activate
pip install "litellm[proxy]"

Escribe un config.yaml mínimo:

model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: deepseek-chat
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY

litellm_settings:
  drop_params: true

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Arranca:

export ANTHROPIC_API_KEY="sk-ant-tu-clave"
export DEEPSEEK_API_KEY="sk-tu-clave"
export LITELLM_MASTER_KEY="sk-litellm-clave-local"
litellm --config config.yaml --port 4000

model_name es el nombre expuesto al exterior y litellm_params.model es el modelo real del proveedor, con el formato habitual "proveedor/modelo". os.environ/XXX indica que se lee de una variable de entorno; no escribas la clave directamente en el yaml y la subas al repositorio.

Una vez arrancado, apunta el SDK de OpenAI a la pasarela local:

from openai import OpenAI

client = OpenAI(
    api_key="sk-litellm-clave-local",
    base_url="http://127.0.0.1:4000",
)
resp = client.chat.completions.create(
    model="claude-sonnet",
    messages=[{"role": "user", "content": "Responde solo OK"}],
)
print(resp.choices[0].message.content)

3. Enrutamiento de modelos y conmutación por error

En producción rara vez se conecta un solo proveedor. Una configuración habitual es:

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2
  timeout: 600
  fallbacks:
    - claude-sonnet: ["deepseek-chat"]

Significado de algunos parámetros:

  • routing_strategy: cómo elegir entre varios despliegues del mismo modelo; simple-shuffle es una opción habitual para empezar.
  • num_retries: número de reintentos; ten en cuenta que cada reintento genera coste real.
  • timeout: tiempo máximo por petición; configúralo según la ruta más lenta del negocio.
  • fallbacks: modelo al que se cambia cuando el principal no está disponible.

La conmutación por error no es gratuita. El modelo de respaldo puede tener un estilo de salida, una longitud de contexto y una capacidad de llamada a herramientas distintos, y el negocio debe poder aceptarlo. En escenarios con requisitos de formato estrictos, es preferible devolver un error explícito antes que degradar en silencio.

4. Claves virtuales y presupuestos

Compartir una sola master key en el equipo es el punto de partida de un incidente operativo. Lo correcto es emitir una clave virtual por proyecto y limitar los modelos disponibles y el presupuesto:

curl -X POST "http://127.0.0.1:4000/key/generate" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["claude-sonnet"],
    "max_budget": 20,
    "duration": "30d",
    "metadata": {"project": "demo"}
  }'

La clave devuelta se entrega al equipo de negocio; la master key se queda solo en manos de operaciones. La unidad y la moneda del presupuesto se rigen por la documentación de LiteLLM; aquí solo se muestra la estructura de campos, sin implicar ninguna tarifa.

5. Despliegue con Docker y comprobaciones previas

Para una prueba en una sola máquina, puedes ejecutar directamente el contenedor:

docker run -d --name litellm \
  -p 4000:4000 \
  -v "$(pwd)/config.yaml:/app/config.yaml" \
  -e ANTHROPIC_API_KEY \
  -e DEEPSEEK_API_KEY \
  -e LITELLM_MASTER_KEY \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

Antes de salir a producción, revisa al menos estos puntos:

  1. No expongas la pasarela directamente a Internet; pon delante Nginx o Caddy para TLS y control de acceso.
  2. Usa un valor aleatorio fuerte para la master key y no lo escribas en el repositorio de código.
  3. Si necesitas persistir el consumo, conecta PostgreSQL; de lo contrario, parte de las estadísticas se perderá al reiniciar.
  4. Configura la rotación de logs y alertas de disco; los registros de peticiones crecen muy rápido.
  5. Mantén una comprobación de salud: curl http://127.0.0.1:4000/health.
  6. Antes de actualizar, revisa el changelog y fija una etiqueta de versión en la imagen; no uses latest de forma permanente.

Hay otro punto que se pasa por alto con facilidad: la pasarela es un nuevo punto único de fallo. Si cae, caen todos los modelos. Como mínimo, configura supervisión del proceso, reinicio automático y una vía de alerta independiente.

6. Registros y costes: no esperes a que llegue la factura

Un valor oculto de la pasarela es que registra las llamadas. LiteLLM puede registrar el modelo, los tokens, la latencia y el coste de cada petición, y agregarlos por clave, equipo y etiqueta. Para completar este trabajo hacen falta tres pasos:

  1. Configurar una base de datos para que los registros de gasto persistan y no vivan solo en memoria.
  2. Etiquetar las peticiones, por ejemplo con el nombre del proyecto en metadata; de lo contrario, a fin de mes no podrás separar por proyecto.
  3. Conectar un backend de observabilidad para centralizar el trazado y los logs.

Configuración de ejemplo:

litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

general_settings:
  database_url: os.environ/DATABASE_URL

Dos avisos: primero, el servicio de callback también debe ser de alta disponibilidad; si se bloquea, puede ralentizar las peticiones principales. Segundo, los logs pueden contener el texto original de los usuarios, así que define de antemano el plazo de conservación y los permisos de acceso, y no guardes los logs de producción para siempre.

En cuanto al coste, la pasarela solo te permite ver el gasto, no reducirlo automáticamente. Las acciones que de verdad ahorran siguen siendo elegir bien el modelo, comprimir el contexto y controlar el número de reintentos.

7. ¿Construir la pasarela o usar una gestionada?

Dimensión LiteLLM autoalojado Pasarela de IA gestionada
Ruta de los datos Control total propio Pasa por el proveedor
Coste inicial Bajo: instalas y funciona Registro y listo
Operación a largo plazo Actualizaciones, copias y monitorización son tuyas Responsabilidad del proveedor
Facturación y facturas Tú te encargas del proveedor Factura unificada en yuanes
Flexibilidad Alta: puedes modificar código y rutas Limitada por las capacidades de la plataforma
Responsabilidad ante fallos Asumida por ti Según los términos del servicio

Una forma práctica de decidir:

  • Si tienes operaciones, requisitos de cumplimiento y necesitas personalizar a fondo el enrutamiento, elige el autoalojado.
  • Si el equipo es pequeño, solo quieres unificar claves y facturación y no quieres arreglar contenedores de madrugada, elige la gestionada.
  • También puedes empezar con la gestionada para validar el negocio y evaluar el autoalojado cuando el volumen se estabilice.

Los equipos en China deben considerar además la red. La pasarela autoalojada no resuelve por sí sola la accesibilidad del proveedor; si el acceso al proveedor es inestable, la pasarela solo amplifica los fallos. En ese caso es más realista "autoalojar con un proveedor accesible desde el país" o "usar directamente una pasarela gestionada".

Si no necesitas modificar el código y solo quieres una entrada compatible con OpenAI, claves unificadas y facturación en yuanes, una pasarela gestionada suele funcionar el mismo día del registro; LiteLLM encaja mejor como infraestructura que requiere mantenimiento a largo plazo. Ambas opciones pueden coexistir: usar LiteLLM internamente para el enrutamiento y una entrada gestionada de cara al exterior.

8. Preguntas frecuentes

¿LiteLLM es gratuito?

La parte de código abierto puede desplegarse por tu cuenta, pero las llamadas a los modelos del proveedor generan coste igualmente; los precios de las funciones de empresa y del servicio gestionado se rigen por la documentación oficial.

¿En qué se diferencia de One API y New API?

One API y New API están más orientados a la distribución de cuotas entre usuarios, mientras que LiteLLM se centra más en el enrutamiento multimodelo y la unificación del SDK. Ambos pueden ofrecer una entrada compatible con OpenAI; elige según si necesitas distribución con facturación o capacidad de enrutamiento.

¿Admite las llamadas nativas a herramientas de Claude?

El grado de soporte depende de la versión y de la adaptación del proveedor. Para llamadas a herramientas complejas, caché y otras capacidades, conviene validar con peticiones reales y no fiarse solo de la documentación.

¿Autoalojar la pasarela ahorra dinero?

No necesariamente. Ahorras la comisión de la plataforma, pero pagas servidores, operación y tiempo de inactividad. Con volúmenes pequeños, la gestionada suele ser más rentable.

¿Qué configuración mínima hace falta en producción?

TLS, master key, claves virtuales, límites de presupuesto, logs, copias de seguridad de la base de datos y comprobación de salud. No puede faltar ninguno de estos elementos.

Siguiente paso

Si quieres validar primero las llamadas multimodelo sin mantener contenedores, puedes registrarte en la pasarela de IA de ZSQH y completar la primera petición con la entrada compatible con OpenAI; los modelos y precios figuran en precios de modelos. Cuando el volumen y los requisitos de cumplimiento estén claros, decide si necesitas autoalojar LiteLLM.

Lecturas relacionadas: