Via YT Combinator. Desde auto-arch-tournament.

¿Qué sucede cuando usted toma un bucle de investigación autónomo de su zona de confort y apuntarlo a un dominio que no tiene ningún negocio siendo bueno en? Andrej Karpathy autobús mostró que un agente de codificación, dado dos días y una nanochat de una única GPU, encuentra 20 optimizaciones de tiempo de entrenamiento por sí mismo. La receta es general — propone, implementa, mide, mantiene las victorias— pero la demostración estaba dentro del césped del agente: Python, descenso de gradiente, pomos conocidos.

Quería saber si se generalizó. Así que lo señalé a una CPU.

La configuración

auto-arch-tournament es un núcleo de RV32IM de 5 etapas en SystemVerilog — el programa de libros de texto que escribiría en una clase de arquitectura de postgrado. Sin caches, sin predictor de rama, sin multi-isue el día uno. Esas son hipótesis de investigación, no características.

El orquestador está codificado. El LLM nunca lo edita. Cada ronda, tres ranuras funcionan en paralelo:

1. El agente propone una hipótesis microarquitectural como YAML, comprobada con esquema contra schemas/hypothesis.schema.json.
2. Un agente de implementación edita archivos bajo rtl/ en un pajar aislado.
3. La puerta eval:
   • riscv-formal — 53 controles BMC simbólicos (decodificación, trampas, pedidos, animación, M-ext)
   • Verilator cosim — RVFI byte-identical against a Python ISS, ~22% random bus stalls
   • 3-seed nextpnr P pacienteR on a Gowin GW2A-LV18 (Tang Nano 20K) — median Fmax × CoreMark iter/cycle = fitness
   • Validación de CoreMark CRC - los mismos informes VexRiscv de los 4 CRC
4. Mejora → fusionado en el tronco, se convierte en la nueva base de referencia. Regreso / roto / colocación-failed → worktree destruido.

Una rotación de diversidad obliga a cada ranura para elegir una categoría diferente (micro_opt | structural | predictor | memory | extensionAsí que el agente no se fija en una idea.

Muéstrame los resultados

Base de referencia bloqueada en la misma metodología VexRiscv publica — sin caché completo, datos 2K, -O3, ~22% de la retropresión del autobús - en 2.23 CoreMark/MHz, 301 iter/s. El referente humano es VexRiscv publicado 2.57 CoreMark/MHz @ 144 MHz.

Entonces lo dejé correr. 73 hipótesis, 9h 51m en la pared.

ResultadoCondeMejora (aceptada)10Regreso50Roto (formal/cosim)9La ubicación falló4

Los 10 ganadores aceptados, en orden:

Δtiter/sCM/MHzFmaxLUT4Hipótesis0,0h301.042.226135 MHz9.880Base de referencia0.4h313.102.320135 MHz10.186Backward-Branch Taken Predictor0,7h324.482.348138 MHz10.192IF Direct-Jump Predictor2.1h375.432.348160 MHz5.888Cold Multi-Cycle DIV/REM Unit2.7h397.552.366168 MHz5,854Ranura de retiro de una tienda más profunda3.5h422.772.366179 MHz5,933Contratador de orden RVFI segmentado3.8h472.962.891164 MHz5.916Registrado Lookahead I-Fetch Replay Predictor4.0h505.652.891175 MHz5.938Etiquetas de la repetición de la prueba de reinicio5.3h529.352.891183 MHz5.930RTL-Only Hot/Cold ALU Opcode Split6.1h577.762.908199 MHz5.944Registro bancario I-Fetch Replay Predictor

Estado final: 2.91 CoreMark/MHz, 577 iter/s, 199 MHz Fmax, 5,944 LUT4.

Eso es +92% sobre la base cerrada y +56% sobre VexRiscv en CoreMark iter/sec (370 → 578), con 40% menos LUTs. Los compuestos ganadores: ~13% de ellos es eficiencia arquitectónica (2.91 vs 2.57 CoreMark/MHz) y el resto es Fmax (199 vs 144 MHz) — un diseño más pequeño y simple que el sintetizador también relojes más rápido. Para el contexto, la brecha CoreMark/MHz entre VexRiscv full no cache y linux balanced configs (su siguiente nivel arriba, con caches) es alrededor de 40 puntos porcentuales, por lo que el bucle cerró 13 de aquellos en menos de diez horas, en un solo objetivo FPGA, contra un VexRiscv basal tomó años para llegar.

La función de paso negro es el mejor funcionamiento. Cruza la línea VexRiscv entonada por humanos en la iteración 6 y nunca mira hacia atrás. El movimiento interesante fue la iteración 3: sacar DIV/REM de la ruta del ciclo único. El agente no sabía que también amalgamaría la cuenta de LUT. Lo descubrió haciendo y viendo el sintetizador.

La parte interesante no es el bucle

Hay mucho ruido ahora mismo sobre los bucles de agente. Construir un planificador, construir un codificador, darles herramientas, ejecutarlos en un enjambre, levantar una semilla ronda. El bucle es sobre todo un problema resuelto. Escoge un modelo, elige una biblioteca de andamios, elige cuántas ranuras paralelas puedes permitirte. Lo que sea que tengas en el bucle, lo tienes durante seis meses.

Lo que a nadie se le paga para construir, y lo que este proyecto es en realidad, es el verificador.

De 73 hipótesis, 63 estaban equivocadosRegresaron, rompieron el ISA o fallaron en el tiempo. Algunos ejemplos reales del registro:

• La misma idea, dos veces. Move DIV/REM off the single-cycle ALU path primero entró en la ronda 1, ranura 0, y rompió cosim en la prueba de sí mismo antes de que llegara a la FPGA. El agente lo replanteó como Cold Multi-Cycle DIV/REM Unit dos horas más tarde —la misma idea, la implementación fija— y se convirtió en el gran avance. Sin la puerta cosim el primer intento roto habría enviado.
• Violaciones de sandbox. Dos hipótesis separadas intentaron añadir un test/_helpers.py archivo fuera del rtl/** y test/test_*.py permitido. La caja de arena del camino rechazó la ronda antes de que cualquier eval corriera. Si permites que el agente edite el arnés, eventualmente editará el arnés.
• Una regresión de -73%. En la ronda 24, después de la máxima aptitud de 577 iter/s ya estaba bloqueada, el agente propuso Registered Lookahead JALR Target Predictor. Fitness colapsó a 154 iter/s, una caída del 73%. Aceptado en el maletero, que un error deshacer cada victoria anterior en una sola ronda. El orquestador lo atrapó en el cheque de comparación-contra-baseline.
• Errores de esquema. Una hipótesis declarada fitness_delta_pct: 1.5 donde el esquema requiere un entero. Rechazado antes de generar cualquier código. Trivial - y exactamente el tipo de cosa que, sin el esquema, se convierte en un tipo silencioso coacción más adelante en el oleoducto.

Cada uno de esos fallos cuesta ~5–15 minutos de computación. Cada uno de ellos, sin compromiso, habría corrompido la carrera o enseñado al agente que un movimiento equivocado era uno correcto.

El verificador en este proyecto hace las cosas inglamorosas que estaría tentado a saltar:

• El ill / unique / liveness / cover cheques formales, no sólo los insn_* Unos. Los primeros cuatro capturan núcleos silenciosamente rotos; los insn_* sólo capturan aritmética silenciosa.
• Una caja de arena. El agente puede editar rtl/** y test/test_*.py. Touch formal/checks.cfg, tools/eval/fpga.py, o la mesa canónica de CRC y la ronda es rechazada antes de cualquier carrera eval. De lo contrario un agente eventualmente "mejorar" suavizando un cheque.
• Próxima de 3 semillas, mediana Fmax. Una semilla es un cambio de moneda; tres es un número que se puede comparar a través de iteraciones.
• validación de CRC sobre la producción de banco. Impresión de CoreMark Correct operation validated. incluso cuando no lo es, porque revisa sus propios CRCs e imprime el literal independientemente. The eval re-validates the four CRCs against the canonical 2K-config values.
• Frenando la región temporizada con los marcadores de inicio / parada MMIO. El calentamiento e impresión de CoreMark comerá su número de fitness si mide el extremo a extremo.

El bucle de agente es un productor. El verificador es lo único que está de pie entre usted y un número con confianza equivocado.

Lo que esto significa para el próximo lote de empresas

La próxima ola de empresas no va a ser gente escribiendo código. Va a ser gente escribiendo verificadores, con un bucle corriendo contra ellos.

El bucle es mercancía. Modelo + velocidad + herramientas + marcador + ranuras paralelas. Todo el mundo está convergiendo en la misma forma, y los proveedores de esas piezas están corriendo entre sí a cero margen.

El verificador no es mercancía. Es el artefacto que codifica lo que su negocio realmente significa por Correcto.En una CPU es una ISA y una suite formal de propiedades. En una tubería de facturación son invariantes en un libro mayor. En un compilador es una prueba diferencial contra la referencia. En un flujo de trabajo clínico es una propiedad que la FDA ha firmado. Ninguno de estos son problemas de inteligencia artificial. Son "cuál es tu dominio, y puedes escribir las reglas abajo" problemas.

Si puedes escribir las reglas, un agente las satisfará más rápido de lo que tu equipo lo hará. Si no puedes, y la mayoría de los equipos no pueden, porque las reglas viven en las cabezas de tres ingenieros y una página de Confluencia nadie actualizado, el agente satisfará un diferentes conjunto de reglas, las que infería de lo que podía observar. No se dará cuenta hasta la producción.

Las compañías que ganan esto no son las que tienen el planificador más inteligente. Son los que verifican el contrato.

¿Qué sigue?

El proyecto es actualmente secuencial a nivel redondo: los perdedores son descartados cada ronda, aunque sus caminos fallidos son una señal útil. La próxima iteración se mueve a una búsqueda basada en la población: mantener el top-K cada ronda, mutar de cualquiera de ellos, dejar que las ramas muertas permanezcan muertas. Eso debería escalar el espacio de búsqueda sin escalar la factura modelo linealmente.

También tengo curiosidad de cuánto de la victoria en las primeras 10 horas se generaliza con CoreMark. Algunos de esos predictores claramente se ajustan a su perfil de rama. Next experiment swaps in Embench against the same baseline, and we see which winners survivors a burden change and which were CoreMark trivia.

Ambas son preguntas interesantes. La pregunta más interesante —para mí, y para cualquier persona que envía un producto— es qué partes de su negocio ya tienen un verificador lo suficientemente agudo como para apuntar un lazo. Encuéntrelo, y la productividad de su equipo deja de escalar con topcount.

El futuro es brillante. La frontera es el verificador.