LiteLLM: un solo gateway para todos tus modelos

La mayoría de los stacks va acumulando llamadas al modelo de la peor manera: un servicio trae una llave de Anthropic escrita a fuego en el código, otro carga una de OpenAI en su propio archivo de env, un tercero llama directo a un modelo local, y nadie es capaz de responder "¿cuánto gastamos la semana pasada?" sin ponerse a grepear logs en tres lugares distintos. LiteLLM existe precisamente para acabar con ese desorden. Unifica más de 100 proveedores detrás de una interfaz con la forma de OpenAI, la usas como SDK de Python dentro de tu proceso o, mucho más útil, como un proxy independiente al que apunta todo tu stack, para que las llaves, los presupuestos, los fallbacks y el logging vivan en un solo plano de control en lugar de andar dispersos por cada app. Aquí va qué es la herramienta de verdad, en qué casos un gateway justifica honestamente su complejidad frente a un SDK nativo, un quickstart que puedes copiar tal cual, y las concesiones que el README pasa por alto, empezando por cómo la normalización aplana justo las funciones del proveedor de las que quizá dependes.

01 · Qué es en realidad

LiteLLM tiene dos caras, y confundirlas es la primera fuente de líos. El SDK es una librería de Python que llamas dentro de tu proceso, «from litellm import completion», y que traduce una sola llamada de función a la forma que pida el proveedor de destino, y luego traduce la respuesta de vuelta al formato chat-completions de OpenAI. El proxy es un servidor independiente (normalmente un contenedor de Docker) que expone esa misma traducción por HTTP, de modo que cualquier cliente, en cualquier lenguaje, que hable la API de OpenAI puede apuntarle y llegar a todos los proveedores que tiene detrás.

La capa de traducción es la base, pero es el proxy lo que hace que LiteLLM deje de ser una comodidad y pase a ser infraestructura. Apenas tus servicios empiezan a llamar al proxy en vez de a los proveedores directamente, ganas un único lugar donde hacer todo lo que de otra forma tendrías que reimplementar en cada app:

• Llaves virtuales. Emites llaves por equipo o por servicio que el proxy mapea a las credenciales reales del proveedor. Tus apps nunca ven la llave de Anthropic o de OpenAI que está arriba; rotas la real en un solo lugar y revocas una llave virtual filtrada sin tener que tocar nada más.
• Presupuestos y límites de tasa. Le pones un tope de gasto mensual y un techo de requests por minuto a cada llave virtual. Cuando un loop descontrolado se pone a martillar a Claude a las 3 de la mañana, el proxy lo corta en el presupuesto en vez de que te enteres por la factura el mes que viene.
• Fallbacks. Declaras una lista ordenada de modelos; si el principal falla o se pasa de tiempo, el proxy reintenta con el siguiente de forma transparente. El código que llama pide un modelo y se lleva la resiliencia de regalo.
• Logging unificado. Cada request que pasa por el proxy cae en un solo stream de logs (modelo, tokens, latencia, costo, la llave virtual que lo hizo), y esa es la diferencia entre "gastamos de más" y "este servicio gastó de más en este modelo".

02 · Por qué un gateway vale la pena

El argumento a favor de LiteLLM se vuelve fuerte justo cuando dejas de tener un solo modelo y una sola app. Estas son las situaciones donde la pieza extra que tienes que mover sí se paga sola:

Enrutamiento multi-proveedor sin reescribir nada

Con una cuenta de Anthropic y, digamos, un crédito de cómputo de Together AI, la jugada obvia es enrutar las tareas baratas o abiertas a Together y las de razonamiento pesado a Claude. Hecho de forma rústica, eso significa dos SDKs, dos flujos de auth y código condicional en cada punto de llamada. Con el proxy se reduce a un string de modelo y una entrada en el config, la app pide «anthropic/claude-sonnet-4-5» o «together_ai/...» y el gateway se encarga del resto. Cambiar de proveedor más adelante es tocar el config, no un refactor.

Control de costos que no programas a mano

Si alguna vez intentaste imponer un presupuesto de LLM por equipo repartiendo contadores de tokens por todo el código de la aplicación, ya sabes que eso se descompone enseguida. El proxy lo resuelve como política: los presupuestos y límites de tasa se pegan a las llaves, no a los puntos de llamada, así un servicio nuevo hereda las reglas con solo usar una llave acotada, sin que nadie tenga que acordarse de agregar la contabilidad. Es el mismo instinto que acotar un rol de base de datos en vez de confiar en que cada query se porte bien.

Resiliencia como configuración

Las caídas de proveedores y los picos de rate limit no son nada raros. Meter los fallbacks dentro del código de la aplicación significa que cada equipo reinventa la lógica de reintentar-y-degradar, casi siempre mal. Declarar los fallbacks una sola vez en el gateway hace que cada llamada herede el mismo comportamiento probado, y lo afinas en un único lugar cuando la confiabilidad de un proveedor cambia.

Cuándo no vale la pena: una app de un solo proveedor que únicamente le habla a Claude gana muy poco con un proxy y carga con el costo de un servicio más que hay que correr, asegurar y mantener al día. El SDK nativo de Anthropic es más simple, expone cada función directo, y no tiene una capa de traducción que pueda aplanar nada. Sácale provecho a LiteLLM cuando el desorden sea real, varios proveedores, varios consumidores, gasto de verdad que haya que controlar, y no antes, por si acaso.

03 · Quickstart

Empieza con el SDK para sentir cómo funciona la traducción, y pásate al proxy cuando quieras el plano de control. La llamada del SDK de abajo nombra un modelo con prefijo de proveedor y declara un fallback en la misma línea:

from litellm import completion

resp = completion(
    model="anthropic/claude-sonnet-4-5",
    messages=[{"role": "user", "content": "resume este ticket"}],
    fallbacks=["together_ai/meta-llama/Llama-3.1-70B-Instruct"],
)
print(resp.choices[0].message.content)

El proxy es donde esto se vuelve infraestructura. Defines tus modelos, llaves y políticas en un archivo de config y lo corres como contenedor. Una config mínima que mapea dos nombres amigables a proveedores reales y define un fallback se ve así:

model_list:
  - model_name: smart
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: cheap
    litellm_params:
      model: together_ai/meta-llama/Llama-3.1-70B-Instruct
      api_key: os.environ/TOGETHER_API_KEY

litellm_settings:
  fallbacks: [{ "smart": ["cheap"] }]

Lo corres y, a partir de ahí, cualquier cliente compatible con OpenAI llega a todos los proveedores cambiando solo la base URL, usando una llave virtual que el proxy emitió, nunca la credencial real que está arriba:

import OpenAI from "openai"

const client = new OpenAI({
  baseURL: "http://litellm:4000/v1",
  apiKey: process.env.LITELLM_VIRTUAL_KEY, // con alcance, presupuesto y revocable
})

const r = await client.chat.completions.create({
  model: "smart", // resuelve a Claude, cae al modelo barato si hay error
  messages: [{ role: "user", content: "redacta una respuesta" }],
})

Corre el proxy en su propio contenedor dentro de una red interna, nunca expongas el puerto 4000 al internet público, ponle límites de recursos explícitos, y deja las llaves reales de los proveedores solo en el environment del proxy. Así tus apps no guardan nada más que una llave virtual revocable, lo que reduce bastante el radio de impacto si alguna se filtra.

04 · La concesión de la normalización

Este es el que muerde a quien se apura demasiado en estandarizar todo sobre el proxy, así que se lleva su propia sección. Justo lo que vuelve valioso a LiteLLM, reducir a cada proveedor a una sola forma, es exactamente lo que puede dejar fuera, sin que te enteres, el poder específico de cada proveedor. Una interfaz normalizada solo puede exponer la intersección de lo que todos los proveedores hacen limpio; cualquier cosa fuera de esa intersección hay que tratarla como caso especial, y los casos especiales son donde se cuelan las fugas.

Las funciones con más probabilidad de no pasar limpias son justamente las que te importan, precisamente porque ahorran dinero o mejoran la calidad:

• Prompt caching. El prompt caching de Anthropic puede recortar muchísimo el costo de un system prompt largo y estable, pero depende de marcadores de cache-control y de armar el request con la forma exacta. Si eso no sobrevive la traducción, pierdes el descuento sin darte cuenta y tu factura sale más alta de lo que el propio dashboard del gateway te hace pensar que deberías estar pagando.
• Presupuestos de thinking / razonamiento. Los controles de extended-thinking son específicos de cada proveedor. Una API normalizada quizá no pase tu presupuesto de thinking, o lo pase de un modo que el proveedor de arriba termina ignorando, así que crees que configuraste la profundidad de razonamiento y resulta que no.
• Semánticas de tools y los bordes del streaming. Los formatos de tool-call, las llamadas a tools en paralelo y la forma de los eventos de streaming difieren de manera sutil entre proveedores. Los casos comunes mapean bien; los bordes, justo las partes de las que tu loop de agente puede depender, son donde "compatible con OpenAI" pasa a ser "compatible lo suficiente para una demo, pero no para confiar a ciegas".

La postura pragmática: enruta el grueso del tráfico normal por el gateway para tener control y resiliencia, y para el puñado de llamadas que se apoyan fuerte en las funciones de frontera de un proveedor, considera llamar a ese proveedor directo, o, como mínimo, comprueba que la función sobrevive el proxy antes de confiar en ella. El gateway no tiene por qué ser todo o nada.

05 · Concesiones sin maquillaje

LiteLLM es de verdad útil, pero es infraestructura que ahora te toca administrar a ti, y no sale gratis:

• Es un servicio más que correr y asegurar. El proxy es un proceso con tus llaves reales de proveedor en su environment y un puerto que bajo ninguna circunstancia debe dar a internet. Es un lugar pensado y defendible para concentrar los secretos, pero también es un único objetivo de alto valor, así que se gana el aislamiento de red, las llaves virtuales acotadas y la misma disciplina de parcheo que cualquier otro servicio.
• Agrega un salto. Cada llamada pasa ahora por un round-trip de red más y por una cosa más que puede caerse. Las funciones de fallback y resiliencia están, en parte, para compensar esto, pero el proxy en sí se vuelve una dependencia en tu camino crítico; presupuesta su disponibilidad.
• La normalización aplana funciones, como vimos arriba. La comodidad de una sola forma se paga perdiendo acceso a los bordes filosos de cada proveedor. Ten claro qué bordes necesitas antes de comprometerte.
• Controla el gasto; no lo reduce. El proxy te dice cuánto gastas y le pone tope a los descontroles (valor real), pero no abarata ningún modelo ni te elige uno más barato. Enrutar la tarea correcta al modelo correcto sigue siendo tu decisión de diseño; el gateway solo hace que esa decisión sea barata de expresar y fácil de imponer.

En mi propio trabajo, el proxy se gana su lugar en el momento en que un stack tiene más de un proveedor y más de un consumidor, el punto donde las llaves dispersas y el gasto que nadie puede cuadrar dejan de ser una carga hipotética y se vuelven una real. Pongo las llaves reales en el proxy, no le entrego a las apps nada más que llaves virtuales acotadas, declaro los fallbacks una sola vez, y me queda un único stream de logs que responde "quién gastó qué en cuál modelo" sin tener que montar una investigación forense. La disciplina que lo mantiene honesto es el paso de verificación: comprueba que las funciones del proveedor en las que te apoyas sobreviven la traducción, mantén el puerto fuera del internet público, y recuerda que el gateway controla las llamadas que haces. Nunca decide cuáles llamadas debiste haber hecho.