K-EXAONE-2.0-750B-A37B-DSpark: LG's 750B Korean MoE Is Coming to vLLM

On August 9, 2026, a pull request opened in the vLLM repository to add K-EXAONE-2.0-750B-A37B-DSpark — the speculative-decoding variant of LG AI Research's 750-billion-parameter Korean flagship. Four days later, on August 13, a second and more foundational PR made the leak concrete: vLLM now has a generic DSparkDraftModel config path, which maps any Hugging Face checkpoint that declares architectures=DSparkDraftModel with model_type=qw​en​3 onto the recognized Qw​en3DSparkModel, with a test plan that actually serves the RadixArk Qw​en​3.8-2.4T-A95B-DSpark drafter through the dspark spec method. The base K-EXAONE-2.0-750B-A37B shipped July 31 under Apache 2.0, and at launch vLLM could serve it with the MTP draft method but not with DSpark — the drafter LG also ships and claims is worth a 3–5× decode speedup. DSpark itself is Deep​Seek's method, the same semi-autoregressive drafter that runs on Deep​Seek-V4-Pro-DSpark and Deep​Seek-V4-Flash-DSpark, so the two PRs together are the clearest sign yet that Deep​Seek's speculative-decoding stack is becoming the open-weights default.

This is a what-we-know-so-far piece, not a launch story. Both pull requests are open and unmerged, the DSpark checkpoint has no independent benchmark, and LG's speedup figure is a vendor claim. Everything below is labeled accordingly. What is real today: the weights are on Hugging Face, the base model shipped, vLLM's DSpark spec-decoder already serves Deep​Seek and Kim​i checkpoints, and the generic config path that would let a third-party DSpark drafter load — the piece this leak was waiting for — is now sitting in a public pull request, tested but not shipped.

The short version

• PR #51558, opened August 9, 2026, adds K-EXAONE-2.0-750B-A37B-DSpark to vLLM; it is open with no approvals yet.

• PR #52197, opened August 13, 2026, lands generic DSparkDraftModel config support — architectures=DSparkDraftModel with model_type=qw​en​3, normalized to Qw​en3DSparkModel — and its test plan runs the RadixArk Qw​en​3.8-2.4T-A95B-DSpark drafter with the dspark spec method and seven spec tokens. Also open, also unmerged.

• DSpark is the EAGLE-family drafter Deep​Seek open-sourced and ships on Deep​Seek-V4-Pro-DSpark and Deep​Seek-V4-Flash-DSpark; LG is the highest-profile adoption by another lab so far, and RadixArk's Qw​en​3.8 drafter is a second independent one.

• The DSpark variant is the 78-layer 750B MoE plus five extra draft layers; LG claims DSpark and MTP each give roughly 3–5× decode speedup, aimed at long-horizon agentic workloads.

• At launch vLLM supported MTP for K-EXAONE 2.0 but not DSpark; the model-specific PR and the generic config path are the DSpark support landing.

• No provider hosts any K-EXAONE 2.0 checkpoint today, and every benchmark on the card is LG's own.

What the pull requests are (and aren't)

vLLM PR #51558, "[Model] Add K-EXAONE-2.0-750B-A37B-DSpark," was opened by lkm2835 — the same contributor behind the earlier K-EXAONE support in vLLM (#50524 for the base model) and in SGLang (#33648). It is a fork PR tagged with the new-model label, review was requested from the vLLM code owners, and it has no approvals yet. The description is three lines: it adds support for the DSpark checkpoint "developed by LG AI Research," links the Hugging Face model card and the K-EXAONE 2.0 technical report (arXiv 2608.04505), and references the earlier vLLM work in #50524.

The August 13 PR is different in kind. #52197, "Support DSpark configs with architectures=DSparkDraftModel + model_type=qw​en​3," adds a generic normalization layer: a Hugging Face draft checkpoint that declares itself a DSparkDraftModel on a qw​en​3 model type is remapped to a Qw​en3DSparkModel that vLLM's existing spec-decoder can load. The reference model in its test plan is RadixArk/Qw​en​3.8-2.4T-A95B-DSpark — a DSpark speculator for the max-class Qw​en​3.8-2.4T-A95B target — served with the dspark spec method and a seven-token spec window. The commit message is the whole idea: "architectures=DSparkDraftModel+model_type=qw​en​3." The point of the change is that a third-party DSpark drafter should be loadable by configuration rather than needing per-model code, which is how every supported DSpark checkpoint is wired in today. It is open and unmerged, same as #51558.

Read that status literally. "Support is being added" is not "support is available": until either PR merges and ships in a release, a standard vLLM build still will not load the DSpark variant. The model card itself says serving K-EXAONE 2.0 with DSpark is not currently supported on vLLM, which uses MTP instead. These two PRs are the steps that change that sentence — if and when they land.

Why DSpark is the real story here

The model name is doing a lot of work. "A37B" means 37 billion active parameters per token. "DSpark" is the speculative-decoding drafter Deep​Seek introduced this year: a semi-autoregressive, EAGLE-family draft model that proposes a block of tokens in a single pass and lets the target model verify them, so output quality is unchanged while generation gets faster. Deep​Seek open-sourced it and ships the drafter with its own Deep​Seek-V4-Pro-DSpark and Deep​Seek-V4-Flash-DSpark checkpoints, with community-reported speedups in the range of 60–85% for Flash and 57–78% for Pro versus a single-token MTP baseline.

What the new PR makes plain is that DSpark support in vLLM was never the open question. vLLM's own docs already list DSpark modules for Deep​Seek-V4, Kimi K3, and Gem​ma​4 checkpoints, and the team wrote up the design in a July engineering post. Every one of those integrations is wired in by hand, though — a blessed list of checkpoints, not a route anyone can use. The K-EXAONE checkpoint simply isn't on that list. #52197 is the attempt to make the route generic: one config mapping (DSparkDraftModel plus qw​en​3) instead of another bespoke model class, and a third-party drafter as the reference test case rather than a Deep​Seek model. That is why a leaked draft-checkpoint story is really an infrastructure story.

K-EXAONE-2.0-750B-A37B-DSpark keeps the base model's 78 layers and adds five DSpark draft layers, and LG's model card claims both DSpark and MTP accelerate generation by roughly 3–5× — its own numbers, aimed at "long-horizon workloads such as agentic tasks," where decode latency is the bottleneck. Two things follow. First, speculative decoding is becoming a first-class feature of open frontier models rather than a serving trick you bolt on afterward. Second, it is Deep​Seek's draft stack that is becoming the default — which is exactly why a Korean government-backed sovereign flagship shipping with it matters beyond the usual "new model" beat.

The model behind the PR

K-EXAONE-2.0-750B-A37B-DSpark is a variant of K-EXAONE 2.0, the sequel to LG's 236B K-EXAONE line and South Korea's largest homegrown foundation model, built under the government's sovereign-AI program. The base model — 750B total parameters, 37B active, Mixture-of-Experts with 256 experts and 8 active per token, a 262,144-token context window, ten languages, Apache 2.0 — shipped on Hugging Face on July 31, 2026, upcycled from the 236B predecessor rather than trained from scratch.

LG's own benchmark averages (24 benchmarks, 70.1 overall) show the expected shape for a Korean sovereign model: strong reported results in long-context retrieval, Korean-societal safety, and agentic coding, alongside figures that trail Alibaba's Qw​en​3.5 on general reasoning (83.5 vs 89.8 on MMLU-Pro, for instance). None of it is independently verified yet. The DSpark variant changes none of those scores — it is a serving artifact, a faster way to run the same model — which is exactly why it is surfacing in inference-framework pull requests rather than an announcement.

The serving reality behind a 750B MoE

Here is where the DSpark support actually matters. K-EXAONE-2.0-750B-A37B-DSpark is a 751-billion-parameter checkpoint in BF16/F32, and LG's guidance is a minimum of two nodes of eight NVIDIA H200 GPUs (16 GPUs, tensor-parallel 16). At that scale, decode throughput is the whole game — tokens per second, and the cost of a long agentic turn — and that is precisely what speculative decoding attacks. A 3–5× decode speedup, if it holds outside LG's harness, is the difference between an H200 cluster being economical or not. LG also documents a generation-collapse issue on B200 GPUs that needs the --disable-prefill-cuda-graph workaround until fixed — a reminder that this is bleeding-edge serving, not turnkey.

What it costs, and how you'd actually try it

No API serves K-EXAONE 2.0 today. The Hugging Face card for the DSpark variant still reads "this model isn't deployed by any inference provider," and a 16×H200 footprint means it reaches a hosted API only when someone with that hardware decides to host it. That is the real friction point: the open-weights frontier is increasingly a serving problem, not an availability problem.

When a provider does pick it up, the speculative-decoding speedup will show up in the price per token, and the switching cost to try it should be near zero if your application is already model-agnostic. On OrcaRouter — one Open​AI-compatible endpoint across 200+ models, with provider list price passed through at 0% markup — a model that lands on any upstream provider becomes a routing change rather than a re-integration, and automatic failover means a brand-new 750B MoE that turns out to be slow or unstable falls back to a known-good model without an incident. To be explicit: OrcaRouter does not host K-EXAONE-2.0-750B-A37B-DSpark today, and neither does any other API we could find. The point of the routing layer is being wired for the day one of them does.

What we're watching

• The two PRs merging. #51558 (model-specific) and #52197 (generic config) are both open with no approvals. Merge plus release is what turns "DSpark support" from pull requests into flags you can actually pass.

• The generic path's scope. If #52197 merges, any qw​en​3-typed DSparkDraftModel on Hugging Face becomes loadable by configuration — the difference between DSpark being a list of blessed checkpoints and DSpark being an open standard.

• A first independent score. Every benchmark on the card is LG-run. The first Artificial Analysis or arena data point on a 750B Korean MoE will be the first number not printed by the vendor.

• DSpark beyond Deep​Seek. LG and RadixArk are now two independent productizers of Deep​Seek's draft method, and the generic vLLM path is a third signal that the stack is consolidating.

• Quantized serving. LG ships FP8 and NVFP4 checkpoints of the base model; a quantized DSpark variant that fits on fewer GPUs would change the economics faster than any benchmark.

FAQ

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

The weights are on Hugging Face under Apache 2.0, but this is not a launch story: vLLM support is two open, unmerged pull requests (#51558 and #52197), the speedup figure is LG's own, and no provider hosts the model. What "confirmed" means here is the serving path — the generic DSparkDraftModel config support now exists in a public PR with a runnable test plan — not that any released vLLM build can serve it yet.

What's the difference between K-EXAONE-2.0-750B-A37B and the DSpark variant?

The base model's 78 layers plus five DSpark draft layers for speculative decoding — the same weights underneath, the same benchmarks, and a faster-to-decode serving artifact rather than a different model.

Is DSpark LG's or Deep​Seek's?

DSpark is Deep​Seek's open-sourced speculative-decoding method, also shipped on Deep​Seek-V4-Pro-DSpark and Deep​Seek-V4-Flash-DSpark; LG is the highest-profile adopter so far, and RadixArk's Qw​en​3.8-2.4T-A95B-DSpark is a second independent drafter built on the same method. LG's model card claims the same 3–5× speedup range.

Can I run K-EXAONE-2.0-750B-A37B-DSpark on my own hardware today?

Only by self-hosting: LG's guidance is a minimum of sixteen NVIDIA H200 GPUs, and standard releases of vLLM, SGLang, and Transformers still need unmerged forks or the pending generic config path to recognize the architecture. The DSparkDraftModel support in #52197 is the closest thing to a shared route, but it is still an open pull request.

What makes this worth watching is not the pull requests themselves — it is what they signal. A 750-billion-parameter, Apache-2.0 Korean sovereign flagship chose to ship Deep​Seek's speculative-decoding stack, an independent inference company has built a DSpark drafter for a max-class Qw​en​3.8, and vLLM is answering with a generic config path instead of a per-model patch. That is how frontier open models become real — not at the moment the weights drop, but at the moment the drafters merge.