Aprimorando a auto-tunagem de GEMM com nvMatmulHeuristics no CUTLASS 4.2

Visão geral

General Matrix Multiply (GEMM) kernel selection em GPUs NVIDIA modernas é um problema de otimização com vários parâmetros. O desempenho do kernel depende de um grande conjunto de meta-parâmetros de compilação e tempo de execução, incluindo CTA, warp e tamanhos de tile de instrução; esquemas de kernel; estratégias de rasterização; dimensões de cluster; e fatores de divisão (split-k). Abordagens tradicionais geram milhares de configurações, compilam-nas e executam uma busca exaustiva para identificar a mais rápida. Esse fluxo pode levar horas e se mostra problemático para bibliotecas offline compiladas como o CUTLASS e para stacks JIT, como Torch Inductor ou OpenAI Triton, onde a compilação rápida é crucial. NVIDIA apresenta nvMatmulHeuristics, um módulo de otimização de meta-parâmetros de kernel que fornece heurísticas rápidas para prever um conjunto pequeno e de alto potencial de configurações GEMM. O módulo analisa o problema GEMM fornecido e as capacidades de hardware alvo para prever configurações que entregam o máximo desempenho. A integração com o CUTLASS 4.2 transforma o fluxo de geração de kernel e tuning de brute force para um caminho direcionado e eficiente. Para um determinado problema GEMM, nvMatmulHeuristics gera um conjunto conciso de configurações candidatas para testar. O recurso é apresentado como parte central dos heurísticos do cuBLAS e está disponível em acesso antecipado para uso geral, com integração no biblioteca CUTLASS. Um exemplo demonstra um GEMM FP16 simples (A transposto ou não, B, e C/D conforme layout). O fluxo envolve fornecer uma lista de problemas GEMM em JSON e construir o CUTLASS com opções de CMake específicas para emitir um conjunto de configurações por problema. Na prática, essa abordagem reduz drasticamente o tempo total de tuning. Em vez de compilar e perfilar exaustivamente milhares de kernels, você gera um conjunto curto e direcionado de candidatos e executa apenas esse conjunto. Isso é particularmente valioso para ambientes como PyTorch, onde os tempos de compilação JIT são críticos, e para bibliotecas que desejam alto desempenho sem longos ciclos de tuning.

Principais recursos

Prediz um conjunto pequeno e top-N de configurações GEMM por problema
Reduz o tempo total de tuning ao concentrar construção e perfil em um conjunto de candidatos
Integrado com CUTLASS 4.2 e heurísticas cuBLAS; disponível em acesso antecipado
Aceita uma entrada JSON descrevendo problemas GEMM; fácil de adaptar a fluxos existentes
Gera uma CSV de teste a partir das configurações emitidas para perfil automático
Compatível com cutlass_profiler para executar as configurações geradas
Habilita opções de cluster fixo em tempo de compilação, reduzindo variabilidade em tempo de execução
Demonstra desempenho próximo ao exaustivo com muito menos trabalho; por exemplo, 16 configurações atingem 96% do pico com tempo significativamente menor
Compatibiliza fluxos de trabalho em frameworks de DL, compiladores e bibliotecas de kernels

Tabela: comparação de abordagens de tunning

| Abordagem | Como funciona | Benefícios típicos | Observações |---|---|---|---| | Busca exaustiva | Gera e compila milhares de kernels; faz tuning completo | Melhor kernel possível; desempenho teórico máximo | Tempo muito alto de build+tuning (exemplos acima de 700 minutos) |nvMatmulHeuristics (este recurso) | Prediz top-N kernels por problema; compila um conjunto pequeno e perfila | Grandes ganhos de tempo; desempenho próximo do pico | Requer lista de problemas em JSON e integração de build |Pré-compilados/cluster estático | Usa tamanhos de cluster fixos de kernels pré-compilados | Configuração rápida; menor tuning em tempo de execução | Pode reduzir flexibilidade; desempenho depende das escolhas de compilação |

Casos de uso comuns

Integração com frameworks de DL: acelerar caminhos JIT (p. ex., PyTorch) reduzindo o tempo de tuning while mantendo alto desempenho para workloads GEMM.
Bibliotecas offline: permitem conjuntos de kernels bem ajustados com mínimo overhead de tuning durante a implantação.
workloads de modelos com grandes operações GEMM (p.ex., Llama, DeepSeek) onde tuning exaustivo é proibitivo.
Cenários que exigem resultados de profiling repetíveis; a abordagem ajuda a tornar builds reprodutíveis ao enfatizar um conjunto pequeno de candidatos.

Setup & instalação (comandos exatos)

O fluxo depende de preparar uma lista de problemas GEMM em JSON, construir o CUTLASS com o nvMatmulHeuristics ativado e, em seguida, rodar o profiling com o CSV gerado. As etapas explicitadas no texto são as seguintes opções de configuração do CMake que dirigem o fluxo heurístico:

cmake .. \
-DCUTLASS_LIBRARY_HEURISTICS_PROBLEMS_FILE= \
-DCUTLASS_LIBRARY_HEURISTICS_CONFIGS_PER_PROBLEM=N

Após configurar com estas opções, uma construção padrão emitirá um CSV de teste durante o processo. Você pode usar o CSV gerado para conduzir o auto-tuning via uma ferramenta de profiling (cutlass_profiler) que pode consumir o CSV e executar as configurações. Para resultados de profiling consistentes, execute com clocks travados. Notas:

Construa o CUTLASS como de costume, mas com as duas flags de heurísticas do CUTLASSLibrary mostradas acima.
O formato exato dos problemas JSON não está especificado aqui; o fluxo refere-se a uma lista de problemas GEMM expressos em JSON.

Quick start (exemplo mínimo executável)

Prepare uma lista de problemas GEMM em JSON (o exemplo no texto cita um único GEMM FP16, com A transposto (tnn) ou não, e layouts de B e C/D).
Construa o CUTLASS com heurísticas ativadas usando os comandos da seção anterior.
O sistema de build emitirá um CSV com as configurações geradas para cada problema GEMM.
Execute o fluxo de profiling com cutlass_profiler no CSV gerado para executar as configurações. Para resultados consistentes, utilize clocks travados durante o profiling.
Compare o desempenho com uma linha de base exaustiva, se disponível; nos casos descritos, 16 configurações atingem 96% do pico com muito menos tempo, e mais candidatos se aproximam do baseline exaustivo mantendo economias de tempo significativas.

Prós e contras

Prós
Redução enorme de tempo de build+tuning vs busca exaustiva
Desempenho próximo ao pico com um conjunto pequeno de candidatos
Melhor experiência para pipelines JIT e para deploys em dispositivos
Opções de cluster estático podem melhorar previsibilidade de compilação
Contras
Requer formatação/integração de uma lista de problemas em JSON
Recurso em acesso antecipado; APIs podem evoluir
Ainda depende de capacidades de hardware e da acurácia da caracterização do problema

Alternativas (comparação breve)

Busca exaustiva: garante o melhor kernel, mas custa tempo e recursos elevados (exemplos citados passam de 700 minutos).
Heurísticas com cluster estático: obtém boa performance, depende de escolhas de compilação; menos flexibilidade em tempo de execução.
Kernels pré-compilados/dinâmicos tipo Blackwell: oferecem adaptação em tempo de execução, mas podem exigir tuning de runtime; nvMatmulHeuristics busca deslocar mais decisão para o compile-time.

Pricing ou Licença

nvMatmulHeuristics é descrito como parte central dos heurísticos do cuBLAS e está disponível em acesso antecipado para uso geral, com integração ao CUTLASS. Não há informações de preço no material.