Volver al catálogo
LiteLLM: The Universal LLM Gateway (v1.82 - 2026 Edition)
Una completa serie de podcasts sobre LiteLLM, desde el Python SDK y la gestión unificada de excepciones hasta el Proxy Server, el balanceo de carga, las virtual keys, la observabilidad y características empresariales como RBAC y el MCP Gateway.
Reproduciendo ahora
Click play to start
0:00
0:00
1
La piedra Rosetta de los LLMs: El Python SDK
Descubre la identidad central de LiteLLM: una interfaz unificada de Python para más de 100 LLMs. Aprende a integrar LiteLLM en tu código base actual para llamar a Anthropic, Vertex u Ollama sin cambiar tu lógica de parsing compatible con OpenAI.
2
La magia de la traducción de parámetros
Deja de preocuparte por qué proveedor soporta qué hiperparámetro. Aprende cómo el SDK de LiteLLM traduce automáticamente los inputs estándar de OpenAI, como temperature, tools y max_tokens, en todos los modelos upstream.
3
Gestión unificada de excepciones
Escribe tus bloques try-except una sola vez. Descubre cómo LiteLLM captura errores personalizados de AWS, Google y Azure, mapeándolos perfectamente a las excepciones estándar de OpenAI como RateLimitError.
4
El LLM Gateway: Configurando el Proxy Server
Lleva LiteLLM de tu código local a una plataforma centralizada. Aprende a lanzar el Proxy Server de LiteLLM a través de Docker y a configurar tus primeros endpoints usando el archivo config.yaml.
5
Gestión centralizada de secretos
Mantén tus API keys fuera de las configuraciones en texto plano. Aprende a conectar LiteLLM a gestores de secretos empresariales como AWS Secrets Manager o Azure Key Vault para obtener credenciales de forma dinámica.
6
Model Aliases: La actualización en la sombra
Migra a los usuarios a nuevos modelos de forma silenciosa. Descubre cómo usar los Model Aliases en LiteLLM para mapear las peticiones de un modelo a un endpoint completamente diferente sin alterar el código del lado del cliente.
7
Balanceo de carga para alto rendimiento
Evita los rate limits y el tiempo de inactividad enrutando el tráfico de forma inteligente. Explora por qué simple-shuffle es la estrategia recomendada para el balanceo de carga en producción a través de múltiples despliegues.
8
Caídas de API y Fallbacks
No vuelvas a sufrir una caída de IA. Aprende a configurar fallbacks de modelos en LiteLLM para que, si tu proveedor principal falla, el tráfico se redirija automáticamente a un proveedor de respaldo.
9
Context Window Fallbacks
Deja de pagar de más por ventanas de contexto masivas en prompts cortos. Aprende a usar comprobaciones pre-call y Context Window Fallbacks para enrutar documentos demasiado grandes a modelos especializados.
10
Domando las peticiones colgadas con Timeouts
No dejes que las APIs lentas congelen tu aplicación. Descubre cómo configurar timeouts globales y stream timeouts en LiteLLM para abortar peticiones atascadas y activar fallbacks rápidos.
11
Virtual Keys para FinOps
Asegura el uso de tu API con precisión. Aprende a generar virtual keys usando LiteLLM, estableciendo límites estrictos de RPM, TPM y presupuesto para proteger a tu organización de costes de IA descontrolados.
12
Seguimiento de gastos y Custom Tags
Atribuye cada céntimo de gasto en LLMs con precisión. Aprende a pasar etiquetas de metadatos en tus peticiones y a generar informes de gastos exhaustivos usando LiteLLM.
13
Caché para velocidad y ahorro
Deja de pagar por las mismas respuestas del LLM una y otra vez. Aprende a configurar el exact caching con Redis y el semantic caching con Qdrant para reducir drásticamente la latencia y los costes de la API.
14
RBAC: Empoderando a los Team Admins
Distribuye la gestión de la plataforma de forma segura. Entiende el Role-Based Access Control de LiteLLM, delegando poder a los Org Admins y Team Admins sin comprometer la seguridad global.
15
Security Guardrails
Añade una capa de seguridad invisible a tus peticiones de LLM. Aprende a configurar guardrails pre-call y post-call en LiteLLM para bloquear prompt injections y enmascarar PII antes de que llegue a proveedores externos.
16
Gestión dinámica de Callbacks
Dale a los microservicios el poder de la privacidad. Aprende a usar la cabecera x-litellm-disable-callbacks para permitir que las peticiones de API sensibles queden excluidas del logging de observabilidad central.
17
Observabilidad Drop-in
Obtén visibilidad instantánea de tu tráfico de LLMs. Aprende a canalizar la telemetría, las trazas y las excepciones a herramientas como Langfuse y Sentry usando simples callbacks de éxito y fallo.
18
Métricas de Prometheus y Salud del Pod
Tómale el pulso a tu proxy. Descubre cómo exponer el endpoint /metrics a Prometheus, rastrear las in-flight requests y usar custom tags para segmentar los datos en Grafana.
19
Text-to-Speech Universal
Estandariza tu generación de voz. Descubre cómo llamar a modelos Text-to-Speech de Gemini, Vertex y AWS Polly usando exactamente el mismo formato de endpoint de audio compatible con OpenAI.
20
El puente de la Assistants API
Gestiona el estado de la conversación sin esfuerzo entre proveedores. Aprende cómo LiteLLM envuelve modelos no nativos en la interfaz estándar de la Assistants API de OpenAI, permitiéndote usar Threads y Messages en todas partes.
21
El MCP Gateway
Potencia tus modelos con herramientas de forma centralizada. Descubre cómo configurar servidores Model Context Protocol (MCP) por HTTP, SSE o STDIO en LiteLLM, dando a cualquier LLM acceso a capacidades externas.
22
A2A: Rastreando Agentes Autónomos
Pon a los agentes autónomos bajo control. Aprende a invocar agentes complejos de LangGraph o Bedrock a través del proxy usando el protocolo A2A, permitiendo la agrupación de trazas y el seguimiento unificado de gastos.
23
Rotación de Keys con Zero-Downtime
Logra transiciones de seguridad sin tiempo de inactividad. Aprende a configurar rotaciones automáticas programadas de keys y periodos de gracia para virtual keys de nivel empresarial en LiteLLM.
24
La Admin UI y el AI Hub
Haz que tu plataforma de IA sea accesible para todos. Aprende a gestionar la Admin UI, ajustar las credenciales de la interfaz y usar el AI Hub para permitir a los desarrolladores descubrir de forma segura los modelos y agentes permitidos.
Episodios
1
La piedra Rosetta de los LLMs: El Python SDK
4m 11sDescubre la identidad central de LiteLLM: una interfaz unificada de Python para más de 100 LLMs. Aprende a integrar LiteLLM en tu código base actual para llamar a Anthropic, Vertex u Ollama sin cambiar tu lógica de parsing compatible con OpenAI.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway universal de LLMs, episodio 1 de 24. Cambias tu API key de OpenAI por una de Anthropic y, de repente, toda tu aplicación falla. Cada proveedor estructura sus inputs y outputs de forma diferente, lo que te obliga a escribir y mantener una lógica de parsing personalizada para cada nuevo modelo. La piedra Rosetta de los LLMs, el Python SDK de LiteLLM, resuelve esto por completo.
Existe la idea errónea de que LiteLLM compite con LangChain. No es así. LiteLLM no es un agent framework. No orquesta tools, no gestiona memoria ni hace chain de tareas. Es simplemente un drop-in replacement para el cliente de OpenAI.
El Python SDK de LiteLLM traduce más de cien APIs de proveedores diferentes al formato exacto de chat completion de OpenAI. No tienes que aprender los matices específicos de las APIs de Vertex AI, Anthropic o Hugging Face. Escribes tu código una sola vez usando el estándar de OpenAI, y LiteLLM gestiona la capa de traducción en segundo plano.
El núcleo de este SDK es una única interfaz unificada llamada la completion function. Cuando usas esta función, proporcionas un model string. Este string le dice a LiteLLM a qué proveedor contactar. También pasas parámetros estándar de OpenAI como temperature, max tokens y la messages list. LiteLLM toma esos parámetros estándar y los mapea a los campos correctos para el proveedor de destino.
Imagina un escenario donde quieres llamar a Claude 3.5 Sonnet. Usando el SDK estándar de Anthropic, tendrías que estructurar tus prompt blocks según los requisitos específicos de su API de mensajes. Con LiteLLM, solo tienes que llamar a la completion function. Le pasas el nombre del modelo para Claude. Le pasas tu array de messages estándar, usando diccionarios con los roles user y system. Finalmente, proporcionas tu API key de Anthropic, ya sea como parámetro o como variable de entorno.
Aquí está la clave. El response object que devuelve esta función está estructurado exactamente igual que un objeto chat completion de OpenAI.
Cuando quieres extraer el texto generado por Claude, recorres exactamente el mismo path que harías para un modelo GPT. Miras el array de choices. Coges el primer elemento. Accedes al message object. Lees la propiedad content. La lógica de tu aplicación no tiene ni idea de que Anthropic generó el texto. La request de red subyacente fue traducida, enviada al proveedor, y la response fue mapeada de vuelta al schema de OpenAI antes de llegar a tus variables.
Esta abstracción se aplica a toda la interacción. Cubre errores, estadísticas de uso de tokens e incluso respuestas en streaming. Si Anthropic devuelve un error de rate limit, LiteLLM lo mapea a la excepción de rate limit estándar de OpenAI. Tu código de error handling existente lo captura sin modificaciones. Si pides una respuesta en streaming, LiteLLM devuelve chunks que son exactamente iguales a los chunks de streaming de OpenAI.
Puedes iterar por diferentes modelos simplemente cambiando el string value del parámetro model y cambiando la variable de entorno para la API key. El resto de tu código en Python permanece completamente estático. Ya no estás atado a un único ecosistema solo porque escribiste tu código de integración para un proveedor específico.
El verdadero valor de la interfaz de completion unificada es desacoplar la lógica de tu aplicación de las infinitas variaciones en las APIs de los proveedores de modelos, convirtiendo cambios complejos de infraestructura en simples cambios de strings.
¡Gracias por escuchar, feliz programación a todos!
2
La magia de la traducción de parámetros
4m 22sDeja de preocuparte por qué proveedor soporta qué hiperparámetro. Aprende cómo el SDK de LiteLLM traduce automáticamente los inputs estándar de OpenAI, como temperature, tools y max_tokens, en todos los modelos upstream.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway universal de LLM, episodio 2 de 24. ¿Claude espera max tokens, max tokens to sample, o algo completamente distinto? Cada vez que cambias de proveedor de modelos, normalmente tienes que reescribir todo el payload de tu API request para que coincida con sus convenciones de nombres específicas. Parameter Translation Magic es la feature que hace que este problema desaparezca.
Cuando llamas a la función de completion en LiteLLM, siempre escribes tu request usando el formato de parámetros estándar de OpenAI. No necesitas buscar las dictionary keys específicas para Anthropic, Vertex AI o Cohere. La librería intercepta tus inputs con formato OpenAI y los traduce automáticamente a la estructura exacta que requiere el proveedor de destino.
Veamos un escenario específico. Quieres consultar un modelo Gemini de Vertex AI. Necesitas que use function calling, y quieres que las respuestas sean muy deterministas, así que pones la temperatura a cero coma dos. Si estuvieras escribiendo una integración directa, Vertex tiene su propia forma única y muy anidada de definir tools y establecer las configuraciones de generación del modelo. Con LiteLLM, ignoras eso por completo. Construyes tu array de tools usando la sintaxis JSON estándar de OpenAI. Pasas ese array, junto con tu valor de temperatura, directamente a la completion call. LiteLLM coge esos argumentos de OpenAI, los desglosa y construye el payload correcto de la API de Vertex AI antes de enviar la network request.
Este mapping automático es increíblemente eficiente, pero introduce un edge case. ¿Qué pasa si pasas un parámetro de OpenAI que el modelo de destino simplemente no soporta en absoluto? Quizás especificas un presence penalty, pero el proveedor no tiene un concepto equivalente. Por defecto, LiteLLM es estricto. Lanzará una exception y hará fallar la completion call. Esta es una decisión de diseño deliberada. Evita que pierdas silenciosamente configuración que podría ser crítica para el comportamiento de tu aplicación.
Fallar de forma estricta es seguro, pero puede ser frustrante si estás enrutando dinámicamente los user prompts a través de docenas de modelos diferentes en producción. Si quieres que la llamada tenga éxito independientemente de pequeños desajustes en los parámetros, añades un flag llamado drop params puesto a true dentro de tu completion call. Cuando habilitas esto, LiteLLM sigue traduciendo todo lo que puede mapear con éxito. Pero si encuentra un parámetro de OpenAI que el proveedor de destino no reconoce, simplemente elimina ese parámetro no soportado del payload y envía el resto de la request. La llamada tiene éxito, y el parámetro no soportado se ignora de forma segura.
Si prefieres gestionar las capacidades de forma elegante en tu propio código en lugar de depender de silent drops, hay una herramienta de introspección integrada. Puedes llamar a una helper function llamada get supported openai params. Pasas el nombre del modelo como argumento, y devuelve una lista de todos los parámetros estándar de OpenAI que se mapean con éxito a ese modelo específico. Esto te permite comprobar qué soporta realmente un modelo en runtime antes de ejecutar la completion call.
Aquí está la clave. El verdadero valor de la traducción de parámetros es que promueve la especificación de la API de OpenAI de un schema específico del proveedor a un lenguaje de interfaz universal para todo tu application stack.
¡Gracias por escuchar, happy coding a todos!
3
Gestión unificada de excepciones
4m 00sEscribe tus bloques try-except una sola vez. Descubre cómo LiteLLM captura errores personalizados de AWS, Google y Azure, mapeándolos perfectamente a las excepciones estándar de OpenAI como RateLimitError.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Universal LLM Gateway, episodio 3 de 24. Escribir lógica personalizada de error handling para quince APIs de IA diferentes es una excelente manera de perder tu fin de semana. Cada API tiene su propia forma de decirte que estás enviando demasiadas requests o que tu token es inválido. Para evitar que escribas condicionales interminables, LiteLLM utiliza Unified Exception Handling.
En lugar de aprender cómo Anthropic, Cohere o Google muestran sus errores, solo necesitas gestionar un estándar. LiteLLM mapea todas las exceptions subyacentes del proveedor directamente a los tipos de exception estándar de OpenAI. Si una request falla, el gateway intercepta el raw error, lo traduce basándose en el HTTP status code y la respuesta del proveedor, y lanza el error de OpenAI correspondiente.
Imagina un escenario en el que utilizas un endpoint de inferencia de Hugging Face. Durante las horas punta, el endpoint se satura de tráfico. Hugging Face rechazará la request. Si llamaras directamente a su API, necesitarías parsear su error específico HTTP cinco cero tres service unavailable o un mensaje de throttling personalizado. Con el mapping de exceptions unificado, no necesitas un exception handler específico para Hugging Face.
Estructuras tu código usando un bloque try estándar alrededor de tu generation call. Justo debajo, añades un bloque except diseñado para capturar un Rate Limit Error de OpenAI. Dentro de ese bloque, activas tu función estándar de exponential backoff. Tu aplicación se pausa, espera y reintenta la request. Si más adelante cambias Hugging Face por Vertex AI, tu lógica de backoff sigue siendo exactamente la misma. El Rate Limit Error de OpenAI captura el evento de throttling de Vertex con la misma fiabilidad.
Este mapping cubre todo el conjunto estándar de fallos. Puedes capturar un API Timeout Error de OpenAI cuando un servidor remoto se queda colgado. Puedes capturar un Authentication Error cuando una API key rota o caduca. Puedes gestionar un API Connection Error por caídas de red o un Bad Request Error si tu payload está mal formado. El código de tu aplicación trata a todo el ecosistema de IA como si se comunicara únicamente con un único proveedor predecible.
Aquí está la clave. A veces, una abstracción limpia oculta demasiado contexto. Un Bad Request Error genérico de OpenAI te dice que la llamada falló, pero a menudo necesitas saber exactamente por qué. Azure, por ejemplo, aplica filtros estrictos de política de contenido. Si Azure rechaza un prompt porque infringe las directrices de seguridad, mapear eso a un error genérico de OpenAI conlleva el riesgo de perder el safety flag específico que necesitas loguear o mostrar al usuario.
Para solucionar esto, LiteLLM adjunta un atributo llamado provider specific fields al objeto exception. Cuando capturas una exception de OpenAI en tu código, puedes inspeccionar este atributo. Contiene un diccionario con los datos de error originales, sin mapear, directamente del proveedor. Obtienes el flujo unificado de try y except para el routing y los retries, pero conservas los datos granulares para el debugging y la auditoría.
Construyes tus sistemas resilientes, tus retries y tus circuit breakers completamente en torno a las exception classes de OpenAI. Estandarizar tus error boundaries evita que los failure modes específicos del proveedor se filtren en la lógica core de tu aplicación.
¡Gracias por escuchar, happy coding a todos!
4
El LLM Gateway: Configurando el Proxy Server
4m 07sLleva LiteLLM de tu código local a una plataforma centralizada. Aprende a lanzar el Proxy Server de LiteLLM a través de Docker y a configurar tus primeros endpoints usando el archivo config.yaml.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway LLM universal, episodio 4 de 24. ¿Qué pasaría si toda tu empresa pudiera compartir un único endpoint LLM sin exponer nunca las claves API en crudo del proveedor? Pasar de una integración SDK local a una arquitectura centralizada cambia cómo gestionas el acceso. Esto es El Gateway LLM: Configurando el servidor proxy.
Muchos desarrolladores asumen que introducir un proxy middleware personalizado requiere escribir código de cliente personalizado para comunicarse con él. Eso es falso. El proxy de LiteLLM habla el formato nativo de la API de OpenAI. Cualquier librería, aplicación o script que sepa cómo hablar con OpenAI solo necesita actualizar su base URL para que apunte a tu nuevo proxy.
Para iniciar el servidor proxy, necesitas un archivo de configuración. Este es un archivo YAML que define tu lógica de enrutamiento. El núcleo de este archivo es una sección llamada model list. Esta lista mapea los nombres de los modelos que tus aplicaciones internas van a solicitar a los modelos reales del proveedor de backend.
Dentro del model list, cada entrada requiere dos elementos principales. El primero es el model name. Este es el alias que expones a tus usuarios. Podrías llamarlo internal-chat-model. El segundo es un bloque llamado LiteLLM parameters. Aquí es donde configuras el destino real. Esta distinción es importante. El model name es lo que pide tu cliente, pero el bloque LiteLLM parameters define qué procesa realmente la request.
Si estás enrutando a un deploy de Azure OpenAI, tu bloque LiteLLM parameters contendrá el string específico del modelo de Azure, tu base URL de la API de Azure y la versión de la API. También le dices a LiteLLM qué variable de entorno contiene la API key. No debes hardcodear la key en el propio archivo YAML.
Con el archivo de configuración listo, haces el deploy del proxy usando Docker. Usas la imagen oficial de LiteLLM del GitHub Container Registry. Cuando ejecutas el contenedor de Docker, realizas tres pasos específicos. Mapeas tu puerto local cuatro mil al puerto cuatro mil del contenedor. Montas tu archivo de configuración YAML en el contenedor para que el proxy pueda leer tu model list. Finalmente, pasas las credenciales reales de tu proveedor al contenedor como variables de entorno.
Una vez que el contenedor está corriendo, el proxy está activo y escuchando en localhost puerto cuatro mil. Lo pruebas exactamente igual que probarías la API oficial de OpenAI. Haces una request HTTP POST estándar usando una herramienta como cURL. Apuntas a localhost puerto cuatro mil, seguido del path barra chat barra completions. En el body de la request, especificas el alias que definiste antes como el modelo, y proporcionas tu array de mensajes.
El proxy recibe este payload estándar. Lee el alias solicitado, lo busca en tu archivo de configuración y extrae los parámetros de Azure. Luego firma la request con tu API key de Azure, la reenvía a Microsoft y traduce la respuesta de vuelta al formato exacto que espera tu cliente.
Aquí está la clave. El proxy abstrae completamente el proveedor de backend de la capa de aplicación. Si decides cambiar tu deploy de Azure por un proveedor completamente diferente el mes que viene, no tocas ni una sola línea del código de tu aplicación. Solo actualizas los LiteLLM parameters en tu archivo de configuración YAML y reinicias el contenedor.
El valor principal del servidor proxy es que tus aplicaciones de cliente nunca saben, y nunca necesitan saber, qué proveedor cloud está generando realmente los tokens.
¡Gracias por escuchar, happy coding a todos!
5
Gestión centralizada de secretos
4m 05sMantén tus API keys fuera de las configuraciones en texto plano. Aprende a conectar LiteLLM a gestores de secretos empresariales como AWS Secrets Manager o Azure Key Vault para obtener credenciales de forma dinámica.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El gateway universal de LLMs, episodio 5 de 24. Si la API key maestra de tu empresa está en un fichero YAML en plaintext en un servidor de producción, tu equipo de seguridad va a tener un mal día. Las credenciales hardcodeadas son un incidente a punto de ocurrir. La solución es el Centralized Secret Management.
Cuando ejecutas un gateway, necesita acceso a las API keys de tu proveedor upstream para enrutar el tráfico correctamente. El enfoque por defecto suele ser meterlas en una variable de entorno local o directamente en el fichero de configuración principal. El Centralized Secret Management cambia este patrón por completo. Permite que el gateway lea dinámicamente las credenciales desde un vault empresarial externo, como AWS Secrets Manager, Azure Key Vault, Google Secret Manager o HashiCorp Vault.
Para habilitar esta conexión, configuras dos campos específicos dentro del bloque general de settings de tu fichero de configuración. El primer campo es el key management system. Aquí, defines el identificador de tu proveedor de vault. Si usas AWS, lo configurarías como aws_kms. El segundo campo son los key management settings. Esta es una estructura anidada donde proporcionas los parámetros de conexión exactos que requiere tu vault específico, como la región de AWS de destino u otros detalles de autenticación necesarios.
Una vez establecida la conexión con el vault, tienes que decirle a las configuraciones de enrutamiento de tus modelos individuales que saquen sus keys de ese vault. Esto lo haces usando un prefijo de string específico en lugar de la key real.
Aquí está el punto clave. En lugar de escribir un string de la key real, escribes la frase os punto environ barra diagonal, seguida inmediatamente por el nombre exacto de tu secreto tal y como existe en el vault.
Veamos un escenario concreto. Quieres enrutar tráfico a un modelo de Azure, y la API key real está guardada de forma segura en AWS Secrets Manager bajo el nombre azure api key production. En tu fichero de configuración, preparas el bloque de enrutamiento del modelo. Pero para el campo de la API key, pones el valor os punto environ barra diagonal azure api key production.
Cuando el gateway procesa una request para ese modelo, ve el prefijo. Sabe que no debe usar ese string como una key literal. En su lugar, hace una llamada segura a AWS Secrets Manager, pide el valor para ese nombre de secreto exacto, y recupera la key real para autenticar la request. La key en plaintext nunca toca tu disco. Tu fichero de configuración se mantiene totalmente limpio y seguro para hacer commit al version control.
Eso cubre cómo traer credenciales upstream al gateway. Pero la integración con el secret manager va en ambas direcciones. También puede escribir datos. Cuando usas el gateway para generar nuevas proxy keys virtuales para tus equipos de ingeniería internos, puedes configurar el sistema para que guarde automáticamente esas keys recién generadas directamente en tu secret manager. Esto asegura que las credenciales internas que emites se almacenen y gestionen con exactamente los mismos controles de seguridad que las credenciales del proveedor que consumes.
Tus ficheros de configuración definen la estructura de tu infraestructura de enrutamiento, pero nunca deberían guardar sus secretos. El lugar más seguro para guardar una API key en la configuración de tu gateway es en ninguna parte.
¡Gracias por escuchar, feliz programación a todos!
6
Model Aliases: La actualización en la sombra
4m 00sMigra a los usuarios a nuevos modelos de forma silenciosa. Descubre cómo usar los Model Aliases en LiteLLM para mapear las peticiones de un modelo a un endpoint completamente diferente sin alterar el código del lado del cliente.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway Universal de LLMs, episodio 6 de 24. ¿Qué pasaría si pudieras migrar a todos tus usuarios de OpenAI a Anthropic sin pedirles que actualicen ni una sola línea de su código de integración? ¿O cambiar discretamente a un usuario del free tier a una alternativa open source sin romper la lógica de su aplicación existente? El mecanismo que hace posible esta transición silenciosa se llama Model Aliases.
Es fácil confundir los alias con el routing, así que vamos a separarlos. El routing gestiona el load balancing entre múltiples deployments del mismo modelo exacto. Si tienes tres instancias separadas de Azure OpenAI corriendo la misma versión de GPT cuatro, el routing distribuye el tráfico entrante de manera uniforme entre ellas para evitar los rate limits. Los alias hacen algo completamente diferente. Un alias intercepta el nombre del modelo solicitado y lo mapea a un modelo completamente distinto detrás del proxy.
Aplicas este mapeo en el momento en que creas una virtual key para un cliente. Cuando envías tu request al endpoint de generación de keys de LiteLLM, incluyes un objeto aliases en tu payload. Este objeto es simplemente un diccionario que empareja el nombre del modelo que pedirá el cliente con el nombre del modelo que realmente quieres servir.
Veamos un escenario concreto. Tienes un segmento de usuarios del free tier. Originalmente construyeron sus herramientas en torno a GPT cuatro, y ese string exacto está actualmente hardcodeado en sus network requests. Servir GPT cuatro a usuarios que no pagan es caro, así que decides redirigir sus prompts a un endpoint interno de Mistral siete B altamente optimizado.
Para lograr esto, generas una nueva virtual key específicamente para este grupo de usuarios. En el payload de generación, defines un alias que mapea el string GPT cuatro directamente al nombre de tu deployment de Mistral siete B. Les das esta nueva virtual key a los usuarios. Ellos no modifican el código de su aplicación. Continúan enviando requests estándar de chat completion a tu proxy, pidiendo explícitamente GPT cuatro.
Aquí está la clave. El proxy de LiteLLM recibe la request entrante y autentica la virtual key. Lee la configuración vinculada a esa key específica y detecta tu regla de alias. Antes de rutear el payload a un proveedor externo, el proxy reescribe el parámetro del modelo en memoria. Elimina GPT cuatro y lo sustituye por Mistral siete B. La request va a tu deployment interno de Mistral, genera el texto y rutea la respuesta de vuelta al cliente a través del proxy.
La aplicación cliente recibe el formato de respuesta estándar que espera. Sus parsers funcionan perfectamente, y la aplicación sigue funcionando con normalidad. Los desarrolladores que mantienen esa aplicación cliente desconocen por completo que se ha cambiado el modelo de lenguaje subyacente.
Como los alias se asocian directamente a virtual keys individuales en lugar de a la configuración global del servidor, mantienes un control absoluto sobre los diferentes segmentos de usuarios. Una key puede hacer un alias del tráfico hacia un modelo más barato para los usuarios gratuitos, mientras que otra key permite que el tráfico premium pase sin modificaciones. También puedes usar esta misma lógica para gestionar las deprecations de modelos. Cuando un proveedor retira un modelo antiguo, simplemente asignas un alias del nombre antiguo a la nueva versión, salvando a todos tus clientes de tener que hacer push de actualizaciones de código de emergencia. El aspecto más poderoso de un gateway de modelos no es solo gestionar el tráfico de red, sino desacoplar las expectativas del cliente de la realidad física de tu arquitectura backend.
¡Gracias por escuchar, happy coding a todos!
7
Balanceo de carga para alto rendimiento
3m 45sEvita los rate limits y el tiempo de inactividad enrutando el tráfico de forma inteligente. Explora por qué simple-shuffle es la estrategia recomendada para el balanceo de carga en producción a través de múltiples despliegues.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 7 de 24. Por fin conseguiste acceso a producción en Azure OpenAI, lanzaste tu app, e inmediatamente te topaste con un error masivo de rate limit en tu primer gran pico de tráfico. Tienes la cuota, pero tienes un cuello de botella en una sola región. El Load Balancing para alto throughput soluciona esto. Para manejar grandes volúmenes de requests sin alcanzar los límites, necesitas distribuir tu tráfico entre múltiples deployments idénticos. En LiteLLM, esto lo haces configurando un router. Agrupas varios endpoints de backend bajo un único nombre de modelo lógico. Digamos que tienes una app respaldada por cinco deployments de Azure repartidos en cinco regiones geográficas diferentes. Cuando tu app pide un completion, el router decide cuál de esas cinco regiones recibe la request. Controlas esta lógica de decisión configurando una routing strategy en los settings de tu router. El enfoque intuitivo es el usage-based routing, donde el sistema envía la request al deployment que tenga menos tráfico en ese momento. Pero hacer eso requiere llevar el tracking del uso exacto de tokens en tiempo real. Hacer tracking del estado en tiempo real implica hacer una llamada de red a una caché como Redis por cada request, incluso antes de que salga el prompt. Eso le añade un impuesto de latencia permanente a tu app. Para entornos de producción de alto throughput, te interesa evitar ese hop extra. El enfoque recomendado es una estrategia llamada simple-shuffle. Simple-shuffle no hace tracking del estado en vivo. Selecciona aleatoriamente un endpoint de tu pool basándose en pesos predefinidos. Cuando añades tus cinco deployments de Azure a tu archivo de configuración, asignas un límite a cada uno, normalmente Requests Per Minute, o RPM. También puedes usar Tokens Per Minute, o TPM. Si tu región principal tiene un límite de RPM de diez mil, y una región secundaria tiene un límite de RPM de cinco mil, simple-shuffle lee esos números y los trata como pesos. Automáticamente enviará el doble de tráfico a la región principal. Por debajo, el router coge la lista de deployments disponibles para ese modelo, tiene en cuenta sus pesos de RPM, y los mezcla en una lista aleatoria para esa request específica. Prueba con el primer deployment de la lista. Como la aleatorización respeta estrictamente los límites de RPM que configuraste, tu tráfico se distribuye perfectamente entre las cinco regiones a lo largo del tiempo, esquivando los rate limits sin el overhead de la monitorización en tiempo real. Para configurarlo, abres tu archivo de configuración y pones el parámetro de routing strategy en simple-shuffle. Luego, en tu lista de modelos, defines tus cinco endpoints de Azure. Les pones a todos exactamente el mismo nombre de modelo. Finalmente, le añades el parámetro RPM a la definición de cada endpoint con el peso que quieras. Cuando tu app llama al router usando ese nombre de modelo, el router se encarga de las matemáticas y la aleatorización automáticamente. Obtienes los beneficios de una arquitectura distribuida sin necesitar una dependencia de Redis. La mejor manera de manejar una escala masiva suele ser cambiar un tracking perfecto en tiempo real por una aleatorización stateless y estadísticamente predecible. ¡Gracias por escuchar, happy coding a todos!
8
Caídas de API y Fallbacks
4m 11sNo vuelvas a sufrir una caída de IA. Aprende a configurar fallbacks de modelos en LiteLLM para que, si tu proveedor principal falla, el tráfico se redirija automáticamente a un proveedor de respaldo.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway Universal de LLMs, episodio 8 de 24. Cuando tu proveedor principal de modelos de lenguaje sufre una caída, ¿tu aplicación se cae con él, o pivota silenciosamente a un backup? Hoy cubrimos caídas de API y fallbacks, el mecanismo exacto que mantiene tu sistema online cuando fallan los endpoints externos.
Primero, viene bien distinguirlo de un concepto relacionado. Los fallbacks no son load balancing. El load balancing distribuye proactivamente tu tráfico entre múltiples deployments activos para evitar saturar un solo endpoint. Los fallbacks, por otro lado, son rescates estrictamente reactivos. Se quedan inactivos durante el funcionamiento normal y solo se activan después de que haya ocurrido un fallo definitivo.
El objetivo principal es mantener un uptime alto, idealmente alcanzando esa marca del noventa y nueve coma nueve por ciento, incluso cuando tus proveedores upstream no lo hacen. Las APIs externas inevitablemente lanzarán errores 500 de internal server error o excepciones 429 de rate limit. Cuando eso pasa, una configuración de fallback le dice al proxy que intercepte el error al vuelo y enrute la request a un proveedor alternativo, protegiendo completamente el código de tu aplicación de la interrupción.
Esto lo configuras en tu archivo YAML de configuración del proxy usando un array de fallbacks. Imagina un escenario concreto. Tu deployment principal es gpt-4. Quieres asegurarte de que, si gpt-4 se queda offline, el proxy intente automáticamente con claude-3-opus en su lugar.
En tu archivo de configuración, defines el setup de tu modelo gpt-4 como siempre. Dentro de la definición de ese modelo específico, añades una key de fallbacks. El valor de esta key es simplemente un array de strings, donde cada string es el nombre de otro modelo definido en tu configuración. Añades claude-3-opus a este array.
Cuando tu aplicación envía un prompt al proxy pidiendo gpt-4, LiteLLM lo enruta al endpoint principal. Si ese endpoint devuelve un error, la lógica del proxy lo captura. Si tienes retries configurados, podría intentar el endpoint principal un par de veces más. Pero una vez que el principal falla definitivamente, el proxy activa la secuencia de fallback.
Aquí es donde se pone interesante. El proxy coge el prompt y los parámetros originales exactos. Como LiteLLM normaliza el formato de la API, traduce sin problemas la request con formato OpenAI al formato Anthropic que requiere Claude. Inmediatamente envía la request traducida al endpoint de backup. El código de tu aplicación no necesita gestionar ninguna lógica de error, reescribir el prompt, ni administrar las API keys para el segundo proveedor. El proxy gestiona todo el pivote internamente.
No estás limitado a un solo backup. El array de fallbacks acepta una lista de modelos. Si tu gpt-4 principal falla, y luego tu primer fallback claude-3-opus también falla, el proxy pasa al siguiente nombre en el array. Recorre la lista secuencialmente. Si llega al final del array y todos los modelos de backup fallan, solo entonces el proxy devuelve un error a tu aplicación cliente.
Aquí está la clave. Al poner en capas diversos modelos de fallback en tu configuración, aíslas eficazmente el código de tu aplicación de la inestabilidad externa, transformando las caídas graves del proveedor en nada más que picos de latencia invisibles para tus usuarios finales.
¡Gracias por escuchar, happy coding a todos!
9
Context Window Fallbacks
3m 39sDeja de pagar de más por ventanas de contexto masivas en prompts cortos. Aprende a usar comprobaciones pre-call y Context Window Fallbacks para enrutar documentos demasiado grandes a modelos especializados.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El gateway universal de LLMs, episodio 9 de 24. Usar un modelo caro con un contexto de 128k para cada query del usuario es un desperdicio enorme de dinero. Pero si por defecto usas un modelo más barato y pequeño, un usuario que suba un PDF enorme romperá tu aplicación inmediatamente. El mecanismo que resuelve esta tensión se llama Context Window Fallbacks.
Puede que asumas que el fallback routing solo ocurre después de que la API del proveedor devuelva un código de error. Eso es cierto para los fallbacks de fiabilidad generales, pero los límites de contexto funcionan de forma distinta. LiteLLM puede gestionar los tamaños del prompt de forma proactiva usando una configuración llamada enable pre-call checks. Cuando cambias este boolean a true en la configuración de tu router, el proxy detiene la request y calcula el recuento exacto de tokens del prompt antes de que el proveedor llegue a verlo.
Aquí está la clave. Configuras un modelo principal, como uno muy rentable, y en ese mismo bloque de configuración, defines una lista de context window fallbacks que apunta a un modelo mucho más grande. Cuando llega una nueva request, se ejecuta el pre-call check. Si el recuento de tokens calculado entra en el límite del modelo principal, la request continúa normalmente. Si el prompt es demasiado grande, LiteLLM descarta la ruta principal por completo. Y reenvía al instante la request al modelo de fallback más grande.
Esto significa que nunca recibes un error de context length de la API upstream. También significa que evitas la penalización de latencia de esperar a que un proveedor rechace el payload inicial. La aplicación que hace la request no tiene ni idea de que el routing ha cambiado por detrás.
LiteLLM se basa en su model registry interno para conocer los límites de contexto exactos de los diferentes proveedores. Sin embargo, puede que quieras aplicar límites más estrictos. Quizás quieras lanzar el fallback antes para dejar más espacio para los output tokens generados, o quizás estés haciendo routing a un deploy personalizado con una asignación de memoria no estándar. Esto lo gestionas sobrescribiendo el parámetro max input tokens directamente en la configuración de tu modelo. Especificar este valor fuerza al proxy a usar tu límite personalizado al evaluar el pre-call check.
Piensa en el tráfico de una aplicación estándar. Un usuario hace una pregunta de texto sencilla. El proxy cuenta cincuenta tokens, valida que caben y lo enruta a GPT-3.5. Unos minutos después, ese mismo usuario sube un PDF enorme que contiene ochenta mil tokens. El proxy calcula el nuevo tamaño, ve que supera el límite de GPT-3.5 y lo redirige automáticamente a GPT-4-128k. La lógica de tu aplicación se mantiene completamente estática. Solo pagas por el modelo premium cuando el payload realmente lo requiere.
Sacar la validación de tokens del código de tu aplicación y pasarla a la capa del proxy transforma tu estrategia de fallback de una red de seguridad pasiva a un motor activo de optimización de costes.
¡Gracias por escuchar, feliz programación a todos!
10
Domando las peticiones colgadas con Timeouts
4m 09sNo dejes que las APIs lentas congelen tu aplicación. Descubre cómo configurar timeouts globales y stream timeouts en LiteLLM para abortar peticiones atascadas y activar fallbacks rápidos.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El LLM Gateway universal, episodio 10 de 24. No hay nada peor para la experiencia de usuario que un chatbot que muestra un spinner de carga durante cuarenta y cinco segundos simplemente porque una upstream API se ha quedado colgada en silencio. Necesitas una forma fiable de cortar las conexiones muertas al instante para que tu sistema pueda recuperarse. Resolvemos esto controlando las requests colgadas con timeouts.
Cuando enrutas tráfico a modelos de lenguaje externos, los retrasos de red y las caídas del proveedor son inevitables. Si un proveedor deja de responder, el comportamiento por defecto de muchos clientes HTTP es mantener la conexión abierta durante mucho tiempo. LiteLLM intercepta este problema usando dos mecanismos de timeout distintos. El primero es el parámetro de timeout estándar. Esta configuración dicta el tiempo total máximo que LiteLLM esperará a que se complete una request entera, desde el momento en que se envía hasta el último carácter generado.
Si configuras un timeout estándar de treinta segundos, y el modelo tarda treinta y un segundos en escribir una respuesta larga, LiteLLM abortará la request. Esto funciona bien para background tasks o generaciones cortas sin streaming. Sin embargo, aplicar un timeout total a una aplicación de streaming crea un problema estructural. Una respuesta completa podría tardar legítimamente sesenta segundos en llegar por streaming al usuario. Si configuras un timeout total corto para cazar requests colgadas, matarás accidentalmente generaciones largas que funcionan perfectamente.
Aquí es donde la cosa se pone interesante. LiteLLM proporciona un segundo parámetro llamado stream timeout. Esta configuración mide específicamente el tiempo hasta el primer token. Controla exactamente cuánto tiempo esperará el gateway para recibir el chunk inicial de datos del proveedor. Una vez que llega ese primer chunk de datos, el reloj del stream timeout se detiene, y la conexión permanece abierta durante el resto de la generación.
Considera un escenario concreto. Estás enrutando tráfico a un endpoint principal de Azure OpenAI. Dentro de tu archivo de configuración, defines tu bloque de modelo y añades el parámetro de stream timeout, configurándolo en dos segundos. Un usuario envía un prompt complejo. LiteLLM reenvía esta request a Azure. Normalmente, el upstream server procesa el prompt y devuelve el primer chunk en una fracción de segundo. Pero en este caso, el nodo específico de Azure se queda colgado.
El gateway empieza a contar. Pasa un segundo. Pasan dos segundos. El primer chunk no llega. Como definiste un stream timeout de dos segundos, LiteLLM se niega a esperar a que salte el timeout HTTP estándar. Aborta la conexión a la fuerza justo en la marca de los dos segundos.
Abortar la request muerta es solo la mitad del beneficio arquitectónico. Al forzar un fallo rápido, LiteLLM activa inmediatamente tu lógica de fallback. En el momento en que la request de Azure da timeout, el gateway redirige exactamente el mismo prompt del usuario al siguiente nodo disponible y sano en tu lista de deploy. El usuario experimenta un retraso apenas perceptible de dos segundos antes de que el texto empiece a llegar por streaming, evitando por completo una interfaz congelada.
Tienes la flexibilidad de aplicar estas reglas a diferentes niveles. Puedes aplicar un timeout global a todas las requests enrutadas, o puedes ajustarlas con precisión por modelo. Un modelo pesado de razonamiento lógico podría requerir un stream timeout permisivo de cinco o diez segundos, mientras que un modelo de clasificación rápido debería hacer failover después de solo un segundo.
La capacidad de respuesta de tu aplicación no solo depende de lo rápido que tenga éxito tu proveedor principal, sino también de lo agresivamente que fuerces el fallo de una conexión colgada. ¡Gracias por escuchar, happy coding a todos!
11
Virtual Keys para FinOps
4m 18sAsegura el uso de tu API con precisión. Aprende a generar virtual keys usando LiteLLM, estableciendo límites estrictos de RPM, TPM y presupuesto para proteger a tu organización de costes de IA descontrolados.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway universal de LLM, episodio 11 de 24. Un script descontrolado escrito por un desarrollador junior puede generar fácilmente una factura de OpenAI de diez mil dólares de la noche a la mañana. La plataforma del proveedor subyacente sigue aceptando requests tan rápido como el loop puede lanzarlas. Las Virtual Keys para FinOps son la forma de evitar que esto pase.
Hay una confusión muy común entre las master keys y las virtual keys. Nunca debes darle tu master key a un desarrollador. La master key es tu credencial administrativa. Su propósito principal es autenticar tu plataforma para crear virtual keys. Las virtual keys son las credenciales restringidas que realmente entregas a los desarrolladores o aplicaciones para que las usen en su código.
Creas una nueva credencial haciendo una request HTTP POST al endpoint key generate en tu proxy LiteLLM. Autorizas esta request usando tu master key como bearer token. En el body de esta request es donde defines los límites financieros.
Imagina un escenario en el que estás dando acceso a un becario de verano. Quieres asegurarte de que tenga suficiente acceso para montar un prototipo, pero necesitas una garantía absoluta de que no va a fundirse tu presupuesto de infraestructura. Para ello, pasas dos parámetros específicos en tu payload JSON.
Primero, defines el tope financiero configurando el parámetro max budget. Si pones este valor a diez, asignas exactamente diez dólares americanos a esta key específica. Este es un hard limit de por vida. Una vez que el coste total de todos los prompts y completions vinculados a esta key alcance los diez dólares, la key se desactiva automáticamente y rechazará todas las requests posteriores.
Segundo, controlas la velocidad de esas requests configurando el parámetro RPM limit. RPM significa requests per minute. Si estableces el RPM limit a uno, el proxy aplica estrictamente una request por cada ventana de sesenta segundos. Si un loop infinito accidental en el código del becario intenta lanzar cien requests de golpe, el proxy procesa la primera y rechaza inmediatamente las noventa y nueve restantes con un error de rate limit estándar.
Cuando envías este payload al endpoint generate, LiteLLM procesa las reglas y devuelve una respuesta que contiene la virtual key recién generada. Esta key se ve idéntica a una credencial de proveedor estándar, normalmente empezando con un prefijo sk. Le das esta string al becario.
Aquí está la clave del asunto. El desarrollador usa esta virtual key exactamente igual que una key de OpenAI o Anthropic, apuntando su client library estándar a la URL de tu proxy LiteLLM en lugar de a la internet pública. Cuando llega una request, el proxy la intercepta. Consulta su base de datos interna para verificar que la virtual key existe. Luego comprueba si la key ha superado su presupuesto de diez dólares o su límite de velocidad de una request por minuto.
Si la request pasa ambas comprobaciones, el proxy intercambia la virtual key por tu API key corporativa real y reenvía el payload al proveedor. Cuando el proveedor responde, el proxy calcula el coste exacto de los tokens de prompt y completion basándose en los precios publicados para ese modelo específico. Deduce esa fracción de céntimo del presupuesto de diez dólares de la virtual key, registra la transacción y envía la respuesta de vuelta al desarrollador. El desarrollador no se entera en absoluto del intercambio de credenciales subyacente ni de la contabilidad interna.
Al forzar los límites en la capa del proxy, las virtual keys interceptan las requests no autorizadas o descontroladas antes de que lleguen al proveedor de facturación, garantizando matemáticamente que un script comprometido o mal escrito nunca exceda su presupuesto asignado.
¡Gracias por escuchar, feliz programación a todos!
12
Seguimiento de gastos y Custom Tags
3m 54sAtribuye cada céntimo de gasto en LLMs con precisión. Aprende a pasar etiquetas de metadatos en tus peticiones y a generar informes de gastos exhaustivos usando LiteLLM.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway universal para LLMs, episodio 12 de 24. Tu director financiero acaba de entrar y te pregunta exactamente qué nueva feature del producto se está fundiendo el presupuesto mensual de IA. Abres el dashboard de tu proveedor, pero solo ves una enorme factura global para toda la empresa. No tienes respuesta. El Spend Tracking y las Custom Tags en LiteLLM resuelven este punto ciego.
Cuando enrutas requests a través de LiteLLM, el proxy calcula automáticamente el coste de cada completion basándose en el modelo específico y el recuento de tokens. Un importe total en dólares es inútil si no puedes atribuirlo a un origen específico. La forma más sencilla de agrupar este gasto es usando el parámetro user estándar en tu llamada de chat completion. Le pasas un string único que representa a tu cliente final. LiteLLM lo intercepta, calcula el coste y lo registra asociado a ese user ID específico.
El seguimiento por usuario resuelve un problema, pero a menudo un solo usuario lanza múltiples procesos de backend. Imagina que tienes un workload de clasificación de documentos, y el departamento de facturación necesita un informe que agrupe el gasto por background jobs específicos. Un user ID no ayuda aquí. Aquí es donde entran en juego las custom tags. LiteLLM te permite adjuntar un array de strings a cualquier request, y hará el seguimiento del gasto asociado exactamente a esos strings.
Aquí está la clave. Las librerías estándar, como el SDK oficial de OpenAI o LangChain, no reconocen de forma nativa la metadata de LiteLLM. Si intentas pasar un parámetro no reconocido llamado metadata, el SDK lo filtrará o lanzará un error antes de que la request llegue al proxy. Para evitar esto, usas un parámetro llamado extra body. Esta es una vía de escape estándar integrada en los SDKs modernos específicamente para inyectar campos personalizados.
Veamos cómo hacer esto con una request de LangChain. Configuras tu objeto chat model estándar. Cuando llamas al método invoke, pasas tu prompt como de costumbre. Junto al prompt, pasas un parámetro llamado extra body. Lo igualas a un dictionary. Dentro de ese dictionary, creas una key llamada metadata. Dentro de metadata, añades una key llamada tags, que apunta a un array de strings. Podrías pasar un string como job ID cuatro cero dos. LangChain empaqueta este extra body tal cual y lo envía por la red. LiteLLM recibe el payload, extrae tus tags del bloque de metadata, y asocia el coste exacto de esa llamada al LLM al job ID cuatro cero dos.
Eso cubre los inputs. ¿Qué pasa con los outputs? Una vez que tu tráfico está fluyendo con estos tags, necesitas extraer los datos. Lo haces consultando el endpoint del informe de gasto global en tu proxy de LiteLLM. Haces una request HTTP GET estándar a este endpoint. El proxy devuelve un payload JSON detallando exactamente a dónde fue el dinero. Agrupa tu gasto total por API key, por user y, lo que es crucial, por cada custom tag que hayas proporcionado. Puedes entregarle esto directamente a tu departamento de facturación. Podrán ver al instante que el job de clasificación de documentos costó exactamente cuatro dólares con veinte céntimos, independientemente de qué modelo subyacente haya gestionado el enrutamiento real.
Añadir tags a tu tráfico a nivel de proxy significa que la granularidad de tu facturación ya no viene dictada por cómo tu proveedor cloud estructura sus facturas; está completamente definida por el contexto de tu propia aplicación.
¡Gracias por escuchar, happy coding a todos!
13
Caché para velocidad y ahorro
4m 00sDeja de pagar por las mismas respuestas del LLM una y otra vez. Aprende a configurar el exact caching con Redis y el semantic caching con Qdrant para reducir drásticamente la latencia y los costes de la API.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway universal de LLMs, episodio 13 de 24. ¿Por qué pagar a una API externa para que genere la misma explicación básica mil veces? Quemas créditos y obligas a los usuarios a esperar por cálculos que ya se han hecho. Resolver esta ineficiencia es el núcleo del caching para ganar velocidad y ahorrar.
LiteLLM gestiona el caching completamente a nivel de proxy. Cuando llega una request, el proxy comprueba si ya ha visto este prompt exacto antes. Si es así, devuelve la respuesta almacenada inmediatamente. La latencia cae de segundos a milisegundos, y el coste de la API se reduce a cero. Para configurarlo, usas tu archivo config punto yaml. Habilitas el caching en tu bloque de configuración global poniendo cache a true, y especificas tu tipo de cache. Redis es el backend estándar para el caching de coincidencia exacta. Proporcionas tu host, puerto y contraseña de Redis, y el proxy se encarga de almacenar los pares de entrada y salida.
Pero el caching exacto es frágil. Busca un match perfecto de string. Si un usuario pide, escribe un poema sobre LiteLLM, y otro usuario pide, crea un poema de LiteLLM, una cache exacta ve dos requests completamente diferentes. Reenvía la segunda request al modelo de lenguaje pesado, perdiendo tiempo y dinero en una tarea redundante solo porque el fraseo cambió ligeramente.
Aquí es donde entra en juego el caching semántico. En lugar de comparar strings de texto en crudo, el caching semántico compara el significado subyacente de los prompts. LiteLLM soporta Qdrant, una base de datos vectorial, para gestionar esto. Cuando configuras el caching semántico, debes especificar un modelo de embedding junto a tu modelo de generación principal. Cuando llega una request, el proxy pasa primero el prompt al modelo de embedding. Este modelo convierte el texto en un vector, que es una representación matemática del significado del prompt.
Luego, el proxy consulta a Qdrant para ver si ya existe un vector similar en la cache. Como escribe un poema y crea un poema comparten la misma intención semántica, sus vectores se mapean muy cerca en el espacio. Qdrant detecta esta similitud. Si el match es lo bastante cercano, el proxy saca la respuesta cacheada del primer usuario y se la entrega al segundo usuario. Te saltas por completo el pesado paso de generación de texto, pagando solo una fracción de céntimo por la rápida búsqueda del embedding.
Configurar esto requiere unas pocas líneas más en tu config punto yaml. Cambias el tipo de cache a qdrant semantic. Defines parámetros específicos de Qdrant, como la URL del endpoint de Qdrant y tu API key. Y lo más importante, defines un umbral de similitud. Este es un valor decimal entre cero y uno. Un umbral alto, como cero coma noventa y nueve, exige un fraseo casi idéntico. Un umbral más bajo, como cero coma ocho, capta variaciones más amplias, pero aumenta el riesgo de devolver una respuesta desactualizada o ligeramente fuera de tema si dos prompts suenan similares pero tienen intenciones diferentes.
Aquí está la clave. El caching semántico no es solo un mecanismo de almacenamiento, es un filtro activo para la intención del usuario. Ajustar tu umbral de similitud es lo único que se interpone entre una reducción masiva de costes y devolver respuestas irrelevantes a tus usuarios.
¡Gracias por escuchar, feliz programación a todos!
14
RBAC: Empoderando a los Team Admins
3m 25sDistribuye la gestión de la plataforma de forma segura. Entiende el Role-Based Access Control de LiteLLM, delegando poder a los Org Admins y Team Admins sin comprometer la seguridad global.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway universal para LLM, episodio 14 de 24. Eres ingeniero de plataforma y te pasas la mitad del día respondiendo mensajes que piden nuevas API keys o aumentos de presupuesto. Cada onboarding de un desarrollador se convierte en un ticket de IT que bloquea su trabajo y te hace perder el tiempo. La solución es delegar el control sin perder la supervisión, utilizando Role-Based Access Control.
LiteLLM soporta cuatro roles de usuario específicos para gestionar esta delegación. Estos son el proxy admin, el org admin, el team admin y el internal user. El proxy admin está en lo más alto. Si haces deploy de LiteLLM, tú eres el proxy admin. Tú configuras los modelos, preparas la base de datos y estableces las reglas globales. Pero no deberías estar gestionando las peticiones de API keys del día a día. Ahí es donde entra en juego la jerarquía.
Puedes agrupar tu empresa en organizaciones, que representan departamentos enormes, y equipos, que son grupos de trabajo específicos dentro de esos departamentos. El org admin puede gestionar los equipos dentro de su organización específica. Pero el verdadero poder operativo lo tiene el team admin.
Aquí está la clave. Puedes delegar todas las tareas administrativas locales a un jefe de departamento convirtiéndolo en team admin. Como proxy admin, configuras la estructura inicial una sola vez. Creas un equipo, aplicas un límite de presupuesto estricto de quinientos dólares al mes y asignas al lead developer como team admin. Después de eso, te desentiendes por completo.
El team admin ahora tiene la autonomía para gestionar a sus propios ingenieros. Puede hacer login en la UI o usar la API para añadir nuevos usuarios a su equipo. Puede generar nuevas API keys para esos desarrolladores y monitorizar el gasto total de su grupo específico. Y lo que es crucial, cualquier API key creada por el team admin o sus ingenieros queda vinculada automáticamente a ese presupuesto de equipo de quinientos dólares. El team admin tiene control local total, pero no puede gastar ni un solo céntimo más allá del límite que impuso el proxy admin.
Por debajo del team admin está el internal user. Este es el rol que se asigna a los desarrolladores estándar que escriben el código. Un internal user tiene acceso restringido. Puede ver su propio gasto de tokens y, si el team admin se lo permite, generar sus propias API keys personales. Su visión del sistema está estrictamente limitada a sí mismo. No puede ver el presupuesto general del equipo, no puede ver las API keys de sus compañeros, y desde luego no puede modificar la configuración del equipo.
Para configurar esto de forma programática, el proxy admin hace una única request a la API, al endpoint de creación de equipos. Le pasas el nombre del equipo, el parámetro de max budget, y un array de user IDs etiquetados con el rol de team admin. El sistema devuelve un team ID. A partir de ese momento, el responsable del departamento usa ese team ID para enrutar sus propias requests de gestión, saltándose por completo al equipo de platform engineering.
Role-Based Access Control en LiteLLM no va solo de ocultar botones en una UI, va de restringir físicamente el gasto de tokens a nivel de grupo, mientras delegas la gestión de API keys a las personas que realmente lideran los proyectos.
¡Gracias por escuchar, feliz programación a todos!
15
Security Guardrails
4m 14sAñade una capa de seguridad invisible a tus peticiones de LLM. Aprende a configurar guardrails pre-call y post-call en LiteLLM para bloquear prompt injections y enmascarar PII antes de que llegue a proveedores externos.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Universal LLM Gateway, episodio 15 de 24. Confiar en que un modelo de lenguaje se comporte bien por sí solo no es una estrategia de seguridad. Si un usuario pega accidentalmente datos confidenciales de clientes en un prompt, pedirle al modelo que los ignore educadamente ya es demasiado tarde. Necesitas un portero en la puerta, y eso es exactamente lo que proporcionan los Security Guardrails.
Los Security Guardrails en LiteLLM actúan como una capa de seguridad invisible entre los clientes de tu aplicación y los proveedores del modelo de lenguaje. Interceptan el tráfico de la API en dos fases distintas. La primera fase se llama pre call. Esta se ejecuta después de que LiteLLM recibe la request entrante de tu aplicación, pero justo antes de que reenvíe ese payload al proveedor externo. La segunda fase se llama post call, que se activa después de que el modelo genera su respuesta, pero antes de que LiteLLM envíe esa respuesta de vuelta al cliente original.
Defines esta lógica de enrutamiento completamente dentro de tu archivo config punto yaml. En el bloque de proxy settings, defines tus guardrails especificando un endpoint o una integración compatible, y luego le asignas un modo, ya sea pre call o post call.
Veamos un escenario concreto usando un guardrail de pre call. Supongamos que un empleado le pide a un modelo alojado en la nube que resuma un ticket de soporte, pero ese ticket contiene números de la Seguridad Social de Estados Unidos. Definitivamente no quieres que esos números salgan de tu red interna. Puedes configurar Microsoft Presidio como tu guardrail de pre call. Cuando la aplicación envía el prompt, LiteLLM intercepta la request y le entrega el texto a Presidio. Presidio escanea el texto, localiza el número de la Seguridad Social y lo reemplaza con una máscara genérica. LiteLLM luego toma este prompt sanitizado y lo envía a través de internet al proveedor de la nube. El modelo externo genera un resumen basado en el texto enmascarado, y el código de tu aplicación funciona como si nada fuera de lo común hubiera pasado.
Aquí está la clave. No tienes que aplicar estas reglas globalmente a todo tu tráfico. LiteLLM te permite añadir guardrails a nivel de modelo específico. Esto es crucial cuando operas una arquitectura híbrida. Puedes configurar tu enrutamiento para que cualquier prompt enviado a un modelo de nube pública pase por el estricto guardrail de enmascaramiento de PII. Sin embargo, si enrutas ese mismo prompt exacto a un modelo open source que se ejecuta en tu propio hardware on premises, simplemente omites el guardrail del bloque de configuración de ese modelo. El modelo local procesa los datos en crudo y sin enmascarar porque la información nunca cruza el límite de tu red. Evitas una sobrecarga de procesamiento innecesaria y preservas el contexto exacto.
El modo post call opera usando exactamente el mismo flujo, solo que en el viaje de vuelta. Cuando el modelo externo responde, LiteLLM pasa el output a través de tus guardrails de post call. Esto te permite evaluar el texto en busca de lenguaje tóxico, URLs internas alucinadas o menciones no autorizadas de la competencia antes de que el usuario llegue a verlo. Si el guardrail de post call marca el contenido, LiteLLM intercepta el viaje de retorno. Bloquea el texto y devuelve un error de seguridad al cliente en lugar de entregar el output dañino.
Al gestionar esto directamente a nivel de proxy, la arquitectura de tu aplicación permanece completamente inalterada. Tus desarrolladores simplemente envían requests de completion estándar, y el proxy se encarga de aplicar tus reglas de cumplimiento. Las capas de seguridad más fiables son aquellas en las que el código de tu aplicación nunca tiene que pensar. ¡Gracias por escuchar, y happy coding a todos!
16
Gestión dinámica de Callbacks
4m 12sDale a los microservicios el poder de la privacidad. Aprende a usar la cabecera x-litellm-disable-callbacks para permitir que las peticiones de API sensibles queden excluidas del logging de observabilidad central.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway Universal de LLMs, episodio 16 de 24.
Quieres hacer logging de todo el tráfico de LLMs para debugging, pero ¿qué pasa cuando un microservicio envía datos muy sensibles por temas de compliance que no se pueden guardar bajo ningún concepto? Podrías pensar que tienes que desactivar la observabilidad a nivel global, dejando a todo tu sistema a ciegas solo para proteger unas pocas rutas específicas de la API. El Dynamic Callback Management resuelve este problema permitiéndote controlar el logging a nivel de request.
En un setup estándar de LiteLLM, los callbacks se encargan de enviar los payloads de request y response a plataformas de observabilidad externas. Configuras plataformas como Langfuse o Datadog a nivel de proxy y, por defecto, capturan todo lo que pasa por ahí. El error común es pensar que este logging es un sistema de todo o nada. La gente suele pensar que, para manejar datos sensibles, tienen que desplegar un proxy completamente separado con el logging desactivado. El Dynamic Callback Management te quita todo ese trabajo extra.
Imagina un microservicio que maneja historiales médicos. La aplicación necesita procesar los síntomas del paciente a través de un modelo de lenguaje, pero enviar esos datos tan sensibles a un stack de logging de terceros viola el compliance. Para evitar esta fuga de datos, el microservicio simplemente añade una cabecera HTTP específica a su request de salida. Esta cabecera se llama x-litellm-disable-callbacks. Le asignas como valor una lista separada por comas con las plataformas específicas que te quieres saltar.
Para el servicio de historiales médicos, el microservicio pasa la cabecera con el valor langfuse coma datadog. Cuando el proxy de LiteLLM recibe esta request, evalúa la cabecera antes de llamar al modelo de lenguaje. El prompt se envía al provider, y la response se devuelve al cliente como de costumbre. La intervención ocurre durante la fase de telemetría. El proxy lee la cabecera disable y bloquea activamente el envío del payload a los endpoints de observabilidad especificados para esa única transacción. Mientras tanto, todas las demás aplicaciones que hacen peticiones al mismo proxy de forma concurrente siguen haciendo logging de su tráfico sin ninguna interrupción.
Aquí es donde la cosa se pone interesante. Dar a los clientes el poder de desactivar sus propios logs de auditoría introduce un riesgo potencial de seguridad. En entornos muy regulados, los desarrolladores no siempre deberían tener la autoridad para ocultar su tráfico. Si tu infraestructura requiere un audit trail estricto e inalterable para cada prompt, debes forzarlo de forma centralizada.
Esto lo gestionas usando el compliance locking. Dentro del archivo de configuración del proxy, en el bloque de ajustes generales, pones un parámetro llamado allow dynamic callback disabling a false. Este único ajuste establece una política global estricta que sobrescribe cualquier instrucción del lado del cliente.
Si un microservicio intenta pasar la cabecera disable callbacks mientras este bloqueo está activo, el proxy no ignora la cabecera silenciosamente. En su lugar, rechaza la transacción por completo y devuelve un error HTTP 403 Forbidden. Este mecanismo garantiza que el tráfico o bien cumple con la política global de logging obligatoria, o se descarta antes de llegar al modelo de lenguaje.
La verdadera utilidad del Dynamic Callback Management es que traslada la privacidad de los datos de un deploy de infraestructura rígido a un parámetro ágil a nivel de request, al mismo tiempo que da a los ingenieros de plataforma la última palabra sobre el compliance.
¡Gracias por escuchar, happy coding a todos!
17
Observabilidad Drop-in
3m 46sObtén visibilidad instantánea de tu tráfico de LLMs. Aprende a canalizar la telemetría, las trazas y las excepciones a herramientas como Langfuse y Sentry usando simples callbacks de éxito y fallo.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway Universal de LLMs, episodio 17 de 24. Cuando un usuario se queja de que la IA le dio una respuesta extraña hace tres días, ¿cómo recuperas el prompt exacto que la causó? Analizar los logs de la aplicación en busca de payloads JSON multilínea es una pesadilla. Necesitas datos de trace estructurados, pero crear integraciones personalizadas para cada herramienta de monitorización consume horas de ingeniería. Este problema exacto lo resuelve la Drop-in Observability.
En lugar de escribir funciones wrapper personalizadas para cronometrar tus llamadas a la API, contar tokens y capturar timeouts, LiteLLM intercepta el tráfico de forma nativa. Expone dos hooks principales en tus settings: el callback de éxito y el callback de error. Estos callbacks actúan como mecanismos de enrutamiento automático para tu telemetría. Aceptan un array de strings que representan proveedores de observabilidad externos compatibles. Simplemente indicas la herramienta que quieres usar, y LiteLLM traduce sus datos de request internos al formato exacto que espera esa herramienta específica.
Veamos el callback de éxito. Este se activa en el momento en que un modelo de lenguaje devuelve una respuesta válida. Cuando esto sucede, LiteLLM captura automáticamente un snapshot de la transacción. Esto incluye el prompt de entrada exacto enviado al modelo, el output generado, el tiempo que tardó en generarse y el uso preciso de tokens. Para enviar estos datos a una herramienta externa, abres tus settings de LiteLLM y configuras la variable del callback de éxito con una lista que contenga el string "langfuse". Siempre que tus claves de autenticación de Langfuse estén presentes en tus variables de entorno, el sistema se encarga del resto. Aquí está la clave. El proceso de logging ocurre de forma asíncrona en segundo plano. El thread principal de tu aplicación nunca se bloquea mientras espera que el proveedor de observabilidad confirme el trace. Tus usuarios experimentan cero latencia añadida.
Eso cubre el happy path. Para los errores, usas el callback de error. Este se activa cuando una llamada a la API da un timeout, alcanza un rate limit del proveedor, o falla por completo. Sin un tracing adecuado, un error del LLM suele aparecer como un status code opaco. Al configurar tu variable del callback de error con una lista que contenga el string "sentry", mapeas las excepciones del LLM directamente a tu flujo de trabajo de error tracking existente. Cuando una request falla, LiteLLM empaqueta el tipo de excepción, el nombre del modelo y el input intentado, y luego envía ese contexto directamente a Sentry.
Para configurar esto en tu código, no necesitas modificar tus llamadas a la API reales. Solo tocas la configuración global. Asignas tus herramientas elegidas a los arrays de callbacks una sola vez durante el inicio de la aplicación. A partir de ese momento, cada llamada de completion que hagas queda monitorizada. Tu lógica principal permanece completamente desacoplada de tu infraestructura de logging. Si decides cambiar Langfuse por otro proveedor el mes que viene, cambias un string en un array.
El verdadero poder de los drop-in callbacks no es solo evitar el código boilerplate. Es estandarizar la forma de tu telemetría en docenas de proveedores de LLMs diferentes, para que tu plataforma de monitorización vea exactamente un formato consistente, independientemente de qué modelo subyacente haya respondido al prompt.
¡Gracias por escuchar, happy coding a todos!
18
Métricas de Prometheus y Salud del Pod
3m 45sTómale el pulso a tu proxy. Descubre cómo exponer el endpoint /metrics a Prometheus, rastrear las in-flight requests y usar custom tags para segmentar los datos en Grafana.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El gateway universal de LLMs, episodio 18 de 24. Si una request a un LLM tarda diez segundos, ¿es lento el proveedor de IA o el event loop de tu proxy está completamente colapsado? No puedes solucionar un cuello de botella hasta que sepas exactamente dónde se encuentra. Las métricas de Prometheus y el pod health en LiteLLM te dan esa visibilidad exacta.
LiteLLM expone un endpoint de métricas estándar en la ruta barra metrics. Un error común al monitorizar los gateways de IA es tratar todos los retrasos en la respuesta como latencia del proveedor del LLM. Eso es inexacto. Hay dos periodos de espera distintos. Primero, está la latencia de la queue pre-ASGI. Este es el tiempo que una request pasa esperando dentro de tu infraestructura antes de que el proxy siquiera empiece a procesarla. Segundo, está la latencia real del LLM, que es el tiempo que pasas esperando a que OpenAI, Anthropic u otro proveedor devuelva los tokens. El endpoint de métricas separa estos números para que sepas exactamente a quién echarle la culpa de una respuesta lenta.
Para monitorizar tu pod health, dependes de un gauge específico llamado litellm in flight requests. Esta métrica rastrea el número exacto de requests concurrentes que un pod está procesando activamente en cualquier milisegundo. Esta es una medida en tiempo real del queue depth. Cuando hay picos de tráfico, este número sube.
Imagina un escenario concreto. Tu dashboard de monitorización muestra un pico masivo en la duración total de las requests. Los usuarios se quejan de respuestas lentas. Si solo te fijas en el tiempo total, podrías asumir que OpenAI está sufriendo un outage. Pero al comprobar el endpoint de métricas, la latencia del proveedor se mantiene estable en dos segundos. Aquí está la clave. Miras litellm in flight requests y ves que se ha disparado de veinte a doscientos. Esto demuestra que el retraso no es de OpenAI. La queue de tu pod está completamente sobrecargada. Armado con este gauge exacto, puedes configurar tu infraestructura para disparar un evento de auto-scale en el momento en que las in-flight requests crucen un umbral específico, levantando nuevos pods del proxy antes de que el event loop se colapse.
También necesitas saber quién está generando este tráfico. LiteLLM soporta tags personalizados de Prometheus. Cuando una request llega al gateway, puedes pasar metadatos personalizados en el payload de la request, como un ID de proyecto, un departamento o el nombre de una aplicación. LiteLLM extrae estos tags personalizados y los adjunta como labels a las métricas de Prometheus. En lugar de ver simplemente que el gateway procesó diez mil tokens, ves que la aplicación de marketing procesó siete mil tokens y el dashboard de analítica procesó tres mil. Esto le da a DevOps la capacidad de agrupar el uso de tokens, el queue depth y la latencia por tenants específicos.
La conclusión más crítica para el rendimiento del gateway es esta: nunca hagas auto-scale de tu proxy de IA basándote en la latencia total de respuesta, porque desperdiciarás dinero escalando cuando el proveedor externo simplemente esté yendo lento; escala basándote en tu gauge de in-flight requests para reaccionar solo cuando tu propia queue de infraestructura esté realmente llena.
¡Gracias por escuchar, feliz programación a todos!
19
Text-to-Speech Universal
4m 21sEstandariza tu generación de voz. Descubre cómo llamar a modelos Text-to-Speech de Gemini, Vertex y AWS Polly usando exactamente el mismo formato de endpoint de audio compatible con OpenAI.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Universal LLM Gateway, episodio 19 de 24. Quieres añadir generación de voz a tu app, pero escribir código de integración personalizado para el formato de audio de cada proveedor requiere un mantenimiento constante. Cada vez que cambias de un modelo de voz de OpenAI a uno de Google, los campos JSON requeridos, los paths de la API y los return types de audio cambian por completo. El mecanismo que resuelve esto es el Text-to-Speech universal usando el bridge audio-speech de LiteLLM.
En lugar de mantener clientes de API separados para OpenAI, Vertex AI y Gemini, estandarizas tu app en un único formato. LiteLLM expone un endpoint unificado que imita exactamente la route audio-speech estándar de OpenAI. Construyes una request que contiene tu texto, el nombre del modelo elegido y una preferencia de voz, enviándola a LiteLLM como si estuvieras hablando directamente con OpenAI. El gateway luego traduce este payload estandarizado al formato específico que requiere tu proveedor de destino.
Aquí está la clave. Muchos proveedores de IA no ofrecen una API de Text-to-Speech directa y dedicada que haga stream de archivos de audio out of the box. Dependiendo del proveedor, acceder a un modelo de voz de forma nativa suele requerir rutear la request a través de un endpoint genérico de text completion. Es posible que tengas que pasar flags de configuración muy específicos, enviar un system prompt complejo y, a continuación, extraer strings de audio codificados en base64, profundamente anidados dentro de una respuesta JSON. LiteLLM abstrae toda esta capa de traducción. Gestiona la negociación de la API, desempaqueta la estructura de respuesta propietaria y aísla los datos de audio reales.
Considera un escenario concreto. Decides generar audio hablado usando el modelo preview Gemini Flash TTS de Google. En el código de tu app, apuntas tu cliente HTTP estándar a la URL de tu proxy LiteLLM en el path audio-speech. Configuras el parámetro model para que apunte al modelo Gemini Flash TTS. Asignas tu plain text al parámetro input y especificas un identificador de voz válido.
Cuando ejecutas la request, LiteLLM intercepta el payload. Se autentica de forma segura con Google Cloud o Vertex AI dependiendo de tu setup. Reempaqueta tu plain text y la selección de voz en el esquema JSON específico que requiere la API de Google. Cuando el modelo de Google procesa el texto y devuelve el resultado, LiteLLM intercepta la respuesta propietaria. En lugar de obligar a tu app cliente a parsear un payload personalizado de Google Cloud, LiteLLM extrae los bytes de audio raw. Hace de bridge en la capa de transporte sin problemas, haciendo stream inmediatamente de un archivo MP3 estándar de vuelta a tu cliente. Tu app de frontend o backend recibe un audio stream estándar, completamente ajena al hecho de que la generación subyacente fue realizada por Google en lugar de OpenAI.
Esta lógica de bridge significa que escribes la integración de tu cliente de Text-to-Speech exactamente una vez. Si Vertex lanza mañana un nuevo modelo de audio más rápido, solo necesitas cambiar el string del model en tu request. El código de la app que gestiona el stream de MP3 permanece totalmente intacto. Tratar la generación de audio exactamente de la misma manera que tratas la generación de texto te permite estandarizar la lógica de tu app. Al forzar todas las requests de Text-to-Speech a través de una única interfaz unificada, puedes rutear, hacer load-balance y configurar failovers para tu generación de audio a través de proveedores completamente diferentes sin escribir ni una sola línea de código de fallback específico del proveedor. ¡Gracias por escuchar, feliz programación a todos!
20
El puente de la Assistants API
4m 12sGestiona el estado de la conversación sin esfuerzo entre proveedores. Aprende cómo LiteLLM envuelve modelos no nativos en la interfaz estándar de la Assistants API de OpenAI, permitiéndote usar Threads y Messages en todas partes.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 20 de 24. OpenAI gestiona el conversation state de forma excelente, manteniendo el código de tu cliente completamente stateless. Sin embargo, atar tu arquitectura a un único proveedor solo para mantener ese state management es un precio muy alto que pagar. El Assistants API Bridge en LiteLLM resuelve esta tensión.
El bridge es una feature del proxy de LiteLLM que expone los endpoints exactos de la Assistants API de OpenAI. Llamas a rutas estándar como los endpoints de v one assistants y v one threads, pero enrutas la generación de texto real a cualquier modelo que quieras.
Las interfaces estándar de chat completion son stateless. Cada vez que haces una pregunta, tu cliente debe enviar todo el historial de la conversación de vuelta al servidor. Esto consume ancho de banda y complica tu código client-side. La Assistants API soluciona esto manteniendo el historial de la conversación en el servidor dentro de un objeto Thread. Simplemente añades nuevos mensajes al thread y le dices al servidor que ejecute el asistente. El problema es que la mayoría de los demás proveedores, desde setups locales hasta alternativas cloud empresariales, no ofrecen esta interfaz stateful de forma nativa.
El bridge de LiteLLM hace un polyfill de esta funcionalidad que falta. Para que funcione, configuras el proxy de LiteLLM para que se conecte a una base de datos. Esta base de datos actuará como storage layer para tu conversation state. Luego, apuntas tu cliente de OpenAI existente a la URL del proxy de LiteLLM en lugar de a los servidores por defecto de OpenAI.
El flujo lógico comienza creando un asistente. Envías una request al proxy definiendo las instrucciones del asistente y especificando un target model. Este podría ser un deployment de Azure OpenAI o un modelo Astra compatible con OpenAI. El proxy guarda esta configuración en su base de datos.
A continuación, creas un thread. Un thread es simplemente un contenedor vacío almacenado por el proxy. Cuando un usuario dice algo, envías una request para añadir un mensaje a ese thread específico. El proxy guarda el mensaje. Hasta este punto, no se ha contactado en absoluto con el large language model subyacente.
Aquí está la clave. El bridge solo se comunica con tu target model cuando disparas un run. Cuando le dices al proxy que ejecute el asistente en un thread específico, LiteLLM recupera todo el historial de mensajes de su base de datos. Formatea ese historial en un payload de chat completion estándar y stateless. Luego, envía ese payload plano al modelo subyacente que configuraste antes.
El modelo evalúa la conversación y devuelve una respuesta al proxy. LiteLLM coge ese texto, lo empaqueta como un nuevo mensaje del asistente, lo guarda en la base de datos del thread y actualiza el run status a completed. Tu cliente hace polling al proxy, ve el estado completed y hace un fetch del último mensaje exactamente como lo haría normalmente.
El código de tu aplicación permanece completamente intacto. Sigue creyendo que está hablando con un sistema stateful nativo. El proxy gestiona la traducción de forma transparente, recibiendo una request stateful del cliente, ejecutando una llamada stateless al modelo y manteniendo la capa de persistencia entre medias.
Esta separation of concerns significa que la arquitectura de tu cliente puede depender de una interfaz de API moderna y state-managed, mientras que tu infraestructura es totalmente libre de cambiar los modelos subyacentes según los requisitos de coste, privacidad o rendimiento.
¡Gracias por escuchar, happy coding a todos!
21
El MCP Gateway
4m 54sPotencia tus modelos con herramientas de forma centralizada. Descubre cómo configurar servidores Model Context Protocol (MCP) por HTTP, SSE o STDIO en LiteLLM, dando a cualquier LLM acceso a capacidades externas.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway universal de LLM, episodio 21 de 24. Tienes un modelo Llama open-source ejecutándose en local, pero quieres que lance acciones o lea archivos usando exactamente las mismas integraciones de GitHub que usa tu agente de Claude Code. No quieres reescribir la lógica de tu aplicación para soportar un nuevo toolset por cada modelo nuevo. El MCP Gateway resuelve esto.
Primero, separemos MCP de A2A, o routing Agent-to-Agent. Una confusión muy común es tratarlos como si fueran lo mismo. A2A es cuando haces routing de un prompt del usuario hacia un agente externo especializado para generar una respuesta de texto. MCP es totalmente distinto. MCP significa Model Context Protocol, y se trata de proporcionar un set de herramientas estandarizado a un modelo, dejando que ese modelo decida cuándo y cómo invocarlas para completar una tarea.
La feature del MCP Gateway permite que el proxy de LiteLLM actúe como puente entre cualquier modelo de lenguaje y tus servidores MCP. En lugar de escribir código para registrar herramientas en cada aplicación cliente que construyas, las defines de forma centralizada en el proxy. A partir de ese momento, cualquier modelo que llame al proxy puede utilizar esas herramientas.
LiteLLM se conecta a los servidores MCP usando dos métodos principales. El primero es STDIO, o Standard Input and Output. Esto se usa para herramientas locales. Configuras el proxy para ejecutar un comando local específico, como correr un node script o un archivo de Python, directamente en la máquina host. El segundo método es HTTP con Server-Sent Events, o SSE. Esto se usa para conectarse a servidores MCP remotos a través de una red.
Veamos un escenario concreto. Quieres añadir un servidor MCP de Zapier remoto para que tus modelos puedan interactuar con web apps externas. Haces esto completamente dentro del archivo YAML de configuración del proxy. Bajo el bloque de configuración principal, añades una sección de servidores MCP. Le das un nombre a la integración, por ejemplo, zapier-integration. Defines el tipo de transporte como SSE. Luego, proporcionas la URL del endpoint de tu servidor MCP de Zapier. Como esta es una conexión remota, también especificarás los headers de autenticación necesarios, como un bearer token, directamente dentro de esta definición YAML.
Ahora el proxy sabe cómo hablar con Zapier. El siguiente paso es la ejecución. Cuando tu aplicación cliente envía una request estándar de chat completion a LiteLLM, solo necesita incluir un header específico indicando qué herramientas MCP quiere cargar.
Aquí está la clave. La aplicación cliente no necesita saber qué herramientas ofrece realmente Zapier. El proxy intercepta la request del cliente, contacta al servidor MCP de Zapier a través de la conexión SSE, y obtiene dinámicamente la lista actual de herramientas disponibles. Luego, el proxy inyecta esas definiciones de herramientas en el payload y reenvía todo el paquete al modelo de lenguaje.
Si el modelo de lenguaje decide invocar una herramienta de Zapier, envía un tool call de vuelta al proxy. El proxy lo captura, ejecuta la acción contra el servidor MCP de Zapier, obtiene el resultado y se lo devuelve al modelo. Tu aplicación cliente está completamente aislada de esta negociación de ida y vuelta. Simplemente recibe tool responses estándar compatibles con OpenAI.
El verdadero poder del MCP Gateway es desacoplar la implementación de la herramienta de la elección del modelo, lo que significa que una integración construida para un ecosistema funciona al instante en docenas de modelos diferentes sin tener que escribir código adapter personalizado.
¡Gracias por escuchar, happy coding a todos!
22
A2A: Rastreando Agentes Autónomos
3m 56sPon a los agentes autónomos bajo control. Aprende a invocar agentes complejos de LangGraph o Bedrock a través del proxy usando el protocolo A2A, permitiendo la agrupación de trazas y el seguimiento unificado de gastos.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El Gateway Universal de LLMs, episodio 22 de 24.
Cuando tu agente autónomo entra en un loop de razonamiento de cincuenta pasos, ¿cómo rastreas la factura hasta la request original? Si el agente hace docenas de llamadas aisladas a diferentes modelos de lenguaje, tus logs de facturación se convierten en un caos ilegible de requests desconectadas. La solución a esto es el Agent Gateway de LiteLLM, también conocido como protocolo A2A.
Antes de explorar cómo funciona, deberíamos aclarar una confusión común. Los oyentes suelen confundir esto con el Model Context Protocol, o MCP. MCP se usa para proporcionar tools externas a un modelo de lenguaje. A2A hace exactamente lo contrario. Trata a un agente autónomo externo como si fuera un modelo de lenguaje estándar, permitiéndote invocarlo y rastrearlo a través de un gateway centralizado.
Para configurar esto, defines tu agente en el archivo de configuración de LiteLLM exactamente igual que definirías un modelo de lenguaje estándar. Le das un nombre al modelo, configuras la base URL apuntando al endpoint de la API de tu agente, y especificas el provider como un endpoint personalizado de OpenAI. Ahora, LiteLLM sabe cómo enrutar las requests entrantes de los clientes directamente a tu agente.
Cuando un cliente envía una request pidiendo este agente, LiteLLM actúa como un pass-through para los headers de contexto. Coge los metadatos asociados a la request, como identificadores de usuario, tags de enrutamiento de equipo y límites de presupuesto, y los empaqueta en headers HTTP específicos. El más importante de ellos es el header X-LiteLLM-Trace-Id. LiteLLM reenvía estos headers junto con el prompt a tu agente.
Aquí está la clave. Tu agente recibe esta request, inicia su loop autónomo y empieza a hacer sus propias llamadas internas para procesar la tarea. Si el agente hace estas llamadas directamente a un provider público, pierdes el contexto de seguimiento. En su lugar, el agente debe enrutar sus llamadas internas de vuelta a través de LiteLLM. Cuando hace esto, debe incluir el trace ID que recibió en la request original.
Piensa en un escenario concreto. Estás invocando un agente local de LangGraph. Un cliente envía un prompt a través de LiteLLM para iniciar el proceso. LiteLLM asigna un trace ID único y reenvía el payload al endpoint de LangGraph. Tu aplicación LangGraph lee los headers HTTP entrantes y extrae el X-LiteLLM-Trace-Id. Cuando LangGraph necesita evaluar un paso o resumir datos, usa su cliente interno para enviar una llamada de completion de vuelta a LiteLLM. Y lo que es crucial, adjunta ese mismo header de trace ID a su request saliente.
Como cada llamada interna lleva el mismo identificador de trace, LiteLLM las agrupa automáticamente. Cuando miras tu plataforma de observabilidad o tus logs de presupuesto, no ves cincuenta requests aleatorias de fuentes desconocidas. Ves un único trace unificado. Sabes exactamente qué usuario activó el agente, cuánto costó todo el loop de razonamiento y qué pasos autónomos específicos consumieron la mayor parte del presupuesto.
Tratar a los agentes como endpoints de modelo estándar transforma los workflows complejos de agentes de múltiples pasos en unidades de cómputo rastreables y facturables.
¡Gracias por escuchar, feliz programación a todos!
23
Rotación de Keys con Zero-Downtime
4m 00sLogra transiciones de seguridad sin tiempo de inactividad. Aprende a configurar rotaciones automáticas programadas de keys y periodos de gracia para virtual keys de nivel empresarial en LiteLLM.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: The Universal LLM Gateway, episodio 23 de 24. Rotar las API keys de producción suele implicar downtime programado, coordinación frenética y cruzar los dedos para que ningún sistema backend se quede tirado con una credencial caducada. Un hard cutover es una medida de seguridad estricta, pero también es una forma infalible de romper las requests en curso. La solución a esta tensión son las Zero-Downtime Key Rotations.
En un setup de proxy empresarial, mantener virtual keys estáticas para siempre es un riesgo de seguridad inaceptable. LiteLLM maneja esto permitiéndote programar rotaciones automáticas de keys. En lugar de generar nuevas credenciales a mano y coordinar el momento exacto para cambiarlas, dejas que el proxy se encargue de su ciclo de vida. Pero simplemente automatizar la creación de una nueva key no resuelve el problema de fiabilidad subyacente. Si el gateway rechaza inmediatamente la key antigua en el segundo en que se crea una nueva, cualquier servicio que aún no haya sincronizado la nueva credencial fallará al instante.
Para solucionar esto, LiteLLM utiliza un grace period. Cuando creas o actualizas una virtual key, configuras dos parámetros específicos. Primero, estableces el auto rotate interval, que define exactamente con qué frecuencia debe nacer una nueva key. Segundo, defines el grace period, que le dice al sistema cuánto tiempo debe seguir siendo válida la key antigua después de que ocurra la rotación.
Imagina una arquitectura de microservicios estándar donde tu política de seguridad exige rotar las access keys del LLM cada treinta días. Haces una request al endpoint de generación de keys de LiteLLM. En esa request, estableces el parámetro auto rotate en 30 días. En la misma request, estableces el parámetro grace period en 24 horas. El proxy guarda esta política y pone en marcha el reloj.
Al llegar a la marca de los treinta días, se dispara la rotación. LiteLLM genera automáticamente una virtual key completamente nueva. Aquí viene lo importante. Durante las siguientes 24 horas, tienes dos keys totalmente válidas apuntando exactamente a la misma configuración, presupuesto y lógica de tracking.
Durante esta ventana de solapamiento, tu secrets manager obtiene la nueva key y la inyecta poco a poco en tu entorno de producción. A medida que los containers se reinician o los config maps se actualizan, los servicios cambian de forma independiente a la nueva credencial. Si un background worker específico sigue usando la key antigua doce horas dentro del grace period, LiteLLM acepta la request sin quejarse. El gateway enruta el tráfico al Large Language Model y registra la transacción con normalidad.
Una vez que transcurre el grace period exacto de 24 horas, LiteLLM invalida automáticamente la key original. Cualquier sistema restante que siga intentando usar la credencial antigua recibirá un error de autenticación. La migración está completa.
Has desacoplado por completo la creación del nuevo secreto de la destrucción del antiguo. Separar estos dos eventos transforma la rotación de keys de un pánico de infraestructura frágil y altamente coordinado, en una rutina en background silenciosa y fiable.
¡Gracias por escuchar, happy coding a todos!
24
La Admin UI y el AI Hub
4m 41sHaz que tu plataforma de IA sea accesible para todos. Aprende a gestionar la Admin UI, ajustar las credenciales de la interfaz y usar el AI Hub para permitir a los desarrolladores descubrir de forma segura los modelos y agentes permitidos.
Hola, soy Alex de DEV STORIES DOT EU. LiteLLM: El gateway LLM universal, episodio 24 de 24. Tu equipo de plataforma ha montado un gateway LLM muy seguro y con un enrutamiento perfecto. Pero cuando los desarrolladores internos realmente necesitan desarrollar algo, ¿cómo saben qué modelos y agentes tienen permiso para usar? Sin un mecanismo de descubrimiento, tu gateway es una caja negra invisible. Esa visibilidad la proporcionan la Admin UI y el AI Hub.
La Admin UI es un dashboard visual integrado directamente en el proxy de LiteLLM. Operar un gateway LLM únicamente mediante archivos de configuración y consultas a la base de datos escala mal cuando varios equipos empiezan a solicitar acceso. La Admin UI ofrece a los operadores de la plataforma un lugar centralizado para gestionar el proxy. A través de esta interfaz, puedes generar nuevas API keys, hacer un seguimiento del gasto de tokens entre diferentes equipos, monitorizar los logs de requests en tiempo real y configurar las reglas de enrutamiento de modelos.
Cuando inicias el proxy de LiteLLM por primera vez, este dashboard está activado por defecto y protegido con credenciales de login por defecto. Para testing local, esto es práctico. Para producción, es una vulnerabilidad. Debes cambiar estas credenciales por defecto inmediatamente. Esto lo haces configurando variables de entorno específicas para el usuario y la contraseña de administrador antes de arrancar el contenedor.
Aquí está la clave. Es posible que no quieras exponer ningún dashboard gráfico en tu gateway de producción. Muchos equipos de plataforma aprovisionan la infraestructura estrictamente mediante scripts automatizados y no quieren un control plane interactivo accesible a través de la red. Si eso encaja con tu modelo de seguridad, puedes desactivar el dashboard por completo. Al configurar una variable de entorno llamada disable admin ui en true, eliminas la interfaz por completo. El proxy seguirá enrutando el tráfico y aplicando las reglas, pero el servidor web no servirá las pantallas de administración.
Eso cubre a los operadores de la plataforma, pero los ingenieros que consumen la API necesitan una perspectiva diferente. Ahí es donde entra en juego el AI Hub. Mientras que la Admin UI es para control, el AI Hub es para descubrimiento. Actúa como un portal interno de desarrolladores para tu organización.
En lugar de escribir al equipo de plataforma para preguntar qué modelos están aprobados actualmente o dónde está la documentación de un agente interno, los desarrolladores visitan el AI Hub. Se autentican, normalmente a través del proveedor de single sign-on de tu organización, y se les presenta un catálogo. Pueden ver exactamente a qué modelos están autorizados a llamar, revisar los rate limits aplicados a esos modelos y descubrir agentes preconfigurados creados por otros equipos.
Y lo que es más importante, el AI Hub permite a los desarrolladores hacer self-service. Pueden generar sus propias API keys vinculadas a los presupuestos específicos de su equipo sin esperar a que un ingeniero de plataforma aprovisione una manualmente. Esto cambia fundamentalmente la forma en que tu organización interactúa con la IA generativa. Cierra la brecha entre los ingenieros de infraestructura que aseguran el gateway y los ingenieros de producto que construyen las aplicaciones.
El gateway solo es útil si es accesible, y el AI Hub convierte un proxy restringido en una plataforma de self-service que permite a tus equipos de ingeniería avanzar rápido sin arruinar tu presupuesto. Con esto concluimos nuestra serie sobre LiteLLM. Te animo a explorar la documentación oficial, probar estas configuraciones de forma práctica y visitar DEV STORIES DOT EU para sugerir temas para futuras series. ¡Gracias por escuchar, happy coding a todos!