💻 computer science

High-Performance FP16 General Matrix Multiplication on NVIDIA Ada Lovelace via CUTLASS and WMMA: A Benchmark and Pipeline-Depth Analysis

Este artículo evalúa el rendimiento de GEMM en FP16 en la NVIDIA RTX 4060 de arquitectura Ada Lovelace a través de cuBLAS, CUTLASS e implementaciones personalizadas de WMMA, revelando que una profundidad de segmentación de tres con una geometría de tesela específica alcanza el 52,7% del rendimiento máximo, al tiempo que demuestra que la presión sobre la memoria compartida, en lugar de la profundidad de la segmentación, es el principal cuello de botella que limita una mayor optimización.

Autores originales: Lucas Lima Freitag

Publicado 2026-07-15

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Lucas Lima Freitag

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes una cocina superrápida (una GPU) con un equipo de chefs especializados llamados Tensor Cores. Estos chefs son increíblemente rápidos picando y mezclando ingredientes (multiplicación de matrices) para un banquete gigante (aprendizaje profundo). La cocina en la nueva estufa "Ada Lovelace" (una tarjeta gráfica RTX 4060) es teóricamente capaz de servir 60.55 TFLOPS (eso es 60.55 billones de operaciones matemáticas por segundo).

Pero aquí está el truco: el hecho de que los chefs puedan picar así de rápido no significa que lo estén haciendo. A menudo tienen que esperar a que los ingredientes sean entregados desde la despensa.

El Gran Experimento: Cómo mantener a los chefs ocupados

Los investigadores querían averiguar la mejor manera de organizar la cocina para que los chefs nunca dejen de picar. Probaron tres formas diferentes de dirigir la cocina:

La Caja Negra (cuBLAS): Una receta preempaquetada y de código cerrado de NVIDIA que suele funcionar de maravilla, pero que no te permite retocar los detalles.
El Plano Abierto (CUTLASS): Un kit de herramientas flexible y de código abierto que te permite construir tu propia disposición de cocina desde cero.
El Enfoque DIY (WMMA): Una cocina construida a medida donde controlas cada uno de los movimientos de los chefs, pero es mucho más difícil de construir.

Configuraron un desafío de cocina masivo con ingredientes de tamaño 8192 × 8192 y probaron diferentes "profundidades de pipeline". Piensa en la profundidad del pipeline como el número de bandejas de ingredientes que la cocina mantiene listas.

Profundidad de Pipeline 2: Solo 2 bandejas listas.
Profundidad de Pipeline 3: 3 bandejas listas.
Profundidad de Pipeline 4: 4 bandejas listas.

La sabiduría común (y un modelo matemático simple) sugería que más bandejas = más velocidad. La lógica era: "Si tenemos más bandejas, los chefs nunca se quedarán sin ingredientes, por lo que trabajarán más rápido".

La Sorpresa: Más no siempre es mejor

Los investigadores midieron la velocidad y esto es lo que encontraron:

Profundidad 2: La cocina funcionó a 25.6 TFLOPS. Los chefs estaban esperando demasiado tiempo.
Profundidad 3: La cocina se aceleró hasta los 31.9 TFLOPS (que es el 52.7% del máximo teórico). ¡Este fue el punto ideal!
Profundidad 4: La cocina en realidad se ralentizó a 31.1 TFLOPS.

Este es el hallazgo principal: Añadir una cuarta bandeja no ayudó; empeoró las cosas. El modelo matemático simple predijo que la velocidad debería haber saltado a 35.4 TFLOPS, pero no fue así. El modelo estaba equivocado por un 13.8%.

¿Por qué el añadir una bandeja salió mal?

El artículo explica que la cocina tiene un espacio limitado. Cuando añadieron la 4ª bandeja (aumentando el uso de la "Memoria Compartida" a 96 KB), esto obligó a la cocina a reducir el número de equipos de cocina (threadblocks) que podían trabajar al mismo tiempo.

Con 3 bandejas, la cocina podía albergar 2 equipos de chefs en cada estufa.
Con 4 bandejas, la cocina solo podía albergar 1 equipo.

Incluso aunque el equipo único tenía más ingredientes, tenían que esperar más tiempo porque había menos equipos para intercambiar cuando uno se quedaba atascado. La cocina se volvió "abarrotada" de ingredientes pero "vacía" de trabajadores. Los investigadores midieron que la "ocupación" (cuántos equipos están trabajando) cayó, y los chefs tuvieron que usar más "registros" (sus libretas personales), lo que también los ralentizó.

Los Ganadores y Perdedores

El Ganador: El kit de herramientas CUTLASS con 3 bandejas y un tamaño de tile específico de 256 × 128. Alcanzó 31.9 TFLOPS. Esto fue tan bueno que de hecho superó a la "Caja Negra" estándar (cuBLAS) por un margen mínimo, casi imperceptible, del 1.3% (que los autores dicen que es probablemente ruido, pero demuestra que el plano abierto puede igualar al cerrado).
El Segundo Lugar DIY: El kernel personalizado WMMA (la cocina totalmente DIY) logró 25.1 TFLOPS en una prueba ligeramente más pequeña. Fue más lento porque no utilizó los trucos de "doble buffering" para superponer la entrega de ingredientes con la cocción.
El Perdedor: La idea de que "más profundidad de pipeline es siempre mejor". El artículo descarta explícitamente esto para este hardware específico.

¿Qué tan seguros están?

Los autores están muy seguros de estos números porque los midieron directamente en el hardware, ejecutando la prueba 10 veces y promediando los resultados. Incluso contrastaron sus cálculos con una herramienta integrada de NVIDIA (el profiler) y descubrieron que su código personalizado coincidía perfectamente con ella.

Sin embargo, admiten algunas cosas que no demostraron:

Solo probaron un tamaño específico de problema (8192). No saben si la regla de "3 bandejas es lo mejor" se mantiene para problemas más pequeños o de formas extrañas.
No pudieron probar profundidades de pipeline superiores a 4 porque la cocina simplemente se quedó sin espacio (memoria).
Tuvieron que realizar sus pruebas en Windows, donde un error del controlador impidió que compararan su código personalizado y el código estándar en la misma ejecución (aunque lo hicieron en ejecuciones separadas).

La Conclusión

Si estás intentando sacar el máximo provecho de una tarjeta gráfica de consumo como la RTX 4060 para tareas intensivas de matemáticas, no sigas añadiendo más buffers sin más. Existe una zona "Goldilocks" (ni muy fría ni muy caliente). En este caso, 3 etapas de preparación fueron perfectas. Ir a 4 etapas hizo que la cocina estuviera demasiado congestionada, ralentizando a todo el mundo.

Los investigadores han publicado todo su código como código abierto, para que cualquiera pueda intentar construir su propia cocina y ver si puede batir el récord de 31.9 TFLOPS. Sugieren que el trabajo futuro debería centrarse en diferentes tamaños de problemas y utilizar Linux para obtener datos aún más limpios, pero por ahora, han demostrado que 31.9 TFLOPS es el pico actual para esta configuración, y que 31.1 TFLOPS es lo que sucede cuando intentas ser demasiado codicioso con la memoria.

Resumen Técnico: GEMM FP16 de Alto Rendimiento en NVIDIA Ada Lovelace mediante CUTLASS y WMMA

Planteamiento del Problema
La Multiplicación de Matrices Generalizada (GEMM) es la base computacional del aprendizaje profundo y la computación científica. Si bien la arquitectura NVIDIA Ada Lovelace (específicamente la RTX 4060 de grado de consumo con el chip AD107) ofrece un rendimiento pico teórico de FP16 de 60.55 TFLOPS de Tensor Cores, lograr un rendimiento cercano al pico requiere una orquestación intrincada de la jerarquía de memoria de la GPU. El desafío radica en equilibrar las estrategias de segmentación (tiling), la profundidad del pipeline de software y la ocupación de los bloques de hilos para saturar los Tensor Cores sin verse limitado por la presión de la memoria compartida o las restricciones de los registros. La literatura previa ha caracterizado extensamente la GEMM a nivel de perfilador de biblioteca, pero existe una brecha en la evaluación sistemática del impacto de profundidades de pipeline arbitrarias y geometrías de teselas utilizando la API de nivel de dispositivo de CUTLASS en hardware de consumo.

Metodología
Los autores realizaron un benchmark sistemático de operaciones GEMM FP16→FP32 en una NVIDIA RTX 4060 (Ada Lovelace) ejecutando Windows 11 con CUDA 13.1. El estudio comparó tres niveles de implementación:

cuBLAS: La biblioteca de código cerrado optimizada por el fabricante, utilizada como referencia.
CUTLASS Device-Level API: Una biblioteca de plantillas C++ de código abierto que permite la personalización en tiempo de compilación de las dimensiones de las teselas, la profundidad del pipeline ( $S$ ) y la vectorización del epílogo.
Kernel WMMA Personalizado: Un kernel ajustado manualmente utilizando la API de Warp Matrix Multiply Accumulate (WMMA) de CUDA para validación pedagógica.

Los experimentos se centraron en un tamaño de problema fijo de $N = 8192$ ( $M=N=K=8192$ ). La metodología incluyó:

Variación de la Profundidad del Pipeline: Pruebas de configuraciones de CUTLASS con profundidades de pipeline $S=3$ y $S=4$ utilizando teselas de bloque de hilos de $256 \times 128$ y $128 \times 128$ .
Modelado Analítico: Desarrollo de un modelo de rendimiento basado en la eficiencia del pipeline ( $S/(S+\kappa)$ ) y su extensión para incluir restricciones de ocupación ( $\gamma(S)$ ) para predecir el rendimiento (throughput).
Validación: Garantizar la corrección numérica del kernel WMMA personalizado frente a cuBLAS con un umbral de error relativo de $10^{-2}$ .
Protocolo de Medición: Uso de temporización desde el host con fases de calentamiento (warmup) para mitigar el escalado de reloj y la sobrecarga de inicialización, señalando problemas específicos de estabilidad del driver en Windows (TDR) que requirieron separar los flujos de ejecución de cuBLAS y CUTLASS.

Resultos Clave

Configuración Óptima: La configuración de CUTLASS con una profundidad de pipeline de $S=3$ , una tesela de bloque de hilos de $256 \times 128$ y una vectorización de epílogo de 4 alcanzó 31.9 TFLOPS (52.7% del pico teórico). Esto igualó el rendimiento del kernel s16816gemm_f16 integrado en el perfilador de CUTLASS y superó ligeramente la referencia de cuBLAS (31.5 TFLOPS) por un 1.3%, una diferencia atribuida a la sobrecarga del benchmark más que a una superioridad algorítmica.
Anomalía de la Profundidad del Pipeline: De forma contraintuitiva, aumentar la profundidad del pipeline a $S=4$ resultó en una regresión de rendimiento a 31.1 TFLOPS (una disminución del 2.5%).
Análisis de Cuellos de Botella: La degradación en $S=4$ se atribuyó al colapso de la ocupación. Mientras que $S=3$ (que requiere 72 KB de memoria compartida) permitía 2 bloques por Unidad Multiprocesador de Flujo (SM), $S=4$ (que requiere 96 KB) forzó la ocupación a solo 1 bloque por SM. Esto redujo a la mitad el número de warps concurrentes, disminuyendo la capacidad del programador (scheduler) para ocultar la latencia de memoria. Además, la presión de registros aumentó de ~64 a ~72 registros por hilo.
Precisión del Modelo: Un modelo analítico simple predijo con precisión el rendimiento para $S=2$ y $S=3$ , pero sobreestimó $S=4$ en un 13.8%. Un modelo extendido que incorpora techos de ocupación corrigió la predicción de $S=4$ para situarla dentro del 1% del valor medido.
Rendimiento del Kernel Personalizado: El kernel WMMA personalizado alcanzó 25.1 TFLOPS (41.5% del pico) en $N=4096$ . Su menor rendimiento se atribuyó a la falta de pipelining de software (buffering simple) y a una mayor sobrecarga de sincronización en comparación con las plantillas optimizadas de CUTLASS.

Contribuciones Clave

Marco de Benchmarking Reproducible: Un marco de código abierto que utiliza la API de nivel de dispositivo de CUTLASS para instanciar kernels GEMM con parámetros arbitrarios en tiempo de compilación en GPUs Ada Lovelace.
Empirismo de la Profundidad de Pipeline: Evidencia experimental que demuestra que los pipelines más profundos ( $S=4$ ) no siempre producen un mayor rendimiento en GPUs de consumo debido a las restricciones de memoria compartida y ocupación, contradiciendo los modelos de rendimiento simples.
Modelo Analítico Calibrado: Un modelo de rendimiento que predice con éxito el rendimiento para $S=2$ y $S=3$ , pero que requiere una extensión limitada por ocupación para modelar con precisión el régimen de $S=4$ .
Referencia Pedagógica: Un kernel WMMA personalizado totalmente validado que sirve como referencia para la programación de bajo nivel de Tensor Cores.
Observación del Comportamiento del Driver: Documentación de una inestabilidad específica del driver en Windows (relacionada con TDR) al intercalar kernels de CUTLASS y cuBLAS, resaltando las restricciones prácticas en el benchmarking cruzado de librerías en Windows.

Significancia y Reivindicaciones
El artículo sostiene que lograr un alto rendimiento en GEMM en GPUs de consumo modernas es un problema de múltiples cuellos de botella donde la profundidad del pipeline no es el único determinante del rendimiento. El estudio destaca que la presión de la memoria compartida y las restricciones de ocupación pueden revertir los beneficios esperados de los pipelines de software más profundos. Al demostrar que una RTX 4060 de grado de consumo puede alcanzar aproximadamente el 53% del pico teórico de Tensor Cores (31.9 TFLOPS), el trabajo sugiere que niveles de rendimiento cercanos a los de centros de datos son accesibles en hardware económico. Los autores posicionan sus herramientas y hallazgos de código abierto como un recurso para educadores e investigadores para estudiar técnicas de optimización de GPU, contribuyendo a los objetivos más amplios de la computación de alto rendimiento accesible y la inferencia de aprendizaje automático energéticamente eficiente. El trabajo no pretende resolver todos los desafíos de optimización de GEMM, sino que proporciona un análisis específico y reproducible de los compromisos entre la profundidad del pipeline y la ocupación en la arquitectura Ada Lovelace.