A.X K2 DSpark vs A.X K2: Was ein reines Entwurfsmodell tatsächlich bringt

Das Seltsamste an einem Vergleich zwischen A.X K2 DSpark und A.X K2 ist, dass es eigentlich kein Vergleich ist. A.X K2 DSpark kann nicht anstelle von A.X K2 verwendet werden – es kann überhaupt nicht eigenständig eingesetzt werden. Es ist ein „Nur-Drafter-Checkpoint", den SK Telecom Anfang August still und leise ohne Ankündigung auf Hugging Face veröffentlicht hat: ein Draft-Modell für spekulative Dekodierung, dessen einzige Aufgabe darin besteht, A.X K2 – das 688-Milliarden-Parameter-Flaggschiff des Unternehmens mit offenen Gewichten und Mixture-of-Experts-Architektur – Tokens schneller erzeugen zu lassen, ohne seine Antworten zu verändern. Die eigentliche Frage, auf die es bei diesem Vergleich ankommt, ist also nicht „Welches ist besser?", sondern „Solltest du A.X K2 mit DSpark ausführen oder ohne?" In diesem Beitrag ist jede Angabe mit einer Quelle versehen, denn die Diskrepanz zwischen dem, was das Repository uns sagt, und dem, was tatsächlich gemessen wurde, ist die ganze Geschichte.

Was A.X K2 DSpark eigentlich ist

SK Telecoms Modellkarte ist ungewöhnlich direkt, was der Zweck des Modells ist. A.X K2 DSpark „ist ein DSpark-Speculative-Decoding-Draftmodell für A.X K2" und „ein reiner Drafter-Checkpoint: Es hat keine eigenständige Verwendung und soll von vLLM zusammen mit A.X K2 durch Speculative Decoding geladen werden." In der Praxis bedeutet das: Man lädt es herunter, richtet ein kompatibles vLLM sowohl darauf als auch auf A.X K2 aus, und die beiden arbeiten als Team: DSpark schlägt Kandidaten-Tokens vor, A.X K2 verifiziert sie, und nur verifizierte Tokens werden ausgegeben.

Zwei Details des Entwurfsmechanismus sind aus dem Repository ersichtlich. Erstens schlägt DSpark mehrere Kandidaten-Tokens parallel vor, anstatt eine Entwurfssequenz Token für Token zu schreiben, und nutzt dabei A.X K2s eigene versteckte Repräsentationen zusammen mit leichtgewichtiger lokaler Abhängigkeitsmodellierung. Zweitens ist das Ganze von Grund auf verlustfrei ausgelegt: Jeder Kandidat wird vom Zielmodell verifiziert, bevor er übernommen wird, sodass die Ausgabeverteilung von A.X K2 konstruktionsbedingt unverändert bleibt.

Die Veröffentlichung selbst ist eine Vorabankündigung. Die Karte besagt, dass sich das Modell „derzeit in der finalen Validierung befindet und für die öffentliche Veröffentlichung in den nächsten Tagen geplant ist“ und dass die Evaluierung „derzeit im Gange“ ist — jede Metrik für Durchsatz, TPOT und mittlere akzeptierte Länge auf der Karte ist weiterhin als TBD aufgeführt.

Warum dieses "versus" eigentlich "mit versus ohne" ist

Da A.X K2 DSpark keine eigenständige Verwendung hat, gibt es kein Szenario, in dem Sie es anstelle von A.X K2 wählen. Die Wahl besteht zwischen A.X K2 allein und A.X K2 mit angehängtem Draft-Modell. In Bezug auf die Ausgabequalität sind die beiden Konfigurationen konstruktionsbedingt identisch; die einzige Achse, die sich bewegen kann, ist die Dekodiergeschwindigkeit.

Zur Klarstellung: Der A.X K2 ist ein Mixture-of-Experts-Decoder mit insgesamt 688B Parametern, davon 33B aktiv, mit 256 Experten plus einem gemeinsamen Experten (8 aktiv pro Vorwärtsdurchlauf), 61 Schichten, 64 Aufmerksamkeitsköpfen und einem Vokabular von 163.840 Token, der am 29. Juli mit offenen Gewichten unter Apache 2.0 veröffentlicht wurde. Er wurde mit etwa 8,2 Billionen Token nativ in MXFP8 vortrainiert, nutzt SK Telecoms Sparse Gated Attention für Effizienz bei langen Kontexten und besitzt einen Kontext von 262.144 Token (nativ 128K, erweitert auf 256K via YaRN). SK Telecom berichtet, dass er über 14 Benchmarks im Schnitt +32,2 Prozentpunkte über A.X K1 liegt, mit Verbesserungen bei Langkontext- und Agentenauswertungen von bis zu 83,9 Punkten – alles vom Anbieter gemeldet, ohne dass bisher ein unabhängiger Gesamtwert veröffentlicht wurde.

DSpark ist speziell für diese Architektur entwickelt. Die Karte gibt an, dass es auf die MoE-Struktur, das Attention-Layout und die native 256K-Konfiguration von A.X K2 abgestimmt ist und gegen kein anderes Ziel validiert wird. Es erbt denselben 262.144-Token-Kontext, daher kostet Sie der Betrieb hinsichtlich der Fenstergröße nichts.

Modellblatt lesen: erkennbar, noch nicht bestätigt

Das Repo gibt dir ein klares Bild davon, was das Modell ist, und eine kurze Liste der Dinge, die es dir nicht sagt.

Heute wissbar:

Es ist ein reiner Drafter-Checkpoint ohne eigenständige Verwendung, der von vLLM zusammen mit A.X K2 durch spekulative Dekodierung geladen wird.

Die Lizenz ist Apache 2.0; die Gewichte können kostenlos heruntergeladen und verwendet werden.

• Die Kontextlänge entspricht A.X K2 bei 262.144 Tokens.

• Es läuft über den vLLM-Fork von SK Telecom (das Repository SKT-AI/vllm, Branch axk2-v0.23.0) unter Verwendung eines --speculative-config-Flags.

• Die Methode ist in einem Paper mit dem Titel „DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" dokumentiert (arXiv:2607.05147, eingereicht am 6. Juli 2026) — aus diesem Paper stammen auch die Beschleunigungszahlen, die Sie zitiert sehen werden.

• Kein Inferenzanbieter stellt es heute bereit, daher gibt es keine gehostete API, die aufgerufen werden kann.

Noch nicht bestätigt:

• Eine offizielle Ankündigung — die Karte verspricht die öffentliche Veröffentlichung „in den nächsten Tagen“.

• Jeder A.X K2-spezifische Speedup-Wert. Die Evaluierung ist im Gange und jede Leistungskennzahl ist TBD.

• Wie viel es unter Last tatsächlich hilft, was die Karte als „lastabhängig“ einstuft.

• Jede unabhängige Messung des Entwurfsmodells durch einen Dritten.

Wie DSpark sich von gewöhnlicher spekulativer Dekodierung unterscheidet

Spekulatives Decoding ist ein altbekannter Trick: Ein kleines, schnelles Draft-Modell schreibt eine Schätzung für die nächsten mehreren Token, und das große Modell prüft die gesamte Schätzung in einem einzigen Forward-Pass, wobei es das Präfix akzeptiert, das die Verifikation übersteht, bevor es einen korrigierenden Schritt unternimmt. Gut umgesetzt reduziert es die Latenz drastisch, ohne Qualitätsverlust.

Der Haken, wie es das DSpark-Papier formuliert, ist, dass neuere parallele Draft-Modelle, die in einem Durchgang lange Sequenzen vorschlagen, unter einem "schnellen Akzeptanzverfall" leiden, weil die späteren Token im Entwurf keine Abhängigkeit von den früheren aufweisen und daher viel häufiger abgelehnt werden. Und das blinde Verifizieren langer Blöcke verschwendet Batch-Kapazität für Token, die wahrscheinlich abgelehnt werden, was den Durchsatz gerade in Systemen mit hoher Nebenläufigkeit beeinträchtigt.

DSpark greift beide Probleme an:

• Semi-autoregressives Drafting. Es koppelt ein paralleles Rückgrat mit einem leichtgewichtigen sequenziellen Modul und fügt eine Intra-Block-Abhängigkeitsmodellierung hinzu, sodass spätere Draft-Token von früheren abhängen — genau das mildert die Suffix-Degeneration.

• Konfidenzgesteuerte Verifikation. Anstatt eine feste Blocklänge zu verifizieren, passt sie die Verifikationslänge pro Anfrage an, basierend auf geschätzten Präfix-Überlebenswahrscheinlichkeiten und dem Durchsatzprofil der Engine. Die Verifikation wird lastbewusst.

Die Zahlen des Papiers — und was sie dir nicht verraten

Hier ist die Zahl, die Sie zitiert sehen werden: DSpark „beschleunigt die Generierungsgeschwindigkeit pro Benutzer um 60 bis 85 Prozent" bei gleichen Durchsatzwerten im Vergleich zur MTP-1-Produktionsbasislinie. Das Papier berichtet auch über eine deutlich verbesserte akzeptierte Länge im Vergleich zu modernsten autoregressiven und parallelen Draftern in Offline-Benchmarks und sagt, dass es eine starke Durchsatzverschlechterung unter strengen Interaktivitätsbeschränkungen verhindert.

Lesen Sie das Kleingedruckte, denn es ist für dieses spezifische Aufeinandertreffen wichtig: Diese Zahl von 60–85 % wurde im Serving-System von DeepSeek-V4 unter Live-Benutzerverkehr gemessen – nicht auf A.X K2. Es ist eine Aussage über die DSpark-Methode, die auf dem Stack eines anderen Modells eingesetzt wurde. Die A.X-K2-DSpark-Karte hingegen hat noch überhaupt keine Beschleunigungszahl. Die ehrliche Bilanz für diese Kombination ist daher: konstruktionsbedingt identische Ausgabe und eine Beschleunigung, die das Paper zu dieser Methode als plausibel nahelegt, die SK Telecom selbst aber noch nicht an dem Modell gemessen hat, für das dieser Entwurfs-Checkpoint erstellt wurde.

Was es tatsächlich braucht, um es auszuführen

Die Voraussetzung ist der Teil, an dem die meisten Leute abspringen: Man muss A.X K2 selbst hosten. Es gibt keine gehostete API für das Zielmodell — es ist Open-Weight, und das Betreiben eines 688B/33B-aktiven MoE ist eine ernsthafte infrastrukturelle Verpflichtung. DSpark ist nur für Teams von Bedeutung, die diese Verpflichtung bereits eingegangen sind.

Wenn du eines hast, sind die Grenzkosten für das Hinzufügen des Entwurfsmodells gering:

• Laden Sie den Apache-2.0-Draft-Checkpoint herunter und führen Sie SK Telecoms vLLM-Fork (Zweig axk2-v0.23.0) aus.

Aktivieren Sie die spekulative Dekodierung über das Flag `--speculative-config` und richten Sie es auf den DSpark-Checkpoint.

• Planen Sie zusätzlichen Speicher für die Draft-Gewichte ein, und akzeptieren Sie, dass Sie sich nun auf einem Vendor-Fork von vLLM befinden statt auf der Standardversion — ein Aspekt, der bei der Wartung zu berücksichtigen ist.

• Man beachte den eigenen Warnhinweis des Papers, dass Verifikation nicht kostenlos ist: Bei hoher Nebenläufigkeit verbraucht nachlässige Verifikation Batchkapazität – genau das Versagensmodell, das konfidenzgesteuerte Verifikation bewältigen soll.

Noch etwas Wissenswertes: Hugging Face berichtet, dass Downloads „für dieses Modell nicht erfasst werden“, es gibt also kein öffentliches Signal dafür, wie viele Teams es tatsächlich ausprobiert haben.

Wer sollte welche auswählen?

Führen Sie A.X K2 unverändert aus, wenn eine der folgenden Aussagen auf Sie zutrifft:

• Sie verwenden Standard-vLLM und möchten keinen zweiten Checkpoint oder Vendor-Fork im Pfad.

Ihre Workloads sind durchsatzgebunden, aber nicht latenzgebunden, und Benutzer tolerieren das Warten auf lange Generierungen.

Sie würden lieber auf die offizielle Veröffentlichung und die ersten unabhängigen Messungen warten.

Führe A.X K2 plus DSpark aus, wenn du das bist:

• Sie hosten A.X K2 selbst und die Generierungslatenz oder der Token-Durchsatz bereitet Ihnen Probleme.

Long-Context- und Agentic-Workloads lassen Nutzer auf lange Ausgaben warten – das Regime, für das spekulative Dekodierung konzipiert ist.

Sie sind damit einverstanden, eine Vorankündigungskomponente auszuführen, deren Nachteil begrenzt ist: Im schlimmsten Fall hilft sie nicht, und sie kann die Ausgabequalität nicht verändern.

Wählen Sie keines von beiden, wenn Sie überhaupt kein 688B-MoE selbst hosten. Die Souveränitäts- und Koreanisch-Sprachstärken von A.X K2 kommen nur dann bei Ihnen an, wenn Sie es betreiben, und viele Teams werden stattdessen über einen gehosteten Katalog auf Open-Source-Spitzenmodelle zugreifen. Genau hier zahlt es sich aus, Ihre Integration modellagnostisch zu halten: Der eine OpenAI-kompatible Endpunkt von OrcaRouter umfasst über 200 Modelle zum Listenpreis des Anbieters mit 0 % Aufschlag, automatischem Failover und einer Routing-DSL, um mehrere Modelle in einem einzigen Aufruf zu kombinieren. (Weder A.X K2 noch A.X K2 DSpark wird heute irgendwo gehostet – auch nicht auf OrcaRouter –, es geht also um den Rest Ihres Stacks, nicht um das Routing dieser beiden.) Dieser Ansatz überträgt sich trotzdem: Probieren Sie ein unerprobtes Modell mit einem Bruchteil des Traffics aus und schalten Sie automatisch um, anstatt einen Produktionspfad darauf zu setzen.

Was als Nächstes ansehen

Die Lage ist einfach: Das Repo ist real, die Methode ist dokumentiert, die Messungen nicht. Die drei Dinge, auf die man achten sollte, sind die versprochene öffentliche Veröffentlichung (laut Karte „in den nächsten Tagen"), die ersten A.X-K2-spezifischen Durchsatz- oder Latenzzahlen, sobald SK Telecoms Evaluierung abgeschlossen ist, und ob ein Inferenzanbieter das Paar aufnimmt – genau das würde DSpark für Teams relevant machen, die nicht selbst hosten.

FAQ

Kann A.X K2 DSpark A.X K2 ersetzen?

Nein. Es ist ein reiner Drafter-Checkpoint ohne eigenständige Verwendung — er existiert, um die Dekodierung von A.X K2 zu beschleunigen, nicht als Alternative dazu. Du kannst A.X K2 DSpark nicht ohne A.X K2 ausführen.

Verändert DSpark die Ausgabequalität von A.X K2?

Nein, konstruktionsbedingt. Jeder Kandidaten-Token wird von A.X K2 verifiziert, bevor er übernommen wird, sodass die Ausgabeverteilung unverändert bleibt — die Karte beschreibt den Ansatz als verlustfrei.

Muss ich A.X K2 selbst hosten, um DSpark zu verwenden?

Ja. DSpark wird von vLLM zusammen mit A.X K2 geladen, also gibt es nichts, wofür es Entwürfe erstellen könnte, es sei denn, du betreibst das 688B-Ziel. Es gibt heute keine gehostete API für eines der beiden Modelle.

Funktioniert DSpark mit anderen Modellen?

SK Telecom hat es für die MoE-Architektur, die Aufmerksamkeitsstruktur und den 256K-Kontext von A.X K2 entworfen und es nicht gegen ein anderes Zielsystem validiert.

Das Urteil

A.X K2 DSpark vs. A.X K2 ist ein „Versus", bei dem die ehrliche Antwort „beides" lautet. Wenn Sie bereits A.X K2 ausführen und Nutzer auf lange Generierungen warten, ist das Draft-Modell ein kostenloses, risikoarmes Experiment: Apache-2.0-Gewichte, im schlimmsten Fall keine Beschleunigung, und konstruktionsbedingt keine Qualitätsverschlechterung möglich. Wenn Sie nicht latenzgebunden sind – oder überhaupt kein 688B-MoE selbst hosten –, können Sie es getrost ignorieren, bis SK Telecoms Evaluierungsergebnisse vorliegen und die versprochene öffentliche Veröffentlichung das Modell offiziell macht. Was Sie nicht tun sollten, ist, die 60–85-%-Angabe des Papers für eine Messung dieses Modells zu halten: Derzeit ist alles DSpark-spezifische an A.X K2 noch TBD.