A.X K2 DSpark vs A.X K2: Vad en drafter-only-modell faktiskt ger dig

Det märkligaste med en jämförelse mellan A.X K2 DSpark och A.X K2 är att det egentligen inte är en jämförelse. A.X K2 DSpark kan inte användas i stället för A.X K2 – den kan inte användas alls på egen hand. Det är en "drafter-only checkpoint" som SK Telecom tyst släppte på Hugging Face i början av augusti utan något tillkännagivande: en draftmodell för spekulativ avkodning vars enda uppgift är att få A.X K2, företagets Mixture-of-Experts-flaggskepp med öppna vikter och 688 miljarder parametrar, att generera tokens snabbare medan svaren lämnas orörda. Så den verkliga frågan som den här jämförelsen kretsar kring är inte "vilken är bättre." Utan "bör du köra A.X K2 med DSpark, eller utan den?" Allt i den här texten är märkt med källa, eftersom gapet mellan vad repot berättar för oss och vad som faktiskt har uppmätts är hela historien.

Vad A.X K2 DSpark faktiskt är

SK Telecoms modellkort är ovanligt rakt på sak om vad modellen är till för. A.X K2 DSpark "är en DSpark-spekulativ avkodnings-draftmodell för A.X K2" och "en draft-only-checkpoint: den har ingen fristående användning och är avsedd att laddas av vLLM tillsammans med A.X K2 genom spekulativ avkodning." I praktiken innebär det att du laddar ner den, pekar en kompatibel vLLM mot både den och A.X K2, och de två arbetar som ett team: DSpark föreslår kandidattoken, A.X K2 verifierar dem, och endast verifierade token släpps.

Två detaljer om draftmekanismen går att utläsa från repot. För det första föreslår DSpark flera kandidattoken parallellt, med utgångspunkt i A.X K2:s egna dolda representationer tillsammans med lättviktig lokal beroendemodellering, snarare än att skriva en draftsekvens en token i taget. För det andra är det hela konstruerat för att vara förlustfritt: varje kandidat verifieras av målmodellen innan den accepteras, så A.X K2:s utdatafördelning är oförändrad per konstruktion.

Själva releasen är ett förhandsmeddelande. Kortet säger att modellen {{1}}"för närvarande är i slutlig validering och planeras för offentlig release inom de närmaste dagarna"{{/1}} och att utvärderingen {{2}}"pågår för närvarande"{{/2}} — alla throughput-, TPOT- och mean-accepted-length-mått på kortet är fortfarande listade som TBD.

Varför detta "versus" egentligen är "med versus utan"

Eftersom A.X K2 DSpark inte har någon fristående användning, finns det inget scenario där du väljer det istället för A.X K2. Valet står mellan A.X K2 ensamt och A.X K2 med draftmodellen kopplad. När det gäller utdatakvalitet är de två konfigurationerna identiska till sin konstruktion; den enda axeln som kan röra sig är avkodningshastigheten.

För protokollet, här är vad A.X K2 är: en Mixture-of-Experts-avkodare med totalt 688B parametrar, 33B aktiva, med 256 experter plus en delad expert (8 aktiva per framåtpass), 61 lager, 64 uppmärksamhetshuvuden och ett ordförråd på 163 840 tokens, släppt med öppna vikter under Apache 2.0 den 29 juli. Den var förtränad på cirka 8,2 biljoner tokens i nativ MXFP8, använder SK Telecoms Sparse Gated Attention för effektivitet vid långa kontexter, och har en kontext på 262 144 tokens (nativ 128K utökad till 256K via YaRN). SK Telecom rapporterar att den i genomsnitt ligger +32,2 procentenheter över A.X K1 över 14 riktmärken, med utvärderingar av lång kontext och agenter upp cirka 83,9 poäng — allt leverantörsrapporterat, utan något oberoende sammanvägt resultat publicerat ännu.

DSpark är designat specifikt för den arkitekturen. Kortet säger att det är anpassat till A.X K2:s MoE-struktur, attention-layout och inbyggda 256K-konfiguration, och är inte validerat mot något annat mål. Det ärver samma 262 144-tokens kontext, så att köra det kostar dig ingenting i fönsterstorlek.

Att läsa modellkortet: vetbart, ännu inte bekräftat.

Repot ger dig en tydlig bild av vad modellen är, och en kort lista över saker som den inte berättar för dig.

Vetbart idag:

Det är en checkpoint som endast är avsedd för drafter och saknar fristående användning, laddad av vLLM tillsammans med A.X K2 genom spekulativ avkodning.

• Licensen är Apache 2.0; vikterna är fria att ladda ner och använda.

• Kontextlängden matchar A.X K2 vid 262 144 tokens.

• Den körs via SK Telecoms vLLM-gaffel (SKT-AI/vllm-repot, grenen axk2-v0.23.0) med flaggan --speculative-config.

• Metoden är dokumenterad i en artikel, "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv:2607.05147, inlämnad den 6 juli 2026) — den artikeln är också källan till de hastighetsökningssiffror som du kommer att se citerade.

• Ingen inferensleverantör driftsätter det idag, så det finns inget värdbaserat API att anropa.

Ännu inte bekräftat:

• Ett officiellt tillkännagivande — kortet lovar offentlig utgivning ”inom de närmaste dagarna.”

• Eventuella A.X K2-specifika snabbhetssiffror. Utvärdering pågår och varje prestandamått är TBD.

• Hur mycket det faktiskt hjälper under belastning, vilket kortet flaggar som "arbetsbelastningsberoende."

• Alla oberoende tredjepartsmätningar av utkastsmodellen.

Hur DSpark skiljer sig från vanlig spekulativ avkodning

Spekulativ avkodning är ett väl beprövat knep: en liten, snabb utkastmodell skriver en gissning för de nästa flera token, och den stora modellen kontrollerar hela gissningen i ett enda framåtriktat pass, och accepterar prefixet som överlever verifieringen innan den tar ett korrigerande steg. Gjort väl minskar det latensen dramatiskt utan kvalitetsförlust.

Poängen, som DSpark-papperet formulerar det, är att nyare parallella utkastare – vilka föreslår långa sekvenser i ett enda steg – lider av ”snabb acceptansförfall” eftersom de senare token i utkastet inte är beroende av de tidigare, så de avvisas mycket oftare. Och att blint verifiera långa block slösar batchkapacitet på token som sannolikt kommer att avvisas, vilket skadar genomströmningen precis i system med hög samtidighet.

DSpark angriper båda problemen:

• Semi-autoregressiv utkastgenerering. Den kopplar samman en parallell backbone med en lättviktig sekventiell modul och adderar modellering av beroenden inom blocket, så att senare utkast-tokens beror på tidigare — vilket är det som motverkar suffixförfall.

• Konfidensschemalagd verifiering. I stället för att verifiera en fast blocklängd anpassar den verifieringslängden per begäran, baserat på uppskattade sannolikheter för prefixöverlevnad och motorns genomströmningsprofil. Verifieringen blir lastmedveten.

Papperets siffror — och vad de inte berättar för dig

Här är siffran du kommer att se citerad: DSpark "påskyndar användarspecifika genereringshastigheter med 60 till 85 procent" vid matchade genomströmningsnivåer, jämfört med MTP-1-produktionsbaslinjen. Artikeln rapporterar också väsentligt förbättrad accepterad längd jämfört med toppmoderna autoregressiva och parallella drafters på offline-riktmärken, och säger att den förhindrar allvarlig genomströmningsförsämring under strikta interaktivitetsbegränsningar.

Läs det finstilta, eftersom det spelar roll för just den här jämförelsen: den där siffran på 60–85 % uppmättes i DeepSeek-V4:s tjänstesystem under live-användartrafik — inte på A.X K2. Det är ett påstående om DSpark-metoden som tillämpats på en annan modells stack. A.X K2 DSpark-kortet har däremot inget snabbningsnummer alls ännu. Den ärliga poängtavlan för den här kombinationen är därför: identisk utdata per konstruktion, och en snabbning som metodens artikel föreslår är rimlig, men som SK Telecom självt ännu inte har mätt på den modell som denna utkast-checkpoint byggdes för.

Vad det faktiskt kräver att köra det

Förutsättningen är den del som de flesta kommer att avskräckas av: du måste självhosta A.X K2. Det finns inget värdbaserat API för målmodellen — den är open-weight, och att servera en 688B/33B-aktiv MoE är ett seriöst infrastrukturåtagande. DSpark har bara betydelse för team som redan har gjort det åtagandet.

Om du har det, är marginalkostnaden för att lägga till draftmodellen liten:

• Ladda ner Apache 2.0-utkastcheckpointen och kör SK Telecoms vLLM-fork (grenen axk2-v0.23.0).

• Aktivera spekulativ avkodning via flaggan --speculative-config och peka den mot DSpark-kontrollpunkten.

• Budgetera extra minne för utkastvikterna, och acceptera att du nu befinner dig på en leverantörsfork av vLLM snarare än standardversionen — en underhållsaspekt.

• Kom ihåg artikelns eget förbehåll att verifiering inte är gratis: under hög samtidighet förbrukar slarvig verifiering batchkapacitet, vilket är exakt det felsätt som konfidensschemalagd verifiering är utformad för att hantera.

En ytterligare sak som är värd att känna till: Hugging Face rapporterar att nedladdningar "inte spåras för den här modellen", så det finns ingen offentlig signal om hur många team som faktiskt har testat den.

Vem ska välja vilken

Kör vanlig A.X K2 om något av detta stämmer in på dig:

• Du kör standard vLLM och vill inte ha en andra checkpoint eller en vendor-fork i sökvägen.

Dina arbetsbelastningar är begränsade av genomströmning men inte av latens, och användare tolererar att vänta på långa genereringar.

Du skulle hellre vänta på den officiella releasen och de första oberoende mätningarna.

Kör A.X K2 plus DSpark om detta är du:

• Du self-hostar A.X K2 och det som smärtar är genereringslatensen eller token-genomströmningen.

Långkontext- och agentiska arbetsbelastningar får användare att vänta på långa utdata — det scenario som spekulativ avkodning är byggd för.

Du är bekväm med att köra en förhandsannonseringskomponent vars nackdel är begränsad: i värsta fall hjälper den inte, och den kan inte ändra utdatakvaliteten.

Välj ingetdera om du inte själv-hostar en 688B MoE överhuvudtaget. A.X K2:s suveränitet och styrkor inom koreanska språket når dig bara om du kör den, och många team kommer istället att nå öppna frontier-modeller via en hostad katalog. Det är där det lönar sig att hålla din integration modellagnostisk: OrcaRouters enda OpenAI-kompatibla endpoint täcker 200+ modeller till leverantörens listpris med 0 % påslag, automatisk failover och en routing-DSL för att komponera flera modeller till ett enda anrop. (Varken A.X K2 eller A.X K2 DSpark är hostade någonstans idag — inklusive på OrcaRouter — så detta handlar om resten av din stack, inte om att routa detta par.) Förhållningssättet går ändå att överföra: testa en obeprövad modell på en bråkdel av trafiken och växla över automatiskt, istället för att satsa en produktionsväg på den.

Vad du ska titta på härnäst

Läget är enkelt: {{1}}repo:t är verkligt, metoden är dokumenterad, mätningarna är det inte{{/1}}. De tre sakerna att hålla koll på är {{2}}den utlovade offentliga releasen (kortet säger "inom de närmaste dagarna"){{/2}}, {{3}}de första A.X K2-specifika siffrorna för genomströmning eller latens när SK Telecoms utvärdering är klar{{/3}}, och {{4}}om någon inferensleverantör plockar upp paret — vilket är vad som skulle göra DSpark relevant för team som inte självhostar{{/4}}.

FAQ

Kan A.X K2 DSpark ersätta A.X K2?

Nej. Det är en drafter-only-checkpoint utan fristående användning — den finns till för att göra A.X K2-avkodning snabbare, inte som ett alternativ till den. Du kan inte köra A.X K2 DSpark utan A.X K2.

Ändrar DSpark A.X K2:s utdatakvalitet?

Nej, per konstruktion. Varje kandidattoken verifieras av A.X K2 innan det committeras, så utdatadistributionen är oförändrad — kortet beskriver metoden som förlustfri.

Behöver jag själv hosta A.X K2 för att använda DSpark?

Ja. DSpark laddas av vLLM tillsammans med A.X K2, så det finns inget för den att generera utkast till om du inte kör 688B-målet. Det finns inget hostat API för någon av modellerna idag.

Fungerar DSpark med andra modeller?

SK Telecom designade det för A.X K2:s MoE-arkitektur, uppmärksamhetsstruktur och 256K-kontext, och har inte validerat det mot något annat mål.

Domen

A.X K2 DSpark vs A.X K2 är en "versus" där det ärliga svaret är "båda". Om du redan kör A.X K2 och användare väntar på långa genereringar, är draftmodellen ett gratis experiment med låg risk: Apache 2.0-vikter, i värsta fall ingen hastighetsökning och ingen kvalitetsförsämring möjlig per konstruktion. Om du inte är latensbegränsad — eller inte självhostar en 688B MoE alls — kan du tryggt ignorera den tills SK Telecoms utvärderingssiffror landar och den utlovade offentliga releasen gör modellen officiell. Vad du inte bör göra är att missta artikelns 60–85 %-siffra för en mätning av denna modell: just nu är allt DSpark-specifikt med A.X K2 fortfarande TBD.