Solar Open 2 250B: Frontier Agent-scores, maar nergens om ze te draaien

De Hugging Face-kaart voor Solar Open 2 250B 250B geeft je een serving-commando, en dat commando werkt niet. Het vraagt vLLM om een reasoning-parser met de naam solar_open2, een tool-call-parser met de naam solar_open2, en een logits-processor genaamd SolarOpen2TemplateLogitsProcessor — drie dingen die in geen enkele uitgebrachte versie van vLLM bestaan. Ondersteuning voor de architectuur verscheen op 5 augustus in de mainline als een pull-request die niet is gemerged, twee weken nadat Upstage de gewichten op 22 juli publiceerde. Die kloof is op dit moment nog steeds het interessantste feit over Solar Open 2, en het is het onderdeel dat elk launchartikel oversloeg ten gunste van de benchmarktabel. Dus hier is de andere versie: wat Upstage daadwerkelijk heeft uitgebracht, wat de eigen cijfers wel en niet aantonen, wat er door de enige externe score die nu op de boeken staat verandert, en wat er nodig is om een enkel token uit het ding te krijgen — afgemeten aan DeepSeek V4 Flash, het model dat Upstage als belangrijkste maatstaf koos.

Wat Upstage daadwerkelijk heeft uitgebracht

Alles hieronder is afkomstig uit de eigen config.json van de repository en het technisch rapport van Solar Open 2 (arXiv 2607.20062) — primaire bronnen, maar wel de primaire bronnen van de leverancier. Geen onafhankelijk laboratorium heeft eigen metingen van dit model gepubliceerd. Er is nu één extern cijfer opgedoken, een door de pers gerapporteerde Artificial Analysis Intelligence Index-score van 37 uit de tweede evaluatieronde van de overheid, en die krijgt een eigen alinea in de benchmarksectie hieronder, omdat erover is gerapporteerd, niet omdat het is gereproduceerd.

• Grootte — 250.287.794.944 parameters in totaal, ongeveer 15B actief per token

• Sparsity — 320 gerouteerde experts plus 1 gedeelde expert, top-8 per token gerouteerd, en first_k_dense_replace ingesteld op 0, wat betekent dat het mengsel begint bij laag nul zonder de dichte warm-up-lagen die vergelijkbare MoE-ontwerpen gewoonlijk behouden.

• Shape — 48 lagen, hidden size 4096, head dim 128, 64 query-heads tegen 8 key/value-heads

• Let op — 12 softmax (GQA)-lagen, op indices 0, 4, 8 enzovoort tot 44; de andere 36 lagen zijn linear attention. Driekwart van de stapel bevat geen softmax.

• Posities — use_rope is false. Er is helemaal geen positionele codering.

• Context — max_position_embeddings van 1,048,576

• Woordenschat — 196.608 tokens, in het Engels, Koreaans en Japans.

• Gewichten — bfloat16, wat neerkomt op 500,6 GB. Dat is slechts 250,29 miljard parameters maal twee bytes, en het komt overeen met de geheugenvoetafdruk die Nota AI rapporteert voor het niet-gekwantiseerde model.

• Training — volgens het rapport ongeveer 11,9T tokens: 10T algemene pre-training, 1T op een samengestelde hoogwaardige subset, 0,9T voor de lengte-uitbreiding, met een opgegeven verhouding van 4:6 echt-tot-synthetisch, waarbij Engels boven 80% ligt en wiskunde en code elk ten minste 15%.

• Licentie — de Upstage Solar-licentie, waaraan voorwaarden zijn verbonden (hieronder)

De voorganger, Solar Open 1, was een 100B-model dat in januari werd uitgebracht. Solar Open 2 is niet zozeer een vernieuwing ervan, maar eerder een ander beest.

De architectuur is het eigenlijke verhaal

Het laagpatroon is één softmax-laag gevolgd door drie lineaire-aandachtlagen, twaalf keer herhaald. Dat is al gerapporteerd. Wat niet is gerapporteerd, is welke lineaire aandacht het betreft, en waarom dat ertoe doet.

De lineaire lagen zijn KDA — Kimi Delta Attention, het mechanisme dat Moonshot AI introduceerde voor Kimi Linear. Upstage heeft geen nieuwe lineaire attention uitgevonden; het nam die van iemand anders over en veranderde één ding. De wijziging is in de config zichtbaar als kda_allow_neg_eigval ingesteld op true, en het rapport legt uit wat het oplevert: standaard KDA beperkt de eigenwaarden van de toestandsovergang tot het bereik [0,1], dus elke stap kan alleen aan de recurrente toestand toevoegen of deze laten afnemen. Het instellen van die vlag verbreedt de schrijfsterkte tot beta = 2·sigmoid(·), een bereik van (0,2), waardoor de eigenwaarden worden uitgebreid naar [-1,1]. Een stap kan nu het teken omdraaien van wat al is opgeslagen. In gewone taal: de toestand kan zichzelf corrigeren in plaats van alleen maar te accumuleren, wat het door Upstage genoemde mechanisme is om een lange agent-traject bij elkaar te houden over veel tool-aanroepen heen.

De twaalf softmax-lagen zijn GQA met een elementsgewijze sigmoïde uitvoerpoort — use_gqa_gate is true in de config — waarvan het rapport stelt dat ze niet-lineariteit toevoegen en attention sinks onderdrukken.

En de reden dat er geen RoPE is, volgt uit de lineaire lagen. Omdat een recurrente toestand de tokenvolgorde intrinsiek codeert, betoogt het rapport dat je positionele codering volledig kunt verwijderen en niet langer gebonden bent aan de lengteverdeling waarop je hebt getraind. RoPE is in dit kader datgene dat extrapolatie begrenst; verwijder het en het plafond is niet langer een functie van je trainingsdata.

Het getal 1M is een ontwerpclaim, geen meting

Dat argument is elegant en het vormt ook de hele basis voor de kop over 1M tokens. Het technische rapport publiceert geen RULER, geen needle-in-a-haystack, geen long-context-suite van welke aard dan ook. Het venster wordt beredeneerd vanuit de architectuur, niet aangetoond op een benchmark. Ondertussen zette de enige openbare implementatiebeschrijving die we konden vinden — Backend.AI, dat het gekwantiseerde model over twee DGX Spark-systemen serveert — max-model-len op 200.000, niet 1.048.576. Het architecturale plafond kan best reëel zijn. Welke kwaliteit er overleeft bij 500K of 1M tokens, staat simpelweg niet in het artikel.

De efficiëntieclaim heeft dezelfde kanttekening: het rapport stelt dat de hybride stack op 1M context ongeveer een kwart van het geheugen en rekenwerk nodig heeft van een all-softmax stack, en afzonderlijk dat het hybride ontwerp de doelverlies met ongeveer 3,2× minder trainings-tokens bereikte dan all-softmax op MMLU. Beide zijn Upstage's eigen cijfers. Er worden helemaal geen doorvoer- of latentiecijfers gepubliceerd.

De benchmarkkaart, eerlijk gelezen

Op de Engelse suite, tegen DeepSeek V4 Flash, scoort Solar Open 2 250B 86,2 op MMLU-Pro tegenover 85,9 en 92,4 op LiveCodeBench v6 tegenover 92,3 — verschillen klein genoeg om score-ruis te zijn. Vervolgens scoort het 16,6 op APEX-Agents tegenover 13,2, wat de enige echte kloof is en, niet verrassend, het getal waarmee Upstage leidt.

De verliezen staan in hetzelfde rapport en krijgen minder aandacht. SWE-Bench Verified: 70,4 tegen 73,8. GDPval-AA v2, op ELO: 1128 tegen 1187. Terminal Bench Hard: 28,3, tegen 41,7 voor MiMo-V2.5. ArtifactsBench: 55,9, achter beide frontier-baselines. Tot eer van Upstage benoemt het rapport deze hiaten en waar ze op wijzen — software-engineering op repository- en terminalniveau, en numerieke precisie in kantoorproducten — in plaats van ze te verdoezelen.

De vergelijking die echt indruk maakt, is intern. Tegen Solar Open 1: LiveCodeBench v6 gaat van 56,5 naar 92,4, SWE-Bench Verified van 15,4 naar 70,4, APEX-Agents van 2,4 naar 16,6. Wat je ook van de onderlinge vergelijkingen vindt, dat is een echte generatiesprong in zes maanden.

Op het gebied van Koreaans ligt het gemiddelde over de suite op 85,4 tegenover DeepSeek V4 Flash's 84,9 — maar het gemiddelde doet het werk. Solar Open 2 250B verliest KMMLU-Pro (78,4 tegen 78,9) en Ko-AIME'25 (97,7 tegen 98,0), en wint Ko-GDPval (86,8 tegen 85,0). De voorsprong komt van de deliverable-benchmark, niet van kennis of wiskunde.

Dat brengt ons bij de uitspraak die het verst rondging: dat Solar Open 2 250B een model evenaart dat meer dan zes keer zo groot is. De basis is Ko-GDPval, waar het 86.8 scoort tegen 86.9 van DeepSeek-V4-Pro. Dat is één Koreaanse benchmark, en het is een gelijkspel in plaats van een overwinning — terwijl op de Engelse suite het kleinere broertje van V4-Pro Solar Open 2 250B op SWE-Bench Verified al verslaat. Eén benchmark laat zich niet veralgemenen tot een wet over schaalefficiëntie. Een verwante kanttekening: de baselinecijfers voor APEX-Agents verschillen licht tussen het paper en de secundaire berichtgeving (13.2 versus 13.4 voor dezelfde modellen), dus behandel de volgorde als richtinggevend in plaats van exact.

Wat voorkeur betreft, plaatste een blinde paarsgewijze test over 835 Koreaanse gesprekken Solar Open 2 250B op 44,1% tegen 26,6%, waarbij het rapport de overwinning op het gebied van afstemming en eerlijkheid toeschrijft aan culturele verankering in plaats van extra veiligheidstraining. Het is de moeite waard om te vermelden wat ontbreekt: het rapport bevat geen kwantitatieve evaluatie van schade, weigeringen of jailbreaks van welke aard dan ook.

De modelkaart op Hugging Face heeft sindsdien nog een paar cijfers toegevoegd aan het gedeelte met evaluatieresultaten — GPQA Diamond 86.3, HLE 28.8 en MathArena AIME 2026 95.7 — maar ze zijn overgenomen uit de modelkaart zelf in plaats van uit een onafhankelijke run, dus ze dragen hetzelfde label als alles hierboven: de cijfers van Upstage, niet gereproduceerd.

Er is nu een extern cijfer opgedoken dat niet uit het lab van Upstage komt. Op 13 augustus berichtten Koreaanse financiële media — Edaily, Seoul Economic Daily, ITDaily en iNews24, die allemaal dezelfde cijfers publiceerden — over de scores van de tweede evaluatieronde van het soevereine-AI-programma van de overheid, gemeten op de Intelligence Index van Artificial Analysis (AAII v4.1.1): Motif 3 op 47, Solar Open 2 250B op 37, A.X-K2 van SK Telecom op 35 en K-EXAONE 2.0 0803 van LG AI Research op 31. Die 37 plaatst Solar Open 2 250B op de tweede plaats van de vier Koreaanse finalisten, tien punten achter Motif 3. Om het precies aan te duiden: dit is door de pers gerapporteerd — de score is niet verschenen op het eigen leaderboard van Artificial Analysis, dat voor dit model nog steeds niets teruggeeft — en dezelfde berichtgeving merkt op dat de AAII geen Koreaanstalige benchmarks bevat, een echte blinde vlek voor een model waarvan de binnenlandse resultaten centraal staan in de pitch. Maar het is de eerste meting van Solar Open 2 250B die niet terug te voeren is op Upstage, en het is consistent met de rest van dit artikel: sterke scores voor agenten en deliverables, terwijl veel van de rest nog steeds door niemand buiten de leverancier is bewezen.

Waarom niemand het op standaardsoftware kan serveren.

De modelkaart vertelt het verhaal beter dan welk commentaar dan ook. Het aantal downloads van vorige maand ligt inmiddels boven de 26.000; daarnaast zijn er 743 likes, zestien community-kwantisaties en drie finetunes — en in het vak Inference Providers geldt nog steeds de regel: "Dit model wordt door geen enkele Inference Provider aangeboden", waarbij inmiddels een tiental mensen staat vermeld die op de kaart om providerondersteuning vragen. Echte interesse, nul gehoste endpoints.

Volg de werkende deployments en ze leiden allemaal naar een fork. Nota AI's NVFP4-build pint de installatie op tag v0.22.0-solar-open2 van git+https://github.com/UpstageAI/vllm.git — Upstage's eigen vLLM. Backend.AI's DGX Spark-write-up had die fork nodig plus een gepatchte FlashInfer, omdat upstream FlashInfer geen expert-parallelle ondersteuning had en het compressed-tensors-formaat niet wilde accepteren.

Mainline-ondersteuning is pull request 51129 voor vllm-project/vllm, geopend op 5 augustus door een bijdrager die zich oesni noemt. Het is nog steeds open: op 10 augustus markeerde mergify mergeconflicten, dus de PR draagt nu een needs-rebase-label en wacht nog steeds op review. Wat die PR moest bouwen is de meest eerlijke beschrijving van de moeilijkheid van dit model die er in het openbaar bestaat:

• Een Solar-specifieke KimiGatedDeltaAttention-laag in een nieuw solar_open2.py, die de 2·sigmoid(b)-bèta van de negatieve-eigenwaarde-wijziging meeneemt.

De operatie vllm::solar_open2_kda_attention is geregistreerd als een CUDA-graph-splitsingsoperatie.

• Een KDA-prefill-warmup tijdens het profileren, begrensd tot 2048 tokens, toegevoegd specifiek omdat echte prefills zonder dit ongeveer 23% langzamer liepen.

• Parsers voor reasoning-output en tool-aanroepen in zowel streaming- als niet-streamingmodus

• Serving-validatie op 8×B200 rapporteert 107.02 GiB per rank aan KV-cache, naast 463 geslaagde unittests

Dat zijn de cijfers van de auteur van de PR, door niemand anders gereproduceerd, en de code kan nog veranderen voordat het wordt gemerged. Maar lees die lijst naast de architectuursectie en de vorm van het probleem wordt duidelijk: de twee keuzes die Solar Open 2 250B goedkoop maken om te draaien bij lange context — KDA in driekwart van de lagen, en geen RoPE — zijn precies de keuzes waarvoor generieke inference-stacks geen bestaand codepad hebben. Openheid van gewichten en openheid van het pad om ze te draaien zijn verschillende dingen, en slechts één daarvan werd op 22 juli uitgebracht.

Wat het kost om op te staan

Begin met de geheugenondergrens. 500,6 GB aan bfloat16-gewichten tegenover de 141 GB van een H200 betekent dat vier GPU's je 564 GB geven — ongeveer 63 GB over op de hele node voor KV-cache en activaties voordat er ook maar één verzoek binnenkomt. Daarom vermeldt de kaart vier H200's als minimum en beveelt er acht aan, en daarom biedt FlexAI het aan als een dedicated 8×H100-endpoint met prijzen op aanvraag in plaats van een gedeelde API per token.

Kwantalisering schuift die ondergrens een heel eind naar beneden. De NVFP4-build van Nota AI (4-bits gewichten en activaties, groepsgrootte 16, in compressed-tensors-formaat) brengt het model van 500,6 GB terug naar 153,3 GB, en hun eigen evaluatie stelt het nauwkeurigheidsverlies op 0,22 punt, gemiddeld over vier benchmarks — van 81,57 naar 81,35, met Tau2-Bench van 75,20 naar 75,08, GPQA-Diamond van 86,26 naar 85,45, MMLU-Pro van 86,19 naar 86,15, en LiveCodeBench die de andere kant op gaat, van 87,03 naar 88,55, wat eerder kwantiseringsruis is dan een verbetering. Het addertje onder het gras zit in de hardware: NVFP4 vereist de FP4-tensorcores die met Blackwell zijn geïntroduceerd, dus alleen B200 of GB200, niets op Hopper. Als je op H100's draait, is de variant die je wilt hun INT4-build met globale pruning — 117,8 GB na pruning, precies passend op twee daarvan.

Nu de rekenkunde die de doorslag geeft. DeepSeek V4 Flash — wederom het model waartegen Upstage koos te worden afgemeten — kost $0,15 per miljoen invoertokens en $0,29 per miljoen uitvoertokens op OrcaRouter, wat de lijstprijs van DeepSeek is, rechtstreeks doorberekend zonder opslag (0% markup). Bij een mix van 3:1 invoer tot uitvoer komt dat neer op ruwweg $0,185 per miljoen. Neem een illustratieve $2 per GPU-uur voor een node met acht GPU's en je zit op ongeveer $11.700 per maand voordat iemand ook maar een verzoek verstuurt — gelijk aan ruwweg 63 miljard gemengde tokens aan API-verkeer, of 2,1 miljard tokens per dag, elke dag, alleen al om break-even te draaien. Kwantiseer je af naar een node met twee GPU's en het break-evenpunt zakt naar zo'n 16 miljard tokens per maand. Vul je eigen GPU-tarief in; de vorm blijft hetzelfde. Het zelf hosten van een 250B-model is een beslissing over benutting en controle, geen korting.

Om precies te zijn over wat er wel en niet beschikbaar is: Solar Open 2 250B staat niet op OrcaRouter, en volgens de eigen modelkaart is het bij geen enkele inferentieprovider beschikbaar. Wat wel op OrcaRouter staat, is het veld waartegen het wordt afgemeten — DeepSeek V4 Flash, Qwen3.8-Max en een paar honderd andere modellen achter één sleutel tegen de lijstprijs van de provider, met failover tussen providers als er een uitvalt. Dat is hier om een beperkte, praktische reden van belang: als de vraag die je eigenlijk beantwoord wilt hebben is "verslaat een agent-getuned model wat we al in productie gebruiken", dan kun je die helft van de vergelijking vanmiddag nog draaien door een modelstring te wijzigen, terwijl de GPU-offerte voor de andere helft nog in de inkoopfase zit.

Twee strings op de licentie

De Upstage Solar-licentie staat commercieel gebruik, fine-tuning en destillatie toe, en Upstage beschrijft deze als gebaseerd op Apache-2.0 met toegevoegde merkenbepalingen. De twee toegevoegde verplichtingen zijn degene die je goed moet lezen: een afgeleid model moet het voorvoegsel "Solar" in zijn naam dragen, en je moet de vermelding "Built with Solar" tonen.

Voor interne implementatie is dat een non-event. Als je van plan bent dit te distilleren tot iets dat je onder je eigen productmerk uitbrengt, dan is de naamgevingsclausule een merkbeslissing vermomd als een licentievoorwaarde, en het is twintig minuten van een advocaat waard voordat je een trainingsrun start. Lees de clausule in de repo in plaats van te vertrouwen op berichtgeving erover — de berichtgeving over deze licentie is losjes geweest, waaronder ten minste één artikel dat het ronduit beschrijft als Apache 2.0.

Wie moet nu handelen, en wie moet wachten?

Ga ervoor als de kwaliteit van de Koreaanse of Japanse output jouw product is en je de gewichten op hardware kunt plaatsen die je al bezit — die combinatie is precies waar "open weights, no endpoint" goed voor is, en Upstage's eigen formulering is expliciet dat soevereiniteit betekent dat je een model zelf kunt implementeren en verifiëren, niet alleen dat het in eigen land is getraind. Ga ervoor als je ongebruikte GPU's hebt en een agentworkload met genoeg volume om ze te vullen, want bij werkelijk gebruik keert de per-token-berekening om. Ga ervoor als audit- of dataresidency-eisen betekenen dat een API nooit een optie was.

Wacht, als je een per-token-eindpunt wilt. Upstage heeft gezegd dat het van plan is Solar Open 2 250B op een platform van derden aan te bieden; op het moment van schrijven is dat nog niet gebeurd — de Playground-proef draaide alleen tot 31 juli, en de modelkaart toont nog steeds geen aanbieder. Wacht, als je op Hopper zit en rekende op de 4-bit build, aangezien de NVFP4-versie Blackwell nodig heeft. En wacht voordat je iets ontwerpt rond het 1M-contextgetal, dat momenteel een eigenschap van de architectuur is in plaats van een gemeten resultaat.

Het ding om in de gaten te houden is pull request 51129, dat op 10 augustus een needs-rebase-label kreeg nadat mergify mergeconflicten markeerde. De dag dat Solar Open 2 250B verschijnt in een getagde vLLM-release is de dag dat het ophoudt een infrastructuurproject te zijn en een model wordt dat iedereen gewoon kan uitproberen. De door de pers gerapporteerde AAII van 37 is een begin — een eerste externe meting, hoe voorlopig ook, en een die nog steeds niet op het eigen leaderboard van Artificial Analysis staat. De echte test is degene die draait op standaardsoftware, en die heeft nog geen datum.