Claude Fable scrive un kernel per GPU in pochissimo tempo

Jack Clark, cofondatore di Anthropic, racconta nella sua newsletter Import AI 464 un risultato che merita due letture, non una sola. Claude Fable, il modello della classe Mythos di Anthropic, ha scritto codice CUDA per una GPU RTX PRO 6000 Blackwell ottenendo un’accelerazione di 18,71 volte rispetto a un baseline PyTorch ottimizzato, misurata su KernelBench-Mega. Il dato è forte. Ma un conto è la velocità, un altro è sapere se quel codice è sicuro da mettere in produzione.

Un kernel scritto in un solo lancio, mentre i rivali ne usano fino a 14

Il numero che fa notizia è il confronto diretto con gli altri modelli. Claude Opus 4.8, con Triton, arriva a 14,4x. GLM-5.2 si ferma a 11,14x. GPT-5.5 tocca 4,34x. Fable stacca tutti con un margine ampio, e lo fa con una scelta tecnica specifica: la sua soluzione usa un solo lancio di kernel cooperativo per token decodificato, mentre le soluzioni rivali ne richiedono da 4 a 14 per token.

Meno lanci significa meno overhead di comunicazione tra CPU e GPU, meno sincronizzazioni, meno tempo perso a orchestrare il lavoro invece di farlo. È il tipo di ottimizzazione che un ingegnere CUDA esperto insegue per mesi. L’analisi di uno dei maintainer del benchmark conferma il dettaglio del lancio unico, un elemento tecnico difficile da falsificare anche restando scettici sul contesto.

Fable 5 è stato lanciato da Anthropic il 9 giugno 2026 a 10 dollari per milione di token in input e 50 in output, meno della metà di Claude Mythos Preview. L’annuncio ufficiale lo posiziona come modello economico rispetto alla generazione precedente, il che rende il risultato ancora più rilevante sul piano commerciale: prestazioni più alte a un prezzo più basso sono l’argomento che vende infrastruttura.

Veloce non vuol dire sicuro: cosa KernelBench non misura

Qui si ferma la parte facile della storia, e comincia quella che nessun comunicato racconta da sé. KernelBench-Mega, come la maggior parte dei benchmark di ottimizzazione GPU, verifica due cose: che l’output del kernel combaci con l’implementazione di riferimento su un set di test, e quanto è veloce farlo. Sono le due metriche che producono un numero da titolo: correttezza funzionale più velocità.

Quello che un benchmark di questo tipo non è progettato per misurare è tutta un’altra categoria di problemi. Casi limite non coperti dal set di test. Input avversari costruiti apposta per rompere l’assunzione implicita nel codice. Race condition che emergono solo sotto certi pattern di concorrenza, magari mai eseguiti durante la valutazione. Bug di memory safety, come letture o scritture fuori dai bordi di un buffer, che in CUDA possono restare silenti per migliaia di esecuzioni prima di manifestarsi. Nessuno di questi problemi compare in un punteggio di velocità, perché il benchmark non li sta cercando.

Non c’è, in quello che sappiamo da questo dossier, alcuna prova che il kernel scritto da Fable contenga bug o vulnerabilità. Sarebbe scorretto affermarlo. Ma è altrettanto scorretto il passaggio opposto, quello implicito in ogni titolo entusiasta: dedurre dalla velocità che il codice sia pulito, sicuro, pronto per la produzione. Il salto logico “veloce e corretto sui test quindi affidabile” è lo stesso errore che per anni ha afflitto la fiducia cieca nel codice umano che passava i test unitari senza mai vedere una revisione di sicurezza.

Chi giudica il benchmark è la stessa filiera che lo supera

C’è un secondo livello di cautela, distinto dal primo ma complementare. Chi certifica il risultato lo fa attraverso KernelBench-Mega, un benchmark specifico. E chi racconta la notizia al mondo è Jack Clark, cofondatore della stessa azienda che ha costruito il modello vincitore. Non è un motivo per liquidare il dato: il dettaglio tecnico del lancio unico è verificabile, ed è stato verificato in modo indipendente da un maintainer del benchmark. Ma è un motivo per leggerlo con un grado di cautela superiore a quello che si riserverebbe a un annuncio arrivato da una fonte terza senza interessi in gioco.

La combinazione dei due livelli, il benchmark che non misura sicurezza e la filiera che si autocertifica, dovrebbe portare a una conclusione operativa precisa: chi userebbe questi kernel in un ambiente di produzione ha bisogno comunque di revisione umana dedicata e di test di sicurezza specifici, non di fidarsi del numero pubblicato su un leaderboard. La differenza tra “vince un benchmark di velocità” e “è pronto per girare su hardware critico” è enorme, e nessun annuncio la colma da solo.

Il lavoro degli ingegneri di ottimizzazione non sparisce, cambia livello

Qui si apre il vero punto di frizione per chi lavora nel settore. Gli ingegneri di ottimizzazione GPU e CUDA sono una nicchia specialistica pagata a peso d’oro proprio perché le competenze scarseggiano: tiling, scheduling, fusion di operatori sono lavori di basso livello che richiedono anni di pratica. Se un modello scrive un kernel più veloce con un solo lancio invece di 14, quel lavoro di basso livello perde valore di mercato con rapidità.

Ma è proprio la mancanza di garanzie sulla qualità del codice generato a spostare, non a eliminare, il valore di quella competenza. Resta necessario chi sa definire cosa ottimizzare e perché, chi sa leggere un kernel generato e riconoscere una race condition che il benchmark non ha mai testato, chi sa mettere in piedi un processo di verifica per codice che nessun essere umano ha scritto riga per riga. Il ruolo si sposta dal produrre il codice al certificarlo, e quel secondo compito richiede competenze almeno pari a quelle di chi scriveva il kernel a mano.

Dove porta la corsa: dal kernel al ciclo che si autoalimenta

Clark lega il risultato a uno scenario più ampio: sistemi AI più bravi a scrivere kernel diventano sistemi più bravi a fare ricerca e sviluppo su se stessi, il concetto noto come auto-miglioramento ricorsivo. È una lettura che spiega perché Anthropic investe risorse nel raccontare bene ogni progresso su questo fronte specifico: ogni kernel scritto meglio non è solo un numero di performance, è un mattone di un ciclo che, se si chiude, accelera tutto il resto.

Nvidia guadagna comunque da questa dinamica, indipendentemente da chi vince il singolo benchmark: ogni kernel scritto meglio rende l’hardware Blackwell più efficiente e giustifica l’investimento delle aziende in GPU di fascia alta. Le aziende che non hanno accesso ai modelli di punta, perché costano o richiedono infrastruttura Blackwell dedicata, restano un passo indietro nell’efficienza di calcolo, un divario che si somma a quello già esistente tra chi ha capitale per comprare GPU top di gamma e chi no. Il monopolio da smontare attorno a CUDA resta la cornice competitiva in cui ogni kernel più veloce pesa doppio.

Il progresso tecnico qui è reale: il lancio unico di kernel cooperativo è un risultato ingegneristico verificabile, non un trucco di marketing. Ma un benchmark di velocità resta un benchmark di velocità, non un certificato di sicurezza. Chi rischia di più in questa fase sono gli ingegneri di ottimizzazione, che vedono eroso il valore del lavoro manuale senza ancora avere strumenti maturi per validare in modo sistematico ciò che il modello produce al posto loro. Chi guadagna oggi, doppiamente, è Anthropic, come fornitore del modello e come narratore del proprio stesso progresso. Nvidia incassa comunque, perché ogni kernel ottimizzato rende più solido l’argomento per comprare la sua prossima generazione di GPU. Tra questi due guadagni certi e un rischio concreto per chi scrive codice GPU di professione, resta sospesa la domanda che il benchmark non ha nemmeno provato a rispondere: quel codice, prima di girare su un sistema vero, chi lo ha controllato per davvero?