Il collo di bottiglia di un agente AI in produzione quasi mai è l’intelligenza del modello. È l’attesa. Ogni chiamata a uno strumento, leggere un database, interrogare un gestionale, scrivere una riga nel CRM, costa un giro di inferenza, e in una catena di dieci passaggi quei decimi di secondo diventano l’esperienza d’uso. Il 20 agosto 2026 Liquid AI ha pubblicato LFM2.5-DSpark, un metodo di decodifica speculativa che taglia del 57% la latenza media del function-calling su LFM2.5-2.6B e spinge il throughput fino a 2,67x su quello stesso modello e a 3,18x sul MoE da 8B. Per chi porta gli agenti AI on device dentro l’azienda c’è una notizia in più: il codice è già dentro llama.cpp, non è un annuncio in attesa di rilascio.
In questo articolo scoprirai:
- Che cosa cambia DSpark: 57% di latenza in meno sulle chiamate a strumenti
- Come funziona la decodifica speculativa: uno piccolo indovina, uno grande verifica
- Dall’H100 al MacBook: quanto accelera davvero un modello che gira in locale
- Perché a un’impresa italiana interessa un agente che non esce dal perimetro
- On-device, cloud o ibrido: la prima decisione sugli agenti AI on device per le aziende
Che cosa cambia DSpark: 57% di latenza in meno sulle chiamate a strumenti
Il dato che conta per chi costruisce agenti è uno solo: DSpark riduce del 57% la latenza media del function-calling su LFM2.5-2.6B negli scenari multi-tool, quelli in cui il modello concatena più chiamate prima di rispondere, come misurato nella scheda tecnica del metodo pubblicata da Liquid AI. È il caso d’uso tipico di un agente aziendale, non un benchmark accademico.
I numeri di DSpark modello per modello: quale riga guardare
Attenzione però a come si legge il «fino a 3x» del titolo. Il picco di 3,18x su GPU è misurato su LFM2.5-8B-A1B nel test MATH500 su una H100 da 80GB in BF16; il modello da 2,6 miliardi di parametri, quello pensato per il deployment leggero, guadagna in media 2,67x, passando da 323 a 864 token al secondo (tabelle pubblicate da Liquid AI nella scheda del metodo). Il picco on-device di 2,87x è invece del modello da 1,2B su HumanEval, girato su un MacBook Pro M4 Max. Sono numeri ottimi, ma appartengono a modelli diversi: chiunque pianifichi un’infrastruttura deve guardare la riga del proprio modello, non il massimo della tabella.
Quello che DSpark non cambia: la qualità dell’output
Il punto più importante è ciò che non cambia. La qualità dell’output resta identica alla decodifica greedy di partenza: l’accuratezza sui benchmark (pass@1, exact match) è invariata, perché un token proposto viene accettato solo se coincide con quello che avrebbe prodotto il modello grande. Non è una compressione, non è una quantizzazione, non è un compromesso sulla qualità in cambio di velocità. È lo stesso modello che risponde prima. Questa distinzione è centrale quando si valuta se portare un LLM in produzione su hardware limitato, ed è il terreno di lavoro tipico dell’inference engineering, cioè l’ottimizzazione dei modelli in produzione.
Come funziona la decodifica speculativa: uno piccolo indovina, uno grande verifica
La fase di decodifica di un Large Language Model è limitata dalla memoria, non dal calcolo: gran parte del tempo se ne va nel trasferire i pesi dalla DRAM alla SRAM, non nel moltiplicare matrici. La GPU, in pratica, aspetta. La decodifica speculativa sfrutta questo spazio vuoto.
L’idea è del 2022 e viene da un lavoro di Yaniv Leviathan, Matan Kalman e Yossi Matias, Fast Inference from Transformers via Speculative Decoding: un modello piccolo e veloce propone diversi token in avanti, il modello grande li verifica tutti insieme in un unico passaggio e tiene solo quelli corretti. Gli autori misuravano già allora un’accelerazione di 2x-3x su T5-XXL con output identici, senza riaddestramento né modifiche all’architettura.
I tre pezzi che DSpark aggiunge alla decodifica speculativa
DSpark aggiunge tre pezzi a questo schema. Un backbone parallelo in stile DFlash, condizionato sul contesto del modello target, che produce gli stati nascosti di tutti i token bozza in un colpo solo. Una testa sequenziale leggera, modellata come catena di Markov fra token vicini, che alza il tasso di accettazione nelle posizioni più lontane, quelle dove di solito la speculazione fallisce. E un verificatore a confidenza schedulata, che stima la probabilità di sopravvivenza di ogni token e taglia le code poco promettenti quando verificarle costerebbe più di quanto faccia risparmiare.
I modelli bozza pesano circa 300 milioni di parametri (295,7M per l’1,2B, 327,7M per gli altri due) e sono stati addestrati per 15 epoche su un mix di dati SFT, chat, codice e function-calling, secondo la documentazione del metodo. Dettaglio rivelatore: l’epoca finale è stata scelta in base al tasso di accettazione più alto, non alla loss più bassa. Sul modello da 2,6B il tasso medio di accettazione è 4,81 token per ciclo di verifica.
Dall’H100 al MacBook: quanto accelera davvero un modello che gira in locale
Sui numeri on-device conviene essere precisi, perché è lì che si gioca la promessa. Su un MacBook Pro M4 Max, in FP16 GGUF con backend Metal, LFM2.5-2.6B passa da una media di 61 a 139 token al secondo, cioè 2,27x medio sui cinque benchmark testati (MATH500, HumanEval, MBPP, GSM8K, MT-Bench). Il modello da 1,2B fa meglio: da 138 a 350 token al secondo, 2,54x medio.
DSpark su architetture MoE: dove l’accelerazione on-device non arriva
Poi c’è il caso che rende credibile il resto. LFM2.5-8B-A1B, il modello MoE, on-device guadagna appena 1,18x in media, e Liquid AI lo scrive, attribuendolo ai limiti attuali dell’implementazione MoE nel backend Metal di llama.cpp. Un fornitore che pubblica anche il proprio risultato peggiore sta dando un’informazione utile: su architetture a esperti il vantaggio della decodifica speculativa locale oggi non c’è.
DSpark verificato da terzi: llama.cpp adesso, SGLang non ancora
La verifica indipendente più interessante arriva dalla pull request upstream. La PR #27383 che porta DSpark in llama.cpp è stata effettivamente unita il 20 agosto 2026: nei test allegati, su una RTX 4070 Laptop, il throughput medio sale da 94,0 a 199,0 token al secondo (2,12x) con un tasso di accettazione di 3,54 token su 8. Su hardware consumer, misurato da terzi, il guadagno resta oltre il doppio.
Una nota di onestà sul «day-one support». Per llama.cpp è vero e verificabile. Per SGLang serve ancora la PR #31041: la documentazione ufficiale di SGLang sulla decodifica speculativa elenca EAGLE-2, EAGLE-3, MTP, DFLASH, STANDALONE e NGRAM, ma DSPARK non compare ancora fra gli algoritmi rilasciati. Chi pianifica un deployment su SGLang lavora su codice non ancora in release.
Perché a un’impresa italiana interessa un agente che non esce dal perimetro
Qui la notizia tecnica incontra un problema di mercato molto concreto. Secondo il rapporto Imprese e ICT dell’Istat pubblicato il 15 dicembre 2025, le imprese italiane con almeno 10 addetti che usano almeno una tecnologia di AI sono passate dal 5,0% del 2023 all’8,2% del 2024 fino al 16,4% del 2025. Il divario però si allarga: 53,1% fra le grandi imprese contro 15,7% fra le PMI, 37 punti percentuali di distanza contro i circa 20 del 2023.
Gli ostacoli reali agli agenti AI in azienda: normativa, dati, privacy
Interessante è il perché chi valuta poi non investe. Dopo le competenze (58,6%), gli ostacoli più citati nella rilevazione Istat sono l’incertezza del quadro normativo (47,3%), la qualità dei dati disponibili (45,2%) e le preoccupazioni su privacy e protezione dei dati (43,2%). Tre freni su quattro riguardano dove finiscono i dati e chi risponde di cosa, non le capacità del modello.
AI Act e agenti on-device: il dato che non lascia la macchina
Il contesto regolatorio ha appena stretto: dal 2 agosto 2026 si applica il resto dell’AI Act, con le sole eccezioni previste dall’articolo 6(1), inclusi gli obblighi sui sistemi ad alto rischio. Vale la pena leggere nel dettaglio cosa prevede l’AI Act e chi deve adeguarsi prima di scegliere un’architettura.
Ed è qui che un modello da 2,6B che risponde a 139 token al secondo su un portatile smette di essere una curiosità. Non è la strada del cloud sovrano europeo, dove i dati escono comunque dall’azienda ma restano sotto giurisdizione UE: è la strada opposta, in cui il dato non lascia la macchina. Se il vostro caso d’uso tocca cartelle cliniche, contratti o anagrafiche clienti, la differenza è sostanziale.
On-device, cloud o ibrido: la prima decisione sugli agenti AI on device per le aziende
Questa notizia riguarda l’ottimizzazione dell’inferenza, non il rilascio del modello: se cercate le caratteristiche di base, il pezzo giusto è quello su LFM2.5-2.6B, l’agente AI locale che gira su qualsiasi device. Qui il tema è che lo stesso modello, con lo stesso output, adesso risponde due o tre volte più in fretta.
Quando conviene un agente AI on-device e quando conviene il cloud
La scelta fra locale, cloud e ibrido non si fa a intuito e non ha una risposta universale. Il locale vince quando il dato non può muoversi, quando la connettività non è garantita o quando la catena di chiamate a strumenti è lunga e la latenza di rete si accumula a ogni passaggio. Il cloud resta imbattibile quando serve il modello di frontiera, quando i picchi di carico sono imprevedibili o quando nessuno in azienda può occuparsi di manutenere l’infrastruttura. L’ibrido è quasi sempre la risposta reale: un modello leggero locale che gestisce il grosso delle richieste e instrada al cloud solo ciò che lo richiede davvero. Per capire cosa sappiano fare concretamente questi sistemi, la nostra guida agli agenti AI è il punto di partenza; per il funzionamento sottostante, il pezzo su come funziona davvero un modello di AI, dal testo che entra alla risposta che esce.
Il punto è che questa decisione dipende dai vostri dati, dai vostri vincoli normativi e dall’hardware che avete già. Noi di MIMIR la affrontiamo caso per caso all’inizio di ogni onboarding, perché non vendiamo solo un prodotto ma l’assistenza dedicata per arrivarci: se avete un’esigenza aziendale su AI e agenti, parlarne con qualcuno che ha già fatto quella valutazione costa meno che scoprire l’errore a integrazione finita.
Fonti:
- Liquid AI — LFM2.5-DSpark: il metodo, i benchmark e i modelli bozza
- Leviathan, Kalman, Matias — Fast Inference from Transformers via Speculative Decoding (2022)
- llama.cpp — PR #27383 che porta DSpark upstream, unita il 20 agosto 2026
- Documentazione SGLang — speculative decoding
- AI Act — timeline di applicazione
