LFM2.5-8B-A1B-DSpark vs LFM2.5-2.6B-Base: la parte veloce contro la materia prima

Ordina la famiglia LFM2.5 in base a ciò che ogni checkpoint può fare da solo, e LFM2.5-8B-A1B-DSpark e LFM2.5-2.6B-Base si trovano alle estremità opposte della linea — e nessuna delle due estremità può rispondere a una domanda. Il primo è un modello draft da 327,7 milioni di parametri che esiste esclusivamente per far sì che il modello edge mixture-of-experts di Liquid AI generi token più velocemente. Il secondo è un checkpoint pre-addestrato grezzo da 2,69 miliardi di parametri che esiste esclusivamente per essere messo a punto in qualcos'altro. Entrambi sono stati rilasciati ad agosto 2026 con la LFM Open License v1.0 di Liquid, entrambi sono a un download di distanza su Hugging Face, ed entrambi sono facilissimi da scaricare per sbaglio — perché i loro nomi li fanno sembrare due versioni della stessa cosa.

I nomi sono la trappola. "DSpark" sembra il nuovo fiore all'occhiello scintillante della famiglia, e "Base" sembra il semplice default che puoi davvero eseguire. Nessuna delle due cose è vera. Il checkpoint DSpark non può rispondere da solo a nulla — propone solo token che LFM2.5-8B-A1B deve verificare. Anche Base non può rispondere a nulla, ma per la ragione opposta: è un modello di base non ottimizzato che predice testo, ma non è mai stato sottoposto a post-addestramento per diventare un modello chat o agente. Non è una rivalità: è una pipeline. Un checkpoint si trova proprio alla fine dello stack di servizio, l'altro proprio all'inizio di una sessione di addestramento.

Due checkpoint che condividono un nome, non un lavoro.

LFM2.5-8B-A1B-DSpark (rilasciato il 20 agosto 2026) è un modello draft per decodifica speculativa: una rete basata solo su attenzione a cinque strati, un blocco di nove token proposti per passo e una testa di Markov sul vocabolario di 128.000 token del target. Lo carichi insieme al LFM2.5-8B-A1B — un MoE da 8,3B totali, ~1,5B attivi, rilasciato il 28 maggio — il draft indovina i prossimi token, e il target verifica l'intero blocco in un'unica passata in avanti, mantenendo tutto ciò che accetta. Poiché il target controlla ogni token, l'output con decodifica greedy è identico a quello del solo LFM2.5-8B-A1B: "senza perdite per costruzione", per usare l'espressione di Liquid. Il draft è una componente di velocità, non un cervello. È stato rilasciato insieme ai draft gemelli per LFM2.5-1.2B-Instruct e LFM2.5-2.6B, ciascuno in Safetensors e GGUF, con supporto dal primo giorno in SGLang e llama.cpp.

LFM2.5-2.6B-Base (rilasciato il 4 agosto 2026) è l'altra estremità della pipeline: una base da 2,69 miliardi di parametri in uno stack ibrido a 30 livelli — 22 blocchi di short-convolution a doppio gate più 8 blocchi di attenzione a query raggruppate — pre-addestrata su circa 34 trilioni di token, con una fase intermedia di addestramento che estende il contesto a 128K. Non ha template di chat, nessun instruction tuning e nessun benchmark pubblicato, e la stessa scheda del modello di Liquid lo consiglia solo per un fine-tuning esteso. Il suo unico scopo è essere la materia prima che una pipeline di post-addestramento in quattro fasi — due round di SFT, specializzazione dell'insegnante, distillazione on-policy, quindi apprendimento per rinforzo agentico — trasforma nell'agente di chiamata di strumenti LFM2.5-2.6B. Stessa famiglia, stessa licenza, stessa pagina di download. Lavori completamente diversi.

Fianco a fianco: sette dimensioni, due lavori

Poiché i due checkpoint svolgono funzioni diverse, il confronto onesto tiene distinti i ruoli di entrambe le parti:

• Che cos'è — LFM2.5-8B-A1B-DSpark è un modello draft di decodifica speculativa da 0.3B; LFM2.5-2.6B-Base è un modello foundation pre-addestrato grezzo da 2.69B.

• Con cosa funziona — il DSpark draft si abbina al MoE LFM2.5-8B-A1B (8,3B totali, ~1,5B attivi per token); la Base gira da sola, ma solo come predizione testuale non messa a punto.

• Uso standalone — DSpark non produce nulla da solo; accelera solo un target. Base genera testo, ma nessun comportamento utile del prodotto — nessuna capacità di seguire istruzioni, nessuna chiamata a strumenti, nessun template di chat.

• Qualità dell'output — DSpark eredita l'output greedy esatto del target, perché ogni token proposto viene verificato; Base non ha alcun benchmark pubblicato su alcun compito, per scelta progettuale.

• Velocità — DSpark aggiunge al suo target una media misurata dal fornitore di 2,54× su un H100 (fino a 3,18× su MATH500) e 1,18× su un M4 Max, non replicata; Base non ha alcuna rivendicazione sulla velocità di inferenza.

• Impronta di memoria — DSpark aggiunge circa 0,3 GB di pesi draft accanto al target; Base è il 2,69B completo, eseguibile in meno di 2,5 GB, la più piccola base seria della famiglia.

• Formati e disponibilità — DSpark è disponibile in Safetensors e GGUF con supporto di SGLang e llama.cpp dal primo giorno; Base è disponibile in Safetensors più GGUF, ONNX e MLX e funziona su Transformers, vLLM, SGLang, llama.cpp e MLX. Nessuno dei due è attualmente servito da un provider di inferenza — entrambi sono checkpoint self-host.

Gli unici numeri in questo confronto provenivano da un solo laboratorio.

Ogni dato quantitativo qui riportato è una misurazione di un singolo fornitore, effettuata il giorno del rilascio della bozza e non ancora riprodotta in modo indipendente — va letto come promettente, non verificato. Liquid ha misurato LFM2.5-8B-A1B-DSpark con batch size 1, temperatura 0, su una singola H100 da 80GB in BF16 con SGLang e su un MacBook Pro M4 Max in FP16 GGUF con i kernel Metal sperimentali di llama.cpp. Sulla H100 la coppia ha raggiunto una media di 2,54× (418 → 1.074 token al secondo), con un miglior risultato singolo di 3,18× su MATH500 (428 → 1.362 tok/s) e un tasso di accettazione medio di circa 7 token proposti su 10. Sulla M4 Max la stessa coppia ha registrato una media di appena 1,18× (90 → 106 tok/s) — il caso limite on-device segnalato dalla stessa Liquid, perché la verifica di un blocco attiva più esperti nell'attuale backend Metal MoE e sposta più traffico di pesi attraverso il bus di memoria.

Il lato Base di questo confronto non ha numeri, e questa assenza è di per sé la specifica. LFM2.5-2.6B-Base è stato pre-addestrato, non post-addestrato; non è mai stato valutato per chat, uso di strumenti o comportamento da agente, perché nessuno intendeva che fosse usato in quel modo. Le sue cifre significative sono architetturali: 2,69 miliardi di parametri, contesto da 128K, tokenizer in 16 lingue, meno di 2,5 GB per essere eseguito. Non si esegue il benchmark di un modello di base; si esegue il benchmark di ciò in cui lo si trasforma con il fine-tuning.

C'è un'ironia familiare che vale la pena menzionare prima di decidere qualsiasi cosa. La bozza di cui parla questo articolo — quella per la 8B-A1B — è precisamente quella che guadagna meno su un laptop (1.18×), mentre la bozza sorella per la famiglia 2.6B, che accelera la sorella post-addestrata di questa stessa Base, fa registrare una media di 2.27× su un M4 Max con una riduzione del 57% della latenza delle chiamate di funzione multi-strumento. Se il dispositivo in questione è un telefono o un laptop piuttosto che un box GPU, il percorso 2.6B è dove risiede la storia della velocità.

Allora quale scarichi?

Non devi mai scegliere direttamente tra questi due, perché non sono alternative — ma devi sapere in quale lavoro ti trovi:

Se servi LFM2.5-8B-A1B su GPU di tua proprietà e vuoi più token al secondo dallo stesso silicio, LFM2.5-8B-A1B-DSpark è un add-on reversibile: compila SGLang o llama.cpp con le integrazioni DSpark del 20 agosto, indica il draft nel comando di lancio, mantieni il greedy decoding, e la dimensione del blocco viene letta automaticamente dalla configurazione del draft. Il vantaggio è un throughput circa 2.5× superiore senza alcuna modifica agli output; lo svantaggio è 0,3 GB di pesi aggiuntivi e una build abbastanza recente da contenere le PR. Rimuovi i due flag speculativi e torni al target normale.

Se vuoi costruire il tuo specialista — un modello di dominio, un assistente in lingua personalizzata, un fine-tuning su dati proprietari — LFM2.5-2.6B-Base è uno dei punti di partenza seri più economici nell'ecosistema open-weights: 2.6B, sotto i 2.5GB, contesto di 128K, tokenizer multilingue. Il checkpoint DSpark non può aiutarti affatto in questo, perché non è una base.

Se vuoi davvero l'agente on-device di Liquid — tool calling, attività multi-step — non vuoi nessuno di questi due. Vuoi il LFM2.5-2.6B post-addestrato, e puoi decidere in seguito se aggiungerci la sua bozza. La Base è materia prima per chi vuole addestrare; la bozza 8B-A1B è un componente di velocità per chi ha già in produzione il MoE. La mossa sbagliata è scaricare la Base perché cercavi un agente più veloce, o la bozza perché cercavi una base su cui addestrare.

Dove i due si collegano — e dove entra in gioco un router

Entrambi i checkpoint sono casi di self-host. Il draft è un accessorio del livello di serving che esiste solo all'interno del tuo stack SGLang o llama.cpp; la Base è un artefatto di training. Nessuno dei due appare in alcun catalogo ospitato, e nessuno dei due ha un prezzo di listino per token. In pratica, ciò significa che entrambi i percorsi finiscono per affiancarsi ai modelli ospitati che già chiami — e questa combinazione è esattamente l'infrastruttura che un livello di routing esiste per semplificare.

Dal lato del serving, l'economia della bozza è semplice e reale: 2,5× più token al secondo dalla stessa GPU significa 2,5× meno tempo e circa 2,5× meno GPU per lo stesso carico di lavoro, senza alcuna variazione di qualità. Ma questa leva esiste solo se possiedi l'inferenza. Nel momento in cui chiami l'8B-A1B tramite un'API, il fornitore trattiene l'aumento di velocità — ed è qui che il confronto lato API diventa quello che conta: quanto fa pagare il fornitore e se un taglio di prezzo ti raggiunge lo stesso giorno in cui viene annunciato. Questo è lo scopo di un router pass-through: un'unica API su oltre 200 modelli, prezzi di listino del fornitore trasmessi con margine 0%, così un ribasso del vendor è immediatamente attivo dalla tua parte, e failover automatico, così un picco di latenza di un singolo fornitore non diventa la tua latenza. Puoi anche mettere davanti il tuo stack LFM self-hosted attraverso lo stesso endpoint, ed è così che provi un modello bozza nuovissimo contro traffico reale senza scommettere su di esso un percorso di produzione.

LFM2.5-8B-A1B-DSpark e LFM2.5-2.6B-Base condividono un nome di famiglia e lavori opposti: uno è un componente di accelerazione agganciato al MoE edge, l'altro è il cervello non ottimizzato da cui nasce l'agente 2.6B. Nessuno dei due funziona da solo. Scegli il drafter per accelerare un MoE che già esegui su GPU, scegli la Base per affinare una base 2.6B e trasformarla in qualcosa di tuo, e lascia perdere entrambi se quello che volevi era un agente funzionante — perché l'unica cosa che entrambi i checkpoint hanno in comune è che nessuno dei due, da solo, fa nulla che tu possa usare.

Domande frequenti

Posso eseguire LFM2.5-8B-A1B-DSpark da solo?

No. È un modello draft senza output autonomo — propone token candidati che il target LFM2.5-8B-A1B poi verifica, quindi esiste solo all'interno di uno stack di serving a decodifica speculativa costruito sulle integrazioni SGLang o llama.cpp del 20 agosto. Scaricarlo da solo non ti dà nulla da interrogare.

LFM2.5-2.6B-Base è il checkpoint che viene eseguito sul dispositivo come agente?

Non così com'è. La Base è il fondamento pre-addestrato grezzo, senza tuning su istruzioni e senza template di chat. Il modello che funge da agente on-device di Liquid è il LFM2.5-2.6B post-addestrato, prodotto dalla Base tramite la pipeline di post-addestramento in quattro fasi — e, se lo si vuole più veloce, abbinato al draft LFM2.5-2.6B-DSpark.