In questo articolo Indice dei contenuti 2 sezioni
Con Mercury 2.5 la startup Inception prova a cambiare le regole di come un modello linguistico mette insieme le parole, e lo fa dichiarando numeri che fanno alzare più di un sopracciglio: fino a 1.107 token al secondo su GPU NVIDIA, una finestra di contesto da 260.000 token e un listino di circa 0,18 euro per milione di token in ingresso e circa 0,70 euro per milione in uscita. Il punto centrale, però, non sta nella tabella dei prezzi ma nell’architettura, perché qui non si parla della classica generazione autoregressiva bensì di un approccio basato sulla diffusione.
La differenza è meno astratta di quanto sembri. I modelli linguistici a cui siamo abituati costruiscono il testo un pezzo alla volta, dove ogni token nasce dopo aver visto quello precedente, in una catena di operazioni strettamente legate fra loro. Mercury lavora in modo diverso: parte da una rappresentazione incompleta o rumorosa dell’intera sequenza e la sistema poco per volta, correggendo più posizioni nello stesso passaggio. Concettualmente la tecnica arriva dai modelli di diffusione usati per generare immagini, solo che con il testo il gioco si complica parecchio, perché i token sono discreti e le relazioni di significato molto più rigide.
Cosa cambia davvero con la generazione parallela
Il vantaggio più evidente della generazione parallela è la riduzione del numero di passaggi necessari per arrivare a una risposta lunga. Attenzione però a non leggerlo come una scorciatoia gratuita: i token non sono mai del tutto indipendenti fra loro, e il modello deve comunque tenere in piedi coerenza sintattica, significato e legami interni alla frase. Su questo fronte la ricerca sui diffusion language model ha lavorato parecchio, sperimentando decoding adattivo, criteri di confidenza e strategie per stabilire quali posizioni aggiornare a ogni iterazione. Il guadagno concreto, alla fine, dipende dall’hardware, dalla lunghezza dell’output e da come viene configurata l’inferenza.
Rispetto a Mercury 2, che rappresentava la generazione precedente, Inception dichiara un salto di qualità del 40% e l’ampliamento del contesto da 128.000 a 260.000 token. Sulla velocità serve invece una distinzione che spesso si perde per strada: i 1.107 token al secondo misurano il throughput, cioè quanti token vengono prodotti nell’unità di tempo, che non coincide con la latenza percepita da chi sta dall’altra parte dello schermo. Quella dipende anche dal time to first token, ovvero quanto si aspetta prima che la risposta cominci a comparire. Nelle applicazioni vocali e interattive entrambe le metriche pesano sull’esperienza finale.
Il terreno di gioco sono gli agenti software
Le caratteristiche dichiarate rendono Mercury 2.5 interessante soprattutto per gli scenari in cui il modello viene interrogato molte volte di seguito. Pensiamo a un agente software: deve interpretare una richiesta, scegliere gli strumenti da usare, leggere i risultati e infine produrre una risposta. Tagliare il tempo di ciascuna di queste operazioni significa abbassare la latenza complessiva, in particolare quando più attività possono girare in parallelo. Il modello supporta inoltre reasoning regolabile, chiamate parallele agli strumenti e output JSON vincolato a uno schema, tre elementi che nel lavoro con gli agenti contano molto.
Un esempio citato dall’azienda riguarda Augment Code, che impiega Mercury per compiti come la compressione del contesto e la selezione degli strumenti MCP. In una specifica configurazione Inception parla di un tempo di elaborazione sceso da circa 150 secondi a 27, accompagnato da una riduzione dichiarata dei costi. Sono però dati forniti dal produttore, non benchmark indipendenti, e per mettere davvero a confronto modelli diversi servirebbero condizioni hardware, prompt e metriche equivalenti. La distinzione non è un dettaglio da puristi, perché nel settore la differenza fra un numero da comunicato stampa e un test verificabile da terzi si vede eccome quando si passa dalla demo al lavoro quotidiano.
