LiteLLM vs Kong AI Gateway
Ambos se pueden autoalojar y ambos son de núcleo abierto. La línea que realmente decide: ¿su gateway es un gateway de LLM o un gateway de API general que también habla con modelos?
LiteLLM y Kong AI Gateway se comparan porque son las dos opciones autoalojables que más equipos incluyen en su lista corta. No son el mismo tipo de software. LiteLLM es un proxy de LLM: toda su superficie son modelos, proveedores y enrutamiento compatible con OpenAI. Kong es un gateway de API general (plugins, upstreams, limitación de velocidad para tráfico HTTP arbitrario) con plugins de IA añadidos. Esa diferencia determina todas las demás filas de abajo: puntos de entrada de protocolo, granularidad de gobernanza y cuánto tiene que construir usted mismo.
Tres gateways, cinco criterios
Cada una de las dos primeras columnas es una lectura de una línea de la página comparativa correspondiente. La columna de GateLLM es nuestra propia posición, no una evaluación de terceros: valórela en consecuencia.
| Criterio | LiteLLM | Kong AI Gateway | GateLLM |
|---|---|---|---|
| Despliegue | OSS autoalojado | OSS autoalojado (+ Konnect gestionado) | Totalmente autoalojado (Docker / Helm), sin plano de control del proveedor |
| Base de la facturación | OSS gratuito; Enterprise con precio por uso | OSS gratuito; plugins limitados a Enterprise | Licencia por instancia; sin recargo por token ni tarifa por asiento |
| Puntos de entrada de protocolo | Centrado en OpenAI | Compatible con OpenAI + plugins de IA | Cuatro de entrada × cuatro de salida (OpenAI / Anthropic / Gemini / DashScope) |
| Gobernanza | SSO (límite de 5 usuarios) / RBAC en Enterprise | RBAC / SSO en Enterprise | SSO / SCIM / RBAC + ACL por grupo de claves y topes de presupuesto |
| Independencia del proveedor | Independiente (BerriAI) | Independiente (Kong Inc.) | Independiente (Fluxon LLC) |
Cuándo LiteLLM, cuándo Kong, cuándo ninguno
Elija LiteLLM si el tráfico que gobierna es tráfico de modelos y nada más: enrutamiento por modelo, conmutación por error entre proveedores y atribución de costos sin aprender un DSL de plugins, y si se siente cómodo operando un servicio de Python. Es el camino más corto de "llamar a muchos proveedores" a "llamar a muchos proveedores a través de un solo endpoint".
Elija Kong si ya ejecuta Kong para tráfico de API que no es de LLM. Reutilizar el gateway que ya tiene (sus plugins, su limitación de velocidad, sus runbooks operativos) suele superar a introducir un segundo gateway solo para IA. Los plugins de IA son la mitad menor de esa decisión.
Ninguno, si un solo proveedor, un solo equipo y una factura mensual manejable son su situación real. Llamar directamente a la API del proveedor es más sencillo que cualquiera de las dos opciones, y ningún gateway justifica su costo operativo hasta que necesite conmutación por error entre proveedores, atribución de costos por equipo o controles de cumplimiento que el proveedor no pueda darle.