DeepSeek DSpark: slik blir svarene fra V4 raskere enn med MTP

DeepSeek har sluppet et nytt system kalt DSpark, som skal gjøre svarene fra AI-modeller vesentlig raskere uten å ofre kvalitet. Ifølge selskapets egne tall øker det hvor mange brukere en server kan betjene med opp mot 661 prosent under harde fartskrav, sammenlignet med den forrige teknikken deres, MTP, og det er allerede tatt i bruk i DeepSeek V4.

Hvis du har brukt en agent til å løse en lang oppgave og sittet og sett på en loading-spinner i evigheter, vet du hvor irriterende ventetiden kan være. Jo lengre svaret blir, jo lengre tar det å generere – fordi modellen skriver ett ord om gangen og må sjekke det opp mot alt som er skrevet før. Det er akkurat denne flaskehalsen DSpark angriper.

Jeg er skeptisk til kinesiske modeller som DeepSeek generelt, men jeg kan ikke la være å bli imponert når et lite, ressursfattig selskap publiserer en løsning på et problem bransjen har slitt med lenge – og i tillegg gir bort koden. Så la meg forklare hva DSpark faktisk gjør, og hvorfor det er et smartere triks enn det først høres ut som.

Hva er DSpark egentlig?

DSpark er en ny variant av spekulativ dekoding, en teknikk som lar en liten, rask modell gjette flere ord fremover mens den store modellen bare bekrefter gjetningene i stedet for å skrive alt selv. DeepSeek publiserte metoden 27. juni og har allerede rullet den ut i DeepSeek V4.

Poenget med spekulativ dekoding er enkelt: den store modellen er treg og dyr, men den er den eneste vi stoler på for kvaliteten på svaret. En liten «utkast»-modell er billig og rask, men mindre presis. Løsningen har alltid vært å la den lille modellen gjette en bunke ord, og la den store modellen sjekke hele bunken samtidig – siden en GPU er god på å sjekke mange ting parallelt, men dårlig på å vente på ett og ett ord.

Problemet er at de små utkast-modellene har hatt to varianter, og begge har en svakhet. Den ene skriver ett ord om gangen (nøyaktig, men treg). Den andre gjetter en hel blokk med ord samtidig (rask, men upresis mot slutten av blokken – et fenomen kalt suffix decay, der ordene lengre ut i utkastet ofte blir feil fordi de ikke tar hensyn til hverandre). DSpark er DeepSeeks svar på akkurat dette dilemmaet.

Hvordan retter DSpark opp i suffix decay-problemet?

DSpark bygger videre på den raske, parallelle utkast-modellen, men legger til en liten mekanisme kalt et Markov-hode. Den ser kun på ordet rett før for å justere sannsynligheten for det neste ordet – akkurat nok kontekst til at utkastet henger bedre sammen uten å bli tregt.

Trikset er at denne ekstra sjekken nesten ikke koster noe. Markov-hodet bruker såkalt lavrangs-faktorisering (en måte å komprimere beregningen på) for å holde seg billig, og selv om systemet strekker utkastene betydelig lengre, øker ventetiden per runde med bare 0,2 til 1,3 prosent. Til gjengjeld blir de godkjente utkastene rundt 30 prosent lengre enn med sammenlignbare metoder – altså mer tekst per runde, med den samme kvalitetskontrollen fra den store modellen.

Hvordan avgjør DSpark hvor langt hvert utkast skal være?

DSpark har en egen modul (et confidence-hode) som gir hvert genererte ord en sikkerhetsscore, og stopper utkastet automatisk når scoren faller under en fast terskel – slik unngår systemet å kaste bort regnekraft på gjetninger den store modellen uansett vil avvise.

Dette høres kanskje kjedelig ut, men det er trolig den viktigste delen av hele systemet. Skriver modellen svar på en matteoppgave eller kode, er svaret ofte ganske forutsigbart, og utkastet kan derfor være langt uten stor risiko. Skriver den derimot en kreativ tekst med mange gyldige måter å formulere seg på, blir gjetningene fort usikre etter noen få ord, og da bør utkastet kuttes tidlig. Ifølge DeepSeeks egne tall økte andelen godkjente utkast i samtale-oppgaver fra 45,7 prosent til 95,7 prosent etter at denne styringen ble lagt til – en enorm forskjell i hvor mye regnekraft som faktisk går til spille.

Systemet ser i tillegg på hvor mye ledig kapasitet det er på GPU-ene akkurat nå, og justerer utkastlengden deretter. Er det lite trafikk, tillater den lengre og mer aggressive gjetninger for å presse ut mer fart per bruker. Er serveren under press, kutter den utkastene kortere for at hele systemet ikke skal krype – i stedet for at én bruker skal få litt raskere svar mens alle andre lider.

Hvor mye raskere er DSpark enn den gamle MTP-metoden?

Sammenlignet med DeepSeeks egen forrige teknikk, MTP (som kun forutsier ett ekstra ord om gangen), gir DSpark 60 til 85 prosent raskere generering per bruker på V4-Flash uten å gå på bekostning av kvaliteten, ifølge selskapets egne målinger. Det er tallet jeg selv fester mest lit til, fordi det måler hvor mye kjappere du faktisk får svaret ditt ved vanlig belastning.

Det mest oppsiktsvekkende tallet kommer likevel når DeepSeek satte en hard driftsbetingelse: hver bruker må minimum få 120 tokens per sekund – altså en reell responstid, ikke bare et laboratorietall. Under det kravet brøt den gamle MTP-metoden fort sammen og klarte bare å betjene et lite antall samtidige brukere før alt låste seg. DSpark klarte derimot rundt 661 prosent høyere total systemkapasitet under de samme betingelsene – fordi den er smart nok til å strekke eller kutte utkastene etter behov i stedet for å bruke én fast lengde for alle. Noen har lest dette som at modellen ble «sju ganger raskere», men det er en misforståelse: det handler om hvor mange brukere serveren klarer å holde oppe samtidig ved et strengt fartskrav, ikke om at selve svaret kommer sju ganger kjappere.

Verdt å presisere: dette er DeepSeeks egne tall fra deres egen publikasjon, ikke en uavhengig verifisert benchmark. Jeg pleier å ta selskapers egne prestasjonstall med en klype salt, og det gjelder her også. Men metoden og resonnementet bak er offentliggjort i detalj, koden er gitt ut under en MIT-lisens, og hvem som helst kan i prinsippet etterprøve det selv. Det er en helt annen åpenhet enn det man ofte ser fra de store, lukkede AI-selskapene, som stort sett behandler denne typen infrastrukturdetaljer som forretningshemmeligheter.

Betyr dette noe for deg som kjører modeller lokalt?

Indirekte, ja. DSpark er allerede tatt i bruk i DeepSeek V4, så bruker du den modellen via API eller en tjeneste som har oppdatert til den nyeste versjonen, får du trolig raskere responstid uten at du trenger å gjøre noe selv. Koden er også åpen, så det er bare et tidsspørsmål før andre åpne prosjekter forsøker å implementere lignende teknikker for spekulativ dekoding i egne modeller.

Det er samme type utvikling jeg har skrevet om før med DFlash-teknikker for spekulativ dekoding – både på Googles Gemma-modeller og i verktøy som ExLlamaV3. Trenden er tydelig: fremtidens fart handler mindre om å bygge enda større modeller, og mer om smartere måter å bruke regnekraften man allerede har på. Det er verdt å merke seg spesielt fordi det er akkurat den type problemløsning DeepSeek har måttet mestre – de har rett og slett ikke tilgang til de samme GPU-ressursene som amerikanske konkurrenter, og blir derfor tvunget til å tenke smartere i stedet for bare å kaste mer maskinvare på problemet.

Vil du se hvor denne utviklingen kom fra, kan du lese min gjennomgang av DeepSeek V4-forhåndsvisningen, modellen DSpark nå er bygget inn i. DeepSeeks egen modellside for V4 ligger på Hugging Face for den som vil grave videre i vektene selv.

Jeg forblir skeptisk til kinesiske modeller når det gjelder ting som datahåndtering og sensur, men rent teknisk er det vanskelig å ikke anerkjenne ingeniørarbeidet her. DeepSeek fortsetter å levere publikasjoner som er mer imponerende for hva de får til med begrensede ressurser, enn for rå skala.

Ofte stilte spørsmål