Kubernetes Inference Perf: compara el stack de serving, no solo el modelo
Kubernetes Inference Perf hace más coherentes las comparaciones entre servidores de modelos, pero sus resultados siguen dependiendo de los prompts, los patrones de carga, el número de tokens y los clústeres.
El proyecto Inference Perf de Kubernetes cuenta ahora con un artículo de software revisado por pares. El Journal of Open Source Software lo publicó el 27 de agosto, ofreciendo a los profesionales una descripción citable de una herramienta diseñada para enviar tráfico de IA generativa realista a través de distintos servidores de modelos y stacks de serving.
Su promesa más útil es la coherencia, no una clasificación universal. Inference Perf puede mantener constantes un generador de carga y un contrato de métricas mientras un equipo cambia el servidor de modelos, el acelerador, el router o la política de Kubernetes. No puede hacer comparables dos ejecuciones cuyos prompts, longitudes de salida, patrones de carga, contadores de tokens, ventanas de calentamiento o ajustes del servidor sean distintos.
Ese límite convierte «agnóstico al servidor de modelos» de adjetivo de marketing en requisito de ingeniería: congela la carga de trabajo, registra todo el stack de serving y compara únicamente la dimensión que el experimento pretendía cambiar.
Inference Perf mide un despliegue, no la inteligencia del modelo
El artículo de JOSS describe un benchmark modular con generación de datos, generación de carga, clientes de servidor, recopilación de métricas, informes JSON y análisis. La documentación actual del proyecto enumera integraciones verificadas para vLLM, SGLang y Hugging Face TGI, además de compatibilidad con endpoints de estilo OpenAI. Puede generar cargas de trabajo de tasa constante, Poisson, concurrentes, en ráfaga, de saturación, con prefijo compartido, multivuelta y reproducción de trazas.
Esas funciones responden a preguntas sobre serving. Pueden mostrar con qué rapidez ve un usuario el primer token, con qué regularidad llegan los siguientes, cuántas solicitudes cumplen un objetivo de latencia, dónde se satura un sistema y si un router o un autoscalador se recupera de un cambio de tráfico. No muestran si la respuesta del modelo es correcta, segura, fundamentada o útil.
La propuesta original de Kubernetes WG Serving dejaba muy claro ese alcance. Quería una herramienta de «benchmark como código» capaz de probar servidores de modelos, aceleradores y orquestación sin estar ligada a un solo stack. Recomendar un servidor o servicio alojado ganador era explícitamente un objetivo que quedaba fuera del proyecto.
El propio grupo de trabajo ha completado desde entonces su mandato. Una actualización del proyecto de CNCF de febrero dice que su trabajo pasó a los grupos de interés especial de Kubernetes y que Inference Perf está patrocinado por SIG Scalability. El software sigue activo: v0.6.1, publicado el 23 de julio, es la última versión etiquetada, mientras la rama principal continúa cambiando. Fijar una versión forma por tanto parte del resultado, no es una tarea de mantenimiento menor.
La pregunta de serving determina la métrica útil
Una cifra de rendimiento oculta varios sistemas distintos. Un benchmark debería comenzar con la promesa al usuario u operador y después elegir la métrica capaz de refutarla.
| Pregunta que debe responder la ejecución | Evidencia principal | Qué debe acompañar al resultado | Qué puede engañar al lector |
|---|---|---|---|
| ¿Cuánto tarda el usuario en ver avances? | Tiempo hasta el primer token (TTFT), especialmente p50 y p95 | Distribución de longitudes de prompt, estado de la caché, concurrencia y tratamiento del calentamiento | Una buena media puede ocultar una cola lenta o la penalización del arranque en frío |
| ¿Qué tan fluida es una respuesta en streaming? | Tiempo por token de salida (TPOT) y latencia entre tokens (ITL) | Longitud de salida, modo de streaming y fuente del recuento de tokens | Salidas más cortas o tokenizadores diferentes pueden fabricar una mejora aparente |
| ¿Cuánto trabajo puede completar el stack? | Solicitudes y tokens de entrada/salida por segundo | Tasa ofrecida, tasa alcanzada, fallos y longitudes de solicitud | Contar solo los éxitos puede ocultar la sobrecarga y el trabajo descartado |
| ¿Qué capacidad cumple el objetivo del producto? | Goodput de solicitudes o tokens bajo restricciones de latencia declaradas | Umbrales exactos de nivel de servicio y política de errores | El rendimiento bruto puede aumentar después de que la latencia útil ya se haya desplomado |
| ¿Ayudaron el enrutamiento o el autoscaling? | Latencia por etapa, rendimiento, goodput, errores y telemetría de infraestructura | Número de réplicas, política de enrutamiento, eventos de escalado, profundidad de la cola y métricas de GPU y servidor | Una instantánea en estado estable puede perderse la transición que la función debía mejorar |
Las definiciones de métricas del proyecto distinguen entre latencia de solicitud de extremo a extremo, TTFT, TPOT, TPOT normalizado e ITL, en lugar de reducirlo todo a «latencia». Su cálculo de goodput cuenta únicamente las solicitudes correctas que cumplen todas las restricciones de latencia configuradas. Eso convierte el goodput en una medida de capacidad más sólida cuando un producto tiene un objetivo real de nivel de servicio.
Incluso una métrica correcta puede tener un denominador equivocado. Inference Perf registra el uso de tokens comunicado por el servidor y la retokenización del lado del cliente, porque ambos pueden discrepar por la sobrecarga de las plantillas de chat, las revisiones del tokenizador, los esquemas de herramientas o el texto transmitido. Sus informes muestran los recuentos de fallback y las discrepancias de tokens. Si una ejecución normaliza el TPOT con recuentos del cliente y otra usa recuentos del servidor, la comparación ya ha cambiado dos cosas.
Tres capas separan la velocidad del servidor del comportamiento del clúster
Una evaluación útil del serving en Kubernetes separa el comportamiento del servidor local del comportamiento del clúster. Combinarlo todo en una sola ejecución puede producir un gráfico impresionante sin revelar qué componente lo causó.
La línea base más limpia mantiene constantes la revisión del modelo, la cuantización, la imagen del servidor, el acelerador, el número de réplicas, la ruta de enrutamiento, la distribución de prompts, el comportamiento de salida y la carga ofrecida. Un barrido de tasas puede revelar entonces el punto en que la latencia o los errores hacen inútil un rendimiento adicional. Las pruebas del router y del autoscalador responden de nuevo a otra pregunta: exponen el retraso de escalado, el crecimiento de la cola, la alteración de la caché, los fallos y la recuperación durante una transición, en vez de medir únicamente el estado estable final.
Repetir las ejecuciones en orden alterno hace más creíble esa separación. Los informes de etapa y por solicitud en bruto, el config.yaml generado, los registros del servidor y del cliente y los eventos del clúster revelan inestabilidades que una mediana o una única mejor ejecución ocultarían.
Inference Perf también puede probar tráfico multivuelta y con prefijo compartido, pero esas cargas necesitan otro control: la admisión de caché y la afinidad del enrutamiento. Una solicitud que llega a una caché de prefijo caliente no es comparable con otra enviada a una réplica fría. Registra los tokens de prompt en caché y sin caché cuando el servidor los exponga, y trata un cambio de enrutamiento que altere los aciertos de caché como un resultado del stack completo, no como un resultado de velocidad pura del servidor.
Una herramienta idéntica no garantiza un trabajo idéntico
La nueva guía de comparabilidad entre herramientas también advierte sobre las comparaciones hechas únicamente con Inference Perf. Las distribuciones predeterminadas de entrada y salida no son longitudes fijas. Las pruebas de tasa en lazo abierto y las pruebas en lazo cerrado con concurrencia fija miden comportamientos distintos. Los parámetros de muestreo, el comportamiento del tokenizador y los ajustes de parada temprana cambian la cantidad de trabajo enviada al servidor.
El calentamiento es un punto especialmente delicado. La guía dice que Inference Perf no tiene una fase específica de calentamiento excluida: mide cada solicitud que envía. Una herramienta que descarta las solicitudes de calentamiento observa una ventana distinta, sobre todo cuando la compilación, las cachés o el autoscaling ralentizan las solicitudes iniciales. Los equipos pueden calentar primero el servidor o usar una etapa inicial corta y excluirla de la comparación, pero el tratamiento elegido debe quedar registrado.
Las comparaciones entre herramientas requieren aún más cuidado. La guía documenta los significados y valores predeterminados de flags que dependen de la versión en otros clientes de benchmark y recomienda comprobar los tokens totales de entrada y salida antes de comparar tasas. Las medias iguales no bastan cuando difieren los mínimos, máximos, espacios entre llegadas o la fuente de los tokens.
Un arnés agnóstico al servidor elimina una fuente de variación. No elimina el diseño experimental.
Una comparación de Kubernetes patrocinada muestra las dos caras del método
Un informe metodológico de Principled Technologies de mayo ofrece un ejemplo concreto. Los evaluadores usaron Inference Perf con Llama 3.1 8B Instruct, vLLM 0.11.0, respuestas en streaming, prompts con prefijo compartido y un barrido de tasas de Poisson. Publicaron los manifiestos del clúster, la configuración de la herramienta, las versiones de software, varias etapas de carga y la regla usada para seleccionar un punto de equilibrio entre rendimiento y latencia.
Ese detalle hace que el experimento sea inspeccionable. También muestra por qué un resultado es inseparable de su configuración: el informe compara sistemas GKE y EKS configurados, no nubes abstractas, Kubernetes genérico ni todas las cargas posibles. El apéndice dice que las pruebas terminaron el 14 de abril y que Google encargó el proyecto. También hace referencia a versiones de Inference Perf anteriores a la versión actual v0.6.1.
El estudio es útil como registro de medición trabajado, no como prueba neutral de que una plataforma será más rápida para otro modelo, región, acelerador, compilación del servidor, distribución de prompts o política de enrutamiento. Reproducir su YAML sin reproducir todo el entorno crearía un experimento nuevo.
Un resultado defendible es una afirmación acotada
Antes de elegir un servidor o una política de clúster, compara el cambio previsto con una línea base sin modificar. Si cambia el servidor de modelos, mantén fijos el modelo, el hardware, el flujo de solicitudes y la ruta de Kubernetes. Si cambia el router, mantén fijas las imágenes del servidor y el conjunto de réplicas. Si cambia el acelerador, revela todos los cambios asociados de software y topología que no se pudieron mantener constantes.
Después, formula la conclusión a la misma escala que el experimento: «la política B mantuvo la carga de trabajo declarada en el umbral p95 en este clúster», no «la política B es más rápida». Combina el resultado de serving con una evaluación de calidad independiente si el cambio puede alterar las salidas y calcula el coste a partir del uso medido de recursos, no solo del precio de lista del acelerador.
El explicador de evaluación de IA muestra por qué la métrica se convierte en parte de la decisión de producto. El análisis de precios de Gemini (en español) añade la misma advertencia desde otra dirección: el rendimiento de tokens no es el resultado empresarial cuando los reintentos y el trabajo rechazado consumen la factura.
La revisión por pares hace que Inference Perf sea más fácil de citar. La razón más sólida para usarlo es práctica: un arnés repetible puede revelar dónde se dobla el stack de serving bajo tráfico real. Sus cifras solo se convierten en evidencia portable cuando la carga de trabajo, el contador, la ventana y el entorno viajan con ellas.
Fuentes
- JOSS: Inference Perf, a benchmarking tool for GenAI inference
- Kubernetes SIGs Inference Perf repository and documentation
- Inference Perf v0.6.1 release
- Inference Perf metric definitions and token-count provenance
- Inference Perf goodput documentation
- Inference Perf cross-tool comparability guide
- Kubernetes WG Serving Inference Perf proposal
- CNCF: Kubernetes WG Serving concludes its work
- Principled Technologies GKE inference study methodology