LM Studio 0.4.22 Build 1, daterad 28 augusti 2026, lägger till stöd för DFlash, DSpark och MTP som assistant drafters. Versionsnoteringen anger samtidigt ett hårt minimikrav: llama.cpp-motorn ska vara version 2.29.1 eller nyare. Däremot lovar den varken en viss hastighetsökning eller att alla tre tekniker fungerar med varje modell. Där börjar det användbara arbetet: kontrollera kompatibiliteten, frys provet och låt fyra lokala körlägen konkurrera på samma villkor.
Behåll en drafter bara om medianen förbättrar ditt valda huvudmått, minnesökningen ryms med marginal och svaren fortfarande klarar samma kontroll. Ett nytt val i gränssnittet är en hypotes, inte ett resultat.
Vad de tre valen faktiskt behöver
Alla tre försöker minska kostnaden för sekventiell generering genom att föreslå flera kommande token som målmodellen sedan verifierar. Men de kommer inte från samma sorts underlag. llama.cpp:s aktuella dokumentation beskriver DFlash som en liten block-diffusionsmodell som producerar ett helt block av förslag i en framåtpassage. Den draftern är tränad för en bestämd målmodell och delar bland annat målmodellens tokenisering. En fil med DFlash i namnet är därför inte utbytbar mellan godtyckliga målmodeller.
DSpark bygger enligt samma dokumentation vidare på DFlash med ett semi-autoregressivt Markov-huvud. Även där hör draftern ihop med ett bestämt mål. Vid kontrollen den 30 augusti 2026 anger llama.cpp dessutom att DSpark-drafts bara stöds med Qwen3-backbone. Det är en färsk implementationsgräns, inte en egenskap du bör räkna med över tid; kontrollera dokumentationen igen när du byter motor.
MTP är annorlunda. Typbeskrivningen i llama.cpp anger att läget använder MTP-huvuden i huvudmodellen. Det betyder inte att MTP finns i varje GGUF. Om LM Studio inte erbjuder valet för den exakta målfilen ska du inte försöka jämföra det genom att byta till en annan modell: då har du ändrat både modell och avkodningsmetod och provet svarar inte längre på samma fråga.
| Läge | Kompatibilitetskontroll | Resursfråga |
|---|---|---|
| Grundläge | Samma målmodell utan assistant drafter. | Referens för RAM, VRAM och tider. |
| DFlash | Exakt draftmodell ska vara avsedd för målet. | Ryms mål och separat drafter samtidigt? |
| DSpark | Exakt modellpar; vid kontrollen stöds Qwen3-backbone. | Ger blockförslagen mer än deras overhead kostar? |
| MTP | Målfilen måste innehålla användbara MTP-huvuden. | Ger inbyggda huvuden vinst utan oacceptabelt påslag? |
Kontrollera version och minnesmarginal före första körningen
Börja med den motor LM Studio verkligen använder, inte bara appversionen. Den officiella runtime-dokumentationen anger att lms runtime ls listar installerade inference runtimes och att runtimekommandot också kan hämta, välja och uppdatera dem. Anteckna hela runtime-namnet och versionsnumret i provprotokollet. Om llama.cpp-motorn är äldre än 2.29.1 uppfyller installationen inte utgåvans angivna krav för de nya assistant drafters.
lms runtime ls
Datum: 2026-08-30
LM Studio: 0.4.22 Build 1
Aktiv runtime: ____________________
Målmodell och kvantisering: ____________________
Drafterfil eller MTP-läge: ____________________Gör sedan en minneskontroll. LM Studios dokumentation för lms load beskriver --estimate-only, som skriver ut uppskattat GPU-minne och totalt minne utan att ladda modellen. Kör det först för målet med den kontextlängd och GPU-offload du tänker använda. För DFlash och DSpark behöver du dessutom marginal för draftmodellen. Estimatet är en förkontroll; faktisk topp i Aktivitetshanteraren, nvidia-smi eller motsvarande systemverktyg ska fortfarande antecknas under provet.
Om grundläget redan ligger nära minnestaket blir en drafterjämförelse missvisande. En ny konfiguration som tvingar fler lager till CPU kan ge lägre tokens per sekund av placeringsskälet, inte därför att själva metoden är dålig. Ta hjälp av AI-burkens hårdvaruguide för att hålla vikter, KV-cache och arbetsmarginal åtskilda.
Frys ett prov som mäter både fart och användbart svar
Skapa tre promptar från ditt verkliga flöde. En ska vara kort och mäta interaktiv väntan, en ska beställa minst 300 nya token så att genereringshastigheten hinner dominera, och en ska innehålla ett kontrollerbart formatkrav. Ett exempel på det tredje är: ”Sammanfatta texten i exakt fem punktlistor. Varje punkt ska börja med ett verb och innehålla högst 18 ord.” Då kan du kontrollera samma sak som prompten beställer.
Frys följande innan du byter läge: exakt målfil och kvantisering, kontextlängd, GPU-offload, Flash Attention, prompttext, systemprompt, temperatur, seed och maximalt antal nya token. Använd temperatur 0 om du främst vill upptäcka om svaren skiljer sig. llama.cpp-dokumentationen varnar för att stokastisk CPU- och backend-sampling kan välja olika token även med fast seed på grund av flyttalsvariationer; greedy sampling är därför det renare jämförelseläget när exakt utdata spelar roll.
Kör varje prompt tre gånger per läge. Redovisa första körningen separat och ta medianen av de tre som huvudvärde. Stäng andra GPU-tunga program och ändra inte kontext eller offload för att få en enskild drafter att passa. Om du måste göra det har du hittat en viktig praktisk nackdel, och den hör hemma i resultatet.
Hämta samma två tidsmått från LM Studio
LM Studios äldre men fortfarande dokumenterade REST API v0 returnerar både tokens_per_second och time_to_first_token i svarens statistik. Den officiella endpointsidan rekommenderar v1 för nya projekt, men v0 är användbar här eftersom just de två fälten visas explicit i ett icke-strömmat svar. Starta den lokala servern, ladda den frysta konfigurationen och skicka samma JSON för varje läge:
curl http://localhost:1234/api/v0/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "DIN-MODELLIDENTIFIERARE",
"messages": [{"role": "user", "content": "DIN FRYSTA PROMPT"}],
"temperature": 0,
"max_tokens": 400,
"stream": false
}'Har du aktiverat API-autentisering i LM Studio behöver anropet också en Authorization: Bearer …-rubrik med den token som gäller för din lokala server. Lämna inte in en exempelsträng som om den vore en riktig token.
Spara hela svaret, inte bara två siffror. tokens_per_second beskriver takten efter att genereringen kommit igång. time_to_first_token fångar väntan innan första token. En drafter kan förbättra det ena men försämra det andra. För chatt känns första token ofta viktigast; för långa sammanfattningar eller kodutkast väger den uthålliga genereringshastigheten tyngre.
Fyll tabellen innan du utser en vinnare
| Läge | Median tok/s | Median första token | Topp RAM/VRAM | Godkända svar |
|---|---|---|---|---|
| Grundläge | ___ | ___ s | ___/___ GB | ___ av 3 |
| DFlash | ___ | ___ s | ___/___ GB | ___ av 3 |
| DSpark | ___ | ___ s | ___/___ GB | ___ av 3 |
| MTP | ___ | ___ s | ___/___ GB | ___ av 3 |
Beräkna förändringen mot grundläget, inte mot den långsammaste konkurrenten: (drafter − grundläge) / grundläge × 100 för tokens per sekund. För tiden till första token är lägre bättre, så redovisa hellre sparade millisekunder än en svårtolkad positiv procentsats. Lägg dessutom till en kolumn för fel: laddningsfel, CPU-offload, minnesbrist eller ett svar som bröt formatkravet.
llama.cpp:s statistik kan också visa hur många drafttokens som genererades och accepterades. En låg acceptans kan förklara overhead, men hög acceptans är inte slutmålet. Det är möjligt att acceptera många förslag och ändå få en liten end-to-end-vinst om draftern kostar mycket att köra på just din hårdvara. Därför vinner bara ett läge som förbättrar ditt användarmått.
Tre beslut som tabellen kan ge
- Behåll draftern. Medianen förbättras i den arbetslast du bryr dig om, alla tre svar klarar kontrollen och minnet har rimlig marginal.
- Behåll grundläget. Hastigheten rör sig inom normal variation, första token blir långsammare eller draftmodellen tränger undan målmodellen från GPU.
- Kör om ett smalare prov. Ett läge vinner på den långa prompten men förlorar interaktivt. Spara då två namngivna konfigurationer för två verkliga arbetsflöden i stället för att kalla en teknik bäst.
Byt inte målmodell mitt i jämförelsen bara för att göra en drafter kompatibel. Vill du prova ett annat modellpar är det ett nytt experiment med ett eget grundläge. Samma regel gäller kvantisering. Guiden till Q4, Q5 och Q8 hjälper dig välja fil, men valet ska vara fryst inom just denna benchmark.
Nyheten är stödet – resultatet är ditt
LM Studio 0.4.22 gör tre moderna draftertyper tillgängliga i appens llama.cpp-väg. Det är nyhetsvärdet. Vilken som hjälper dig går inte att läsa ur namnen DFlash, DSpark eller MTP, och versionsnoteringen försöker inte heller lova ett svar. På en lokal AI-burk avgör modellparet, kvantiseringen, minnesplaceringen, prompttypen och hårdvaran om spekulativ avkodning betalar sin egen kostnad.
Spara därför runtimeversion, modellidentifierare, konfiguration, de tolv råsvaren och den ifyllda tabellen. Då kan du köra om samma prov efter nästa runtimeuppdatering och se om en faktisk förändring skett. Det är mer värdefullt än en generell topplista: du får ett beslut för din modell, din maskin och den väntetid du faktiskt märker.
Källor
- LM Studio – versionsnotering 0.4.22: publiceringsdatum, stöd för DFlash, DSpark och MTP samt minimikravet llama.cpp engine 2.29.1
- llama.cpp – speculative decoding: DFlash, DSpark, MTP, kompatibilitetsavgränsningar, sampling, statistik och benchmarkprincip
- LM Studio –
lms runtime: lista och hantera installerade inference runtimes - LM Studio – REST API v0: svarsfälten för tokens per sekund och tid till första token
- LM Studio –
lms load: minnesestimat, kontextlängd och GPU-offload
Källorna kontrollerades 30 augusti 2026. Ingen egen benchmark eller installation ligger bakom artikeln, och inga hastighets-, acceptans- eller minnesvärden presenteras som uppmätta resultat. llama.cpp-dokumentationen lästes i aktuell masterversion och kan ändras; kontrollera den igen tillsammans med den runtime du faktiskt väljer.