Buoyant, la empresa que desarrolla Linkerd, ha publicado Kinference, un proyecto open source destinado a construir plataformas de inferencia en Kubernetes. Colocado delante de un conjunto de servidores vLLM, decide, para cada solicitud, hacia qué servidor se envía. El proyecto se distribuye bajo licencia Apache 2.0 en GitHub, en su versión v0.1.0-alpha.7.
- Buoyant publica Kinference, un plan de control open source para la inferencia en Kubernetes con vLLM.
- Kinference elige, para cada solicitud, el servidor vLLM que la atiende, teniendo en cuenta la caché KV.
- Según Buoyant, el TTFT mediano baja de 6,88 s a 0,31 s con prefijo compartido, y el rendimiento útil se multiplica por 7,4 frente a un enrutamiento aleatorio.
- El proyecto sigue en fase alfa, y la limitación de tasa, los clasificadores y la compatibilidad con la API de Anthropic aún no están disponibles.
Una capa de control sobre vLLM
Kinference combina Kubernetes, la plataforma de orquestación de contenedores, y vLLM, el motor que ejecuta los modelos de lenguaje. Según la FAQ de Buoyant, vLLM constituye el plano de datos, mientras que Kinference actúa como plano de control. En una misma capa, aplica políticas de enrutamiento, límites de tasa en tokens, un balanceo de carga que tiene en cuenta la caché KV, es decir, la memoria que conserva los cálculos ya realizados, así como métricas por inquilino.
El sistema comprende dos elementos: una puerta de enlace de tráfico y un gestor de inferencia. Este último expone una interfaz gRPC, recibe una solicitud y devuelve el punto de conexión seleccionado, así como el cuerpo de la solicitud eventualmente modificado. Funciona con un proxy, como la Buoyant Gateway. Kinference supervisa los eventos de la caché KV y las métricas del motor, y se apoya en el crate dynamo-kv-router de NVIDIA para procesar estos eventos. Su configuración se basa en cinco recursos de Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider e InferenceWorkerSet.
Las políticas de inferencia son reglas declarativas que precisan cómo se enruta o se rechaza cada solicitud. Pueden basarse en el inquilino, el modelo solicitado, el estado de los pools de GPU o etiquetas semánticas. El sitio del proyecto presenta varios ejemplos, como el envío de solicitudes simples hacia un modelo más pequeño, o el recurso a un proveedor en la nube como Bedrock cuando un servidor tiene más de 2 solicitudes en espera. Las políticas se almacenan en git y pueden validarse fuera de línea con la herramienta de línea de comandos kinfctl.
Resultados medidos por Buoyant
Buoyant comparó Kinference con el simple balanceo de carga de Kubernetes. Cada configuración utilizaba tres pods vLLM 0.31.0, cada uno en una GPU L40S, con el modelo Qwen3.8-27B-FP8. En un tráfico que comparte un mismo prefijo, la latencia mediana antes del primer token (TTFT) pasa, según Buoyant, de 6,88 s a 0,31 s, es decir, una disminución de aproximadamente el 95 %. Sin prefijo compartido, las cifras son de 6,92 s frente a 6,83 s, sin diferencia significativa según el editor.
En una prueba de capacidad, el rendimiento útil, medido en solicitudes por minuto que respetan un objetivo de TTFT, alcanza 103,0 frente a 14,0 solic/min en el tráfico con prefijo compartido, es decir, aproximadamente 7,4 veces más. Estas cifras son auto-declaradas. La referencia es un enrutamiento aleatorio, y no otro enrutador que tenga en cuenta la caché, como llm-d o Dynamo. Buoyant precisa además que sus umbrales de 8 s y 4 s convienen más a agentes fuera de línea que a chatbots. La tabla comparativa publicada con el artículo presenta el ángulo distintivo de Kinference como la gobernanza, es decir, las políticas, los alias de modelos, las conmutaciones por error a proveedores y la contabilidad por inquilino, mientras que llm-d y Dynamo se describen como más eficaces en el servicio bruto.
El proyecto sigue en fase alfa. La limitación de tasa, los clasificadores y la compatibilidad con la API de Anthropic aún no están disponibles.
