LFM2.5‑DSpark accelera l'inferenza fino a 3,18x

Fino a 3,18 volte più throughput su GPU e fino a 2,87x on‑device. LFM2.5‑DSpark riduce anche la latenza delle function‑call del 57% in media sul modello LFM2.5–2.6B. L’integrazione, compatibile con LFM, è open source e già disponibile a monte¹.

La base tecnica è il collo di bottiglia del decode negli LLM: la latenza viene soprattutto dallo streaming dei pesi dalla DRAM alla SRAM, non dal calcolo. La decodifica speculativa risponde così: un modello “draft” leggero propone token candidati; il modello “target” li verifica tutti in un singolo forward pass, condividendo il costo di caricare i pesi su tutti i token verificati¹.

Nel tempo sono emerse più varianti di speculazione. Tra le più note ci sono EAGLE‑3, DFlash e, più di recente, DSpark. In questo contesto, DSpark combina tre componenti: un backbone parallelo in stile DFlash, condizionato sulle caratteristiche di contesto del modello target, che produce gli hidden state per tutti i token proposti in un solo passaggio; una testa sequenziale leggera, modellata come catena di Markov tra token vicini, che aggiunge dipendenze locali tra i token generati¹.

I numeri pubblicati sintetizzano l’effetto sulla velocità. Su GPU, LFM2.5‑DSpark arriva fino a 3,18x di throughput rispetto alla baseline. Su dispositivi locali, raggiunge fino a 2,87x. Sui carichi con chiamate di funzione, LFM2.5–2.6B vede in media un taglio del 57% della latenza. Questi risultati puntano alla direzione dichiarata: toward on‑device agentic inference¹.

La spiegazione sta nel ripartire il costo di memoria su gruppi di token. Con la verifica in blocco, il modello target sfrutta un unico caricamento dei pesi per più token candidati. Il draft, essendo leggero, può proporre rapidamente sequenze da validare. Insieme, questi passaggi riducono l’impatto del vincolo di banda memoria che caratterizza la fase di decode¹.

Sul fronte dell’adozione, l’integrazione DSpark compatibile con LFM è stata pubblicata upstream. Il supporto è disponibile dal primo giorno per llama.cpp e SGLang. La disponibilità del codice facilita test e integrazione su runtime già diffusi, senza attendere porting separati¹.

Il quadro tecnologico resta quello della speculazione: sfruttare un modello “draft” per generare proposte e farle convalidare in blocco dal modello “target”. DSpark si inserisce in questo filone con un backbone parallelo ispirato a DFlash e una testa sequenziale di tipo Markoviano che cattura dipendenze locali tra token adiacenti. L’obiettivo è massimizzare il riuso del caricamento dei pesi durante la verifica e ridurre il tempo per step di decode, in linea con i vincoli di memoria osservati negli LLM¹.

Il richiamo all’inferenza agentica on‑device segnala dove si vuole arrivare: tagliare la latenza nelle function‑call e sfruttare meglio il tempo tra generazione e verifica, con il modello LFM2.5–2.6B che fa da riferimento per le misure dichiarate¹.