// TOM'S HARDWARE ITALIA — HARDWARE & GADGET
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.
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.
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.
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: