La extensión Inference del Gateway API permite enrutar solicitudes de modelos grandes (LLM) en Kubernetes según el estado de los pods, consultando señales como KV cache, adaptadores LoRA y longitud de cola para elegir el backend óptimo;
Gateway API, mediante la extensión Inference, introduce un enrutamiento consciente del estado para solicitudes a grandes modelos (LLM) en Kubernetes: el Gateway intercepta peticiones, determina el modelo objetivo y decide a qué pod enviar cada solicitud basándose en señales de serving. Ese enfoque promete aprovechar mejor la capacidad del clúster y reducir latencia al evitar backends que no estén preparados para procesar la petición eficientemente.
A nivel de entrada, el Gateway valida la petición según hostnames y reglas definidas en un objeto HTTPRoute. El nombre del modelo puede extraerse desde la ruta, desde cabeceras o a través de un Body‑Based Router (BBR) cuando el identificador aparece dentro del payload JSON. Con ese nombre, el Gateway asocia la solicitud a un InferencePool, que representa el conjunto de pods que sirven ese modelo.
La decisión de destino no recae en algoritmos de reparto genéricos (por ejemplo round‑robin). En su lugar, la extensión Inference pausa la entrega y consulta un Endpoint Picker (EPP) propio del pool para seleccionar el pod más adecuado. El EPP actúa como capa de selección dinámica entre la entrada y el serving efectivo. El Endpoint Picker evalúa múltiples señales de serving antes de dirigir la petición: estado del KV cache (aciertos o fallos), disponibilidad y estado de adaptadores LoRA, longitud de las colas en cada pod, latencias observadas y otras métricas de capacidad. Además, el EPP aplica control de flujo para evitar sobrecargar pods no preparados y así reducir fallos o recomputos costosos.
El motivo técnico es claro: los balanceadores HTTP convencionales están diseñados para tráfico web relativamente uniforme, mientras que las inferencias LLM implican tasas, costes y duraciones muy variables. Un enrutamiento basado en el estado del backend tiende a utilizar mejor la capacidad del clúster y a disminuir latencias al no enviar solicitudes a pods con KV cache frío, sin LoRA cargada o con colas largas.
Para que la extensión Inference funcione en producción, los equipos de ingeniería deben migrar a Gateway API y habilitar la extensión, instrumentando métricas de estado por pod y por pool. Es necesario validar HTTPRoute y BBR y supervisar el comportamiento del EPP. Una observabilidad adecuada — midiendo aciertos/fallos de KV cache, presencia/estado de LoRA, longitudes de cola y latencias por pod-permite comprobar que el enrutamiento consciente reduce recomputos y evita colas largas en backends no preparados.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
