K-EXAONE-2.0-750B-A37B-DSpark: LGs 750B Korean-MoE kommt zu vLLM

Am 9. August 2026 wurde im vLLM-Repository ein Pull-Request eröffnet, um K-EXAONE-2.0-750B-A37B-DSpark hinzuzufügen – die spekulative Dekodierungsvariante des koreanischen Flaggschiffs von LG AI Research mit 750 Milliarden Parametern. Vier Tage später, am 13. August, machte ein zweiter, grundlegenderer PR das Leak konkret: vLLM verfügt nun über einen generischen DSparkDraftModel-Konfigurationspfad, der jeden Hugging-Face-Checkpoint, der architectures=DSparkDraftModel mit model_type=qw​en​3 deklariert, auf das erkannte Qw​en3DSparkModel abbildet – mit einem Testplan, der tatsächlich den RadixArk Qw​en​3.8-2.4T-A95B-DSpark-Drafter über die dspark-Spec-Methode bedient. Das Basis-Modell K-EXAONE-2.0-750B-A37B wurde am 31. Juli unter Apache 2.0 veröffentlicht, und zum Start konnte vLLM es mit der MTP-Draft-Methode bedienen, aber nicht mit DSpark – den Drafter, den LG ebenfalls mitliefert und der eine 3–5× schnellere Dekodierung ermöglichen soll. DSpark selbst ist Deep​Seeks Methode, derselbe semi-autoregressive Drafter, der auf Deep​Seek-V4-Pro-DSpark und Deep​Seek-V4-Flash-DSpark läuft. Zusammen sind die beiden PRs das bislang deutlichste Zeichen dafür, dass Deep​Seeks Stack für spekulative Dekodierung zum Standard für offene Gewichte wird.

Dies ist ein Bericht über den aktuellen Kenntnisstand, keine Startmeldung. Beide Pull-Requests sind offen und noch nicht gemerged, der DSpark-Checkpoint hat keinen unabhängigen Benchmark, und LGs Beschleunigungsangabe ist eine Herstellerangabe. Alles unten ist entsprechend gekennzeichnet. Was heute real ist: Die Gewichte sind auf Hugging Face, das Basismodell ist erschienen, vLLMs DSpark-Spec-Decoder bedient bereits Deep​Seek- und Kim​i-Checkpoints, und der generische Konfigurationspfad, der das Laden eines DSpark-Drafters von Drittanbietern ermöglichen würde — das Teil, auf das dieses Leak gewartet hat — liegt jetzt in einem öffentlichen Pull-Request vor, getestet, aber nicht veröffentlicht.

Die Kurzfassung

• PR #51558, eröffnet am 9. August 2026, fügt K-EXAONE-2.0-750B-A37B-DSpark zu vLLM hinzu; er ist offen und hat noch keine Genehmigungen.

• PR #52197, eröffnet am 13. August 2026, integriert generische DSparkDraftModel-Konfigurationsunterstützung — architectures=DSparkDraftModel mit model_type=qwen3, normalisiert zu Qwen3DSparkModel — und sein Testplan führt den RadixArk Qwen3.8-2.4T-A95B-DSpark-Drafter mit der dspark-spec-Methode und sieben spec-Tokens aus. Ebenfalls offen, ebenfalls ungemergt.

• DSpark ist der Drafter der EAGLE-Familie, den Deep​Seek als Open Source veröffentlicht hat und der auf Deep​Seek-V4-Pro-DSpark und Deep​Seek-V4-Flash-DSpark läuft; LG ist die bisher prominenteste Übernahme durch ein anderes Labor, und der Qw​en​3.8-Drafter von RadixArk ist ein zweiter unabhängiger Drafter.

• Die DSpark-Variante ist das 78-Schichten-750B-MoE plus fünf zusätzliche Draft-Schichten; LG gibt an, dass DSpark und MTP jeweils eine etwa 3–5-fache Decode-Beschleunigung bieten, ausgelegt für langfristige agentische Workloads.

• Beim Launch unterstützte vLLM MTP für K-EXAONE 2.0, aber nicht für DSpark; die DSpark-Unterstützung kommt über den modellspezifischen PR und den generischen Konfigurationspfad.

• Kein Anbieter hostet heute einen K-EXAONE-2.0-Checkpoint, und jede Benchmark auf der Karte stammt von LG selbst.

Was die Pull Requests sind (und was nicht)

vLLM PR #51558, „[Model] Add K-EXAONE-2.0-750B-A37B-DSpark", wurde von lkm2835 eröffnet – demselben Mitwirkenden, der zuvor die K-EXAONE-Unterstützung in vLLM (#50524 für das Basismodell) und in SGLang (#33648) beigesteuert hat. Es ist ein Fork-PR mit dem Label „new-model", und es wurde eine Überprüfung durch die vLLM-Codebesitzer angefordert, aber es hat noch keine Genehmigungen. Die Beschreibung umfasst drei Zeilen: Sie fügt Unterstützung für den DSpark-Checkpoint hinzu, „entwickelt von LG AI Research", verlinkt die Hugging-Face-Modellkarte und den technischen Bericht zu K-EXAONE 2.0 (arXiv 2608.04505) und verweist auf die frühere vLLM-Arbeit in #50524.

Der PR vom 13. August ist anderer Art. #52197, „Support DSpark configs with architectures=DSparkDraftModel + model_type=qw​en​3", fügt eine generische Normalisierungsschicht hinzu: Ein Hugging-Face-Draft-Checkpoint, der sich selbst als DSparkDraftModel auf einem qw​en​3-Modelltyp deklariert, wird auf ein Qw​en3DSparkModel umgemappt, das von vLLMs bestehendem Spec-Decoder geladen werden kann. Das Referenzmodell in seinem Testplan ist RadixArk/Qw​en​3.8-2.4T-A95B-DSpark — ein DSpark-Spekulator für das Max-Class-Ziel Qw​en​3.8-2.4T-A95B — bereitgestellt mit der dspark-Spec-Methode und einem Sieben-Token-Spec-Fenster. Die Commit-Nachricht ist die ganze Idee: „architectures=DSparkDraftModel+model_type=qw​en​3." Der Sinn der Änderung besteht darin, dass ein Drittanbieter-DSpark-Drafter per Konfiguration ladbar sein sollte, anstatt pro Modell Code zu benötigen, wie das heute bei jedem unterstützten DSpark-Checkpoint verdrahtet ist. Er ist offen und nicht gemergt, genau wie #51558.

Lesen Sie diesen Status wörtlich. „Unterstützung wird hinzugefügt" bedeutet nicht „Unterstützung ist verfügbar": Bis einer der PRs gemergt und in einem Release veröffentlicht wird, wird ein Standard-vLLM-Build die DSpark-Variante weiterhin nicht laden können. Die Modellkarte selbst sagt, dass das Serving von K-EXAONE 2.0 mit DSpark derzeit nicht auf vLLM unterstützt wird, das stattdessen MTP verwendet. Diese beiden PRs sind die Schritte, die diesen Satz ändern — falls und wenn sie landen.

Warum DSpark hier die eigentliche Geschichte ist.

Der Modellname leistet eine Menge Arbeit. „A37B“ bedeutet 37 Milliarden aktive Parameter pro Token. „DSpark“ ist der Drafter für spekulative Dekodierung, den Deep​Seek dieses Jahr eingeführt hat: ein semi-autoregressives Draft-Modell aus der EAGLE-Familie, das in einem einzigen Durchlauf einen Block von Token vorschlägt und es dem Zielmodell ermöglicht, diese zu verifizieren, sodass die Ausgabequalität unverändert bleibt, während die Generierung schneller wird. Deep​Seek hat ihn als Open Source veröffentlicht und liefert den Drafter mit seinen eigenen Deep​Seek-V4-Pro-DSpark- und Deep​Seek-V4-Flash-DSpark-Checkpoints aus, wobei die Community Geschwindigkeitssteigerungen im Bereich von 60–85 % für Flash und 57–78 % für Pro im Vergleich zu einer Single-Token-MTP-Baseline berichtet.

Was der neue PR deutlich macht, ist, dass DSpark-Unterstützung in vLLM nie die offene Frage war. Die eigenen Dokumente von vLLM listen bereits DSpark-Module für Deep​Seek-V4, Kimi K3 und Gem​ma​4-Checkpoints auf, und das Team beschrieb das Design in einem technischen Beitrag vom Juli. Jede dieser Integrationen ist jedoch von Hand verdrahtet – eine gesegnete Liste von Checkpoints, keine Route, die jeder nutzen kann. Der K-EXAONE-Checkpoint steht einfach nicht auf dieser Liste. #52197 ist der Versuch, die Route generisch zu machen: ein Konfigurations-Mapping (DSparkDraftModel plus qw​en​3) statt einer weiteren maßgeschneiderten Modellklasse, und ein Drittanbieter-Drafter als Referenztestfall anstatt eines Deep​Seek-Modells. Genau deshalb ist eine Geschichte über einen durchgesickerten Draft-Checkpoint eigentlich eine Infrastruktur-Geschichte.

K-EXAONE-2.0-750B-A37B-DSpark behält die 78 Schichten des Basismodells und fügt fünf DSpark-Draft-Layer hinzu. Die Modellkarte von LG gibt an, dass sowohl DSpark als auch MTP die Generierung um etwa das 3- bis 5-Fache beschleunigen — eigene Zahlen, die auf „langfristige Workloads wie agentische Aufgaben“ abzielen, bei denen die Dekodierungslatenz der Engpass ist. Daraus folgen zwei Dinge. Erstens wird spekulative Dekodierung zu einem erstklassigen Feature offener Frontier-Modelle, nicht zu einem Serving-Trick, den man nachträglich aufpfropft. Zweitens ist es der Draft-Stack von Deep​Seek, der zum Standard wird — genau deshalb ist ein von der koreanischen Regierung unterstütztes souveränes Flaggschiff, das damit ausgeliefert wird, über die übliche „neues Modell“-Meldung hinaus von Bedeutung.

Das Modell hinter dem PR

K-EXAONE-2.0-750B-A37B-DSpark ist eine Variante von K-EXAONE 2.0, dem Nachfolger der 236B-K-EXAONE-Reihe von LG und Südkoreas größtem einheimischen Basismodell, das im Rahmen des staatlichen Sovereign-AI-Programms entwickelt wurde. Das Basismodell — 750B Gesamtparameter, 37B aktiv, Mixture-of-Experts mit 256 Experten und 8 aktiven pro Token, ein Kontextfenster von 262.144 Token, zehn Sprachen, Apache 2.0 — wurde am 31. Juli 2026 auf Hugging Face veröffentlicht; es entstand durch Upcycling aus dem 236B-Vorgänger und nicht durch Training von Grund auf.

LGs eigene Benchmark-Durchschnittswerte (24 Benchmarks, insgesamt 70,1) zeigen das erwartete Bild für ein souveränes koreanisches Modell: starke ausgewiesene Ergebnisse bei Long-Context-Retrieval, koreanischer gesellschaftlicher Sicherheit und agentischem Coding, neben Werten, die beim allgemeinen Reasoning hinter Alibabas Qw​en​3.5 zurückbleiben (83,5 gegenüber 89,8 bei MMLU-Pro, zum Beispiel). Nichts davon ist bisher unabhängig verifiziert. Die DSpark-Variante ändert keinen dieser Werte — sie ist ein Serving-Artefakt, eine schnellere Möglichkeit, dasselbe Modell auszuführen — genau deshalb taucht sie in Pull Requests von Inferenz-Frameworks auf und nicht in einer Ankündigung.

Die Serving-Realität hinter einem 750B-MoE

Hier zeigt sich, wo die DSpark-Unterstützung tatsächlich eine Rolle spielt. K-EXAONE-2.0-750B-A37B-DSpark ist ein Checkpoint mit 751 Milliarden Parametern in BF16/F32, und LGs Empfehlung lautet mindestens zwei Knoten mit je acht NVIDIA-H200-GPUs (16 GPUs, Tensor-Parallelismus 16). In dieser Größenordnung ist der Decode-Durchsatz das A und O — Tokens pro Sekunde und die Kosten einer langen agentischen Interaktion — und genau das greift spekulatives Decoding an. Ein 3–5-facher Decode-Speedup, sofern er außerhalb von LGs Testumgebung hält, entscheidet darüber, ob ein H200-Cluster wirtschaftlich ist oder nicht. LG dokumentiert außerdem ein Problem mit dem Generierungskollaps auf B200-GPUs, das bis zur Behebung den Workaround --disable-prefill-cuda-graph erfordert — eine Erinnerung daran, dass dies hochmodernes Serving ist, kein Plug-and-Play.

Was es kostet, und wie man es tatsächlich ausprobieren würde.

Heute stellt keine API K-EXAONE 2.0 bereit. Die Hugging-Face-Karte für die DSpark-Variante sagt weiterhin „dieses Modell wird von keinem Inferenzanbieter bereitgestellt“, und ein 16×H200-Fußabdruck bedeutet, dass es eine gehostete API nur dann erreicht, wenn jemand mit dieser Hardware beschließt, es zu hosten. Das ist der eigentliche Reibungspunkt: Die Grenze der offenen Gewichte ist zunehmend ein Serving-Problem, kein Verfügbarkeitsproblem.

Wenn ein Anbieter es tatsächlich ins Programm nimmt, wird sich die Speculative-Decoding-Beschleunigung im Preis pro Token niederschlagen, und die Umstellungskosten, es auszuprobieren, sollten nahezu null sein, wenn Ihre Anwendung bereits modellagnostisch ist. Bei OrcaRouter — einem OpenAI-kompatiblen Endpunkt für über 200 Modelle, bei dem der Listenpreis der Anbieter ohne Aufschlag durchgereicht wird — wird ein Modell, das bei einem beliebigen Upstream-Anbieter landet, zu einer Routing-Änderung statt einer Neu-Integration, und automatisches Failover bedeutet, dass ein brandneues 750B-MoE, das sich als langsam oder instabil erweist, ohne Störfall auf ein bekannt funktionierendes Modell zurückfällt. Um es deutlich zu sagen: OrcaRouter hostet K-EXAONE-2.0-750B-A37B-DSpark heute nicht, und auch keine andere uns bekannte API tut das. Der Sinn der Routing-Schicht ist, auf den Tag vorbereitet zu sein, an dem einer der Anbieter es tut.

Was wir uns ansehen

• Die beiden PRs, die zusammengeführt werden. #51558 (modellspezifisch) und #52197 (generische Konfiguration) sind beide offen und haben keine Approvals. Merge plus Release ist das, was „DSpark-Unterstützung“ von Pull-Requests in Flags verwandelt, die man tatsächlich übergeben kann.

• Der Umfang des generischen Pfads. Falls #52197 gemergt wird, wird jedes als qw​en​3 typisierte DSparkDraftModel auf Hugging Face per Konfiguration ladbar – der Unterschied zwischen DSpark als einer Liste freigegebener Checkpoints und DSpark als einem offenen Standard.

• Ein erster unabhängiger Messwert. Jede Benchmark auf der Karte wird von LG durchgeführt. Der erste Datenpunkt von Artificial Analysis oder Arena für ein 750B koreanisches MoE-Modell wird die erste Zahl sein, die nicht vom Anbieter stammt.

• DSpark über Deep​Seek hinaus. LG und RadixArk sind jetzt zwei unabhängige Produktanbieter der Draft-Methode von Deep​Seek, und der generische vLLM-Pfad ist ein drittes Signal, dass sich der Stack konsolidiert.

{{1}}Quantisiertes Serving{{/1}}. {{2}}LG liefert FP8- und NVFP4-Checkpoints des Basismodells aus; eine quantisierte DSpark-Variante, die auf weniger GPUs passt, würde die Wirtschaftlichkeit schneller verändern als jeder Benchmark.{{/2}}

FAQ

Ist K-EXAONE-2.0-750B-A37B-DSpark veröffentlicht?

Die Gewichte sind auf Hugging Face unter Apache 2.0 verfügbar, aber das ist keine Launch-Story: Die vLLM-Unterstützung besteht aus zwei offenen, nicht zusammengeführten Pull-Requests (#51558 und #52197), die Speedup-Zahl ist LGs eigene, und kein Anbieter hostet das Modell. Was hier mit „bestätigt“ gemeint ist, ist der Serving-Pfad – die generische DSparkDraftModel-Konfigurationsunterstützung existiert nun in einem öffentlichen PR mit einem ausführbaren Testplan – nicht, dass ein veröffentlichter vLLM-Build es bereits serven kann.

Was ist der Unterschied zwischen K-EXAONE-2.0-750B-A37B und der DSpark-Variante?

Die 78 Schichten des Basismodells plus fünf DSpark-Draft-Schichten für spekulative Dekodierung – darunter dieselben Gewichte, dieselben Benchmarks und ein schneller zu dekodierendes Bereitstellungsartefakt anstatt eines anderen Modells.

Gehört DSpark zu LG oder zu DeepSeek?

DSpark ist die Open-Source-Methode von DeepSeek für spekulative Dekodierung, die auch auf DeepSeek-V4-Pro-DSpark und DeepSeek-V4-Flash-DSpark verfügbar ist; LG ist bisher der prominenteste Anwender, und RadixArks Qwen3.8-2.4T-A95B-DSpark ist ein zweiter unabhängiger Drafter, der auf derselben Methode basiert. LGs Modellkarte gibt denselben Beschleunigungsbereich von 3–5× an.

Kann ich K-EXAONE-2.0-750B-A37B-DSpark heute auf meiner eigenen Hardware ausführen?

Nur durch Self-Hosting: LGs Empfehlung liegt bei mindestens sechzehn NVIDIA H200 GPUs, und die Standardversionen von vLLM, SGLang und Transformers benötigen weiterhin nicht gemergte Forks oder den ausstehenden generischen Konfigurationspfad, um die Architektur zu erkennen. Die DSparkDraftModel-Unterstützung in #52197 ist das, was einem gemeinsamen Weg am nächsten kommt, aber es ist immer noch ein offener Pull-Request.

Was dies beachtenswert macht, sind nicht die Pull Requests selbst — sondern das, was sie signalisieren. Ein souveränes koreanisches Flaggschiff mit 750 Milliarden Parametern und Apache-2.0-Lizenz hat sich entschieden, den Speculative-Decoding-Stack von Deep​Seek auszuliefern; ein unabhängiges Inferenzunternehmen hat einen DSpark-Drafter für ein Qw​en​3.8 der Max-Klasse gebaut; und vLLM reagiert mit einem generischen Konfigurationspfad statt eines modellspezifischen Patches. So werden offene Frontier-Modelle Realität — nicht in dem Moment, in dem die Gewichte erscheinen, sondern in dem Moment, in dem die Drafter gemerged werden.