Por Canuto  

Buoyant presentó Kinference, un proyecto abierto para coordinar solicitudes dirigidas a modelos vLLM en Kubernetes. La compañía reporta fuertes mejoras de latencia cuando las consultas comparten prefijos, aunque las cifras provienen de pruebas propias y la herramienta aún está en fase alfa.
***

  • Kinference decide a qué worker de vLLM enviar cada solicitud y permite definir políticas de enrutamiento mediante recursos de Kubernetes.
  • En la prueba de Buoyant, la mediana del tiempo hasta el primer token cayó de 6,88 a 0,31 segundos con prefijos compartidos.
  • La herramienta está en versión alfa y sus resultados se compararon con el enrutamiento aleatorio de Kubernetes Service.

Buoyant, la empresa conocida por desarrollar Linkerd, lanzó Kinference, un proyecto de código abierto que añade una capa de control a la inferencia de modelos en Kubernetes. El sistema coordina solicitudes frente a grupos de workers que ejecutan vLLM y aplica criterios de enrutamiento, balanceo consciente de la caché KV y métricas por inquilino. La compañía apunta a equipos que sirven varios modelos de pesos abiertos para distintos usuarios o áreas internas.

La propuesta se concentra en decidir qué worker debe atender cada petición, en vez de sustituir el motor que genera las respuestas. Buoyant describe a vLLM como el plano de datos y a Kinference como el plano de control, una separación que permite añadir reglas de operación y selección de destinos sobre la infraestructura existente. El proyecto se distribuye bajo licencia Apache 2.0 y su versión indicada en el lanzamiento es la v0.1.0-alpha.7.

Una capa de coordinación para vLLM

Kinference combina dos componentes: una puerta de enlace de tráfico y un manejador de inferencia. Este último expone una interfaz gRPC, recibe la solicitud y devuelve el endpoint escogido junto con un cuerpo que puede haber sido modificado; para completar el recorrido, se integra con un proxy, como Buoyant Gateway. La arquitectura sitúa la decisión de enrutamiento antes de que la petición llegue al servidor de modelos.

Para elegir un destino, el sistema observa eventos de caché KV de vLLM y métricas del motor. La implementación actual utiliza el componente de NVIDIA llamado dynamo-kv-router para procesar esos eventos, de modo que puede considerar si un worker ya conserva en caché partes reutilizables del prompt. También toma en cuenta la longitud de las colas, dos señales que Kinference utiliza para estimar el tiempo hasta el primer token de los endpoints candidatos.

La configuración se expresa con cinco recursos personalizados de Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider e InferenceWorkerSet. Esos objetos permiten describir los grupos de inferencia, los proveedores y las reglas que intervienen en el recorrido de una petición, en lugar de concentrar toda la lógica en ajustes manuales del servicio. Buoyant también ofrece la herramienta de línea de comandos kinfctl para validar políticas sin conexión.

El despliegue está pensado para clústeres de Kubernetes con GPU que ejecuten vLLM. La guía de inicio describe cinco pasos, que incluyen instalar los CRDs de Gateway API v1.5.1, el chart de Helm de Buoyant Gateway y luego el chart de Kinference. El proyecto incluye métricas para Prometheus y paneles de Grafana con indicadores como TTFT, ITL, latencia de extremo a extremo y tokens de prompt cacheados o no cacheados, en su mayoría desglosados por inquilino.

Políticas declarativas para distintos escenarios

El recurso InferencePolicy permite definir reglas para enrutar o rechazar solicitudes según el inquilino, el modelo pedido, el estado del grupo de GPU o etiquetas semánticas. Esa última posibilidad habilita, por ejemplo, que una etiqueta relacionada con información personal identificable cambie los destinos disponibles. La lógica busca ofrecer a los operadores control sobre qué modelos y proveedores pueden atender cada clase de petición.

Entre los ejemplos publicados por Buoyant aparece una estrategia que dirige solicitudes de baja complejidad a un modelo más económico, salvo que la superposición de caché haga más rápido recurrir a uno grande. Otra política permite desviar ráfagas a proveedores en la nube, saltándose workers con más de dos prompts en cola y usando alternativas como Bedrock. Son ejemplos de configuración del proyecto, no resultados de pruebas independientes sobre el ahorro o la calidad de esas decisiones.

Las políticas también contemplan que ciertas solicitudes no salgan de la infraestructura local. Si se activa una etiqueta PII, una regla puede excluir proveedores externos y rechazar la petición cuando no haya un destino permitido, mediante la opción onEmpty: Reject. Para cargas por lotes, otro patrón restringe el envío a workers cuya caché KV esté por debajo del 70% de uso, mientras que los alias permiten exponer un nombre estable como standard-model detrás del cual pueden operar varios modelos.

En muchos ejemplos, la regla final minimiza el TTFT previsto, sigla en inglés del tiempo hasta el primer token. Kinference estima ese tiempo para los endpoints candidatos a partir de la superposición de caché y el tamaño de la cola, con el propósito de evitar que una elección aparentemente equilibrada envíe la solicitud a un worker lento o sin contexto reutilizable. La diferencia frente a un balanceador simple es que la decisión puede depender del contenido y del estado de la infraestructura, no solo de repartir conexiones.

Resultados de latencia y capacidad

Buoyant publicó una comparación con el balanceo básico de Kubernetes Service. En cada configuración utilizó tres pods de vLLM 0.31.0, cada uno con una GPU L40S, y el modelo Qwen3.8-27B-FP8; GuideLLM 0.8.1 generó la carga de prueba. La referencia fue un servicio ClusterIP, en el que kube-proxy escoge un pod aleatorio por conexión, por lo que el ensayo contrasta Kinference con una línea base de enrutamiento no consciente de la caché.

En la carga de control, sin prefijos compartidos, la mediana del TTFT fue de 6,92 segundos con Kubernetes Service y de 6,83 segundos con Kinference, una diferencia que la empresa describió como no significativa. Con prefijos compartidos, la mediana pasó de 6,88 a 0,31 segundos, cerca de 95% menos; en el escenario multiturno bajó de 1,70 a 0,59 segundos, una reducción aproximada de 65%. Así, el resultado más marcado apareció cuando varias solicitudes podían reutilizar un prefijo.

La latencia mediana de extremo a extremo también cayó, según la prueba, 45% en el escenario de prefijo compartido y 32% en el multiturno. En el tráfico de control, el percentil 95 del TTFT descendió de 21,46 a 12,33 segundos, aunque la mediana apenas cambió; Buoyant atribuyó esa diferencia al balanceo que considera la cola. Las cifras muestran que una mejora en los extremos de la distribución puede coexistir con una mediana similar en solicitudes sin contexto compartido.

La evaluación de capacidad midió el goodput, definido en el informe como las solicitudes por minuto que cumplen un objetivo de TTFT. El pico llegó a 103,0 solicitudes por minuto con Kinference frente a 14,0 con el servicio de Kubernetes en prefijos compartidos, alrededor de 7,4 veces más; en multiturno, la comparación fue de 82,7 frente a 23,8, unas 3,5 veces. Buoyant dijo que su línea base no cumplió el objetivo de nivel de servicio en ninguna concurrencia probada.

Una alfa con resultados que requieren contexto

Los resultados son autoinformados por Buoyant y la comparación utiliza una referencia concreta: el balanceo aleatorio de Kubernetes Service. Por eso, las cifras no establecen que Kinference supere a todos los enrutadores conscientes de caché disponibles. Además, los objetivos de servicio usados en las pruebas, de ocho y cuatro segundos, fueron descritos por la propia compañía como adecuados para agentes sin conexión y no para aplicaciones de chat.

El lanzamiento sitúa Kinference junto a proyectos como llm-d, NVIDIA Dynamo y vLLM Production Stack, pero destaca un énfasis distinto. Según la comparación de Buoyant, Kinference reúne políticas declarativas, alias de modelos, respaldo hacia proveedores externos y métricas por inquilino; el manejo de límites de tasa figura como una capacidad prevista, no como una función ya disponible. La herramienta tampoco incluye todavía clasificadores ni soporte para la API de Anthropic.

La misma tabla comparativa presenta a llm-d y Dynamo con cobertura de motores más amplia y funciones de prefill y decode desagregados, mientras que Kinference se centra actualmente en vLLM y señala SGLang y TensorRT-LLM como motores previstos. Buoyant también diferencia las cifras de rendimiento citadas para esos proyectos, que proceden de otras configuraciones y referencias, por lo que no constituyen una comparación directa entre todos ellos. El valor distintivo que plantea Kinference está en el gobierno de solicitudes y proveedores, además del enrutamiento basado en caché.

Para los equipos que evalúan el proyecto, el punto de partida es reconocer tanto su potencial como su grado de madurez: v0.1.0-alpha.7 sigue siendo una versión temprana. La licencia Apache 2.0 y la configuración en recursos de Kubernetes facilitan probarlo dentro de entornos existentes, pero los resultados publicados no sustituyen ensayos propios con las cargas, modelos y objetivos de servicio de cada organización. Por ahora, la evidencia más favorable se concentra en solicitudes con prefijos compartidos, mientras que el escenario sin ellos no mostró una mejora significativa en la mediana.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados