LiteLLM es un proxy de código abierto compatible con OpenAI que ejecutas tú mismo: se sitúa delante de tus propias cuentas de proveedor y ofrece a tu código un único endpoint y un formato único de clave para todas ellas (su documentación). Los equipos buscan alternativas por dos motivos no relacionados. Operativo: un proxy autogestionado es otro servicio que actualizar, escalar y vigilar. Cadena de suministro: el 24 de marzo de 2026, un atacante publicó en PyPI dos versiones de LiteLLM con puertas traseras, y el incidente puso delante de muchos equipos la superficie de ataque de «un paquete dentro de tu compilación», un riesgo que no habían valorado. Esta comparativa relaciona cada motivación con la herramienta que realmente la resuelve, incluido el caso de seguir con LiteLLM, que es más sólido de lo que sugieren las siete listas comerciales de esta búsqueda.
Sesgo declarado desde el principio: Kunavo es nuestro producto y aparece primero. Todas las demás herramientas reciben una recomendación genuina; los detalles que hemos verificado están disponibles en las páginas comparativas; y los dos productos que no hemos evaluado se describen únicamente al nivel que indican sus propios sitios.
La lista breve
| Alternativa | Tipo | Elígelo por |
|---|---|---|
| Kunavo | Puerta de enlace de inferencia alojada (acceso revendado) | Sin proxy ni cuentas de proveedores; por debajo del precio oficial en la mayoría de los modelos |
| OpenRouter | Puerta de enlace de inferencia alojada (acceso revendado) | La lista de modelos más amplia con una sola cuenta |
| Portkey | Plano de control alojado (BYO keys) | Conserva tus claves de proveedor y deja de ejecutar el proxy |
| Helicone | Capa de observabilidad (tus propias claves) | Los registros y el seguimiento de costes eran el único motivo para ejecutarlo |
| TrueFoundry | Puerta de enlace de IA empresarial | Compras quiere un SLA y un proveedor al que llamar |
| MLflow AI Gateway | Autohospedado y de código abierto | La misma estructura que LiteLLM, pero otro proyecto |
| Cloudflare AI Gateway | Proxy perimetral (tus propias claves) | Caché, límites de velocidad y analítica sobre tus propias claves |
La distinción que resuelve la mayor parte
LiteLLM hace dos trabajos a la vez y la mayoría de sus sustitutos solo hace uno. Es un proxy (un endpoint para muchos proveedores) y también una herramienta BYO-key (las cuentas de los proveedores siguen siendo tuyas). Una puerta de enlace de inferencia alojada —Kunavo u OpenRouter— sustituye ambas funciones: no hay ningún proxy que ejecutar ni ninguna cuenta de proveedor que gestionar, porque la puerta de enlace conserva las credenciales ascendentes y te factura por el uso. Un plano de control alojado —Portkey o TrueFoundry— sustituye solo la primera: dejas de operar el proxy, pero conservas las cuentas. Saber qué mitad estás sustituyendo resuelve la mayor parte de esta lista. El patrón se explica con más detalle en la guía de puertas de enlace LLM.
Lo que realmente hizo que la gente buscara
El resultado principal de esta búsqueda no es un artículo en formato de lista: es un hilo de Reddit sobre el ataque a la cadena de suministro. Esto es lo que ocurrió, según la propia actualización de seguridad de LiteLLM: el 24 de marzo de 2026, un atacante publicó litellm==1.82.7 y litellm==1.82.8 en PyPI con código malicioso inyectado en los archivos wheel distribuidos. Estuvieron disponibles desde las 10:39 UTC durante aproximadamente 40 minutos, antes de que PyPI los pusiera en cuarentena. La intrusión se rastreó hasta la dependencia Trivy del flujo de trabajo de análisis de seguridad CI/CD de LiteLLM; el atacante eludió el flujo de publicación oficial y subió los paquetes directamente a PyPI. Según SecurityWeek, más de 2.500 organizaciones se vieron afectadas.
La remediación de LiteLLM está documentada y es sustancial: paquetes comprometidos retirados, credenciales de los mantenedores rotadas, Mandiant contratado para realizar el análisis forense y v1.83.0 publicada mediante un flujo CI/CD reconstruido, con entornos de compilación aislados, controles de publicación más estrictos e imágenes Docker firmadas con cosign. Si usas la versión 1.83.0 o posterior y no ejecutabas una versión contaminada durante esa ventana de 40 minutos, este incidente está cerrado para ti.
La razón por la que esto sigue llevando a la gente a esta búsqueda es estructural, no específica de LiteLLM. Un proxy autohospedado es un paquete dentro de tu compilación, lo que convierte a tu CI/CD y a tu clúster en parte de su radio de impacto. Esa es la frase que merece atención: es igualmente cierta para todas las alternativas autohospedadas de esta página, incluido MLflow AI Gateway, y es lo único que elimina un endpoint alojado: llamas a una URL HTTPS, así que no hay ningún paquete que envenenar ni nada del gateway ejecutándose dentro de tu red.
La otra mitad honesta: un gateway alojado no es más seguro; está expuesto de otra manera. Tu clave de API y el texto de tus prompts atraviesan la infraestructura de otra persona, y asumes su riesgo de filtración en lugar de tu propio riesgo de aplicar parches. Si el texto de los prompts no puede salir de tu infraestructura, el autohospedaje es la respuesta correcta y el resto de esta página trata sobre una concesión que no deberías hacer.
1. Kunavo: sin proxy ni cuentas de proveedores
Kunavo es un gateway de inferencia alojado: una URL base compatible con OpenAI, una clave sk-kn-, un saldo de pago por uso, y nosotros gestionamos las credenciales de los proveedores ascendentes en lugar de ti. Frente a LiteLLM, es una división del trabajo diferente: no ejecutas un proxy ni mantienes cuentas separadas en Anthropic, Google y OpenAI.
Precio: la mayor parte del catálogo aparece con tarifas inferiores a las oficiales de los proveedores: Claude Sonnet 4.6 a $2.10 / $10.50 por cada millón de tokens, frente a $3.00 / $15.00 de Anthropic. LiteLLM no aplica margen porque no revende nada; lo que pagas es tu propio acuerdo con el proveedor, así que la comparación es nuestra tarifa frente a tu tarifa directa, no frente a cero. Cobertura: modelos de chat, imagen, vídeo y música con la misma clave y saldo. Lo que no hace: enrutar tus propias claves de proveedor: esa es la parte de BYO-key que LiteLLM conserva y que nosotros no sustituimos. Detalles: Kunavo frente a LiteLLM.
2. OpenRouter: la cola de modelos más extensa
El otro gateway de inferencia alojado, y el que debes elegir cuando la amplitud del catálogo importa más que el precio unitario: cientos de modelos de un amplio conjunto de proveedores con una sola cartera, además de niveles gratuitos y enrutamiento con tus propias claves, algo que Kunavo no ofrece. Si dejas LiteLLM porque quieres dejar de mantener cuentas, OpenRouter y Kunavo son las dos opciones realistas. Kunavo frente a OpenRouter los compara lado a lado, y el resumen de OpenRouter cubre el resto de ese mercado.
3. Portkey: conserva tus claves y olvídate de las operaciones
Un plano de control alojado sobre las cuentas de proveedores que ya tienes: enrutamiento, alternativas, controles de seguridad y observabilidad, sin tener que ejecutar tu propio proxy. Es el reemplazo más cercano si elegiste LiteLLM por sus funciones de enrutamiento y presupuesto y lo único que realmente quieres dejar es su operación. Detalles: Kunavo frente a Portkey.
4. Helicone: si la observabilidad era el motivo principal
Muchas implementaciones de LiteLLM existen porque alguien necesitaba registros de solicitudes y atribución de costes por equipo, y el proxy era la forma de conseguirlos. Si ese es tu caso, una capa de observabilidad sobre tus llamadas existentes a los proveedores es mucho más pequeña de operar que un gateway. Detalles: Kunavo frente a Helicone.
5. TrueFoundry: cuando compras necesita un proveedor
Ocupa la posición 2 en esta búsqueda con su propia comparación con LiteLLM. Es un gateway de IA empresarial comercializado por su sobrecarga de latencia, flexibilidad de despliegue, SLA, gobernanza y controles preparados para auditorías (su página de producto). No lo hemos evaluado, así que esta entrada es una referencia, no una recomendación: si tu obstáculo es que un proxy de código abierto no tiene un contrato de soporte, esta es la categoría que lo resuelve, y vale la pena leer la comparación sabiendo que la escribieron ellos.
6. MLflow AI Gateway: el reemplazo de código abierto equivalente
Posición 3, y lo más parecido de esta página al propio LiteLLM: un gateway de código abierto y autohospedado que pone tus propias claves de proveedor al frente, mantenido como parte del proyecto MLflow. Conviene decirlo claramente: cambiar un proxy autohospedado por otro mantiene el modelo de despliegue y, por tanto, también la superficie de ataque descrita arriba. Es una opción legítima: es lo que quieres si lo que no te gustaba era el proyecto, no el modelo.
7. Cloudflare AI Gateway: almacenamiento en caché y límites en el edge
Un proxy ligero delante de las cuentas de proveedores que ya tienes: almacenamiento en caché de respuestas, limitación de velocidad, reintentos y analítica, sin revender inferencia. Se combina con cualquier fuente de inferencia en lugar de sustituirla, incluido Kunavo u OpenRouter. Detalles: Kunavo frente a Cloudflare AI Gateway.
Cuándo LiteLLM sigue siendo la opción correcta
- El texto de los prompts no puede salir de tu infraestructura. Datos regulados, entornos aislados o una política que un gateway alojado simplemente no puede cumplir. El autohospedaje es la respuesta y la única pregunta es qué proxy autohospedado elegir.
- Tienes contratos negociados con proveedores. El gasto comprometido o las tarifas empresariales de Anthropic, OpenAI o Google valen más que cualquier precio publicado por un revendedor, y las herramientas BYO-key son la forma de seguir utilizándolos.
- Usas sus presupuestos por clave y el enrutamiento por equipo. Esas funciones son la razón por la que existen muchas implementaciones de LiteLLM; comprueba que tu reemplazo las cubra antes de asumir que cambiar la URL base constituye toda la migración.
- Quieres código fuente que puedas leer y modificar. Un proxy de código abierto que controlas es una propiedad real, y el incidente de marzo de 2026 no la elimina: fue un compromiso del flujo de publicación, ya remediado, no un fallo del propio proxy.
Cambiar implica dos líneas
Todas las alternativas de aquí que revenden inferencia hablan el protocolo de red de OpenAI, así que pasar de un proxy de LiteLLM es un base_url y un cambio de clave; las estructuras de solicitud y respuesta no cambian:
# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
api_key=os.environ["LITELLM_MASTER_KEY"],
base_url="http://litellm.internal:4000",
)
# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
api_key=os.environ["KUNAVO_API_KEY"],
base_url="https://api.kunavo.com/v1",
)
resp = client.chat.completions.create(
model="claude-sonnet-5",
messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)La parte que no son dos líneas es todo lo que LiteLLM hacía además de enrutar: presupuestos por clave, distribución entre equipos, callbacks personalizados. Haz primero un inventario. Los detalles del nivel de red están en la guía de API compatible con OpenAI, y lo que un gateway debería gestionar por ti cubre el conjunto de funciones con el que debes evaluar un reemplazo.
Preguntas frecuentes
¿Cuál es la mejor alternativa a LiteLLM?
Depende de lo que estés sustituyendo. Si quieres dejar de ejecutar un proxy y de gestionar cuentas de proveedores, una puerta de enlace de inferencia alojada como Kunavo u OpenRouter sustituye ambas cosas a la vez. Si quieres conservar tus propias claves de proveedor pero no operar tú mismo el proxy, Portkey o TrueFoundry son planos de control BYO-key alojados. Si los registros y el seguimiento de costes eran los únicos motivos por los que ejecutabas LiteLLM, Helicone cubre solo eso. Si quieres código abierto que puedas alojar tú mismo, MLflow AI Gateway es la alternativa más parecida.
¿Por qué se buscan alternativas a LiteLLM en 2026?
Por dos motivos distintos. El operativo es habitual: un proxy autogestionado es un servicio que debes actualizar, escalar y por el que alguien debe recibir alertas. El segundo es específico: el 24 de marzo de 2026, un atacante publicó en PyPI dos versiones de LiteLLM con puertas traseras y, según SecurityWeek, el incidente afectó a más de 2.500 organizaciones. Desde entonces, LiteLLM ha rotado las credenciales y reconstruido su canal de publicación, por lo que para la mayoría de los equipos la pregunta no es si LiteLLM es seguro ahora, sino si quieren tener esa dependencia en su compilación.
¿Qué versiones de LiteLLM se vieron comprometidas en el ataque a la cadena de suministro de marzo de 2026?
litellm==1.82.7 y litellm==1.82.8. Según la actualización de seguridad del propio LiteLLM, estuvieron disponibles en PyPI el 24 de marzo de 2026 desde las 10:39 UTC durante unos 40 minutos, antes de que PyPI las pusiera en cuarentena. LiteLLM atribuyó el compromiso a la dependencia Trivy de su flujo de trabajo de análisis CI/CD, contrató a Mandiant para el análisis forense y publicó v1.83.0 mediante un canal reconstruido con entornos de compilación aislados e imágenes Docker firmadas.
¿Es más segura una puerta de enlace de IA alojada que alojar LiteLLM por cuenta propia?
No es más segura, sino que está expuesta de otra forma. Una puerta de enlace alojada elimina el paquete de tu compilación y el proxy de tu clúster, por lo que una publicación envenenada no puede llegar a tu CI/CD ni a tus nodos de Kubernetes a través de ellos. A cambio, tu clave de API y el texto de tus prompts pasan por un tercero, y heredas el riesgo de una brecha de ese proveedor en lugar del tuyo. Los equipos que no puedan enviar el texto de los prompts fuera de su propia infraestructura deberían alojarlo por sí mismos; la elección es un modelo de confianza, no una puntuación de seguridad.
¿Existe una alternativa de código abierto a LiteLLM?
MLflow AI Gateway es la alternativa más parecida: una puerta de enlace de código abierto y autohospedada que pone tus propias claves de proveedor detrás de un único endpoint, mantenida como parte del proyecto MLflow. Ocupa la posición 3 en esta búsqueda y es la alternativa más similar a LiteLLM por su estructura.
¿Cómo migro desde LiteLLM?
Si te trasladas a otro endpoint compatible con OpenAI, la migración consiste en cambiar base_url y la clave de API: las estructuras de solicitud y respuesta no cambian, y los nombres de los modelos se mantienen con el mismo estilo. Lo que no se resuelve en dos líneas es lo que LiteLLM hacía por ti además del enrutamiento: aplicación de presupuestos, distribución de claves por equipo y callbacks personalizados. Comprueba cuáles de esas funciones cubre tu sustituto antes de cambiar.
¿Cuándo debería seguir usando LiteLLM?
Quédate cuando el texto de los prompts no pueda salir de tu infraestructura, cuando ya tengas contratos negociados con proveedores que quieras seguir utilizando, cuando necesites sus funciones de presupuesto por clave y enrutamiento por equipo, o cuando quieras un proxy de código abierto que puedas leer y modificar tú mismo. Son fortalezas reales, y el incidente de marzo de 2026 no elimina ninguna: fue un compromiso del canal de publicación, ya corregido, y no un defecto de lo que hace el proxy.