K-EXAONE-2.0-750B-A37B-DSpark: LG:s 750B koreanska MoE kommer till vLLM

Den 9 augusti 2026 öppnades en pull request i vLLM-repositoriet för att lägga till K-EXAONE-2.0-750B-A37B-DSpark – den spekulativa avkodningsvarianten av LG AI Researchs koreanska flaggskepp med 750 miljarder parametrar. Fyra dagar senare, den 13 augusti, gjorde en andra och mer grundläggande PR läckan konkret: vLLM har nu en generisk DSparkDraftModel-konfigurationssökväg, som mappar vilken Hugging Face-checkpoint som helst som deklarerar architectures=DSparkDraftModel med model_type=qw​en​3 till den igenkända Qw​en3DSparkModel, med en testplan som faktiskt serverar RadixArk Qw​en​3.8-2.4T-A95B-DSpark-draftern genom dspark-specmetoden. Basmodellen K-EXAONE-2.0-750B-A37B släpptes den 31 juli under Apache 2.0, och vid lanseringen kunde vLLM servera den med MTP-draftmetoden men inte med DSpark – den drafter som LG också levererar och hävdar är värd en 3–5× avkodningsacceleration. DSpark i sig är Deep​Seeks metod, samma semi-autoregressiva drafter som körs på Deep​Seek-V4-Pro-DSpark och Deep​Seek-V4-Flash-DSpark, så de två PR:erna tillsammans är det tydligaste tecknet hittills på att Deep​Seeks spekulativa avkodningsstack blir standard för öppna vikter.

Det här är en artikel om vad vi vet hittills, inte en lanseringshistoria. Båda pull requestarna är öppna och inte sammanfogade, DSpark-checkpointen har inget oberoende benchmark, och LGs speedup-siffra är ett leverantörspåstående. Allt nedan är märkt därefter. Vad som är verkligt idag: vikterna finns på Hugging Face, basmodellen har släppts, vLLM:s DSpark-spec-avkodare serverar redan Deep​Seek- och Kim​i-checkpoints, och den generiska konfigurationsvägen som skulle låta en tredjeparts-DSpark-drafter ladda — det som denna läcka väntade på — finns nu i en offentlig pull request, testad men inte levererad.

Den korta versionen

• PR #51558, öppnad 9 augusti 2026, lägger till K-EXAONE-2.0-750B-A37B-DSpark i vLLM; den är öppen utan några godkännanden ännu.

• PR #52197, öppnad 13 augusti 2026, inför generiskt stöd för DSparkDraftModel-konfiguration — architectures=DSparkDraftModel med model_type=qw​en​3, normaliserat till Qw​en3DSparkModel — och dess testplan kör RadixArk Qw​en​3.8-2.4T-A95B-DSpark-draftaren med dspark-spec-metoden och sju spec-tokens. Även öppen, även ej sammanfogad.

• DSpark är den drafter i EAGLE-familjen som Deep​Seek har släppt som öppen källkod och som levereras med Deep​Seek-V4-Pro-DSpark och Deep​Seek-V4-Flash-DSpark; LG är den hittills mest uppmärksammade adoptionen från ett annat labb, och RadixArks Qw​en​3.8-drafter är en andra oberoende sådan.

• DSpark-varianten är den 78-lagers 750B MoE-modellen plus fem extra draftlager; LG hävdar att DSpark och MTP vardera ger ungefär 3–5× snabbare avkodning, inriktade på långsiktiga agentiska arbetsbelastningar.

• Vid lanseringen stödde vLLM MTP för K-EXAONE 2.0 men inte DSpark; den modellspecifika PR:n och den generiska konfigurationsvägen är där DSpark-stödet landar.

• Ingen leverantör tillhandahåller någon K-EXAONE 2.0-checkpoint idag, och varje riktmärke på kortet är LGs eget.

Vad pull requests är (och inte är)

vLLM PR #51558, ”[Model] Add K-EXAONE-2.0-750B-A37B-DSpark”, öppnades av lkm2835 — samma bidragsgivare bakom det tidigare K-EXAONE-stödet i vLLM (#50524 för basmodellen) och i SGLang (#33648). Det är en fork-PR märkt med new-model-etiketten, granskning begärdes från vLLM:s kodägare, och den har inga godkännanden ännu. Beskrivningen är tre rader: den lägger till stöd för DSpark-checkpointen ”utvecklad av LG AI Research”, länkar till Hugging Face-modellkortet och K-EXAONE 2.0:s tekniska rapport (arXiv 2608.04505), och refererar till det tidigare vLLM-arbetet i #50524.

PR:en den 13 augusti är av annat slag. #52197, "Support DSpark configs with architectures=DSparkDraftModel + model_type=qw​en​3," lägger till ett generiskt normaliseringslager: en Hugging Face-draftcheckpoint som deklarerar sig som en DSparkDraftModel på en qw​en​3-modelltyp mappas om till en Qw​en3DSparkModel som vLLM:s befintliga spec-avkodare kan läsa in. Referensmodellen i testplanen är RadixArk/Qw​en​3.8-2.4T-A95B-DSpark — en DSpark-spekulator för målmodellen Qw​en​3.8-2.4T-A95B i maxklassen — serverad med dspark-specmetoden och ett spec-fönster på sju token. Commit-meddelandet är hela idén: "architectures=DSparkDraftModel+model_type=qw​en​3." Poängen med ändringen är att en tredjeparts-DSpark-drafter ska kunna läsas in via konfiguration snarare än att kräva per-modell-kod, vilket är hur varje DSpark-checkpoint som stöds är kopplad idag. Den är öppen och inte sammanslagen, precis som #51558.

Läs den statusen bokstavligt. "Stöd läggs till" är inte "stöd finns tillgängligt": tills någon av PR:erna slås samman och levereras i en release, kommer en standard-vLLM-bygge fortfarande inte att kunna läsa in DSpark-varianten. Modellkortet självt säger att serving av K-EXAONE 2.0 med DSpark inte för närvarande stöds på vLLM, som använder MTP istället. Dessa två PR:er är stegen som ändrar den meningen — om och när de landar.

Varför DSpark är den verkliga historien här

Modellnamnet gör en hel del arbete. "A37B" betyder 37 miljarder aktiva parametrar per token. "DSpark" är den drafter för spekulativ avkodning som Deep​Seek introducerade i år: en semiautoregressiv draftmodell i EAGLE-familjen som föreslår ett block av token i en enda genomgång och låter målmodellen verifiera dem, så utdatakvaliteten förblir oförändrad medan genereringen blir snabbare. Deep​Seek släppte den med öppen källkod och levererar draftern med sina egna Deep​Seek-V4-Pro-DSpark- och Deep​Seek-V4-Flash-DSpark-checkpoints, med community-rapporterade hastighetsförbättringar på 60–85 % för Flash och 57–78 % för Pro jämfört med en singeltoken-MTP-baslinje.

Vad den nya PR:n gör tydligt är att DSpark-stöd i vLLM aldrig var den öppna frågan. vLLM:s egna dokument listar redan DSpark-moduler för Deep​Seek-V4, Kimi K3 och Gem​ma​4-checkpoints, och teamet beskrev designen i ett tekniskt inlägg i juli. Var och en av dessa integrationer är dock manuellt inkopplad — en godkänd lista av checkpoints, inte en väg som vem som helst kan använda. K-EXAONE-checkpointen finns helt enkelt inte på den listan. #52197 är försöket att göra vägen generisk: en konfigurationsmappning (DSparkDraftModel plus qw​en​3) istället för en annan skräddarsydd modellklass, och en tredjeparts-drafter som referenstestfall snarare än en Deep​Seek-modell. Det är därför en historia om ett läckt draft-checkpoint egentligen är en infrastrukturhistoria.

K-EXAONE-2.0-750B-A37B-DSpark behåller basmodellens 78 lager och lägger till fem DSpark-utkastlager, och LG:s modellkort hävdar att både DSpark och MTP accelererar genereringen med ungefär 3–5× — dess egna siffror, riktade mot "långsiktiga arbetsbelastningar som agentiska uppgifter," där avkodningslatensen är flaskhalsen. Två saker följer. För det första håller spekulativ avkodning på att bli en förstklassig funktion hos öppna frontmodeller snarare än ett serveringsknep som du kopplar på i efterhand. För det andra är det Deep​Seeks utkaststack som håller på att bli standarden — vilket är precis varför en sydkoreansk regeringsstödd suverän flaggskeppsmodell som levereras med den betyder något utöver den vanliga "ny modell"-bevakningen.

Modellen bakom PR:en

K-EXAONE-2.0-750B-A37B-DSpark är en variant av K-EXAONE 2.0, uppföljaren till LGs 236B K-EXAONE-serie och Sydkoreas största inhemskt utvecklade basmodell, byggd inom regeringens suveräna AI-program. Basmodellen — 750B totala parametrar, 37B aktiva, Mixture-of-Experts med 256 experter och 8 aktiva per token, ett kontextfönster på 262 144 token, tio språk, Apache 2.0 — släpptes på Hugging Face den 31 juli 2026, uppcyklad från 236B-föregångaren snarare än tränad från grunden.

LGs egna genomsnittliga benchmarkresultat (24 benchmarks, 70,1 totalt) uppvisar den förväntade profilen för en koreansk suverän modell: starka rapporterade resultat inom hämtning med lång kontext, koreansk samhällssäkerhet och agentisk kodning, tillsammans med siffror som hamnar efter Alibabas Qw​en3.5 när det gäller allmän resonemangsförmåga (83,5 mot 89,8 på MMLU-Pro, till exempel). Inget av detta är ännu oberoende verifierat. DSpark-varianten förändrar inte någon av dessa siffror – den är en serveringsartefakt, ett snabbare sätt att köra samma modell – vilket är exakt varför den dyker upp i pull requests för inferensramverk snarare än i ett tillkännagivande.

Serveringsverkligheten bakom en 750B MoE

Det är här som DSpark-stödet faktiskt spelar roll. K-EXAONE-2.0-750B-A37B-DSpark är en checkpoint med 751 miljarder parametrar i BF16/F32, och LG:s rekommendation är minst två noder med åtta NVIDIA H200 GPU:er vardera (16 GPU:er, tensor-parallell 16). I den skalan är avkodningsgenomströmningen hela spelet — tokens per sekund och kostnaden för en lång agentisk runda — och det är precis det som spekulativ avkodning angriper. En 3–5× snabbare avkodning, om den håller utanför LG:s testmiljö, är skillnaden mellan att ett H200-kluster är lönsamt eller inte. LG dokumenterar också ett problem med genereringskollaps på B200 GPU:er som kräver workarounden --disable-prefill-cuda-graph tills det är åtgärdat — en påminnelse om att detta är banbrytande servering, inte nyckelfärdig.

Vad det kostar, och hur du faktiskt skulle prova det

Inget API tillhandahåller K-EXAONE 2.0 idag. Hugging Face-kortet för DSpark-varianten säger fortfarande "den här modellen är inte driftsatt av någon inferensleverantör," och ett fotavtryck på 16×H200 innebär att den når ett hostat API endast när någon med den hårdvaran bestämmer sig för att hosta den. Det är den verkliga friktionspunkten: open-weights-fronten är i allt högre grad ett serveringsproblem, inte ett tillgänglighetsproblem.

När en leverantör väl tar upp modellen kommer den prestandaökning som speculative decoding ger att synas i priset per token, och byteskostnaden för att prova det bör vara nära noll om din applikation redan är modellagnostisk. På OrcaRouter — en Open​AI-kompatibel slutpunkt som täcker 200+ modeller, där leverantörens listpris förs vidare utan påslag — blir en modell som hamnar hos en uppströmsleverantör en routingändring snarare än en nyintegration, och automatisk failover innebär att en helt ny 750B MoE som visar sig vara långsam eller instabil faller tillbaka till en beprövad modell utan incident. För att vara tydlig: OrcaRouter hostar inte K-EXAONE-2.0-750B-A37B-DSpark idag, och det gör inte heller något annat API vi kunde hitta. Poängen med routinglagret är att vara redo för den dag en av dem gör det.

Vad vi tittar på

• De två PR:arna som slås samman. #51558 (modellspecifik) och #52197 (generisk konfiguration) är båda öppna utan godkännanden. Merge plus release är det som förvandlar "DSpark support" från pull requests till flaggor du faktiskt kan skicka.

• Den generiska sökvägens omfattning. Om #52197 slås samman, blir alla qw​en​3-typade DSparkDraftModel på Hugging Face laddningsbara via konfiguration — skillnaden mellan att DSpark är en lista över godkända kontrollpunkter och att DSpark är en öppen standard.

• Ett första oberoende resultat. Varje benchmark på kortet är LG-körd. Den första datapunkten från Artificial Analysis eller arena på en 750B koreansk MoE kommer att vara den första siffran som inte publicerats av leverantören.

• DSpark bortom Deep​Seek. LG och RadixArk är nu två oberoende produktiserare av Deep​Seeks draft-metod, och den generiska vLLM-vägen är en tredje signal på att stacken konsolideras.

• Kvantiserad servering. LG levererar FP8- och NVFP4-checkpoints av basmodellen; en kvantiserad DSpark-variant som får plats på färre GPU:er skulle förändra ekonomin snabbare än något riktmärke.

Vanliga frågor

Är K-EXAONE-2.0-750B-A37B-DSpark släppt?

Vikterna finns på Hugging Face under Apache 2.0, men detta är ingen lanseringsnyhet: vLLM-stödet är två öppna, ej sammanslagna pull requests (#51558 och #52197), snabbningssiffran är LG:s egen, och ingen leverantör är värd för modellen. Vad som menas med "bekräftat" här är serveringsvägen — det generiska DSparkDraftModel-konfigurationsstödet finns nu i en offentlig PR med en körbar testplan — inte att något släppt vLLM-bygge kan servera den ännu.

Vad är skillnaden mellan K-EXAONE-2.0-750B-A37B och DSpark-varianten?

Grundmodellens 78 lager plus fem DSpark-draftlager för spekulativ avkodning — samma vikter under, samma riktmärken, och en serveringsartefakt som är snabbare att avkoda snarare än en annan modell.

Är DSpark LG:s eller DeepSeeks?

DSpark är Deep​Seeks öppen källkod-metod för spekulativ avkodning, även levererad med Deep​Seek-V4-Pro-DSpark och Deep​Seek-V4-Flash-DSpark; LG är den mest uppmärksammade användaren hittills, och RadixArks Qw​en​3.8-2.4T-A95B-DSpark är en andra oberoende drafter byggd på samma metod. LGs modellkort hävdar samma 3–5× hastighetsförbättring.

Kan jag köra K-EXAONE-2.0-750B-A37B-DSpark på min egen hårdvara idag?

Endast genom egen hosting: LGs vägledning är minst sexton NVIDIA H200 GPU:er, och standardutgåvorna av vLLM, SGLang och Transformers behöver fortfarande omatchade forks eller den väntande generiska konfigurationsvägen för att känna igen arkitekturen. Stödet för DSparkDraftModel i #52197 är det närmaste en gemensam väg, men det är fortfarande en öppen pull request.

Det som gör detta värt att se är inte själva pull requests — utan vad de signalerar. En 750-miljardersparameter, Apache-2.0 koreansk suverän flaggskeppsmodell valde att leverera Deep​Seeks spekulativa avkodningsstack, ett oberoende inferensföretag har byggt en DSpark-drafter för en max-klass Qw​en​3.8, och vLLM svarar med en generisk konfigurationssökväg istället för en per-modell patch. Så blir frontlinjens öppna modeller verkliga — inte i det ögonblick vikterna släpps, utan i det ögonblick drafterna slås samman.