LFM2.5-VL-3B-DSpark: il Drafter da 279,5M di Liquid AI è stato rilasciato sei giorni prima che chiunque lo annunciasse

Esiste una versione di questa storia in cui LFM2.5-VL-3B-DSpark è un nuovo modello. Non lo è. È un modello draft da 279,5 milioni di parametri per il speculative decoding che esiste esattamente per un unico scopo — rendere più veloce il decoding del modello visione-linguaggio di Liquid AI, LFM2.5-VL-3B — e non è in grado di generare una risposta utilizzabile da solo. Il motivo per cui vale comunque la pena leggerne è la tempistica: i pesi sono arrivati su Hugging Face il 18 settembre 2026, senza alcun annuncio allegato, sono rimasti lì per sei giorni e solo il 24 settembre è arrivato un post sul blog del fornitore. Radar ha individuato il repo nel vuoto.

Quel divario è anche il confine di ciò che è conoscibile in questo momento. Tutto nel repository — la scomposizione dei parametri, la dimensione del blocco, le integrazioni con i framework, la licenza — è un file su disco che tu o io possiamo aprire. Ogni valore di accelerazione è misurato dal fornitore, dall'harness di benchmark di Liquid stesso, e nessuno al di fuori dell'azienda ha pubblicato una riproduzione. Questo articolo tiene deliberatamente separate quelle due pile.

Cosa contiene effettivamente il repository

Apri la scheda del modello e la natura della cosa è inequivocabile. LFM2.5-VL-3B-DSpark è un modello draft il cui target è fissato nei suoi metadati: base_model: LiquidAI/LFM2.5-VL-3B. Non lo indirizzi verso un modello diverso e non lo servi da solo.

• Parametri totali della bozza — 279,5M, BF16, di cui 193,0M è lo stack del decoder a 4 strati, 65,5M è una testa Markov, 21,0M è una proiezione dello stato nascosto e 6,4k sono normalizzazioni più una testa di confidenza

• Backbone — 4 layer di attenzione completa, dimensione nascosta 2.048, dimensione intermedia 6.144 con SiLU/SwiGLU, attenzione grouped-query con 32 teste di attenzione e 8 teste key-value, dimensione testa 64

• Teste aggiuntive — una testa Markov a rango 256 e una testa di confidenza, ed è ciò che distingue il drafting di DSpark da un semplice drafter parallelo

• Dimensione del blocco — 9 durante l'addestramento; 8 o 9 in inferenza a seconda dell'hardware, e 8 specificamente su Apple silicon

• Vocabolario — 128.000, legato alla lingua di arrivo anziché trasportato dalla bozza

• Peso nello stack di deployment — Liquid afferma che il drafter aumenta dell'8,9% il numero di parametri in deployment

L'8,9% è il numero a cui aggrapparsi. La promessa per questa classe di modelli non è mai "un'inferenza più veloce è gratis"; è "un'inferenza più veloce ti costa circa un decimo della memoria di un modello". Con 279,5 milioni di parametri extra oltre a un modello target da 3,1 miliardi, si tratta di una tassa più contenuta di quanto suggerirebbe la dimensione del solo drafter, perché l'embedding e la testa LM sono legati al modello target e non duplicati.

DSpark è una tecnica DeepSeek prima di essere un modello Liquid

La denominazione induce confusione, quindi vale la pena essere precisi. DSpark non è un'invenzione di Liquid AI né una famiglia di modelli. È un framework di decodifica speculativa proveniente da una linea di ricerca separata, descritto in un articolo del luglio 2026 come decodifica speculativa con pianificazione basata sulla confidenza e generazione semi-autoregressiva. Le sue tre idee: una backbone parallela che genera una bozza di un intero blocco in un'unica passata in avanti, un modulo sequenziale leggero che ripristina una certa dipendenza tra token di bozza adiacenti affinché l'accettazione non crolli alla fine del blocco, e un verificatore che accorcia la finestra di verifica per ciascuna richiesta quando la confidenza della bozza stessa suggerisce che la coda verrà rifiutata.

Quello che Liquid ha fatto è applicare quella ricetta ai modelli visione-linguaggio e rilasciare un checkpoint. La scheda è schietta sul fatto che questo trasferimento è meno drammatico di quanto sembri: dal punto di vista del drafter, la modalità è irrilevante, perché nel momento in cui i token raggiungono gli strati nascosti una patch di immagine e un token di testo sono entrambi soltanto tensori. Ecco perché una tecnica sviluppata sui modelli di testo si trasferisce a un VLM senza essere reinventata — ed è anche il motivo per cui il drafter non può essere venduto come una nuova capacità.

Liquid aveva già rilasciato i drafter DSpark per testo — le versioni companion 2.6B, 8B-A1B e 1.2B-Instruct sono state pubblicate ad agosto 2026, con le esportazioni GGUF arrivate il 19 agosto. Il drafter per la visione è la stessa idea estesa al ramo multimodale, ed è la quarta o quinta voce di una linea, non un debutto.

I numeri di speedup, e chi li ha misurati

Ogni valore riportato di seguito è di Liquid stesso, raccolto sull'infrastruttura di benchmarking di Liquid, e nessuno di essi ha una riproduzione indipendente. Considerali un tetto dichiarato dal fornitore, non un risultato atteso. La scheda separa l'accelerazione di decodifica da quella end-to-end, cosa che conta più del dato di punta.

• Migliore accelerazione della decodifica — 3,13× su COCO, misurata con MLX-VLM su un Apple M5 Max con dimensione del blocco 8, FP16, dimensione batch 1, temperatura 0

• Miglior speedup di decodifica su GPU — 2,66× su COCO, SGLang su una singola H100 80GB, BF16, dimensione del blocco 9

• Miglior speedup di decodifica di llama.cpp — 2,14× su COCO, Apple M3 Ultra, dimensione blocco 8

• Intervallo di decodifica H100 su sei attività di visione — da 2,04× a 2,66×, con end-to-end da 1,64× a 2,27×

• Intervallo di decodifica M5 Max — da 2,30× a 3,13×, end-to-end da 1,56× a 2,62×

• Intervallo di decodifica M3 Ultra — da 1,57× a 2,14×, end-to-end da 1,30× a 1,77×

• Accettazione della bozza — circa da 3,2 a 4,5 token accettati per passata di verifica del target, su tutti e tre gli stack

L'andamento in quegli intervalli è la parte onesta. I guadagni end-to-end sono costantemente la metà più piccola di ogni coppia, perché il drafter accelera la decodifica e nient'altro. Nota anche che lo stesso drafter, con la stessa dimensione del blocco, si attesta a 3,13× su uno stack e a 1,57× su un altro — il tasso di accettazione è una proprietà del drafter e del carico di lavoro, ma il guadagno in tempo effettivo è una proprietà dell'hardware e dell'overhead del runtime. Un'affermazione "2,66× più veloce" senza stack associato non è un'affermazione su cui puoi agire.

Due punti di correttezza dalla scheda meritano di essere affermati chiaramente, perché sono ciò che rende un drafter accettabile in produzione. Con la decodifica greedy, la decodifica speculativa è esatta: il target verifica ogni token proposto, quindi il testo è quello che il target avrebbe prodotto da solo. Con impostazioni di campionamento abbinate a temperatura diversa da zero, preserva la distribuzione di output del target. La formulazione di Liquid — ottieni lo speedup, non un modello diverso — è accurata per quanto afferma, e la scheda è onesta sul fatto che aumentare la temperatura riduce l'accettazione e quindi erode il beneficio di throughput.

Ciò che ammette il post di Liquid stesso

Il post del blog del 24 settembre è più utile della scheda del modello per un motivo: ne indica il limite. L'inferenza visione-linguaggio paga un costo di prefill che l'inferenza testuale non paga — l'immagine deve passare attraverso un encoder visivo, e il backbone linguistico deve poi elaborare le centinaia di token visivi che quell'encoder produce. Su un dispositivo, quel prefill domina la latenza end-to-end. La decodifica speculativa accelera solo la decodifica. La codifica visiva e il prefill restano invariati. Liquid invoca la legge di Amdahl contro il proprio prodotto e fa notare che, laddove il prefill rappresenta una grande quota del tempo di esecuzione, un grande speedup nella decodifica comporta solo un modesto miglioramento end-to-end.

Si tratta di un vincolo reale sulla decisione d'acquisto, e spiega perché il time-to-first-token non è nell'elenco degli elementi che questo drafter migliora. Implica anche che i carichi di lavoro che ne traggono maggior beneficio sono quelli che generano output lunghi a partire da un'immagine modesta — una didascalia, una lunga trascrizione OCR, una conversazione a più turni con un'immagine mantenuta — piuttosto che quelli che rispondono a una domanda breve su un'immagine grande.

Il post aggiunge due ulteriori limiti di ambito. Tutti i numeri utilizzano l'elaborazione a 16 bit sia per l'encoder visivo sia per il backbone linguistico, e l'accelerazione dei modelli quantizzati è fuori dall'ambito di questa release. Dato che il punto di forza principale di un VLM edge da 3B è l'esecuzione in un paio di gigabyte, "gli speedup sono misurati in FP16" è un'avvertenza significativa per chiunque avesse pianificato di abbinarlo a un export a 4 bit. Liquid osserva inoltre che il drafter è stato addestrato interamente su hardware AMD.

Eseguendolo

Il supporto fin dal primo giorno è reale e copre tre runtime, più di quanto ottengano la maggior parte dei drafter. SGLang su NVIDIA richiede la v0.5.19 o successiva e guida il drafter attraverso --speculative-algorithm DSPARK con il percorso di draft e una dimensione di blocco pari a 9. MLX-VLM su Apple silicon richiede la v0.7.2 o successiva e rileva il drafter quando viene passato con --draft-model; c'è un unico punto critico — la decodifica DSpark in MLX-VLM al momento usa il campionamento greedy, quindi la temperatura deve essere impostata a 0. Per llama.cpp esiste un repository GGUF separato, con un'unica esportazione F16 di circa 567 MB, e la scheda è esplicita: il drafter quantizzato va abbinato al target quantizzato, non al checkpoint safetensors originale.

Il punto in cui un livello di routing si guadagna il suo posto qui non è su questo modello — OrcaRouter non instrada LFM2.5-VL-3B-DSpark o LFM2.5-VL-3B, e questa è un'abbinatura di drafter self-hosted che scarichi e servi da te. È sul resto dello stack che lo circonda. La stessa applicazione che esegue un piccolo modello vision open-weight on-device di solito ha un percorso di fallback per le query che il modello piccolo non riesce a gestire, e puntare quel percorso verso un singolo endpoint che copre oltre 200 modelli — fatturato al prezzo di listino di ciascun provider senza ricarichi aggiunti, con failover automatico quando un provider degrada — è un'integrazione più piccola rispetto a istituire un secondo contratto con un fornitore. Il drafter migliora una gamba di quell'architettura; il router è ciò che impedisce all'altra gamba di diventare un secondo progetto.

Ciò che non è ancora noto

Al momento della scrittura, il repository ha 37 download e 6 like. Non esiste alcuna voce per questo drafter su nessun aggregatore pubblico di benchmark, nessuna riproduzione da parte di terzi di alcuno degli intervalli di speedup, e nessuna misurazione indipendente del tasso di accettazione su hardware che Liquid non ha testato. Inoltre non ci sono benchmark di qualità sulla scheda per ovvi motivi — il drafter preserva l'output per costruzione, quindi i numeri di qualità appartengono a LFM2.5-VL-3B, e la scheda rimanda ai benchmark di quel modello anziché inventarne di propri.

Un dettaglio nei metadati è un piccolo indizio di quanto sia recente la cosa: il modello porta un tag di libreria SGLang e un flag di algoritmo SGLang che esiste appositamente per invocarlo. Il supporto del framework doveva arrivare prima dell'annuncio, il che è coerente con l'intervallo di sei giorni tra il repository e il post sul blog.

Quindi: un pezzo di ingegneria autentico, utile e dall'ambito ristretto, annunciato una settimana dopo il suo rilascio, il cui intero valore è un numero misurato dal fornitore su hardware che potresti non possedere. Se stai servendo LFM2.5-VL su una H100 o su un Mac della serie M e il tuo carico di lavoro è a forte prevalenza di decodifica, il costo in memoria è dell'8,9% e il lato negativo è quasi nullo perché l'output è dimostrabilmente quello del target. Se la tua latenza è dominata dal prefill, oppure contavi sull'export a 4 bit, il post di Liquid stesso ti dice che non aiuterà. La riproduzione, quando arriverà, è la cosa da aspettare.

OrcaRouter mette oltre 200 modelli dietro un'unica chiave al prezzo di listino del provider con 0% di ricarico, ed esprime il percorso di fallback come un livello di routing anziché come codice applicativo. Il drafter è self-hosted in ogni caso: è il router che impedisce che il segmento a cui il tuo modello piccolo passa il testimone diventi un secondo progetto.