K-EXAONE-2.0-750B-A37B-DSpark: LG's 750B Koreaans MoE komt naar vLLM

Op 9 augustus 2026 werd in de vLLM-repository een pull request geopend om K-EXAONE-2.0-750B-A37B-DSpark toe te voegen — de speculatieve-decoderingvariant van LG AI Research's Koreaanse vlaggenschipmodel met 750 miljard parameters. Vier dagen later, op 13 augustus, maakte een tweede en fundamenteler PR het lek concreet: vLLM heeft nu een generiek DSparkDraftModel-configpad dat elk Hugging Face-checkpoint dat architectures=DSparkDraftModel met model_type=qw​en​3 declareert, toewijst aan het erkende Qw​en3DSparkModel, met een testplan dat daadwerkelijk de RadixArk Qw​en​3.8-2.4T-A95B-DSpark-drafter via de dspark-specmethode serveert. Het basismodel K-EXAONE-2.0-750B-A37B werd op 31 juli uitgebracht onder Apache 2.0, en bij de lancering kon vLLM het serveren met de MTP-draftmethode, maar niet met DSpark — de drafter die LG ook meelevert en waarvan LG claimt dat deze een 3–5× decodeversnelling oplevert. DSpark zelf is de methode van Deep​Seek, dezelfde semi-autoregressieve drafter die draait op Deep​Seek-V4-Pro-DSpark en Deep​Seek-V4-Flash-DSpark, dus de twee PR's samen zijn tot nu toe het duidelijkste teken dat de stack voor speculatieve decodering van Deep​Seek de standaard voor open weights aan het worden is.

Dit is een stuk over wat we tot nu toe weten, geen lanceerverhaal. Beide pull-requests zijn open en niet samengevoegd, de DSpark-checkpoint heeft geen onafhankelijke benchmark, en het versnellingscijfer van LG is een bewering van de leverancier. Alles hieronder is dienovereenkomstig geëtiketteerd. Wat vandaag de dag echt is: de gewichten staan op Hugging Face, het basismodel is uitgebracht, vLLM's DSpark-spec-decoder bedient al DeepSeek- en Kimi-checkpoints, en het generieke configuratiepad dat een DSpark-drafter van een derde partij zou kunnen laden — het stuk waar dit lek op wachtte — bevindt zich nu in een openbare pull-request, getest maar niet uitgebracht.

De korte versie

• PR #51558, geopend op 9 augustus 2026, voegt K-EXAONE-2.0-750B-A37B-DSpark toe aan vLLM; deze is nog open en heeft nog geen goedkeuringen.

• PR #52197, geopend op 13 augustus 2026, introduceert algemene ondersteuning voor DSparkDraftModel-configuratie — architectures=DSparkDraftModel met model_type=qw​en​3, genormaliseerd naar Qw​en3DSparkModel — en het testplan voert de RadixArk Qw​en​3.8-2.4T-A95B-DSpark-drafter uit met de dspark-spec-methode en zeven spec-tokens. Ook open, ook niet gemerged.

• DSpark is de EAGLE-familie-drafter die Deep​Seek als open source heeft uitgebracht en die wordt gebruikt in Deep​Seek-V4-Pro-DSpark en Deep​Seek-V4-Flash-DSpark; LG is tot nu toe de meest prominente adoptie door een ander lab, en de Qw​en​3.8-drafter van RadixArk is een tweede onafhankelijke.

De DSpark-variant is de 78-laags 750B MoE plus vijf extra draft-lagen; LG beweert dat DSpark en MTP elk een decode-versnelling van ongeveer 3–5× opleveren, gericht op langetermijn-agentische workloads.

• Bij de lancering ondersteunde vLLM MTP voor K-EXAONE 2.0, maar niet voor DSpark; de DSpark-ondersteuning wordt toegevoegd via de modelspecifieke PR en het generieke configpad.

• Geen enkele aanbieder host vandaag een K-EXAONE 2.0-checkpoint, en elke benchmark op de kaart is van LG zelf.

Wat pull requests wel (en niet) zijn

vLLM PR #51558, "[Model] Add K-EXAONE-2.0-750B-A37B-DSpark," werd geopend door lkm2835 — dezelfde bijdrager achter de eerdere K-EXAONE-ondersteuning in vLLM (#50524 voor het basismodel) en in SGLang (#33648). Het is een fork-PR die is voorzien van het label 'new-model', er is om review gevraagd bij de vLLM-code-eigenaren, en er zijn nog geen goedkeuringen. De beschrijving bestaat uit drie regels: het voegt ondersteuning toe voor de DSpark-checkpoint 'ontwikkeld door LG AI Research', linkt de Hugging Face-modelkaart en het technisch rapport van K-EXAONE 2.0 (arXiv 2608.04505), en verwijst naar het eerdere vLLM-werk in #50524.

De PR van 13 augustus is wezenlijk anders. #52197, "Support DSpark configs with architectures=DSparkDraftModel + model_type=qwen3," voegt een generieke normalisatielaag toe: een Hugging Face-conceptcheckpoint dat zichzelf als een DSparkDraftModel op een qwen3-modeltype declareert, wordt hermapt naar een Qwen3DSparkModel dat de bestaande spec-decoder van vLLM kan laden. Het referentiemodel in het testplan is RadixArk/Qwen3.8-2.4T-A95B-DSpark — een DSpark-speculator voor het max-klasse doelmodel Qwen3.8-2.4T-A95B — aangeboden met de dspark-specmethode en een spec-venster van zeven tokens. De commitmelding is het hele idee: "architectures=DSparkDraftModel+model_type=qwen3." Het punt van de wijziging is dat een externe DSpark-drafter via configuratie geladen moet kunnen worden in plaats van dat er per-modelcode nodig is, zoals tegenwoordig elke ondersteunde DSpark-checkpoint is aangesloten. De PR is open en niet gemerged, net als #51558.

Lees die status letterlijk. "Er wordt ondersteuning toegevoegd" is niet "ondersteuning is beschikbaar": totdat een van beide PR's wordt gemerged en in een release uitkomt, zal een standaard vLLM-build de DSpark-variant nog steeds niet laden. De modelkaart zelf zegt dat het serveren van K-EXAONE 2.0 met DSpark momenteel niet wordt ondersteund op vLLM, dat in plaats daarvan MTP gebruikt. Deze twee PR's zijn de stappen die die zin veranderen — als en wanneer ze gemerged worden.

Waarom DSpark hier het echte verhaal is

De modelnaam doet veel werk. "A37B" betekent 37 miljard actieve parameters per token. "DSpark" is het draftmodel voor speculatieve decodering dat Deep​Seek dit jaar introduceerde: een semi-autoregressief draftmodel uit de EAGLE-familie dat in één doorgang een blok tokens voorstelt en het doelmodel deze laat verifiëren, zodat de uitvoerkwaliteit ongewijzigd blijft terwijl de generatie sneller wordt. Deep​Seek heeft het als open source uitgebracht en levert de drafter mee met zijn eigen Deep​Seek-V4-Pro-DSpark- en Deep​Seek-V4-Flash-DSpark-checkpoints, met door de community gerapporteerde versnellingen van 60–85% voor Flash en 57–78% voor Pro ten opzichte van een single-token MTP-basislijn.

Wat de nieuwe PR duidelijk maakt, is dat DSpark-ondersteuning in vLLM nooit de open vraag was. vLLM's eigen documentatie vermeldt al DSpark-modules voor Deep​Seek-V4-, Kimi K3- en Gem​ma​4-checkpoints, en het team beschreef het ontwerp in een technische blogpost van juli. Elk van die integraties is echter met de hand ingebouwd — een goedgekeurde lijst van checkpoints, geen route die iedereen kan gebruiken. Het K-EXAONE-checkpoint staat simpelweg niet op die lijst. #52197 is de poging om de route generiek te maken: één config-mapping (DSparkDraftModel plus qw​en​3) in plaats van weer een op maat gemaakte modelklasse, en een drafter van derden als referentietestgeval in plaats van een Deep​Seek-model. Daarom is een verhaal over een gelekt draft-checkpoint eigenlijk een infrastructuurverhaal.

K-EXAONE-2.0-750B-A37B-DSpark behoudt de 78 lagen van het basismodel en voegt vijf DSpark-draftlagen toe. De modelkaart van LG beweert dat zowel DSpark als MTP de generatie met ruwweg 3–5× versnellen — eigen cijfers, gericht op 'workloads met een lange horizon, zoals agentische taken', waar decode-latentie het knelpunt is. Hieruit volgen twee dingen. Ten eerste wordt speculatieve decodering een eersteklas functie van open frontiermodellen, in plaats van een servertruc die je er later aan vastschroeft. Ten tweede wordt de draft-stack van Deep​Seek de standaard — en dat is precies waarom een door de Zuid-Koreaanse overheid gesteund soeverein vlaggenschip dat met deze stack wordt uitgebracht, meer betekent dan het gebruikelijke 'nieuw model'-nieuws.

Het model achter de PR

K-EXAONE-2.0-750B-A37B-DSpark is een variant van K-EXAONE 2.0, het vervolg op LG's 236B K-EXAONE-lijn en Zuid-Korea's grootste in eigen land ontwikkelde basismodel, gebouwd onder het soevereine-AI-programma van de overheid. Het basismodel — 750B totale parameters, 37B actief, Mixture-of-Experts met 256 experts en 8 actief per token, een contextvenster van 262.144 tokens, tien talen, Apache 2.0 — werd op 31 juli 2026 op Hugging Face uitgebracht, geüpcycled van de 236B-voorganger in plaats van vanaf nul getraind.

LG's eigen benchmarkgemiddelden (24 benchmarks, 70,1 totaal) laten de verwachte vorm zien voor een Koreaans soeverein model: sterke gerapporteerde resultaten bij lange-contextretrieval, Koreaans-maatschappelijke veiligheid en agentische codering, naast cijfers die achterblijven bij Alibaba's Qw​en​3.5 op algemeen redeneren (83,5 versus 89,8 op MMLU-Pro, bijvoorbeeld). Nog niets daarvan is onafhankelijk geverifieerd. De DSpark-variant verandert geen van die scores — het is een serving-artefact, een snellere manier om hetzelfde model te draaien — en dat is precies waarom het opduikt in pull requests van inferentie-frameworks in plaats van in een aankondiging.

De serving-realiteit achter een 750B MoE

Hier is waar de DSpark-ondersteuning er echt toe doet. K-EXAONE-2.0-750B-A37B-DSpark is een checkpoint met 751 miljard parameters in BF16/F32, en LG's richtlijn is een minimum van twee nodes van acht NVIDIA H200 GPU's (16 GPU's, tensor-parallel 16). Op die schaal draait alles om decode-doorvoer — tokens per seconde, en de kosten van een lange agentische beurt — en dat is precies waar speculatieve decodering op aanvalt. Een 3–5× decode-versnelling, als die standhoudt buiten LG's testopstelling, is het verschil tussen een H200-cluster dat economisch is of niet. LG documenteert ook een generatie-instortingsprobleem op B200 GPU's dat de --disable-prefill-cuda-graph workaround nodig heeft totdat het is opgelost — een herinnering dat dit bleeding-edge serving is, niet kant-en-klaar.

Wat het kost, en hoe je het daadwerkelijk zou proberen

Geen enkele API biedt vandaag K-EXAONE 2.0 aan. De Hugging Face-kaart voor de DSpark-variant vermeldt nog steeds "dit model is door geen enkele inference-provider geïmplementeerd", en een voetafdruk van 16×H200 betekent dat het alleen een gehoste API bereikt wanneer iemand met die hardware besluit het te hosten. Dat is het echte knelpunt: het open-weights-grensgebied is steeds meer een serving-probleem, geen beschikbaarheidsprobleem.

Wanneer een provider het oppikt, zal de snelheidswinst door speculatieve decoding tot uiting komen in de prijs per token, en de overstapkosten om het uit te proberen zouden bijna nul moeten zijn als je applicatie al model-agnostisch is. Op OrcaRouter — één Open​AI-compatibel endpoint voor 200+ modellen, met de lijstprijs van de provider die zonder opslag wordt doorberekend — wordt een model dat op een bovenliggende provider terechtkomt een routeringswijziging in plaats van een herintegratie, en automatische failover betekent dat een gloednieuw 750B MoE-model dat traag of instabiel blijkt te zijn, terugvalt op een bekend goed model zonder dat er een incident ontstaat. Om expliciet te zijn: OrcaRouter host vandaag K-EXAONE-2.0-750B-A37B-DSpark niet, en geen enkele andere API die we konden vinden doet dat evenmin. Het doel van de routeringslaag is om voorbereid te zijn op de dag dat een van hen dat wel doet.

Wat we kijken

• De twee PR's die worden samengevoegd. #51558 (modelspecifiek) en #52197 (generieke configuratie) zijn beide open zonder goedkeuringen. Samenvoegen plus release is wat "DSpark-ondersteuning" verandert van pull requests naar vlaggen die je daadwerkelijk kunt doorgeven.

De reikwijdte van het generieke pad. Als #52197 wordt samengevoegd, wordt elk op qw​en​3 getypeerd DSparkDraftModel op Hugging Face laadbaar via configuratie — het verschil tussen DSpark als een lijst van goedgekeurde checkpoints en DSpark als een open standaard.

• Een eerste onafhankelijke score. Elke benchmark op de kaart wordt door LG uitgevoerd. Het eerste datapunt van Artificial Analysis of arena op een 750B Koreaanse MoE zal het eerste getal zijn dat niet door de leverancier is gepubliceerd.

DSpark voorbij Deep​Seek. LG en RadixArk zijn nu twee onafhankelijke productontwikkelaars van Deep​Seeks draft-methode, en het generieke vLLM-pad is een derde signaal dat de stack zich consolideert.

• Gekwantiseerde serving. LG levert FP8- en NVFP4-checkpoints van het basismodel; een gekwantiseerde DSpark-variant die op minder GPU's past, zou de economie sneller veranderen dan welke benchmark dan ook.

Veelgestelde vragen

Is K-EXAONE-2.0-750B-A37B-DSpark uitgebracht?

De gewichten staan op Hugging Face onder Apache 2.0, maar dit is geen lanceerverhaal: vLLM-ondersteuning bestaat uit twee openstaande, niet-gemergede pull-requests (#51558 en #52197), het snelheidswinstcijfer is van LG zelf, en geen enkele provider host het model. Wat hier met "bevestigd" wordt bedoeld is het servingpad — de generieke ondersteuning voor de DSparkDraftModel-configuratie bestaat nu in een publieke PR met een uitvoerbaar testplan — niet dat een uitgebrachte vLLM-build het al kan serveren.

Wat is het verschil tussen K-EXAONE-2.0-750B-A37B en de DSpark-variant?

De 78 lagen van het basismodel plus vijf DSpark-conceptlagen voor speculatieve decodering — dezelfde onderliggende gewichten, dezelfde benchmarks, en een serveerartefact dat sneller te decoderen is, in plaats van een ander model.

Is DSpark van LG of van DeepSeek?

DSpark is de open-source-methode voor speculatieve decodering van Deep​Seek, die ook wordt geleverd op Deep​Seek-V4-Pro-DSpark en Deep​Seek-V4-Flash-DSpark; LG is tot nu toe de meest prominente adopter, en RadixArk's Qw​en​3.8-2.4T-A95B-DSpark is een tweede onafhankelijke drafter die op dezelfde methode is gebaseerd. De modelkaart van LG claimt dezelfde 3–5× versnelling.

Kan ik K-EXAONE-2.0-750B-A37B-DSpark vandaag op mijn eigen hardware draaien?

Alleen door zelf te hosten: de richtlijn van LG is een minimum van zestien NVIDIA H200 GPU's, en standaardreleases van vLLM, SGLang en Transformers hebben nog steeds niet-gemergde forks of het lopende generieke config-pad nodig om de architectuur te herkennen. De DSparkDraftModel-ondersteuning in #52197 is het dichtst bij een gedeelde route, maar het is nog steeds een open pull request.

Wat dit de moeite waard maakt om te volgen, zijn niet de pull requests zelf — het is wat ze signaleren. Een Koreaans soeverein vlaggenschip met 750 miljard parameters, onder Apache-2.0, koos ervoor om Deep​Seek's speculatieve decoderingsstack te leveren, een onafhankelijk inferentiebedrijf heeft een DSpark-drafter gebouwd voor een max-class Qw​en​3.8, en vLLM antwoordt met een generiek configuratiepad in plaats van een per-model patch. Zo worden frontier open modellen werkelijkheid — niet op het moment dat de gewichten vrijkomen, maar op het moment dat de drafters mergen.