LFM2.5-2.6B-DSpark: il drafter da 328M che rende l'agente on-device di Liquid 2,3× più veloce

Nessuno al di fuori di Liquid AI ha eseguito LFM2.5-2.6B-DSpark sul proprio hardware e pubblicato un risultato. È da qui che bisogna partire onestamente con questo modello, perché l'intera questione è una rivendicazione di prestazioni: non è un 2.6B migliore, è un modello draft da 328M di parametri che si pone davanti al modello agentico 2.6B LFM2.5-2.6B e propone token che quest'ultimo deve verificare, così l'agente gira circa il doppio più veloce senza cambiare il proprio output.

Rilasciato il 20 agosto 2026 con un approfondimento tecnico su Hugging Face e un post di accompagnamento sul blog di Liquid, LFM2.5-2.6B-DSpark è il fiore all'occhiello di una piccola famiglia di checkpoint drafter per decodifica speculativa pubblicati da Liquid quel giorno. Tutto ciò che segue nella colonna delle velocità è misurato dal fornitore e non ancora confermato in modo indipendente; tutto ciò che si trova nel repository, i formati e il supporto del framework sono semplicemente lì per essere verificati.

Cos'è DSpark, in un respiro

La decodifica speculativa è il trucco di far girare un modello bozza economico davanti a quello vero: il bozzista indovina la prossima manciata di token, il target verifica l'intero lotto in un'unica passata in avanti e conserva i token con cui è d'accordo. Quando le previsioni sono giuste, avanzi di più token al prezzo di uno, quindi la produttività aumenta senza toccare i pesi del target. DSpark — la tecnica, originariamente proposta dai ricercatori di DeepSeek nel luglio 2026 e già implementata in DeepSeek-V4 — è una versione di quel trucco ottimizzata per piccoli modelli on-device. Liquid la chiama decodifica speculativa a pianificazione della confidenza, e ha tre componenti mobili: un backbone parallelo che produce stati nascosti per tutti i token bozza in un'unica passata, una testa sequenziale leggera che modella la dipendenza tra token adiacenti così che il tasso di accettazione non crolli verso la fine del blocco, e un verificatore che pota i suffissi a bassa confidenza quando controllarli costerebbe più di quanto risparmi.

Quell'ultimo pezzo è ciò che rende DSpark diverso da un semplice drafter: non spinge sempre un blocco completo attraverso la verifica. Quando la fiducia del draft dice che un suffisso difficilmente verrà accettato, accorcia il blocco e risparmia il calcolo sprecato. Il blocco di draft è di nove token, quindi il target ne verifica fino a dieci alla volta.

Il redattore, in cifre

Il checkpoint LFM2.5-2.6B-DSpark è un modello draft da 0,3 miliardi di parametri, basato esclusivamente sull'attenzione: cinque layer di attenzione completi (dimensione nascosta 2.048, attenzione a query raggruppate con 32 teste e 8 teste chiave-valore), un vocabolario di 128K token, una testa di Markov con rango 256 e una testa di confidenza. Liquid lo ha addestrato per 15 epoche su un mix di dati di istruzioni, conversazioni, codice e chiamate di funzione — su hardware AMD — e ha selezionato l'epoca in base al tasso di accettazione più alto piuttosto che alla loss più bassa.

Quel tasso di accettazione è il numero che decide quanto vale il drafter. Su cinque benchmark con batch size 1 e temperatura 0, LFM2.5-2.6B-DSpark ha mediato 4.83 token accettati per passo di decodifica su una H100 e 4.42 su una M4 Max — circa metà del blocco accettato, ed è da qui che derivano i raddoppi di velocità.

Gli speedup, etichettati

Tutti i seguenti dati provengono dalle misurazioni di Liquid AI — SGLang su una singola H100 80GB in BF16, e llama.cpp con il backend Metal su un MacBook Pro M4 Max in FP16 GGUF, batch size 1, temperatura 0 — e nessuno di essi è stato riprodotto da una parte indipendente al momento della stesura di questo documento:

• Media H100 — 2.67×, da 323 a 864 token/s. Per benchmark: MATH500 3.06×, HumanEval 2.56×, MBPP 2.64×, GSM8K 2.22×, MT-Bench 2.87×.

• Media M4 Max — 2,27×, da 61 a 139 token/s. Per benchmark: MATH500 2,25×, HumanEval 2,63×, MBPP 2,11×, GSM8K 2,36×, MT-Bench 1,99×.

• Tool calling — negli scenari di chiamata di funzioni multi-tool, la latenza media è diminuita del 57%.

Contesto della famiglia — il drafter più grande della famiglia, LFM2.5-8B-A1B-DSpark, ha raggiunto fino a 3,18× su H100 e il drafter da 1,2B fino a 2,87× su M4 Max; i numeri di 2,6B sopra sono nella media.

Due cose contano in quei numeri oltre alle medie. Primo, sono misurati a temperatura 0 e batch size 1 — la configurazione che favorisce la speculazione e la configurazione in cui si svolge per lo più il lavoro interattivo degli agenti on-device. Anche la garanzia di identità vale in questo caso: la decodifica speculativa verifica ogni token proposto, quindi con decodifica greedy il testo emesso è esattamente quello che il target avrebbe prodotto da solo. Secondo, il divario si riduce con l'aumentare della concorrenza: su una singola H100, Liquid riporta che il vantaggio di DSpark converge intorno al batch size 128, quindi il drafter è un vantaggio in termini di latenza per carichi di lavoro interattivi e ricchi di tool, non una soluzione magica per il throughput grezzo di un server al massimo delle prestazioni.

Cosa è confermato, e cosa no.

Confermato, nel senso che il repository è pubblico e verificabile: il drafter viene distribuito come Safetensors (BF16) e GGUF; si abbina al LFM2.5-2.6B post-addestrato, non alla base; il supporto dal primo giorno è arrivato a monte in llama.cpp (con kernel Metal sperimentali) e in SGLang; è concesso in licenza ai sensi della LFM Open License v1.0 di Liquid; e — importante per chiunque stia pianificando in base a questo — la scheda del modello dichiara che nessun provider di inferenza lo serve, quindi è un componente da eseguire da sé.

Non ancora confermato: che le accelerazioni si riproducano su altre architetture e configurazioni (nessuno al di fuori di Liquid ha pubblicato una misurazione), come si comporta il drafter con il campionamento invece che con la decodifica greedy, e se il dato della latenza di chiamata strumentale del 57% regga su harness per agenti reali oltre all'harness di benchmark usato da Liquid. Nessuna di queste è un'accusa — la release ha un giorno — ma sono la differenza tra un numero promettente e uno verificato.

Eseguendolo

In SGLang usi una build con supporto DSpark, avvii il server verso il modello target e nomini il drafter: l'algoritmo speculativo è DSPARK, il percorso del modello draft punta a LiquidAI/LFM2.5-2.6B-DSpark, e la dimensione del blocco viene letta dal config.json del draft. In llama.cpp carichi il GGUF target con il GGUF draft come modello draft e imposti il tipo di spec su draft-dspark, con la dimensione del blocco letta dai metadati sidecar. Entrambe le integrazioni sono state integrate a monte, quindi non servono fork: basta una build abbastanza recente per contenerle.

Quando vale la pena aggiungerlo

LFM2.5-2.6B-DSpark giustifica i circa 0,3 GB di memoria aggiuntiva quando si distribuisce effettivamente l'agente 2.6B dove Liquid lo ha progettato per vivere — su un telefono, un laptop o un dispositivo edge — per carichi di lavoro interattivi o di chiamata di strumenti che sono vincolati alla latenza e funzionano in modalità greedy. È precisamente il profilo in cui il fattore 2,27× su dispositivo e la riduzione del 57% della latenza delle chiamate di strumenti fanno la differenza. È meno interessante se si serve con batch elevato su un server (il guadagno di velocità converge verso 1×), o se il carico di lavoro viene eseguito con temperatura superiore a zero, dove i numeri riportati non sono più applicabili. E se si utilizza la variante 8B-A1B della famiglia, da notare il caso limite: il suo guadagno su dispositivo oggi è solo di circa 1,18×, perché la verifica dei token di bozza attiva più esperti nel backend Metal di llama.cpp — Liquid lo segnala come problema noto.

Niente di DSpark cambia dove gira l'agente 2.6B: è una storia di self-hosting per design, e starà accanto ai modelli hosted che già chiami. Quel mix di un drafter locale e una dozzina di endpoint API è esattamente il tipo di infrastruttura che un livello di routing serve a comprimere: una chiave API su oltre 200 modelli, failover automatico quando un provider degrada, e prezzi di listino dei provider trasmessi con markup 0%, così il confronto dei costi tra locale e hosted per un agente di classe 2.6B resta leggibile invece di vivere in un foglio di calcolo.

Il modo giusto di leggere LFM2.5-2.6B-DSpark oggi è come una promettente affermazione di velocità, misurata dal fornitore e non ancora verificata in modo indipendente, associata a un checkpoint reale, scaricabile ed eseguibile. Se distribuisci l'agente 2.6B sul dispositivo, il drafter è economico da provare e facile da rimuovere — aggiungi i due flag speculativi al comando SGLang, mantieni la decodifica greedy e misura sul tuo carico di lavoro prima di fidarti del 2.3×. La repository c'è; la verifica indipendente è il punto aperto.