Defeating Non determinism in LLM Inference
Chiunque abbia avuto l’ardire di chiedersi perché i modelli linguistici di grandi dimensioni si comportino come una macchina capricciosa piuttosto che come un algoritmo rigoroso, si sarà scontrato con una verità scomoda: i cosiddetti LLM non deterministici non sono un bug, sono una feature, o meglio un effetto collaterale inevitabile della loro implementazione industriale. La fantasia di poter fissare un seed casuale e ottenere sempre la stessa risposta è parente stretta della convinzione che la Silicon Valley sia fatta di garage pieni di geni e non di venture capitalist con fogli Excel. Affascinante, ma fondamentalmente falsa.
Per anni ci siamo raccontati che il problema fosse colpa della matematica traditrice. Il mantra era sempre lo stesso: la non-associatività della virgola mobile, quel piccolo dettaglio che fa sì che (a + b) + c non sia esattamente uguale a a + (b + c). Poi qualcuno aggiungeva la ciliegina sulla torta: le GPU, lavorando in parallelo, eseguono somme in ordini diversi, e questo manda tutto all’aria.
Sembrava elegante, quasi poetico, un difetto intrinseco del calcolo digitale che rende l’intelligenza artificiale irrimediabilmente caotica. Peccato che fosse, appunto, una storia da raccontare ai neofiti.
Il nuovo lavoro del laboratorio Thinking Machines, fondato da Mira Murati nel 2025, ha messo in chiaro che quella che potremmo chiamare l’ipotesi “concurrency + floating point” non regge alla prova dei fatti. Nella pratica, durante un forward pass tipico di un modello Transformer, non ci sono neppure quelle operazioni atomiche di addizione che si supponevano responsabili della divergenza. L’argomento è quindi chiuso: il colpevole non è la matematica, bensì l’infrastruttura. In altre parole, il determinismo dei modelli linguistici non viene tradito dal calcolo, ma dal modo in cui serviamo le richieste.
Il cuore della questione sta in un aspetto tanto banale quanto devastante: il batch size LLM non è costante. Quando invii un prompt al tuo modello preferito, la tua richiesta non viaggia in un tunnel isolato. Viene accodata insieme a decine di altre, e il sistema di serving decide al volo come impacchettarle in un batch per massimizzare l’uso della GPU. La prima volta potresti finire in un batch da otto, la seconda in un batch da sedici.
Questo cambia radicalmente il percorso computazionale, perché alcune operazioni del Transformer normalizzazione, softmax, attenzioni condivise vengono calcolate a livello di batch. Risultato: anche se il seed iniziale è lo stesso, la sequenza di operazioni non lo è, e quindi l’output diverge.
Il paradosso è che questa non-deterministicità non è nemmeno legata alle GPU. Lo stesso fenomeno si manifesta su CPU e TPU, perché non è l’hardware a cambiare il risultato, ma l’architettura software che gestisce i job. Parlare di “magia nera” della precisione numerica è quindi una distrazione. La verità è più prosaica: i modelli linguistici sono non deterministici perché la loro esecuzione viene ottimizzata per throughput, non per coerenza.
Il laboratorio di Murati ha fatto un passo ulteriore, dimostrando che il problema è risolvibile. Con la libreria batch_invariant_ops, hanno implementato kernel matematici che eliminano la dipendenza dal batch.
Hanno preso un modello da otto miliardi di parametri, Qwen3-8B, e lo hanno fatto girare in modo completamente deterministico su vLLM. Un colpo secco alla narrativa dominante: non è impossibile ottenere determinismo nei modelli linguistici, semplicemente nessuno lo ha mai ritenuto abbastanza importante da sacrificare efficienza per ottenerlo.
Questa rivelazione ha conseguenze sottili ma enormi. Significa che ogni volta che qualcuno si ostina a confrontare due modelli “a parità di condizioni”, ignorando che l’infrastruttura di serving gioca a dadi con i batch, sta in realtà conducendo un esperimento contaminato. Significa anche che i risultati delle ricerche che confrontano performance su generazioni testuali sono sempre afflitti da una dose di casualità sistemica e ironicamente, significa che se davvero volessimo un LLM con comportamento riproducibile, potremmo costruirlo. Solo che andrebbe molto più lento, costerebbe molto di più, e farebbe arrabbiare gli investitori che si aspettano efficienza scalabile.
C’è una componente filosofica che non va trascurata. Gli ingegneri hanno sempre predicato l’importanza del determinismo come base della scienza computazionale.
MdT è stata introdotta nel 1936 da Alan Turing come modello di calcolo per dare risposta all’Entscheidungsproblem (problema di decisione)proposto da Hilbert nel suo programma di fondazione formalista della matematica.
Un algoritmo, per definizione, produce lo stesso output per lo stesso input. Un LLM, che è un algoritmo estremamente complesso, sembra violare questo principio. Ma in realtà il principio non è rotto, è semplicemente aggirato. L’input non è mai solo il prompt, bensì il prompt più il contesto infrastrutturale invisibile, fatto di batch size, di scheduling, di stati transitori delle GPU. Se si considera l’input completo, allora il determinismo torna al suo posto. È solo che abbiamo scelto di non considerare quell’input perché ci complica la narrativa.
Alcuni obietteranno che questa è una distinzione accademica. Nella pratica, quello che conta è che due chiamate allo stesso modello non producono lo stesso testo. Ed è vero. Ma allora la domanda diventa: davvero vogliamo che lo producano? Una delle ragioni per cui i modelli linguistici sono percepiti come “creativi” è proprio la loro variabilità. Se un assistente restituisse sempre la stessa risposta, parola per parola, sarebbe percepito come un motore di ricerca un po’ più elegante, non come un’intelligenza artificiale. La non-deterministicità è un difetto tecnico, ma è anche una caratteristica psicologica che alimenta la fascinazione.
Il futuro del determinismo nei modelli linguistici dipenderà meno dalla matematica e più dal business. Settori come la finanza regolata, la ricerca scientifica o la medicina potrebbero richiedere output bit-per-bit riproducibili, e quindi spingeranno verso kernel invarianti al batch. Altri settori, dove la velocità e la diversità delle risposte contano di più, continueranno a cavalcare la non-deterministicità senza rimpianti. È la solita storia: la tecnologia è neutra, ma l’infrastruttura che la governa riflette le priorità economiche.
A questo punto la vera ironia è che l’industria dell’intelligenza artificiale, ossessionata dall’idea di “determinismo” nei modelli di training controllare i seed, congelare i dataset, versionare ogni parametro non ha applicato lo stesso rigore alla fase di inferenza. Come se ci fosse un tacito accordo: la riproducibilità scientifica serve solo per pubblicare paper, non per servire milioni di utenti in produzione. La scoperta di Thinking Machines mette in crisi questa ipocrisia e apre un fronte nuovo. La domanda non è più se possiamo rendere deterministici gli LLM, ma se siamo disposti a pagarne il prezzo.
Un ingegnere pragmatico risponderà che no, non conviene. Meglio abbracciare l’incertezza, costruire metriche che tengano conto della variabilità e investire in infrastrutture che minimizzino la latenza. Ma un ricercatore, o un regolatore, potrebbe avere un’opinione opposta: senza determinismo, come possiamo garantire l’affidabilità in contesti critici? È accettabile che un sistema di supporto medico generi due risposte diverse alla stessa domanda, solo perché il batch al momento del calcolo era più o meno affollato?
Il dibattito è appena iniziato, ma la linea di frattura è chiara. I LLM non deterministici non sono un destino matematico, ma una scelta architetturale. Abbiamo sacrificato la coerenza sull’altare dell’efficienza, e ora dobbiamo decidere se continuare il culto o abbattere l’idolo. Chi parla di non-associatività dei float non ha capito che il problema non è nell’aritmetica, ma nell’economia dell’infrastruttura. Non è questione di numeri, è questione di priorità.
Forse tra qualche anno guarderemo a questa fase con la stessa ironia con cui guardiamo oggi i floppy disk da 1,44 MB. Diremo: davvero credevamo che gli LLM fossero condannati a non essere riproducibili, quando in realtà bastava riscrivere i kernel? Nel frattempo, però, continueremo a vivere in un mondo dove la stessa domanda al modello produce risposte diverse e forse va bene così. Perché, in fondo, l’illusione che l’IA sia creativa vale molto di più della certezza che sia deterministica.
Il mito del non determinismo negli LLM è stato venduto come una verità matematica immutabile, quasi un dogma da accettare con rassegnazione. Ci hanno raccontato che era colpa della non associatività dell’aritmetica floating point, che i thread GPU litigano tra loro come bambini in un parco giochi e che il risultato dipende da quale arriva primo allo scivolo. La narrativa era comoda, spiegava il caos con un po’ di tecnicismo fumoso, e ci lasciava con l’illusione che fosse la natura stessa dei numeri a tradirci. Peccato che, come spesso accade, la realtà ingegneristica è molto meno romantica.
Il nuovo lavoro del Thinking Machines Lab, con Mira Murati come volto visibile, smonta la favola e mostra che il cuore del problema è molto più banale e imbarazzante: il batching. Non sono le formule a cambiare, è il modo in cui i server raggruppano le richieste. Se in un istante sei l’unico utente della GPU ottieni un batch di dimensione uno, se due millisecondi dopo arriva qualcun altro la tua inferenza finisce in un batch da quattro, e a quel punto la sequenza dei numeri casuali consumati cambia.
Il risultato: un prompt identico produce una frase diversa. Non serve scomodare Gödel o il caos deterministico, basta guardare al motore di scheduling dei job.La soluzione proposta nel paper ha un nome elegante, batch-invariant ops, ed è un tentativo di rendere i kernel numerici indifferenti alla dimensione del batch.
Se ci pensi è quasi un insulto alla nostra intelligenza collettiva che non l’abbiamo fatto prima. Ma la domanda che conta non è se sia possibile, bensì quanto ci costa. Perché ogni volta che imponi invarianti rigide su un sistema ottimizzato per throughput, sacrifichi efficienza e qui sta la parte interessante: vogliamo davvero trasformare un’auto da corsa in un treno svizzero che parte sempre puntuale?
Guardando i dati, i kernel batch-invariant ottengono la determinismo desiderato, ma al prezzo di rallentare la macchina. Alcune operazioni, come riduzioni e normalizzazioni, devono rinunciare a scorciatoie che sfruttano il parallelismo estremo delle GPU. La conseguenza è meno token al secondo, più latenza, minore saturazione dell’hardware. In produzione, dove il margine tra margine lordo positivo e perdita secca è misurato in microsecondi di inferenza, questo compromesso non è un dettaglio estetico, è la differenza tra sostenibilità e bancarotta.
Eppure c’è un paradosso che mi affascina: i casi in cui vogliamo davvero determinismo non sono quelli in cui cerchiamo throughput infinito, ma quelli in cui serve accountability. Se sei un regolatore, se stai auditando un modello per bias o per stabilità, non ti interessa che il sistema macini milioni di richieste al secondo, ti interessa che domani il prompt X dia la stessa risposta che ha dato oggi. È la differenza tra un assistente creativo e una macchina scientifica riproducibile.
Quindi la domanda diventa quasi filosofica: vogliamo macchine che imitano la nostra variabilità, o strumenti che funzionano come cronometri? L’industria finora ha scelto la prima via, esaltando la “magia” della generazione stocastica, ma il paper di Thinking Machines mostra che la seconda strada non solo esiste, è implementabile (a quale prezzo). Il prezzo è chiaro: meno velocità, più rigore. Il trade-off tipico di ogni rivoluzione tecnologica.
Non mi sorprenderebbe vedere nascere due ecosistemi paralleli. Da una parte gli endpoint non deterministici, più veloci, più convenienti, più “creativi”. Dall’altra i servizi deterministici, lenti ma certificabili, usati per auditing, ricerca, applicazioni regolamentate.
Sarà un po’ come scegliere tra volare low cost e prendere il Frecciarossa: entrambi ti portano a destinazione, ma il contratto implicito con l’utente è radicalmente diverso e qui sta la parte provocatoria: abbiamo passato anni a chiamare il non determinismo un bug inevitabile, quando in realtà è una feature del modello di business.
Il batching dinamico è ottimale per saturare GPU costose e spremere ogni watt di calcolo, e ogni ingegnere lo sa. Rinunciarci per il determinismo significa cambiare non solo il kernel, ma l’economia dell’inferenza. È un gesto quasi politico.
Se fossi un regolatore europeo mi butterei a capofitto su questa nuova libreria batch-invariant, perché diventa improvvisamente possibile chiedere alle aziende di dimostrare la riproducibilità delle risposte. Se fossi un cloud provider guarderei con orrore ai benchmark che mostrano il calo di throughput. Se fossi un investitore capirei che il determinismo non è solo un problema tecnico, è una nuova linea di segmentazione del mercato.
Tu che costruisci sistemi, dovrai decidere da che parte stare. Vuoi un oracolo che non puoi mai citare in tribunale perché cambia opinione di continuo, o un orologio che scandisce la stessa verità ogni volta che lo interroghi? La verità è che non puoi avere entrambi.