Resumo Técnico: Um Verificador de Nível de Contrato para Kernels de GPU Gerados por LLM e um Backward Nativo para Blackwell para a Família Gated-Linear-Recurrence

1. Declaração do Problema

O campo da geração de kernels de GPU usando Grandes Modelos de Linguagem (LLMs) reporta altas taxas de correção, mas essas afirmações dependem de um sinal de validação frágil. Os benchmarks atuais (ex: KernelBench, TritonBench) tipicamente aceitam um kernel se sua saída for "próxima" de uma implementação de referência em alguns inputs aleatórios em um único formato (shape) fixo, utilizando uma tolerância frouxa (ex: torch.allclose com atol=rtol=10⁻²).

O artigo argumenta que este "teste único e frouxo" cria uma ilusão de correção. Um kernel pode passar neste teste enquanto é fundamentalmente quebrado de formas que o teste nunca sonda:

• Corrupção Silenciosa de Dados: Retornar um número finito onde a referência retorna NaN ou Infinity.
• Não Determinismo: Produzir resultados diferentes em cada execução.
• Fragilidade de Formato (Shape Fragility): Quebrar imediatamente quando o comprimento da sequência ou o tamanho do lote (batch size) muda.
• Deriva de Precisão: Acumular reduções em fp16 enquanto a referência mantém um total em fp32.

Os autores postulam que uma parte significativa das "vitórias" reportadas na geração de kernels é ilusória porque os critérios de aceitação são fracos demais para detectar esses falhas silenciosas.

2. Metodologia

O Verificador de Nível de Contrato

Para abordar o sinal de validação fraco, os autores construíram um verificador de nível de contrato que operacionaliza a taxonomia de "Contratos de Kernel". Este sistema submete os kernels a doze portões adversariais, graduados contra uma implementação de referência lenta e de alta precisão (verdade fundamental/ground truth).

Os portões são divididos em duas categorias:

1. Portões Sem Tolerância: Estes exigem correspondências exatas (igualdade de bytes ou máscaras exatas) e não admitem argumentos de tolerância. Eles verificam:
   • EXC-01/02: Propagação correta de NaN/Infinity e tratamento de subnormais.
   • ORD-02: Determinismo bit a bit entre execuções e ausência de aliasing de buffer.
   • RES-02: Adesão aos limites de recursos de hardware (ex: orçamento de Memória de Tensor).
2. Portões com Limiar (Thresholded Gates): Estes utilizam tolerâncias derivadas baseadas em modelos de erro de ponto flutuante (ex: atol ≈ 4ε√N) em vez de valores arbitrários ajustados manualmente. Eles verificam:
   • CMP-01/03: Correção através de diversos inputs e variando formatos (shapes).
   • ORD-01: Limites de ordem de somatório.
   • PRC-01/02: Regimes de precisão e precisão do acumulador interno.

Mecanismos de Justiça:

• Red Team: O verificador é validado contra 19 kernels deliberadamente quebrados (ex: cache de respostas, retorno de inputs, absorção silenciosa de NaN) e deve rejeitar todos os 19 enquanto passa as referências honestas.
• Controle Positivo: O verificador é testado nos próprios kernels escritos à mão pelos autores para garantir que não seja ajustado para falhar em código estrangeiro.
• Calibração: Os limiares são definidos no ponto mais frouxo defensável, separando o "ruído honesto" de kernels corretos do "erro real" de kernels quebrados.

A Auditoria

O verificador foi aplicado a 2.638 kernels gerados por máquina do corpus Dr. Kernel / KernelGYM. Crucialmente, esses kernels já haviam sido aceitos como "corretos" pelo próprio sistema de origem de sua estrutura (harness). A auditoria mediu quantos desses kernels "certificados" de fato violavam o contrato.

O Kernel Backward Nativo

Para fornecer um controle positivo independente, os autores desenvolveram um backward de treinamento nativo para Blackwell tcgen05 para a família Gated-Linear-Recurrence (GDN). Este kernel:

• Implementa o estágio de reverse-state scan e as etapas de VJP (Produto Vetor-Jacobiano) de WY/inversa triangular nativamente no hardware Blackwell.
• Resolve a restrição de Memória de Tensor (TMEM) (Issue #904), onde kernels oficiais falham ao compilar devido ao excesso do orçamento de 512 colunas de TMEM.
• É verificado contra um oráculo de dupla precisão (fp64) e determinismo bit a bit.

3. Principais Contribuições

1. Um Verificador de Nível de Contrato de Doze Portões: Uma operacionalização escalável de contratos de correção apresentando portões sem tolerância e limiares derivados, validados por um red team de kernels quebrados e um controle positivo.
2. A Auditoria do Gap de Rigor: Uma auditoria em larga escala de 2.638 kernels aceitos revelando um enorme gap de correção:
   • 39,5% (1.043 kernels) falham em um portão sem tolerância, o que significa que estão quebrados de formas que nenhum argumento de tolerância pode excusar.
   • 62,1% carregam pelo menos uma violação de contrato.
   • O benchmark padrão aceita 1.487 desses kernels quebrados, enquanto o verificador os rejeita; inversamente, o verificador rejeita apenas 14 kernels que o benchmark aceita.
3. Primeiro Backward Nativo tcgen05 para Blackwell para GDN: Um backward de treinamento escrito à mão para a família GDN (cobrindo Mamba-3, GLA, KDA, etc.) que gerencia corretamente o ciclo de vida do TMEM, superando o bloqueador de compilação #904.
4. Resultos de Suporte:
   • Seis kernels Triton de Mamba-3 verificados por contrato que contornam o #904.
   • Treinamento de um modelo de 1,1 bilhão de parâmetros de ponta a ponta nestes kernels.
   • Um otimizador automático de reforço (GRPO) que consegue ajustar botões de lançamento (launch knobs), mas falha em descobrir edições de fonte que melhorem a velocidade sem quebrar a correção.

4. Resultados

O Gap de Rigor

A auditoria demonstra que a verificação "allclose" padrão é um ponto cego sistemático.

• Defeito Modal: A falha mais comum (34,2%) é o EXC-01: um kernel substituindo silenciosamente um NaN ou Infinity por um número finito. Isso converte um erro de treinamento detectável em corrupção silenciosa de dados.
• Rigidez de Formato (Shape Rigidity): 18,1% dos kernels falham quando o formato muda (CMP-03), apesar de passarem no formato fixo usado em benchmarks.
• Diferencial: O desacordo entre a verificação padrão e o verificador é quase inteiramente unidirecional (1.487 vs 14), indicando que o padrão perde classes específicas de erros em vez de ser apenas "mais estrito".

Verificação do Kernel Nativo

O kernel backward nativo dos autores serve como um controle positivo:

• Ele passa por todos os 12 portões do verificador.
• Atinge um erro relativo de pior caso de 3,3 × 10⁻³ contra um oráculo fp64.
• É bit a bit determinístico.
• Treina com sucesso cinco membros da família GDN.
• Nota de Velocidade: O kernel nativo é atualmente mais lento (latência estrutural) do que a biblioteca de fallback Triton existente (fla), principalmente devido à natureza sequencial do reverse-state scan e ao código de ligação (glue code) em fp32. Os autores explicitamente declaram esse déficit de velocidade em vez de obscurecê-lo.

Alinhamento de Modos de Falha

O artigo destaca um alinhamento crítico: os mesmos portões que detectaram bugs reais nos próprios kernels dos autores durante o desenvolvimento (ex: problemas de propagação de NaN, erros de inferência de formato, erros de ciclo de vida de TMEM) foram exatamente os portões que detectaram as falhas no corpus estrangeiro. Isso confirma que o verificador não é enviesado contra código estrangeiro, mas sim uma ferramenta de diagnóstico geral.

5. Significância e Alegações

O artigo afirma que o sinal de correção por trás do progresso reportado na geração de kernels é muito mais fraco do que os números sugerem.

• Gap Qualitativo: O gap não é meramente uma questão de "quão perto é perto o suficiente" (um debate de limiar), mas sim uma falha qualitativa em detectar erros silenciosos como absorção de NaN e não determinismo.
• Padrão Acionável: Um pequeno conjunto de contratos sem tolerância (propagação de não-finitos, determinismo, polimorfismo de formato) fecharia a maior parte do gap com custo modesto. Os autores propõem estes como um novo padrão de benchmark.
• Integridade Metodológica: Ao usar o mesmo instrumento para auditar código estrangeiro e validar seu próprio trabalho (incluindo a admissão de seus próprios déficits de velocidade), os autores demonstram uma metodologia onde as rejeições do verificador são diagnósticas, não arbitrárias.
• Impacto Sistêmico: O trabalho expõe que uma parcela significativa dos kernels gerados por LLM reportados como "corretos" estão, na verdade, quebrados, e que a dependência do campo em testes de formato único e frouxo é insuficiente para confiabilidade de nível de produção.

O artigo conclui que os doze contratos identificados são suficientes para começar a fechar este gap, mudando o foco de "passar em um teste frouxo" para "satisfazer um contrato".