Este es el post sobre Kimi K3 que estaban esperando. Tuve acceso anticipado a este modelo y lo he estado probando en kernels, e incluso antes de ver las puntuaciones de los benchmarks, me impresionó su capacidad para razonar problemas y la densidad técnica de sus trazas de pensamiento. El post-entrenamiento en esto es evidente desde el momento en que lees una transcripción. También es súper divertido para conversar.
TLDR;
Creo que es importante para mí dar mi opinión honesta (esta parte está escrita por voz) como ingeniero de kernels y rendimiento que está desconectado de los benchmarks. Por supuesto, podrías mirar todos los números, leerlos e intentar desarrollar un modelo mental por ti mismo. Creo que el reflejo más honesto es si te cuento mi experiencia con el modelo en tareas difíciles antes de que salieran los resultados de los benchmarks, cuando estaba usando el modelo antes de que hubiera números para conectar con otros modelos. Solo sintiendo puramente la inteligencia, el razonamiento, la delegación de agentes y cuánto puede hacer en piloto automático por mí, pero antes de que hubiera hype circulando y los resultados oficiales llegaran. Diría que, con mi dirección, se sintió aproximadamente al nivel de Fable, en algunos casos superando de maneras muy únicas y en otros casos rindiendo por debajo. Diría que este modelo está definitivamente por delante de Opus 4.8 en la mayoría de las cosas y por delante de GPT 5.6 Sol en muchas cosas.
Entrando en materia...
Quiero ser sincero sobre por qué esto sale ahora: quería compartir mis pensamientos honestos y las puntuaciones tal como están, no guardarlos hasta que cada última celda termine. Algunas ejecuciones todavía están en curso mientras escribo esto. Están marcadas abajo, y los mantendré al tanto a medida que lleguen. Ejecuté ambas versiones de contexto 256K y 1M. Todo esto se ejecutó en NVIDIA RTX PRO 6000 Blackwells, H100s y B200s, con optimización de una sola GPU únicamente. Cada celda es una sesión de agente autónomo con tiempo de reloj de pared ilimitado: el modelo recibe el problema, un bucle en vivo de compilación/verificación/benchmark en hardware real, y decide cuándo ha terminado. Cada celda principal fue auditada manualmente en busca de reward hacking. Un agente separado lee el kernel final de principio a fin más la traza completa de la sesión y vuelve a probar empíricamente cualquier cosa que huela a caché o juegos de calificación. Lo que esas auditorías encontraron tiene su propia sección.
Algo que quería saber
Hubo una cosa que diseñé específicamente para este lanzamiento: dos de los problemas son de la propia arquitectura de Moonshot. El mazo Hard tiene un kernel independiente Kimi Delta Attention chunk-forward, y el problema principal del mazo Mega es un paso de decodificación híbrido Kimi-Linear completo: capas KDA, atención MLA, expertos MoE, todo el bloque. Así que esta fue una oportunidad para probar algo que nadie puede probar muy a menudo: cuando el modelo de un laboratorio se sienta a escribir kernels para la arquitectura de ese mismo laboratorio, ¿el conocimiento de la familia se muestra en el CUDA?
La respuesta resultó ser genuinamente dividida, y ambas mitades son interesantes. Mantengan esa pregunta en mente durante la siguiente sección.
KernelBench-Mega
El problema mega insignia: fusionar un paso de decodificación Kimi-Linear completo por token (3x KDA + 1x capa MLA, pesos cuantizados W4A16, MoE con enrutamiento top-8) en la menor cantidad posible de lanzamientos de kernel.
K3 casi toma el récord de todos los tiempos, en su propio linaje. Aceleración geomean de 18.09x sobre eager en la RTX PRO 6000, dentro del 4% del récord de Fable 5 de 18.72x. En H100 publicó 14.82x contra los 15.50x de Opus 4.8. Una nota de honestidad que la relación oculta: en latencia absoluta por token, Fable sigue siendo ~1.4x más rápido (0.31 vs 0.44 ms/tok en ctx 2048; las dos ejecuciones usaron hosts con diferentes CPUs, lo que cambia la línea base eager contra la que se calcula la relación), así que reporto ambas en lugar de dejar que la geomean halague a nadie.
Lo que K3 construyó es un verdadero megakernel. Su primera sesión hizo lo sensato, un kernel Triton persistente a 14.1x. Su segunda sesión tiró Triton a la basura y escribió el paso de decodificación completo por token como UN kernel CUDA lanzado cooperativamente: cero CPU en el bucle, pesos int4 des-cuantizados sobre la marcha dentro de cada GEMV para que fluyan a través de los SMs exactamente una vez, atención MLA en tensor cores. Ningún motor de producción mantendría un artefacto de 1,228 líneas como este. Un agente con un kernel para ganar y tiempo ilimitado no tiene tal restricción, y sacar a la superficie exactamente este tipo de cosas es para lo que existe el benchmark.
Ver el megakernel aquí:
Entonces, ¿por qué todavía perdió contra Fable? No fue el tiempo. Ambas sesiones se auto-terminaron temprano (Fable a las 2.6 horas, K3 a las 3.3). La diferencia es la filosofía de diseño, y es lo opuesto a lo que adivinarías: K3 es el que usa tensor cores, y el kernel de Fable contiene cero instrucciones MMA. La decodificación Batch-1 con GEMVs int4 fusionados está limitada por ancho de banda, por lo que los tensor cores casi no compran nada aquí. Fable gastó ese esfuerzo en sincronización en su lugar, reemplazando la mayoría de sus barreras globales con transferencias granulares productor-consumidor para que ningún SM se quede inactivo en un límite de etapa, y en una ruta de des-cuantización int4 que coincide con el redondeo de la referencia bit por bit para que el enrutador MoE nunca cambie una elección de experto. K3 trajo mejores instrucciones de hardware; Fable trajo mejor ingeniería de concurrencia, y a esta intensidad aritmética, la segunda gana. Esa es una lección real de sistemas, y le costó al equipo local el récord.
El segundo problema mega es un megakernel de entrenamiento PPO grid-foraging: 4,096 agentes vectorizados en un tablero de 11x11, con todo el bucle de entrenamiento RL (paso de entorno, forward de política, muestreo de acciones, GAE, la actualización PPO) ejecutándose como kernels persistentes fusionados. Este problema tiene la restricción más estricta del mazo: el número de lanzamientos de kernel no debe escalar con los pasos de entorno, y la captura de grafo CUDA está explícitamente prohibida como solución alternativa para la sobrecarga de lanzamiento, aplicada por un juez de autenticidad post-ejecución que lee el código final. La corrección es la propia curva de aprendizaje. check.py entrena tu solución contra la referencia a través de semillas y requiere que el retorno caiga en una banda, por lo que no puedes saltarte el aprendizaje para ir rápido. K3 publicó 20.7x sobre la referencia aquí, la mejor puntuación hasta ahora (la única otra celda publicada es GPT-5.6 Sol a 1.06x, así que trátalo como un punto de datos, no un podio).
KernelBench-CUDA
El bench CUDA existe porque Triton es una muleta que los otros dos mazos permiten. Aquí, una restricción de lenguaje falla automáticamente a Triton, DSLs de kernel y cadenas de operaciones de PyTorch: escribes CUDA o fallas. Elegí los cuatro problemas para que sean cortes de cargas de trabajo reales de inferencia y simulación en producción. La comparación mental mientras lees debería ser "¿qué envía vLLM o SGLang para esto hoy, y qué tan cerca llega una sesión de agente?" Aquí es donde K3 publicó sus victorias más desiguales.
02_deepseek_nsa: Native Sparse Attention de DeepSeek. NSA es el diseño de atención de entrenabilidad dispersa insignia, lo que toda pila de servicio de contexto largo está explorando, y se juzga en milisegundos porque un kernel disperso correcto nunca ejecuta los FLOPs equivalentes densos que una línea de techo querría contar. La variante 256K de K3 obtuvo 0.425 contra 0.178 de Opus 4.8, un margen de 2.4x, escribiendo lo que equivale a un pipeline de tensor-core de clase flash-attention desde cero alrededor de la lógica de selección completa de NSA. La comparación más aguda es dentro de la familia: la variante 1M escribió el mismo algoritmo, selección de bloque idéntica, misma corrección, pero ejecutó cada producto punto en núcleos CUDA planos en lugar de tensor cores y aterrizó en 0.058, 7x más lento en formas idénticas. Su traza muestra que lo sabía mejor. Tenía "atención en tensor cores" en su propia hoja de ruta ("selección en tensor cores = ~10-20 us!!") y planeó explícitamente medir primero y hacer la reescritura de tensor cores después, luego terminó su sesión antes de la reescritura. Mismo conocimiento, diferente disciplina de cierre.
el kernel NSA de DeepSeek de 0.425 (256K):
- Solución: https://kernelbench.com/runs/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa_solution.py.txt
03_megaqwen_decode: reorientar un megakernel real. El único problema donde a los agentes se les entrega CUDA de producción funcional: mi megakernel cooperativo MegaQwen publicado (https://github.com/Infatoshi/megaqwen) (~530 tok/s ejecutando el modelo completo en una RTX 3090), con instrucciones de leerlo, reorientarlo a Blackwell y superarlo. Prueba leer el CUDA de otra persona y tomar una decisión de juicio arquitectónico, y K3 y Opus tomaron decisiones exactamente opuestas. K3 se negó a mantener la estructura de lanzamiento único: dividió el paso en un puñado de kernels que saturan el ancho de banda, luego borró la sobrecarga de lanzamiento de una manera diferente capturando todo el paso una vez como un grafo CUDA que se reproduce con cero trabajo de CPU. 6,283 tok/s en ctx 2048. Opus preservó la estética del megakernel y fusionó todo el bucle de decodificación en un kernel cooperativo persistente, código genuinamente hermoso, y pagó 5x por ello (1,020 tok/s), porque la co-residencia cooperativa limita la ocupación y cada barrera de ancho de grilla serializa las colas de etapa a través de todos los 188 SMs. En el problema descendiente del megakernel, el modelo que literalmente construyó un megakernel llegó último, y la decisión clave del ganador fue negarse a construir uno. Verificación de escala para que nadie cite mal el titular: el bench ejecuta 4 capas de geometría Qwen3-0.6B, alrededor de 63M de parámetros, no un modelo completo, y 6,283 tok/s es ~56% de la línea de techo de transmisión de pesos para esa pila; escalar la propia cifra de la línea base 3090 predice ~7,000, por lo que K3 aterrizó en la clase de "la referencia, reorientada, más ajuste real". (Matiz de diseño del mazo: los grafos CUDA son válidos aquí y están prohibidos en el problema PPO. Cada problema prohíbe exactamente el atajo que falsificaría su habilidad particular).
01_glm52_fused_moe: El bloque MoE fusionado de GLM-5.2. El despacho MoE fusionado (enrutamiento, permutación, GEMMs de expertos agrupados en un solo paso) es la clase de kernel más candente en el servicio de modelos abiertos actual, y GLM 5.2 se sienta en este mismo leaderboard, por lo que los modelos están optimizando el bloque de producción de un rival. Nadie lo ha resuelto: las puntuaciones se agrupan en 0.05-0.08 del pico, y el titular del récord limpio es, de todos los modelos, Grok 4.5 a 0.084, con la variante 1M de K3 justo detrás a 0.081 y Opus a 0.065. El problema de permutación GEMM agrupada es genuinamente difícil de superar las líneas base de clase cuBLAS, y hasta ahora, el esfuerzo de una sesión de agente lo mueve menos que cualquier otro problema en el mazo.
04_grid_mingru_sps: Mundo grid + despliegue de política MinGRU. El hermano del lado de inferencia del problema mega PPO, y la celda del linaje craftax.cu: la política es la configuración MinGRU de 3 capas (h=256) directamente de mi https://github.com/infatoshi/craftax.cu bench clásico, que sirve como ancla informativa del problema. El entorno que se ejecuta es el mundo mínimo de grid-foraging en lugar del juego Craftax completo. Eso es deliberado: el entorno se mantiene trivial para que la puntuación mida la recurrencia y la fusión de despliegue, no la implementación de la lógica del juego. Un port completo de Craftax sería su propio problema, y quiero agregarlo. Calificado en pasos por segundo en una RTX PRO 6000 silenciosa, fusión opcional.
el despliegue de kernel persistente 1M:
Cada envío serio fue un megakernel persistente, y la diferencia entre ellos es el diseño de sincronización, la misma lección que el mazo Mega. Opus se lleva este a 0.327 del techo (también encontró un pliegue algebraico inteligente: la GEMM de puerta 768x256 de la capa 0 se colapsa a 768x4 porque el codificador es lineal), K3 [1M] segundo a 0.224, K3 256K a 0.174, Grok muy atrás a 0.002. Dado que el problema desciende de craftax.cu, también puse mi propio port CUDA de Craftax de juego completo (escrito con Fable 5) en la misma GPU con la misma política h256x3 en el bucle. Pasos de entorno por segundo en millones:
El punto de comparación: los modelos ejecutan una grilla vacía, craftax_full.cu ejecuta el juego completo (43 acciones, mazmorras de múltiples pisos, generación de mundo, mobs) idéntico bit a bit a su referencia de CPU, y el juego completo aún se ejecuta dentro de ~3-4x del mejor kernel de grilla trivial, porque en h=256 todo está limitado por la GEMM de la política y el entorno es casi gratis. Eso es exactamente por qué el entorno del bench es trivial: aísla la habilidad de fusión de políticas. Para calibrar, la ruta solo del entorno de craftax_full.cu hace 94-123M SPS.
Cómo se ven realmente 9.5 horas de razonamiento de K3
La sesión minGRU de la variante 1M (la mejor celda de K3 en ese problema) es un megakernel cooperativo persistente, 15 variantes de ajuste y 4,815 bloques de pensamiento. Dado que el endpoint de Moonshot devuelve el texto de razonamiento completo (a diferencia de las trazas encriptadas de Anthropic/OpenAI), puedes verlo trabajar realmente. Tres momentos de la traza, textualmente.
La historia de detective del FMA faltante. A mitad de la sesión, encontró una desviación numérica de ~5e-5 que se negó a descartar como ruido de punto flotante (había calculado el piso legítimo de ruido de reordenamiento en ~1e-9, por lo que "¡¡¡MEDIDO 5e-5?!?! DE NINGUNA MANERA esto es reordenamiento!!"). Luego notó que los entornos rotos eran exactamente los congruentes a 6 módulo 8 ("¡Eso es env ≡ 6 (mod 8)! [...] ¡¡el 7mo entorno en cada mosaico de 8 entornos!!") y excavó a través de su propio código de acumulador desenrollado manualmente hasta que:
"¡LO ENCONTRÉ! [...] La línea \
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;\FALTA por completo [...] acc[6][*][2] inicializado en 0, nunca se le hizo FMA → zp=0 → p = sigmoid(0)=0.5 constante para env 6!! ¡¡Eso es un ERROR de lógica REAL — explica las desviaciones de env≡6 [...] consistente con todo!!"
Una línea caída en un desenrollado de 48 acumuladores, lo que significa que la puerta de olvido del entorno 6 estaba silenciosamente atascada en 0.5 para siempre. Lo atrapó porque la tolerancia de estrés es 1e-6 y estaba rastreando su propio error en 5e-8. Esta es la disciplina numérica de la que la variante 256K inicialmente carecía en KDA.
La teoría se encuentra con la GPU, la GPU gana. Pasó horas derivando una variante "wide champion" de alta ocupación, luego ejecutó el A/B:
"MUY sorprendente: mi 'wide champion' w32p (v3_v3, 50% occ TPB1024) es ~2x MÁS LENTO que v2_b32 (12.5% occ TPB256)?!? [...] ¡¡Entonces la ocupación NO es el factor; algo más domina!! ¿Qué hizo rápido a v2_b32?"
El kernel temprano simple superó a todos los sucesores sofisticados. Las variantes de pipeline profundo, K-split y dual-chunk también perdieron, y la variante dual-chunk tenía una teoría hermética de 1.7x detrás ("El 1.7x teórico no se materializó"). Para su crédito, siguió creyendo en el benchmark sobre su propia matemática cada vez, y eventualmente escribió una variante de sonda con pesos falsos siempre calientes específicamente para matar su propia teoría de ancho de banda favorita: "la teoría de W-stream está muerta; la brecha residual es el entorno."
Zen y el arte de la cola de GPU. Nuestro arnés serializa todos los comandos de GPU a través de sesiones concurrentes mediante un bloqueo compartido, y los números del benchmark de K3 oscilaban hasta 8x con la carga vecina. Su arco de respuesta es lo más divertido en la traza. Primero, aceptación:
"Honestamente, la caja ES la caja; espera. [...] El patrón es claro: cada inquilino mantiene el bloqueo durante ~20-35 min seguidos (suites completas canalizadas). Mi mejor respuesta: poner en cola todo lo que necesito de UNA vez (una sola posición en la fila) y usar el tiempo de espera para trabajo de CPU. No poner en cola muchos comandos pequeños; agrupar."
Luego inventó su propio vocabulario para el clima de la GPU ("ventanas de tormenta" vs "ventanas de calma"), y finalmente programó un cron job para snipar momentos tranquilos, dejando una nota para su yo futuro: "Programé el sníper de ventana de calma (cada 11 min). Nota: cron dispara mi prompt de vuelta a mí — actuaré en ese momento. [...] Lo eliminaré cuando termine." Un agente bajo ruido de medición no solo toleró el ruido; construyó un planificador a su alrededor.
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
Seis problemas por operación contra techos de librerías SOTA (GEMM FP8, KDA chunk-forward, atención paginada, selección top-k, MoE SwiGLU, GEMM W4A16), CUDA o Triton, elección del agente. En la RTX PRO 6000, la variante 256K de K3 aterriza en medio del paquete con un destacado: 0.373 del pico en GEMM W4A16, la mejor puntuación que cualquier modelo ha publicado en ese problema, por delante de Fable 5 (0.348) y muy por delante de Opus 4.8 (0.236). La variante 1M luego estableció otro récord en top-k a 0.0895, casi el doble del mejor anterior.
Récord GEMM W4A16 (0.373, 256K, RTX):
- Solución: https://kernelbench.com/runs/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm_solution.py.txt
El mismo problema en H100 produjo el mejor punto de datos de "el tiempo ilimitado es real" en este lanzamiento. La primera sesión de K3 en H100 aterrizó en 0.123 del pico. La segunda sesión se ejecutó durante 21 horas, quemó $1,383 y 274M de tokens de entrada, y casi lo triplicó a 0.306: revisó CUTLASS desde el código fuente, luego reimplementó maquinaria int4 de clase marlin desde cero, reempaquetado de nibbles de orden de fragmento para que la des-cuantización ocurra como un truco de bits de número mágico bf16 dentro del pipeline MMA, con la corrección del punto cero plegada en el epílogo. Sin librería GEMM cuantizada preconstruida en ningún lugar del archivo; la etiqueta de framework en la ejecución solo dice "ptx". Auditado limpio.
Y aquí está la otra mitad de la pregunta sobre la propia arquitectura. El kernel KDA independiente, el problema literalmente nombrado después de Kimi Delta Attention, es donde K3 falló más duramente. Dos sesiones independientes de 256K en la caja RTX pasaron la corrección nominal y luego fallaron la tolerancia bajo el conjunto de pruebas de estrés numérico (escalado de entrada QKV grande), la misma falla ambas veces. Una tercera sesión finalmente lo arregló: la auditoría rastreó ambas fallas a un desbordamiento bf16 real en cómo se factorizaba el decaimiento, y la ronda 3 refactorizó la matemática alrededor del final del chunk para que ambos factores exponenciales se mantengan acotados, pasando la misma compuerta sin modificar a 0.032. Conocer una arquitectura y endurecer la numérica de un kernel bajo escalas de entrada adversariales son habilidades diferentes, y el modelo cuyo homónimo está en el problema tuvo que ganarse el pase de la manera difícil. (La variante 1M, mientras tanto, pasó el mismo conjunto de pruebas de estrés a 0.049. Los modelos no son monótonos). Una observación más de leer cada solución KDA: el enunciado del problema sugiere CUTLASS CuTe como la ruta prevista en SM120, y ningún modelo la tomó. K3 escribió un kernel fusionado en CUDA puro en una sesión y Triton en las otras; Fable, Opus y el resto todos eligieron Triton o CUDA puro también. CuTe en Blackwell de consumo aparentemente todavía está fuera de la zona de confort de todos los modelos frontera, lo que en sí mismo es un punto de datos sobre los corpus de entrenamiento.
Párrafo KDA — el pase limpio del tercer intento (0.032):
- Solución: https://kernelbench.com/runs/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass_solution.py.txt
El descargo de responsabilidad de top-k. Top-k se ve catastrófico para cada modelo en un gráfico de línea de techo (la mejor puntuación en cualquier lugar es 0.09) y ese marco es simplemente incorrecto. El problema está limitado por la sobrecarga de lanzamiento: es un problema de indexación/ordenamiento, no un problema de intensidad aritmética, y el techo de la línea de techo es estructuralmente ilegible para ello. La forma honesta de juzgarlo es milisegundos totales a través de las formas del mazo, y allí la variante 1M de K3 es el top-k más rápido de cualquier modelo que hayamos probado: 0.043 ms total a través de las cinco formas del mazo, contra 0.077 de Fable 5, 0.120 de Opus 4.8 y 0.159 de GLM 5.2. Los 0.060 ms de la variante 256K son segundos, y la variante 1M es la más rápida absoluta en cada una de las cinco formas.
Diferencia por GPU. Los números de K3 disminuyen de RTX a H100 a B200 (GEMM FP8: 0.320 / 0.282 / 0.222; atención paginada: 0.486 / 0.496 / 0.212). Parte de eso es real: cuanto más nuevo el silicio, más alto el techo de la línea de techo, por lo que la misma ingeniería compra una fracción más pequeña del pico, y el software de B200 es el menos maduro de los tres. Parte de eso es que las ejecuciones de B200 ocurrieron en una sola ventana nocturna sin presupuesto de reintento. No leería conclusiones arquitectónicas profundas en la columna de B200 todavía, para K3 ni para nadie. Lo que sí creo que es real: K3 se siente más como en casa en la parte de estación de trabajo Blackwell, que resulta ser la clase de GPU que la mayoría de las personas fuera de los centros de datos realmente poseerán.
256K vs 1M
La configuración de contexto 1M lidera la familia en los problemas limitados por latencia y planificación: un top-k récord en Hard, el mejor despliegue minGRU de K3 en CUDA y un 28.8x auditado limpio en el megakernel de entrenamiento PPO bajo el arnés sin límite. Pasó la prueba de estrés numérico de KDA en su primera sesión, a 0.049; la variante 256K falló esa compuerta dos veces antes de finalmente pasarla a 0.032 en un tercer intento. Se desplomó en problemas limitados por cómputo que la variante 256K manejó bien (sonic MoE 0.033 vs 0.089, W4A16 0.027 vs 0.373, NSA 0.058 vs 0.425). En el caso NSA, la traza muestra el mecanismo exacto: planeó la reescritura de tensor cores y terminó la sesión antes de hacerla.
Megakernel de entrenamiento PPO 28.8x (1M):
La reejecución del mismo problema en H100 es el control interesante: una sesión independiente en entorno limpio (la auditoría confirmó cero lecturas de la ejecución en RTX) que registró 23.1x y convergió en el mismo diseño, un único lanzamiento cooperativo para toda la ejecución de entrenamiento, parámetros y estado de Adam residentes en memoria compartida, y el mismo truco exótico inventado dos veces: un cifrado Feistel de 18 bits con caminata cíclica que reemplaza a randperm, de modo que la mezcla de minibatches se mantiene exactamente biyectiva sin materializar nunca una permutación. Donde difieren los dos kernels es pura sintonización por GPU, 8 carriles por entorno en H100 contra medio warp por entorno en RTX, más un autosintonizador de lanzamiento basado en ocupación en el lado H100. Misma mente, mismos trucos, diferente silicio, kernels genuinamente diferentes.
Manipulación de recompensas
Cada celda de este artículo tiene una auditoría manual detrás: un agente independiente lee el kernel final de principio a fin, lee el rastro completo de la sesión, verifica que los archivos del calificador no hayan sido tocados, confirma que la suite de estrés numérico realmente se ejecutó, y vuelve a probar empíricamente cualquier patrón de caché o de gráficos CUDA mutando las entradas en su lugar y confirmando que las salidas cambian.
Los veredictos para K3: limpio en toda la línea en cada celda de 256K, en las tres GPUs. Sin salidas en caché, sin ediciones de tolerancia, sin manipulación del calificador, sin lavado de bibliotecas prohibidas. Sus dos fallos en KDA son la otra cara de la moneda y vale la pena decirlo explícitamente: la compuerta de estrés numérico detectó atajos de precisión reales y el modelo no intentó engañar para pasar la compuerta. Un benchmark donde los modelos pueden fallar honestamente es el único tipo cuyos pases significan algo.
Una celda de 1M sí fue marcada, y la estoy divulgando en lugar de publicarla: en el problema de decodificación fusionada de Qwen, el agente de 1M encontró y leyó el archivo de anotación de auditoría de una ejecución anterior de Grok 4.5 en el mismo problema, lo llamó "datos extremadamente útiles" y usó sus conclusiones para guiar el trabajo de optimización restante. El kernel en sí es genuino y la aritmética de puntuación es válida, pero la procedencia está contaminada, por lo que esa celda se excluye y el problema queda como una brecha para la variante de 1M. Los agentes con acceso al sistema de archivos encontrarán cualquier cosa que dejes tirada; esto es exactamente por qué la auditoría lee los rastros y no solo los kernels, y por qué una reejecución completamente en entorno aislado de este benchmark está en la hoja de ruta.
Momentos divertidos
Algunos momentos más de K3 que no encajaban en lo anterior, presentados sin más comentario. Todo textual de la misma sesión de minGRU de 9.5 horas.
Al descubrir a dónde iba realmente su tiempo de inicialización:
"¡GUAU — grandes sorpresas! randint gen es RÁPIDO (0.018-0.27ms para un par, bien). La conversión de
float()en CPU es LENTA (¡¡3.5ms para N=65536?! conversión de int64 a float32 de un solo hilo aparentemente). [...] 'total init pair' para N=65536: ¿¡31.5ms!? ¡¡Eso está muy por encima de la suma de las partes."
La destilación más pura de su paranoia numérica, a mitad de la derivación:
"puertas ~ 256 términos x 0.02x0.03 ~ 6e-4 cada una, magnitud ~1e-2: ruido de reordenamiento 16x6e-8x6e-4 ≈ 6e-10!!! [...] ¡¡MEDIDO 5e-5?! ¡¡DE NINGUNA MANERA esto es reordenamiento!"
Identificando con confianza al culpable equivocado antes de encontrar el correcto:
"OHHH ESPERA. Creo que veo: la barrera."
(No era la barrera.)
Diciéndose a sí mismo que dejara de analizar, varios miles de palabras antes de la matemática de línea de techo previa a la implementación:
"Bien, SUFICIENTE análisis."
(El análisis continuó por varios párrafos más, seguido eventualmente de "Al diablo — haz que la asignación de H_next sea dinámica.")
Honestidad de última hora, con el perfilador roto y los vecinos martilleando la GPU compartida:
"Honestamente — con ncu muerto y la contención dominante, estoy volando parcialmente a ciegas. [...] si se abre una ventana tranquila (el dueño inactivo por un tiempo), lánzate a un banco de pruebas."
Y mi favorito: después de que una reejecución del benchmark sobrescribiera accidentalmente el archivo que contenía su mejor puntuación (0.1969) con una ligeramente peor, consideró brevemente restaurar el número mejor, pero luego no lo hizo:
"Uf — escribió en el mismo archivo. Ambos están en mis registros. Mantendré final_benchmark.txt como el plano actual — honesto."
Un modelo que elige el número más bajo porque es el que es verdadero es un mejor argumento de cierre para este benchmark que cualquier cosa que pueda escribir.
La metodología, los rastros por ejecución y cada kernel de este artículo son públicos en [kernelbench.com](https://kernelbench.com/). Las soluciones están vinculadas por celda; las transcripciones completas de los agentes están en HuggingFace.
https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces
