A.X-K2-DSpark: SK Telecoms Speculative-Decoding-Draftmodell ist unangekündigt erschienen

A.X-K2-DSpark ist ein Modell, das Sie wahrscheinlich nie direkt aufrufen werden — und genau deshalb lohnt es sich, darüber zu lesen. SK Telecom hat es still und leise auf Hugging Face veröffentlicht, ohne Launch-Post und ohne Pressemitteilung dahinter; die Modellkarte beginnt einfach mit der Aussage, dass der Checkpoint „derzeit in der finalen Validierung ist und für die öffentliche Veröffentlichung innerhalb der nächsten Tage geplant ist." Es ist ein reiner Drafter-Checkpoint für spekulative Dekodierung, gebaut für eine einzige Aufgabe: SK Telecoms 688B-Parameter-Flaggschiff A.X K2 schneller und kostengünstiger zu bedienen, indem es Tokens vorschlägt, die A.X K2 dann verifiziert. Hier ist, was das Repository tatsächlich verrät, was noch unbestätigt ist und warum ein kleines Hilfsmodell wie dieses der Ort ist, an dem sich die nächste Runde der Kostensenkungen beim LLM-Serving versteckt.

Was A.X-K2-DSpark eigentlich ist

A.X-K2-DSpark ist in keinem sinnvollen Sinne ein eigenständiges Modell. Die Modellkarte sagt dies in ihren Hinweisen zur beabsichtigten Verwendung: Es handelt sich um einen „Nur-Entwurf-Checkpoint“ ohne „eigenständige Verwendung“, der von vLLM zusammen mit seinem Zielmodell A.X K2 innerhalb einer spekulativen Dekodierungsschleife geladen wird. Es ist die Entwurfsstufe eines zweistufigen Generators – ein kleines Modell schlägt schnell Kandidaten-Token vor, und das Zielmodell verifiziert sie, bevor ein Token an die Ausgabe übergeben wird.

Das Ziel ist, zur Einordnung, eines der größten Open-Weight-Modelle überhaupt. A.X K2 ist SK Telecoms Mixture-of-Experts-Modell mit 688B Gesamtparametern und 33B aktiven Parametern, das Ende Juli 2026 unter Apache 2.0 auf Hugging Face veröffentlicht wurde. Es basiert auf einer Basisarchitektur, die Multi-head Latent Attention mit DeepSeek Sparse Attention kombiniert und SK Telecoms eigene Sparse Gate Attention als Long-Context-Modifikation hinzufügt. A.X-K2-DSpark basiert auf den Hidden States von A.X K2 und fügt eine leichtgewichtige lokale Abhängigkeitsmodellierung zwischen Kandidatenpositionen hinzu, sodass es mehrere Tokens parallel vorschlagen kann, anstatt streng autoregressiv zu arbeiten. Jeder Kandidat wird dann von A.X K2 verifiziert, bevor er übernommen wird – weshalb die Modellkarte das Ergebnis als „lossless by construction“ bezeichnet: Die Ausgabeverteilung bleibt durch den Entwurfsmechanismus unverändert; nur die Serving-Geschwindigkeit ändert sich.

Wie spekulative Dekodierung funktioniert und warum ein 688B-MoE sie benötigt

Spekulative Dekodierung existiert, weil autoregressive Generierung seriell und speichergebunden ist. Das Erzeugen jedes Tokens bedeutet, das die Gewichte des Modells aus dem Speicher gelesen werden, und bei einem 688B-Modell ist das eine enorme Anzahl von Bytes, die für jedes einzelne Token bewegt werden müssen – selbst wenn nur 33B Parameter in jedem Vorwärtsdurchlauf aktiv sind. Der Trick besteht darin, ein wenig zusätzliche Rechenleistung für einen kleinen Drafter aufzuwenden, der die nächsten mehreren Tokens auf einmal errät, und dann das große Modell alle Vermutungen in einem einzigen Vorwärtsdurchlauf überprüfen zu lassen und das längste Präfix beizubehalten, das seiner eigenen Verteilung entspricht. Wenn der Drafter gut ist, erhält man zwei oder drei Tokens pro Durchlauf des großen Modells statt einem, ohne Änderung am endgültigen Output.

Das gesamte Spiel dreht sich um die Akzeptanzrate. Ein Drafter, der schlecht rät, bekommt seine Vorschläge abgelehnt, und der Verifikationsdurchlauf kostet trotzdem dieselbe Speicherbandbreite, sodass der Geschwindigkeitsvorteil verpufft. Deshalb sind Drafter zu einem eigenen ernsthaften Forschungsthema geworden: Bei einem Modell der Größe von A.X K2 ist der Unterschied zwischen einer 1,5-fachen und einer 3-fachen Beschleunigung der Unterschied zwischen einer Serving-Flotte von zehn GPUs und einer von fünf. Effizienzschichten wie diese sind es, aus denen die nächste Runde von Preissenkungen bei gehosteten LLM-APIs kommen wird – nicht aus den Qualitätszahlen der Basismodelle, sondern aus dem Serving-Stack, der um sie herum aufgebaut ist.

DSpark ist die Methode — und sie kommt vom DeepSeek-Team.

„DSpark“ im Modellnamen ist eine spezifische Technik und keine Erfindung von SK Telecom. Die Modellkarte zitiert das Paper „DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation“ (arXiv 2607.05147), einen Preprint vom 6. Juli 2026 eines 33-köpfigen Autorenteams bei DeepSeek, das die Methode in seinem eigenen V4-Serving-System unter Live-Datenverkehr einsetzte. SK Telecom hat dieselbe Technik an sein eigenes Zielmodell angepasst.

Die zwei Beiträge des Papers entsprechen direkt dem, was die A.X-K2-DSpark-Karte beschreibt. Erstens: semi-autoregressives Drafting – ein paralleles Rückgrat schlägt Token über ein Fenster hinweg vor, während ein leichtgewichtiges sequenzielles Modul die Abhängigkeiten zwischen den Kandidatenpositionen modelliert und damit das klassische Problem behebt, dass die Akzeptanzraten paralleler Drafting-Ansätze über die vorgeschlagene Sequenz hinweg stark abfallen. Zweitens: konfidenzgesteuerte Verifikation – anstatt immer eine feste Anzahl von Draft-Tokens zu verifizieren, schätzt das System die Wahrscheinlichkeit, dass jedes Präfix überlebt, und legt die Verifikationslänge pro Anfrage fest, abgestimmt auf das Durchsatzprofil der Engine – sodass der Verifikationsaufwand lastabhängig und nicht einheitlich ist.

Nach den eigenen Zahlen des Papers — also den nicht unabhängig verifizierten Messungen der Autoren — lieferte DSpark {{1}}eine um 60–85 % schnellere Generierung pro Nutzer als die Produktions-MTP-1-Baseline bei gleichem Durchsatz{{/1}} und verhinderte schwere Durchsatzeinbußen unter strengen Interaktivitätsbeschränkungen. Zwei Einschränkungen sind beim Lesen dieser Meldung zu beachten. Diese Ergebnisse wurden auf dem eigenen Stack und Zielsystem der Autoren gemessen, nicht auf A.X K2; und die Model Card des A.X-K2-DSpark weist ausdrücklich darauf hin, dass dessen eigene Evaluierung noch im Gange ist. Das Paper belegt, dass die Methode in der Produktion funktioniert. Es belegt nicht, dass der Checkpoint von SK Telecom diese Leistungssteigerungen reproduziert — genau das ist der unbestätigte Teil.

Was das Repo sagt — und was es nicht sagt.

Hier ist, was derzeit aus dem Repository bekannt ist – alles aus der Modellkarte:

• Rolle — reiner Entwurfs-Checkpoint für A.X K2; keine eigenständige Verwendung; nicht mit anderen Zielen validiert und „inkompatibel mit nicht verwandten Modellen".

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

• Kontextlänge — 262,144 Token (256K), entsprechend der nativen Konfiguration des A.X K2.

• Lizenz — Apache 2.0.

• Mechanismus — DSpark semi-autoregressives Drafting; jeder Kandidat wird von A.X K2 vor dem Commit verifiziert (verlustfrei).

• Status — "derzeit in der finalen Validierung"; Veröffentlichung geplant "in den nächsten Tagen."

Und hier ist, was explizit noch nicht bestätigt ist:

• Präzision und Größe des Checkpoints — beide auf der Modellkarte als TBD aufgeführt.

• Durchsatz, TPOT und mittlere akzeptierte Länge — die drei Zahlen, die dir sagen würden, ob der Verfasser tatsächlich arbeitet, alle TBD, mit „die Evaluation ist derzeit im Gange."

• Ergebnisse pro Domäne — die Karte verspricht Aufschlüsselungen für Koreanisch, Mathe, Naturwissenschaften und Code „später“, ohne ein Datum zu nennen.

• Eine formelle AnkündigungSK Telecom hat A.X-K2-DSpark nirgendwo angekündigt, soweit wir feststellen können; das Repository ist die Ankündigung.

• Unabhängige Bewertungen — solche gibt es nicht. Alles auf der Karte ist SK Telecoms eigene Behauptung, und das meiste davon ist noch immer ein Versprechen.

Die wichtigste unbestätigte Kennzahl ist {{1}}die mittlere akzeptierte Länge{{/1}} — {{2}}die durchschnittliche Anzahl an Draft-Tokens, die A.X K2 pro Verifikationsdurchlauf akzeptiert{{/2}}. Allein diese Zahl entscheidet, ob dieser Drafter ein {{3}}1,2-faches Nice-to-have{{/3}} oder ein {{4}}2,5-faches Serving-Upgrade{{/4}} ist, und sie ist zugleich die Zahl, die am wahrscheinlichsten ohne Herkunftsangabe kursieren wird, sobald das Release live geht. Begegnen Sie ihr mit Skepsis, wenn sie auftaucht: Die {{5}}60–85-%-Angabe{{/5}} des DSpark-Papers wurde am Serving-Stack eines anderen Modells gemessen, und A.X K2 hat seine eigenen Draft-Akzeptanz-Merkmale.

Wie du es tatsächlich ausführen würdest

Den Drafter auszuführen bedeutet, A.X K2 aus SK Telecoms Fork von vLLM zu serven. Das Beispiel der Modellkarte, leicht gekürzt, lautet:

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

Mit dem Fork aus dem SKT-AI-vLLM-Repository, der auf dem axk2-v0.23.0-Branch installiert wurde. Einige Vorbehalte, die die Karte offen anspricht: Das Setup zielt auf die native 256K-Kontextkonfiguration des A.X K2 ab, und die Beschleunigung ist arbeitslastabhängig – Parallelität, Ausgabelänge, Akzeptanzrate und die relativen Kosten von Drafting gegenüber Verifikation beeinflussen alle das Ergebnis. Mit anderen Worten, das ist Serving-Infrastruktur, kein Download-and-Run-Skript. Sie benötigen die Gewichte des A.X K2, einen Cluster, der groß genug für Tensor-Parallel-8 ist, und die Geduld, num_speculative_tokens gegen Ihren eigenen Datenverkehr zu tunen. Das ist ein bedeutendes Projekt für ein Team, das A.X K2 bereits betreibt; es ist kein Grund, eines aufzubauen.

Die Ökonomie: Effizienzschichten schlagen Qualitätsversprechen.

Der Grund, warum ein Draft-Modell für ein 688B-Modell Beachtung verdient, ist, dass das Benchmark-Rennen der Basismodelle weitgehend gesättigt ist, das Rennen um die Serving-Kosten jedoch nicht. SK Telecoms eigener Launch setzte bereits auf Effizienz – die Sparse-Gate-Attention-Änderung sollte den Token-Gesamtdurchsatz bei 120K-Token-Eingaben um 67,7 % gegenüber der Vorgängergeneration steigern – und ein Drafter ist dieselbe These, angewandt auf das Decoding. Jedes akzeptierte Draft-Token ist ein Forward-Pass des großen Modells, den man nicht bezahlt hat.

Für alle, die diese Modelle über eine API nutzen, statt sie selbst zu hosten, ist das Entwurfsmodell unsichtbar – und genau das ist der Punkt. Wenn ein Anbieter spekulative Dekodierung in seinen Serving-Stack integriert, sieht man kein neues Modell; man sieht, wie dasselbe Modell pro Token schneller und günstiger wird. Die Preisebene ist aus demselben Grund wichtig: Bei OrcaRouter geben wir den Listenpreis des Anbieters ohne Aufschlag (0 %) direkt weiter. Wenn sich die Arbeit eines Anbieters an der Serving-Effizienz also in einer Preissenkung äußert, ist sie bei uns am selben Tag live – ohne Neuverhandlung, ohne Vertragsänderung. Und bei einem unerprobten Modell, das sich vielleicht bewährt oder auch nicht, ist Routing mit automatischem Failover der Weg, es auszuprobieren, ohne einen Produktionspfad darauf zu setzen: ein einziger API-Schlüssel, und die Anfrage wird auf einen anderen Anbieter umgeleitet, falls der erste nachlässt.

Eine ehrliche Anmerkung speziell zu diesem Release: A.X-K2-DSpark ist ein reiner Drafter-Checkpoint, daher kann keine gehostete Modell-API ihn routen – auch unsere nicht. Drafters sind eine serverseitige Komponente, kein aufrufbares Produkt. Wenn der Drafter ausgeliefert wird und die Evaluationszahlen vorliegen, wird in der Preisliste ein schnelleres, günstigeres A.X K2 auftauchen – kein neuer Endpunkt namens „DSpark“.

Ein paar Fragen, die eine Antwort verdienen

Kann ich A.X-K2-DSpark eigenständig verwenden? Nein — das ist die entscheidende Tatsache des Releases. Es ist ein reiner Drafter-Checkpoint ohne eigenständige Verwendung und ohne öffentliche API; es existiert nur als Helfer innerhalb einer vLLM-Speculative-Decoding-Schleife, die A.X K2 bedient, und die Karte vermerkt, dass es mit keinem anderen Ziel validiert wurde.

Ist A.X-K2-DSpark ein Konkurrent zu A.X K2? Das Gegenteil. Es ist ein Beschleuniger für A.X K2 — dasselbe Modell wird schneller, mit unveränderter Ausgabeverteilung. Stellen Sie es sich als ein nachrüstbares Effizienzteil vor, nicht als neuen Eintrag in der Produktpalette.

Wann wird es tatsächlich veröffentlicht? Die Modellkarte sagt, dass es sich in der finalen Validierung befindet und die öffentliche Veröffentlichung „in den nächsten Tagen“ geplant ist. Das ist alles, was bestätigt ist. Das entscheidende Datum ist der Tag, an dem die TBD-Werte — Durchsatz, TPOT und mittlere akzeptierte Länge — ausgefüllt werden, denn dann ist die Veröffentlichung kein Versprechen mehr, sondern etwas, das man bewerten kann.

Muss ich darüber nachdenken, wenn ich A.X K2 über eine API nutze?Wahrscheinlich nicht direkt. Der Serving-Stack hinter einer API entscheidet, ob ein Drafter im Prozess ist; Sie sehen das Ergebnis als Preis und Latenz, nicht als Flag. Am wichtigsten ist das für Teams, die A.X K2 selbst hosten, wo das Opt-in eine vLLM-Konfigurationsänderung ist, die sie kontrollieren.

Die Geschichte hier ist nicht der Drafter selbst — es ist das, was der Drafter signalisiert. Effizienzarbeit wird leise zu einer eigenen Release-Kategorie, und die interessantesten neuen Modelle in diesem Jahr sind zunehmend Helfer, die große Modelle günstig machen, nicht größere Modelle. A.X-K2-DSpark ist das bisher klarste Beispiel: ein Checkpoint ohne eigenständigen Nutzen, vor der Ankündigung veröffentlicht, der den Großteil seiner eigenen Belege als TBD mit sich führt. Achte auf die akzeptierte Längenangabe, sobald sie erscheint, behandle die Gewinne des DSpark-Papers als Herkunftsnachweis für die Methode und nicht als Versprechen für diesen Checkpoint, und plane, wenn du A.X K2 selbst betreibst, Budget für den Benchmark ein — das ist der einzige Weg, um zu wissen, ob der still veröffentlichte Drafter eine 1.2x-Spielerei oder das echte Ding ist.