A.X-K2-DSpark: SK Telecoms spekulativa avkodningsutkastsmodell har anlänt utan förvarning

A.X-K2-DSpark är en modell som du förmodligen aldrig kommer att anropa direkt – och det är just därför den är värd att läsa om. SK Telecom publicerade den tyst på Hugging Face, utan lanseringsinlägg och utan pressmeddelande; modellkortet inleds helt enkelt med att checkpointen "för närvarande genomgår slutlig validering och är planerad för offentlig lansering inom de närmaste dagarna." Det är en drafter-only-checkpoint för spekulativ avkodning, byggd för en enda uppgift: att göra SK Telecoms flaggskeppsmodell A.X K2 med 688 miljarder parametrar snabbare och billigare att servera genom att föreslå tokens som A.X K2 sedan verifierar. Här är vad repot faktiskt berättar för oss, vad som fortfarande är obekräftat, och varför en liten hjälpmodell som denna är där nästa omgång av sänkta LLM-serveringskostnader gömmer sig.

Vad A.X-K2-DSpark faktiskt är

A.X-K2-DSpark är inte en fristående modell i någon meningsfull bemärkelse. Modellkortet anger detta i sina anteckningar om avsedd användning: den är en "checkpoint endast för utkast" med "ingen fristående användning", som laddas av vLLM tillsammans med sin målmodell, A.X K2, i en spekulativ avkodningsloop. Den är utkaststadiet i en tvåstegsgenerator — en liten modell föreslår kandidattoken snabbt, och målmodellen verifierar dem innan någon token fastställs som utdata.

Målet, som kontext, är en av de största modellerna med öppna vikter som finns. A.X K2 är SK Telecoms Mixture-of-Experts-modell med totalt 688B parametrar och 33B aktiva, släppt på Hugging Face i slutet av juli 2026 under Apache 2.0, byggd på en basarkitektur som kombinerar Multi-head Latent Attention med DeepSeek Sparse Attention och lägger till SK Telecoms egen Sparse Gate Attention-modifiering för långa kontexter. A.X-K2-DSpark baseras på A.X K2:s dolda tillstånd och lägger till lättviktsmodellering av lokala beroenden mellan kandidatpositioner, så att den kan föreslå flera tokens parallellt i stället för att skapa utkast strikt autoregressivt. Varje kandidat verifieras sedan av A.X K2 innan den antas – vilket är anledningen till att modellkortet kallar resultatet ”förlustfri per konstruktion”: utdatadistributionen påverkas inte av utkastmodellen; endast serveringshastigheten ändras.

Hur spekulativ avkodning fungerar, och varför en 688B MoE behöver den

Spekulativ avkodning finns eftersom autoregressiv generering är seriell och minnesbunden. Att generera varje token innebär att läsa modellens vikter från minnet, och för en 688B-modell är det ett enormt antal byte att flytta för varje enskild token – även när bara 33B parametrar är aktiva i varje framåtpass. Tricket är att lägga lite extra beräkningskraft på en liten draftmodell som gissar flera kommande token i ett svep, och sedan låta den stora modellen verifiera alla gissningar i ett enda framåtpass och behålla det längsta prefixet som matchar dess egen fördelning. När draftmodellen är bra får du två eller tre token per framåtpass av den stora modellen istället för ett, utan någon förändring av slutresultatet.

Hela spelet handlar om acceptansgraden. En drafter som gissar dåligt får sina förslag avvisade, och verifieringspasset kostar fortfarande samma minnesbandbredd, så hastighetsökningen försvinner. Det är därför drafters har blivit ett seriöst forskningsämne i sin egen rätt: för en modell i storleken av A.X K2 är skillnaden mellan en 1.5x och 3x hastighetsökning skillnaden mellan en serverflotta på tio GPU:er och en på fem. Effektivitetslager som detta är varifrån nästa runda av prissänkningar i värdbaserade LLM-API:er kommer — inte från basmodellens kvalitetssiffror, utan från servingstacken som omger dem.

DSpark är metoden — och den kommer från DeepSeek-teamet

”DSpark” i modellnamnet är en specifik teknik och inte en uppfinning av SK Telecom. Modellkortet citerar uppsatsen ”DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation” (arXiv 2607.05147), en preprint från 6 juli 2026 av ett team på 33 författare vid DeepSeek, som använde metoden i sitt eget serveringssystem från V4-eran under verklig trafik. SK Telecom har anpassat samma teknik till sin egen målmodell.

Artikelns två bidrag motsvarar direkt det som A.X-K2-DSpark-kortet beskriver. För det första: semi-autoregressiv utkastgenerering. En parallell ryggrad föreslår tokens över ett fönster medan en lättviktig sekventiell modul modellerar beroenden mellan kandidatpositionerna, vilket åtgärdar det klassiska problemet att parallella utkastares acceptansgrad sjunker kraftigt över den föreslagna sekvensen. För det andra: konfidensschemalagd verifiering. Istället för att alltid verifiera ett fast antal utkast-token uppskattar systemet sannolikheten att varje prefix överlever och ställer in verifieringslängden per begäran, anpassad till motorns genomströmningsprofil — så att verifieringsinsatsen är lastmedveten snarare än enhetlig.

Enligt papperets egna siffror — som är författarnas mätningar, inte oberoende verifierade — levererade DSpark 60–85 % snabbare generering per användare än produktionsbaslinjen MTP-1 vid matchad genomströmning, och förhindrade allvarlig genomströmningsförsämring under strikta interaktivitetsbegränsningar. Två förbehåll är viktiga för läsningen av detta pressmeddelande. Dessa resultat mättes på författarnas egen stack och mål, inte på A.X K2; och modellkortet för A.X-K2-DSpark anger uttryckligen att dess egen utvärdering fortfarande pågår. Papperet bevisar att metoden fungerar i produktion. Det bevisar inte att SK Telecoms checkpoint återskapar dessa vinster — det är just den obekräftade delen.

Vad repot säger — och vad det inte säger.

Här är vad som går att få reda på från repot just nu, allt från modellkortet:

• Roll — checkpoint endast för drafter för A.X K2; ingen fristående användning; inte validerad med något annat mål och "inkompatibel med orelaterade modeller."

• Target — A.X K2, 688B totalt / 33B aktiva Mixture-of-Experts.

• Kontextlängd — 262 144 tokens (256K), matchar A.X K2:s ursprungliga konfiguration.

• Licens — Apache 2.0.

• Mekanism — DSpark semi-autoregressiv drafting; varje kandidat verifieras av A.X K2 innan commit (förlustfritt).

• Status — "för närvarande i slutlig validering"; lansering planerad "inom de närmaste dagarna."

Och här är det som uttryckligen ännu inte bekräftats:

• Checkpointens precision och storlek — båda listade som TBD på modellkortet.

• Genomströmning, TPOT och genomsnittlig accepterad längd — de tre siffrorna som skulle tala om för dig om skribenten faktiskt fungerar, alla TBD, med "utvärdering pågår för närvarande."

• Resultat per domän — kortet lovar uppdelningar för koreanska, matematik, naturvetenskap och kod "senare", utan datum.

• Ett formellt tillkännagivande — SK Telecom har inte tillkännagett A.X-K2-DSpark någonstans som vi kan hitta; repositoryt är tillkännagivandet.

• Oberoende betyg — det finns inga. Allt på kortet är SK Telecoms egna påståenden, och det mesta är fortfarande ett löfte.

Den viktigaste obekräftade siffran är medelvärdet för accepterad längd — det genomsnittliga antalet draft-tokens som A.X K2 accepterar per verifieringspass. Just den siffran avgör om denna drafter är en 1.2x bagatell eller en 2.5x serveringsuppgradering, och det är också den siffra som mest sannolikt kommer att cirkulera utan källhänvisning när releasen går live. Var skeptisk mot den när den dyker upp: DSpark-artikelns siffra på 60–85 % mättes på en annan modells serving-stack, och A.X K2 har sina egna egenskaper för draft-acceptans.

Hur du faktiskt skulle köra det

Att köra draftern innebär att servera A.X K2 från SK Telecoms fork av vLLM. Modellkortets exempel, lätt trimmat, är:

vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'

med forken installerad från SKT-AI vLLM-repot på grenen axk2-v0.23.0. Några varningar som kortet är tydliga med: installationen riktar in sig på A.X K2:s inbyggda 256K-kontextkonfiguration, och hastighetsökningen är arbetsbelastningsberoende — samtidighet, utdatalängd, acceptansgrad och den relativa kostnaden för att skapa utkast jämfört med verifiering påverkar alla resultatet. Med andra ord är detta serveringsinfrastruktur, inte ett ladda-ner-och-kör-skript. Du behöver A.X K2:s vikter, ett kluster som är tillräckligt stort för tensor-parallell 8, och tålamod att ställa in num_speculative_tokens mot din egen trafik. Det är ett meningsfullt projekt för ett team som redan serverar A.X K2; det är inte en anledning att sätta upp en.

Ekonomin: effektivitetslager slår kvalitetspåståenden

Anledningen till att en draftmodell för en 688B-modell är värd att hålla koll på är att benchmarkkapplöpningen för basmodeller till stor del har mättats, medan kapplöpningen om serveringskostnad inte har det. SK Telecoms egen lansering lutade sig redan mot effektivitet — Sparse Gate Attention-förändringen påstods öka den totala token-genomströmningen med 67,7 % jämfört med föregående generation vid 120K-token-indata — och en draftmodell är samma tes tillämpad på avkodning. Varje accepterad draft-token är ett framåtpass i den stora modellen som du inte betalade för.

För den som konsumerar dessa modeller via ett API i stället för att driva dem själv, är draftern osynlig — och det är just poängen. När en leverantör lägger till spekulativ avkodning i sin serveringsstack ser du ingen ny modell; du ser samma modell bli snabbare och billigare per token. Prissättningslagret är viktigt av samma anledning: hos OrcaRouter för vi vidare leverantörens listpris rakt av med 0 % påslag, så när en leverantörs arbete med serveringseffektivitet tar sig uttryck i en prissänkning, är den live hos oss samma dag — ingen omförhandling, ingen kontraktsförändring. Och för en oprövad modell som kanske inte alls håller måttet, är routing med automatisk failover sättet att prova den utan att basera en produktionssatsning på den: en API-nyckel, och begäran överförs automatiskt till en annan leverantör om den första försämras.

En ärlighetsnotis specifik för denna release: A.X-K2-DSpark är enbart en drafter-checkpoint, så det är inget som något hostat modell-API kan dirigera – inte ens vårt. Drafters är en serverkomponent, inte en anropsbar produkt. När draftern släpps och utvärderingssiffrorna landar, är det som dyker upp i en prislista en snabbare, billigare A.X K2 – inte en ny endpoint som heter "DSpark."

Några frågor värda att besvara

Kan jag använda A.X-K2-DSpark på egen hand? Nej — det är den avgörande faktorn för releasen. Den är en checkpoint som enbart fungerar som drafter, utan fristående användning och utan offentligt API; den existerar endast som en hjälpkomponent i en vLLM spekulativ-avkodningsloop som serverar A.X K2, och kortet anger att den inte har validerats mot något annat mål.

Är A.X-K2-DSpark en konkurrent till A.X K2?Tvärtom. Det är en accelerator för A.X K2 — samma modell blir snabbare, med oförändrad utdatadistribution. Se det som en påbyggnadsdel för effektivitet, inte en ny produkt i sortimentet.

När kommer den faktiskt att släppas? Modellkortet säger att den är i slutlig validering och planerad för offentlig release "inom de närmaste dagarna." Det är allt som är bekräftat. Datumet att hålla koll på är dagen då TBD-siffrorna — genomströmning, TPOT och genomsnittlig accepterad längd — fylls i, för då slutar releasen att vara ett löfte och blir något du kan utvärdera.

Behöver jag tänka på det om jag använder A.X K2 via ett API? Förmodligen inte direkt. Servingstacken bakom ett API avgör om en drafter är med i loopen; du ser resultatet som ett pris och en latens, inte en flagga. Det är viktigast för team som själva hostar A.X K2, där att välja in är en vLLM-konfigurationsändring som de kontrollerar.

Historien här är inte själva draftaren — det är vad draftaren signalerar. Effektivitetsarbete håller på att bli en egen releaseskategori i tysthet, och de mest intressanta nya modellerna i år är i allt högre grad hjälpare som gör stora modeller billiga, inte större modeller. A.X-K2-DSpark är det tydligaste exemplet hittills: en checkpoint utan fristående användning, publicerad innan tillkännagivandet, med större delen av sin egen evidens som TBD. Håll utkik efter siffran för accepterad längd när den dyker upp, behandla vinsterna i DSpark-artikeln som ursprung för metoden snarare än som ett löfte för den här checkpointen, och om du servar A.X K2 själv, budgetera för benchmarken — det är enda sättet att veta om den tyst publicerade draftaren är en 1,2x-finess eller den äkta varan.