LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: Bör du verkligen ansluta draftaren?

Här är beslutet på en rad: LFM2.5-24B-A2B-DSpark är en fil med 327,7 miljoner parametrar som du lägger bredvid LFM2.5-24B-A2B så att 24B-modellen producerar samma typ av utdata snabbare. Det är inte ett alternativ till modellen och inte något du väljer i stället för den. Den enda riktiga frågan som de två namnen väcker är en ingenjörsfråga – kopplar du draftern till din driftsättning eller låter du den vara – och svaret beror mindre på den hastighetsökning som Liquid AI lyfter fram än på två siffror som ingen gör reklam för: hur många tokens utkastet får godkända på din trafik, och hur mycket samtidighet du redan kör. De dokumenterade AI-felen och agentincidenterna bakom släpp som det här samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omtvistad.

Liquid AI har inte publicerat något lanseringsinlägg för draftern. Repositoriet blev offentligt 2026-10-19 med vikter, en benchmark-CSV och SGLang-startflaggor, medan målmodellens eget modellkort fortfarande märker draftern som "coming soon" och Liquids dokumentationssida för spekulativ avkodning endast listar målen 1.2B, 2.6B, 8B och VL-3B. Det här är alltså en jämförelse av en levererad artefakt mot en levererad modell, skriven utifrån repositoriet snarare än utifrån ett pressmeddelande – vilket innebär att varje prestandasiffra nedan är leverantörsrapporterad och ingen av dem har oberoende reproducerats.

Vad utkastaren faktiskt ändrar, och vad den inte ändrar

Mekanismen är värd trettio sekunder eftersom den avgör allt annat. Avkodningen av en token är minnesbunden: GPU:n lägger största delen av tiden på att strömma vikter till SRAM, inte på att göra aritmetik. Spekulativ avkodning utnyttjar det genom att låta en liten modell gissa de närmaste flera tokens på en gång och sedan låta den riktiga modellen kontrollera hela gissningen i en enda framåtpassning. Om gissningen var bra producerade du nio tokens till ungefär kostnaden för en. Om den var dålig behåller målmodellen sin egen token och du betalade lite extra.

Vad som ändras: tokens per sekund och formen på ditt GPU-utnyttjande. Vad som inte ändras: modellens vikter, dess kontextfönster, dess beteende för verktygsanrop eller dess priser där den säljs. LFM2.5-24B-A2B behåller 24,0B totala parametrar med 2,45B aktiva per token, 40 lager uppdelade på gated kortkonvolutioner och grouped-query-attention, 64 experter per block med top-4-routing, ett kontextfönster på 131 072 tokens och en vokabulär på 128 000 tokens. Draftmodellen lägger till fem attentionlager, ett Markov-huvud med rang 256 och ett konfidenshuvud, och återanvänder målmodellens inbäddningar och LM-huvud i stället för att ha egna.

Ett förbehåll flyttades mellan de två utgåvorna och förtjänar en rad. I augusti stod det i Liquids DSpark-rapport att den genererade sekvensen är "per konstruktion identisk med baslinjens giriga avkodning". Modellkortet för 24B-draften säger i stället att flyttalsdifferenser mellan batchad verifiering och vanlig avkodning "kan ge annan text, även vid girig sampling". Båda påståendena är försvarbara – det första är sant i exakt aritmetik – men om ditt utvärderingsramverk jämför utdata byte för byte, räkna med att det märker det.

Kostnadssidan av räkenskaperna

Draftmodellen är inte gratis. Den upptar 655 MB i BF16 på GPU:n (eller en F16 GGUF på 664 MB på CPU:n), ligger i samma minnespool som målmodellen, och varje steg den föreslår kostar en verifierande framåtpassning över ett block med token i stället för över en enda token. Med en MoE-målmodell är den sista delen dyrare än den låter: att verifiera nio token aktiverar fler experter än att avkoda ett, så antalet byte som flyttas per verifierad token ökar, inte minskar. Liquid angav precis detta som skälet till att dess 8B-draftmodell bara gav 1,18× på en M4 Max trots hög acceptans.

Som motvikt till det är besparingarna tillräckligt stora för att mätas i GPU-timmar. Med leverantörens egna B300-siffror från benchmarks/b300-fp8.csv, och utan att göra något annat än att dividera en miljard utdatatokens med den observerade genomströmningen:

• MATH-500, samtidighet 1 – 324 tok/s på egen hand (857 GPU-timmar per miljard token) mot 853 tok/s med draftmodellen (326 GPU-timmar). En minskning av beräkningstiden med 2,63×.

• MATH-500, samtidighet 256 — 15 423 tok/s ensam (18,0 GPU-timmar) jämfört med 27 579 tok/s med draftaren (10,1 GPU-timmar). En minskning med 1,79×.

• GSM8K, samtidighet 256 – 4 491 tok/s på egen hand (61,9 GPU-timmar) jämfört med 9 660 tok/s med draftern (28,8 GPU-timmar). En minskning med 2,15×.

• LiveCodeBench, samtidighet 256 – 18 812 tok/s på egen hand (14,8 GPU-timmar) mot 25 231 tok/s med draftern (11,0 GPU-timmar). Bara en minskning på 1,34×, den svagaste cellen i tabellen.

Det där är genomströmningskvoter omvandlade till tid, inte till pengar, eftersom pengarna beror på vad du betalar per GPU-timme och den här artikeln kommer inte att hitta på någon taxa. Men ordningen gäller oavsett taxa: att koppla in draftern är värt två till tre timmar per tio för resonemangs- och kodgenereringstrafik vid låg samtidighet, och värt ungefär en tredjedel av det vid hög samtidighet. Om din 24B-distribution är en agent för en enskild användare på en arbetsstation är argumentet starkt. Om den är en mättad batch-endpunkt är argumentet verkligt men mycket svagare än 2,4×-rubriken antyder.

Där ritaren förtjänar sin plats, sett till arbetsbelastning

Spridningen mellan de åtta datamängderna i leverantörstabellen är inte brus; den motsvarar prompttyper, och den kopplingen är det mest användbara i släppet. Acceptansen varierade från 6,70 token per steg på MBPP ner till 4,02 på LiveCodeBench. De datamängder som fick höga resultat är de där modellens utdata begränsas av prompten – korta funktioner i stil med enhetstester, aritmetik med en kontrollerbar väg, flervalssvar. De som fick låga resultat är de där modellen måste hitta på en lång, obegränsad lösning: tävlingsprogrammeringsproblem och matematik i AIME-stil.

Det är intuitionen att ta med dig in i din egen utvärdering. En 24B-resonemangsmodell som säljs för agentiskt arbete spenderar större delen av sina utdatatoken i en tankekedja, vilket ser mer ut som LiveCodeBench än som MBPP. En modell som används för strukturerad extraktion, klassificering med ett schema eller ett fast verktygsanropsformat ser mycket mer ut som raderna med hög acceptans. Om din arbetsbelastning är den förra, förvänta dig att hamna närmare 1,34× nedre änden av intervallet än 3,28× övre änden. Ingen har publicerat acceptans per arbetsbelastning för den här draftaren, och modellkortets åtta datamängder är det närmaste man kommer en vägledning.

Ställt mot detta: 24B är en modell endast för resonemang. Liquid säger att den alltid tänker innan den svarar – chattmallen infogar en <think>-tagg automatiskt. Det är den sämsta möjliga formen för spekulation, eftersom resonemangssträckan är exakt den långa sträcka med låg acceptans. Utkastaren kommer fortfarande att hjälpa till; den hjälper mest med det slutliga svaret och minst med den del som tar längst tid.

Hur man avgör det på din egen hårdvara på en eftermiddag

Du behöver inte lita på något av ovanstående. Båda inferensvägarna exponerar acceptansräknaren, som är det enda talet som avgör om draftern betalar sig på din trafik.

I SGLang startar du målmodellen med draftern ansluten, blockstorlek 9 och tio draft-tokens, och läser sedan av mätvärdena för spekulativ avkodning som servern rapporterar per begäran. Acceptansgraden i leverantörens tabell ligger mellan 0,33 och 0,65 beroende på datamängd; en körning som hamnar långt under den relevanta raden innebär att draftern gissar fel och att du betalar för verifieringen utan att få någon snabbhetsvinst. I llama.cpp med F16 GGUF-sidecaren finns draft_n och draft_n_accepted direkt i tidsmätningarna per svar. Dividera det ena med det andra.

Två operativa detaljer kommer att kosta dig en timme om du missar dem. SGLang-servern behöver ett bygge som inkluderar LFM2-MoE DSpark-sökvägen som slogs samman 2026-08-31 — på något äldre är drafter-arkitekturen helt enkelt okänd. Och blockstorleken är en egenskap hos checkpointen, inte en fri parameter: llama.cpp begränsar --spec-draft-n-max till sidecar-filens metadatavärde på 9, så att begära 12 ger ingenting.

Frågan som denna jämförelse inte kan besvara

Det finns en version av "ska jag koppla in draftern" som inte har något med GPU:er att göra, och det är den som de flesta team faktiskt ställs inför. Om du anropar LFM2.5-24B-A2B via ett hostat API är det inte du som fattar beslutet om draftern. Serveringsstacken kopplar antingen in en spekulativ avkodare eller inte; du ser en siffra för tokens per sekund och ett pris, och båda har beslutats uppströms. Liquids egen Console listar 24B till $0.10 per miljon indatatokens, $0.05 för cachad indata och $1.00 per miljon utdata – en publicerad taxa som redan återspeglar vilken avkodningsväg de än kör, och som kan ändras utan förvarning.

Det är skarven där routing hjälper snarare än krånglar till. Ett hostat anrop och en självhostad driftsättning är inte så mycket konkurrerande planer som två inställningar på samma kostnadsratt: självhosting plus draftmodellen minimerar kostnaden per token om din volym håller GPU:n upptagen, och en hostad endpoint minimerar arbetet med att få ett svar. OrcaRouter är byggt för det andra — en nyckel för fler än 200 modeller med 0 % påslag på leverantörens listpris, så en ändring i leverantörspriset syns hos oss samma dag, med automatisk failover om en leverantör presterar sämre och ett routing-DSL för att dela upp trafik i stället för att hårdkoda en enda backend. Vi tillhandahåller för närvarande inte LFM2.5-familjen, så för just den här modellen innebär den hostade sidan Liquids eget API eller dina egna GPU:er; jämförelsen som är värd att göra är mot de modeller vi faktiskt har, till exempel Qwen3.6-35B-A3B — modellen som Liquid benchmarkar mot i agentiska uppgifter — eller Gemma 4 26B-A4B.

Så: bifoga det eller inte

Anslut den om du själv serverar LFM2.5-24B-A2B vid måttlig samtidighet, särskilt för strukturerad utdata eller utdata formad för extrahering, och om du har 655 MB ledigt utrymme bredvid målmodellen. Leverantörens siffror säger att du där ungefär halverar eller minskar din avkodningstid till en tredjedel, och nackdelen är begränsad: en dålig draftmodell kostar en verifieringsomgång, inte ett felaktigt svar.

Låt det vara avstängt om din endpoint redan är mättad i hundratal, om din utdata är ett långt fritt formulerat resonemang, eller om du behöver siffror för Apple Silicon innan du bestämmer dig – kortet har inga, och den närmaste motsvarigheten från samma familj levererades med 1,18× på en MacBook. Och låt det förstås vara avstängt om du inte kör modellen alls: en drafter är en optimering för en driftsättning, och det finns inget att optimera förrän driftsättningen finns.

Det som skulle avgöra resten är ett leverantörsinlägg och en Mac-mätning. Inget av dem finns per 2026-10-21, vilket är ett märkligt läge för ett släpp vars vikter redan går att ladda ner – och, för alla som är villiga att själva köra acceptansräknaren, ett ovanligt billigt tillfälle att bli den första oberoende siffran på tavlan.