💻 computer science

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

Este artigo avalia o desempenho de GEMM em FP16 na NVIDIA RTX 4060 da arquitetura Ada Lovelace através de cuBLAS, CUTLASS e implementações customizadas de WMMA, revelando que uma profundidade de pipeline de três com uma geometria de tile específica atinge 52,7% do throughput de pico ao demonstrar que a pressão na memória compartilhada, em vez da profundidade do pipeline, é o principal gargalo que limita a otimização adicional.

Autores originais: Lucas Lima Freitag

Publicado 2026-07-15

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Lucas Lima Freitag

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você tem uma cozinha superveloz (uma GPU) com uma equipe de chefs especializados chamados Tensor Cores. Esses chefs são incrivelmente rápidos em picar e misturar ingredientes (multiplicação de matrizes) para um banquete gigante (aprendizado profundo). A cozinha no novo fogão "Ada Lovelace" (uma placa gráfica RTX 4060) é teoricamente capaz de servir 60,55 TFLOPS (isso são 60,55 trilhões de operações matemáticas por segundo).

Mas tem um detalhe: só porque os chefs podem picar nessa velocidade, não significa que eles estejam picando assim. Eles frequentemente precisam esperar os ingredientes serem entregues da despensa.

O Grande Experimento: Como Manter os Chefs Ocupados

Os pesquisadores queriam descobrir a melhor maneira de organizar a cozinha para que os chefs nunca parem de picar. Eles testaram três maneiras diferentes de rodar a cozinha:

A Caixa Preta (cuBLAS): Uma receita pré-embalada e de código fechado da NVIDIA que geralmente funciona muito bem, mas não permite que você ajuste os detalhes.
O Projeto Aberto (CUTLASS): Um kit de ferramentas flexível e de código aberto que permite que você construa seu próprio layout de cozinha do zero.
A Abordagem DIY (WMMA): Uma cozinha construída sob medida onde você controla cada movimento dos chefs, mas é muito mais difícil de construir.

Eles montaram um enorme desafio de culinária com ingredientes de tamanho 8192 × 8192 e testaram diferentes "profundidades de pipeline". Pense na profundidade de pipeline como o número de bandejas de ingredientes que a cozinha mantém prontos.

Profundidade de Pipeline 2: Apenas 2 bandejas prontas.
Profundidade de Pipeline 3: 3 bandejas prontas.
Profundidade de Pipeline 4: 4 bandejas prontas.

O senso comum (e um modelo matemático simples) sugeria que mais bandejas = mais velocidade. A lógica era: "Se tivermos mais bandejas, os chefs nunca ficarão sem ingredientes, então eles trabalharão mais rápido."

A Surpresa: Mais Não é Sempre Melhor

Os pesquisadores mediram a velocidade e aqui está o que encontraram:

Profundidade 2: A cozinha operou a 25,6 TFLOPS. Os chefs estavam esperando demais.
Profundidade 3: A cozinha acelerou para 31,9 TFLOPS (o que é 52,7% do máximo teórico). Este foi o ponto ideal!
Profundidade 4: A cozinha na verdade desacelerou para 31,1 TFLOPS.

Esta é a principal descoberta: Adicionar aquela quarta bandeja não ajudou; tornou as coisas piores. O modelo matemático simples previu que a velocidade deveria ter saltado para 35,4 TFLOPS, mas não saltou. O modelo estava errado por 13,8%.

Por que Adicionar uma Bandeja Deu Errado?

O artigo explica que a cozinha tem espaço limitado. Quando eles adicionaram a 4ª bandeja (aumentando o uso da "Memória Compartilhada" para 96 KB), isso forçou a cozinha a reduzir o número de equipes de cozinha (threadblocks) que poderiam trabalhar ao mesmo tempo.

Com 3 bandejas, a cozinha podia acomodar 2 equipes de chefs em cada fogão.
Com 4 bandejas, a cozinha só conseguia acomodar 1 equipe.

Mesmo que a única equipe tivesse mais ingredientes, eles tiveram que esperar mais tempo porque havia menos equipes para substituir quando uma ficava travada. A cozinha ficou "lotada" de ingredientes, mas "vazia" de trabalhadores. Os pesquisadores mediram que a ocupação (quantas equipes estão trabalhando) caiu, e os chefs tiveram que usar mais "registradores" (seus blocos de notas pessoais), o que também os atrasou.

Os Vencedores e Perdedores

O Vencedor: O kit de ferramentas CUTLASS com 3 bandejas e um tamanho de tile específico de 256 × 128. Ele atingiu 31,9 TFLOPS. Isso foi tão bom que superou a "Caixa Preta" padrão (cuBLAS) por uma margem minúscula, quase imperceptível de 1,3% (o que os autores dizem ser apenas ruído, mas prova que o projeto aberto pode igualar o fechado).
O Segundo Lugar do DIY: O kernel customizado WMMA (a cozinha totalmente DIY) conseguiu 25,1 TFLOPS em um teste ligeiramente menor. Foi mais lento porque não utilizou os truques sofisticados de "double buffering" para sobrepor a entrega de ingredientes com o cozimento.
O Perdedor: A ideia de que "mais profundidade de pipeline é sempre melhor". O artigo explicitamente descarta isso para este hardware específico.

O Quão Certos Eles Estão?

Os autores estão muito confiantes nesses números porque os mediram diretamente no hardware, rodando o teste 10 vezes e tirando a média dos resultados. Eles até conferiram sua matemática contra uma ferramenta de medição integrada da NVIDIA (o profiler) e descobriram que seu código customizado correspondia perfeitamente.

No entanto, eles admitem algumas coisas que não provaram:

Eles testaram apenas um tamanho específico de problema (8192). Eles não sabem se a regra de "3 bandejas é o melhor" se mantém para problemas menores ou de formatos estranhos.
Eles não puderam testar profundidades de pipeline superiores a 4 porque a cozinha simplesmente ficou sem espaço (memória).
Tiveram que rodar seus testes no Windows, onde um erro de driver impediu que comparassem seu código customizado e o código padrão exatamente na mesma execução (embora o tenham feito em execuções separadas).

A Conclusão

Se você está tentando tirar o máximo proveito de uma placa gráfica de consumo como a RTX 4060 para tarefas pesadas de matemática, não fique apenas adicionando mais buffers. Existe uma zona "Goldilocks" (o ponto ideal). Neste caso, 3 estágios de preparação foram perfeitos. Ir para 4 estágios deixou a cozinha muito apertada, atrasando todo mundo.

Os pesquisadores liberaram todo o seu código como código aberto, para que qualquer pessoa possa tentar construir sua própria cozinha e ver se consegue bater o recorde de 31,9 TFLOPS. Eles sugerem que trabalhos futuros devem olhar para diferentes tamanhos de problemas e usar Linux para obter dados ainda mais limpos, mas, por enquanto, eles mostraram que 31,9 TFLOPS é o pico atual para essa configuração, e que 31,1 TFLOPS é o que acontece quando você tenta ser ganancioso demais com a memória.

Resumo Técnico: GEMM FP16 de Alto Desempenho em NVIDIA Ada Lovelace via CUTLASS e WMMA

Declaração do Problema
A Multiplicação de Matrizes Generalizada (GEMM) é a fundação computacional do aprendizado profundo e da computação científica. Embora a arquitetura NVIDIA Ada Lovelace (especificamente a GPU de nível de consumo RTX 4060 com o chip AD107) ofereça um pico de vazão teórica de FP16 de 60,55 TFLOPS, alcançar um desempenho próximo ao pico requer uma orquestração intrincada da hierarquia de memória da GPU. O desafio reside em equilibrar estratégias de tiling, profundidade de pipelining de software e ocupação de threadblock para saturar os Tensor Cores sem ser limitado pela pressão da memória compartilhada ou restrições de registradores. A literatura prévia caracterizou extensivamente o GEMM ao nível de profiler de biblioteca, mas há uma lacuna na avaliação sistemática do impacto de profundidades de pipeline arbitrárias e geometrias de tile usando a API de nível de dispositivo do CUTLASS em hardware de consumo.

Metodologia
Os autores conduziram um benchmark sistemático de operações GEMM FP16→FP32 em uma NVIDIA RTX 4060 (Ada Lovelace) rodando Windows 11 com CUDA 13.1. O estudo comparou três níveis de implementação:

cuBLAS: A biblioteca de código fechado, otimizada pelo fabricante, usada como referência.
API de Nível de Dispositivo CUTLASS: Uma biblioteca de template C++ de código aberto que permite a customização em tempo de compilação de dimensões de tile, profundidade de pipeline ( $S$ ) e vetorização de epílogo.
Kernel WMMA Customizado: Um kernel ajustado manualmente usando a API CUDA Warp Matrix Multiply Accumulate (WMMA) para validação pedagógica.

Os experimentos focaram em um tamanho de problema fixo de $N = 8192$ ( $M=N=K=8192$ ). A metodologia envolveu:

Variação da Profundidade de Pipeline: Teste de configurações CUTLASS com profundidades de pipeline $S=3$ e $S=4$ usando tiles de threadblock de $256 \times 128$ e $128 \times 128$ .
Modelagem Analítica: Desenvolvimento de um modelo de desempenho baseado na eficiência de pipeline ( $S/(S+\kappa)$ ) e extensão para incluir restrições de ocupação ( $\gamma(S)$ ) para prever a vazão.
Validação: Garantia da correção numérica do kernel WMMA customizado contra o cuBLAS com um limiar de erro relativo de $10^{-2}$ .
Protocolo de Medição: Uso de temporização do lado do host com fases de warmup para mitigar o escalonamento de clock e overhead de inicialização, enquanto nota instabilidades específicas de driver do Windows (TDR) que necessitaram separar os fluxos de execução de cuBLAS e CUTLASS.

Resultos Principais

Configuração Ótima: A configuração CUTLASS com profundidade de pipeline de $S=3$ , um tile de threadblock de $256 \times 128$ e vetorização de epílogo de 4 alcançou 31,9 TFLOPS (52,7% do pico teórico). Isso igualou o desempenho do kernel s16816gemm_f16 integrado do profiler do CUTLASS e excedeu ligeiramente a referência do cuBLAS (31,5 TFLOPS) em 1,3%, uma diferença atribuída ao overhead do benchmark e não à superioridade algorítmica.
Anomalia de Profundidade de Pipeline: Contra-intuitivamente, aumentar a profundidade do pipeline para $S=4$ resultou em uma regressão de desempenho para 31,1 TFLOPS (uma diminuição de 2,5%).
Análise de Gargalo: A degradação em $S=4$ foi atribuída ao colapso de ocupação. Enquanto $S=3$ (exigindo 72 KB de memória compartilhada) permitiu 2 threadblocks por Streaming Multiprocessor (SM), $S=4$ (exigindo 96 KB) forçou a ocupação para apenas 1 bloco por SM. Isso reduziu pela metade o número de warps concorrentes, diminuindo a capacidade do scheduler de esconder a latência de memória. Adicionalmente, a pressão de registradores aumentou de ~64 para ~72 registradores por thread.
Precisão do Modelo: Um modelo analítico simples previu com precisão o desempenho para $S=2$ e $S=3$ , mas superestimou $S=4$ em 13,8%. Um modelo estendido incorporando tetos de ocupação corrigiu a previsão de $S=4$ para dentro de 1% do valor medido.
Desempenho do Kernel Customizado: O kernel WMMA customizado alcançou 25,1 TFLOPS (41,5% do pico) em $N=4096$ . Seu menor desempenho foi atribuído à falta de pipelining de software (buffering único) e maior overhead de sincronização em comparação aos templates otimizados do CUTLASS.

Principais Contribuições

Framework de Benchmarking Reproduzível: Um framework de código aberto utilizando a API de nível de dispositivo CUTLASS para instanciar kernels GEMM com parâmetros arbitrários de tempo de compilação em GPUs Ada Lovelace.
Empirismo de Profundidade de Pipeline: Evidência experimental demonstrando que pipelines mais profundos ( $S=4$ ) nem sempre geram maior vazão em GPUs de consumo devido a restrições de memória compartilhada e ocupação, contradizendo modelos simples de vazão.
Modelo Analítico Calibrado: Um modelo de desempenho que prevê com sucesso a vazão para $S=2$ e $S=3$ , mas que requer uma extensão limitada por ocupação para modelar com precisão o regime de $S=4$ .
Referência Pedagógica: Um kernel WMMA customizado totalmente validado servindo como referência para programação de baixo nível de Tensor Cores.
Observação de Comportamento de Driver: Documentação de uma instabilidade específica de driver do Windows (relacionada a TDR) ao intercalar kernels CUTLASS e cuBLAS, destacando restrições práticas em benchmarking de múltiplas bibliotecas no Windows.

Significância e Alegações
O artigo alega que alcançar GEMM de alto desempenho em GPUs de consumo modernas é um problema de múltiplos gargalos onde a profundidade do pipeline não é o único determinante da vazão. O estudo destaca que a pressão de memória compartilhada e as restrições de ocupação podem reverter os benefícios esperados de pipelines de software mais profundos. Ao demonstrar que uma RTX 4060 de nível de consumo pode alcançar ~53% do pico teórico de Tensor Core (31,9 TFLOPS), o trabalho sugere que níveis de desempenho próximos aos de datacenters são acessíveis em hardware de baixo custo para cargas de trabalho específicas. Os autores posicionam suas ferramentas e descobertas de código aberto como um recurso para educadores e pesquisadores estudarem técnicas de otimização de GPU, contribuindo para os objetivos mais amplos de computação de alto desempenho acessível e inferência de aprendizado de máquina energeticamente eficiente. O trabalho não pretende resolver todos os desafios de otimização de GEMM, mas fornece uma análise específica e reproduzível dos trade-offs entre profundidade de pipeline e ocupação na arquitetura Ada Lovelace.