Sankalp usa Codex loop para colocarse en el 12.º lugar en el concurso B200 QR de GPU Mode

Why it matters

Sankalp's result shows how a strict benchmark can turn a coding agent into an experimental system. Engineers still have to choose the architecture, interpret profiles and change the search policy when the agent stalls.

El resultado verificable de forma independiente es el puesto 12.º entre 183 participantes con 1,804.779 microsegundos en una NVIDIA B200. Alcanzó ese resultado después de más de 1,500 envíos durante 14 días usando OpenAI Codex. El proyecto formó parte de la serie de GPU Mode, Linear Algebra Kernels in the Age of Research, y de su competencia qr_v2.

En un relato del proyecto del 8 de julio, Sankalp escribió: "Durante el transcurso de 14 días, hice más de 1,500 envíos." El blog de Sankalp informa una mejora de 232x respecto a una línea base aproximada de PyTorch de 419,000 microsegundos; esa comparación es específica para esta carga de trabajo de benchmark y no fue reproducida de forma independiente en los materiales suministrados.

La competencia terminó el 29 de junio, alrededor de seis semanas y media antes de este artículo. El resultado final de Sankalp fue aproximadamente 48% más lento que la envío ganador de 1,220.774 microsegundos. Su resultado sigue siendo notable porque participó con aproximadamente un año de experiencia aprendiendo optimización de kernels GPU, mayormente en Triton, y dijo que nunca había trabajado profesionalmente en el campo.

Sankalp describió un bucle de optimización que combinaba generación de código, benchmarking, profiling y envíos al leaderboard. Él eligió la arquitectura e interpretó los resultados. Los detalles del flujo de trabajo abajo provienen de su relato; el resultado medible de forma independiente es su tiempo y puesto en el leaderboard.

Un benchmark diseñado para agentes

GPU Mode, una plataforma para competencias de programación GPU y benchmarks de kernels, y Core Automation pidieron a los competidores que implementaran la factorización QR compacta de Householder por lotes para matrices cuadradas. Cada envío debía aceptar matrices CUDA en FP32 y devolver la misma representación compacta usada por PyTorch torch.geqrf: una matriz H que contiene el resultado upper-triangular R y los vectores de Householder almacenados, además de los coeficientes de los reflectores en un vector tau.

El verificador reconstruía Q, comprobaba la ortogonalidad y el error residual, y clasificaba las entregas correctas por tiempo de ejecución de media geométrica a través de formas de matriz y condiciones de entrada. La carga de trabajo cubría matrices de hasta 4,096 por 4,096, incluyendo casos de condicionamiento difíciles. Los competidores podían usar menor precisión internamente, pero su salida aún tenía que pasar las comprobaciones estilo FP32.

Esa combinación le dio a Codex una definición rápida y cuantitativa de progreso. La interfaz de línea de comandos popcorn de GPU Mode permitió al agente probar, benchmarkear y enviar candidatos. Los tiempos a nivel de forma mostraban dónde cada cambio ayudaba o perjudicaba, mientras que el profiling aportaba otra capa de evidencia.

Según el relato de Sankalp, él mantuvo un archivo AGENTS.md que contenía instrucciones de operación, una declaración del problema, registros de experimentos y bitácoras de envíos con sello temporal. Las sesiones posteriores de Codex podían leer qué enfoques habían fallado en lugar de redescubrirlos. También le dio al agente objetivos numéricos y dejó que algunas corridas de optimización continuaran durante la noche, revisando cada dos o tres horas para preguntar qué había cambiado y qué cuello de botella seguía persiguiendo.

El directorio resultante eventualmente contenía 560 variantes de envío con nombre, 119 scripts de sondeo y comparación Modal B200, y 68 documentos por experimento. Modal, un proveedor de infraestructura en la nube, suministró créditos GPU para la competencia, según Sankalp. Los registros preservaron enfoques fallidos, resultados de profiling e historial de envíos para que sesiones posteriores de Codex pudieran construir sobre el trabajo anterior.

Transformar trabajo secuencial en multiplicación de matrices

Sankalp primero usó Claude y material educativo para entender la QR de Householder, según su relato del trabajo técnico. Se decidió por un diseño de Householder por bloques con una actualización WY final, luego usó profiling, comprobaciones de corrección y envíos repetidos al leaderboard para guiar la optimización posterior.

El problema central de rendimiento era la dependencia secuencial. Una implementación convencional de Householder procesa las columnas en orden, con cada reflector dependiendo de la matriz producida por el paso anterior. Eso deja una cantidad sustancial de trabajo en operaciones de matriz-vector más lentas mientras los tensor cores de la B200 esperan.

El enfoque por bloques confina el trabajo secuencial a un panel estrecho y convierte la actualización posterior más grande en multiplicación de matrices, donde la GPU tiene mucho más trabajo paralelo disponible. Sankalp informó haber alcanzado alrededor de 5,000 microsegundos en el caso 512 por 512, de mayor peso, dentro de su primer día usando esa arquitectura.

Más ganancias requirieron cambios a lo largo de la pila. El historial de envíos en su publicación pasó por panels personalizados en Triton, actualizaciones WY agrupadas, reproducción con CUDA graph, ensamblaje de layout fusionado, especialización de kernels de forma fija y una ruta Cholesky a medida para las matrices más grandes. Sankalp reportó que el resultado rastreado de la tabla completa bajó de 108,803 microsegundos a aproximadamente 1,805 microsegundos. Esta progresión fue independiente de la línea base aproximada de PyTorch de 419,000 microsegundos usada en su cálculo de 232x.

El relato de los perfiles posteriores de Sankalp indica que la sobrecarga de lanzamiento y el procesamiento de paneles dominaron, mientras que el kernel rara vez estuvo limitado por el ancho de banda de memoria bruto o la capacidad de cómputo. Su tabla de optimización registra trabajo para reducir lanzamientos, fusionar reducciones, especializar formas fijas, combinar el ensamblaje V/T y eliminar copias, concatenaciones y representaciones temporales.

Sankalp escribió que dio a Codex acceso al profiling de Modal y usó profiling de Torch, NVIDIA Nsight Systems y, más tarde, NCU. Estos son detalles de metodología auto-reportados. En su relato, Codex implementó y midió cambios mientras él inspeccionaba los resultados, fijaba objetivos y redirigía la búsqueda.

El humano cambió el proceso de búsqueda

Según el relato de Sankalp, la optimización se volvió más difícil después de que el resultado cayera por debajo de los 3,000 microsegundos. Describió que Codex pasaba más tiempo en el ajuste de parámetros y en pequeñas variantes de ideas que ya había probado. Sankalp respondió cambiando cómo los experimentos competían por atención.

Le instruyó a Codex que mantuviera un haz de tres a cinco familias candidatas en lugar de preservar un único resultado vigente y rechazar cada intento más lento. Los candidatos incluían cambios cercanos al mejor resultado actual, fallos prometedores y ideas estructurales de mayor riesgo.

En el mismo relato, Sankalp describió usar llamadas headless claude -p como asesores, asignar sub-agentes para buscar ideas de optimización y limpiar el contexto acumulado antes de corridas nuevas. Sus instrucciones en AGENTS.md trataban los timeouts como inconclusos, preservaban bitácoras con sello temporal, exigían salida completa como evidencia y registraban por qué los candidatos eran promovidos o rechazados. El archivo también advertía contra repetir ideas rechazadas sin un cambio material.

Codex aportó persistencia, generación de código y un gran presupuesto de búsqueda. Sankalp seleccionó la arquitectura, revisó el ciclo de retroalimentación, reconoció comportamientos repetitivos y cambió la política de experimentos.

En su reseña de las 10 entradas principales, Sankalp afirmó que competidores más rápidos usaron detectores de distribución de entradas, eliminaron más llamadas a librerías, implementaron inversas triangulares personalizadas y manejaron datos de menor precisión de forma más agresiva. Estas fueron observaciones de Sankalp y no hallazgos auditados de forma independiente. En la conclusión de la misma publicación, escribió que él "no pudo usar las instrucciones tcgen05" en la B200 para explotar más sus tensor cores.

GPU Mode convierte los concursos en un banco de pruebas para agentes

En un ensayo de Core Automation sobre código de sistemas escrito por IA, el cofundador de GPU Mode Mark Saroufim escribió que él y el cofundador Andreas Kopf empezaron un grupo de lectura sobre programación de GPU a finales de 2023. El grupo luego se expandió a un canal de YouTube, competencias de kernels y hackatones.

Saroufim utilizó la expresión "data starvation" para referirse a la escasez de material sobre kernels de GPU disponible en línea para entrenar modelos de codificación. Los concursos de GPU Mode generan ejemplos medibles de agentes y humanos trabajando en esa clase poco abundante de problemas de sistemas.

El puesto 12 de Sankalp ofrece una visión fundamentada de esa actividad. Un recién llegado usó un agente para acercarse a la cima de una tabla de clasificación competitiva en una tarea estrecha y medible. El trabajo aún requirió que aprendiera el problema, estructurara los experimentos, desafiara el comportamiento repetitivo e interpretara los resultados del perfilado. Su resultado muestra el valor de un evaluador que pueda producir evidencia confiable después de cada ejecución.