The Pulse

Liquid AI aggiunge il decoding DSpark a LFM2.5-VL-3B

Un articolo del team di Liquid AI descrive un modello draft sperimentale per accelerare il decoding.

AI.info Team · Scritto con l’IA · verificato · 2026-09-24

Il 24 settembre 2026 Liquid AI ha rilasciato un modello sperimentale di speculative decoding per il suo modello visivo-linguistico LFM2.5-VL-3B. Il componente aggiuntivo, chiamato LFM2.5-VL-DSpark, è progettato per accelerare la generazione di testo, lasciando al modello bersaglio il compito di verificare i token proposti. Il modello draft aggiunge circa 280 milioni di parametri, pari all’8,9% dei 3 miliardi di parametri del modello bersaglio.

DSpark propone, LFM2.5-VL-3B verifica

Lo speculative decoding usa un modello draft più piccolo per proporre più token alla volta. Il modello bersaglio, più grande, controlla questi candidati in un unico passaggio, accettando quelli che corrispondono e fornendo un proprio token quando un candidato non supera la verifica. Questo può ridurre il numero di passaggi onerosi nella generazione del testo, senza chiedere al modello più piccolo di sostituire quello bersaglio.

Per la versione visivo-linguistica, il modello draft acquisisce gli stati nascosti da determinati layer di LFM2.5-VL-3B. Le patch dell’immagine e i token di testo vengono proiettati in una rappresentazione condivisa prima di questi layer, così il modello draft lavora con vettori di stati nascosti della stessa dimensionalità per entrambe le modalità di input. L’algoritmo di inferenza resta lo stesso dei modelli DSpark testuali dell’azienda.

Il modello draft ha quattro layer composti esclusivamente da meccanismi di attenzione. L’azienda ha scelto questa architettura dopo test di ablazione con tre, quattro e cinque layer e l’ha addestrata per 10 epoche su una miscela di dati di fine-tuning supervisionato visivo-linguistico, ponderata in base ai carichi di lavoro previsti. L’azienda riferisce che il tasso di accettazione è migliorato con l’aggiunta di token di addestramento, prima di raggiungere rendimenti decrescenti. La ripartizione dei componenti indica 193 milioni di parametri per lo stack del decoder, 21 milioni per la proiezione degli stati nascosti, 65,5 milioni per la head di Markov e 6.400 per le normalizzazioni e la head di confidenza, per un totale di 279,5 milioni.

I guadagni di velocità variano a seconda del dispositivo e del compito

Liquid AI ha testato il sistema su sei carichi di lavoro visivo-linguistici: domande e risposte visive generali, domande e risposte visive incentrate sul testo, generazione di didascalie per immagini, domande su grafici, ragionamento complesso e conversazioni a più turni. Le valutazioni hanno usato una dimensione del blocco DSpark pari a otto e hanno seguito il benchmark MMSpec.

Su un M5 Max con MLX, il decoding è stato da 2,30× a 3,13× più veloce nei diversi compiti, mentre la latenza end-to-end è migliorata da 1,56× a 2,62×. Su un M3 Ultra con llama.cpp, i guadagni nel decoding sono variati da 1,57× a 2,14×, con miglioramenti end-to-end da 1,30× a 1,77×.

I dati relativi a H100 nell’articolo sono discordanti. Il riepilogo indica accelerazioni del decoding fino a 2,66×, mentre i risultati dettagliati riportano un intervallo da «20,4x a 2,66x». L’articolo non spiega la differenza, quindi da questi dati non è possibile riportare un risultato coerente per il decoding su H100. Per la latenza end-to-end su H100, i risultati dettagliati riportano miglioramenti da 1,64× a 2,27×.

L’elaborazione delle immagini limita l’accelerazione complessiva

DSpark accelera il decoding, non la codifica delle immagini né il prefill del prompt. Un modello visivo-linguistico deve prima elaborare un’immagine attraverso il suo encoder visivo, poi gestire i token visivi e il prompt testuale. Secondo Liquid AI, questi passaggi possono rappresentare una quota sostanziale del tempo totale di risposta, in particolare sui dispositivi edge con una capacità di calcolo inferiore a quella delle GPU dei datacenter. Questo contribuisce a spiegare perché il miglioramento end-to-end può essere inferiore all’accelerazione del decoding.

Il modello draft è disponibile nei formati Safetensors e GGUF, con supporto per llama.cpp, MLX-VLM e SGLang. Per le integrazioni, gli utenti hanno bisogno di build compatibili. Il modello bersaglio verifica ogni token proposto; secondo l’articolo, questo rende esatto lo speculative decoding, con un output greedy che corrisponde a quello del modello bersaglio eseguito da solo. Il risultato è una fase di decoding più breve, abbinata a un modello draft da 279,5 milioni di parametri, anziché un encoder visivo più veloce.