LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark: stesso file da 328M, due scommesse molto diverse

Scaricando uno dei due file si ottengono 655.421.522 byte. LFM2.5-24B-A2B-DSpark e LFM2.5-8B-A1B-DSpark sono identici al byte, condividono una backbone a cinque strati, la stessa testa Markov rank-256, la stessa dimensione di blocco pari a 9 e lo stesso vocabolario da 128.000 token — e nessuno dei due può rispondere a un singolo prompt, perché entrambi sono drafter per decodifica speculativa che esistono solo per indovinare token per un modello target. Ciò che li distingue non è la loro specifica. È il modello target su cui sono stati addestrati e quanta evidenza esiste che il trucco funzioni su di esso. Uno ha pubblicato misurazioni su GPU e MacBook da un post di lancio; l'altro ha una tabella GPU e nessun annuncio. Scegliere tra i due non è quindi affatto un confronto tra modelli — è un confronto tra due scommesse, e solo una delle due è stata incassata. I fallimenti AI documentati e gli incidenti degli agenti dietro rilasci come questo sono raccolti in l'Archivio degli incidenti AI di OrcaRouter dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.

I file sono gemelli; i job no.

Leggi i due config.json file affiancati e quasi ogni campo coincide: dimensione nascosta 2.048, dimensione intermedia 6.144, attivazione SiLU, 32 teste di attenzione su 8 teste KV con dimensione della testa 64, cinque livelli di attenzione completa, dimensione del blocco 9, enable_confidence_head: true, una testa Markov vanilla di rango 256. Il conteggio dei parametri è identico, ed è per questo che i file safetensors coincidono byte per byte.

Tre campi differiscono, e ciascuno è portante.

• Tap sui layer target — il drafter 8B legge gli stati nascosti dai layer 2, 6, 10, 14 e 18 di un target a 24 layer; il drafter 24B legge i layer 2, 10, 18, 26 e 34 di un target a 40 layer. Questo è il campo che rende i file non intercambiabili.

• Posizioni massime — 128.000 per il drafter 8B contro 131.072 per il 24B, seguendo le finestre di contesto dei rispettivi target.

• RoPE theta — 5.000.000 contro 10.000.000, impostato dalla codifica posizionale del target anziché da qualsiasi aspetto del drafter.

Quell'ultima coppia è la prova più chiara che questi checkpoint sono stati addestrati per ciascun target anziché scalati da una base comune. Il drafter non ha un'identità indipendente: la sua distribuzione di input coincide con qualunque forma assumano gli stati nascosti del target, e questi cambiano quando cambiano l'architettura e l'addestramento del target. Punta il drafter da 8B sul modello da 24B e già i soli indici dei layer lo rendono privo di senso; anche se coincidessero, i logit che è stato addestrato a predire non coinciderebbero.

Che cosa sta effettivamente accelerando ciascuno

I target sono più diversi di quanto suggerisca la denominazione "8B versus 24B", e la differenza va nella direzione opposta per chiunque dia per scontato che il modello più grande sia il carico più pesante sul dispositivo.

• Parametri totali e attivi — LFM2.5-8B-A1B ha 8,3B totali con 1,5B attivi per token; LFM2.5-24B-A2B ha 24,0B totali con 2,45B attivi.

Profondità — 24 livelli (18 convoluzioni con gating più 6 GQA) contro 40 livelli (30 convoluzioni più 10 GQA).

• Contesto — 128.000 token rispetto a 131.072.

• Budget di addestramento — 38T token contro 36T, quindi il modello più piccolo non è stato addestrato in misura insufficiente rispetto a quello più grande.

• Instradamento — l'8B utilizza un MoE a 64 esperti con instradamento top-4, come il 24B, quindi entrambi pagano la penalità di attivazione degli esperti che compromette la verifica.

Entrambi sono modelli di ragionamento che pensano prima di rispondere, il che qui conta più del numero di parametri. Il punto debole più grande della decodifica speculativa è l'output lungo e non vincolato, e una catena di pensiero è esattamente questo. Le tabelle dei fornitori lo mostrano: le righe con il tasso di accettazione più alto in entrambe le versioni sono benchmark a risposta breve come MBPP e MT-Bench, mentre quelle più basse sono quelle in cui il modello deve inventare un lungo percorso di soluzione.

Il divario di prove è la vera differenza

Qui è dove le due release smettono di essere confrontabili. Il drafter 8B è stato rilasciato il 2026-08-20 nell'ambito dell'annuncio di un'intera famiglia, con misurazioni su due macchine molto diverse: una singola H100 da 80 GB in BF16 tramite SGLang, e un MacBook Pro M4 Max con pesi GGUF FP16 tramite llama.cpp con kernel Metal sperimentali. Ha fatto una media di 2,54× su H100 con un picco di 3,18× su MATH-500, e appena 1,18× sul MacBook — da 90 a 106 token al secondo, in media su cinque dataset.

Il drafter da 24B ha una sola riga hardware: un singolo NVIDIA B300 con target FP8, cache KV BF16, temperatura 0. Registra una media di 2,38× con concorrenza 1, 2,69× con concorrenza 32 e 1,71× con concorrenza 256 su otto dataset, con un picco di 3,28× su MBPP con concorrenza 32. Non c'è alcuna riga Mac, nessuna riga H100 e nessun post di annuncio che spieghi l'omissione.

Per il modello la cui intera proposta ruota attorno ad agenti on-device — il post di lancio di Liquid per il 24B apre con 184 token al secondo su un Apple M5 Max — il dato MacBook mancante è il vuoto più significativo del rilascio. Il risultato dell'8B spiega perché potrebbe essere piccolo: verificare un blocco di token attiva più esperti rispetto a decodificarne uno, quindi un target MoE sposta più peso per token accettato. E il tasso di accettazione da solo non è il fattore predittivo: il drafter 8B ha in realtà registrato in media più token accettati per passo rispetto a quanto riporta la scheda del 24B (6,95 su cinque dataset contro 5,16 su otto) e ha comunque fornito solo 1,18× su un MacBook. Questo è il punto da tenere a mente: sull'8B, una forte accettazione non ha salvato il throughput on-device. Presumere che il 24B si comporti diversamente è una scommessa senza un numero a supporto.

Confrontando le due tabelle tra loro

I rapporti di sintesi non sono confrontabili a parità di condizioni e non andrebbero sottratti l'uno dall'altro. GPU diverse, precisione target diversa, set di dati diversi, diverse variazioni di concorrenza. Ma due schemi resistono al disallineamento.

Innanzitutto, il tetto è simile. La migliore cella H100 dell'8B era 3,18× su MATH-500 con dimensione batch 1; la migliore cella B300 del 24B è 3,28× su MBPP con concorrenza 32. I drafter di questo design ricadono nella stessa fascia 1,5×–3,3× indipendentemente dal target che servono, che è quanto ci si aspetta quando l'architettura del drafter è mantenuta fissa e cambiano solo i pesi.

In secondo luogo, e in modo più utile, è il limite inferiore il punto in cui i target divergono. La cella H100 più debole dell'8B era GSM8K a 1,29×; la cella B300 più debole del 24B con concorrenza 256 era LiveCodeBench a 1,34× e AIME a 1,36×. Nessuna delle due release produce un caso in cui la speculazione sia gratuita, ed entrambe producono casi in cui vale a malapena la memoria.

C'è anche un cambiamento nella documentazione tra le due schede che è facile trascurare e che vale la pena segnalare. Il materiale di agosto diceva che l'output in decodifica greedy è identico al baseline "per costruzione"; la scheda dell'8B promette "esattamente gli stessi output". La scheda del 24B, invece, avverte che le differenze in virgola mobile tra verifica in batch e decodifica semplice possono produrre testo diverso, anche con campionamento greedy. La scheda successiva è quella più cauta e, se in CI esegui diff degli output a livello di byte, vale la pena considerare entrambe potenzialmente non identiche anziché fidarti della promessa più vecchia.

Quale sia rilevante per te lo decide il tuo obiettivo, non il tuo budget

Non esiste scenario in cui un team scelga uno dei due rispetto all'altro per merito. Esegui il 24B perché ti serve la capacità di un modello 24B su una macchina che lo possa contenere — 14,5 GB a Q4_K_M in GGUF, oppure una singola B300 per la configurazione di serving FP8. Esegui l'8B perché 8,3B parametri totali con 1,5B attivi è ciò che entra in un dispositivo edge o in un laptop, e il drafter recupera parte della velocità di decode a cui hai rinunciato passando a un modello piccolo. Il drafter è un accessorio rispetto a quella prima decisione, e la decisione si basa quasi sempre su memoria e qualità molto prima che la speculazione entri nella conversazione.

L'unico caso in cui la scelta è ancora aperta è la valutazione. Se stai verificando se DSpark valga la pena di essere adottato nel tuo stack, l'abbinamento 8B è l'esperimento più economico: entra su una singola H100, ha numeri Mac che puoi confrontare con il tuo laptop e la modalità di fallimento on-device è già stata documentata dal fornitore. L'abbinamento 24B è l'esperimento di produzione più interessante e quello meno documentato.

Per entrambi, il numero che decide l'esito è il contatore di accettazione, non la tabella del fornitore. SGLang espone l'accettazione dello speculative decoding per singola richiesta; llama.cpp riporta draft_n e draft_n_accepted nei tempi per risposta. Esegui i tuoi prompt per dieci minuti e dividi. Se l'accettazione si avvicina alla media della scheda, il drafter conviene; se si colloca all'estremo inferiore, stai pagando passaggi di verifica e dovresti scollegarlo — e questa conclusione varrà per entrambi i checkpoint, perché il meccanismo è lo stesso.

Nessuno dei due checkpoint è un modello che puoi chiamare

Questa è la parte che trae in inganno chi incontra questi nomi in un catalogo di modelli e presume che siano opzioni su un menu. Non sono endpoint. Nessuno dei due drafter ha un prezzo per milione di token, nessuno dei due compare in un elenco API e nessuno dei due sarà mai destinatario del routing di una piattaforma che serve modelli — perché l'abbinamento corretto è una configurazione lato server, non un parametro della richiesta.

Liquid AI vende il target da 24B stesso a 0,10 $ per milione di token di input, 0,05 $ in cache e 1,00 $ per milione di output, e qualsiasi speculazione ci sia dietro quel prezzo è invisibile a chi effettua la chiamata. Questa è ormai la forma ordinaria del mercato: l'ingegneria interessante avviene dentro lo stack di serving, e ciò che arriva a uno sviluppatore è una tariffa e un valore di token al secondo. È nella comparazione sopra questo livello che le piattaforme di routing si guadagnano il loro posto — mettere un candidato accanto ai modelli che deve battere. OrcaRouter gestisce un unico endpoint su oltre 200 modelli con markup dello 0% sul prezzo di listino del provider, così quando la tariffa di un fornitore cambia, la tariffa che vedi si aggiorna lo stesso giorno, e il failover impedisce che un modello candidato diventi un singolo punto di errore mentre lo valuti. La famiglia LFM2.5 oggi non è tra questi, quindi un 8B o 24B self-hosted con il suo drafter allegato resta un deployment locale; i modelli su cui vale la pena testarlo — Qwen3.6-35B-A3B sul fronte agentico, Gemma 4 26B-A4B sul fronte dell'efficienza — sono quelli che instradiamo.

Cosa ha stabilito un anno di rilasci di DSpark

La famiglia ora copre quattro target testuali e un target vision, da 1,2B a 24B, tutti accomunati da un'unica ricetta per il drafter: circa 300M parametri, cinque layer di attenzione, blocco 9, addestrato sugli stati nascosti del target stesso. È proprio questa coerenza il vero risultato. Liquid ha trasformato la decodifica speculativa da progetto di ricerca specifico per singolo modello a passaggio di produzione: lo stesso drafter, riadattato al nuovo target, rilasciato entro pochi giorni da ogni nuovo modello. Se valga la pena intraprendere questo passaggio sul vostro hardware è una domanda che riguarda il vostro traffico, e la risposta varia in base al carico di lavoro molto più di quanto vari in base a quale di questi due file scaricate.

Quello che il rilascio 24B aggiunge a questo quadro non è un rapporto migliore. È la prima volta che un drafter viene distribuito senza la documentazione di accompagnamento — e la prima volta che la scheda del fornitore stesso ti dice, in linguaggio chiaro, che gli output potrebbero dopotutto non essere identici bit per bit.