¿Qué causa las brechas en la utilización de la GPU durante el procesamiento por lotes continuo de LLM?
Las brechas en la utilización de la GPU suelen aparecer cuando el planificador de batching continuo no puede reunir trabajo ejecutable o alimentar el acelerador sin un bloqueo por dependencia.
Un servidor LLM doméstico puede informar un alto rendimiento y, aun así, mostrar valles periódicos de uso de la GPU entre iteraciones de decodificación. El batching continuo elimina las secuencias finalizadas y admite otras nuevas, pero no puede crear trabajo cuando las llegadas son escasas, los bloques KV no están disponibles, los prefills largos bloquean la decodificación o el tiempo de ejecución de la CPU prepara los lotes con demasiada lentitud. La sincronización y el movimiento de memoria también pueden generar brechas incluso con una cola de solicitudes llena.
El suministro de solicitudes y la rotación de secuencias pueden vaciar un lote
El batching continuo reemplaza las secuencias finalizadas en los límites de cada iteración. Si las llegadas son intermitentes, las salidas terminan al mismo tiempo o los límites de admisión mantienen las solicitudes fuera de la cola ejecutable, el recuento de tokens activos puede caer por debajo del rango de funcionamiento eficiente de la GPU.
Las pruebas de membresía de lotes continuos comparan la membresía estática y continua de solicitudes con distintas longitudes de entrada, longitudes de salida y tiempos de llegada. El patrón característico es un recuento bajo de tokens ejecutables durante las brechas de utilización, a pesar de que el acelerador funciona correctamente y no hay errores de memoria.
Una cola realmente vacía no es un defecto del planificador. Compara la tasa de llegada, las secuencias admitidas y los tokens programados por iteración antes de interpretar cada intervalo inactivo como capacidad perdida. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.
El prefill, la decodificación y la asignación de KV crean huecos en el planificador
El prefill procesa muchos tokens del prompt con kernels que requieren mucho cómputo, mientras que la decodificación avanza cada secuencia un token y suele estar limitada por la memoria. Mezclar ambas fases puede retrasar la decodificación, y reservar o recuperar bloques KV puede pausar la admisión entre iteraciones.
El diseño de programación de prefill por fragmentos utiliza un prefill dividido en fragmentos para evitar que los prompts largos monopolicen las iteraciones de servicio. Su mecanismo identifica brechas que se correlacionan con los límites del prefill, la asignación de KV o la expulsión preventiva de solicitudes, en lugar de con una demanda débil. El resultado intermedio debe seguir siendo inspeccionable antes de continuar con la automatización.
Si las brechas de la GPU aumentan con la longitud del prompt, pero no con la longitud de salida, la programación del prefill es la causa más probable. Si siguen la presión de la caché o las expulsiones, la admisión de memoria es la responsable, incluso cuando la cola permanece llena. Ese límite debe medirse por separado en condiciones operativas realistas.
La alimentación desde la CPU y la sincronización entre dispositivos pueden dejar los kernels sin trabajo
La tokenización, el muestreo, las decisiones del planificador, los metadatos de los tensores, las copias del host al dispositivo, las operaciones colectivas distribuidas y el registro ocurren fuera de los kernels principales. Un hilo de la CPU saturado o una sincronización bloqueante puede dejar a la GPU esperando entre lotes que, por lo demás, son válidos. La consecuencia práctica aparece cuando varias fuentes compiten por un contexto limitado.
La investigación sobre la interferencia entre prefill y decodificación separa los recursos de prefill y decodificación para reducir las interferencias y cumplir los objetivos de latencia. El resultado refuerza que un único gráfico de utilización combina el comportamiento del planificador, el host, la comunicación y el acelerador. Esta dependencia debe permanecer explícita en la interfaz final.
El límite del fallo es un intervalo de muestreo corto que informa como cero una utilización correspondiente a límites normales de los kernels. Confirma las brechas con una traza o con contadores de hardware; el promedio del panel puede crear valles aparentes que no reducen los tokens por segundo.
Alinea las líneas temporales de la cola, el planificador y los kernels
Reproduce llegadas controladas, estables y con ráfagas, mientras registras las solicitudes en espera, admitidas y en ejecución, los tokens de prompt y de decodificación por iteración, los bloques KV libres, las expulsiones preventivas, el tiempo del planificador de la CPU, la tokenización, el muestreo, las copias, las operaciones colectivas, las brechas entre lanzamientos de kernels, las frecuencias de la GPU y el rendimiento de salida.
Compara el patrón con el comportamiento del batching continuo y, después, modifica individualmente la tasa de llegada, la longitud del prompt, el tamaño del prefill por fragmentos, el presupuesto de caché y la afinidad de la CPU. Mantén constantes el modelo, la cuantización y el objetivo de latencia. Por lo tanto, el resultado debe comprobarse con las pruebas originales.
Clasifica cada valle como ausencia de demanda, bloqueo de admisión, interferencia del prefill, presión de la caché, falta de recursos del host o sincronización antes de ajustar nada. Optimiza el límite responsable; forzar un lote más grande no puede solucionar una cola vacía ni un hilo del host bloqueado.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Qué hace que un planificador de agentes de IA repita pasos que ya completó?
Rastrea los pasos repetidos del planificador mediante la persistencia del estado, la evidencia de finalización, el análisis de los resultados de las herramientas, la...
¿Qué causa errores de permisos solo dentro de los subprocesos de agentes de IA?
Compare la identidad del proceso principal y del proceso secundario, la vista del sistema de archivos, el entorno, las capacidades, la política de seguridad...
¿Qué causa la saturación de la CPU cuando se ejecutan simultáneamente la transcodificación por hardware y la IA de vídeo?
Rastrea la saturación de la CPU en la descarga de códecs, la conversión de píxeles, las copias de fotogramas, el preprocesamiento de IA, el...
