LiteLLM: un proxy para unificar proveedores de modelos
Actualizado: 2026-05-03
La primera integración con un LLM es sencilla: una clave, un SDK, tres líneas y un prompt. La segunda, seis meses después, ya no. Aparece un segundo proveedor porque Claude razona mejor en tareas largas, o porque conviene tener un modelo self-hosted para datos que no pueden salir del perímetro, o porque los embeddings multilingües de Cohere cuestan una fracción de los de OpenAI. En ese momento el código deja de ser limpio. Cada SDK tiene su propio cliente, formato de mensajes, semántica de streaming, errores y reglas de function calling. El equipo escribe adaptadores, y cada requisito transversal — rate limiting, observabilidad, budget por cliente, fallback si un proveedor falla — se implementa por duplicado o por triplicado.
El patrón que resuelve esto es viejo en infraestructura: un proxy. En lugar de que cada aplicación hable directamente con cada proveedor, todas hablan con un único servicio interno que habla por ellas. LiteLLM[1] es, a principios de 2024, el proyecto open source más serio para hacerlo en el espacio LLM. Ofrece una API compatible con la de OpenAI sobre más de cien proveedores, se despliega como librería o como servidor HTTP, y trae de serie casi todo lo que acabarías escribiendo tú mismo.
Puntos clave
- El proxy LLM no es una idea revolucionaria — es la misma capa de indirección que ya pusimos entre aplicaciones y bases de datos, colas e identidades.
- Las cuatro razones que justifican un proxy son: homogeneidad de API, gobierno (claves virtuales + presupuestos), resiliencia (fallbacks automáticos) y observabilidad centralizada.
- El modo servidor es el relevante para uso serio — el modo librería pierde casi todas las ventajas transversales.
- La traducción entre APIs no siempre es perfecta: las features más específicas de cada proveedor (structured output, tool use) a veces no mapean 1:1.
- Con un único proveedor y sin previsión de cambiar, la complejidad no se paga — una abstracción local basta.
Por qué proxiar
La justificación debe ser concreta, porque todo proxy añade latencia y otra pieza que mantener. Hay cuatro razones, y normalmente aparecen juntas.
La primera es la homogeneidad. Un solo cliente compatible con OpenAI en todas las aplicaciones, apuntando a un endpoint interno, sustituye a media docena de SDKs. Cambiar de modelo pasa a ser un campo de configuración, no un refactor. Migrar una app entera de GPT-4 a Claude 3 Opus se reduce a reapuntar un alias.
La segunda es el gobierno. En cuanto hay más de un equipo usando LLMs, alguien pregunta cuánto gasta cada uno, y quiere limitarlo antes de que el recibo sorprenda a finanzas. Un proxy central emite claves virtuales por equipo, usuario o servicio, con presupuesto y caducidad. Las claves reales de los proveedores solo viven en un sitio.
La tercera es la resiliencia. Los proveedores de LLM fallan, rate-limitan y degradan respuestas con más frecuencia de lo esperado. Un proxy puede declarar fallbacks — si GPT-4 devuelve 429 o 5xx, reintentar en Claude 3 Sonnet; si Anthropic está saturado, caer al Mistral autoalojado — sin que las aplicaciones se enteren. Esto convierte incidentes de proveedor en degradaciones silenciosas, no en caídas de producto.
La cuarta es la observabilidad. Métricas de coste, latencia y tokens por modelo, por tenant y por ruta, emitidas desde un solo punto a Prometheus o Langfuse, evitan instrumentar cada llamada en cada aplicación. También es el lugar natural para cache, redacción de PII, auditoría y compliance.
Librería o servidor
LiteLLM tiene dos modos, y la elección define el resto. En modo librería se importa litellm.completion dentro del código de la aplicación y se disfruta de la API unificada sin desplegar nada nuevo. Razonable para monolitos, prototipos o scripts puntuales, pero pierde casi todas las ventajas transversales.
En modo proxy se despliega un binario aparte — contenedor, pod, systemd unit — y las aplicaciones le hablan como si fuera OpenAI. Esta es la configuración para cualquier uso serio. Su coste es un hop de red interno de 5-20 ms, despreciable frente a los cientos o miles de milisegundos de una llamada real a un LLM.
Qué se declara en el proxy
La configuración típica es un YAML con tres bloques:
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
router_settings:
fallbacks:
- gpt-4: ["claude-3-sonnet"]
routing_strategy: least-busy
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
database_url: os.environ/DATABASE_URL
El primer bloque, model_list, mapea nombres lógicos a configuraciones concretas de proveedor. El segundo, router_settings, declara política de enrutamiento y fallbacks. El tercero, general_settings, fija la clave maestra, apunta a Postgres para persistir presupuestos y uso, y opcionalmente conecta Redis para cache semántica.
El resto de la superficie — budgets por clave, caching con TTL, tagging por entorno, integraciones con Langfuse o Helicone, métricas Prometheus — se describe en el mismo fichero con bloques análogos, sin tocar el código de las aplicaciones.
Lo que no hay que esperar
LiteLLM traduce entre APIs distintas, y la traducción no siempre es perfecta. Las funciones más específicas de cada proveedor — structured output con esquemas complejos, el function calling de OpenAI frente al tool use de Anthropic, los modos de reasoning de ciertos modelos — a veces no mapean 1:1. Vale la pena mirar el changelog antes de confiar un flujo crítico a una traducción no trivial.
La latencia añadida es pequeña pero no nula, y para embeddings a volumen alto puede notarse más de lo esperado. El propio proxy es una pieza más que mantener, con su base de datos, sus actualizaciones y sus métricas. Y si el uso real es un único proveedor sin previsión de cambiar, la complejidad no se paga: una capa de abstracción local en el backend basta.
Patrón que funciona
El despliegue que se estabiliza en equipos con uso serio es siempre parecido: dos réplicas del proxy detrás de un service interno, Postgres compartida para keys y uso, Redis para cache semántica, claves virtuales por equipo o servicio con presupuesto mensual, fallbacks declarados para los modelos críticos, scrape de Prometheus con labels model, tenant y route, y alertas sobre tasa de error por proveedor. Las aplicaciones ven un solo endpoint compatible con OpenAI y envían un header con su clave virtual; todo lo demás ocurre en el proxy.
Este patrón de proxy se combina bien con la evaluación continua de modelos que describe el artículo sobre elegir LLMs abiertos para empresa: el proxy permite cambiar el modelo sin tocar las aplicaciones.
Conclusión
Un proxy de LLMs no es una idea revolucionaria — es la misma capa de indirección que ya pusimos entre aplicaciones y bases de datos, colas e identidades. Tiene sentido por las mismas razones: aísla decisiones que cambian con frecuencia, concentra gobierno y observabilidad, y permite que la aplicación se desentienda de los detalles del proveedor. LiteLLM es la implementación open source más completa, suficientemente estable para producción y lo bastante flexible para absorber los cambios que seguirán llegando en el stack de modelos. Con un único proveedor y sin previsión de un segundo, la pieza es prescindible. A partir del segundo modelo, dejar de escribir adaptadores y delegarlo en un proxy deja de ser una cuestión de estilo y pasa a ser higiene básica.
