LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: Non ne scegli uno, ne agganci uno

La ricerca che porta le persone qui è un confronto, ma la risposta onesta è che LFM2.5-VL-3B-DSpark e LFM2.5-VL-3B non sono due cose tra cui scegliere. Il secondo è un modello visione-linguaggio da 3,1B che puoi scaricare e servire. Il primo è un modello draft da 279,5M di parametri che esiste solo per stare davanti al secondo e fargli decodificare più velocemente. Togli il drafter dallo stack e non produce nulla; non puoi eseguirne il benchmark da solo, perché "da solo" non è una configurazione che supporta. Il vero confronto è tra LFM2.5-VL-3B eseguito da solo e lo stesso modello eseguito con il drafter agganciato.

Se la si legge in questo modo, la decisione si riduce a una sola domanda: la memoria aggiuntiva e la complessità di runtime aggiuntiva ti fanno guadagnare abbastanza latenza da contare per il tuo carico di lavoro? I numeri della stessa Liquid AI dicono di sì per il lavoro a forte componente di decodifica e dicono esplicitamente di no quando domina il prefill. Nessuno dei due aspetti è stato riprodotto al di fuori dell'azienda.

I due checkpoint, fianco a fianco

Ciò che li differenzia è l'intera questione, quindi vale la pena mettere i due repository uno accanto all'altro prima che inizi la discussione sulla velocità.

• Ruolo — LFM2.5-VL-3B genera testo e risponde riguardo alle immagini; LFM2.5-VL-3B-DSpark propone token che esso deve verificare e non genera nulla di utilizzabile da solo

• Parametri — 3,1B per il target, 279,5M BF16 per il drafter, che secondo Liquid rappresenta un aumento dell'8,9% del numero di parametri distribuiti

• Architettura — l'obiettivo è un modello ibrido costruito su un backbone LFM2.5-2.6B con un encoder visivo SigLIP2 NaFlex; il drafter è composto da 4 layer di full attention a dimensione nascosta 2.048 con grouped-query attention, più una Markov head e una confidence head

• Finestra di contesto — 32.768 token per il target; il drafter non ha un contesto proprio e eredita quello del target

• Encoder di visione — SigLIP2 NaFlex 400M sul target; il drafter non ne ha alcuno e non vede mai direttamente l'immagine

• Vocabolario — 128.000, e l'embedding e la testa LM del drafter sono legati al target anziché duplicati, motivo per cui la tassa di memoria è inferiore a quanto 279,5M parametri suggerirebbero

• Licenza — entrambi sono distribuiti con la licenza LFM1.0 di Liquid, che su Hugging Face è "other" anziché una licenza OSI, quindi leggi i termini prima di un deployment commerciale

• Formati — il target viene distribuito come quantizzazioni safetensors, GGUF, ONNX e MLX; il drafter viene distribuito come safetensors e un singolo GGUF F16 di circa 567 MB

Una riga di quell'elenco merita di essere evidenziata perché è la ragione meccanica per cui questo abbinamento riesce a funzionare: il drafter non è un piccolo modello di visione. Non ha alcun encoder visivo e non tocca mai l'immagine. Quando i token raggiungono gli strati nascosti da cui il drafter genera le bozze, una patch di immagine e un token di testo sono entrambi soltanto tensori, quindi la modalità è invisibile al calcolo di drafting. È ciò che ha permesso a Liquid di trasferire su un VLM una tecnica sviluppata per i modelli di testo senza riprogettarla.

Ciò che il redattore cambia e ciò che lascia invariato

Il modello target non cambia. Non è marketing — è la proprietà di correttezza della decodifica speculativa. Con la decodifica greedy, ogni token bozza viene verificato dal target, quindi l'output è esattamente ciò che il target avrebbe prodotto da solo. In impostazioni di campionamento corrispondenti a temperatura non nulla, la distribuzione dell'output coincide con quella del target. Il drafter scambia memoria con tempo e non tocca nient'altro.

Il che significa che ogni valore di qualità che si può trovare per LFM2.5-VL-3B si applica invariato alla configurazione abbinata. Nella valutazione di Liquid stessa, il target ottiene 80,7 su ScreenSpot-v2, 61,5 su BLINK, 58,3 su MuirBench, 73,1 su MME, 63,3 su MMStar, 81,3 su ChartQA e 88,7 su POPE — tutti dichiarati dal fornitore, nessuno riprodotto in modo indipendente, e tutti ugualmente veri sia che il drafter sia collegato sia che non lo sia. Qui non c'è alcun compromesso tra qualità e velocità da valutare, e qualsiasi pagina di confronto che ne presenti uno ha frainteso il modello.

Ciò che cambia è il costo di un token in termini di tempo reale. Liquid misura speedup di decodifica da 2,04× a 2,66× su una singola H100 in BF16 tramite SGLang con dimensione del blocco 9, da 2,30× a 3,13× su un Apple M5 Max tramite MLX-VLM con dimensione del blocco 8, e da 1,57× a 2,14× su un M3 Ultra tramite llama.cpp. End-to-end, le stesse esecuzioni si attestano a 1,64×–2,27×, 1,56×–2,62× e 1,30×–1,77× rispettivamente. Quelle coppie sono l'intero argomento: la decodifica migliora all'incirca il doppio rispetto all'end-to-end, e il divario è la parte del carico di lavoro che il drafter non può toccare.

Il problema del prefill, dichiarato dal fornitore

La frase più utile nell'annuncio di Liquid stesso è quella che argomenta contro una lettura illimitata del suo titolo. L'inferenza visione-linguaggio paga un costo di prefill che l'inferenza testuale non paga: l'immagine passa attraverso un encoder visivo, e il backbone linguistico elabora poi le centinaia di token visivi che quell'encoder emette. Su un dispositivo edge quel prefill è una quota consistente della latenza end-to-end. La decodifica speculativa accelera solo la decodifica: la codifica visiva e il prefill restano invariati. Laddove il prefill domina, un'accelerazione di decodifica di 3× si traduce in un guadagno end-to-end molto più piccolo.

Questa è la legge di Amdahl applicata dal fornitore al proprio prodotto, e dovrebbe orientare chi legge questa pagina. Una lunga trascrizione di una singola pagina scansionata, una didascalia, una conversazione a più turni che porta avanti un'unica immagine — a forte prevalenza di decode, e il drafter si guadagna i suoi 279,5M di parametri. Una domanda breve su un'immagine grande ad alta risoluzione — a forte prevalenza di prefill, e non se li guadagna. Metti lo stesso target su un server ad alta concorrenza e il quadro cambia di nuovo: Liquid misura una frontiera tra throughput e interattività anziché un singolo numero, e riporta che DSpark mantiene il proprio vantaggio a ogni livello di concorrenza testato, mentre il divario si restringe all'aumentare della concorrenza.

Due note di delimitazione dell'ambito più brevi dalla stessa fonte. Tutte le misurazioni 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 della release. Se il tuo piano era quello di abbinare un export target a 4 bit al drafter perché tutto il fascino di un VLM da 3B sta nel rientrare in pochi gigabyte, quella combinazione non è quella che è stata misurata.

Quanto ti costa davvero allegarlo

La memoria è il costo visibile e la scheda lo quantifica: l'8,9% di parametri in più nello stack di deployment. La complessità di runtime è quella invisibile. SGLang richiede la v0.5.19 o successiva e una riga di lancio che include --speculative-algorithm DSPARK, il percorso del modello draft e una dimensione di blocco; l'esempio della scheda stessa disabilita anche la cache radix e fissa una frazione di memoria statica, che sono decisioni di serving su cui ora devi ragionare. MLX-VLM richiede la v0.7.2 o successiva e riceve il drafter tramite --draft-model, ma la decodifica DSpark in quel contesto usa attualmente il campionamento greedy, quindi la temperatura deve essere forzata a 0 — un vincolo reale se la tua applicazione si basa sulla diversità di campionamento. llama.cpp funziona tramite il drafter GGUF abbinato al target GGUF, non con il checkpoint safetensors originale.

C'è un ulteriore costo che si manifesta in produzione anziché in un benchmark: il drafter e il target devono procedere insieme. Il disallineamento di versione tra loro è una modalità di errore che non esiste in un deployment con un solo modello, e rilasciare l'uno o l'altro in modo indipendente è ormai un problema che coinvolge due artefatti.

Questo è un pairing self-hosted. OrcaRouter non instrada LFM2.5-VL-3B né il suo drafter — li scarichi entrambi e li servi tu stesso — quindi la questione del routing riguarda tutto ciò a cui il modello piccolo passa la mano. La maggior parte dei deployment che abbinano un VLM edge da 3B al drafter ha comunque query a cui il modello piccolo non dovrebbe rispondere, e inviarle a un unico endpoint che copre oltre 200 modelli al prezzo di listino di ciascun provider, con failover automatico se un provider peggiora, è una sola integrazione invece di una per fornitore. Significa anche che nel momento in cui un provider taglia un prezzo, la tua tariffa lo riflette lo stesso giorno anziché al prossimo rinnovo contrattuale.

Quale scaricare

Se il tuo carico di lavoro è orientato alla decodifica e il tuo hardware è uno dei tre testati da Liquid, aggancia il drafter: il rovescio della medaglia è contenuto, perché l'output è dimostrabilmente quello del target e il costo in memoria è inferiore a un decimo di un modello. Se la tua latenza è dominata dal prefill, oppure stai eseguendo un target quantizzato, oppure dipendi dal campionamento non greedy in un runtime che non ha rimosso quella restrizione, esegui LFM2.5-VL-3B da solo. È veloce di per sé: 228 token al secondo su un M5 Max, 116 su un AMD Ryzen AI Max+ 395 e 20 su un Galaxy S26 Ultra, tutti dati del produttore, in circa 3 GB di memoria.

Quello che ancora nessuno può dirti è se i numeri di Liquid reggono sul tuo hardware. Al momento della stesura, il drafter aveva 37 download su Hugging Face e nessuna riproduzione indipendente di alcuna cifra nelle sue tabelle. L'ingegneria è solida e l'argomentazione di correttezza è una dimostrazione più che un'affermazione, ma la grandezza è una misurazione — e le misurazioni di un solo laboratorio su un solo insieme di macchine sono esattamente il tipo di numero da verificare di persona prima di metterlo in un piano di capacità.

OrcaRouter raggiunge oltre 200 modelli tramite un'unica chiave, con il prezzo di listino di ciascun provider passato direttamente con markup dello 0% e failover automatico tra provider. prezzo di listino del provider passato direttamente con markup dello 0% L'abbinamento in questa pagina è self-hosted in ogni caso - il router serve per tutto ciò a cui il modello piccolo passa la mano, e significa che un taglio di prezzo di un provider si riflette sulla tua tariffa lo stesso giorno.