K-EXAONE-2.0-750B-A37B-DSpark: LG เตรียมนำโมเดล MoE ภาษาเกาหลีขนาด 750B สู่ 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. One line in a changelog, but it closes a real gap. 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. The DSpark variant's whole reason to exist has effectively been stuck on SGLang. DSpark itself is Deep​Seek's method, the same semi-autoregressive drafter that runs on DeepSeek-V4-Pro-DSpark and DeepSeek-V4-Flash-DSpark, so this PR is also 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. The PR is 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, and vLLM support for the DSpark variant is now in progress.

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.

• DSpark is the EAGLE-family drafter Deep​Seek open-sourced and ships on DeepSeek-V4-Pro-DSpark and DeepSeek-V4-Flash-DSpark; LG is the highest-profile adoption by another lab so far.

• 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; this PR is 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 request is (and isn'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.

Read that status literally. "Support is being added" is not "support is available": until the 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. This PR is the step that changes that sentence — if and when it lands.

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 DeepSeek-V4-Pro-DSpark and DeepSeek-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.

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 Qwen3.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 an inference-framework pull request 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 OpenAI-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 PR merging. #51558 is open with no approvals. Merge plus release is what turns "DSpark support" from a pull request into a flag you can actually pass.

• 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. Deep​Seek already publishes DSpark drafters for other targets; LG is the highest-profile adopter by another lab. Whether the method becomes the open-weights default is worth watching on its own.

• 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.

คำถามที่พบบ่อย

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 an open, unmerged pull request (#51558), the speedup figure is LG's own, and no provider hosts the model.

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 DeepSeek-V4-Pro-DSpark and DeepSeek-V4-Flash-DSpark; LG is the highest-profile adopter so far, and its 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 to recognize the architecture.

What makes this worth watching is not the pull request itself — it is what the pull request signals. A 750-billion-parameter, Apache-2.0 Korean sovereign flagship chose to ship Deep​Seek's speculative-decoding stack, and the serving ecosystem is now catching up layer by layer: SGLang first, vLLM next. That is how frontier open models become real — not at the moment the weights drop, but at the moment the drafters merge.