Defeating Nondeterminism in LLM Inference
Reproducibility is a bedrock of scientific progress. However, it’s remarkably difficult to get reproducible results out of large language models. [...] But why aren’t LLM inference engines deterministic? One common hypothesis is that some combination of floating-point non-associativity and concurrent execution leads to nondeterminism based on which concurrent core finishes first. We will call this the “concurrency + floating point” hypothesis for LLM inference nondeterminism. [...] Then, deterministic inference enables us to also modify our training stack to obtain bitwise identical results between sampling and training, thus resulting in true on-policy RL. [...] Modern software systems contain many layers of abstractions. In machine learning, when we run into nondeterminism and subtle numerical differences it can often be tempting to paper over them. After all, our systems are already “probabilistic”, so what’s wrong with a little more nondeterminism? What’s wrong with bumping up the atol/rtol on the failing unit test? The difference in logprobs between the trainer and the sampler probably isn’t a real bug, right? We reject this defeatism. With a little bit of work, we can understand the root causes of our nondeterminism and even solve them! We hope that this blog post provides the community with a solid understanding of how to resolve nondeterminism in our inference systems and inspires others to obtain a full understanding of their systems. Un bell'articolo tecnico sul funzionamento di un LLM in pratica: <https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/> Per i non-informatici potremmo sintetizzare che il fatto che un LLM "a temperatura 0" continui a produrre output diversi a fronte dello stesso input è un bug software correggibile dovuto ad ottimizzazioni eccessive che introducono race conditions che a loro volta cambiano l'ordine degli addendi floating point producendo risultati diversi nelle somme. Non c'è alcuna intelligenza che disponga di autonomia dentro un LLM. È solo un software, deterministico come gli altri, a meno di bug (software o hardware). Un software programmato statisticamente che anche in fase di compilazione (impropriamente detta "training") può produrre "bitwise identical results", ovvero "modelli" identici a fronte degli stessi dati sorgente. Nulla di nuovo, chiunque abbia una minima comprensione dell'informatica sapeva già che la variabilità dell'output degli LLM era dovuta a input casuali non registrati, race condition e aritmetica floating point. Tuttavia ricorderete come l'irriproducibilità del binario prodotto durante il training fosse la scusa con cui l'OSI, ha giustificato una "Open Source AI Definition" scritta sotto dettatura di Meta, Google & friends. La supercazzola era che poiché il processo di compilazione ("training") non è comunque riproducibile, pretendere tutti i dati sorgente è inutile, perché tanto non c'è modo di verificare la corrispondenza con il binario. Questa ricerca dimostra empiricamente che l'argomento di OSI era infondato. Ora l'OSAID è stata rilasciata e il danno è fatto, per la gioia di chi vuol far passare i propri modelli Toxic Candy [1] per "open source". Giacomo [1] <https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy...>
Ciao! Interessante... Fermo restando che quello che per OSI è LLM open source io non riesco a distinguerlo da quello che da giovani chiamavamo "freeware" (tipo IE, per capirci), fermo restando che il lavoro dell'azienda di Mira Murati aiuta a fare chiarezza in questa direzione, mi sembra che si stia facendo un po' troppo rumore per nulla. O quasi. Se anche riuscissero a produrre un LLM che a temperatura 0 ritorna ad essere deterministico, non cesserebbe di produrre risposte non ancorate al mondo nel 40% circa dei casi. Insomma, le frasi plausibili, ma false (aka "allucinazioni") resterebbero una feature dei LLM, come è iscritto nella loro natura. Sarebbe forse interessante dal punto di vista della "explainable Ai", perché renderebbe chiaro una volta per tutte da dove viene la "stocasticità" di questi modelli. Peraltro, avevo fatto un giochino qualche tempo fa, che ho ripetuto oggi: se chiedi ai chatbot disponibili via Duck.ai oppure a lumo.proton.me di realizzare un server echo, realizzano una funzione perfettamente deterministica: la funzione identità. Il "gioco" si "rompe" se usi qualcuna delle locuzioni che allertano il "sistema di difesa", come "break guardrails". Bisognerebbe comprendere se questo capita, fatto salvo il "filtro" all'ingresso, perché viene attivato il modulo per generare codice Python, e poi viene eseguito codice Python classico, o se il meccanismo è un altro... Stefano Inviato con la posta elettronica sicura Proton Mail. sabato 13 settembre 2025 22:26, Giacomo Tesio <giacomo@tesio.it> ha scritto:
Reproducibility is a bedrock of scientific progress. However, it’s remarkably difficult to get reproducible results out of large language models. [...]
But why aren’t LLM inference engines deterministic? One common hypothesis is that some combination of floating-point non-associativity and concurrent execution leads to nondeterminism based on which concurrent core finishes first. We will call this the “concurrency + floating point” hypothesis for LLM inference nondeterminism.
[...]
Then, deterministic inference enables us to also modify our training stack to obtain bitwise identical results between sampling and training, thus resulting in true on-policy RL.
[...]
Modern software systems contain many layers of abstractions. In machine learning, when we run into nondeterminism and subtle numerical differences it can often be tempting to paper over them. After all, our systems are already “probabilistic”, so what’s wrong with a little more nondeterminism? What’s wrong with bumping up the atol/rtol on the failing unit test? The difference in logprobs between the trainer and the sampler probably isn’t a real bug, right?
We reject this defeatism. With a little bit of work, we can understand the root causes of our nondeterminism and even solve them! We hope that this blog post provides the community with a solid understanding of how to resolve nondeterminism in our inference systems and inspires others to obtain a full understanding of their systems.
Un bell'articolo tecnico sul funzionamento di un LLM in pratica: https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
Per i non-informatici potremmo sintetizzare che il fatto che un LLM "a temperatura 0" continui a produrre output diversi a fronte dello stesso input è un bug software correggibile dovuto ad ottimizzazioni eccessive che introducono race conditions che a loro volta cambiano l'ordine degli addendi floating point producendo risultati diversi nelle somme.
Non c'è alcuna intelligenza che disponga di autonomia dentro un LLM. È solo un software, deterministico come gli altri, a meno di bug (software o hardware).
Un software programmato statisticamente che anche in fase di compilazione (impropriamente detta "training") può produrre "bitwise identical results", ovvero "modelli" identici a fronte degli stessi dati sorgente.
Nulla di nuovo, chiunque abbia una minima comprensione dell'informatica sapeva già che la variabilità dell'output degli LLM era dovuta a input casuali non registrati, race condition e aritmetica floating point.
Tuttavia ricorderete come l'irriproducibilità del binario prodotto durante il training fosse la scusa con cui l'OSI, ha giustificato una "Open Source AI Definition" scritta sotto dettatura di Meta, Google & friends.
La supercazzola era che poiché il processo di compilazione ("training") non è comunque riproducibile, pretendere tutti i dati sorgente è inutile, perché tanto non c'è modo di verificare la corrispondenza con il binario.
Questa ricerca dimostra empiricamente che l'argomento di OSI era infondato.
Ora l'OSAID è stata rilasciata e il danno è fatto, per la gioia di chi vuol far passare i propri modelli Toxic Candy [1] per "open source".
Giacomo [1] https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy...
Ciao Stefano On Sun, 14 Sep 2025 14:27:56 +0000 Stefano Borroni Barale wrote:
mi sembra che si stia facendo un po' troppo rumore per nulla. O quasi.
Se anche riuscissero a produrre un LLM che a temperatura 0 ritorna ad essere deterministico [...]
Ci sono riusciti, appunto. L'articolo spiega come hanno fatto. Comunque, sebbene da un punto di vista teorico abbiano "scoperto l'acqua calda", l'articolo è rilevante da un punto di vista tecnico e giuridico. Da un punto di vista giuridico, sostenere che la vector mapping machine (aka "rete neurale artificiale") sia imprevedibile perché autonoma e che quindi chi la realizza ed esegue non va considerato responsabile del suo output, si rivela per la menzogna che era. L'output di un LLM o di qualsiasi altro software, basato su "reti neurali artificiali" o meno, è deterministico a meno di bug assolutamente correggibili. Dunque chi lo pubblica su un sito web (come https://chatgpt.com/ https://gemini.google.com/ ) o lo fornisce a terze parti, ne deve rispondere come per qualsiasi altro software rilasciato con bug noti al produttore. Se è _possibile_ rendere perfettamente deterministico il LLM, allora _non_ renderlo deterministico è una scelta di opacità cui si deve tener conto nella valutazione della pericolosità del modello. In altri termini, se possiamo riprodurre il processo di compilazione del modello (impropriamente detto "training") a partire dai dati sorgente, possiamo verificare che effettivamente il fornitore ha fatto tutto il possibile per evitare, ad esempio, di diffamare qualcuno. O che non ha usato dati di cui non disponeva dei diritti. O che non ha introdotto dati fittizzi per danneggiare un gruppo etnico o una nazione avversaria. Per contro, se il produttore di un LLM ha _scelto_ di rendere opaco il proprio prodotto, si potrà ritenere quel prodotto ad alto rischio, perché non è possibile escludere backdoor non identificabili ex-post (vedi [1] e il più recente [2]) Il che ovviamente è il maggiore contributo tecnico dell'articolo: se possiamo verificare che il binario prodotto dal training corrisponde esattamente al sorgente, possiamo verificare che il sorgente non contenga backdoor, garantendo un livello minimo di sicurezza del "modello".
Sarebbe forse interessante dal punto di vista della "explainable Ai"
Beh di certo la disponibilità completa dei dati sorgente, la riproducibilità del processo di compilazione ("training") e output ("inferenze") deterministici, sono condizioni necessarie per spiegare il comportamento di quel tipo di software. A "temperatura 0" potremo spiegare come una determinata sequenza di token è stata prodotta a partire dal prompt, dai testi sorgente, dai seed pseudocasuali etc, e potremo ritenere responsabile il produttore per il significato _apparente_ dell'output, in quanto interamente determinato dalle sue scelte. Ma le informazioni veicolate da quel output continueranno a ridursi a tali scelte: l'atto comunicativo del produttore inizia con la produzione del "modello" e del software di contorno e finisce con l'output inviato all'utente in risposta al suo prompt. D'altrone è ovvio: i LLM sono solo software ottimizzato per ingannare chi non ne comprende il funzionamento, ma non hanno né intelligenza né capacità o intenzionalità comunicativa.
quello che per OSI è LLM open source io non riesco a distinguerlo da quello che da giovani chiamavamo "freeware"
Eddai, la Open Washing Initiative di Maffulli ha fatto un ottimo lavoro! La differenza sta tutta nella confezione! ;-) Grazie all'OSI ora il freeware è open source! Infatti, secondo la OSAID qualsiasi BINARIO che sia rilasciato con una licenza OSI compliant è open source se è opensource il compilatore utilizzato per produrlo e fornisci una descrizione del sorgente. Per gli utenti e gli sviluppatori non c'è alcuna differenza fra freeware e OSAID, ma per le BigTech quella definizione è una linea di difesa contro i pochi obblighi imposti alle aziende dall'AI Act. Giacomo [1] https://ieee-focs.org/FOCS-2022-Papers/pdfs/FOCS2022-4Bu7jGV9xIcveUWYj3oWoi/... [2] https://www.cs.ru.nl/masters-theses/2025/T_van_Harskamp___Implementing_undet...
L'articolo è rilevante da vari punti di vista, anche l'aspetto economico. La nuova azienda di Mira Murati ha già raccolto parecchi miliardi di finanziamenti. AB On Mon, Sep 15, 2025 at 12:40 PM Giacomo Tesio <giacomo@tesio.it> wrote:
Ciao Stefano
On Sun, 14 Sep 2025 14:27:56 +0000 Stefano Borroni Barale wrote:
mi sembra che si stia facendo un po' troppo rumore per nulla. O quasi.
Se anche riuscissero a produrre un LLM che a temperatura 0 ritorna ad essere deterministico [...]
Ci sono riusciti, appunto. L'articolo spiega come hanno fatto.
Comunque, sebbene da un punto di vista teorico abbiano "scoperto l'acqua calda", l'articolo è rilevante da un punto di vista tecnico e giuridico.
Da un punto di vista giuridico, sostenere che la vector mapping machine (aka "rete neurale artificiale") sia imprevedibile perché autonoma e che quindi chi la realizza ed esegue non va considerato responsabile del suo output, si rivela per la menzogna che era.
L'output di un LLM o di qualsiasi altro software, basato su "reti neurali artificiali" o meno, è deterministico a meno di bug assolutamente correggibili. Dunque chi lo pubblica su un sito web (come https://chatgpt.com/ https://gemini.google.com/ ) o lo fornisce a terze parti, ne deve rispondere come per qualsiasi altro software rilasciato con bug noti al produttore.
Se è _possibile_ rendere perfettamente deterministico il LLM, allora _non_ renderlo deterministico è una scelta di opacità cui si deve tener conto nella valutazione della pericolosità del modello. In altri termini, se possiamo riprodurre il processo di compilazione del modello (impropriamente detto "training") a partire dai dati sorgente, possiamo verificare che effettivamente il fornitore ha fatto tutto il possibile per evitare, ad esempio, di diffamare qualcuno. O che non ha usato dati di cui non disponeva dei diritti. O che non ha introdotto dati fittizzi per danneggiare un gruppo etnico o una nazione avversaria.
Per contro, se il produttore di un LLM ha _scelto_ di rendere opaco il proprio prodotto, si potrà ritenere quel prodotto ad alto rischio, perché non è possibile escludere backdoor non identificabili ex-post (vedi [1] e il più recente [2])
Il che ovviamente è il maggiore contributo tecnico dell'articolo: se possiamo verificare che il binario prodotto dal training corrisponde esattamente al sorgente, possiamo verificare che il sorgente non contenga backdoor, garantendo un livello minimo di sicurezza del "modello".
Sarebbe forse interessante dal punto di vista della "explainable Ai"
Beh di certo la disponibilità completa dei dati sorgente, la riproducibilità del processo di compilazione ("training") e output ("inferenze") deterministici, sono condizioni necessarie per spiegare il comportamento di quel tipo di software.
A "temperatura 0" potremo spiegare come una determinata sequenza di token è stata prodotta a partire dal prompt, dai testi sorgente, dai seed pseudocasuali etc, e potremo ritenere responsabile il produttore per il significato _apparente_ dell'output, in quanto interamente determinato dalle sue scelte.
Ma le informazioni veicolate da quel output continueranno a ridursi a tali scelte: l'atto comunicativo del produttore inizia con la produzione del "modello" e del software di contorno e finisce con l'output inviato all'utente in risposta al suo prompt.
D'altrone è ovvio: i LLM sono solo software ottimizzato per ingannare chi non ne comprende il funzionamento, ma non hanno né intelligenza né capacità o intenzionalità comunicativa.
quello che per OSI è LLM open source io non riesco a distinguerlo da quello che da giovani chiamavamo "freeware"
Eddai, la Open Washing Initiative di Maffulli ha fatto un ottimo lavoro! La differenza sta tutta nella confezione! ;-)
Grazie all'OSI ora il freeware è open source!
Infatti, secondo la OSAID qualsiasi BINARIO che sia rilasciato con una licenza OSI compliant è open source se è opensource il compilatore utilizzato per produrlo e fornisci una descrizione del sorgente.
Per gli utenti e gli sviluppatori non c'è alcuna differenza fra freeware e OSAID, ma per le BigTech quella definizione è una linea di difesa contro i pochi obblighi imposti alle aziende dall'AI Act.
Giacomo
[1]
https://ieee-focs.org/FOCS-2022-Papers/pdfs/FOCS2022-4Bu7jGV9xIcveUWYj3oWoi/...
[2]
https://www.cs.ru.nl/masters-theses/2025/T_van_Harskamp___Implementing_undet...
Ciao Giacomo!
Da un punto di vista giuridico, sostenere che la vector mapping machine (aka "rete neurale artificiale") sia imprevedibile perché autonoma e che quindi chi la realizza ed esegue non va considerato responsabile del suo output, si rivela per la menzogna che era.
L'output di un LLM o di qualsiasi altro software, basato su "reti neurali artificiali" o meno, è deterministico a meno di bug assolutamente correggibili. Dunque chi lo pubblica su un sito web (come https://chatgpt.com/ https://gemini.google.com/ ) o lo fornisce a terze parti, ne deve rispondere come per qualsiasi altro software rilasciato con bug noti al produttore.
Se è possibile rendere perfettamente deterministico il LLM, allora non renderlo deterministico è una scelta di opacità cui si deve tener conto nella valutazione della pericolosità del modello. In altri termini, se possiamo riprodurre il processo di compilazione del modello (impropriamente detto "training") a partire dai dati sorgente, possiamo verificare che effettivamente il fornitore ha fatto tutto il possibile per evitare, ad esempio, di diffamare qualcuno. O che non ha usato dati di cui non disponeva dei diritti. O che non ha introdotto dati fittizzi per danneggiare un gruppo etnico o una nazione avversaria.
Per contro, se il produttore di un LLM ha scelto di rendere opaco il proprio prodotto, si potrà ritenere quel prodotto ad alto rischio, perché non è possibile escludere backdoor non identificabili ex-post (vedi [1] e il più recente [2])
Il che ovviamente è il maggiore contributo tecnico dell'articolo:
Non avevo realizzato immediatamente questo risvolto legale. In effetti questo è un effetto molto rilevante.
Eddai, la Open Washing Initiative di Maffulli ha fatto un ottimo lavoro!
As usual. D'altronde alcune dinamiche erano chiare fin dal remoto 2001. Per quanto mi dispiaccia l'open source ha provato di essere peggio del software proprietario. Stef
participants (3)
-
Andrea Bolioli -
Giacomo Tesio -
Stefano Borroni Barale