Liquid AI presenta LFM2.5‑VL‑3B‑DSpark: decodifica speculativa per modelli visione‑lingua fino a 3,13× più veloce

Introduzione

Liquid AI ha annunciato LFM2.5‑VL‑3B‑DSpark, un modello sperimentale di speculative decoding pensato per il suo modello vision‑language LFM2.5‑VL‑3B. Il nuovo drafter introduce circa 280  milioni di parametri aggiuntivi e promette un’accelerazione significativa della fase di decodifica senza modificare i risultati prodotti dal modello principale. I pesi sono disponibili su Hugging Face in formato Safetensors e GGUF, con supporto immediato in SGLang, MLX‑VLM e llama.cpp. La licenza di rilascio è la LFM Open License v1.0, che consente l’uso commerciale gratuito solo a società con fatturato annuo inferiore a 10 milioni di dollari.

Cos’è la decodifica speculativa per un VLM

In un modello tradizionale, ogni token viene generato con una singola forward pass. La decodifica speculativa aggiunge un piccolo drafter che propone in anticipo diversi token; il modello di destinazione verifica l’intero blocco in una sola passata, mantenendo i token che concorda. DSpark segue la stessa ricetta dei drafter DSpark per i modelli testuali descritta nel DSpark paper. Il drafter legge gli stati nascosti del modello target da più layer e predice i prossimi k token.

Il punto chiave del design è che la modalità non influisce sul drafter: una volta che i token raggiungono gli strati nascosti, sia i token testuali sia i frammenti di immagine sono semplicemente tensori. Perciò Liquid AI ha riutilizzato lo stesso algoritmo di inferenza anche per il modello vision‑language.

Architettura e parametri del drafter

Il drafter è un modello semplificato basato esclusivamente su meccanismi di attenzione. Dopo una serie di ablation, è emersa la configurazione migliore: 4 layer e una dimensione di blocco di 9 token. Liquid AI consiglia un blocco di 8 o 9 token a seconda dell’hardware; sui dispositivi Apple silicon si utilizza il blocco 8.

• Decoder stack (4 layer): 193,0 M parametri
• Hidden‑state projection: 21,0 M parametri
• Markov head: 65,5 M parametri
• Norms + confidence head: 6,4 k parametri
• Totale: 279,5 M parametri

L’embedding e la testa di language model sono condivisi con il modello target, per cui il drafter non li replica. Questo aumento equivale a un incremento dell’8,9 % del conteggio totale dei parametri distribuiti.

Addestramento

L’addestramento è stato effettuato tramite supervised fine‑tuning su dati che coprono i compiti più comuni di vision‑language, per 10 epoche. Tutte le sperimentazioni di ablation e l’intero ciclo di training sono stati eseguiti esclusivamente su hardware AMD, dimostrando la portabilità della soluzione.

Risultati dei benchmark

La valutazione è stata condotta con il benchmark MMSpec su sei tipologie di task: General VQA, Text VQA, Image Captioning, Chart VQA, Complex Reasoning e Multi‑turn Conversation. Le prove sono state eseguite con batch size = 1, temperatura = 0 e pesi a 16 bit per il vision encoder e il backbone. I dati sono stati raccolti su Pipette, l’infrastruttura pubblica di Liquid AI per il benchmarking su dispositivi.

Tabella di velocità

• MLX‑VLM, M5 Max MacBook Pro (blocco 8): decodifica 2,30×‑3,13×, end‑to‑end 1,56×‑2,62×, token accettati per passata 3,24‑4,34
• llama.cpp, M3 Ultra (blocco 8): decodifica 1,57×‑2,14×, end‑to‑end 1,30×‑1,77×, token accettati per passata 3,31‑4,50
• SGLang, 1× H100 80 GB (blocco 9): decodifica 2,04×‑2,66×, end‑to‑end 1,64×‑2,27×, token accettati per passata 3,46‑4,57

Le cifre “fino a” per decodifica e end‑to‑end spesso derivano da task differenti. Su M5 Max, il valore massimo di 3,13× proviene da COCO Captioning, mentre il 2,62× di end‑to‑end è relativo a MMMU‑Pro. L’accettazione dei token rimane in un intervallo simile su entrambe le piattaforme Apple, suggerendo che dipenda più dal drafter e dal carico di lavoro che dal runtime specifico.

A livelli di concorrenza più elevati, DSpark mantiene un vantaggio di throughput su ogni livello misurato su un singolo H100 in SGLang, anche se il divario si riduce con l’aumento della concorrenza.

Qualità dell’output e temperatura

Con decodifica greedy, il modello target verifica ogni token proposto, quindi l’output è identico a quello del modello base. Con temperature diverse da zero e campionamento abbinato, la decodifica speculativa conserva la distribuzione di probabilità del modello target, come dimostrato da Leviathan et al. Tuttavia, temperature più alte riducono l’accettazione perché la probabilità si distribuisce su più token candidati, diminuendo il throughput.

Perché i guadagni end‑to‑end sono minori sui dispositivi edge

La decodifica speculativa velocizza solo la fase di generazione dei token; la codifica dell’immagine e la fase di pre‑fill rimangono invariate. Un VLM deve prima codificare l’immagine, poi elaborare centinaia di token visivi insieme al prompt. Su dispositivi edge con capacità di calcolo inferiore rispetto a GPU data‑center, la pre‑fill rappresenta una porzione maggiore della latenza totale. Liquid AI inquadra questo fenomeno con la legge di Amdahl: il speedup totale è limitato dalla parte non accelerata. Questo spiega