LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: Dovresti davvero agganciare il drafter?

Ecco la decisione in una riga: LFM2.5-24B-A2B-DSpark è un file da 327,7 milioni di parametri che metti accanto a LFM2.5-24B-A2B in modo che il modello 24B produca lo stesso tipo di output più rapidamente. Non è un'alternativa al modello e non è qualcosa che scegli al posto suo. L'unica vera domanda che i due nomi sollevano è di ingegneria — colleghi il drafter al tuo deployment o lo lasci fuori — e la risposta dipende meno dall'accelerazione da copertina di Liquid AI che da due numeri che nessuno pubblicizza: quanti token del draft vengono accettati sul tuo traffico, e quanta concorrenza stai già gestendo. I fallimenti AI documentati e gli incidenti degli agenti dietro a rilasci come questo sono raccolti nell'OrcaRouter AI Incident Archive dove ogni voce riporta le proprie fonti, la severità, il grado di confidenza e il flag di contestazione.

Liquid AI non ha pubblicato un post di lancio per il drafter. Il repository è diventato pubblico il 2026-10-19 con pesi, un CSV di benchmark e flag di lancio SGLang, mentre la model card del target stesso etichetta ancora il drafter come "coming soon" e la pagina della documentazione sul speculative decoding di Liquid elenca solo i target 1.2B, 2.6B, 8B e VL-3B. Quindi si tratta di un confronto tra un artefatto rilasciato e un modello rilasciato, scritto a partire dal repository anziché da un comunicato stampa — il che significa che ogni numero di prestazioni riportato di seguito è dichiarato dal fornitore e nessuno di essi è stato riprodotto in modo indipendente.

Che cosa modifica effettivamente il drafter e che cosa no

Il meccanismo merita trenta secondi perché determina tutto il resto. La decodifica di un token è limitata dalla memoria: la GPU passa la maggior parte del tempo a trasferire in streaming i pesi nella SRAM, non a fare aritmetica. La decodifica speculativa sfrutta questo facendo ipotizzare a un modello piccolo i successivi diversi token in una volta, per poi far verificare al modello reale l'intera ipotesi in un'unica passata in avanti. Se l'ipotesi era buona, hai prodotto nove token all'incirca al costo di uno. Se era cattiva, il target mantiene il proprio token e hai pagato un po' di più.

Cosa cambia: i token al secondo e la forma dell'utilizzo della GPU. Cosa non cambia: i pesi del modello, la sua finestra di contesto, il suo comportamento di chiamata degli strumenti o i suoi prezzi dove viene venduto. LFM2.5-24B-A2B mantiene 24,0B parametri totali con 2,45B attivi per token, 40 livelli suddivisi tra convoluzioni brevi con gating e attenzione con query raggruppate, 64 esperti per blocco con routing top-4, un contesto di 131.072 token e un vocabolario di 128.000 token. Il drafter aggiunge cinque livelli di attenzione, una testa Markov di rango 256 e una testa di confidenza, e riutilizza gli embedding e la LM head del modello target invece di portarne di propri.

Una precisazione è cambiata tra le due release e merita una riga. Ad agosto, il documento di DSpark di Liquid affermava che la sequenza emessa è «identica al greedy di base per costruzione». La scheda del drafter 24B dice invece che le differenze in virgola mobile tra verifica in batch e decodifica semplice «possono produrre testo diverso, anche con campionamento greedy». Entrambe le affermazioni sono difendibili — la prima è vera in aritmetica esatta — ma se il vostro harness di valutazione confronta gli output byte per byte, aspettatevi che se ne accorga.

Il lato dei costi del libro contabile

Il drafter non è gratuito. Occupa 655 MB in BF16 sulla GPU (o un GGUF F16 da 664 MB sulla CPU), risiede nello stesso pool di memoria del target e ogni passo che propone costa un forward pass di verifica su un blocco di token anziché su un singolo token. Su un target MoE quest'ultima parte è più costosa di quanto sembri: verificare nove token attiva più esperti rispetto a decodificarne uno, quindi i byte spostati per token verificato aumentano, non diminuiscono. Liquid ha indicato esattamente questo come il motivo per cui il suo drafter da 8B ha fornito solo 1,18× su un M4 Max nonostante un forte tasso di accettazione.

Di contro, i risparmi sono abbastanza grandi da poter essere misurati in ore GPU. Usando i numeri B300 del fornitore stesso da benchmarks/b300-fp8.csv, e non facendo altro che dividere un miliardo di token di output per il throughput osservato:

• MATH-500, concorrenza 1 — 324 tok/s da solo (857 GPU-ore per miliardo di token) rispetto a 853 tok/s con il drafter (326 GPU-ore). Una riduzione di 2,63× del tempo di calcolo.

• MATH-500, concorrenza 256 — 15.423 tok/s da solo (18,0 ore GPU) rispetto a 27.579 tok/s con il drafter (10,1 ore GPU). Una riduzione di 1,79×.

• GSM8K, concorrenza 256 — 4.491 tok/s da solo (61,9 ore GPU) contro 9.660 tok/s con il drafter (28,8 ore GPU). Una riduzione di 2,15×.

• LiveCodeBench, concorrenza 256 — 18.812 tok/s da solo (14,8 ore GPU) contro 25.231 tok/s con il drafter (11,0 ore GPU). Solo una riduzione di 1,34×, la cella più debole della tabella.

Quelli sono rapporti di throughput convertiti in tempo, non in denaro, perché il denaro dipende da quanto paghi per GPU-ora e questo articolo non intende inventare una tariffa. Ma l'ordinamento vale a qualsiasi tariffa: collegare il drafter vale da due a tre ore ogni dieci per il traffico di ragionamento e generazione di codice a bassa concorrenza, e vale circa un terzo di questo ad alta concorrenza. Se la tua distribuzione 24B è un agente monoutente su una workstation, il caso è forte. Se è un endpoint batch saturo, il caso è reale ma molto più debole di quanto suggerisca il titolo 2.4×.

Dove il drafter si guadagna il pane, in termini di carico di lavoro

La dispersione sugli otto dataset nella tabella del fornitore non è rumore; corrisponde ai tipi di prompt, e questa corrispondenza è la cosa più utile del rilascio. L'accettazione variava da 6,70 token per passo su MBPP fino a 4,02 su LiveCodeBench. I dataset che hanno ottenuto punteggi alti sono quelli in cui l'output del modello è vincolato dal prompt — funzioni brevi in stile unit test, aritmetica con un percorso verificabile, risposte a scelta multipla. Quelli che hanno ottenuto punteggi bassi sono quelli in cui il modello deve inventare una soluzione lunga e non vincolata: problemi di programmazione competitiva e matematica in stile AIME.

Quella è l'intuizione da portare nella tua valutazione. Un modello di ragionamento da 24B venduto per il lavoro agentico spende la maggior parte dei suoi token di output all'interno di una catena di pensiero, che assomiglia più a LiveCodeBench che a MBPP. Un modello usato per estrazione strutturata, classificazione con uno schema o un formato fisso di chiamata agli strumenti assomiglia molto di più alle righe ad alta accettazione. Se il tuo carico di lavoro è il primo, aspettati di collocarti più vicino al fondo del 1.34× dell'intervallo che alla cima del 3.28×. Nessuno ha pubblicato l'accettazione per singolo carico di lavoro per questo drafter, e gli otto dataset della scheda sono la cosa più vicina a una guida.

Di contro: il 24B è un modello esclusivamente di ragionamento. Liquid afferma che pensa sempre prima di rispondere — il template della chat inserisce automaticamente un <think> tag. Questa è la forma peggiore possibile per la speculazione, perché l'intervallo di ragionamento è esattamente il tratto lungo e a bassa accettazione. Il drafter aiuterà comunque; aiuterà di più sulla risposta finale e di meno sulla parte che richiede più tempo.

Come scoprirlo, sul proprio hardware, in un pomeriggio

Non devi fidarti di nessuna delle affermazioni precedenti. Entrambi i percorsi di inferenza espongono il contatore delle accettazioni, che è l'unico numero che decide se il drafter si sta ripagando sul tuo traffico.

Su SGLang, avvia il target con il drafter collegato, block size 9 e dieci token di draft, poi leggi le metriche di decodifica speculativa che il server riporta per richiesta. Il tasso di accettazione nella tabella del fornitore è compreso tra 0,33 e 0,65 a seconda del dataset; un'esecuzione che si colloca ben al di sotto della riga pertinente significa che il drafter sta indovinando male e stai pagando la verifica senza ottenere l'accelerazione. Su llama.cpp con il sidecar GGUF F16, i tempi per risposta riportano draft_n e draft_n_accepted direttamente. Dividi uno per l'altro.

Due dettagli operativi ti costeranno un'ora se li trascuri. Il server SGLang richiede una build che includa il percorso DSpark di LFM2-MoE integrato il 2026-08-31 — su qualsiasi versione più vecchia l'architettura del drafter è semplicemente sconosciuta. E la dimensione del blocco è una proprietà del checkpoint, non un parametro libero: llama.cpp limita --spec-draft-n-max al valore di 9 nei metadati del sidecar, quindi chiedere 12 non serve a nulla.

La domanda a cui questo confronto non può rispondere

Esiste una versione di "devo collegare il drafter" che non ha nulla a che fare con le GPU, ed è quella che la maggior parte dei team deve effettivamente affrontare. Se chiami LFM2.5-24B-A2B tramite un'API ospitata, la decisione sul drafter non spetta a te. Lo stack di serving collega o non collega un decoder speculativo; tu vedi un valore di token al secondo e un prezzo, ed entrambi sono stati decisi a monte. La Console di Liquid stessa elenca il 24B a $0,10 per milione di token in input, $0,05 per input in cache e $1,00 per milione in output — una tariffa pubblicata che riflette già qualunque percorso di decodifica venga eseguito, e che può cambiare senza preavviso.

È quello il punto di giunzione in cui il routing aiuta invece di complicare. Una chiamata hosted e un deployment self-hosted non sono tanto piani concorrenti quanto due impostazioni dello stesso parametro di costo: il self-hosting più il drafter riduce al minimo il costo per token se il volume tiene occupata la GPU, e un endpoint hosted riduce al minimo il lavoro necessario per ottenere una risposta. OrcaRouter è pensato per la seconda — una sola chiave per oltre 200 modelli a 0% di ricarico sul prezzo di listino del provider, così una variazione di prezzo del fornitore si riflette dalla nostra parte lo stesso giorno, con failover automatico se un provider si degrada e un DSL di routing per suddividere il traffico invece di vincolare a un unico backend. Al momento non serviamo la famiglia LFM2.5, quindi per questo modello specifico il lato hosted significa l'API di Liquid stessa o le tue GPU; il confronto che vale la pena fare è con i modelli che offriamo, come Qwen3.6-35B-A3B — il modello rispetto al quale Liquid esegue benchmark su attività agentiche — oppure Gemma 4 26B-A4B.

Quindi: allegarlo o no

Allegalo se stai servendo LFM2.5-24B-A2B autonomamente con concorrenza modesta, soprattutto per output strutturati o a forma di estrazione, e se hai 655 MB di margine accanto al target. I numeri del fornitore dicono che lì ridurrai all'incirca della metà o a un terzo il tempo di decodifica, e il rovescio della medaglia è limitato: un drafter scadente costa una passata di verifica, non una risposta sbagliata.

Lascialo disattivato se il tuo endpoint è già saturo nell'ordine delle centinaia, se il tuo output è un lungo ragionamento in forma libera, o se hai bisogno di numeri su Apple-silicon prima di impegnarti — la scheda non ne riporta nessuno, e l'analogo più vicino della stessa famiglia è stato rilasciato a 1,18× su un MacBook. E lascialo disattivato, ovviamente, se non stai affatto eseguendo il modello: un drafter è un'ottimizzazione per un deployment, e non c'è nulla da ottimizzare finché il deployment non esiste.

Ciò che risolverebbe il resto è un post del fornitore e una misurazione su Mac. Nessuno dei due esiste al 2026-10-21, uno stato strano per un rilascio i cui pesi sono già scaricabili — e, per chiunque sia disposto a eseguire personalmente il contatore di accettazione, un’occasione insolitamente economica per essere il primo numero indipendente sul tabellone.