Ingenieria de rendimiento de IA: una escalera de evidencia de rendimiento de GPU a produccion para cuellos de botella de inferencia

Por que la utilizacion de GPU no es un diagnostico de rendimiento

Un servicio de inferencia en GPU puede parecer saludable en un panel y aun asi sentirse lento para los usuarios. El dispositivo esta ocupado. Las solicitudes estan esperando. La latencia de cola se esta desviando. Los reintentos consumen capacidad. Algunas salidas nunca superan la aceptacion del producto. Todos esos hechos pueden ser ciertos al mismo tiempo.

La utilizacion de GPU suele ser la metrica principal menos util en un incidente de inferencia. Indica que el hardware hizo trabajo. No indica si el trabajo correcto se completo dentro de las reglas de carga de trabajo y calidad que el producto necesita.

El mapa de recursos Wafer AI Performance Engineering V2 ayuda porque recopila las capas que los equipos suelen tener que razonar, desde ejecucion y perfilado CUDA hasta kernels, sistemas de servicio y comunicacion distribuida. Un mapa de recursos sigue sin ser un metodo de aceptacion. Los equipos necesitan una ruta desde el sintoma hasta la evidencia, y luego desde la evidencia hasta un cambio de produccion con un plan de rollback.

Para inferencia en produccion, la unidad practica son las tareas aceptadas bajo un contrato de carga de trabajo definido. Eso significa que p50, p95, p99, tiempo hasta el primer token, latencia entre tokens, tiempo de cola, longitud de prompt, longitud de salida, concurrencia, batching, tasa de error, tasa de reintentos, tasa de aceptacion y costo por tarea aceptada deben avanzar juntos en el analisis. Los tokens por segundo brutos tienen su lugar en una ejecucion de laboratorio. En produccion, una ruta mas rapida que causa mas reintentos o falla las comprobaciones de aceptacion es peor, no mejor. Una latencia media mas baja tambien puede ocultar una cola rota.

Esta misma postura centrada en evidencia aparece en guias de infraestructura relacionadas de Optijara, incluida la prueba de aceptacion de ruta AI-in-RAN, la prueba de aceptacion checkpoint-to-bundle de TensorRT Model Connect y la guia QRAT de Qwen3.8-27B. El principio aqui es el mismo. Defina el paquete de evidencia antes de cambiar el sistema. Para productos de IA orientados a busqueda, la disciplina tambien se combina con la actualizacion de spam de Google de agosto y lista de comprobacion GEO de Optijara, donde las afirmaciones respaldadas por fuentes importan mas que una puntuacion unica ordenada.

La Performance Evidence Ladder (PEL) de Optijara

La Performance Evidence Ladder de Optijara, o PEL, es un metodo de diagnostico de cinco etapas para trabajo de inferencia de GPU a produccion. Existe para detener un patron de fallo comun: alguien ve un sintoma, elige su solucion favorita y luego busca metricas que hagan que la solucion parezca razonable. PEL ralentiza eso lo suficiente para poner la evidencia en el orden correcto.

Etapa 1: Traza de solicitud y carga de trabajo

Empiece donde el usuario siente el sistema. Capture la tasa de llegada de solicitudes, bandas de concurrencia, distribucion de longitud de prompt, distribucion de longitud de salida, comportamiento de batching, tiempo de cola, tiempo hasta el primer token, latencia entre tokens, p50, p95, p99, fallos, reintentos y estado de aceptacion. Si el servicio maneja diferentes tipos de tareas, separelos. Las llamadas de recuperacion, los flujos de trabajo que usan herramientas, el chat en streaming y las solicitudes de contexto largo pueden tocar limites diferentes.

La salida es un contrato de carga de trabajo. Establece que se sirve, bajo que restricciones y que cuenta como aceptado. Sin el, la evidencia posterior de GPU puede hacer mas rapida la ruta equivocada.

Etapa 2: Evidencia de ejecucion y memoria de GPU

La etapa 2 pregunta que estan haciendo realmente el dispositivo y el host. La documentacion de CUDA proporciona el modelo mental para ejecucion, jerarquia de hilos, jerarquia de memoria y sincronizacion. Nsight Systems ayuda a los equipos a inspeccionar actividad de CPU, llamadas a la API CUDA, kernels de GPU, operaciones de memoria y huecos entre ellos en una sola linea de tiempo.

No persiga una barra de actividad mas ocupada. Busque causas. Un hueco entre kernels no es lo mismo que presion de ancho de banda de memoria. Un retraso de sincronizacion no es lo mismo que un kernel lento. La admision de solicitudes del lado del host no es ejecucion del lado del dispositivo. La etapa 2 debe nombrar la clase de evidencia antes de que alguien reescriba kernels o cambie controles de servicio.

Etapa 3: Evidencia de kernels y operadores

La etapa 3 pasa de lineas de tiempo a operadores y kernels. PyTorch profiler puede mostrar rutas de operadores, tiempo de CPU y CUDA, comportamiento de memoria y trazas que revelan que operaciones del modelo dominan una ejecucion. Los diagnosticos de PyTorch compile importan cuando la captura de grafo, la fusion o el comportamiento de fallback cambian la ruta de ejecucion. Triton entra en escena cuando un equipo necesita inspeccionar kernels personalizados, formas de tile, movimiento de memoria y el limite entre la logica de nivel Python y el trabajo de nivel dispositivo.

Aqui pertenecen la intensidad aritmetica, la presion de ancho de banda de memoria, la fusion de operadores, las rutas de cuantizacion y los patrones de lanzamiento de kernels. Tambien es donde ocurren errores costosos. La cuantizacion, la compilacion y los kernels personalizados pueden cambiar el comportamiento de salida, la observabilidad, las propiedades numericas y el costo de rollback. Pruebe el candidato contra la aceptacion de tareas, no solo contra una traza de latencia.

Etapa 4: Evidencia de planificacion del motor de inferencia y cache

La etapa 4 observa el motor de servicio. Sistemas como vLLM exponen metricas sobre solicitudes, tokens, comportamiento del planificador, estado de cache y colas. Esa capa importa porque servir LLM no es solo ejecucion del modelo. Incluye prefill, decode, batching continuo, admision de solicitudes, presion de KV cache, mezcla de longitud de prompts y salidas, comportamiento frio, comportamiento caliente y decisiones del planificador.

Un tiempo alto hasta el primer token puede venir de colas, costo de prefill, arranques frios, control de admision o estado de cache. Una latencia alta entre tokens puede venir del comportamiento de decode, presion de memoria, eficiencia de kernels, planificacion o comunicacion. PEL mantiene esas hipotesis separadas hasta que la evidencia apunta a una.

Etapa 5: Evidencia de servicio distribuido y capacidad

La etapa 5 aplica cuando una GPU no es todo el sistema. La inferencia distribuida puede incluir paralelismo tensorial, paralelismo de pipeline, colectivas, movimiento de red, capacidad a nivel de nodo, colocacion, transferencia de datos y dominios de fallo. La documentacion de NCCL importa aqui porque las colectivas y el comportamiento de comunicacion pueden convertirse en parte de la ruta de servicio.

En este punto, el paquete de aceptacion debe incluir alcance de canary, disparador de rollback, condiciones de parada y evidencia de capacidad. Un cambio de topologia no se acepta porque un benchmark mejora. Se acepta cuando el contrato de carga de trabajo, la latencia de cola, los errores, los reintentos, los criterios de aceptacion y el riesgo operativo se mantienen dentro de los limites acordados.

Una matriz de decision de cuellos de botella para inferencia en produccion

Detenga el perfilado una vez que cuatro cosas sean ciertas: el cuello de botella se reproduce, la capa responsable esta identificada, el impacto en la aceptacion es visible y el umbral de rollback esta definido. El perfilado puede cambiar el comportamiento de la carga de trabajo, asi que mas trazado no es automaticamente mejor. El punto de parada correcto es evidencia suficiente para tomar una decision sin fingir que la traza es el producto.

Lista de comprobacion de implementacion: de ejecucion de benchmark a cambio aceptado en produccion

Mantenga separadas las comparaciones frias, calientes y de canary. Las ejecuciones frias exponen efectos de inicio, compilacion, llenado de cache o carga de modelo. Las ejecuciones calientes muestran comportamiento de estado estable bajo el contrato de carga de trabajo. Las ejecuciones de canary responden la pregunta de produccion: se comporta este candidato lo suficientemente bien con trafico real sin exponer toda la carga de trabajo a un riesgo evitable?

Evidencia especifica de herramientas: donde encaja cada fuente en PEL

La documentacion de CUDA respalda la etapa 2 porque proporciona el modelo para hilos, bloques, jerarquia de memoria, sincronizacion y comportamiento de ejecucion. Nsight Systems respalda la misma etapa desde un angulo de linea de tiempo, especialmente cuando los equipos necesitan ver juntos trabajo de CPU, kernels de GPU, API CUDA, operaciones de memoria y huecos.

PyTorch profiler respalda la etapa 3 al hacer visible el comportamiento a nivel de operador. Los diagnosticos de PyTorch compile pueden importar cuando una ruta compilada cambia el comportamiento del grafo, la fusion o las rutas de fallback. Triton encaja en la etapa 3 cuando los operadores estandar no son suficientes o cuando una ruta de kernel personalizado necesita inspeccion. Eso no significa que todo cuello de botella merezca un kernel personalizado. PEL pide a los equipos que prueben primero que el cuello de botella vive en esa capa.

Las metricas de vLLM encajan en la etapa 4 porque el comportamiento de servicio a menudo explica sintomas que las metricas a nivel de GPU no pueden. El estado del planificador, el comportamiento de cache, las metricas de solicitudes, las metricas de tokens y las colas pueden mostrar si el problema es admision, batching, prefill, decode o presion de cache. NCCL encaja en la etapa 5 cuando la comunicacion distribuida es parte de la ruta de servicio.

Que suelen equivocar los equipos al optimizar inferencia en GPU

Tratar la utilizacion como la respuesta

La utilizacion es facil de observar y facil de sobreinterpretar. No le dice a un equipo si los usuarios estan en cola, si la latencia p99 es aceptable, si los reintentos estan aumentando o si la tarea fue aceptada. Usela como una senal en la etapa 2, no como la metrica principal.

Optimizar tokens de benchmark en lugar de tareas aceptadas

Los tokens por segundo pueden ayudar dentro de un experimento controlado, pero los sistemas de produccion completan tareas. Una ruta que emite tokens rapidamente mientras falla comprobaciones de aceptacion, aumenta errores o requiere mas reintentos no es mejor. El rendimiento de tareas aceptadas es la unidad mas segura orientada al negocio.

Cambiar batching sin proteger la latencia de cola

El batching y el batching continuo pueden mejorar el uso de hardware en algunas cargas de trabajo. Tambien interactuan con el tiempo de cola, TTFT, longitud de salida y p99. Evalua un cambio de batching por tipo de tarea y banda de concurrencia, no solo por rendimiento agregado.

Ignorar la obsolescencia de cache y la deriva de carga de trabajo

El comportamiento de KV cache, las distribuciones de prompts, las longitudes de salida y los patrones de recuperacion pueden derivar. Una ejecucion que se ve bien en una carga de trabajo antigua puede fallar cuando cambia la mezcla de solicitudes. Mantenga los contratos de carga de trabajo versionados y repetibles.

Perfilar de maneras que cambian la carga de trabajo

El perfilado anade sobrecarga y puede alterar el tiempo. Eso no hace que el perfilado sea inutilizable. Significa que la sobrecarga debe etiquetarse, las ejecuciones perfiladas y no perfiladas deben compararse con cuidado, y el comportamiento de la traza no debe tratarse como el estado natural del sistema.

Advertencias y trade-offs: el trabajo de rendimiento es un sistema de ingenieria

La evidencia de rendimiento reduce las conjeturas, pero no elimina el costo de implementacion. La instrumentacion lleva tiempo. La recoleccion de trazas puede plantear problemas de privacidad y seguridad porque prompts, salidas, identificadores y metadatos operativos pueden ser sensibles. Los registros deben minimizarse, controlarse por acceso y conservarse solo el tiempo necesario.

La optimizacion tambien puede afectar la calidad. La cuantizacion puede cambiar el comportamiento de salida. La compilacion puede alterar rutas de ejecucion. Los cambios de kernel pueden crear problemas de correccion o portabilidad. Los cambios de planificador y cache pueden desplazar latencia entre tipos de solicitud. Los cambios de topologia distribuida pueden mejorar una ruta mientras anaden costo de comunicacion o complejidad operativa en otra parte.

La varianza de proveedor, hardware, driver, framework y modelo importa. La evidencia de un entorno no debe copiarse a otro como resultado garantizado. PEL hace explicitas esas suposiciones en lugar de ocultarlas detras de una media confiada. El costo por tarea aceptada puede ser util, pero solo cuando la atribucion de costos esta definida.

PEL en la practica: un flujo compacto de evidencia y resumen legible por maquina

{
  "framework": "Optijara Performance Evidence Ladder",
  "stages": [
    {"stage": 1, "name": "request_trace", "signals": ["p50", "p95", "p99", "TTFT", "queue_time", "acceptance_rate"]},
    {"stage": 2, "name": "gpu_execution_memory", "signals": ["kernel_gaps", "memory_movement", "occupancy", "synchronization"]},
    {"stage": 3, "name": "kernel_operator", "signals": ["operator_time", "arithmetic_intensity", "bandwidth_pressure", "compile_path"]},
    {"stage": 4, "name": "serving_scheduler_cache", "signals": ["prefill", "decode", "KV_cache", "batching", "admission"]},
    {"stage": 5, "name": "distributed_capacity", "signals": ["collectives", "network_movement", "placement", "canary", "rollback"]}
  ],
  "acceptance_unit": "cost_per_accepted_task_under_workload_contract",
  "stop_conditions": ["reproduced_bottleneck", "owner_layer_identified", "acceptance_impact_visible", "rollback_threshold_defined"]
}

La pregunta de trabajo para PEL es directa: que capa limita las tareas aceptadas, que evidencia lo prueba y que cambio de produccion puede enviarse con un plan de rollback claro? Si la respuesta sigue siendo "la GPU esta ocupada," el diagnostico no esta terminado.