Phase 17 - Lesson 19

Gateways de IA — LiteLLM, Portkey, Kong AI Gateway, Bifrost

Un gateway se sitúa entre sus aplicaciones y los proveedores de modelos. Las características principales son enrutamiento de proveedores, fallback, reintentos (retries), limitación de tasa (rate limiting), referencias a secretos (secrets), observabilidad y guardrails. Distribución del mercado en 2026: LiteLLM es código abierto con licencia MIT, cuenta con soporte a más de 100 proveedores, compatible con OpenAI, pero experimenta problemas alrededor de ~2000 RPS (8 GB de memoria, provocando fallos en cascada en benchmarks publicados); ideal para Python, <500 RPS y desarrollo/prototipado. Portkey está posicionado en el plano de control (guardrails, redacción de PII, detección de jailbreak, pistas de auditoría), se convirtió en código abierto bajo licencia Apache 2.0 en marzo de 2026, con un overhead de latencia de 20-40 ms y plan de producción de $49/mes. Kong AI Gateway se basa en Kong Gateway — el benchmark del propio Kong en hardware equivalente a 12 CPUs demostró ser 228% más rápido que Portkey y 859% más rápido que LiteLLM; precio de
00/modelo/mes (máximo de 5 en el plan Plus); adecuado para empresas que ya utilizan Kong. Bifrost (Maxim AI) — reintentos automáticos con backoff configurable, con fallback a Anthropic si OpenAI devuelve error 429. Gateways de IA de Cloudflare / Vercel — administrados, sin necesidad de operación (zero-ops) y con reintentos básicos. La residencia de los datos impulsa la decisión de auto-hospedar (self-host); Portkey y Kong se sitúan en el término medio con versiones de código abierto (OSS) + servicio administrado opcional.

Type: Learn Languages: Python (stdlib, simulador simple de enrutamiento de gateway) Prerequisites: Phase 17 · 01 (Managed LLM Platforms), Phase 17 · 16 (Model Routing) Time: ~60 minutos

Objetivos de Aprendizaje

Enumerar las seis características principales de un gateway (enrutamiento, fallback, reintentos, límites de tasa, secretos, observabilidad, guardrails).
Asociar los cuatro gateways de 2026 (LiteLLM, Portkey, Kong AI, Bifrost) a límites de escala y casos de uso.
Citar el benchmark de Kong (228% vs Portkey, 859% vs LiteLLM) y explicar por qué es relevante para cargas >500 RPS.
Elegir entre soluciones auto-hospedadas y administradas según la residencia de datos y el presupuesto operativo.

El Problema

Su producto realiza llamadas a OpenAI, Anthropic y una instancia local de Llama. Cada proveedor tiene un SDK, modelo de error, límite de tasa y esquema de autenticación diferentes. Desea implementar failover (si OpenAI devuelve 429, intentar Anthropic), un único almacén de credenciales, observabilidad unificada y límites de tasa por tenant.

Reinventar esto en la capa de aplicación acopla cada servicio a cada proveedor. Una capa de gateway lo consolida en un único proceso con una única API (generalmente compatible con OpenAI) que se distribuye a los proveedores.

El Concepto

Seis características principales

Enrutamiento de proveedores — OpenAI, Anthropic, Gemini, auto-hospedados, etc. detrás de una sola API.
Fallback — ante un error 429, 5xx o fallo de calidad, intenta en otro lugar.
Reintentos (retries) — retroceso exponencial (exponential backoff), intentos limitados.
Límite de tasa (rate limits) — por tenant, por clave o por modelo.
Referencias a secretos (secrets) — obtiene credenciales de bóvedas (vaults) en tiempo de ejecución (nunca en la aplicación).
Observabilidad — OTel + atributos de GenAI (Fase 17 · 13) + atribución de costos.
Guardrails — redacción de PII, detección de jailbreak, filtros de temas permitidos.

LiteLLM — MIT OSS, Python

Más de 100 proveedores, compatible con OpenAI, enrutamiento configurable, fallback, observabilidad básica.
Deja de funcionar cerca de 2000 RPS en el benchmark de Kong; consumo de memoria de 8 GB, con fallos en cascada bajo carga sostenida.
Adecuado para: aplicaciones Python, <500 RPS, gateways de desarrollo/staging y enrutamiento experimental.
Costo: $0 para la versión de código abierto; existe un plan gratuito en la nube.

Portkey — posición del plano de control

Código abierto con licencia Apache 2.0 desde marzo de 2026. Guardrails, redacción de PII, detección de jailbreak, pistas de auditoría.
Latencia adicional de 20-40 ms por solicitud.
Plan de producción de $49/mes con retención + SLA.
Adecuado para: industrias reguladas que necesitan guardrails y observabilidad integrados.

Kong AI Gateway — la opción a escala

Basado en Kong Gateway (producto maduro de gateway de APIs, escrito en Lua + OpenResty).
Benchmark del propio Kong en equivalente a 12 CPUs: 228% más rápido que Portkey, 859% más rápido que LiteLLM.
Precios:
00/modelo/mes, máximo 5 en el plan Plus.
Adecuado para: equipos que ya usan Kong; >1000 RPS; dispuestos a pagar la licencia.

Bifrost (Maxim AI)

Reintentos automáticos con retroceso configurable.
Receta clásica: fallback a Anthropic cuando OpenAI devuelve error 429.
Solución comercial más reciente.

Cloudflare AI Gateway / Vercel AI Gateway

Administrados, sin necesidad de operación (zero-ops). Reintentos y observabilidad básicos.
Adecuado para: aplicaciones JavaScript desplegadas en la periferia (edge) en Cloudflare/Vercel.
Características limitadas de guardrails y límites de tasa en comparación con Kong/Portkey.

Auto-hospedado vs administrado

La residencia de datos es el factor decisivo. Los sectores de salud y finanzas eligen soluciones auto-hospedadas (LiteLLM, Portkey OSS o Kong). Los productos de consumo prefieren soluciones administradas (Cloudflare AI Gateway) o nivel intermedio (Portkey administrado). Híbrido: auto-hospedado para inquilinos regulados y administrado para los demás.

Presupuesto de latencia

LiteLLM: latencia adicional típica de 5-15 ms.
Portkey: latencia adicional de 20-40 ms.
Kong: latencia adicional de 3-8 ms.
Cloudflare/Vercel: latencia adicional de 1-3 ms (ventaja del procesamiento en el edge).

La latencia del gateway se añade directamente al TTFT. Para SLA de TTFT P99 < 100 ms, use Kong o Cloudflare. Para P99 < 500 ms, cualquiera de ellos funciona.

La semántica de la limitación de tasa importa

El algoritmo de cubeta de tokens (token-bucket) funciona bien hasta escalas moderadas. Los escenarios multi-tenant requieren ventana deslizante (sliding-window) + tolerancia a picos (bursts) + niveles por inquilino. LiteLLM incluye token-bucket; Kong incluye ventana deslizante; Portkey ofrece límites por niveles (tiered).

Gateway + observabilidad + enrutamiento se integran

La Fase 17 · 13 (observabilidade) + 16 (enrutamiento de modelos) + 19 (gateways) representan la misma capa en producción. Elija una herramienta que cubra las tres funciones o conéctelas con cuidado: la mayoría de los despliegues en 2026 combinan Helicone (observabilidad) o Portkey (guardrails) con Kong (escala) dividiendo los roles.

Números que debe recordar

LiteLLM: falla a ~2000 RPS, consumo de 8 GB de memoria.
Portkey: overhead de 20-40 ms; Apache 2.0 desde marzo de 2026.
Kong: 228% más rápido que Portkey, 859% más rápido que LiteLLM.
Precios de Kong:
00/modelo/mes, máximo de 5 en el plan Plus.
Cloudflare/Vercel: latencia adicional de 1-3 ms en el edge.

Uso

code/main.py simula el enrutamiento del gateway con fallback entre 3 proveedores bajo inyección de errores 429/5xx. Informa de la latencia, la tasa de reintentos y la tasa de aciertos de fallback.

Puesta en Producción

Esta lección produce outputs/skill-gateway-picker.md. Dada la escala, postura de operación, cumplimiento y presupuesto de latencia, elige un gateway.

Ejercicios

Ejecute code/main.py. Configure el fallback de OpenAI→Anthropic→auto-hospedado. ¿Cuál es la tasa de aciertos esperada con una tasa de error de proveedor del 5%?
Su SLA exige TTFT P99 < 200 ms sobre una línea base de 300 ms. ¿Cuáles gateways permanecen dentro del presupuesto?
Un cliente de salud requiere auto-hospedaje + redacción de PII + pistas de auditoría. Elija entre Portkey OSS o Kong.
Compare LiteLLM vs Kong: ¿en qué límite de RPS debería migrar el equipo?
Diseñe una política de límite de tasa para un SaaS multi-tenant: planes gratuito, de prueba y de pago. ¿Cubeta de tokens o ventana deslizante?

Términos Clave

Término	Lo que la gente dice	Lo que realmente significa
Gateway	"intermediario de APIs"	Proceso intermediando apps e proveedores
LiteLLM	"el de la licencia MIT"	Python OSS, 100+ proveedores, falla a 2K RPS
Portkey	"gateway de guardrails"	Plano de control + observabilidad, Apache 2.0
Kong AI Gateway	"el de escala"	Basado en Kong Gateway, líder en benchmarks
Bifrost	"gateway de Maxim"	Receta de reintentos + fallback a Anthropic
Cloudflare AI Gateway	"administrado en el edge"	Gateway administrado desplegado en el edge, zero-ops
Redacción de PII	"limpieza de datos"	Máscara mediante Regex + NER antes de enviar al modelo
Detección de jailbreak	"protección contra inyección de prompt"	Clasificador sobre la entrada del usuario
Pistas de auditoría	"logs regulados"	Registro inmutable de cada llamada a LLM
Cubeta de tokens	"límite de tasa simple"	Limitador basado en recarga de tokens
Ventana deslizante	"límite de tasa preciso"	Limitador basado en ventanas temporales; mejor equidad