The Correctness Illusion in LLM-Generated GPU Kernels

Resumen Técnico: La Ilusión de Corrección en Kernels de GPU Generados por LLM

Declaración del Problema
Los benchmarks actuales para evaluar kernels de GPU generados por modelos de lenguaje de gran tamaño (LLM) (por ejemplo, KernelBench, TritonBench, GEAK) dependen de un oráculo de "forma fija y muestra pequeña de estilo allclose" para determinar la corrección. Estos benchmarks suelen probar una única forma de entrada y un tipo de dato (dtype) con tolerancias seleccionadas a mano. Los autores argumentan que este oráculo es sistemáticamente optimista, creando una "ilusión de corrección" donde los kernels con errores pasan la validación a pesar de contener errores significativos. Específicamente, los autores identifican tres modos de falla en los métodos de evaluación actuales:

1. Rigidez de Forma: Probar solo una forma por operación no logra detectar errores relacionados con el enmascaramiento de cola (tail masking), la acumulación de error por uno (off-by-one), o suposiciones de tamaño de bloque que solo se manifiestan en dimensiones específicas.
2. Rigidez de Dtype: Probar solo el dtype principal (por ejemplo, fp32) omite errores de precisión mixta, como desbordamiento (overflow), subdesbordamiento (underflow) o deriva de acumulación en fp16 o bf16.
3. Tolerancias Laxas: Las tolerancias absolutas (atol) y relativas (rtol) seleccionadas a mano suelen ser órdenes de magnitud más laxas que la envolvente de error real del kernel, lo que permite que los errores numéricos reales sean absorbidos.

Metodología
Para probar empíricamente esta hipótesis, los autores construyeron un corpus controlado y un nuevo pipeline de evaluación:

• El Corpus: Un conjunto de 24 kernels (extendido a 26 para pruebas multiplataforma de GPU) que comprende 15 kernels de control correctos y 9 (posteriormente 10) "variantes con errores de estilo LLM". Las variantes con errores no fueron extraídas de salidas de LLM en vivo, sino que fueron sembradas por los autores con errores de transcripción documentados comunes en el código generado por LLM (por ejemplo, la ausencia de 0.5 en GELU, enmascaramiento de cola incorrecto en softmax, la falta de sqrt en RMSNorm, sobrescritura de acumuladores en matmul y escalado incorrecto en mecanismos de atención).
• Fuzzing Consciente del Esquema de Operación (Op-Schema-Aware): En lugar de la generación de formas aleatorias, el fuzzer utiliza el esquema del operador (por ejemplo, matmul A[M, K] · B[K, N]) para generar entradas. Muestrea valores para las dimensiones simbólicas (M, K, N) a partir de un conjunto de candidatos que incluye explícitamente valores límite (por ejemplo, 1, 3, 7, 256, 1025) junto con valores regulares. Esto asegura la cobertura de casos de borde como los bloques de cola (tail blocks).
• Oráculo de Alta Precisión: El oráculo de validación compara las salidas del kernel contra una referencia de CPU de alta precisión (fp64), redondeada al dtype objetivo. Crucialmente, utiliza tolerancias absolutas por (operación, dtype en lugar de la métrica combinada absoluta/relativa allclose utilizada por PyTorch. También registra las distribuciones completas de error (percentiles ULP, detección de NaN/Inf).
• Reproducibilidad: El sistema es totalmente reproducible; cada fallo detectado almacena un snapshot binario de la entrada y una semilla, lo que permite la reproducción byte a byte del fallo.

Resultados Clave
El estudio se realizó en una sola GPU (RTX 3060) y se extendió a cinco clases de GPU (RTX 3060, A10, L40S, A100 SXM4, H100 NVL).

• Tasa de Detección: El oráculo sembrado identificó con éxito 9 de 9 (y posteriormente 10 de 10) los kernels con errores.
• Falsos Positivos: El oráculo aprobó 15 de 15 (y posteriormente 16 de 16) los kernels de control correctos con cero falsos positivos.
• Consistencia entre Arquitecturas: Los veredictos fueron idénticos en las cinco clases de GPU, confirmando que las "ilusiones" (errores que pasan los benchmarks estándar pero fallan ante el oráculo riguroso) son consistentes independientemente de la arquitectura de hardware subyacente.
• Categorías de Errores: Los autores particionan los errores detectados en dos clases:
  1. Errores de magnitud uniforme: Errores como la falta de constantes o factores de escalado incorrectos que se detectan en casi todas las formas pero que los benchmarks estándar pasan debido a las tolerancias laxas.
  2. Errores dependientes de la forma: Errores como fugas de enmascaramiento de cola o sobrescritura de acumuladores que son invisibles sin la generación de formas consciente de los límites.

Significancia y Reivindicaciones
El artículo afirma demostrar que el oráculo estándar de "allclose-en-una-sola-forma" es insuficiente para certificar la corrección de los kernels de GPU generados por LLM. La "ilusión de corrección" surge porque los benchmarks actuales certifican los kernels como correctos basándose en una sección estrecha del dominio de entrada y márgenes de error laxos.

Los autores enfatizan que sus resultados se refieren específicamente a qué patrones de error el oráculo actual certifica como correctos, en lugar de la tasa de error de cualquier LLM desplegado. Al utilizar errores sembrados por autores, establecen una verdad fundamental para errores de transcripción específicos conocidos que ocurren en la generación de código por LLM. El artículo concluye que las contramedidas necesarias para solucionar esto —conjuntos de formas conscientes de los límites, calibración de tolerancia por operación/dtype y generación de entradas con principios definidos— son factibles para cualquier proyecto que actualmente utilice oráculos de estilo allclose.

Limitaciones Notadas
Los autores declaran explícitamente que las variantes con errores fueron sembradas por autores basándose en patrones documentados, no muestreadas de salidas reales de LLM, lo que significa que el estudio mide la sensibilidad del oráculo a tipos de error específicos conocidos, en lugar de la tasa general de fallos de los LLM. Además, la implementación actual depende de la comparación de mismo tipo (kernel-fp16 vs. referencia-fp16) y aún no soporta la validación de tipos cruzados ni la decodificación de cliente nativa de bf16 (proxied vía fp16).