Un planificador decide dónde fusionar el trabajo en la GPU
One Megakernel is Not Enough: Predicting Where to Cut for Streaming Inference · arXiv:2610.35336
En palabras sencillas
Los modelos de ejecución continua producen resultados por etapas, y cada etapa puede funcionar mejor con ajustes distintos de la GPU. Combinar etapas en un kernel persistente puede reducir el coste de lanzar kernels, pero un kernel enorme también puede resultar poco adecuado.
El artículo presenta un planificador que usa mediciones existentes y un modelo de cuándo pueden ejecutarse las etapas y publicar resultados para elegir qué etapas combinar. En una GPU, seleccionó el diseño medido más rápido en los 13 casos probados de modelo y tamaño de lote, dentro de los diseños que los autores habían implementado y comprobado.
La investigación
Cuando un modelo de ejecución continua produce su primera salida, ¿cómo conviene agrupar sus fases en la GPU? Las fases pueden avanzar a ritmos distintos y preferir distintas configuraciones de lanzamiento, y la publicación puede depender del trabajo de más de una fase.
Por eso, no es evidente dónde conviene poner los límites de fusión con solo mirar las etapas del modelo.
El planificador combina perfiles existentes, mediciones compatibles de kernels y una simulación de dependencias de salida para ordenar diseños de fusión compatibles sin medir cada uno de principio a fin.
El planificador combina perfiles existentes, mediciones compatibles de kernels y una simulación de dependencias de salida para ordenar diseños de fusión compatibles sin medir cada uno de principio a fin.
En una GPU H100 NVL, su elección fijada de antemano coincidió con el diseño medido más rápido en los 13 casos probados de modelo y tamaño de lote, comparando los diseños implementados y validados para cada modelo. El resultado respalda el método de ordenación dentro de esos conjuntos de validación.
El resultado de 13 de 13 se aplica a los diseños que los autores implementaron y validaron en una GPU H100 NVL. No establece cuál sería la mejor opción entre diseños no medidos ni en otras arquitecturas de GPU.
Qué muestran las pruebas
- Fusionar implica elegir límites
El planificador de límites que tiene en cuenta la primera publicación sirve para decidir qué regiones contiguas de un modelo de ejecución continua fusionar en megakernels, cuáles ejecutar de manera convencional y cómo deben compartir la GPU.
La pregunta importa porque las fases pueden avanzar a ritmos distintos y preferir distintas configuraciones de lanzamiento, mientras que la primera salida puede depender de más de una fase. La elección de los límites afecta tanto al uso de recursos de GPU como al momento en que se puede publicar la salida.
- Ordena composiciones compatibles
En vez de medir cada diseño candidato completo, el planificador combina perfiles de ejecución convencional, mediciones de operaciones o pasos y detalles de implementación declarados en el código fuente.
Usa mediciones compatibles para estimar costes de ejecución, construye composiciones candidatas compatibles y simula cómo avanzan las tareas y las dependencias de publicación. Excluye los candidatos sin datos de costes compatibles, así que solo ordena los diseños que puede admitir.
- En un caso, ganan tres megakernels
La comparación de NH-TTS con tamaño de lote 32 muestra por qué importan tanto el alcance de la fusión como el solapamiento. En una GPU H100 NVL, un diseño de tres megakernels con trabajo solapado publicó el primer audio 4.05 veces antes que la ejecución convencional con TensorRT y un 21.4% antes que un solo megakernel.
Estas mediciones muestran que, en este caso, ni la ejecución convencional ni la fusión de todo el modelo fueron el diseño probado más rápido.
- Las selecciones coinciden con los mejores diseños medidos
Los autores probaron 13 casos de modelo y tamaño de lote en una GPU H100 NVL, con tres modelos y tres marcos de trabajo. En cada caso, la elección fijada de antemano por el planificador coincidió con el diseño medido más rápido del conjunto de validación de diseños implementados y validados para ese modelo.
Esto respalda su capacidad de seleccionar entre esos candidatos medidos; no demuestra que los conjuntos incluyeran todas las composiciones posibles.
- Importan el solapamiento y el tamaño del lote
Dos controles usaron los mismos costes de ejecución y conjuntos de candidatos, pero reemplazaron la simulación de eventos por una puntuación aditiva o eliminaron el solapamiento. Cada uno coincidió con 11 de los 13 mejores diseños medidos y no acertó en NH-TTS con tamaños de lote 32 y 64, donde eligió la ejecución en serie.
Por separado, Qwen3-TTS favoreció cuatro megakernels hasta el tamaño de lote 32, pero la ejecución convencional con tamaños 48 y 64. Estos resultados respaldan que el papel del solapamiento y el alcance útil de la fusión dependen del caso.
Detalles
- Autores del paper original
- Aditya Chatterjee, Anand Joseph X M, Sanjay Singh Chauhan
- Enviado a arXiv
- Licencia
- CC BY 4.0