A.X-K2-DSpark: SK Telecoms speculatief-decodering conceptmodel is onaangekondigd gearriveerd

A.X-K2-DSpark is een model dat je waarschijnlijk nooit rechtstreeks zult aanroepen — en dat is precies waarom het de moeite waard is om erover te lezen. SK Telecom plaatste het stilletjes op Hugging Face, zonder aankondigingspost en zonder persbericht; de modelkaart opent simpelweg met de mededeling dat het checkpoint "momenteel in de laatste validatiefase is en naar verwachting binnen enkele dagen openbaar wordt uitgebracht." Het is een checkpoint dat uitsluitend als conceptmodel dient voor speculatieve decodering, gebouwd voor één taak: het sneller en goedkoper maken van SK Telecoms vlaggenschip A.X K2 met 688B parameters, door tokens voor te stellen die A.X K2 vervolgens verifieert. Dit is wat de repository ons daadwerkelijk vertelt, wat nog onbevestigd is, en waarom een klein hulpmodel als dit de plek is waar de volgende ronde kostenbesparingen voor LLM-serving zich schuilhoudt.

Wat A.X-K2-DSpark eigenlijk is

A.X-K2-DSpark is in geen enkele betekenisvolle zin een zelfstandig model. De modelkaart zegt dit in de aantekeningen over het beoogde gebruik: het is een "checkpoint dat alleen als ontwerper dient" met "geen zelfstandig gebruik", en wordt door vLLM samen met zijn doelmodel A.X K2 geladen in een speculatieve-decoderinglus. Het is de ontwerpstap van een tweetrapsgenerator — een klein model stelt snel kandidaat-tokens voor, en het doelmodel verifieert ze voordat er een token aan de uitvoer wordt toegevoegd.

Het gaat hier, ter context, om een van de grootste open-weight-modellen ter wereld. A.X K2 is SK Telecoms Mixture-of-Experts-model met in totaal 688B parameters, waarvan 33B actief, uitgebracht op Hugging Face eind juli 2026 onder Apache 2.0, gebouwd op een basisarchitectuur die Multi-head Latent Attention combineert met DeepSeek Sparse Attention en waaraan SK Telecoms eigen Sparse Gate Attention-modificatie voor lange contexten is toegevoegd. A.X-K2-DSpark is geconditioneerd op de hidden states van A.X K2 en voegt lichtgewicht lokale afhankelijkheidsmodellering toe tussen kandidaatposities, zodat het meerdere tokens parallel kan voorstellen in plaats van strikt autoregressief te draften. Elke kandidaat wordt vervolgens door A.X K2 geverifieerd voordat hij wordt vastgelegd — daarom noemt de modelkaart het resultaat 'lossless by construction': de outputverdeling blijft ongewijzigd door de drafter; alleen de serveersnelheid verandert.

Hoe speculatieve decodering werkt, en waarom een 688B MoE het nodig heeft

Speculatieve decodering bestaat omdat autoregressieve generatie serieel en geheugengebonden is. Het genereren van elk token betekent dat de gewichten van het model uit het geheugen worden gelezen, en voor een 688B-model is dat een enorm aantal bytes dat voor elk afzonderlijk token moet worden verplaatst — zelfs wanneer er in elke forward pass slechts 33B parameters actief zijn. De truc is om een beetje extra rekenkracht te besteden aan een kleine drafter die de volgende paar tokens in één keer raadt, en vervolgens het grote model alle gissingen in één enkele forward pass te laten verifiëren en het langste voorvoegsel te behouden dat overeenkomt met zijn eigen distributie. Wanneer de drafter goed is, krijg je twee of drie tokens per grote-model-pass in plaats van één, zonder dat de uiteindelijke output verandert.

Het hele spel draait om de acceptatiegraad. Een drafter die slecht raadt, krijgt zijn voorstellen afgewezen, en de verificatiepass kost nog steeds dezelfde geheugenbandbreedte, dus de versnelling verdampt. Daarom zijn drafters op zichzelf een serieus onderzoeksthema geworden: voor een model ter grootte van A.X K2 is het verschil tussen een 1,5x en een 3x versnelling het verschil tussen een servingvloot van tien GPU's en een van vijf. Efficiëntielagen als deze zijn waar de volgende ronde prijsverlagingen in gehoste LLM-API's vandaan zal komen — niet van de kwaliteitscijfers van basismodellen, maar van de servingstack eromheen.

DSpark is de methode — en die komt van het DeepSeek-team

De "DSpark" in de modelnaam is een specifieke techniek en is geen uitvinding van SK Telecom. De modelkaart citeert het paper "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv 2607.05147), een preprint van 6 juli 2026 van een team van 33 auteurs bij DeepSeek die de methode in het eigen V4-tijdperk-serveersysteem van de auteurs onder live verkeer implementeerden. SK Telecom heeft dezelfde techniek aangepast voor zijn eigen doelmodel.

De twee bijdragen van het artikel corresponderen direct met wat de A.X-K2-DSpark-kaart beschrijft. Ten eerste, semi-autoregressieve conceptgeneratie: een parallelle backbone stelt tokens voor over een venster, terwijl een lichtgewicht sequentiële module de afhankelijkheden tussen de kandidaatposities modelleert. Dit lost het klassieke probleem op dat de acceptatiepercentages van parallelle conceptgeneratoren sterk afnemen over de voorgestelde reeks. Ten tweede, op vertrouwen geplande verificatie: in plaats van altijd een vast aantal concepttokens te verifiëren, schat het systeem de kans dat elk voorvoegsel overleeft en stelt het de verificatielengte per verzoek in, afgestemd op het doorvoerprofiel van de engine — zodat de verificatie-inspanning belastingbewust is in plaats van uniform.

Op basis van de eigen cijfers van het paper — die metingen van de auteurs zijn en niet onafhankelijk zijn geverifieerd — leverde DSpark een 60–85% snellere generatie per gebruiker dan de productie-MTP-1-basislijn bij gelijke doorvoer, en voorkwam het ernstige doorvoervermindering onder strikte interactiviteitsbeperkingen. Twee kanttekeningen zijn belangrijk bij het lezen van deze release. Die resultaten zijn gemeten op de eigen stack en het eigen doel van de auteurs, niet op A.X K2; en de modelkaart van A.X-K2-DSpark zegt expliciet dat de eigen evaluatie nog gaande is. Het paper bewijst dat de methode in productie werkt. Het bewijst niet dat de checkpoint van SK Telecom die winsten reproduceert — dat is precies het onbevestigde deel.

Wat de repo zegt — en wat het niet zegt

Hier is wat er op dit moment uit de repository te weten valt, allemaal van de modelkaart:

• Rol — checkpoint dat uitsluitend als drafter dient voor A.X K2; geen zelfstandig gebruik; niet gevalideerd met enig ander doelwit en "incompatibel met ongerelateerde modellen."

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

• Contextlengte — 262.144 tokens (256K), overeenkomend met de native configuratie van A.X K2.

• Licentie — Apache 2.0.

• Mechanisme — DSpark semi-autoregressieve drafting; elke kandidaat geverifieerd door A.X K2 vóór commit (verliesvrij).

• Status — "momenteel in de eindvalidatie"; release gepland "binnen de komende dagen."

En hier is wat nog niet expliciet is bevestigd:

• Checkpoint-precisie en -grootte — beide vermeld als TBD op de modelkaart.

• Throughput, TPOT en gemiddelde geaccepteerde lengte — de drie getallen die je zouden vertellen of de opsteller daadwerkelijk werkt, allemaal TBD, met "evaluatie is momenteel bezig."

• Resultaten per domein — de kaart belooft uitsplitsingen voor Koreaans, wiskunde, wetenschap en code 'later', zonder datum.

• Een formele aankondiging — SK Telecom heeft A.X-K2-DSpark nergens aangekondigd voor zover wij kunnen vinden; de repository is de aankondiging.

• Onafhankelijke scores — die bestaan niet. Alles op de kaart is een eigen bewering van SK Telecom, en het grootste deel ervan is nog steeds een belofte.

Het belangrijkste onbevestigde getal is de gemiddelde geaccepteerde lengte — het gemiddelde aantal draft-tokens dat A.X K2 per verificatiepass accepteert. Dat ene getal bepaalt of deze drafter een aardigheidje van 1,2x is of een serving-upgrade van 2,5x, en het is ook het getal dat het meest zonder herkomst zal circuleren zodra de release live gaat. Wees sceptisch wanneer het opduikt: het cijfer van 60–85% uit het DSpark-paper werd gemeten op de serving-stack van een ander model, en A.X K2 heeft zijn eigen draft-acceptatiekenmerken.

Hoe je het daadwerkelijk zou uitvoeren

De drafter draaien betekent dat je A.X K2 serveert vanuit de vLLM-fork van SK Telecom. Het voorbeeld van de modelkaart, licht ingekort, is:

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}'

met de fork die vanuit de SKT-AI vLLM-repository op de axk2-v0.23.0-branch is geïnstalleerd. Een paar kanttekeningen waar de kaart open over is: de opzet richt zich op de native 256K-contextconfiguratie van A.X K2, en de versnelling is workloadafhankelijk — gelijktijdigheid, uitvoerlengte, acceptatiegraad en de relatieve kosten van het opstellen versus het verifiëren beïnvloeden allemaal het resultaat. Met andere woorden, dit is serverinfrastructuur, geen download-en-run-script. Je hebt de gewichten van A.X K2 nodig, een cluster dat groot genoeg is voor tensor-parallel 8, en het geduld voor het afstemmen vannum_speculative_tokens op je eigen verkeer. Dat is een zinvol project voor een team dat A.X K2 al serveert; het is geen reden om er een op te zetten.

De economie: efficiëntielagen verslaan kwaliteitsclaims.

De reden waarom een draftmodel voor een 688B-model het volgen waard is, is dat de benchmark-race voor basismodellen grotendeels is verzadigd, en de race op het gebied van serving-kosten nog niet. SK Telecom's eigen lancering leunde al op efficiëntie — de Sparse Gate Attention-wijziging zou de totale token-doorvoer met 67,7% hebben verhoogd ten opzichte van de vorige generatie bij invoer van 120K tokens — en een drafter is dezelfde visie toegepast op decode. Elk geaccepteerd draft-token is een forward pass van het grote model waar je niet voor betaalt.

Voor iedereen die deze modellen via een API consumeert in plaats van ze te hosten, {{1}}is de drafter onzichtbaar — en dat is precies de bedoeling{{/1}}. Wanneer een provider speculatieve decodering aan zijn serving-stack toevoegt, zie je geen nieuw model; je ziet hetzelfde model sneller en goedkoper per token worden. De prijslaag is om dezelfde reden belangrijk: {{2}}bij OrcaRouter geven we de catalogusprijs van de provider rechtstreeks door met 0% opslag{{/2}}, dus wanneer de serving-efficiëntieverbeteringen van een leverancier zich vertalen in een prijsverlaging, is dat dezelfde dag live aan onze kant — geen heronderhandeling, geen contractwijziging. En voor een onbewezen model dat wel of niet kan uitpakken, {{3}}is routering met automatische failover de manier om het uit te proberen zonder er een productiepad op te verwedden{{/3}}: één API-sleutel, en het verzoek valt over naar een andere provider als de eerste verslechtert.

Een eerlijkheidsopmerking specifiek voor deze release: A.X-K2-DSpark is een drafter-only checkpoint, dus het is niet iets waar een gehoste model-API naar kan routeren — ook de onze niet. Drafters zijn een server-side component, geen aanroepbaar product. Wanneer de drafter uitkomt en de eval-cijfers binnenkomen, zal wat er in een prijslijst verschijnt een snellere, goedkopere A.X K2 zijn — geen nieuwe endpoint genaamd "DSpark."

Een paar vragen die het waard zijn om te beantwoorden

Kan ik A.X-K2-DSpark op zichzelf gebruiken? Nee — dat is het bepalende feit van de release. Het is een checkpoint dat uitsluitend als drafter fungeert, zonder zelfstandig gebruik en zonder publieke API; het bestaat alleen als helper binnen een vLLM-speculatieve-decoderinglus die A.X K2 serveert, en de modelcard vermeldt dat het niet met enige andere target is gevalideerd.

Is A.X-K2-DSpark een concurrent van A.X K2? Het tegenovergestelde. Het is een versneller voor A.X K2 — hetzelfde model wordt sneller, met een ongewijzigde outputverdeling. Zie het als een aanbouwpakket dat de efficiëntie verhoogt, niet als een nieuw model in de line-up.

Wanneer wordt het eigenlijk uitgebracht? De modelkaart zegt dat het in de laatste validatie zit en gepland is voor openbare release "binnen de komende dagen." Dat is alles wat bevestigd is. De datum om in de gaten te houden is de dag waarop de TBD-cijfers — throughput, TPOT en gemiddelde geaccepteerde lengte — worden ingevuld, want dan houdt de release op een belofte te zijn en wordt het iets dat je kunt evalueren.

Moet ik erover nadenken als ik A.X K2 via een API gebruik?Waarschijnlijk niet direct. De serving-stack achter een API bepaalt of er een drafter betrokken is; je ziet het resultaat als een prijs en een latentie, niet als een vlag. Het is vooral relevant voor teams die A.X K2 zelf hosten, waarbij opt-in een vLLM-configuratiewijziging is die zij beheren.

Het verhaal hier gaat niet over de drafter zelf — het gaat over wat de drafter signaleert. Efficiëntiewerk wordt stilletjes een eigen releasecategorie, en de interessantste nieuwe modellen van dit jaar zijn steeds vaker helpers die grote modellen goedkoop maken, niet grotere modellen. A.X-K2-DSpark is tot nu toe het duidelijkste voorbeeld: een checkpoint zonder zelfstandig gebruik, vóór de aankondiging geplaatst, met het grootste deel van het eigen bewijs nog als TBD. Let op de accepted-length-waarde wanneer die bekend wordt, behandel de resultaten uit het DSpark-artikel als herkomstbewijs voor de methode in plaats van als belofte voor dit checkpoint, en als je A.X K2 zelf serveert, reserveer dan budget voor de benchmark — dat is de enige manier om te weten of de stilletjes geplaatste drafter een aardige 1,2x-winst is of het echte werk.