Solar Open 2 Puts a 250B Agent Model on Two H200s

Upstage has released Solar Open 2, a 250-billion-parameter open-weight agent model that activates 15 billion parameters per token and can run quantized on two H200 GPUs. That means only 6% of its nominal weights are active at once, making it a credible Korean-office pilot for enterprises that need local control—not a universal replacement for stronger coding models.

The official Solar Open 2 launch includes weights, a commercial-use license, serving guidance, and a technical report. Unlike future-tense “open” launches, the artifacts are inspectable now on the Hugging Face model card. The operating decision is therefore testable: Korean organizations can compare a private two-GPU deployment against closed APIs this quarter.

Sparse weights meet dense Korean work

Fifteen billion divided by 250 billion yields the headline 6% activation ratio. Solar Open 2 routes each token through eight of 320 experts plus one shared expert. Quantization lowers the recommended deployment from four H200s in BF16 to two H200s. That is still expensive infrastructure, but it is procurement a large enterprise can reason about rather than the 64-plus accelerators recommended for production Kimi K3 serving.

The model’s deeper efficiency claim is architectural. The Solar Open 2 technical report interleaves three linear-attention layers with one softmax layer across a 48-layer stack. Upstage says this supplies a million-token context at roughly one quarter of the memory and computation of an all-softmax design. In a controlled proxy, the hybrid architecture reached an MMLU target after 210 billion training tokens; the all-softmax baseline needed 671 billion. Divide 671 by 210 and the result is 3.2× training-token efficiency at that target.

Upstage also transferred 5.69 billion compatible parameters from Solar Open 1—only 2.3% of the new model—then trained the changed experts and attention components. In a proxy experiment, that warm start reached the target loss in 12.6 billion tokens versus 21.5 billion from random initialization, about 41% fewer. For model builders, that may be the most transferable result: preserve the semantic skeleton that survives an architecture change instead of paying to relearn it.

The Korean advantage is more concrete. Upstage’s tokenizer uses about 24% fewer tokens than the best global model in its Korean office-work comparison. Its Ko-GDPval score reached 86.8, effectively tied with a 1.6-trillion-parameter DeepSeek model at 86.9. Solar’s total parameter count is 84.4% lower; its active count is roughly one-third. This is exactly where sovereign specialization should pay: fewer tokens, locally appropriate documents, and deliverables that respect Korean legal, financial, and workplace conventions.

English coding is the caveat. Upstage reports 70.4 on SWE-bench Verified, behind the strongest comparison models at roughly 73 to 74, and 28.3 on Terminal Bench Hard versus MiMo-V2.5’s 41.7. The model leads its comparison on some knowledge and agent suites, including 92.4 on LiveCodeBench and 16.6 on APEX-Agents, but all scores come from Upstage’s harness. Buyers need internal tasks, not a blended leaderboard.

Solar also shows why Naver’s proposed 200MW factory needs efficient domestic models. Sovereign compute without sovereign software is rented dependence; sovereign software too large to serve is an academic artifact. A commercially usable model on two H200s connects those layers.

Switch Korean document agents, not every coder

The best pilot cohort is a Korean enterprise processing private, document-heavy work: compliance reports, spreadsheets, local legal materials, customer support, or office workflows that closed global APIs tokenize inefficiently. Run it on premises, connect only bounded tools, and compare task completion, reviewer time, latency, and full GPU utilization against the current API.

The cost remains undisclosed in the form operators need. Two H200s have acquisition or rental cost, power, orchestration, staffing, and idle-time risk. A low active-parameter count does not mean the whole 250B checkpoint disappears from memory. The official serving guide provides vLLM and Transformers examples, but no production throughput or total-cost curve. Teams should calculate break-even at their own utilization and include the closed API as fallback.

The thesis breaks if the million-token context fails retrieval tests, quantization damages the rare Korean tasks that motivated deployment, or utilization stays too low to amortize two accelerators. The custom Solar License permits commercial use and derivatives, but legal teams should compare it with familiar permissive licenses before distribution. Open weights are not automatically frictionless open source.

The strongest alternative is routing. Keep frontier APIs for difficult English coding and ambiguous reasoning; send stable Korean office work to Solar; escalate when verification fails. That resembles the economics in Kimi K3’s cache-sensitive routing pilot and the verified loops in Nvidia’s engineering-agent toolkit. Model choice should happen per task, not per company.

Evidence that changes the verdict includes independent long-context tests, sustained tokens per second on two H200s, customer-reproduced Ko-GDPval-like outcomes, quantization deltas, and total cost per accepted document. Until those exist, Korean teams should pilot rather than standardize; non-Korean teams should wait unless data control outweighs the benchmark gap.

Solar Open 2’s 6% active ratio is not a magic discount. It is a design choice that makes a 250B sovereign model operable on two accelerators. The meaningful win will come if Korean organizations produce verified work with fewer tokens and less data exposure—not if another enormous checkpoint tops a vendor chart.