Qué es LiteLLM, cómo funciona y para qué sirve en proyectos de IA

Cuando una empresa empieza a trastear con la inteligencia artificial generativa se topa muy rápido con un muro: hay decenas de modelos, cada uno con su API, sus parámetros y sus rarezas. OpenAI por un lado, Anthropic por otro, Google con lo suyo, proveedores locales, modelos open source… y cada cambio exige reescribir código, gestionar credenciales distintas y lidiar con formatos de respuesta incompatibles. Al final, el tiempo se va en “fontanería” técnica en lugar de en crear productos útiles.

En ese contexto aparece LiteLLM como una especie de “Piedra de Rosetta” para LLM. LiteLLM es una capa de abstracción y un gateway que te permite hablar con más de cien modelos de IA usando, básicamente, el mismo idioma: la API de OpenAI. Da igual si por detrás hay GPT‑4o, Claude 3.5, Gemini, modelos de Vertex AI, Ollama o Hugging Face: tu aplicación envía siempre la misma estructura de petición y recibe siempre el mismo tipo de respuesta, mientras LiteLLM se encarga de traducir, enrutar, registrar costes y aplicar políticas de seguridad.

¿Qué es LiteLLM exactamente?

LiteLLM es un proyecto de código abierto que unifica el acceso a más de 100 modelos de lenguaje y modelos multimodales, envolviendo las APIs de distintos proveedores en una interfaz compatible con OpenAI. A nivel conceptual, hace de intermediario entre tu código y el ecosistema de LLMs, de forma que tú piensas en “modelo lógico” (un alias) y LiteLLM se ocupa de hablar con el modelo real que hay al otro lado.

Desde un punto de vista práctico, LiteLLM tiene dos piezas bien diferenciadas pero complementarias: un SDK ligero en Python y un servidor proxy (LLM Gateway). El SDK está pensado para desarrolladores que quieren integrar rápidamente varios LLM en su código sin montar servicios adicionales. El proxy, en cambio, está orientado a equipos, MLOps y organizaciones que necesitan control centralizado de costes, seguridad, observabilidad y alta disponibilidad.

Gracias a esta arquitectura, puedes escribir el código de integración una vez y reutilizarlo con cualquier proveedor. Si hoy tiras de GPT‑4o y mañana quieres probar un Claude 3.5 o un modelo local en Ollama, lo normal es que cambies únicamente el valor del parámetro model o el alias que hayas definido en la configuración del proxy, sin tocar nada más.

Otro punto clave es que LiteLLM estandariza no solo las llamadas, sino también el formato de respuesta. Las salidas de los modelos se exponen de forma consistente bajo estructuras del tipo response['choices'][0]['message']['content'], lo que simplifica muchísimo el trabajo con frameworks como LangChain o LlamaIndex, o con cualquier backend que espere la estructura típica de OpenAI.

Por qué hace falta una capa como LiteLLM en el ecosistema de LLM

El mundo de los modelos de lenguaje está en plena ebullición: OpenAI, Anthropic, Google, Meta, proveedores cloud como Azure o Bedrock, y plataformas como Hugging Face u Ollama lanzan y actualizan modelos constantemente. Cada uno posee su API, límites de uso, formato de tokens y matices en la autenticación, sin mencionar la gestión de facturación y credenciales.

Esa diversidad es una ventaja porque permite elegir el modelo óptimo para cada caso de uso: texto creativo, razonamiento, código, visión, voz, vídeo, etc.. Pero también genera una complejidad brutal: si tu empresa quiere ser “multi‑LLM” de verdad, terminas replicando lógica de integración, almacenamiento de claves, control de cuotas y métricas en cada servicio. Además, el riesgo de quedar atrapado por un único proveedor (vendor lock‑in) crece si tu código está fuertemente acoplado a una API en concreto.

LiteLLM ataca de frente ese problema creando una capa estándar de acceso a LLMs que puede desplegarse tanto en local como en la nube. Bajo el capó, el proyecto soporta:

• Modelos comerciales como GPT‑4o y familia, Claude 3.5, Gemini, modelos de Vertex AI, AWS Bedrock, Azure OpenAI, etc.
• Modelos open source y locales a través de integraciones con Ollama, Hugging Face y servidores de inferencia como vLLM.
• Modelos multimodales (texto, imagen, en algunos casos vídeo) mediante proveedores especializados como RunwayML o Fal.ai.

Con esto en juego, LiteLLM actúa como “hub” central donde se definen alias de modelo, políticas de uso, rutas de fallback y estrategias de enrutamiento. Para los equipos, eso significa que pueden experimentar con nuevos modelos o cambiar de proveedor sin romper los clientes que ya están en producción.

Componentes principales: SDK de Python y Proxy Server

El SDK de LiteLLM en Python es la vía más directa para empezar. Lo instalas con pip, configuras las claves de API vía variables de entorno y llamas a litellm.completion(...) o funciones equivalentes, igual que harías con el SDK de OpenAI. La diferencia es que aquí puedes pasar como model cualquier identificador soportado, por ejemplo:

model="gpt-4o" para OpenAI o model="anthropic/claude-3-5-sonnet-20240620" para Anthropic, usando la misma función y el mismo formato de mensajes.

Esta modalidad es ideal cuando estás prototipando, haciendo pruebas individuales o montando proyectos pequeños donde no necesitas un gateway dedicado. Cambiar de modelo se reduce casi siempre a modificar una cadena de texto.

El otro gran pilar es el LiteLLM Proxy Server, también llamado LLM Gateway. Aquí ya hablamos de un servicio centralizado (normalmente desplegado en Docker o Kubernetes) por el que pasan todas las peticiones de LLM de tu organización. Desde ahí se gestionan:

• Alias de modelos definidos en config.yaml, que apuntan a proveedores y modelos concretos.
• Claves de API virtuales para equipos o aplicaciones, cada una con su presupuesto, límites de uso y permisos.
• Reglas de enrutamiento avanzado, con fallback entre modelos, balanceo de carga y selección por coste o latencia.
• Logging y observabilidad centralizada, incluyendo latencia, errores, prompts y respuestas (con opciones de anonimización).

En muchas empresas el proxy se convierte en la puerta de entrada obligatoria para todos los servicios que quieran usar LLMs, algo muy similar a un API Gateway tradicional pero especializado en IA generativa.

Cómo empezar con LiteLLM: instalación, Docker y registro de modelos

Si quieres trastear rápido con el proxy de LiteLLM, la forma más limpia es clonar el repositorio oficial y arrancar los contenedores con Docker Compose. El flujo típico sería algo así (simplificando los comandos):

• Clonar el repo de GitHub.
• Crear un fichero .env con dos claves importantes: LITELLM_MASTER_KEY (para acceder al panel y gestionar modelos) y LITELLM_SALT_KEY (para cifrar credenciales de los proveedores).
• Levantar la infraestructura con docker-compose up.

Una vez encendido, accedes normalmente a http://localhost:4000 y entras con el usuario administrador (que puedes cambiar) y la clave maestra definida en el entorno. Desde esa interfaz web es posible registrar nuevos modelos, revisar el uso, crear claves virtuales, etc.

Registrar un modelo nuevo es relativamente directo: en el panel vas a “Modelos >> Añadir modelo” y eliges el proveedor. Después introduces la clave de API correspondiente, defines el alias interno que tendrá ese modelo (por ejemplo, Llama3.2-90B-Ultrafast) y, si quieres, personalizas parámetros como coste por token o tokens máximos de entrada y salida. Esa abstracción de nombres te permite usar alias más amigables que los identificadores largos de los proveedores.

En la práctica, mucha gente aprovecha para exponer modelos de alto rendimiento como los de Groq, que destacan por una latencia de inferencia muy baja gracias a su hardware LPU. En el panel puedes registrar un modelo de Groq con su nombre original (por ejemplo, llama-3.2-90b-text-preview) y, hacia fuera, llamarlo como quieras sin afectar a la lógica de tu aplicación.

Otra vía de despliegue muy habitual es usar directamente la imagen de LiteLLM en contenedores Docker junto a un config.yaml, sin necesidad de clonar todo el repo. En ese YAML defines un model_list con cada alias y los parámetros de conexión (modelo real, API base, clave, etc.), montas el archivo como volumen al contenedor y expones el puerto 4000 a tu red interna.

Cómo hacer peticiones a LiteLLM (SDK propio, SDK de OpenAI y cURL)

Una vez tienes el proxy funcionando, lo más cómodo es tratarlo como si fuera el endpoint de OpenAI. Eso significa que cualquier SDK o cliente compatible con la API de OpenAI se puede apuntar al base_url de tu LiteLLM y aprovechar los alias de modelos que hayas configurado.

Si usas el SDK de LiteLLM en Python, la recomendación es indicar explícitamente proveedor y modelo en el parámetro model, siguiendo el patrón "proveedor/nombre_modelo". Por ejemplo:

model="groq/Llama3.2-90B-Ultrafast"

El resto de la llamada es similar a OpenAI: le pasas una lista de mensajes con su role (user, system, assistant) y su contenido, puedes activar stream=True para recibir el texto a trocitos y vas procesando cada chunk en un bucle. El SDK expone los deltas en una estructura tipo chunk['choices'][0]['delta']['content'].

Si prefieres trabajar con el SDK oficial de OpenAI, la cosa es aún más sencilla: configuras el cliente con base_url="http://tu-litellm" y una API key “virtual” (que puede ser cualquier string si así lo has definido en el proxy), y llamas a client.chat.completions.create como siempre. En este escenario, lo único que cambia es el valor de model, que será el alias que definiste en LiteLLM, sin necesidad de anteponer el proveedor.

Finalmente, siempre te queda la opción de tirar directamente de cURL contra el endpoint /v1/chat/completions de tu gateway. En este caso envías un JSON con el modelo, la lista de mensajes y la bandera de streaming si la necesitas, y LiteLLM responde igual que la API oficial de OpenAI. Este enfoque viene muy bien para pruebas rápidas desde terminal, scripts en otros lenguajes o debugging.

Funciones avanzadas: enrutamiento, fallbacks, costes y observabilidad

LiteLLM no es solo “un wrapper bonito” para no aprender 20 SDKs; está pensado para producción y cubre todo el ciclo de vida de la integración con LLMs. Algunas capacidades destacadas:

Enrutamiento avanzado y tolerancia a fallos. Puedes definir cadenas de modelos de respaldo: si el modelo principal falla, da error de cuota o se queda sin capacidad, LiteLLM reintenta automáticamente en el siguiente de la lista. Además, admite distintas estrategias de balanceo (por coste, latencia o peso) para distribuir carga entre varios despliegues del mismo modelo o modelos equivalentes.

Seguimiento de costes y presupuestos. El Proxy Server ofrece un tracking de gasto en tiempo real por proveedor, por clave virtual, por usuario o por equipo. Esto permite fijar límites mensuales o diarios: si un equipo supera su presupuesto, se pueden bloquear peticiones o degradar a un modelo más barato. Para un responsable de producto o un CTO, es una herramienta muy útil para evitar sorpresas en la factura de IA.

Observabilidad centralizada. LiteLLM registra inputs, outputs, latencias y errores en un solo punto, facilitando tanto el debugging como la monitorización de calidad. Hay integraciones listas con herramientas como Langfuse, Helicone, Datadog u OpenTelemetry, así como sistemas de logging tradicionales. En entornos regulados, puedes configurar cómo y cuánto registrar, e incluso anonimizar partes del prompt.

Soporte multimodal. Aunque el foco inicial eran los modelos de texto, LiteLLM ya ha ido ampliando capacidad para manejar imágenes y vídeo a través de algunos proveedores concretos. Todo ello preservando la filosofía de “misma interfaz, distintos modelos”, lo que facilita experimentar con generación de imágenes, vídeo o pipelines mixtos sin rediseñar la integración.

Gestión de equipos y seguridad. A través del panel del proxy se pueden emitir claves de API virtuales con permisos y presupuestos concretos. Eso significa que los usuarios finales nunca ven las claves reales de OpenAI, Anthropic, etc., sino “tokens” internos que LiteLLM mapea a las credenciales maestras. También puedes limitar qué modelos puede usar cada equipo, configurar cuotas por proyecto o exigir determinados headers para auditoría.

Seguridad, gestión de claves y contexto de ataques en la cadena de suministro

En pleno auge de la IA, la seguridad se ha vuelto un factor crítico, sobre todo en torno a la gestión de claves y dependencias de terceros. El ecosistema Python, en particular, ha sufrido en los últimos años varios ataques a la cadena de suministro en PyPI, con paquetes maliciosos que robaban tokens, exfiltraban datos o modificaban pipelines de CI/CD.

Se han documentado campañas como GlassWorm/ForceMemo, donde se comprometían repositorios de GitHub para robar credenciales, o incidentes como el compromiso de la organización Ultralytics, que afectó a paquetes de visión por ordenador muy usados. También han abundado los ataques de typo‑squatting (por ejemplo, paquetes con nombres casi idénticos a “colorama”) que insertaban puertas traseras en entornos de producción.

En el caso concreto de LiteLLM, a día de hoy no hay evidencia confirmada de que el paquete haya sido comprometido vía ataque de cadena de suministro. Algunas issues en GitHub han señalado problemas de consumo de memoria o picos de CPU, pero no se han reportado vulnerabilidades explotables ni exfiltración de datos ligada al proyecto. Aun así, en un contexto tan movido es lógico que los equipos de seguridad estén con la mosca detrás de la oreja.

Para founders, CTOs y responsables de plataforma, tiene sentido extremar precauciones: verificar procedencia y reputación de los paquetes, usar herramientas de firma y verificación (como Sigstore) y monitorizar comportamientos anómalos en servidores y contenedores. Ante cualquier sospecha, la rotación agresiva de credenciales y la auditoría de accesos en pipelines y despliegues es la jugada adecuada, tanto si la dependencia sospechosa es LiteLLM como cualquier otro paquete clave.

Configuración técnica, requisitos previos y despliegue con Docker Compose

Para que LiteLLM funcione de forma estable en un entorno serio, hay una serie de requisitos básicos que conviene tener bien atados. En primer lugar, necesitas una versión compatible de Python (si vas a usar el SDK o scripts de administración), un gestor de paquetes tipo pip y un editor decente (VS Code, PyCharm o similar) para desarrollar tus integraciones.

Además, debes disponer de cuentas en los proveedores de LLM con los que vayas a trabajar (OpenAI, Anthropic, Google Cloud, AWS, Hugging Face, etc.) y sus correspondientes claves de API. Lo habitual es cargarlas como variables de entorno o mediante un gestor de secretos (Vault, AWS Secrets Manager, GCP Secret Manager, etc.), y dejar que LiteLLM las consuma de forma segura.

En cuanto a configuración, hay dos bloques importantes: las variables de entorno de LiteLLM y el archivo de configuración del proxy. Entre las primeras destacan:

• LITELLM_MASTER_KEY: clave maestra para acceder al panel de administración.
• LITELLM_SALT_KEY: semilla usada para cifrar y descifrar las credenciales de los proveedores.
• Claves de API de proveedores (por ejemplo, OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.).

Después, el fichero config.yaml define qué modelos están expuestos a través del proxy y bajo qué alias. Cada entrada en model_list suele incluir el model_name que verá tu aplicación, el modelo real del proveedor, la referencia a la API key (muchas veces declarada como os.environ/NOMBRE_VARIABLE) y ajustes como la verbosidad o parámetros específicos por modelo.

Docker Compose resulta muy práctico para orquestar la instancia de LiteLLM junto a dependencias como Redis (para caché), bases de datos o herramientas de observabilidad. Cada servicio corre en su propio contenedor, lo que da aislamiento, reproducibilidad y facilita escalar horizontalmente si el tráfico crece. Con un único fichero YAML puedes definir cómo se conectan todos los componentes y levantar el stack completo en entornos de dev, staging y producción prácticamente con el mismo comando.

LiteLLM frente a otras puertas de enlace de LLM

En un mercado que se mueve tan rápido, LiteLLM compite (y a la vez se complementa) con soluciones como OpenRouter, Portkey o Kong AI Gateway. Todas atacan el mismo problema de fondo: centralizar y normalizar el acceso a múltiples modelos, pero con diferencias importantes en enfoque y despliegue.

LiteLLM destaca por ser completamente open source, auto‑alojable y sin recargos por token. Tú te encargas de la infraestructura (sea un servidor modesto o un clúster de Kubernetes) y pagas únicamente las facturas de los proveedores de LLM y del hosting. Esto lo hace especialmente atractivo para empresas que quieren máximo control sobre datos y cumplimiento normativo, o que manejan información sensible que no puede salir de su red.

OpenRouter, en cambio, funciona principalmente como un SaaS agregado que expone cientos de modelos a través de una única API gestionada por ellos. Es muy cómodo porque no tienes que desplegar nada, pero implica ceder parte del control sobre el flujo de datos y pagar un pequeño recargo sobre el coste de los tokens. Puede tener sentido si priorizas conveniencia por encima de control.

Portkey y Kong AI Gateway se posicionan más como plataformas de observabilidad, seguridad y gobernanza avanzadas, con funcionalidades muy potentes para el mundo enterprise. En ese contexto, LiteLLM suele ganar puntos cuando la prioridad es el open source y la flexibilidad, mientras que los otros brillos pueden ser más atractivos cuando ya tienes un stack de API gateways y herramientas de observabilidad muy consolidado.

En resumen, LiteLLM encaja especialmente bien para equipos que quieren un gateway de IA que puedan auditar, modificar y desplegar donde les convenga, sin depender totalmente de un tercero. Y si en algún momento necesitas integrarlo con otros gateways o con frameworks como LangChain o LlamaIndex, el hecho de que emule la API de OpenAI simplifica muchísimo la vida.

Implicaciones prácticas para desarrolladores, producto y MLOps

Adoptar LiteLLM no es solo un cambio técnico, también impacta la forma en que los equipos piensan y trabajan con IA. Para los desarrolladores, lo más evidente es la liberación de tiempo: en lugar de aprender tres o cuatro SDKs distintos, gestionan uno y se centran en la lógica de negocio. Menos “pegamento” y más funcionalidad real.

Para perfiles de producto o liderazgo técnico, el valor está en la visibilidad y el control de costes. Tener un punto único desde el que ver qué modelos se están usando, cuánto cuestan, qué equipos consumen más tokens y qué impacto tiene cambiar un modelo caro por uno más barato, da margen de maniobra a la hora de priorizar iniciativas y ajustar presupuestos.

En el ámbito de MLOps y plataformas de IA, LiteLLM puede convertirse en la pieza central de una estrategia multi‑LLM. Desde ahí se definen políticas de uso, se integran herramientas de observabilidad, se orquestan flujos de fallback y se dan servicios comunes al resto de la organización (“IA como servicio interno”). Eso implica también nuevas responsabilidades: gestionar infraestructura de forma robusta, automatizar despliegues, vigilar rendimiento y latencias, y seguir de cerca la evolución del proyecto en GitHub.

Todo esto sucede en paralelo a una tendencia de fondo: la industria se mueve de pensar en “qué modelo uso” a “qué aplicación construyo y qué combinación de modelos me lo permite mejor”. LiteLLM, al reducir fricción para probar y mezclar modelos, se posiciona bien para ese futuro de aplicaciones impulsadas por varios LLM y SLM especializados que colaboran entre sí.

Visto todo lo anterior, se entiende por qué LiteLLM se ha vuelto una pieza tan mencionada en el ecosistema de IA: reduce de forma muy tangible la complejidad de trabajar con muchos modelos, mejora el control de costes y seguridad, y abre la puerta a que empresas de cualquier tamaño puedan jugar en serio con un enfoque multi‑LLM sin ahogarse en detalles de implementación; si tu reto hoy es domar el caos de APIs de IA que tienes repartido por tu stack, poner una capa de LiteLLM en medio suele ser una de las jugadas más rentables.