Due cifre bastano a mostrare il problema: circa 100 token/s per GPT-6-Sol e 5.6-Sol, mentre GPT-6.1-Sol e GPT-6-Astra si fermano intorno a 60 token/s. I dati, raccolti da un utente Reddit sulla piattaforma artificialanalysis.com e collegati a indiscrezioni uscite da Azure Foundry, non dimostrano nulla da soli. Ma rimettono al centro una questione che i benchmark sul serving degli LLM tendono a nascondere: quanti passaggi di inference servono davvero per emettere un token.

La speculazione tecnica parte da un'architettura ricorrente, a volte chiamata looped transformer. Invece di produrre un token con un singolo forward pass, il modello attraverserebbe più volte gli stessi pesi. Secondo le indiscrezioni, GPT-6-Sol opererebbe con tre passaggi di inference per token, mentre GPT-6.1-Sol ne richiederebbe due. Alcuni lettori ipotizzano che il nome Astra indichi proprio il modello a tre passaggi e che 6.1-Sol condivida gli stessi pesi con un'iterazione in meno.

Se quei passaggi multipli sono reali, il token/s come unità di misura diventa fuorviante. Un modello può dimezzare il throughput apparente non perché sia meno efficiente, ma perché esegue più lavoro per token. Chi pianifica un deployment self-hosted e confronta modelli solo su token/s rischia di sottostimare l'occupazione della VRAM, il tempo di calcolo sulla GPU e il TCO complessivo. La differenza tra 100 e 60 token/s non è un semplice calo di prestazioni: può essere un raddoppio dei passaggi necessari.

C'è un secondo strato. Il post di QuackerEnte nota che i numeri di Luna raccontano un'altra storia: 5.6 Luna viaggiava tra 126 e 137 token/s, mentre 6.0 Luna scende intorno a 110-115 token/s. Da qui l'ipotesi di un modello annidato, sul genere di quanto mostrato in passato da NVIDIA: modelli più piccoli dentro un'impronta unificata, con parametri attivi ridotti o un solo passaggio per token. Se Astra, Sol e Luna condividessero davvero lo stesso set di pesi, un fornitore cloud potrebbe servire fasce diverse di utenza senza moltiplicare i cluster. Sol, usato da pochi e senza ricavi diretti, non richiederebbe hardware separato: basterebbe modulare passaggi e batching sul parco GPU già attivo.

Per l'ecosistema locale e open source il segnale è duplice. La speranza espressa nel post è che DeepSeek, Qwen e GLM comincino a esplorare architetture a passaggi multipli, spinti dalla possibilità di sfruttare meglio i pesi a parità di memoria. Ma non basta cambiare architettura: servono framework di serving e strumenti di benchmarking che separino il numero di passaggi dalla velocità di emissione dei token. Oggi un dato aggregato come i token/s non consente di confrontare modelli con costi computazionali diversi. In un contesto self-hosted, dove il costo marginale è l'elettricità e l'hardware già acquistato, quella trasparenza è ancora più importante.

Non ci sono conferme ufficiali. I numeri citati arrivano da una piattaforma indipendente e da screenshot non attribuibili con certezza. Ma questa è proprio la ragione per cui il post interessa: più che una fuga di notizie, è un esercizio di reverse engineering indiretto sui costi di serving. L'autore scrive di non poter provare nulla e chiude con una nota personale: 0,7 token al secondo per un modello biologico da circa 100T parametri, alimentato da due caffè e una barretta di muesli. Il dettaglio è volutamente ironico, ma il punto resta: quando l'unità di misura è opaca, anche le speculazioni di una community diventano un modo per riportare il calcolo reale al centro.