Elegir la centralita: qué gateway OSS poner por delante, y por qué la licencia decide antes que las features

Este post es el companion de decisión de El router de inferencia LLM. Allí se explicó qué es un router de inferencia y por qué existe (catálogo, traffic splitting, política transversal, prefix-aware routing). Aquí se responde la pregunta que de verdad bloquea un despliegue: cuál elegir, con licencias verificadas y un orden de criterios que no es el que la mayoría usa.

TL;DR

El gateway es la pieza por la que pasa el 100 % del tráfico y la más cara de sustituir después: el SDK del cliente, las políticas de auth/rate-limit, el tracing y el catálogo de modelos se acoplan todos a él. Por eso el orden de los criterios importa, y no es el habitual. Primero la licencia: no “¿es open source?” sino “¿las features que necesito están bajo licencia permisiva o detrás de un muro Enterprise?”. Segundo el encaje arquitectónico: ¿es ciudadano de tu Kubernetes (Gateway API) o un proceso aparte que hay que operar al margen? Tercero, madurez y documentación. Cuarto, las features. Con datos verificados a junio 2026: LiteLLM es MIT en el core, pero SSO, audit logs, RBAC fino y varios guardrails son Enterprise; Kong tiene core Apache 2.0 pero sus plugins de IA que importan (semantic cache, prompt guard, AI proxy advanced) están gated; Envoy AI Gateway, Gateway API Inference Extension (GIE), Higress, APISIX y Bifrost son Apache 2.0 de punta a punta. Para un stack RKE2 + vLLM con prioridad K8s-native (que es el caso que asumimos aquí), la recomendación es adoptar el modelo Gateway API Inference Extension —el Endpoint Picker que enruta consciente de prefix cache, KV y LoRA, justo lo que multiplica el hit rate— implementado con Envoy AI Gateway si pesa la trayectoria AI-native, o con Higress si pesa la madurez de hoy; y LiteLLM (MIT) como plano de control multi-proveedor opcional por detrás. Con escepticismo explícito sobre las v0.x, el “OpenAI-compatible ≠ inference-aware” y la telemetría phone-home.

El principio que reordena los criterios: el gateway es matrimonio, no noviazgo

Hay piezas del stack que se cambian un domingo por la tarde: el modelo de embeddings, el reranker, hasta el motor de inferencia detrás de una interfaz OpenAI-compatible. El gateway no. Es la pieza a la que todo lo demás se acopla: el SDK de cada cliente apunta a su URL, las políticas de seguridad viven en él, el tracing nace en él, el catálogo de modelos lo define. Arrancarlo dos años después significa tocar a todos los consumidores a la vez. Es la decisión de infraestructura con mayor coste de reversión de toda la capa de serving.

Cuando una decisión es cara de revertir, el criterio dominante no es “¿qué hace hoy?” sino “¿puedo poseerlo y operarlo durante años sin sorpresas?”. Y eso pone la licencia por delante de las features. Una herramienta brillante cuyo SSO, audit log o RBAC viven detrás de un contrato Enterprise es una herramienta que, el día que tu despliegue ENS necesita esos controles, te obliga a pagar o a migrar —exactamente el escenario que la elección debía evitar. Por eso el orden de filtros de este post es licencia → encaje → madurez/docs → features, y no al revés.

El campo de candidatos (junio 2026)

Las piezas OSS reales que alguien pondría por delante de una flota vLLM on-premise:

Filtro 1 — Licencia: dónde está la letra pequeña

Aquí es donde mueren la mitad de las opciones, y donde “open source” engaña si no se mira el detalle. Lo verificado:

Dos conclusiones que decantan el campo:

• Kong cae para un despliegue AI OSS. Su core es Apache 2.0, pero precisamente los plugins de IA que justificarían elegirlo (semantic cache, prompt guard, proxy advanced) son Enterprise, con contratos que la propia comparativa del sector sitúa por encima de cinco cifras anuales. Para IA sobre presupuesto OSS, APISIX ofrece más built-in sin coste. Kong sigue siendo excelente como API gateway clásico; como AI gateway OSS, no.
• LiteLLM es MIT de verdad en el core, y eso es real: lo puedes forkear, modificar y usar comercialmente. Pero SSO, audit logs, RBAC fino y varios guardrails son Enterprise. Bajo el criterio que fijamos —“core permisivo basta, la gobernanza la resuelvo con OIDC/auditoría externa del stack”— LiteLLM sigue en juego; bajo un criterio “todo OSS o nada”, quedaría tocado. Conviene saber exactamente qué cae de qué lado de la línea antes de comprometerse.

LiteLLM: qué está gated y su equivalente OSS

El matiz que decide si el gating de LiteLLM es un problema real o no: “feature built-in de pago” no es lo mismo que “capacidad imposible en OSS”. En casi todos los casos la capacidad se logra cambiando el cómo —cableando OSS por el hook abierto de LiteLLM, o resolviéndolo en la capa de al lado (el gateway, la observabilidad)—. El desglose, verificado con la doc:

La conclusión que cierra la decisión: en un diseño K8s-native con gateway por delante, el OIDC y la autorización viven en el gateway (Envoy/Higress + OPA) y el audit trail en Langfuse/OTel —ambos Apache 2.0, ya en el stack—, así que LiteLLM puesto por detrás apenas necesita su Enterprise: las piezas de gobernanza están donde corresponde arquitectónicamente y resultan ser OSS. El único coste real es la integración y el mantenimiento DIY, y —para ENS— el diseño de garantías del audit trail (retención, inmutabilidad/WORM) corre de tu cuenta, no sale de fábrica.

El resto —Envoy AI Gateway, GIE, Higress, APISIX, Bifrost— pasan el filtro de licencia limpios: Apache 2.0 de punta a punta, sin features críticas tras un muro.

Filtro 2 — Encaje: ¿ciudadano de Kubernetes o inquilino?

Con prioridad K8s-native (RKE2), la pregunta es si el gateway se modela como recursos del cluster —que se versionan con GitOps, se observan con las mismas herramientas y se integran con el scheduler— o si es un proceso aparte que hay que operar al margen. Aquí aparece la novedad estructural de 2025-2026: la Gateway API Inference Extension (GIE).

GIE es una extensión de la Gateway API estándar de Kubernetes, del SIG-Network, que añade dos piezas: el InferencePool (un pool de réplicas de un modelo como recurso nativo) y el Endpoint Picker (EPP), un planificador que decide a qué réplica va cada request en función del estado de inferencia: longitud de cola, adapters LoRA disponibles, y —la pieza clave— estado del prefix cache de cada réplica. Es exactamente el prefix-aware routing que en el post del router explicaba por qué el hit rate pasa del 5-15 % al 60-85 %, ahora como estándar de la comunidad en vez de feature propietaria de cada producto.

Por qué esto decanta la decisión cuando la prioridad es K8s-native: GIE convierte el routing inference-aware en una interfaz estándar que varias implementaciones cumplen (Envoy AI Gateway, Higress, kgateway, Istio, GKE Inference Gateway). Eliges una implementación hoy y, si mañana cambias, el modelo de recursos (InferencePool, HTTPRoute) se conserva. Es justo la propiedad que querías de una decisión cara de revertir: el acoplamiento es a un estándar, no a un producto. Un proxy standalone como LiteLLM, por bueno que sea, vive fuera de este modelo —es un Deployment más, con su propia config, su propio formato de catálogo y su propio plano de gestión.

Filtro 3 — Madurez y documentación: la honestidad incómoda

Aquí aparece la tensión que ninguna comparativa de marketing reconoce: lo K8s-native-correcto y lo battle-tested-hoy no coinciden del todo en junio de 2026.

• Envoy AI Gateway: la capa AI va por v0.5 —pre-1.0, joven. Pero corre sobre Envoy y Envoy Gateway, que son de lo más maduro que existe en proxies. Tiene la integración GIE/EPP más completa, model virtualization, tracing OpenInference. Riesgo: la capa AI aún se mueve rápido (breaking changes posibles). Docs en crecimiento, buenas.
• GIE: el proyecto está llegando a GA (de las primeras extensiones inference-aware estandarizadas). Madurez del estándar alta y subiendo; madurez de cada implementación, variable.
• Higress: el más maduro hoy entre los K8s-native Apache-2.0 con IA. Producción a escala Alibaba, CNCF, base Envoy/Istio, AI plugins incluidos, soporte de Gateway API. Si “maduro” pesa más que “AI-native de vanguardia”, es la apuesta segura.
• APISIX: gateway clásico muy maduro, con plugins de IA crecientes; menos especializado en inference-aware (prefix/KV) que el modelo GIE. Battle-tested a escala masiva.
• LiteLLM: el de mejor documentación y mayor adopción del campo, con diferencia. Mature como proxy. Su techo es el lenguaje (Python/FastAPI: ~250-300 RPS por instancia, escala por réplicas) y el gating de gobernanza ya visto.
• Bifrost: Apache 2.0, Go, el de mayor rendimiento (overhead de ~11 µs a 5.000 RPS), con semantic caching y governance built-in. Más joven y menos probado a años, pero técnicamente fuerte.

Matriz de decisión

Ponderando los cuatro filtros para el caso RKE2 + vLLM, prioridad K8s-native, core permisivo aceptable:

La recomendación

Para el caso que fijamos —RKE2 + vLLM, prioridad K8s-native, licencia permisiva con core suficiente— la recomendación tiene dos capas, no una:

Capa de datos (lo que va por delante de las réplicas): adopta el modelo Gateway API Inference Extension. Es la decisión que envejece bien porque te acopla a un estándar Apache 2.0, no a un producto, y porque trae el routing prefix/KV/LoRA-aware que de verdad mueve el hit rate. Para la implementación:

• Si pesa la trayectoria AI-native y aceptas operar una capa v0.x sobre un Envoy maduro: Envoy AI Gateway + GIE/EPP. Es donde está la vanguardia y la integración más completa.
• Si pesa la madurez de hoy por encima de todo (ENS, producción crítica, cero apetito por v0.x en la ruta del 100 % del tráfico): Higress con GIE. CNCF, probado a escala, Apache 2.0, y migrable al EPP estándar.

Capa de control (opcional, por detrás): LiteLLM (MIT) si necesitas un punto único multi-proveedor con virtual keys, spend tracking y fallbacks hacia modelos externos. Se coloca detrás del gateway de datos, no en su lugar, y aceptas que SSO/audit/RBAC los resuelves con el OIDC y la auditoría del propio cluster (tal como fijamos en el criterio). Si tu front es solo vLLM on-premise sin proveedores externos, esta capa probablemente sobra.

Lo que no recomendaría aquí: Kong (sus features de IA están gated, contradice el criterio de licencia); y empezar por LiteLLM como gateway de datos principal en un stack que será multi-réplica y K8s-native —su techo de Python y su posición fuera del modelo Gateway API lo convierten en deuda el día que escalas.

Aplicado a nuestra infraestructura: RKE2 + vLLM + 4×H100

El despliegue concreto sobre el cluster genérico de referencia:

# El InferencePool agrupa las réplicas de un modelo (recurso GIE)
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferencePool
metadata: { name: llama-70b-pool }
spec:
  selector: { app: vllm-llama70b }
  extensionRef: { name: llama-70b-epp }   # el Endpoint Picker
---
# La ruta estándar Gateway API apunta al pool
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: llama-70b }
spec:
  parentRefs: [ { name: ai-gateway } ]
  rules:
    - backendRefs:
        - group: inference.networking.x-k8s.io
          kind: InferencePool
          name: llama-70b-pool

Tres notas de encaje con la serie del blog:

• Vive en la capa 1 del stack de siete capas, por delante de las réplicas pinneadas por los resource managers de RKE2. El gateway enruta; el kubelet pinnea; ambos son recursos del mismo cluster GitOps.
• El EPP lee el estado de prefix cache de cada réplica, lo que conecta directamente con la ingeniería de prefix cache hit rate: el gateway es quien materializa esa afinidad en routing real.
• El tracing gen_ai.* del gateway alimenta el pipeline de observabilidad OTel y aterriza en Langfuse, cerrando el círculo de la capa Observe.

Trampas y cosas que no son lo que parecen

“Es open source” sin leer qué cae bajo Enterprise. El error que este post intenta evitar: Kong y LiteLLM son OSS, pero las features que justifican elegirlos para IA (plugins de IA en Kong; SSO/audit/RBAC/guardrails en LiteLLM) están parcial o totalmente gated. “Open source” es la pregunta equivocada; “¿lo que necesito es permisivo?” es la correcta.

“OpenAI-compatible” ≠ “inference-aware”. Casi todos exponen el API de OpenAI. Eso no significa que entiendan el estado del KV cache, la cola de cada réplica o los adapters LoRA. La compatibilidad de API es de entrada; el routing inteligente (EPP) es otra liga. No confundas “habla OpenAI” con “enruta bien”.

Elegir por el benchmark de RPS. Bifrost gana en overhead bruto, pero el cuello de botella de una flota vLLM on-premise rara vez es el proxy: son las GPUs. Optimizar el gateway para 5.000 RPS cuando tus réplicas sirven 300 req/s es resolver el problema que no tienes. La latencia añadida del gateway importa; su throughput pico, casi nunca, en este contexto.

Telemetría phone-home en un despliegue soberano. Varios gateways envían telemetría a casa por defecto. En un contexto ENS/soberanía, eso es un hallazgo de auditoría, no un detalle. Verifica y desactiva el phone-home antes de poner el gateway en la ruta del 100 % del tráfico; documéntalo para el expediente de controles ENS/42001/EU AI Act.

Apostar a una v0.x en la ruta crítica sin plan de rollback. Envoy AI Gateway v0.5 es prometedor, pero está en la ruta del 100 % del tráfico. Si lo eliges, ten el rollback ensayado y sigue el changelog: las v0.x rompen. El estándar GIE mitiga esto (puedes cambiar de implementación), pero la implementación concreta hay que operarla con red.

Confundir el gateway de datos con el plano de control. LiteLLM por delante de todo parece simplificar, pero mezcla dos roles: enrutar tráfico de datos (donde quieres K8s-native + inference-aware) y gestionar claves/spend multi-proveedor (donde LiteLLM brilla). Sepáralos: gateway de datos GIE-native, LiteLLM como control plane detrás si hace falta.

Conclusión

El gateway es la pieza con mayor coste de reversión de la capa de serving, y eso obliga a invertir el orden intuitivo de criterios: primero la licencia —no “¿es OSS?” sino “¿lo que necesito es permisivo o está gated?"—, que ya descarta Kong para IA OSS y pone una estrella a LiteLLM por su gobernanza Enterprise; luego el encaje, donde la Gateway API Inference Extension convierte el routing inference-aware en un estándar Apache 2.0 al que acoplarse sin casarte con un producto; y solo después madurez, docs y features, donde la honestidad obliga a admitir que lo AI-native de vanguardia (Envoy AI Gateway v0.5) y lo battle-tested-hoy (Higress) aún no son lo mismo. Para un stack RKE2 + vLLM con prioridad K8s-native, la respuesta no es un producto sino un modelo —GIE/EPP— implementado con Envoy AI Gateway si miras la trayectoria o con Higress si miras la madurez, y LiteLLM como plano de control opcional por detrás. La decisión que envejece bien es la que te acopla a un estándar, no a un vendor; en gateways, en junio de 2026, ese estándar tiene por fin nombre.

Ver también

• El router de inferencia LLM: la centralita L7 — el post que explica qué es y por qué existe un router de inferencia; este elige cuál con licencias verificadas. Léelos en orden.
• Resource managers de RKE2 — el gateway enruta hacia las réplicas que estos managers pinnean al NUMA node correcto; ambos son recursos del mismo cluster GitOps.
• Ingeniería del prefix cache hit rate — la afinidad que el Endpoint Picker materializa en routing real; el gateway es quien convierte el cache caliente en hit rate.
• El stack de inferencia LLM on-premise en siete capas — el gateway es la capa 1; este post elige la pieza concreta que la ocupa.
• El catálogo OSS para LLMOps en seis etapas y OSS vs hyperscalers — el gateway dentro del mapa OSS completo y su traducción a las nubes públicas.
• Tracing LLM con OpenTelemetry GenAI — el tracing gen_ai.* que nace en el gateway y alimenta la capa Observe.
• Controles técnicos ENS × 42001 × EU AI Act — por qué la licencia, la soberanía del despliegue y el phone-home del gateway son materia de auditoría, no detalles.
• Multi-LoRA serving — el EPP enruta consciente de qué adapter LoRA tiene cargado cada réplica; el gateway y el serving multi-adapter se coordinan aquí.

Referencias

• Kubernetes, Introducing Gateway API Inference Extension (blog oficial, jun 2025): https://kubernetes.io/blog/2025/06/05/introducing-gateway-api-inference-extension/.
• Gateway API Inference Extension, doc del proyecto (Endpoint Picker, InferencePool): https://gateway-api-inference-extension.sigs.k8s.io/.
• Envoy AI Gateway, sitio y release notes (v0.x, GIE integration): https://aigateway.envoyproxy.io/.
• LiteLLM, Enterprise Features (qué está gated): https://docs.litellm.ai/docs/proxy/enterprise · licencia MIT: https://github.com/BerriAI/litellm/blob/main/LICENSE.
• Kong, Announcing Kong’s Open Source AI Gateway y matriz de plugins Enterprise: https://konghq.com/blog/product-releases/announcing-kong-ai-gateway.
• Higress (Apache 2.0, CNCF, AI gateway): https://higress.cn/en/.
• Apache APISIX, APISIX vs Kong (cobertura de IA OSS): https://apisix.apache.org/learning-center/apisix-vs-kong/.
• vLLM, Semantic Router v0.1 Iris y Production Stack (routing específico de vLLM): https://blog.vllm.ai/2026/01/05/vllm-sr-iris.html.