LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark: Samma 328M-fil, två väldigt olika satsningar

Ladda ned vilken som helst av filerna så får du 655,421,522 byte. LFM2.5-24B-A2B-DSpark och LFM2.5-8B-A1B-DSpark är exakt lika stora ända ned på bytenivå, delar en backbone med fem lager, samma Markov-huvud av rang 256, samma blockstorlek på 9 och samma ordförråd på 128,000 tokens — och ingen av dem kan svara på en enda prompt, eftersom båda är utkastmodeller för spekulativ avkodning som bara finns för att gissa tokens åt en målmodell. Det som skiljer dem åt är inte deras egen specifikation. Det är vilken målmodell de tränades mot, och hur mycket bevis det finns för att knepet fungerar på den. Den ena har publicerade GPU- och MacBook-mätningar från ett lanseringsinlägg; den andra har en GPU-tabell och inget tillkännagivande. Att välja mellan dem är därför inte alls en jämförelse av modeller — det är en jämförelse av två satsningar, och bara en av dem har lösts in. De dokumenterade AI-felen och agentincidenterna bakom släpp som detta samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omstridd status.

Filerna är tvillingar; jobben är inte.

Läs de två config.json-filerna sida vid sida och nästan varje fält matchar: dold storlek 2 048, mellanstorlek 6 144, SiLU-aktivering, 32 uppmärksamhetshuvuden över 8 KV-huvuden med huvuddimension 64, fem lager med full uppmärksamhet, blockstorlek 9, enable_confidence_head: true, ett vanligt Markov-huvud med rang 256. Parameterantalet är identiskt, vilket är anledningen till att safetensors-filerna matchar byte för byte.

Tre fält skiljer sig åt, och vart och ett är bärande.

• Lagertappningar från målmodellen – 8B-draftern läser dolda tillstånd från lagren 2, 6, 10, 14 och 18 i en målmodell med 24 lager; 24B-draftern läser lagren 2, 10, 18, 26 och 34 i en målmodell med 40 lager. Det här är fältet som gör att filerna inte kan bytas ut mot varandra.

• Maximalt antal positioner — 128 000 för 8B-utkastaren jämfört med 131 072 för 24B, i linje med deras målmodellers kontextfönster.

• RoPE-theta – 5 000 000 mot 10 000 000, inställt av målmodellens positionskodning snarare än av något som rör draftmodellen.

Det sista paret är det tydligaste beviset på att dessa checkpoints tränades per mål i stället för att skalas från en gemensam bas. Draftaren har ingen oberoende identitet: dess indatadistribution är hur målmodellens dolda tillstånd ser ut, och de ändras när målmodellens arkitektur och träning ändras. Rikta 8B-draftaren mot 24B-modellen och enbart lagerindexen gör den meningslös; även om de stämde överens skulle logitsen som den tränades att förutsäga inte göra det.

Vad var och en faktiskt accelererar

Målen är mer olika än namngivningen "8B versus 24B" antyder, och skillnaden går åt fel håll för alla som antar att den större modellen är den tyngre uppgiften att köra på enheten.

Totala och aktiva parametrar — LFM2.5-8B-A1B har 8,3B totalt med 1,5B aktiva per token; LFM2.5-24B-A2B har 24,0B totalt med 2,45B aktiva.

Djup — 24 lager (18 gated-konvolutioner plus 6 GQA) mot 40 lager (30 konvolutioner plus 10 GQA).

• Kontext — 128 000 tokens mot 131 072.

• Träningsbudget – 38T tokens mot 36T, så den mindre modellen var inte undertränad i förhållande till den större.

• Routing – 8B använder en MoE med 64 experter och top-4-routing, samma som 24B, så båda betalar expertaktiveringsstraffet som försämrar verifieringen.

Båda är resonemangsmodeller som tänker innan de svarar, vilket spelar större roll här än parameterantalen. Spekulativ avkodnings största svaghet är lång, otyglad utdata, och en tankekedja är precis det. Leverantörens tabeller visar det: de högsta acceptansraderna i båda utgåvorna är kortsvarsbenchmarks som MBPP och MT-Bench, och de lägsta är de där modellen måste hitta på en lång lösningsväg.

Bevisgapet är den verkliga skillnaden

Det är här de två utgåvorna slutar vara jämförbara. 8B-draftern lanserades den 20 augusti 2026 som en del av ett samlat tillkännagivande för hela familjen, med mätningar på två mycket olika maskiner: en enda H100 80 GB i BF16 via SGLang, och en M4 Max MacBook Pro som kör FP16 GGUF-vikter via llama.cpp med experimentella Metal-kärnor. Den gav i genomsnitt 2,54× på H100 med en topp på 3,18× på MATH-500, och bara 1,18× på MacBooken – 90 till 106 token per sekund, i genomsnitt över fem datamängder.

24B-draftaren har en enda hårdvarurad: en enda NVIDIA B300 med FP8-målet, BF16 KV-cache, temperatur 0. Den uppnår i genomsnitt 2,38× vid samtidighet 1, 2,69× vid samtidighet 32 och 1,71× vid samtidighet 256 över åtta datamängder, med en topp på 3,28× på MBPP vid samtidighet 32. Det finns ingen Mac-rad, ingen H100-rad och inget tillkännagivandeinlägg som förklarar utelämnandet.

För modellen vars hela säljargument är agenter på enheten – Liquids lanseringsinlägg för 24B:n inleds med 184 tokens per sekund på en Apple M5 Max – är det saknade MacBook-numret den enskilt mest betydelsefulla luckan i lanseringen. 8B-resultatet visar varför det kan vara litet: att verifiera ett block med tokens aktiverar fler experter än att avkoda en, så ett MoE-mål flyttar mer vikt per accepterad token. Och enbart acceptans är inte prediktorn: 8B-draften hade faktiskt i genomsnitt fler accepterade tokens per steg än vad 24B:ns kort anger (6,95 över fem dataset mot 5,16 över åtta) och levererade ändå bara 1,18× på en MacBook. Det är poängen värd att behålla – på 8B:n räddade stark acceptans inte genomströmningen på enheten. Att anta att 24B:n beter sig annorlunda är en satsning utan en siffra bakom sig.

Att läsa de två tabellerna mot varandra

De framträdande kvoterna är inte jämförbara och bör inte subtraheras från varandra. Olika GPU, olika målprecision, olika datamängder, olika svep över samtidighet. Men två mönster överlever trots missmatchningen.

För det första är taket liknande. 8B:s bästa H100-cell var 3,18× på MATH-500 vid batchstorlek 1; 24B:s bästa B300-cell är 3,28× på MBPP vid samtidighet 32. Drafters i den här designen hamnar i samma 1,5×–3,3×-band oavsett vilken målmodell de betjänar, vilket är vad man förväntar sig när drafter-arkitekturen hålls fast och endast vikterna ändras.

För det andra, och mer användbart, är golvet där målen divergerar. 8B:s svagaste H100-cell var GSM8K vid 1,29×; 24B:s svagaste B300-cell vid samtidighet 256 var LiveCodeBench vid 1,34× och AIME vid 1,36×. Ingen av utgåvorna ger ett fall där spekulation är gratis, och båda ger fall där den knappt är värd minnet.

Det finns också en dokumentationsändring mellan de två korten som är lätt att missa och värd att flagga. Augustimaterialet sade att utdata vid greedy-avkodning är identisk med baslinjen "av konstruktion"; 8B-kortet lovar "exakt samma utdata". 24B-kortet varnar i stället för att flyttalsdifferenser mellan batchad verifiering och vanlig avkodning kan ge olika text, även vid greedy-sampling. Det senare kortet är det mer försiktiga, och om du kör utdatadiffar på bytnivå i CI är båda värda att behandla som potentiellt icke-identiska i stället för att lita på det äldre löftet.

Vilken som är relevant för dig avgörs av ditt mål, inte din budget.

Det finns inget scenario där ett team väljer den ena framför den andra utifrån meriter. Man kör 24B för att man behöver en 24B-modells kapacitet på en maskin som klarar av att hålla den — 14,5 GB vid Q4_K_M i GGUF, eller en enda B300 för FP8-serveringskonfigurationen. Man kör 8B för att 8,3B totala parametrar med 1,5B aktiva är det som får plats på en edge-enhet eller en laptop, och draftmodellen återvinner en del av den avkodningshastighet man förlorade genom att gå ner i storlek. Draftmodellen är ett tillbehör till det första beslutet, och beslutet fattas nästan alltid utifrån minne och kvalitet långt innan spekulativ avkodning ens kommer på tal.

Det enda fallet där valet är aktuellt är utvärdering. Om du testar huruvida DSpark över huvud taget är värt att införa i din stack är 8B-kombinationen det billigare experimentet: den ryms på en H100, den har Mac-siffror som du kan jämföra med din egen laptop, och dess felbeteende på enheten har redan dokumenterats av leverantören. 24B-kombinationen är det mer intressanta produktionsexperimentet och det mindre dokumenterade.

För båda är det talet som avgör utfallet acceptansräknaren, inte leverantörens tabell. SGLang exponerar spekulativ avkodnings acceptans per begäran; llama.cpp rapporterar draft_n och draft_n_accepted i tidsmätningarna per svar. Kör dina egna prompter i tio minuter och dividera. Om acceptansen ligger nära kortets medelvärde lönar sig draftaren; om den ligger i den nedre änden köper du verifieringspass och bör koppla bort den – och den slutsatsen kommer att gälla för båda checkpoints, eftersom mekanismen är densamma.

Ingen av checkpointarna är en modell som du kan anropa

Det här är delen som fångar dem som stöter på de här namnen i en modellkatalog och antar att de är alternativ på en meny. De är inte slutpunkter. Ingen av utkastmodellerna har ett pris per miljon token, ingen av dem förekommer i en API-listning, och ingen av dem kommer någonsin att dirigeras till av en plattform som tillhandahåller modeller – eftersom den korrekta parkopplingen är en konfiguration på serversidan, inte en förfrågningsparameter.

Liquid AI säljer själva 24B-målmodellen för $0,10 per miljon indatatokens, $0,05 för cachade och $1,00 per miljon utdatatokens, och eventuell spekulation som ligger bakom det priset är osynlig för anroparen. Det är marknadens vanliga form nu: den intressanta ingenjörskonsten sker inuti serveringsstacken, och det som når en utvecklare är en taxa och en siffra för tokens per sekund. Där routerplattformar förtjänar sin plats är i jämförelsen ovanpå det lagret – att ställa en kandidat bredvid de modeller den måste slå. OrcaRouter kör en slutpunkt över över 200 modeller med 0 % påslag på leverantörens listpris, så när en leverantörs taxa ändras ändras den taxa du ser samma dag, och failover gör att en kandidatmodell inte blir en enda felpunkt medan du utvärderar den. LFM2.5-familjen finns inte bland dem i dag, så en självhostad 8B eller 24B med sin drafter kopplad förblir en lokal driftsättning; de modeller som är värda att testa mot den – Qwen3.6-35B-A3B på den agentiska sidan, Gemma 4 26B-A4B på effektivitetssidan – är de vi routar.

Vad ett år av DSpark-releaser har etablerat

Familjen omfattar nu fyra textmål och ett visionsmål, från 1,2B till 24B, alla med samma recept för draftern: cirka 300M parametrar, fem attention-lager, block 9, tränad på målets egna dolda tillstånd. Det är den konsistensen som är själva fyndet. Liquid har förvandlat spekulativ avkodning från ett forskningsprojekt per modell till ett tillverkningssteg – samma drafter, omriktad, levererad inom några dagar efter varje ny modell. Om det steget är värt att ta på din hårdvara är en fråga om din trafik, och svaret varierar mycket mer med arbetsbelastningen än med vilken av dessa två filer du laddar ner.

Det som 24B-släppet tillför den bilden är inte en bättre kvot. Det är första gången en draftmodell har släppts utan den medföljande dokumentationen – och första gången leverantörens eget kort i klarspråk har talat om för dig att utdata kanske inte är bitidentiska trots allt.