L’inferenza AI è più lenta del necessario
Continuous batching asincrono taglia tempi del 24%. Modelli Qwen e Granite dimostrano che architettura e distillazione contano più dei parametri.
L’asincronia nel continuous batching riduce i tempi di inferenza del 24%
Due GPU identiche, stesso modello, stessa richiesta. Una termina in 300 secondi, l’altra in 228. La differenza non è nella potenza di calcolo, ma in come il sistema orchestra l’inferenza. Il continuous batching asincrono è la dimostrazione che il vero spreco nell’AI non sono i parametri, ma l’architettura software che li gestisce. Mentre il settore corre a sfornare modelli da centinaia di miliardi di parametri, Hugging Face, IBM e Alibaba mostrano che la strada giusta è un’altra: efficienza architetturale, distillazione, e una gestione più intelligente delle risorse.
Il collo di bottiglia che nessuno vede: la GPU aspetta la CPU
Il problema è noto a chi lavora con sistemi di inferenza in tempo reale: il batching sincrono tiene la GPU in idle per quasi un quarto del tempo totale di esecuzione. La GPU completa i suoi calcoli in pochi millisecondi, ma deve attendere che la CPU prepari il batch successivo, che sincronizzi i buffer, che gestisca la coda. Un’attesa che si accumula e che, su carichi sostenuti, diventa un freno visibile. L’approccio asincrono proposto da Hugging Face elimina questo overhead: la CPU prepara il batch mentre la GPU sta ancora elaborando il precedente, e il passaggio di contesto avviene senza lock. Il risultato è concreto: l’asincronia nel continuous batching riduce il tempo di generazione da 300 a 228 secondi, un taglio netto del 24%.
Nessun nuovo hardware, nessuna quantizzazione: pura ingegneria del software.
Da 400 a 27 miliardi: quando l’architettura batte la scala
Se il continuous batching dimostra che si può sprecare meno, i nuovi modelli Qwen 3.6 e IBM Granite R2 dimostrano che si può ottenere di più con molto meno. I modelli Qwen 3.6 da 27 e 35 miliardi di parametri superano i modelli della generazione precedente da 120B e 400B. Non è un miglioramento marginale: su diversi benchmark di ragionamento e coding, il 35B supera il 120B con un decimo dei parametri. E il dato che fa riflettere è il footprint di memoria: il modello da 35B funziona su circa 20 GB di memoria e supera modelli da 120 miliardi che richiedono oltre 70 GB. Questo significa che può girare su una singola GPU consumer, senza bisogno di cluster o quantizzazioni estreme. La distilazione e le scelte architetturali — come l’uso di attention a finestra e training multi-task — permettono di comprimere la conoscenza senza sacrificare la qualità.
Embedding compatti, prestazioni da gigante: i Granite R2
IBM rilascia la famiglia Granite Embedding Multilingual R2, e anche qui il pattern si ripete. Il modello più piccolo, Granite Embedding Multilingual R2: modelli open source con contesto 32K, ha solo 97 milioni di parametri. Eppure su MTEB Multilingual Retrieval ottiene un punteggio MTEB 60.3, superando di 9.4 punti multilingual-e5-small. Rispetto alla versione precedente R1, il guadagno è di 12.2 punti. Il fratello maggiore da 311 milioni di parametri raggiunge un MTEB 65.2, con un miglioramento di 13.0 punti su R1. Non c’è trucco: la differenza sta in un training più ricco (contest length da 32K, training multilingue su 100+ lingue) e in una architettura di embedding ottimizzata per la retrieval. Il modello è compatibile sentence-transformers, quindi può essere integrato in pipeline esistenti con poche righe di codice. Per chi costruisce sistemi RAG o semantic search, avere un embedding che eguaglia modelli dieci volte più grandi significa ridurre latenza e costi infrastrutturali senza compromessi.
Il messaggio è chiaro: la corsa ai parametri è finita. La vera innovazione oggi sta nell’efficienza — sia a livello architetturale (come la distillazione di Qwen o il training multi-task di Granite), sia a livello di runtime (come il continuous batching asincrono). Per chi sviluppa, questo significa poter eseguire modelli di alto livello su hardware accessibile, ridurre la dipendenza da cluster dedicati e, soprattutto, concentrare l’ingegneria dove conta: sull’ottimizzazione del flusso, non sulla moltiplicazione dei parametri.
