NVIDIA Dynamo Recipes for Korean Open Models: A.X K2, K-EXAONE 2.0, Solar Open 2, Motif-3

NVIDIA said on November 8, 2026 that it is releasing Dynamo deployment recipes for four Korean open models, and that they deliver "up to 2x performance out of the box" on B200 GPUs. The public recipe docs back parts of that with real layouts and numbers. They do not show a 2x comparison against a baseline. This post separates the claim from what the docs let you check.

The announcement is part of a larger Korea package. For the sovereign AI, chips and agent side, see our post on NVIDIA and Korea's expanded sovereign AI collaboration.

TL;DR: claimed versus documented

What does NVIDIA's announcement say?

NVIDIA's post, "NVIDIA Dynamo Recipes Bring Korea's Leading Open Models to Production", is four short paragraphs. It names the four models and explains the problem: models that grow beyond one GPU must be split across several, which needs careful coordination of request routing and communication. It describes Dynamo as an open source, distributed inference-serving framework built for multi-node deployment at data center scale.

Then comes the claim. Optimized for B200 GPUs, the recipes "take the guesswork out of deployment, delivering up to 2x performance out of the box". The stated goal is to help developers bring Korea's open models into production faster and turn them into broadly accessible "AI for All" services. The post gives no benchmark table, no baseline and no test date.

"Up to" matters. It tells you the best case across some set of tests, not what your cluster will see. When a vendor does not name the baseline, the number cannot be reproduced. That is why we looked at the recipe pages in the Dynamo documentation and repository.

What is Dynamo, in one paragraph?

According to the ai-dynamo/dynamo repository, Dynamo is an Apache 2.0 licensed orchestration layer that sits above inference engines and coordinates them across GPUs and nodes. It does not replace SGLang, TensorRT-LLM or vLLM. Its features include disaggregated prefill and decode into separately scalable GPU pools, KV-aware routing, a KV Block Manager that offloads cache across GPU, CPU, SSD and remote storage, and an SLA-driven planner. If these terms are new, read our explainers on the KV cache and speculative decoding. For how Dynamo handles failures, see the Dynamo Shadow Engine failover post.

A "recipe" here is a set of Kubernetes manifests, settings and benchmark notes for one model on one hardware layout. The repository's recipe index lists dozens of them.

A chip under a cloud outline, showing how NVIDIA Dynamo recipes place model serving across GPUs

K-EXAONE 2.0 from LG AI Research: what the docs say

The K-EXAONE 2.0 recipe page describes the checkpoint LGAI-EXAONE/K-EXAONE-2.0-750B-A37B-NVFP4.

• Size: about 764.5 billion parameters, roughly 37 billion active per token, with 256 experts and top-8 routing.
• Precision: NVFP4 weights with an FP8 KV cache. The checkpoint is about 530 GB on disk.
• Context: a native 262,144-token window.
• Speculative decoding: multi-token prediction with a draft length of 2.
• Engine: vLLM.

The page lists two topologies. The recommended one is aggregated on 4x B200 with tensor parallelism of 4. The other is disaggregated 1P1D on 8x B200, with KV transfer over NIXL and UCX on InfiniBand RDMA.

The benchmark uses a Mooncake chat trace of 1,805 requests, with 8K input and 1K output tokens.

Read this carefully. The docs say the disaggregated setup matches aggregated per-GPU throughput with twice the GPUs, and they recommend it for lower per-token latency and independent scaling, not for throughput. The page also admits that measured KV reuse is 8.8%, against about 70% designed, because the working set exceeds the KV capacity at TP4. And 38 requests exceeded the context limit and were excluded.

Two settings are worth copying into your notes. The page says the MoE backend must be pinned to FLASHINFER_CUTLASS, because vLLM's automatic choice "silently corrupts long outputs". It also says to use the Dynamo-specific reasoning and tool-call parser flags, because the plain vLLM flags do not reach the Dynamo frontend. First start takes 40 to 120 minutes, and silence in the logs is not a hang.

None of this is a 2x claim. It is an honest benchmark of one model and one trace.

A.X K2 from SK Telecom: what the docs say

The A.X-K2 recipe page lists three checkpoints: skt/A.X-K2 for H200, skt/A.X-K2-NVFP4 for B200, and skt/A.X-K2-EAGLE3 as a draft model. The B200 path uses NVFP4 weights with an FP8 KV cache. Both paths use EAGLE3 speculative decoding with three tokens. The page does not state the parameter count.

On B200 at concurrency 16, with a synthetic EAGLE3 acceptance length of 2.12, the page reports:

Note the word "synthetic" for the acceptance length. The H200 section uses real EAGLE3 acceptance. Its numbers show that the best layout flips with load: at concurrency 64, disaggregated reaches 66.92 tok/s per GPU against 60.67 for aggregated, but at concurrency 128 the disaggregated time to first token reaches 28,194 ms. The page therefore recommends aggregated at low and at very high concurrency, and disaggregated only around concurrency 64.

Solar Open 2 and Motif-3: still experimental

The recipe index lists Solar-Open2-250B-NVFP4 from Upstage as experimental. The aggregated layout is 4x B200 with two replicas at TP2. The disaggregated layout is 8x B200 with one prefill worker at TP4 with expert parallelism and two decode workers at TP2.

Motif-3 NVFP4 is also experimental, on 2x B200 aggregated or 8x B200 in a 3P1D disaggregated layout. Our searches found sources that disagree on the exact Motif-3 layout across releases, so check the repository at the commit you use. The index marks experimental entries as possibly needing extra setup, such as container patching.

The word "experimental" sits oddly beside "bring to production". It does not make the recipes useless. It tells you to test before you commit.

So where would 2x come from?

We could not find a 2x number in the docs. We can list plausible sources, and mark them as our reading, not NVIDIA's:

1. Disaggregated versus aggregated serving at the right concurrency, as in the A.X K2 H200 table, where disaggregated gains about 10% per GPU at concurrency 64.
2. NVFP4 versus higher-precision weights, which cuts memory traffic.
3. Speculative decoding with MTP or EAGLE3, which raises tokens per second per user.
4. Versus a naive deployment with default flags, where a setting like the MoE backend choice matters a great deal.

Any of these could be the baseline. NVIDIA does not say. The repository also has a README note on features such as KV-aware routing "2x faster TTFT", a separate claim for a different feature. Until NVIDIA names a baseline and workload, treat "up to 2x" as marketing for the best case.

How to try a recipe

1. Install the Dynamo Kubernetes Platform on a cluster with the GPU operator and matching B200 nodes.
2. Create a namespace and a secret named hf-token-secret with your Hugging Face token.
3. Set the storage class in model-cache.yaml, apply the PVC and the model download job, and wait for it. For K-EXAONE 2.0 the docs say to allow up to 6 hours.
4. Apply the aggregated or disaggregated manifest from the recipe folder.
5. Port-forward the frontend on port 8000 and send a test request. For reasoning models, use a generous max_tokens. The K-EXAONE page warns that a short cap can return null content on a healthy deployment.
6. Benchmark your own traffic before you trust any number, including ours.

If you only want to run a model on one box, this is the wrong tool. Dynamo targets multi-GPU, multi-node serving. For small local serving, see our post on a local inference server in Rust on DGX Spark.

What this means for builders

• If you serve Korean-language workloads, the recipes save days of trial and error on layouts, parser flags and memory settings.
• If you pick between aggregated and disaggregated, the docs show no universal winner. Measure at your concurrency.
• If you buy hardware, note the footprints: 4 to 12 B200 GPUs per replica for the larger models. These are not small deployments.
• If you evaluate vendor claims, ask for the baseline, the trace and the date. NVIDIA's own docs give more than its blog does. For another example of the vendor's efficiency claims, see our explainer on NVIDIA's five co-design levers and the 30x per megawatt claim.

How to verify and what to watch

• Open the A.X-K2 and K-EXAONE 2.0 pages and compare the tables above with the current versions.
• Watch the repository for Solar Open 2 and Motif-3 to move from experimental to benchmarked.
• Look for a third-party benchmark that names a baseline. That is what would confirm or reject "up to 2x".

Related reading

• NVIDIA and Korea's expanded sovereign AI collaboration
• NVIDIA Dynamo Shadow Engine and 7-second failover
• What is the KV cache?
• What is speculative decoding?
• NVIDIA's five co-design levers explained
• South Korea's AI ecosystem and HyperCLOVA
• NVIDIA planned investments in Point2, Motif, RLWRLD and Upstage

Details are accurate as of November 9, 2026. Recipe pages are labeled "dev" and change often.