Una singola RTX 5090 che genera 2.788 token/s con un diffusion LLM: il dato diffuso dal gruppo di ricerca Introspective Diffusion non è un esercizio accademico, ma un segnale concreto per chi lavora su stack locali e self-hosted. Il progetto ORL (On-Policy Residual Learning), completamente open source, affronta il limite storico dei diffusion language model: la necessità di più passaggi forward per produrre testo, che finora ne ha frenato l'adozione nell'inference a bassa latenza.

L'idea di base non è eliminare i passaggi di denoising, ma far convergere il modello più in fretta. Invece di ricalcolare tutto da zero a ogni step, ORL trasporta le previsioni precedenti come contesto residuo e le affina progressivamente. Poiché questi residui sono generati dal modello stesso e cambiano durante l'addestramento, il team evita il disallineamento tra training e inference lavorando su traiettorie fresche prodotte dal modello corrente. A questo si aggiunge una componente di Adjacent Entropy Contraction che spinge ogni passaggio a ridurre l'incertezza rispetto al precedente, senza forzare previsioni già solide.

I risultati comunicati sono numeri di picco, non medie su prompt arbitrari, e riguardano il decoding single-request con batch size 1. Su una singola RTX 5090, LLaDA-2.1-mini con ORL e precisione NVFP4 raggiunge 2.788 token/s. Su 8 GPU B200, DiffusionGemma 26B MoE arriva a 7.708 token/s. Il modello QwenDLM-4B, derivato da Qwen3-4B, registra un miglioramento fino a 6,9× del throughput end-to-end e un pass@1 su HumanEval che sale dall'82,9% all'89,6%. Per LLaDA-2.1-mini bastano 4,2 milioni di token auto-generati e 36 ore-GPU su H100 per ottenere fino a 3× di throughput a qualità comparabile.

Nel confronto diretto con il decoding speculativo su una singola H100, QwenDLM-4B + ORL tocca 1.298 token/s, contro 746 token/s di DFlash e 405 di EAGLE3, a parità di accuratezza misurata. Il confronto è end-to-end: ORL gira su dlmrt, mentre i decoder speculativi usano vLLM.

Sul fronte dell'infrastruttura, il team ha costruito dlmrt, un motore di inference ottimizzato per il decoding diffusion a bassa latenza. Invece di lanciare e sincronizzare ogni step di denoising dalla CPU, dlmrt cattura l'intero ciclo in un CUDA graph e lo esegue sulla GPU. Supporta inoltre l'inference NVFP4 sulle GPU Blackwell, inclusa la RTX 5090 consumer. Nei confronti su singola H100 con modelli e impostazioni identiche, dlmrt risulta da 1,2 a 1,6 volte più veloce di SGLang/vLLM.

È qui che la notizia smette di essere solo un benchmark e diventa un indicatore strutturale. L'attenzione al single-request, e non all'aggregato per richieste concorrenti, sposta il baricentro dell'ottimizzazione. Chi gestisce deployment on-premise o self-hosted spesso non deve servire centinaia di utenti simultanei, ma ridurre la latenza percepita da un singolo flusso. Diffusion LLM con ORL attaccano proprio questo vincolo: se il modello converge in meno passaggi, una GPU consumer di fascia alta può diventare un nodo di inference credibile, senza dover dimensionare cluster per il throughput aggregato.

Il rilascio open source di modelli, codice di training, pipeline di valutazione e motore di inference abbassa ulteriormente la barriera. I team che lavorano su stack locali possono riprodurre i risultati, testare carichi diversi e contribuire al motore. Questo crea pressione sugli ecosistemi di serving esistenti: vLLM e SGLang, pensati soprattutto per modelli autoregressivi e ottimizzazione batch, devono adattarsi a un paradigma di decoding diverso. Allo stesso tempo, i metodi di speculative decoding come DFlash e EAGLE3, che richiedono un modello draft aggiuntivo, si trovano a competere con un approccio che non ne ha bisogno, perché il residuo fa da contesto interno.

Un altro segnale riguarda la quantization. L'uso di NVFP4 su una GPU consumer Blackwell come la RTX 5090 indica che la compressione dei pesi non è solo una leva per i data center, ma anche per chi vuole self-hosted senza saturare la VRAM. In scenari on-premise, la combinazione di quantization aggressiva e motore di inference dedicato può cambiare i conti del TCO: meno GPU per lo stesso livello di servizio a singolo utente, o la possibilità di spostare workload locali che prima richiedevano hardware più costoso.

Va ribadito che i numeri citati sono risultati di picco su benchmark specifici, non una garanzia di prestazioni medie su carichi reali. Ma il valore del lavoro non sta solo nei token/s: sta nell'aver mostrato che un diffusion LLM può funzionare in condizioni operative realistiche per l'inference locale, con un motore open source progettato per quel tipo di carico.

Il gruppo chiede alla community se la latenza single-request sia il collo di bottiglia principale o se ci siano altri aspetti da ottimizzare. La domanda è più che legittima: per chi valuta deployment on-premise, il single-request è spesso il parametro decisivo, ma restano aperti i nodi di memoria, gestione dei checkpoint e integrazione con framework di orchestrazione. La direzione, però, è chiara: i diffusion LLM non sono più solo una curiosità di ricerca, ma un'alternativa concreta per chi vuole tenere i modelli sotto il proprio controllo.