LFM2.5-24B-A2B-DSpark è disponibile su Hugging Face — Liquid AI non l'ha ancora annunciato

La model card del modello più grande di Liquid AI indica ancora che il suo drafter per il decoding speculativo è in arrivo. Il drafter non arriverà. LFM2.5-24B-A2B-DSpark ha un repository pubblico dal 2026-10-19, un checkpoint BF16 da 655 MB, una tabella di benchmark completa, un sidecar GGUF pubblicato la sera successiva e flag di lancio per SGLang scritti nella sua scheda. Quello che non ha è un annuncio. LFM2.5-24B-A2B, il modello mixture-of-experts da 24B che serve ad accelerare, ha ricevuto un post sul blog, una data di lancio, un listino prezzi e un link al playground il 2026-10-13. Il suo drafter ha ricevuto un repo e una model card, e la pagina di documentazione di Liquid AI stessa per il decoding speculativo elenca ancora come supportati solo i target 1.2B, 2.6B, 8B e VL-3B. I fallimenti documentati dell'IA e gli incidenti degli agenti dietro rilasci come questo sono raccolti in l'OrcaRouter AI Incident Archive dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.

Quel divario è il punto centrale qui, e vale la pena essere precisi su cosa significhi e cosa non significhi. Un repository i cui pesi sono aperti, i cui benchmark sono riproducibili da un CSV che si trova accanto al modello e il cui percorso di inferenza è già stato integrato upstream è un vero rilascio, non una fuga di notizie. Ma nulla al riguardo è stato confermato dal fornitore in prosa, nessuna terza parte lo ha misurato, e i numeri nella scheda sono quelli dello stesso team, misurati sullo stesso hardware che hanno scelto. Questo articolo separa le due cose: ciò che il repository stabilisce e ciò che rimane un'affermazione.

Cosa c'è effettivamente nel repository

Il checkpoint è abbastanza piccolo che l'elenco dei file stesso è informativo. Il tutto è un unico model.safetensors da 655.421.522 byte — 327,7M parametri in BF16 — più una configurazione, una licenza e una directory di benchmark. Nient'altro. Non ci sono tokenizer, né matrice di embedding, né LM head, perché l'architettura li riutilizza tutti e tre dal target al momento del caricamento. Questo è il design: il drafter deve solo sapere come indovinare il prossimo blocco di token nel vocabolario del target, non come rappresentare il mondo.

La configurazione conferma la struttura descritta nel resoconto DSpark di agosto. Cinque layer di attenzione completa con dimensione nascosta 2.048 e dimensione intermedia 6.144 con SiLU/SwiGLU; attenzione grouped-query con 32 teste e 8 teste KV a dimensione di testa 64; una testa Markov di rango 256 e una testa di confidenza separata; dimensione del blocco 9; vocabolario 128.000; e un embedding di posizione massimo di 131.072, che corrisponde esattamente alla finestra di contesto del target. L'unico campo specifico di questo drafter è target_layer_ids: [2, 10, 18, 26, 34] rispetto a num_target_layers: 40 — i cinque layer del modello 24B i cui stati nascosti il drafter legge come contesto. Quegli indici sono il motivo per cui un drafter addestrato per un modello LFM2.5 non può semplicemente essere applicato a un altro.

La licenza è lfm1.0, la stessa licenza personalizzata del resto della famiglia, cosa che vale la pena notare per chiunque pianifichi di ridistribuire un artefatto pacchettizzato target-plus-drafter anziché usarlo internamente.

La tabella di benchmark, letta come tabella di fornitore

La scheda pubblica il throughput per otto dataset con concorrenza 1, 32 e 256, su una singola NVIDIA B300 con target FP8, cache KV BF16 e temperatura 0. Ogni cifra riportata di seguito è di Liquid AI stessa e non è stata riprodotta al di fuori dell'azienda; le righe grezze sono nel benchmarks/b300-fp8.csv del repository se vuoi verificare tu stesso l'aritmetica.

Media aritmetica sugli otto dataset — 2,38× con concorrenza 1, 2,69× con concorrenza 32, 1,71× con concorrenza 256.

• Migliore cella singola — MBPP con concorrenza 32, 3,28×, con MATH-500 subito dietro a 3,04×.

• Peggior singola cella — LiveCodeBench con concorrenza 256, 1,34×, e AIME a 256, 1,36×.

• Token accettati per passo — 5,16 in media, rispetto a un tetto di 10 fissato dalla dimensione del blocco più il token bonus del target.

• Accettazione più alta — MBPP a 6,70 token per passo; più bassa — LiveCodeBench a 4,02.

Due cose relative a quella tabella sono più interessanti del titolo. La prima è che l'aumento medio di velocità è superiore con concorrenza 32 rispetto a concorrenza 1 — 2,69× contro 2,38× — il che è l'opposto della consueta storia del speculative decoding, in cui il batching si mangia il beneficio. La seconda è che crolla a 256. A 256 richieste concorrenti il target da solo sta già generando circa 15.000 token al secondo su quella GPU per MATH-500, e il contributo del drafter scende a 1,79×. Un team di serving che legge solo "2,4×" dimensionerebbe male un cluster; il numero che conta per un endpoint in batch è 1,71×, e anche quello è un numero B300 con un profilo di concorrenza che la maggior parte dei deployment non avrà.

La frase che è cambiata da agosto

Quando Liquid AI ha rilasciato i drafter DSpark per i target 1.2B, 2.6B e 8B-A1B il 2026-08-20, il suo post sul blog ha avanzato un'affermazione forte: poiché il target verifica ogni token proposto e sostituisce le proposte rifiutate con la propria scelta, "la sequenza emessa è quindi identica al greedy baseline per costruzione". La model card del drafter 8B ne ripete lo spirito, promettendo "esattamente gli stessi output".

La scheda del drafter 24B non dice questo. Dice che il target verifica ogni token proposto, e poi: "Le differenze in virgola mobile tra verifica in batch e decodifica semplice possono produrre testi diversi, anche con campionamento greedy." Aggiunge che le misurazioni valutano le prestazioni, non l'accuratezza sul task.

Questa è una frase più prudente, ed è quella giusta. La verifica in batch non esegue le stesse operazioni in virgola mobile nello stesso ordine della decodifica sequenziale, quindi l'identità bit per bit è un'assunzione che vale nell'aritmetica esatta e non sempre su hardware reale. Il fatto che la scheda più recente lo dica mentre quella più vecchia non lo faceva è o una correzione della documentazione o una scoperta avvenuta durante l'addestramento di questo drafter — il repository non ti dice quale delle due, e Liquid non ha pubblicato una spiegazione. In pratica il significato è limitato ma reale: se la tua suite di regressione confronta l'output del modello byte per byte, aggiungere questo drafter può farla fallire, e questa è una proprietà dell'aritmetica più che un bug nel draft.

Perché il redattore è arrivato sei giorni dopo il proprio modello

La cronologia merita di essere esposta, perché spiega il silenzio meglio di qualsiasi speculazione sulla strategia.

• 2026-08-20 — Liquid pubblica la famiglia DSpark: drafter per LFM2.5-1.2B-Instruct, LFM2.5-2.6B e LFM2.5-8B-A1B. Non esiste ancora un target da 24B.

2026-08-31 — SGLang integra la PR #31041, aggiungendo il supporto al decoding speculativo DSpark per LFM2 e LFM2-MoE. Il percorso MoE necessario al 24B arriva qui, un mese e mezzo prima del modello che servirà.

• 2026-10-13 — LFM2.5-24B-A2B viene rilasciato con un post sul blog e un prezzo. Lo stesso giorno, SGLang integra la PR #43939, che consente al server di riutilizzare direttamente la configurazione LFM2-MoE di Hugging Face.

• 2026-10-19 — compare il repository LFM2.5-24B-A2B-DSpark, con pesi e benchmark.

• 2026-10-20 — arriva il sidecar GGUF: un singolo file F16 da 664 MB per llama.cpp.

• 2026-10-21 — la scheda del modello target acquisisce una riga del drafter. Riporta ancora Prossimamente.

Leggi quella sequenza e la spiegazione più probabile è quella banale. L'infrastruttura è stata rilasciata prima dell'artefatto; l'artefatto è stato rilasciato quando l'addestramento è terminato; l'annuncio è un'attività di marketing che non è ancora avvenuta. Niente nel repository suggerisce un lancio deliberatamente silenzioso — la card è completa, i benchmark sono documentati fin nel dettaglio del protocollo, e le invocazioni di SGLang e llama.cpp sono scritte per esteso. Qui silenzioso significa non annunciato, non nascosto.

Ciò che non è ancora conoscibile

Il confine onesto di questo testo è un breve elenco, e ogni voce è una lacuna reale anziché una formalità.

Nessuna misurazione indipendente. Non esiste alcuna voce in Artificial Analysis, nessuna esecuzione di accettazione da parte di terzi, nessuna riproduzione della tabella di throughput. Al 2026-10-21 il repository mostrava sette download e un like. Ogni accelerazione in questo articolo è quella del fornitore, sulla GPU scelta dal fornitore, con la precisione target scelta dal fornitore.

Nessun annuncio, quindi nessuna impostazione. Non sappiamo se Liquid intenda questo come una raccomandazione di produzione per il 24B o come un artefatto di ricerca. Il tono della scheda — flag di lancio completi, una tabella della famiglia, un link di contatto — suggerisce la prima ipotesi, ma si tratta di un'inferenza.

Nessun prezzo, perché non può essercene uno. Un drafter non è un modello servito. Non ha una tariffa per milione di token e non comparirà mai in un catalogo di modelli come endpoint richiamabile. Il suo costo è rappresentato dai 655 MB di VRAM o di memoria unificata che occupa accanto al target, più il calcolo aggiuntivo necessario a verificare un blocco anziché un token.

Nessun dato per Apple silicon. Questa è la lacuna più grande, e la sezione successiva spiega perché conta più delle altre.

L'omissione interessante è il numero Mac mancante

Il modello 24B viene venduto come modello on-device. Il post di lancio di Liquid apre con 184 token al secondo su un Apple M5 Max e lo definisce pensato per agenti veloci e privati sul dispositivo. La scheda del drafter, al contrario, riporta solo i numeri del B300. Per il drafter 8B di agosto, Liquid ha pubblicato sia i risultati su H100 sia quelli su M4 Max ed è stata schietta sul divario tra i due: un'accelerazione media di 2,54× su una H100 diventava 1,18× su un MacBook. La ragione dichiarata era meccanica: verificare k token attiva più esperti rispetto a un singolo passo di decodifica, quindi un target MoE paga più traffico di pesi per token verificato, e il backend Metal di llama.cpp peggiorava la situazione.

LFM2.5-24B-A2B è anche una miscela di esperti: 64 esperti per blocco con routing top-4. Si applica lo stesso meccanismo, e il 24B è un modello più grande con un insieme di esperti più ampio da paginare. Ciò non dimostra che l'accelerazione sul dispositivo sia modesta — il drafter è stato addestrato specificamente per questo target, e l'accettazione è molto migliore di quanto fosse inizialmente quella dell'8B — ma significa che l'unico numero di cui un utente di laptop ha bisogno è proprio quello che la scheda non contiene. Considera non verificata qualsiasi ipotesi che il rapporto del B300 si trasferisca a un Mac.

Eseguirlo, e l’unico flag che ti si ritorcerà contro

Su GPU, la ricetta pubblicata è SGLang con il target FP8 e il drafter collegato, dimensione del blocco 9 e dieci token di draft. La versione installata di SGLang deve essere sufficientemente recente da includere il percorso LFM2-MoE DSpark della PR #31041 e il riutilizzo della configurazione della PR #43939; su una build precedente il server non riconoscerà affatto l'architettura del drafter. Si noti che i numeri del benchmark presuppongono il target FP8 — il target BF16 si comporterà diversamente, e non necessariamente meglio, perché il drafter è stato addestrato su una distribuzione specifica di logit del target.

Su CPU e Apple silicon il percorso è llama.cpp con il sidecar GGUF F16. Il sidecar legge la dimensione del blocco dai propri metadati e limita --spec-draft-n-max a esso, quindi impostare la lunghezza della bozza a 12 non ti dà 12. Le tempistiche per risposta espongono draft_n e draft_n_accepted, che è il campo da monitorare sul tuo carico di lavoro: se l'accettazione sul tuo traffico è molto al di sotto della media di 5.16 della scheda, il drafter ti costa un forward pass e rende poco, e la mossa onesta è scollegarlo.

Che cosa significa se stai scegliendo un modello questa settimana

Per la maggior parte dei team la conseguenza pratica è minima, perché il drafter cambia la velocità e non le capacità. LFM2.5-24B-A2B è ciò che risponde ai prompt; il drafter cambia solo quante di quelle risposte ottieni al secondo. Se il 24B non era nella tua shortlist la scorsa settimana, una sua versione più veloce non ce lo farà entrare.

Se era nella tua shortlist, il drafter migliora il caso a favore del self-hosting e non cambia nulla per il caso API. Vale la pena affermare chiaramente questa distinzione: un checkpoint di decodifica speculativa è invisibile a chiunque chiami un endpoint ospitato, perché è lo stack di serving a decidere se allegarlo. Ciò che puoi confrontare a parità di condizioni è il modello stesso rispetto alle alternative verso cui altrimenti indirizzeresti le richieste — e se lo stai valutando rispetto a qualcosa come Qwen3.6-35B-A3B, il modello rispetto al quale Liquid esegue i benchmark su cinque degli otto task agentici, OrcaRouter mette quel termine di confronto dietro un'unica chiave a 0% di markup sul prezzo di listino del provider, con failover automatico tra provider. Oggi non serviamo la famiglia LFM2.5, quindi il 24B stesso deve arrivare dall'API del fornitore o dalle tue GPU; ciò che offriamo è l'altro lato del confronto senza un secondo contratto.

Cosa cambierebbe questo quadro?

Tre cose, in ordine di quanto sposterebbero la storia. Un post sul blog di Liquid chiarirebbe l'impostazione — se si tratta di un abbinamento consigliato per la produzione o di un rilascio di ricerca. Una misurazione Mac pubblicata chiarirebbe l'affermazione che conta per il pubblico a cui era destinato il 24B. E un test di accettazione indipendente su traffico reale, anziché otto dataset di benchmark a temperatura 0, ti direbbe se 5,16 token per passo sopravvive al contatto con i prompt disordinati, lunghi e con chiamata agli strumenti per cui questo modello viene effettivamente venduto.

Fino a quel momento il repository è pubblico, i pesi sono scaricabili, il CSV è lì a portata di mano, e la model card del fornitore stesso è l'ultimo posto in cui dovreste cercare notizie al riguardo. È uno stato inusuale per un rilascio — ma è reale, e l'artefatto non diventa meno reale solo perché nessuno ha scritto il post sul blog.