LFM2.5-24B-A2B-DSpark är live på Hugging Face – Liquid AI har bara inte tillkännagivit det än

Modellkortet för Liquid AI:s största modell säger fortfarande att dess draftmodell för spekulativ avkodning kommer snart. Draftmodellen kommer inte. LFM2.5-24B-A2B-DSpark har haft ett publikt repository sedan den 19 oktober 2026, en BF16-checkpoint på 655 MB, en fullständig benchmarktabell, en GGUF-sidecar som publicerades kvällen därpå och startflaggor för SGLang inskrivna i sitt modellkort. Det som saknas är ett tillkännagivande. LFM2.5-24B-A2B, 24B mixture-of-experts-modellen som draftmodellen finns till för att accelerera, fick ett blogginlägg, en daterad lansering, en prislista och en playground-länk den 13 oktober 2026. Dess draftmodell fick ett repo och ett modellkort, och Liquid AI:s egen dokumentationssida för spekulativ avkodning listar fortfarande endast målen 1.2B, 2.6B, 8B och VL-3B som stödda. De dokumenterade AI-felen och agentincidenterna bakom lanseringar som denna samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och flagga för omstridd status.

Det glappet är det som är historien här, och det är värt att vara noggrann med vad det innebär och inte innebär. Ett repo vars vikter är öppna, vars benchmarkresultat kan reproduceras från en CSV-fil som ligger bredvid modellen, och vars inferensväg redan är sammanslagen uppströms är en riktig release, inte en läcka. Men ingenting av det har bekräftats av leverantören i löpande text, ingen tredje part har mätt det, och siffrorna i kortet är samma teams siffror mätta på samma hårdvara som de valt. Den här artikeln skiljer på de två: vad repot fastställer och vad som fortfarande är ett påstående.

Vad finns egentligen i arkivet?

Checkpointen är tillräckligt liten för att själva filförteckningen ska vara informativ. Hela saken är en enda model.safetensors på 655 421 522 byte – 327,7 miljoner parametrar i BF16 – plus en konfig, en licens och en benchmark-katalog. Inget annat. Det finns ingen tokenizer, ingen inbäddningsmatris och inget LM-huvud, eftersom arkitekturen återanvänder alla tre från målmodellen vid inläsning. Det är designen: draftern behöver bara veta hur den ska gissa nästa tokenblock i målmodellens vokabulär, inte hur den ska representera världen.

Konfigurationen bekräftar den form som August DSpark-sammanställningen beskrev. Fem full-attention-lager vid dold storlek 2 048 och mellanstorlek 6 144 med SiLU/SwiGLU; grouped-query attention med 32 huvuden och 8 KV-huvuden vid huvuddimension 64; ett Markov-huvud med rang 256 och ett separat konfidenshuvud; blockstorlek 9; vokabulär 128 000; och en maximal positionsinbäddning på 131 072, vilket exakt matchar målets kontextfönster. Det enda fältet som är specifikt för denna drafter är target_layer_ids: [2, 10, 18, 26, 34] mot num_target_layers: 40 – de fem lagren i 24B-modellen vars dolda tillstånd draften läser som kontext. Det är dessa index som gör att en drafter tränad för en LFM2.5-modell inte bara kan pekas mot en annan.

Licensen är lfm1.0, samma anpassade licens som resten av familjen, vilket är värt att notera för alla som planerar att återdistribuera en paketerad artefakt med target-plus-drafter snarare än att använda den internt.

Benchmark-tabellen, läst som en leverantörstabell

Kortet publicerar genomströmning för åtta dataset vid samtidighet 1, 32 och 256, på en enda NVIDIA B300 med FP8-målet, en BF16 KV-cache och temperatur 0. Varje siffra nedan är Liquid AI:s egen och har inte reproducerats utanför företaget; de råa raderna finns i repots benchmarks/b300-fp8.csv om du själv vill kontrollera aritmetiken.

• Aritmetiskt medelvärde över de åtta datamängderna – 2,38× vid samtidighet 1, 2,69× vid samtidighet 32, 1,71× vid samtidighet 256.

• Bästa enskilda cell — MBPP vid samtidighet 32, 3,28×, med MATH-500 tätt efter på 3,04×.

• Sämsta enskilda cell — LiveCodeBench vid samtidighet 256, 1,34×, och AIME vid 256, 1,36×.

• Tokens som accepteras per steg – 5,16 i genomsnitt, mot ett tak på 10 som bestäms av blockstorleken plus målets bonustoken.

• Högsta acceptans — MBPP med 6,70 token per steg; lägst — LiveCodeBench med 4,02.

Två saker i den tabellen är mer intressanta än rubriken. Det första är att den genomsnittliga hastighetsökningen är högre vid samtidighet 32 än vid samtidighet 1 – 2,69× mot 2,38× – vilket är motsatsen till den vanliga berättelsen om spekulativ avkodning, där batchning äter upp vinsten. Det andra är att den kollapsar vid 256. Vid 256 samtidiga förfrågningar genererar målet ensamt redan cirka 15 000 tokens per sekund på den GPU:n för MATH-500, och draftarens bidrag faller till 1,79×. Ett servingteam som bara läser "2,4×" skulle dimensionera ett kluster fel; siffran som spelar roll för en batchad endpoint är 1,71×, och även den är en B300-siffra med en samtidighetsprofil som de flesta driftsättningar inte kommer att matcha.

Meningen som har förändrats sedan augusti

När Liquid AI släppte DSpark-utkastare för 1.2B-, 2.6B- och 8B-A1B-målmodellerna den 2026-08-20 framförde dess blogginlägg ett starkt påstående: eftersom målmodellen verifierar varje föreslagen token och ersätter avvisade förslag med sitt eget val, ”är den emitterade sekvensen därför identisk med baslinjens greedy-avkodning genom konstruktion.” Modellkortet för 8B-utkastaren upprepar andemeningen och lovar ”exakt samma utdata.”

24B-draftmodellens kort säger inte det. Det säger att målmodellen verifierar varje föreslagen token och sedan: "Skillnader i flyttal mellan batchverifiering och vanlig avkodning kan ge olika text, även vid girig sampling." Det tillägger att mätningarna bedömer prestanda, inte uppgiftsnoggrannhet.

Det här är en mer noggrann formulering, och det är den rätta. Batchad verifiering utför inte samma flyttalsoperationer i samma ordning som sekventiell avkodning, så bitidentitet är ett antagande som gäller i exakt aritmetik men inte alltid på verklig hårdvara. Att det nyare kortet säger det medan det äldre inte gjorde är antingen en dokumentationsrättelse eller en upptäckt under träningen av den här draftern – förrådet talar inte om vilket, och Liquid har inte publicerat någon förklaring. Vad det innebär i praktiken är snävt men verkligt: om din regressionssvit diffar modellutdata byte för byte kan tillägget av den här draftern utlösa den, och det är en egenskap hos aritmetiken snarare än en bugg i draften.

Varför draftaren anlände sex dagar efter sin egen modell

Det är värt att redogöra för tidslinjen eftersom den förklarar tystnaden bättre än någon spekulation om strategi.

• 2026-08-20 — Liquid publicerar DSpark-familjen: draftmodeller för LFM2.5-1.2B-Instruct, LFM2.5-2.6B och LFM2.5-8B-A1B. Det finns ännu ingen 24B-målmodell.

• 2026-08-31 — SGLang slår samman PR #31041 och lägger till stöd för spekulativ avkodning med DSpark för LFM2 och LFM2-MoE. MoE-vägen som 24B behöver landar här, en och en halv månad innan modellen den ska betjäna.

• 2026-10-13 — LFM2.5-24B-A2B släpps med ett blogginlägg och ett pris. Samma dag sammanfogar SGLang PR #43939, vilket gör att servern kan återanvända Hugging Face LFM2-MoE-konfigurationen direkt.

• 2026-10-19 — LFM2.5-24B-A2B-DSpark-repositoriet dyker upp, med vikter och riktmärken.

• 2026-10-20 — GGUF-sidecaren landar: en enda F16-fil på 664 MB för llama.cpp.

• 2026-10-21 — målmodellkortet får en drafter-rad. Det står fortfarande Kommer snart.

Läs den sekvensen, och den mest sannolika förklaringen är den tråkiga. Infrastrukturen levererades före artefakten; artefakten levererades när träningen var klar; tillkännagivandet är en marknadsföringsuppgift som ännu inte har utförts. Inget i repositoriet tyder på en avsiktligt tyst lansering – kortet är komplett, benchmarkarna är dokumenterade ända ned till protokollet, och anropen för SGLang och llama.cpp är utskrivna i sin helhet. Tyst betyder här att något inte har tillkännagivits, inte att det är dolt.

Det som ännu inte går att veta

Den ärliga gränsen för den här texten är en kort lista, och varje punkt är en verklig lucka snarare än en formalitet.

Ingen oberoende mätning. Det finns ingen Artificial Analysis-post, ingen tredjepartsgodkänd körning, ingen reproduktion av genomströmningstabellen. Per 2026-10-21 visade förvaret sju nedladdningar och en gillamarkering. Varje hastighetsökning i den här artikeln är leverantörens, på leverantörens valda GPU, med leverantörens valda målprecision.

Inget tillkännagivande, alltså ingen inramning. Vi vet inte om Liquid avser detta som en produktionsrekommendation för 24B eller som en forskningsartefakt. Kortets ton — fullständiga lanseringsflaggor, en familjetabell, en kontaktlänk — tyder på det förra, men det är en slutledning.

Inget pris, eftersom det inte kan finnas något. En drafter är inte en serverad modell. Den har ingen kostnad per miljon token och kommer aldrig att visas i en modellkatalog som en anropbar slutpunkt. Dess kostnad är de 655 MB VRAM eller enhetligt minne som den upptar bredvid målmodellen, plus den extra beräkningen att verifiera ett block i stället för en token.

Inga Apple Silicon-siffror. Detta är den största luckan, och nästa avsnitt förklarar varför den spelar större roll än de andra.

Det saknade Mac-numret är den intressanta utelämningen

24B-modellen säljs som en modell för lokal körning på enheten. Liquids lanseringsinlägg inleds med 184 token per sekund på en Apple M5 Max och beskriver den som byggd för snabba, privata agenter på enheten. Draft-modellens kort redovisar däremot endast B300-siffror. För 8B-draftmodellen i augusti publicerade Liquid både H100- och M4 Max-resultat och var öppen med skillnaden dem emellan: en genomsnittlig hastighetsökning på 2,54× på en H100 blev 1,18× på en MacBook. Den angivna orsaken var teknisk – verifiering av k token aktiverar fler experter än ett enskilt avkodningssteg, så en MoE-målmodelell betalar mer vikttrafik per verifierat token, och llama.cpp:s Metal-backend gjorde det ännu värre.

LFM2.5-24B-A2B är också en blandning av experter: 64 experter per block med top-4-routing. Samma mekanism gäller, och 24B är en större modell med en större expertuppsättning att bläddra igenom. Det bevisar inte att snabbhetsvinsten på enheten är liten – draftern tränades specifikt för detta mål, och acceptansen är mycket bättre än 8B:s var till en början – men det innebär att det enda tal en laptopanvändare behöver är det enda tal som kortet inte innehåller. Behandla alla antaganden om att B300-förhållandet skulle gälla för en Mac som overifierade.

Att köra det – och den där flaggan som kommer att bita dig

På GPU är det publicerade receptet SGLang med FP8-målet och draftern kopplad, blockstorlek 9 och tio draft-tokens. Den installerade SGLang-versionen måste vara tillräckligt ny för att innehålla LFM2-MoE DSpark-sökvägen från PR #31041 och konfigurationsåteranvändningen från PR #43939; på en äldre build kommer servern inte alls att känna igen drafterarkitekturen. Observera att benchmarktalen förutsätter FP8-målet — BF16-målet kommer att bete sig annorlunda, och inte nödvändigtvis bättre, eftersom draftern tränades mot en specifik fördelning av target-logits.

På CPU och Apple silicon är vägen llama.cpp med F16 GGUF-sidovagnen. Sidovagnen läser sin blockstorlek från sin egen metadata och begränsar --spec-draft-n-max till den, så att ställa in utkastlängden till 12 ger dig inte 12. Tidsmätningar per svar exponerar draft_n och draft_n_accepted, vilket är fältet att hålla koll på i din egen arbetsbelastning: om acceptansen för din trafik ligger långt under kortets medelvärde på 5,16 kostar utkastaren dig en forward pass och ger lite, och det ärliga draget är att koppla bort den.

Vad detta innebär om du väljer en modell den här veckan

För de flesta team är den praktiska konsekvensen liten, eftersom draftmodellen ändrar hastigheten och inte förmågan. LFM2.5-24B-A2B är det som svarar på prompter; draftmodellen ändrar bara hur många av dessa svar du får per sekund. Om 24B inte fanns på din kortlista förra veckan gör en snabbare version av den inte att den hamnar där.

Om den fanns med på din kortlista förbättrar draftmodellen argumenten för självhosting och gör ingenting för API-fallet. Den skillnaden är värd att säga rakt ut: en checkpoint för spekulativ avkodning är osynlig för alla som anropar en hostad slutpunkt, eftersom serving-stacken avgör om den ska kopplas in. Det du kan jämföra på lika villkor är modellen i sig mot de alternativ du annars skulle routa till — och om du utvärderar den mot något i stil med Qwen3.6-35B-A3B, den modell som Liquid benchmarkar mot på fem av åtta agentiska uppgifter, tillhandahåller OrcaRouter det jämförelsemålet bakom en enda nyckel till 0 % påslag på leverantörens listpris, med automatisk failover mellan leverantörer. Vi tillhandahåller inte LFM2.5-familjen i dag, så själva 24B måste komma från leverantörens eget API eller dina egna GPU:er; det vi erbjuder är andra sidan av jämförelsen utan ytterligare ett avtal.

Vad skulle förändra den här bilden?

Tre saker, i ordning efter hur mycket de skulle förändra berättelsen. Ett blogginlägg från Liquid skulle avgöra inramningen – om detta är en rekommenderad produktionskombination eller en forskningsrelease. Ett publicerat Mac-mått skulle avgöra det påstående som betyder något för den målgrupp som 24B byggdes för. Och en oberoende acceptanskörning på verklig trafik, snarare än åtta benchmarkdataset vid temperatur 0, skulle visa om 5,16 tokens per steg klarar mötet med de röriga, långa prompter med verktygsanrop som modellen faktiskt säljs för.

Fram till dess är repositoryt publikt, vikterna nedladdningsbara, CSV-filen finns precis där, och leverantörens eget modellkort är det sista stället du bör leta efter nyheter om det. Det är ett ovanligt tillstånd för en release att vara i – men det är ett verkligt sådant, och artefakten blir inte mindre verklig för att ingen skrev blogginlägget.