The Correctness Illusion in LLM-Generated GPU Kernels

Resumo Técnico: A Ilusão de Correção em Kernels de GPU Gerados por LLM

Declaração do Problema
Os benchmarks atuais para avaliar kernels de GPU gerados por Grandes Modelos de Linguagem (LLM) (ex: KernelBench, TritonBench, GEAK) dependem de um oráculo de "forma fixa, amostra pequena e estilo allclose" para determinar a correção. Esses benchmarks tipicamente testam um único formato de entrada e tipo de dado (dtype) com tolerâncias selecionadas manualmente. Os autores argumentam que esse oráculo é sistematicamente otimista, criando uma "ilusão de correção" onde kernels com bugs passam na validação enquanto contêm erros significativos. Especificamente, os autores identificam três modos de falha nos métodos de avaliação atuais:

1. Rigidez de Forma: Testar apenas um formato por operação falha em detectar bugs relacionados a mascaramento de cauda (tail masking), acumulação de erro por um (off-by-one accumulation) ou suposições de tamanho de bloco que só se manifestam em dimensões específicas.
2. Rigidez de Dtype: Testar apenas o dtype primário (ex: fp32) ignora erros de precisão mista, como overflow, underflow ou deriva de acumulação em fp16 ou bf16.
3. Tolerâncias Laxas: Tolerâncias absolutas (atol) e relativas (rtol) escolhidas à mão são frequentemente ordens de magnitude mais largas do que o envelope de erro real do kernel, permitindo que erros numéricos reais sejam absorvidos.

Metodologia
Para testar empiricamente essa hipótesia, os autores construíram um corpus controlado e um novo pipeline de avaliação:

• O Corpus: Um conjunto de 24 kernels (estendido para 26 para testes cross-GPU) compreendendo 15 kernels de controle corretos e 9 (posteriormente 10) "variantes com bugs estilo LLM". As variantes com bugs não foram extraídas de saídas reais de LLMs, mas foram sementadas pelos autores com erros de transcrição documentados comuns em código gerado por LLM (ex: ausência de 0.5 no GELU, mascaramento de cauda incorreto no softmax, ausência de sqrt no RMSNorm, sobrescrita de acumulador no matmul e escalonamento incorreto em mecanismos de atenção).
• Fuzzing Consciente do Esquema da Operação (Op-Schema-Aware Fuzzing): Em vez de geração de forma aleatória, o fuzzer utiliza o esquema do operador (ex: matmul A[M, K] · B[K, N]) para gerar entradas. Ele amostra valores para dimensões simbólicas (M, K, N) de um conjunto de candidatos que inclui explicitamente valores de fronteira (ex: 1, 3, 7, 256, 1025) ao lado de valores regulares. Isso garante a cobertura de casos de borda, como blocos de cauda.
• Oráculo de Alta Precisão: O oráculo de validação compara as saídas do kernel contra uma referência de CPU de alta precisão (fp64), arredondada para o dtype alvo. Crucialmente, ele utiliza tolerâncias absolutas por (op, dtype) em vez da métrica combinada absoluta/relativa allclose usada pelo PyTorch. Ele também registra distribuições completas de erro (percentis ULP, detecção de NaN/Inf).
• Reprodutibilidade: O sistema é totalmente reproduzível; cada falha sinalizada armazena um snapshot binário de entrada e uma semente, permitindo a reprodução byte a byte da falha.

Principais Resultados
O estudo foi conduzido em uma única GPU (RTX 3060) e estendido através de cinco classes de GPU (RTX 3060, A10, L40S, A100 SXM4, H100 NVL).

• Taxa de Detecção: O oráculo sementado sinalizou com sucesso 9 de 9 (e posteriormente 10 de 10) os kernels com bugs.
• Falsos Positivos: O oráculo passou em 15 de 15 (e posteriormente 16 de 16) os kernels de controle corretos com zero falsos positivos.
• Consistência Cross-Arquitetura: Os veredictos foram idênticos em todas as cinco classes de GPU, confirmando que as "ilusões" (bugs que passam em benchmarks padrão, mas falham no oráculo rigoroso) são consistentes independentemente da arquitetura de hardware subjacente.
• Categorias de Bugs: Os autores particionam os bugs detectados em duas classes:
  1. Bugs de magnitude uniforme: Erros como constantes ausentes ou fatores de escala errados que são capturados em quase toda forma, mas ignorados pelos benchmarks padrão devido às tolerâncias largas.
  2. Bugs dependentes de forma: Erros como vazamentos de máscara de cauda ou sobrescritas de acumulação que são invisíveis sem a geração de forma consciente de fronteiras.

Significância e Alegações
O artigo afirma demonstrar que o oráculo padrão "allclose-em-uma-forma" é insuficiente para certificar a correção de kernels de GPU gerados por LLM. A "ilusão de correção" surge porque os benchmarks atuais certificam kernels como corretos baseando-se em uma fatia estreita do domínio de entrada e margens de erro amplas.

Os autores enfatizam que seus resultados referem-se especificamente a quais padrões de bug o oráculo atual certifica como corretos, e não à taxa de erro de qualquer LLM implantado específico. Ao usar bugs sementados pelos autores, eles estabelecem uma verdade fundamental para erros de transcrição específicos conhecidos de ocorrer em geração de código por LLM. O artigo conclui que as contramedidas necessárias para corrigir isso — conjuntos de formas conscientes de fronteiras, calibração de tolerância por op/dtype e geração de entrada principista — são viáveis para qualquer projeto que atualmente utilize oráculos do tipo allclose.

Limitações Notadas
Os autores declaram explicitamente que as variantes com bugs são sementadas pelos autores com base em padrões documentados, não amostradas de saídas reais de LLMs, o que significa que o estudo mede a sensibilidade do oráculo a tipos de erro conhecidos, em vez da taxa geral de falhas de LLMs. Adicionalmente, a implementação atual depende de comparação de mesmo dtype (kernel-fp16 vs. referência-fp16) e ainda não suporta validação cross-dtype ou decodificação de cliente nativa de bf16 (proxied via fp16).