K-EXAONE 2.0 750B-A37B: VRAM, Specs & Self-Host Cost (2026)

K-EXAONE 2.0 750B-A37B is a 750B-total, 37B-active MoE whose weights alone run roughly 1.5TB at BF16, ~750GB at FP8, and 375-420GB even at 4-bit. It does not fit on a single consumer GPU, and BF16 does not fit on a single 8-GPU node either — real deployment needs a multi-node cluster with headroom for KV cache and activations. The license is Apache 2.0 (commercial use allowed), and Japanese is one of the ten supported languages — both matter more in practice than the raw benchmark numbers. Here is what shipped, the per-precision size math, what running it actually takes, and the smaller fallback.

K-EXAONE 2.0 is an open-weight LLM that LG AI Research released on Hugging Face on July 31, 2026. It is the second generation of South Korea's government-backed "Sovereign AI Foundation Model Project," led by the Ministry of Science and ICT, and the repository is LGAI-EXAONE/K-EXAONE-2.0-750B-A37B. It is a 750B-total, 37B-active MoE with 78 layers (2 dense + 76 sparse + 1 MTP), 256 experts with 8 activated per token plus one always-on shared expert. The knowledge cutoff is 2025 Q2.

Weight size is roughly parameters times bytes-per-parameter. For 750B parameters: at BF16 (2 bytes/parameter), 750B x 2 bytes ≈ 1.5TB; at FP8 (1 byte/parameter), 750B x 1 byte ≈ 750GB; at NVFP4-class 4-bit (0.5 bytes/parameter), 750B x 0.5 bytes ≈ 375GB in theory. 4-bit formats carry per-block scaling metadata on top of that, so the safer real-world estimate is 375-420GB. These are floors on weights alone — KV cache, activations, and communication buffers all add on top in a real deployment.

- KV cache: with a 262,144-token context actually in use, this becomes the dominant factor and scales with concurrency
- Activations: intermediate tensors during inference occupy GPU memory on top of the weights
- Communication buffers: multi-node tensor-parallel / expert-parallel setups need memory reserved for inter-node traffic
- Fragmentation: real deployments never hit the theoretical number exactly and need margin

The GPU counts above are only the floor for fitting the weights. Rather than reading them as "it runs on N GPUs," treat them as a starting point — real workloads need a somewhat larger node count once KV cache and activations are added. BF16 and FP8 in particular assume multi-node tensor-parallel or expert-parallel setups; having enough aggregate memory is necessary but not sufficient.

LG also released a smaller K-EXAONE-236B-A23B, along with a quantized K-EXAONE-236B-A23B-GGUF variant. Applying the same formula to 236B parameters: BF16 gives 236B x 2 bytes ≈ 472GB, FP8 gives 236B x 1 byte ≈ 236GB, and 4-bit gives 236B x 0.5 bytes ≈ 118GB (roughly 130GB in practice with metadata) — a meaningfully more approachable set of numbers than the 750B version. If you want to try this on a workstation or a Mac, the 236B-A23B GGUF build is the realistic starting point, not 750B-A37B. Size your VRAM with the VRAM calculator.

The practical edge of K-EXAONE 2.0 is less about raw performance and more about license and language coverage. Apache 2.0 is a permissive license that allows commercial use, modification, and redistribution with few restrictions on on-premises or in-country hosting — a real factor for sectors that cannot send data to an external provider (government, finance, healthcare). Japanese being one of the ten officially supported languages also leaves room to evaluate this Korean-origin model for Japanese-language work.

This table lines up published specs — total parameters, active parameters, license, and context length — and is not a performance ranking. Kimi K3 and DeepSeek V4 are larger by total parameter count, and K-EXAONE 2.0 is comparatively smaller at 750B, but its permissive Apache 2.0 license and ten-language coverage including Japanese are real selection criteria against these other open-weight models.

Framework support for K-EXAONE 2.0 is uneven. SGLang and vLLM both require the add-k-exaone2 custom fork branch called out on the official distribution page, and standard releases may not run the model correctly yet. Transformers is supported directly, and llama.cpp usage is documented via quantized (GGUF) builds.

- vLLM: requires the add-k-exaone2 custom fork branch; timing of an upstream merge is not confirmed as of this writing
- SGLang: also requires the add-k-exaone2 custom fork branch
- Transformers: supported directly — a reasonable starting point to confirm behavior
- llama.cpp: usage is via quantization (GGUF); derivative repos like 236B-A23B-GGUF are the reference point

In short, you cannot drop these weights into a standard production vLLM or SGLang cluster on day one. Tracking a custom fork adds real operational overhead, so the practical sequence is to validate behavior on Transformers or a quantized build first, and move to production only once the add-k-exaone2 branch has stabilized.

LG AI Research's headline benchmark figures are MMLU-Pro 83.5, SWE Bench Verified 68.2, long-context OpenAI-MRCR 94.4, and safety benchmark KGC-Safety 99.8. The average across 24 benchmarks is reported at 70.1, up from 63.3 for the prior (1.0) generation. All of these are vendor-published figures; evaluate on your own tasks separately.

K-EXAONE 2.0 750B-A37B is a large MoE whose weights alone run ~1.5TB at BF16, ~750GB at FP8, and 375-420GB even at 4-bit — it does not run on a single consumer GPU. If you want to try it locally, start from the 236B-A23B GGUF build; if you want full performance in production, plan for a multi-node GPU cluster at BF16/FP8 and an operational process for tracking the vLLM/SGLang custom fork.

At the same time, the permissive Apache 2.0 license and ten-language support including Japanese give it real practical value for organizations weighing on-premises or in-country deployment where data cannot leave their perimeter. Figures, runtime support, and derivative repos may still change shortly after release, so check the Hugging Face distribution page directly before committing to a deployment plan.