LFM2.5-24B-A2B-DSpark is live op Hugging Face — Liquid AI heeft het gewoon nog niet aangekondigd

De modelkaart voor het grootste model van Liquid AI zegt nog steeds dat de speculative-decoding-drafter binnenkort beschikbaar is. Die drafter komt er niet. LFM2.5-24B-A2B-DSpark heeft sinds 2026-10-19 een openbare repository, een BF16-checkpoint van 655 MB, een volledige benchmarktabel, een de volgende avond gepubliceerde GGUF-sidecar en launch flags voor SGLang die in de kaart zijn opgenomen. Wat het niet heeft, is een aankondiging. LFM2.5-24B-A2B, het 24B mixture-of-expertsmodel dat het moet versnellen, kreeg op 2026-10-13 een blogpost, een gedateerde lancering, een prijslijst en een playground-link. Zijn drafter kreeg een repo en een modelkaart, en de eigen documentatiepagina van Liquid AI voor speculative decoding vermeldt nog steeds alleen de doelen 1.2B, 2.6B, 8B en VL-3B als ondersteund. De gedocumenteerde AI-fouten en agentincidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waarbij elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en betwist-vlag bevat.

Die kloof is hier het verhaal, en het loont om precies te zijn over wat die wel en niet betekent. Een repository waarvan de gewichten open zijn, waarvan de benchmarks reproduceerbaar zijn vanuit een CSV die naast het model staat, en waarvan het inferentiepad al upstream is samengevoegd, is een echte release, geen lek. Maar niets ervan is door de leverancier in tekstvorm bevestigd, geen enkele derde partij heeft het gemeten, en de cijfers op de modelkaart zijn de cijfers van hetzelfde team, gemeten op dezelfde hardware die zij zelf hebben gekozen. Dit artikel scheidt de twee: wat de repository vaststelt, en wat een bewering blijft.

Wat zit er eigenlijk in de repository?

De checkpoint is zo klein dat de bestandslijst zelf al informatief is. Het geheel is één model.safetensors van 655.421.522 bytes — 327,7 miljoen parameters in BF16 — plus een configuratie, een licentie en een benchmarksmap. Niets anders. Er is geen tokenizer, geen embeddingmatrix en geen LM-head, omdat de architectuur ze alle drie hergebruikt van het doelmodel bij het laden. Dat is het ontwerp: de drafter hoeft alleen maar te weten hoe hij het volgende blok tokens in de vocabulaire van het doelmodel moet raden, niet hoe hij de wereld moet representeren.

De configuratie bevestigt de opzet die het DSpark-verslag van augustus beschreef. Vijf volledige-aandachtslagen met verborgen grootte 2.048 en tussenliggende grootte 6.144 met SiLU/SwiGLU; gegroepeerde-query-aandacht met 32 koppen en 8 KV-koppen op kopdimensie 64; een Markov-kop met rang 256 en een afzonderlijke zekerheidskop; blokgrootte 9; vocabulaire 128.000; en een maximale positie-embedding van 131.072, wat exact overeenkomt met het contextvenster van het doelmodel. Het enige veld dat specifiek is voor deze drafter is target_layer_ids: [2, 10, 18, 26, 34] tegenover num_target_layers: 40 — de vijf lagen van het 24B-model waarvan de drafter de verborgen toestanden als context leest. Die indices zijn de reden dat een drafter die voor het ene LFM2.5-model is getraind niet simpelweg op een ander model kan worden gericht.

De licentie is lfm1.0, dezelfde aangepaste licentie als de rest van de familie, wat het vermelden waard is voor iedereen die van plan is een gebundeld target-plus-drafter-artefact te herverdelen in plaats van het intern te gebruiken.

De benchmarktabel, gelezen als een leverancierstabel

De kaart publiceert de doorvoer voor acht datasets bij een concurrency van 1, 32 en 256, op één enkele NVIDIA B300 met het FP8-target, een BF16-KV-cache en temperatuur 0. Elk cijfer hieronder is afkomstig van Liquid AI zelf en is niet buiten het bedrijf gereproduceerd; de ruwe rijen staan in de benchmarks/b300-fp8.csv van de repo als je de berekening zelf wilt controleren.

• Rekenkundig gemiddelde over de acht datasets — 2,38× bij gelijktijdigheid 1, 2,69× bij gelijktijdigheid 32, 1,71× bij gelijktijdigheid 256.

• Beste afzonderlijke cel — MBPP bij gelijktijdigheid 32, 3,28×, met MATH-500 op korte afstand op 3,04×.

• Slechtste afzonderlijke cel — LiveCodeBench bij concurrency 256, 1,34×, en AIME bij 256, 1,36×.

• Tokens geaccepteerd per stap — gemiddeld 5,16, tegen een maximum van 10 dat wordt bepaald door de blokgrootte plus het bonus-token van de target.

• Hoogste acceptatiegraad — MBPP met 6,70 tokens per stap; laagste — LiveCodeBench met 4,02.

Twee dingen aan die tabel zijn interessanter dan de kop. Het eerste is dat de gemiddelde versnelling hoger is bij concurrency 32 dan bij concurrency 1 — 2,69× tegenover 2,38× — wat het tegenovergestelde is van het gebruikelijke speculative-decodingverhaal, waarin batching het voordeel opeet. Het tweede is dat het instort bij 256. Bij 256 gelijktijdige verzoeken genereert alleen de target al ongeveer 15.000 tokens per seconde op die GPU voor MATH-500, en de bijdrage van de drafter zakt naar 1,79×. Een servingteam dat alleen "2,4×" leest, zou een cluster verkeerd dimensioneren; het getal dat ertoe doet voor een batched endpoint is de 1,71×, en zelfs dat is een B300-getal met een concurrencyprofiel dat de meeste deployments niet zullen halen.

De zin die sinds augustus is veranderd

Toen Liquid AI op 2026-08-20 de DSpark-drafters voor de targets van 1,2B, 2,6B en 8B-A1B uitbracht, deed zijn blogpost een sterke bewering: omdat het target elk voorgesteld token verifieert en afwijzingen vervangt door zijn eigen keuze, "is de geproduceerde sequentie daarom door constructie identiek aan baseline-greedy." De modelkaart van de 8B-drafter herhaalt de strekking daarvan en belooft "exact dezelfde outputs."

De kaart van de 24B-drafter zegt dat niet. Er staat dat het doelmodel elk voorgesteld token verifieert, en vervolgens: "Verschillen in drijvende komma tussen gebatchte verificatie en gewoon decoderen kunnen andere tekst opleveren, ook bij greedy sampling." Er wordt aan toegevoegd dat de metingen de prestaties beoordelen, niet de taaknauwkeurigheid.

Dit is een zorgvuldiger geformuleerde zin, en het is de juiste. Bij batched verification worden niet dezelfde floating-pointbewerkingen in dezelfde volgorde uitgevoerd als bij sequentiële decoding, dus bit-identiteit is een aanname die geldt in exacte rekenkunde en niet altijd op echte hardware. Dat de nieuwere kaart dit wel zegt en de oudere niet, is ofwel een documentatiecorrectie ofwel een ontdekking tijdens het trainen van deze drafter — de repository vertelt je niet welke van de twee, en Liquid heeft geen uitleg gepubliceerd. Praktisch betekent het iets smals maar reëels: als je regressiesuite de modeloutput byte voor byte vergelijkt, kan het toevoegen van deze drafter die laten afgaan, en dat is een eigenschap van de rekenkunde, geen bug in de draft.

Waarom de opsteller zes dagen na zijn eigen model aankwam

Het is de moeite waard de tijdlijn uiteen te zetten, omdat die de stilte beter verklaart dan elke speculatie over strategie.

• 2026-08-20 — Liquid publiceert de DSpark-familie: drafters voor LFM2.5-1.2B-Instruct, LFM2.5-2.6B en LFM2.5-8B-A1B. Er bestaat nog geen 24B-doelmodel.

• 2026-08-31 — SGLang voegt PR #31041 samen, waarmee ondersteuning voor LFM2- en LFM2-MoE DSpark-speculatieve decoding wordt toegevoegd. Het MoE-pad dat de 24B nodig heeft, landt hier: anderhalve maand voordat het model dat het zal dienen, arriveert.

• 2026-10-13 — LFM2.5-24B-A2B wordt geleverd met een blogpost en een prijs. Op dezelfde dag voegt SGLang PR #43939 samen, waardoor de server de Hugging Face LFM2-MoE-configuratie rechtstreeks kan hergebruiken.

• 2026-10-19 — de LFM2.5-24B-A2B-DSpark-repository verschijnt, met gewichten en benchmarks.

• 2026-10-20 — de GGUF-sidecar wordt uitgebracht: één enkel F16-bestand van 664 MB voor llama.cpp.

• 2026-10-21 — de doelmodelkaart krijgt een drafter-rij. Er staat nog steeds Binnenkort beschikbaar.

Lees die opeenvolging en de meest waarschijnlijke verklaring is de saaie. De infrastructuur was er al vóór het artefact; het artefact verscheen toen de training klaar was; de aankondiging is een marketingtaak die nog niet heeft plaatsgevonden. Niets in de repository wijst op een bewust stille lancering — de kaart is compleet, de benchmarks zijn tot op het protocol gedocumenteerd, en de SGLang- en llama.cpp-aanroepen zijn volledig uitgeschreven. Stil betekent hier niet aangekondigd, niet verborgen.

Wat nog niet kenbaar is

De eerlijke grens van dit stuk is een korte lijst, en elk item is een echte lacune in plaats van een formaliteit.

Geen onafhankelijke meting. Er is geen Artificial Analysis-vermelding, geen acceptatierun door derden, geen reproductie van de doorvoertabel. Op 2026-10-21 toonde de repository zeven downloads en één like. Elke versnelling in dit artikel is die van de leverancier, op de door de leverancier gekozen GPU, met de door de leverancier gekozen doelnauwkeurigheid.

Geen aankondiging, dus geen kader. We weten niet of Liquid dit bedoelt als een productieaanbeveling voor de 24B of als een onderzoeksartefact. De toon van de model card — volledige launch-flags, een familietabel, een contactlink — suggereert het eerste, maar dat is een gevolgtrekking.

Geen prijs, want die kan er niet zijn. Een drafter is geen geserveerd model. Het heeft geen tarief per miljoen tokens en zal nooit als aanroepbaar endpoint in een modelcatalogus verschijnen. De kosten zijn de 655 MB VRAM of unified memory die het naast het doelmodel inneemt, plus de extra rekenkracht om een blok in plaats van een token te verifiëren.

Geen cijfers voor Apple-silicon. Dit is het grootste hiaat, en de volgende sectie legt uit waarom dat meer uitmaakt dan de andere.

Het ontbrekende Mac-nummer is de interessante omissie.

Het 24B-model wordt verkocht als een on-device model. In Liquid's aankondigingspost staat bovenaan 184 tokens per seconde op een Apple M5 Max, en het wordt gepresenteerd als gebouwd voor snelle, private agents op het apparaat. De kaart van de drafter vermeldt daarentegen alleen B300-cijfers. Voor de 8B-drafter in augustus publiceerde Liquid zowel H100- als M4 Max-resultaten en was het open over de kloof daartussen: een gemiddelde snelheidswinst van 2,54× op een H100 werd 1,18× op een MacBook. Als opgegeven reden was mechanisch: het verifiëren van k tokens activeert meer experts dan één decodeerstap, dus een MoE-doel betaalt meer gewichtsverkeer per geverifieerd token, en llama.cpp's Metal-backend maakte dat erger.

LFM2.5-24B-A2B is ook een mixture of experts: 64 experts per blok met top-4-routing. Hetzelfde mechanisme is van toepassing, en de 24B is een groter model met een grotere expertset om doorheen te pagineren. Dat bewijst niet dat de versnelling op het apparaat klein is — de drafter is specifiek voor dit doel getraind, en de acceptatiegraad is veel beter dan die van de 8B in het begin was — maar het betekent wel dat het enige getal dat een laptopgebruiker nodig heeft, precies het getal is dat de kaart niet bevat. Beschouw elke aanname dat de B300-verhouding overdraagbaar is naar een Mac als onverifieerd.

Het draaien ervan, en de ene flag die je zal bijten

Op GPU is het gepubliceerde recept SGLang met het FP8-target en de drafter eraan gekoppeld, blokgrootte 9 en tien draft-tokens. De geïnstalleerde SGLang moet recent genoeg zijn om het LFM2-MoE DSpark-pad uit PR #31041 en het hergebruik van de configuratie uit PR #43939 te bevatten; op een oudere build zal de server de drafter-architectuur helemaal niet herkennen. Merk op dat de benchmarkcijfers uitgaan van het FP8-target — het BF16-target gedraagt zich anders, en niet noodzakelijk beter, omdat de drafter is getraind tegen een specifieke distributie van target-logits.

Op CPU en Apple silicon is het pad llama.cpp met de F16 GGUF-sidecar. De sidecar leest zijn blokgrootte uit zijn eigen metadata en begrenst --spec-draft-n-max daartoe, dus de conceptlengte op 12 zetten levert je geen 12 op. De timing per respons toont draft_n en draft_n_accepted, het veld om in de gaten te houden bij je eigen workload: als de acceptatie op jouw verkeer ver onder het gemiddelde van 5,16 van de kaart ligt, kost de drafter je een forward pass en levert hij weinig op, en dan is het eerlijke advies om hem los te koppelen.

Wat dit betekent als je deze week een model kiest

Voor de meeste teams is het praktische gevolg klein, omdat de drafter de snelheid verandert en niet de capaciteit. LFM2.5-24B-A2B is het onderdeel dat prompts beantwoordt; de drafter verandert alleen hoeveel van die antwoorden je per seconde krijgt. Als de 24B vorige week niet op je shortlist stond, zet een snellere versie ervan hem daar niet op.

Als het op je shortlist stond, versterkt het draftmodel het argument voor self-hosting en verandert niets aan het API-scenario. Dat onderscheid is het waard om duidelijk te benoemen: een checkpoint voor speculatieve decoding is onzichtbaar voor iedereen die een gehost endpoint aanroept, omdat de servingstack beslist of het wordt aangekoppeld. Wat je op gelijke voet kunt vergelijken, is het model zelf met de alternatieven waar je anders naartoe zou routeren — en als je het evalueert tegen iets als Qwen3.6-35B-A3B, het model waarmee Liquid benchmarkt op vijf van de acht agentische taken, dan levert OrcaRouter dat vergelijkingsdoel via één sleutel tegen 0% opslag op de lijstprijs van de provider, met automatische failover tussen providers. Wij bieden de LFM2.5-familie vandaag niet aan, dus de 24B zelf moet van de API van de leverancier zelf of van je eigen GPU's komen; wat wij bieden is de andere kant van de vergelijking zonder een tweede contract.

Wat zou deze afbeelding veranderen?

Drie dingen, in de volgorde van hoeveel invloed ze op het verhaal zouden hebben. Een blogpost van Liquid zou de positionering beslechten — of dit een aanbevolen productiecombinatie is of een researchrelease. Een gepubliceerde Mac-meting zou de claim beslechten die ertoe doet voor het publiek waarvoor de 24B is gebouwd. En een onafhankelijke acceptatierun op echt verkeer, in plaats van acht benchmarkdatasets bij temperatuur 0, zou je vertellen of 5,16 tokens per stap bestand is tegen de rommelige, lange tool-calling-prompts waarvoor dit model daadwerkelijk wordt verkocht.

Tot die tijd is de repository openbaar, zijn de gewichten te downloaden, ligt de CSV gewoon klaar, en is de eigen modelkaart van de leverancier de laatste plek waar je nieuws erover zou moeten zoeken. Dat is een ongebruikelijke toestand voor een release — maar het is er wel een, en het artefact wordt niet minder echt doordat niemand de blogpost heeft geschreven.