NVIDIA packages Dynamo recipes for four Korean AI models
NVIDIA has announced optimized Dynamo recipes for four Korean AI models: SK Telecom’s A.X K2, LG AI Research’s K-EXAONE 2.0, Upstage’s Solar Open 2 and Motif Technologies’ Motif-3. The package targets teams turning model weights into services on NVIDIA B200 infrastructure.
The announcement is dated November 8, with the AI Day Seoul live blog recording it at 9 p.m. Pacific, or November 9 at 05:00 UTC. This is deployment coverage for existing models. It does not establish that all four models or their recipe code first became available that day.
What a Dynamo recipe gives a deployment team
The public recipe index connects checkpoints with serving configurations and benchmark instructions. Aggregated serving keeps prompt processing and response generation together. Disaggregated serving separates those stages so operators can scale them independently. That flexibility comes with more infrastructure to coordinate.
The documented B200 configurations differ enough that hardware planning should come before downloading. These are multi GPU deployment guides, not desktop installation shortcuts.
| Model recipe | Aggregated B200s | Disaggregated B200s |
|---|---|---|
| A.X K2 | 8 | 12 |
| K-EXAONE 2.0 | 4 | 8 |
| Solar Open2 250B | 4 | 8 |
| Motif-3 | 2 | 8 |
The table reflects NVIDIA’s development documentation checked November 9. Motif’s recipe is marked experimental. A.X also has H200 profiles with different weight and cache precision, so a B200 result should not be carried over to that hardware.
Read the performance claim alongside the conditions
NVIDIA says the optimized recipes improve performance by up to 2x. Its short announcement does not identify the baseline or workload behind that headline. The individual recipe results answer narrower questions.
K-EXAONE’s documented four-GPU setup delivers 87 output tokens per second per GPU, compared with 85 for the eight-GPU disaggregated setup. NVIDIA recommends the latter for lower per token latency and separate scaling of the two serving stages, rather than greater throughput per GPU. The tests replay 1,805 requests under latency gates, excluding 38 that exceed the context limit.
Solar’s figures are 216.88 and 206.20 output tokens per second per GPU for its aggregated and disaggregated profiles. They use a 15 percent subset of an internal chat trace. The benchmark does not clear existing worker caches, which matters when comparing those results with a deployment starting from an empty cache.
Motif’s published performance uses a synthetic speculative decoding acceptance setting. It does not measure real acceptance or output quality, although the default deployment manifests use real verification. A.X’s B200 results also use synthetic EAGLE3 acceptance. ByteForward has not independently benchmarked these configurations.
For a fair comparison, keep the model, request lengths and quality checks fixed. Record the number of GPUs, concurrent requests, cache state, time to first token and generation speed separately. A higher total serving capacity can still leave each GPU doing no more useful work.
Correctness and compatibility come before tuning
The recipes require Kubernetes, Dynamo’s operator, shared model storage and access to the relevant checkpoints. Disaggregated layouts add networking requirements such as RDMA. Review the supplied fabric configuration against the actual cluster instead of assuming every manifest is portable.
K-EXAONE pins a specific MoE kernel for correctness. Solar lists API compatibility limits, including parameters that can be accepted without taking effect. Successful startup is therefore only the first check. Run representative requests through the full application and inspect the returned answers and tool behavior.
Teams sharing a cluster also need a capacity policy. Our guide to NVIDIA’s open Run ai stack examines scheduling, quotas and GPU sharing. Those decisions sit alongside a serving recipe and affect how much hardware a workload can actually obtain.
Check the license for the exact checkpoint
The verified cards identify A.X K2 NVFP4 and K-EXAONE 2.0 NVFP4 as Apache 2.0, and Motif-3 NVFP4 as MIT. The Nota quantized Solar checkpoint instead uses the custom Upstage Solar License, with naming and attribution requirements for derivative models. Its card also requires Blackwell hardware for NVFP4 execution.
The useful outcome is a concrete starting point for an evaluation. Choose the checkpoint and license, match the hardware, then test the serving layout against your own latency and correctness requirements. The documentation makes those decisions easier to inspect, but it does not guarantee twice the speed or a lower production bill.
