Este es el post sobre Kimi K3 que estaban esperando. Tuve acceso anticipado a este modelo y lo estuve probando en kernels, y antes incluso de ver las puntuaciones de los benchmarks, ya me impresionó su capacidad para razonar problemas y la densidad técnica de sus trazas de pensamiento. El post-entrenamiento de esta cosa es evidente desde el momento en que lees una transcripción. También es muy divertido hablar con él.
TL;DR;
Creo que es importante que dé mi opinión sincera (esta parte está escrita con voz) como ingeniero de kernels y rendimiento, desvinculado de los benchmarks. Por supuesto, puedes mirar todos los números, leerlos e intentar desarrollar un modelo mental propio. Creo que el reflejo más honesto es contar 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 que conectar con otros modelos. Solo sintiendo puramente la inteligencia, el razonamiento, la delegación de agentes y cuánto piloto automático puede hacer por mí, pero antes de que hubiera hype y llegaran los resultados oficiales. Diría que, con mi dirección, se sintió más o menos 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 opiniones honestas y las puntuaciones tal como están, no guardármelas hasta que termine cada última celda. Todavía hay algunas ejecuciones en curso mientras escribo esto. Están marcadas abajo, y les mantendré al tanto cuando lleguen. Ejecuté versiones de contexto de 256K y 1M. Todo lo que hay aquí se ejecutó en NVIDIA RTX PRO 6000 Blackwells, H100s y B200s, con optimización de una sola GPU. Cada celda es una sesión de agente autónomo con tiempo 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 recompensa engañosa. 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 parezca 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 para la que diseñé específicamente este lanzamiento: dos de los problemas son de la propia arquitectura de Moonshot. La baraja Hard tiene un kernel independiente de avance por fragmentos de Kimi Delta Attention, y el problema insignia de la baraja Mega es un paso de decodificación híbrido completo de Kimi-Linear: capas KDA, atención MLA, expertos MoE, todo el bloque. Así que esta era 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, ¿se nota el conocimiento de la familia en el CUDA?
La respuesta resultó ser genuinamente dividida, y ambas mitades son interesantes. Tengan esa pregunta en mente durante la siguiente sección.
KernelBench-Mega
El problema mega insignia: fusionar un paso de decodificación completo de Kimi-Linear por token (3 capas KDA + 1 capa MLA, pesos cuantizados W4A16, MoE con enrutamiento top-8) en la menor cantidad de lanzamientos de kernel posible.
K3 casi se llevó el récord absoluto, en su propio linaje. 18.09x de aceleración geométrica sobre eager en la RTX PRO 6000, a menos del 4% del récord de Fable 5 de 18.72x. En H100 obtuvo 14.82x frente a 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 desplaza la línea base eager contra la que se calcula la relación), así que informo ambas para no dejar que la media geométrica 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 y escribió todo el paso de decodificación por token como UN kernel CUDA lanzado de forma cooperativa: cero CPU en el bucle, pesos int4 des-cuantizados sobre la marcha dentro de cada GEMV para que fluyan por 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 esa restricción, y sacar a la luz exactamente este tipo de cosas es para lo que existe el benchmark.
Ver el megakernel aquí:
Entonces, ¿por qué perdió contra Fable? No fue por el tiempo. Ambas sesiones se autofinalizaron 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ían: K3 es el que usa tensor cores, y el kernel de Fable contiene cero instrucciones MMA. La decodificación de lote 1 con GEMVs int4 fusionados está limitada por ancho de banda, por lo que los tensor cores apenas compran nada aquí. Fable gastó ese esfuerzo en sincronización, reemplazando la mayoría de sus barreras globales con traspasos productor-consumidor de grano fino para que ningún SM esté inactivo en un límite de etapa, y en una ruta de des-cuantización int4 que coincide con el redondeo del 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 gana la segunda. 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 de forrajeo en cuadrícula: 4,096 agentes vectorizados en un tablero de 11x11, con todo el bucle de entrenamiento RL (paso de entorno, avance de política, muestreo de acciones, GAE, la actualización de PPO) ejecutándose como kernels persistentes fusionados. Este problema tiene la restricción más estricta de la baraja: el recuento de lanzamientos de kernel no debe escalar con los pasos de entorno, y la captura de gráficos CUDA está explícitamente prohibida como solución para la sobrecarga de lanzamiento, aplicada por un juez de autenticidad posterior a la 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 en todas las semillas y requiere que el retorno caiga en una banda, por lo que no puedes saltarte el aprendizaje para ir rápido. K3 obtuvo 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 tómenlo como un punto de datos, no como un podio).
KernelBench-CUDA
El benchmark CUDA existe porque Triton es una muleta que las otras dos barajas permiten. Aquí un bloque de lenguaje falla duramente a Triton, los DSL de kernel y las cadenas de operaciones de PyTorch: escribes CUDA o fallas. Elegí los cuatro problemas para que fueran fragmentos de cargas de trabajo reales de inferencia y simulación de producción. La comparación mental al leer debería ser "¿qué envía vLLM o SGLang hoy para esto, y qué tan cerca llega una sesión de agente?". Aquí es donde K3 obtuvo sus victorias más desiguales.
02_deepseek_nsa: Atención Dispersa Nativa de DeepSeek. NSA es el diseño de atención de dispersión entrenable insignia, la cosa alrededor de la cual está girando cada pila de servicio de contexto largo, 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 de 256K de K3 obtuvo 0.425 frente a 0.178 de Opus 4.8, un margen de 2.4x, escribiendo lo que equivale a un pipeline de tensor-core desde cero, clase flash-attention, alrededor de la lógica de selección completa de NSA. La comparación más aguda está dentro de la familia: la variante de 1M escribió el mismo algoritmo, selección de bloques idéntica, misma corrección, pero ejecutó cada producto punto en núcleos CUDA simples en lugar de tensor cores y obtuvo 0.058, 7x más lento en formas idénticas. Su traza muestra que lo sabía. Tenía "atención con 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 con 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 los agentes reciben 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 la lectura de 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 un solo lanzamiento: dividió el paso en un puñado de kernels que saturan el ancho de banda, luego eliminó la sobrecarga de lanzamiento de otra manera capturando todo el paso una vez como un gráfico CUDA que se reproduce sin 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 núcleo 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 cuadrícula serializa las colas de etapa en los 188 SMs. En el problema descendiente del megakernel, el modelo que literalmente construyó un megakernel quedó ú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 benchmark 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 de la 3090 predice ~7,000, por lo que K3 aterrizó en la clase de "la referencia, reorientada, más ajuste real". (Matiz de diseño de baraja: los gráficos CUDA están permitidos aquí y prohibidos en el problema PPO. Cada problema prohíbe exactamente el atajo que falsificaría su habilidad particular.)
01_glm52_fused_moe: 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 actual de modelos abiertos, y GLM 5.2 se encuentra en esta misma tabla de clasificación, por lo que los modelos están optimizando un bloque de producción de un rival. Nadie lo ha descifrado: las puntuaciones se agrupan en 0.05-0.08 del pico, y el poseedor del récord limpio es, de todos los modelos, Grok 4.5 con 0.084, con la variante de 1M de K3 justo detrás con 0.081 y Opus con 0.065. El problema de permutación de GEMM agrupado 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 la baraja.
04_grid_mingru_sps: Mundo de cuadrícula + despliegue de política MinGRU. El hermano del lado de inferencia del problema PPO mega, 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 benchmark clásico, que sirve como ancla informativa del problema. El entorno que se recorre es el mundo minimalista de forrajeo en cuadrícula en lugar del juego completo Craftax. Eso es deliberado: el entorno se mantiene trivial para que la puntuación mida la recurrencia y la fusión del despliegue, no la implementación de la lógica del juego. Un puerto completo de Craftax sería su propio problema, y quiero agregarlo. Calificado en pasos por segundo en una RTX PRO 6000 tranquila, fusión opcional.
el despliegue de kernel persistente de 1M:
Cada envío serio fue con megakernel persistente, y la diferencia entre ellos es el diseño de sincronización, la misma lección que en la baraja mega. Opus se lleva esta con 0.327 del techo (también encontró un pliegue algebraico ingenioso: el GEMM de puerta 768x256 de la capa 0 se colapsa a 768x4 porque el codificador es lineal), K3 [1M] segundo con 0.224, K3 256K con 0.174, Grok muy atrás con 0.002. Dado que el problema desciende de craftax.cu, también puse mi propio puerto 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 recorren una cuadrícula vacía, craftax_full.cu recorre el juego completo (43 acciones, mazmorras de varios 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 cuadrícula trivial, porque en h=256 todo está limitado por el GEMM de la política y el entorno es casi gratis. Eso es exactamente por qué el entorno del benchmark es trivial: aísla la habilidad de fusión de política. Para calibrar, la ruta solo de entorno de craftax_full.cu hace 94-123M SPS.
Cómo se ven realmente 9.5 horas de razonamiento de K3
La sesión de minGRU de la variante de 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. 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 de ruido de reordenamiento legítimo en ~1e-9, por lo que "¡¡MEDIDO 5e-5?!?! DE NINGUNA MANERA es reordenamiento!!"). Luego notó que los entornos rotos eran exactamente los congruentes con 6 mod 8 ("¡Eso es env ≡ 6 (mod 8)! [...] ¡¡el 7º entorno en cada mosaico de 8 entornos!!") y profundizó en su propio código de acumulador desenrollado a mano hasta:
"¡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 FMA'd → zp=0 → p = sigmoide(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 perdida en un desenrollado de 48 acumuladores, lo que significa que la puerta de olvido de env 6 estaba silenciosamente atascada en 0.5 para siempre. Lo detectó 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 de 256K carecía inicialmente en KDA.
La teoría se encuentra con la GPU, la GPU gana. Pasó horas derivando una variante "campeona ancha" de alta ocupación, luego ejecutó el A/B:
"MUY sorprendente: ¡mi 'campeón ancho' 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 determinante; 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, división K y doble fragmento también perdieron, y la de doble fragmento tenía una teoría sólida de 1.7x detrás ("El 1.7x teórico no se materializó"). Para su crédito, siguió creyendo en el benchmark sobre sus propias matemáticas cada vez, y finalmente escribió una variante de sonda con pesos falsos siempre calientes específicamente para matar su propia teoría favorita de ancho de banda: "la teoría de transmisión de W 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 en sesiones concurrentes a través de un bloqueo compartido, y los números de benchmark de K3 oscilaban hasta 8x con la carga del vecino. Su arco de respuesta es lo más divertido de la traza. Primero, aceptación:
"Honestamente, la caja ES la caja; espera. [...] El patrón está claro: cada inquilino mantiene el bloqueo durante períodos de ~20-35 min (suites completas con pipeline). 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 tranquilas"), y finalmente programó un trabajo cron para cazar momentos tranquilos, dejando una nota para su yo futuro: "Programé el francotirador de ventana tranquila (cada 11 min). Nota: cron me devuelve mi mensaje — actuaré en ese momento. [...] Lo borraré 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 bibliotecas SOTA (GEMM FP8, avance de fragmentos KDA, 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 de 256K de K3 aterriza en medio del grupo 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 de 1M luego estableció otro récord en top-k con 0.0895, casi el doble del mejor anterior.
Récord de 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 duró 21 horas, quemó $1,383 y 274M de tokens de entrada, y casi lo triplicó a 0.306: descargó CUTLASS de la fuente, luego reimplementó la maquinaria int4 clase marlin desde cero, reempaquetado de nibbles en orden de fragmento para que la descuantización ocurra como un truco de bits de número mágico bf16 dentro del pipeline MMA, con la corrección del punto cero doblada en el epílogo. No hay ninguna biblioteca de GEMM cuantizado preconstruida en ningún lado del archivo; la etiqueta de framework en la ejecución solo dice "ptx". Auditoría limpia.
Y aquí está la otra mitad de la pregunta sobre la arquitectura propia. 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), el mismo fallo ambas veces. Una tercera sesión finalmente lo arregló: la auditoría rastreó ambos fallos a un desbordamiento bf16 real en cómo se factorizaba la decadencia, y la ronda 3 reformuló las matemáticas alrededor del final del fragmento para que ambos factores exponenciales se mantengan acotados, pasando la misma puerta no modificada en 0.032. Conocer una arquitectura y endurecer la numérica de un kernel bajo escalas de entrada adversarias 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 de 1M, mientras tanto, pasó el mismo conjunto de pruebas de estrés en 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 sigue estando 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 parece catastrófico para todos los modelos 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 sobrecarga de lanzamiento: es un problema de indexación/ordenamiento, no de intensidad aritmética, y el techo de la línea de techo es estructuralmente ilegible para él. La forma honesta de juzgarlo es los milisegundos totales en todas las formas de la baraja, y allí la variante de 1M de K3 es el top-k más rápido de cualquier modelo que hayamos probado: 0.043 ms en total en las cinco formas de la baraja, frente a 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 de 256K son segundos, y la variante de 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 es el silicio, más alto es 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, ni para K3 ni para nadie. Lo que sí creo que es real: K3 está más cómodo en la parte de la 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 de 1M lidera la familia en los problemas limitados por latencia y planificación: un récord de top-k en Hard, el mejor despliegue de 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, con 0.049; la variante de 256K falló esa puerta dos veces antes de finalmente pasar con 0.032 en un tercer intento. Se derrumbó en problemas limitados por cómputo que la variante de 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 de NSA, la traza muestra el mecanismo exacto: planeó la reescritura con tensor cores y terminó la sesión antes de hacerla.
Megakernel de entrenamiento PPO 28.8x (1M):
La repetició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 obtuvo 23,1x y convergió en el mismo diseño, un 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 cycle-walking como sustituto de randperm, de modo que el barrido de minibatch se mantiene exactamente biyectivo sin materializar nunca una permutación. Donde difieren los dos kernels es en el ajuste puro por GPU: 8 lanes por entorno en H100 frente a medio warp por entorno en RTX, más un autotuner de lanzamiento basado en ocupación en el lado de H100. Misma mente, mismos trucos, diferente silicio, kernels genuinamente diferentes.
Recompensa por trampas (Reward hacking)
Cada celda de esta publicación 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 CUDA-graph mutando las entradas in situ y confirmando que las salidas cambian.
Los veredictos para K3: limpio en todos los aspectos 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 esa moneda y vale la pena decirlo explícitamente: la puerta de estrés numérico detectó atajos de precisión reales y el modelo no intentó sortear la puerta con trampas. Un benchmark donde los modelos pueden fallar honestamente es el único tipo cuyos aprobados significan algo.
Una celda de 1M sí fue marcada, y la estoy revelando 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 queda excluida y el problema se registra como una brecha para la variante de 1M. Los agentes con acceso al sistema de archivos encontrarán cualquier cosa que dejes por ahí; esto es exactamente por qué la auditoría lee los rastros y no solo los kernels, y por qué una repetición completamente aislada de este benchmark está en la hoja de ruta.
Momentos divertidos
Algunos momentos más de K3 que no encajaron en ninguna parte anterior, presentados sin más comentarios. 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,27 ms para un par — bien). La conversión
float()en CPU es LENTA (¡¡3,5 ms para N=65536?! conversión int64→float32 aparentemente monohilo). [...] 'total init pair' para N=65536: ¡¡31,5 ms?!?! 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 derivación:
"puertas ~ 256 términos x 0,02x0,03 ~ 6e-4 cada uno, magnitud ~1e-2: ruido de reordenamiento 16x6e-8x6e-4 ≈ 6e-10!!! [...] ¡¡MEDIDO 5e-5?!?! ¡¡DE NINGUNA MANERA 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 después de las matemáticas de roofline previas a la implementación:
"Muy bien, SUFICIENTE análisis."
(El análisis continuó durante 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 golpeando la GPU compartida:
"Honestamente — con ncu muerto y contención dominante, estoy volando parcialmente a ciegas. [...] si se abre una ventana tranquila (el propietario inactivo por un rato), aprovecha un benchmark."
Y mi favorito: después de que una repetición de 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, luego no lo hizo:
"Uf — escribió en el mismo archivo. Ambos están en mis registros. Me quedaré con 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.
Metodología, rastros por ejecución y cada kernel en esta publicación son públicos en kernelbench.com. Las soluciones están enlazadas 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
