A.X K2 DSpark vs A.X K2: Wat een alleen-drafter-model je daadwerkelijk oplevert

Het vreemdste aan een A.X K2 DSpark versus A.X K2-vergelijking is dat het eigenlijk geen vergelijking is. A.X K2 DSpark kan niet worden gebruikt in plaats van A.X K2 — het kan helemaal niet zelfstandig worden gebruikt. Het is een "drafter-only checkpoint" dat SK Telecom begin augustus stilletjes op Hugging Face heeft gezet zonder aankondiging: een speculatief-decodering-draftmodel waarvan de enige taak is om A.X K2, het open-weight Mixture-of-Experts-vlaggenschip van het bedrijf met 688 miljard parameters, sneller tokens te laten genereren terwijl de antwoorden ongewijzigd blijven. De echte vraag waar het bij deze vergelijking om draait is dus niet "wat is beter?" Het is: "moet je A.X K2 met DSpark draaien, of zonder?" Alles in dit stuk is per bron gelabeld, want de kloof tussen wat de repository ons vertelt en wat er daadwerkelijk is gemeten, is het hele verhaal.

Wat A.X K2 DSpark eigenlijk is

De modelkaart van SK Telecom is ongewoon bot over waar het model voor dient. A.X K2 DSpark "is een DSpark-draftmodel voor speculatieve decodering voor A.X K2" en "een alleen-drafter-checkpoint: het heeft geen zelfstandig gebruik en is bedoeld om door vLLM samen met A.X K2 te worden geladen via speculatieve decodering." In de praktijk betekent dat dat je het downloadt, een compatibele vLLM op zowel dit model als op A.X K2 richt, en de twee werken als een team: DSpark stelt kandidaat-tokens voor, A.X K2 verifieert ze, en alleen geverifieerde tokens worden geproduceerd.

Twee details van het draftmechanisme zijn af te leiden uit de repo. Ten eerste stelt DSpark meerdere kandidaat-tokens parallel voor in plaats van een draftsequentie token voor token te schrijven, waarbij het gebruikmaakt van A.X K2's eigen verborgen representaties in combinatie met lichtgewicht lokale afhankelijkheidsmodellering. Ten tweede is het geheel ontworpen om verliesvrij te zijn: elke kandidaat wordt geverifieerd door het doelmodel voordat deze wordt vastgelegd, waardoor de outputverdeling van A.X K2 per constructie ongewijzigd blijft.

De release zelf is een {{1}}vooraankondiging{{/1}}. Op de kaart staat dat het model {{2}}"momenteel in de laatste validatiefase zit en gepland staat voor publieke release binnen de komende dagen"{{/2}}, en dat de evaluatie {{3}}"momenteel gaande is"{{/3}} — elke {{4}}throughput-, TPOT- en mean-accepted-length-metriek{{/4}} op de kaart wordt nog steeds vermeld als {{5}}TBD{{/5}}.

Waarom dit 'versus' eigenlijk 'met versus zonder' is

Omdat A.X K2 DSpark geen zelfstandig gebruik heeft, is er geen scenario waarin u het kiest in plaats van A.X K2. De keuze is tussen A.X K2 op zichzelf en A.X K2 met het draftmodel eraan gekoppeld. Wat betreft de uitvoerkwaliteit zijn de twee configuraties per constructie identiek; de enige as die kan verschuiven is de decodesnelheid.

Voor de goede orde, hier is wat A.X K2 is: een Mixture-of-Experts-decoder met in totaal 688B parameters, waarvan 33B actief, met 256 experts plus één gedeelde expert (8 actief per forward pass), 61 lagen, 64 aandachtskoppen en een vocabulaire van 163.840 tokens, uitgebracht met open gewichten onder Apache 2.0 op 29 juli. Het is voorgetraind op ongeveer 8,2 biljoen tokens native in MXFP8, gebruikt SK Telecoms Sparse Gated Attention voor efficiëntie bij lange contexten, en heeft een context van 262.144 tokens (native 128K uitgebreid naar 256K via YaRN). SK Telecom meldt dat het gemiddeld +32,2 procentpunten scoort ten opzichte van A.X K1 over 14 benchmarks, met lange-context- en agent-evaluaties tot ongeveer 83,9 punten hoger — allemaal door de leverancier gerapporteerd, zonder dat er nog een onafhankelijke samengestelde score is gepubliceerd.

DSpark is specifiek ontworpen voor die architectuur. De kaart zegt dat het is afgestemd op A.X K2's MoE-structuur, attention-layout en native 256K-configuratie, en is niet gevalideerd tegen enig ander doelwit. Het erft dezelfde context van 262.144 tokens, dus het gebruik ervan kost je niets op het gebied van venstergrootte.

Het lezen van de modelkaart: kenbaar, nog niet bevestigd.

De repo geeft je een duidelijk beeld van wat het model is, en een korte lijst van dingen die het je niet vertelt.

Vandaag kenbaar:

• Het is een checkpoint dat uitsluitend als drafter dient en geen zelfstandig gebruik heeft, geladen door vLLM naast A.X K2 via speculatieve decoding.

• De licentie is Apache 2.0; de gewichten zijn vrij te downloaden en te gebruiken.

• Contextlengte komt overeen met A.X K2 op 262.144 tokens.

Het draait via SK Telecom's vLLM-fork (de SKT-AI/vllm-repository, branch axk2-v0.23.0) met behulp van een --speculative-config-vlag.

De methode wordt beschreven in een paper, "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv:2607.05147, ingediend op 6 juli 2026) — dat paper is ook de bron van de versnellingscijfers die je geciteerd zult zien.

Geen enkele inferentieprovider implementeert het vandaag de dag, dus er is geen gehoste API om aan te roepen.

Nog niet bevestigd:

• Een officiële aankondiging — de kaart belooft een openbare release "binnen de komende dagen."

• {{1}}Elk A.X K2-specifiek versnellingscijfer.{{/1}} {{2}}De evaluatie is gaande en elke prestatiestatistiek is nog te bepalen.{{/2}}

• Hoeveel het daadwerkelijk helpt onder belasting, wat de kaart als 'afhankelijk van de werkbelasting' bestempelt.

• Elke onafhankelijke externe meting van het conceptmodel.

Hoe DSpark verschilt van gewone speculatieve decodering

Speculatieve decodering is een beproefde truc: een klein, snel conceptmodel schrijft een schatting voor de volgende paar tokens, en het grote model controleert de hele schatting in één enkele forward pass, waarbij het het prefix accepteert dat de verificatie doorstaat voordat het één corrigerende stap zet. Goed uitgevoerd vermindert dit de latentie dramatisch zonder kwaliteitsverlies.

De kneep, zoals het DSpark-paper het formuleert, is dat recente parallelle drafters — die in één keer lange reeksen voorstellen — last hebben van "snelle acceptatieverval" omdat de latere tokens in de draft geen afhankelijkheid hebben van de eerdere, waardoor ze veel vaker worden afgewezen. En het blindelings verifiëren van lange blokken verspilt batchcapaciteit aan tokens die waarschijnlijk worden afgewezen, wat de doorvoer juist in systemen met hoge gelijktijdigheid schaadt.

DSpark pakt beide problemen aan:

• Semi-autoregressieve drafting. Het koppelt een parallelle backbone aan een lichtgewicht sequentiële module, waardoor intra-blok afhankelijkheidsmodellering wordt toegevoegd, zodat latere draft-tokens afhangen van eerdere — wat suffixverval tegengaat.

• Vertrouwensgestuurde verificatie. In plaats van een vaste bloklengte te verifiëren, stemt het de verificatielengte per aanvraag af op basis van geschatte overlevingskansen van prefixen en het doorvoerprofiel van de engine. Verificatie wordt belastingbewust.

De cijfers van het artikel — en wat ze je niet vertellen

Hier is het getal dat u geciteerd zult zien: DSpark "versnelt de generatiesnelheden per gebruiker met 60 tot 85 procent" bij gelijke doorvoerniveaus, vergeleken met de MTP-1 productiebaseline. Het artikel rapporteert ook een aanzienlijk verbeterde geaccepteerde lengte ten opzichte van de modernste autoregressieve en parallelle drafters op offline benchmarks, en zegt dat het ernstige doorvoervermindering onder strikte interactiviteitsbeperkingen voorkomt.

Lees de kleine lettertjes, want die zijn belangrijk voor deze specifieke vergelijking: dat cijfer van 60–85% is gemeten in het servesysteem van DeepSeek-V4 onder live gebruikersverkeer — niet op de A.X K2. Het is een bewering over de DSpark-methode die is ingezet op de stack van een ander model. De A.X K2 DSpark-kaart heeft daarentegen nog helemaal geen versnellingscijfer. Het eerlijke scorebord voor deze combinatie is daarom: identieke output door constructie, en een versnelling die volgens het paper van de methode aannemelijk is, maar die SK Telecom zelf nog niet heeft gemeten op het model waarvoor dit concept-checkpoint is gebouwd.

Wat het runnen ervan eigenlijk vereist

De voorwaarde is het deel waar de meeste mensen afhaken: je moet A.X K2 zelf hosten. Er is geen gehoste API voor het doelmodel — het is open-weight, en het draaien van een 688B/33B-actieve MoE is een serieuze infrastructuurinvestering. DSpark is alleen relevant voor teams die die investering al hebben gedaan.

Als je die hebt, zijn de marginale kosten van het toevoegen van het draftmodel klein:

Download de Apache 2.0-conceptcheckpoint en voer SK Telecom's vLLM-fork uit (de axk2-v0.23.0-branch).

Activeer speculatieve decodering via de --speculative-config-vlag, en richt deze op de DSpark-checkpoint.

• Reserveer extra geheugen voor de draft-gewichten, en accepteer dat je nu op een vendor-fork van vLLM zit in plaats van de stockversie — een onderhoudsoverweging.

• Onthoud de eigen kanttekening van de paper dat verificatie niet gratis is: onder hoge concurrency vreet onzorgvuldige verificatie batchcapaciteit op, wat precies de faalmodus is die confidence-scheduled verificatie beoogt te beheren.

Nog iets dat de moeite waard is om te weten: Hugging Face meldt dat downloads 'niet worden bijgehouden voor dit model,' dus er is geen openbaar signaal voor hoeveel teams het daadwerkelijk hebben geprobeerd.

Wie moet welke kiezen

Voer de gewone A.X K2 uit als een van deze op u van toepassing is:

Je draait standaard vLLM en wilt geen tweede checkpoint of een vendor fork in het pad.

Je workloads zijn doorvoergebonden maar niet latentiegebonden, en gebruikers tolereren het wachten op lange generaties.

• Je wacht liever op de officiële release en de eerste onafhankelijke metingen.

Voer A.X K2 plus DSpark uit als dit jij bent:

• Je host A.X K2 zelf en de generatielatentie of token-doorvoer is waar het probleem zit.

• Langcontext- en agentische workloads laten gebruikers wachten op lange outputs — het regime waarvoor speculatieve decoding is gebouwd.

• Je vindt het prima om een vooraankondigingscomponent te draaien waarvan het nadeel beperkt is: in het slechtste geval helpt het niet, en het kan de kwaliteit van de uitvoer niet veranderen.

Kies geen van beide als je helemaal geen 688B MoE self-host. Van de soevereiniteit van A.X K2 en de sterke punten op het gebied van de Koreaanse taal profiteer je alleen als je het draait; veel teams zullen toonaangevende open modellen in plaats daarvan bereiken via een gehoste catalogus. Dat is waar het loont om je integratie model-agnostisch te houden: het ene OpenAI-compatibele endpoint van OrcaRouter bestrijkt 200+ modellen tegen de lijstprijs van de provider met 0% opslag, automatische failover en een routing-DSL om meerdere modellen in één aanroep te combineren. (Noch A.X K2, noch A.X K2 DSpark wordt vandaag ergens gehost — ook niet op OrcaRouter — dus dit gaat over de rest van je stack, niet over het routeren van dit paar.) De aanpak blijft van toepassing: probeer een onbewezen model op een deel van het verkeer en schakel automatisch over, in plaats van een productiepad ervan af te laten hangen.

Wat nu te kijken

De stand van zaken is simpel: de repo is echt, de methode is gedocumenteerd, de metingen niet. De drie dingen om in de gaten te houden zijn de beloofde openbare release (de kaart vermeldt 'binnen de komende dagen'), de eerste A.X K2-specifieke doorvoer- of latentiecijfers zodra de evaluatie van SK Telecom is afgerond, en of een inference-provider het paar oppikt — dat is wat DSpark relevant zou maken voor teams die niet zelf hosten.

Veelgestelde vragen

Kan A.X K2 DSpark A.X K2 vervangen?

Nee. Het is een checkpoint dat uitsluitend voor de drafter is bedoeld en geen zelfstandig gebruik heeft — het bestaat om A.X K2 sneller te laten decoderen, niet om er een alternatief voor te zijn. Je kunt A.X K2 DSpark niet uitvoeren zonder A.X K2.

Verandert DSpark de outputkwaliteit van de A.X K2?

Nee, door constructie. Elk kandidaat-token wordt geverifieerd door A.X K2 voordat het wordt vastgelegd, dus de outputverdeling blijft ongewijzigd — de kaart beschrijft de aanpak als verliesloos.

Moet ik A.X K2 zelf hosten om DSpark te gebruiken?

Ja. DSpark wordt door vLLM geladen naast A.X K2, dus er is niets voor om te draften, tenzij je het 688B-target draait. Er is vandaag geen gehoste API voor een van beide modellen.

Werkt DSpark met andere modellen?

SK Telecom heeft het ontworpen voor de MoE-architectuur, attention-structuur en 256K-context van A.X K2, en heeft het niet gevalideerd tegen enig ander doel.

Het vonnis

A.X K2 DSpark vs A.X K2 is een "versus" waarbij het eerlijke antwoord "allebei" is. Als je al A.X K2 draait en gebruikers wachten op lange generaties, is het draftmodel een gratis experiment met laag risico: Apache 2.0-gewichten, in het slechtste geval geen versnelling, en kwaliteitsvermindering is per definitie onmogelijk. Als je niet latency-gebonden bent — of helemaal geen 688B MoE zelf host — kun je het veilig negeren totdat de evaluatiecijfers van SK Telecom binnen zijn en de beloofde publieke release het model officieel maakt. Wat je niet moet doen, is het cijfer van 60–85% uit het paper aanzien voor een meting van dit model: op dit moment is alles DSpark-specifieks aan A.X K2 nog steeds TBD.