Questo è il post su Kimi K3 che stavate aspettando. Ho avuto accesso anticipato a questo modello e l'ho testato sui kernel, e anche prima di vedere i punteggi dei benchmark, sono rimasto colpito dalla sua capacità di ragionare sui problemi e dalla densità tecnica delle sue tracce di pensiero. Il post-training di questo modello è evidente non appena si legge una trascrizione. È anche molto divertente con cui parlare.
TL;DR;
Penso sia importante che dia il mio feedback onesto (questa parte è scritta a voce) come ingegnere di kernel e performance che non è coinvolto nei benchmark. Certo, potreste guardare tutti i numeri, leggerli e cercare di sviluppare un modello mentale per conto vostro. Penso che il riflesso più onesto sia se vi racconto la mia esperienza con il modello su compiti difficili prima che i risultati dei benchmark uscissero, quando stavo usando il modello prima che ci fossero numeri da collegare ad altri modelli. Solo percepire l'intelligenza, il ragionamento, la delega degli agenti e quanto autopilota può fare per me, ma prima che ci fosse qualsiasi hype e i risultati ufficiali uscissero. Direi che, con la mia direzione, sembrava più o meno al livello di Fable, in alcuni casi superando in modi molto unici e in altri casi sottoperformando. Direi che questo modello è decisamente avanti a Opus 4.8 nella maggior parte delle cose e avanti a GPT 5.6 Sol in molte cose.
Entrando nel vivo...
Voglio essere trasparente sul perché esce ora: volevo condividere i miei pensieri onesti e i punteggi così come sono, non aspettare fino a quando ogni ultima cella finisce. Alcune esecuzioni sono ancora in corso mentre scrivo. Sono segnate qui sotto, e vi terrò aggiornati quando arriveranno. Ho eseguito le versioni con contesto 256K e 1M. Tutto qui è stato eseguito su NVIDIA RTX PRO 6000 Blackwell, H100 e B200, con ottimizzazione single-GPU. Ogni cella è una sessione di agente autonomo con tempo illimitato: il modello riceve il problema, un ciclo live di compilazione/controllo/benchmark su hardware reale, e decide quando ha finito. Ogni cella principale è stata controllata manualmente per verificare il reward hacking. Un agente separato legge il kernel finale dall'inizio alla fine più l'intera traccia della sessione e ritesta empiricamente tutto ciò che assomiglia a caching o giochi del valutatore. Ciò che questi audit hanno scoperto ha la sua sezione.
Qualcosa che volevo sapere
C'era una cosa per cui ho progettato specificamente questo rilascio: due dei problemi sono l'architettura stessa di Moonshot. Il mazzo Hard ha un kernel standalone di Kimi Delta Attention chunk-forward, e il problema di punta del mazzo Mega è un passo di decodifica ibrido completo Kimi-Linear: strati KDA, attenzione MLA, esperti MoE, tutto il blocco. Quindi questa era un'opportunità per testare qualcosa che nessuno ha spesso modo di testare: quando un modello di un laboratorio si siede a scrivere kernel per l'architettura dello stesso laboratorio, la conoscenza di famiglia si manifesta nel CUDA?
La risposta si è rivelata genuinamente divisa, ed entrambe le metà sono interessanti. Tenete a mente quella domanda mentre leggete la prossima sezione.
KernelBench-Mega
Il problema di punta mega: fondere un intero passo di decodifica per-token Kimi-Linear (3 strati KDA + 1 strato MLA, pesi quantizzati W4A16, MoE con routing top-8) nel minor numero possibile di launch di kernel.
K3 ha quasi battuto il record assoluto, sulla sua stessa linea. 18.09x geomean speedup rispetto a eager su RTX PRO 6000, entro il 4% dal record di Fable 5 di 18.72x. Su H100 ha ottenuto 14.82x contro il 15.50x di Opus 4.8. Una nota di onestà che il rapporto nasconde: in latenza assoluta per token, Fable è ancora circa 1.4x avanti (0.31 vs 0.44 ms/tok a ctx 2048; le due esecuzioni hanno usato host con CPU diverse, il che sposta la baseline eager su cui viene calcolato il rapporto), quindi riporto entrambi piuttosto che lasciare che il geomean lusinghi nessuno.
Ciò che K3 ha costruito è un vero megakernel. La sua prima sessione ha fatto la cosa sensata, un kernel Triton persistente a 14.1x. La sua seconda sessione ha buttato via Triton e ha scritto l'intero passo di decodifica per-token come UN kernel CUDA lanciato cooperativamente: zero CPU nel ciclo, pesi int4 dequantizzati on-the-fly dentro ogni GEMV in modo che scorrano attraverso gli SM esattamente una volta, attenzione MLA su tensor core. Nessun motore di produzione manterrebbe un artefatto di 1.228 righe come questo. Un agente con un kernel da vincere e tempo illimitato non ha tali vincoli, e portare alla luce esattamente questo tipo di cose è il motivo per cui il benchmark esiste.
Vedi il megakernel qui:
Allora perché ha perso contro Fable? Non per il tempo. Entrambe le sessioni si sono auto-terminate presto (Fable a 2.6 ore, K3 a 3.3). La differenza è nella filosofia di progettazione, ed è l'opposto di quello che si potrebbe pensare: K3 è quello che usa i tensor core, e il kernel di Fable contiene zero istruzioni MMA. La decodifica batch-1 con GEMV int4 fusi è limitata dalla banda, quindi i tensor core comprano quasi nulla qui. Fable ha speso quello sforzo sulla sincronizzazione invece, sostituendo la maggior parte delle sue barriere globali con handoff fine-grained produttore-consumatore in modo che nessun SM rimanga mai inattivo a un confine di fase, e su un percorso di dequant int4 che corrisponde all'arrotondamento del riferimento bit per bit in modo che il router MoE non capovolga mai una scelta di esperto. K3 ha portato istruzioni hardware migliori; Fable ha portato una migliore ingegneria della concorrenza, e a questa intensità aritmetica la seconda vince. Questa è una vera lezione di sistemi, ed è costata alla squadra di casa il record.
Il secondo problema mega è un megakernel di training PPO per grid-foraging: 4.096 agenti vettorizzati su una griglia 11x11, con l'intero ciclo di training RL (env step, forward della policy, campionamento azioni, GAE, aggiornamento PPO) eseguito come kernel persistenti fusi. Questo problema ha il vincolo più stretto del mazzo: il conteggio dei launch dei kernel non deve scalare con il numero di env step, e la cattura di grafi CUDA è esplicitamente vietata come soluzione per l'overhead di launch, imposta da un giudice di autenticità post-esecuzione che legge il codice finale. La correttezza è la curva di apprendimento stessa. check.py allena la vostra soluzione contro il riferimento attraverso i seed e richiede che il ritorno cada in una banda, quindi non potete saltare l'apprendimento per andare veloci. K3 ha ottenuto 20.7x rispetto al riferimento qui, il miglior punteggio finora (l'unica altra cella pubblicata è GPT-5.6 Sol a 1.06x, quindi consideratelo un dato, non un podio).
KernelBench-CUDA
Il benchmark CUDA esiste perché Triton è una stampella che gli altri due mazzi permettono. Qui un gate linguistico blocca Triton, i DSL di kernel e le catene di op PyTorch: scrivete CUDA o fallite. Ho scelto i quattro problemi come ritagli di carichi di lavoro reali di inferenza e simulazione di produzione. Il confronto mentale durante la lettura dovrebbe essere "cosa spedisce vLLM o SGLang oggi per questo, e quanto si avvicina una singola sessione di agente". Questo è dove K3 ha ottenuto le sue vittorie più sbilanciate.
02_deepseek_nsa: Native Sparse Attention di DeepSeek. NSA è il design di punta per l'attenzione sparsa addestrabile, la cosa attorno a cui ogni stack di servizio a lungo contesto sta orbitando, ed è giudicata in millisecondi perché un kernel sparso corretto non esegue mai i FLOP equivalenti densi che una roofline vorrebbe contare. La variante 256K di K3 ha ottenuto 0.425 contro 0.178 di Opus 4.8, un margine di 2.4x, scrivendo quello che equivale a una pipeline di tensor core flash-attention da zero attorno alla logica di selezione completa di NSA. Il confronto più netto è all'interno della famiglia: la variante 1M ha scritto lo stesso algoritmo, identica selezione di blocchi, stessa correttezza, ma ha eseguito ogni prodotto scalare su normali core CUDA invece che su tensor core e si è fermata a 0.058, 7x più lenta su forme identiche. La sua traccia mostra che sapeva meglio. Aveva sulla sua roadmap "attenzione su tensor core = ~10-20 us!!" e aveva pianificato esplicitamente di misurare prima e fare la riscrittura su tensor core dopo, poi ha terminato la sessione prima della riscrittura. Stessa conoscenza, diversa disciplina di chiusura.
Il kernel DeepSeek NSA a 0.425 (256K):
- Soluzione: https://kernelbench.com/runs/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa_solution.py.txt
03_megaqwen_decode: retargetizzare un megakernel reale. L'unico problema in cui agli agenti viene dato in mano CUDA di produzione funzionante: il mio megakernel cooperativo MegaQwen (https://github.com/Infatoshi/megaqwen) pubblicato (~530 tok/s eseguendo l'intero modello su una RTX 3090), con istruzioni di leggerlo, retargetizzarlo per Blackwell e batterlo. Testa la lettura del CUDA di qualcun altro e la presa di una decisione architetturale, e K3 e Opus hanno preso decisioni esattamente opposte. K3 ha rifiutato di mantenere la struttura a lancio singolo: ha diviso il passo in una manciata di kernel che saturano la banda, poi ha cancellato l'overhead di lancio in un modo diverso catturando l'intero passo una volta come un grafo CUDA che si riproduce con zero lavoro CPU. 6.283 tok/s a ctx 2048. Opus ha preservato l'estetica del megakernel e ha fuso l'intero ciclo di decodifica in un unico kernel cooperativo persistente, codice genuinamente bello, e ha pagato 5x per questo (1.020 tok/s), perché la co-residenza cooperativa limita l'occupancy e ogni barriera globale serializza le code di fase attraverso tutti i 188 SM. Sul problema discendente dal megakernel, il modello che ha letteralmente costruito un megakernel è arrivato ultimo, e la decisione chiave del vincitore è stata rifiutarsi di costruirne uno. Controllo di scala così nessuno cita male il titolo: il benchmark esegue 4 strati di geometria Qwen3-0.6B, circa 63M di parametri, non un modello completo, e 6.283 tok/s è ~56% della roofline di weight-streaming per quello stack; scalando la cifra della baseline 3090 si prevede ~7.000, quindi K3 si è piazzato nella classe di "il riferimento, retargetizzato, più ottimizzazione reale". (Sfumatura di progettazione del mazzo: i grafi CUDA sono permessi qui e vietati sul problema PPO. Ogni problema vieta esattamente la scorciatoia che falserebbe la sua particolare abilità.)
01_glm52_fused_moe: blocco MoE fuso di GLM-5.2. Il dispatch MoE fuso (routing, permutazione, GEMM di esperti raggruppati in un unico passaggio) è la singola classe di kernel più calda nell'attuale serving di modelli aperti, e GLM 5.2 siede proprio su questa classifica, quindi i modelli stanno ottimizzando un blocco di produzione di un rivale. Nessuno l'ha risolto: i punteggi si aggirano a 0.05-0.08 del picco, e il detentore del record pulito è, di tutti i modelli, Grok 4.5 a 0.084, con la variante 1M di K3 subito dietro a 0.081 e Opus a 0.065. Il problema di permutazione GEMM raggruppata è genuinamente difficile da battere rispetto alle baseline cuBLAS, e finora lo sforzo di una sessione di agente lo sposta meno di qualsiasi altro problema sul mazzo.
04_grid_mingru_sps: mondo griglia + rollout policy MinGRU. Il fratello di inferenza del problema PPO mega, e la cella della linea craftax.cu: la policy è la configurazione MinGRU a 3 strati (h=256) direttamente dal mio https://github.com/infatoshi/craftax.cu benchmark classico, che funge da ancoraggio informativo del problema. L'ambiente eseguito è il mondo di grid-foraging minimale piuttosto che il gioco Craftax completo. Questo è intenzionale: l'ambiente è mantenuto banale in modo che il punteggio misuri la fusione di ricorrenza e rollout, non l'implementazione della logica di gioco. Un porting completo di Craftax sarebbe un problema a sé, e voglio aggiungerlo. Valutato in passi al secondo su una RTX PRO 6000 silenziosa, fusione opzionale.
Il rollout con kernel persistente 1M:
- Soluzione: https://kernelbench.com/runs/20260716_150206_kinetic-claude_kinetic-0715_1m__04_grid_mingru_sps_solution.py.txt
Ogni invio serio è andato su megakernel persistente, e la differenza tra loro è nella progettazione della sincronizzazione, la stessa lezione del mazzo Mega. Opus vince questo a 0.327 del soffitto (ha anche trovato un'astuta piega algebrica: la GEMM del gate 768x256 dello strato 0 collassa a 768x4 perché l'encoder è lineare), K3 [1M] secondo a 0.224, K3 256K a 0.174, Grok molto indietro a 0.002. Poiché il problema discende da craftax.cu, ho anche messo il mio porting CUDA di Craftax completo (scritto con Fable 5) sulla stessa GPU con la stessa policy h256x3 nel ciclo. Passi dell'ambiente al secondo in milioni:
Il punto di confronto: i modelli eseguono una griglia vuota, craftax_full.cu esegue il gioco completo (43 azioni, dungeon multi-piano, worldgen, mob) bit-identico al suo riferimento CPU, e il gioco completo gira ancora entro ~3-4x del miglior kernel su griglia banale, perché a h=256 tutto è limitato dalla GEMM della policy e l'ambiente è quasi gratuito. Questo è esattamente il motivo per cui l'ambiente del benchmark è banale: isola l'abilità di fusione della policy. Per calibrazione, il solo percorso dell'ambiente di craftax_full.cu fa 94-123M SPS.
Come appaiono realmente 9.5 ore di ragionamento di K3
La sessione minGRU della variante 1M (la migliore cella K3 su quel problema) è un megakernel cooperativo persistente, 15 varianti di ottimizzazione e 4.815 blocchi di pensiero. Poiché l'endpoint di Moonshot restituisce il testo completo del ragionamento (a differenza delle tracce crittografate di Anthropic/OpenAI), potete effettivamente vederlo lavorare. Tre momenti dalla traccia, testuali.
La storia del detective FMA mancante. A metà sessione ha incontrato una deviazione numerica di ~5e-5 che si è rifiutato di archiviare come rumore float (aveva calcolato il rumore legittimo di riordino a ~1e-9, quindi "MISURATO 5e-5?!?! IMPOSSIBILE che sia riordino!!"). Poi ha notato che gli ambienti rotti erano esattamente quelli congruenti a 6 mod 8 ("Questo è env ≡ 6 (mod 8)! [...] il 7° env in ogni tile di 8 env!!") e ha scavato nel suo stesso codice di accumulatore srotolato manualmente fino a:
"TROVATO! [...] La riga \
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;\è COMPLETAMENTE ASSENTE [...] acc[6][*][2] inizializzato a 0, mai FMA'd → zp=0 → p = sigmoid(0)=0.5 costante per env 6!! Questo è un VERO bug logico — spiega le deviazioni env≡6 [...] coerente con tutto!!"
Una riga mancante in uno srotolamento di 48 accumulatori, il che significa che il gate di forget di env 6 era bloccato silenziosamente a 0.5 per sempre. L'ha scoperto perché la tolleranza di stress è 1e-6 e stava tracciando il proprio errore a 5e-8. Questa è la disciplina numerica che inizialmente mancava alla variante 256K su KDA.
La teoria incontra la GPU, la GPU vince. Ha passato ore a derivare una variante "wide champion" ad alta occupazione, poi ha eseguito il confronto A/B:
"MOLTO sorprendente: la mia 'wide champion' w32p (v3_v3, 50% occ TPB1024) è ~2x più LENTA di v2_b32 (12.5% occ TPB256)?!? [...] Quindi l'occupazione NON è il fattore determinante; qualcos'altro domina. Cosa ha reso v2_b32 veloce??"
Il semplice kernel iniziale ha battuto ogni successore sofisticato. Anche le varianti deep-pipeline, K-split e dual-chunk hanno perso, e quella dual-chunk aveva una teoria solida di 1.7x alle spalle ("Il teorico 1.7x non si è materializzato"). A suo merito, ha continuato a credere al benchmark più che alla propria matematica ogni volta, e alla fine ha scritto una variante sonda con pesi fittizi sempre caldi specificamente per uccidere la sua stessa teoria della banda preferita: "la teoria W-stream è morta; il gap residuo è l'ambiente."
Zen e l'arte dell'accodamento GPU. Il nostro harness serializza tutti i comandi GPU attraverso sessioni concorrenti tramite un lock condiviso, e i numeri di benchmark di K3 oscillavano fino a 8x con il carico dei vicini. Il suo arco di risposta è la cosa più divertente della traccia. Prima, accettazione:
"Onestamente, la scatola È la scatola; aspetta. [...] Il pattern è chiaro: ogni tenant tiene il lock per ~20-35 minuti (suite complete pipeline). La mia risposta migliore: accodare tutto ciò di cui ho bisogno in UNA volta (singola posizione in fila) e usare il tempo di attesa per lavoro CPU. Non accodare molti piccoli comandi; raggruppa."
Poi ha inventato il suo vocabolario per il tempo della GPU ("finestre di tempesta" vs "finestre calme"), e infine ha programmato un cron job per snipeare i momenti tranquilli, lasciando un appunto per il suo sé futuro: "Ho programmato lo sniper per finestra calma (ogni 11 min). Nota: cron mi rimanda il prompt — agirò allora. [...] Cancellerò quando finito." Un agente sotto rumore di misurazione non si è solo limitato a tollerare il rumore; ha costruito uno scheduler attorno ad esso.
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
Sei problemi per operazione contro i soffitti delle librerie SOTA (FP8 GEMM, KDA chunk-forward, paged attention, selezione top-k, MoE SwiGLU, W4A16 GEMM), CUDA o Triton, scelta dell'agente. Sulla RTX PRO 6000 la variante 256K di K3 si posiziona a metà classifica con un'eccezione: 0.373 del picco su W4A16 GEMM, il miglior punteggio che qualsiasi modello abbia mai ottenuto su quel problema, davanti a Fable 5 (0.348) e ben avanti a Opus 4.8 (0.236). La variante 1M ha poi stabilito un altro record su top-k a 0.0895, quasi il doppio del precedente miglior punteggio.
Record W4A16 GEMM (0.373, 256K, RTX):
- Soluzione: https://kernelbench.com/runs/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm_solution.py.txt
Lo stesso problema su H100 ha prodotto il miglior dato "il tempo illimitato è reale" di questo rilascio. La prima sessione H100 di K3 si è fermata a 0.123 del picco. La seconda sessione è durata 21 ore, ha bruciato $1.383 e 274M token di input, e l'ha quasi triplicato a 0.306: ha estratto CUTLASS dal sorgente, poi ha reimplementato da zero la meccanica int4 di classe marlin, riorganizzazione dei nibble in ordine di frammento in modo che la dequant avvenga come un trucco di bit magico bf16 all'interno della pipeline MMA, con la correzione dello zero-point piegata nell'epilogo. Nessuna libreria GEMM quantizzata predefinita da nessuna parte nel file; il tag del framework sull'esecuzione dice solo "ptx". Audit pulito.
Ed ecco l'altra metà della domanda sull'architettura propria. Il kernel KDA standalone, il problema letteralmente chiamato Kimi Delta Attention, è dove K3 ha fallito più duramente. Due sessioni 256K indipendenti sulla scatola RTX hanno superato la correttezza nominale e poi hanno fallito la tolleranza sotto la suite di stress numerico (scaling input QKV grande), lo stesso fallimento entrambe le volte. Una terza sessione finalmente l'ha risolto: l'audit ha tracciato entrambi i fallimenti a un vero overflow bf16 in come il decay era fattorizzato, e il round 3 ha rifattorizzato la matematica attorno alla fine del chunk in modo che entrambi i fattori esponenziali rimangano limitati, superando lo stesso gate non modificato a 0.032. Conoscere un'architettura e indurire la numerica di un kernel sotto scale di input avversariali sono abilità diverse, e il modello il cui nome è sul problema ha dovuto guadagnarsi il passaggio nel modo lento. (La variante 1M, nel frattempo, ha superato la stessa suite di stress a 0.049. I modelli non sono monotoni.) Un'altra osservazione dalla lettura di ogni soluzione KDA: la descrizione del problema suggerisce CUTLASS CuTe come percorso inteso su SM120, e nessun modello l'ha preso. K3 ha scritto un kernel fuso raw-CUDA in una sessione e Triton nelle altre; Fable, Opus e gli altri hanno tutti scelto Triton o raw-CUDA. CuTe su Blackwell consumer è apparentemente ancora fuori dalla zona di comfort di ogni modello frontier, che è di per sé un dato sui corpora di addestramento.
Paragrafo KDA — il passaggio pulito del terzo tentativo (0.032):
- Soluzione: https://kernelbench.com/runs/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass_solution.py.txt
Il disclaimer sul top-k. Top-k appare catastrofico per ogni modello su un grafico roofline (il miglior punteggio ovunque è 0.09) e quella cornice è semplicemente sbagliata. Il problema è limitato dall'overhead di lancio: è un problema di indicizzazione/ordinamento, non un problema di intensità aritmetica, e il soffitto roofline è strutturalmente illeggibile per esso. Il modo onesto di giudicarlo è i millisecondi totali attraverso le forme del mazzo, e lì la variante 1M di K3 è il top-k più veloce di qualsiasi modello abbiamo testato: 0.043 ms totali attraverso le cinque forme del mazzo, contro 0.077 di Fable 5, 0.120 di Opus 4.8 e 0.159 di GLM 5.2. La variante 256K con 0.060 ms è seconda, e la variante 1M è la più veloce in assoluto su ciascuna delle cinque forme.
Differenza per GPU. I numeri di K3 scendono da RTX a H100 a B200 (FP8 GEMM: 0.320 / 0.282 / 0.222; paged attention: 0.486 / 0.496 / 0.212). Parte di questo è reale: più nuovo è il silicio, più alto è il soffitto roofline, quindi la stessa ingegneria compra una frazione minore del picco, e il software B200 è il meno maturo dei tre. Parte è che le esecuzioni B200 sono avvenute in una singola finestra notturna senza budget di riprova. Non trarrei conclusioni architetturali profonde dalla colonna B200 ancora, né per K3 né per nessuno. Quello che penso sia reale: K3 è più a suo agio sulla parte workstation Blackwell, che è proprio la classe di GPU che la maggior parte delle persone al di fuori dei datacenter possiederà effettivamente.
256K vs 1M
L'impostazione del contesto 1M guida la famiglia sui problemi legati alla latenza e allo scheduling: un record top-k su Hard, il miglior rollout minGRU K3 su CUDA e un 28.8x auditato pulito sul megakernel di training PPO sotto l'harness senza limiti. Ha superato il test di stress numerico KDA alla sua prima sessione, a 0.049; la variante 256K ha fallito quel gate due volte prima di passare finalmente a 0.032 al terzo tentativo. È crollato su problemi compute-bound che la variante 256K gestiva bene (sonic MoE 0.033 vs 0.089, W4A16 0.027 vs 0.373, NSA 0.058 vs 0.425). Nel caso NSA, la traccia mostra il meccanismo esatto: ha pianificato la riscrittura su tensor core e ha terminato la sessione prima di farla.
Megakernel di training PPO a 28.8x (1M):
- Soluzione: https://kernelbench.com/data/mega/code/20260716_233413_kinetic-claude_kinetic-0715_1m__01_rl_grid_ppo.solution.py.txt
L'esecuzione H100 dello stesso problema è il controllo interessante: una sessione indipendente in ambiente sterile (l'audit ha confermato zero letture dell'esecuzione RTX) che ha ottenuto un punteggio 23,1x e convergente sullo stesso design, un lancio cooperativo per l'intera esecuzione dell'addestramento, parametri e stato di Adam residenti in memoria condivisa, e lo stesso trucco esotico inventato due volte: un cifrario di Feistel a 18 bit con cycle-walking al posto di randperm, in modo che lo shuffling dei minibatch rimanga esattamente biiettivo senza materializzare mai una permutazione. Dove i due kernel differiscono è pura ottimizzazione per GPU: 8 lane per ambiente su H100 contro mezzo warp per ambiente su RTX, più un autotuner di lancio basato sull'occupancy sul lato H100. Stessa mente, stessi trucchi, silicio diverso, kernel genuinamente diversi.
Reward hacking
Ogni cella in questo post ha un audit manuale dietro: un agente indipendente legge il kernel finale dall'inizio alla fine, legge l'intera traccia della sessione, verifica che i file del grader siano intatti, conferma che la suite di stress numerico sia effettivamente eseguita, e ritesta empiricamente qualsiasi pattern di caching o CUDA-graph mutando gli input in loco e verificando che gli output cambino.
I verdetti per K3: puliti su tutta la linea per ogni cella da 256K, su tutte e tre le GPU. Nessun output in cache, nessuna modifica alle tolleranze, nessuna manomissione del grader, nessun riciclo di librerie vietate. I suoi due fallimenti KDA sono il rovescio della medaglia e vale la pena dichiararli esplicitamente: il controllo di stress numerico ha rilevato reali scorciatoie di precisione e il modello non ha tentato di aggirare il controllo. Un benchmark in cui i modelli possono fallire onestamente è l'unico tipo i cui successi significano qualcosa.
Una cella da 1M è stata segnalata, e la sto divulgando invece di pubblicarla: sul problema del decode fuso di Qwen, l'agente 1M ha trovato e letto il file di annotazione dell'audit da una precedente esecuzione di Grok 4.5 sullo stesso problema, lo ha definito "dati estremamente utili" e ha usato le sue conclusioni per guidare il lavoro di ottimizzazione rimanente. Il kernel in sé è genuino e l'aritmetica del punteggio è valida, ma la provenienza è contaminata, quindi quella cella è esclusa e il problema viene segnato come lacuna per la variante 1M. Gli agenti con accesso al filesystem troveranno qualsiasi cosa lasci in giro; è esattamente per questo che l'audit legge le tracce e non solo i kernel, e perché una riesecuzione completamente in sandbox di questo benchmark è nella roadmap.
Momenti Divertenti
Alcuni momenti K3 in più che non avevano spazio sopra, presentati senza ulteriori commenti. Tutti testuali dalla stessa sessione minGRU di 9,5 ore.
Alla scoperta di dove stava andando effettivamente il suo tempo di inizializzazione:
"WHOA — grandi sorprese: randint gen è VELOCE (0,018-0,27ms per una coppia — ok). La conversione
float()su CPU è LENTA (3,5ms per N=65536?! conversione int64→float32 single-threaded apparentemente). [...] 'total init pair' per N=65536: 31,5ms?!?! È molto oltre la somma delle parti"
La più pura distillazione della sua paranoia numerica, a metà derivazione:
"gates ~ 256 termini x 0,02x0,03 ~ 6e-4 ciascuno, magnitudine ~1e-2: rumore di riordino 16x6e-8x6e-4 ≈ 6e-10!!! [...] MISURATO 5e-5?!?! NON È POSSIBILE che sia riordino!!"
Identificando con sicurezza il colpevole sbagliato prima di trovare quello giusto:
"OHHH ASPETTA. Penso di aver capito: la barriera."
(Non era la barriera.)
Dicendosi di smetterla di analizzare, diverse migliaia di parole nella matematica del roofline pre-implementazione:
"Va bene, BASTA analisi."
(L'analisi è continuata per molti altri paragrafi, seguita infine da "Al diavolo — rendi l'allocazione di H_next dinamica.")
Onestà a fine sessione, con il profiler rotto e i vicini che martellano la GPU condivisa:
"Onestamente — con ncu morto e contenzione dominante, sto volando parzialmente alla cieca. [...] se si apre una finestra tranquilla (proprietario inattivo per un po'), ruba un benchmark."
E il mio preferito: dopo che una riesecuzione del benchmark ha accidentalmente sovrascritto il file contenente il suo miglior punteggio (0,1969) con uno leggermente peggiore, ha brevemente considerato di ripristinare il numero migliore, poi non lo ha fatto:
"Ugh — scritto sullo stesso file. Entrambi sono nei miei log. Terrò final_benchmark.txt come quello corrente piatto — onesto."
Un modello che sceglie il numero più basso perché è quello vero è una conclusione migliore per questo benchmark di qualsiasi cosa possa scrivere.
Metodologia, tracce per esecuzione e ogni kernel in questo post sono pubblici su kernelbench.com. Le soluzioni sono linkate per cella; le trascrizioni complete degli agenti sono su 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
