Solar Open 2 250B: Frontier-agent-poäng utan någonstans att köra dem

Hugging Face-kortet för Solar Open 2 250B 250B ger dig ett serveringskommando, och kommandot fungerar inte. Det ber vLLM om en resonemangsparser vid namn solar_open2, en verktygsanropsparser vid namn solar_open2 och en logits-processor som kallas SolarOpen2TemplateLogitsProcessor — tre saker som inte finns i någon utgiven version av vLLM. Stöd för arkitekturen dök upp i mainline som en icke sammanfogad pull request den 5 augusti, två veckor efter att Upstage publicerade vikterna den 22 juli. Det gapet är fortfarande det mest intressanta faktumet om Solar Open 2 just nu, och det är den del som varje lanseringsartikel hoppade över till förmån för benchmarktabellen. Så här är den andra versionen: vad Upstage faktiskt släppte, vad de egna siffrorna fastställer och inte fastställer, vad det enda externa resultatet som nu är offentligt förändrar, och vad som krävs för att få en enda token ur den — mätt mot DeepSeek V4 Flash, modellen som Upstage valde som sin huvudsakliga måttstock.

Vad Upstage faktiskt levererade

Allt nedan kommer från repots egen config.json och den tekniska rapporten för Solar Open 2 (arXiv 2607.20062) — primära källor, men leverantörens primära källor. Inget oberoende labb har publicerat egna mätningar av denna modell. En extern siffra har nu dykt upp, en pressrapporterad Artificial Analysis Intelligence Index-poäng på 37 från regeringens andra omgångsutvärdering, och den får ett eget stycke i benchmarkavsnittet nedan eftersom den är rapporterad, inte reproducerad.

• Storlek — 250 287 794 944 parametrar totalt, cirka 15B aktiva per token

• Sparsitet — 320 routade experter plus 1 delad expert, top-8 routade per token, och first_k_dense_replace satt till 0, vilket innebär att blandningen startar vid lager noll utan några av de täta uppvärmningslager som jämförbara MoE-designs vanligtvis behåller.

• Form — 48 lager, dold storlek 4096, huvuddimension 128, 64 queryhuvuden mot 8 nyckel-/värdehuvuden

• Attention — 12 softmax (GQA)-lager, vid index 0, 4, 8 och så vidare till 44; de övriga 36 lagren är linjär attention. Tre fjärdedelar av stacken har ingen softmax i sig.

• Positioner — use_rope är falskt. Det finns ingen positionskodning alls

• Kontext — max_position_embeddings på 1,048,576

• Ordförråd — 196 608 token för engelska, koreanska och japanska.

• Vikter — bfloat16, vilket motsvarar 500,6 GB. Det är bara 250,29 miljarder parametrar gånger två byte, och det matchar det minnesavtryck Nota AI rapporterar för den okvantiserade modellen.

Träning — cirka 11,9 biljoner tokens enligt rapporten: 10 biljoner allmän förträning, 1 biljon på ett kurerat högkvalitativt delurval, 0,9 biljoner för längdutökning, med ett angivet förhållande på 4:6 mellan verkliga och syntetiska data, med engelska över 80 % och matematik och kod vardera minst 15 %.

• Licens — Upstage Solar License, som har villkor (nedan)

Föregångaren, Solar Open 1, var en 100B-modell som släpptes i januari. Solar Open 2 är inte så mycket en uppdatering av den som ett helt annat djur.

Arkitekturen är själva historien.

Lagermönstret är ett softmax-lager följt av tre linjära uppmärksamhetslager, upprepat tolv gånger. Det har rapporterats. Vad som inte har rapporterats är vilken linjär uppmärksamhet, och varför det spelar roll.

De linjära lagren är KDA — Kimi Delta Attention, den mekanism Moonshot AI introducerade för Kimi Linear. Upstage uppfann ingen ny linjär attention; det antog någon annans och ändrade en sak. Ändringen syns i konfigurationen som `kda_allow_neg_eigval` satt till true, och rapporten förklarar vad den ger: standard-KDA begränsar tillståndsövergångens egenvärden till intervallet [0,1], så varje steg kan bara addera till det rekurrenta tillståndet eller dämpa det. Att sätta den flaggan vidgar skrivstyrkan till beta = 2·sigmoid(·), ett intervall på (0,2), vilket skjuter ut egenvärdena till [-1,1]. Ett steg kan nu vända tecknet på det som redan lagrats. I klartext: tillståndet kan korrigera sig själv snarare än bara ackumulera, vilket är Upstages angivna mekanism för att hålla en lång agentbana sammanhållen över många verktygsanrop.

De dussintals softmax-lagren är GQA med en elementvis sigmoid-utgångsport — use_gqa_gate är true i konfigurationen — vilket rapporten tillskriver att tillföra icke-linjäritet och undertrycka uppmärksamhetssänkor.

Och anledningen till att det inte finns någon RoPE följer av de linjära lagren. Eftersom ett återkommande tillstånd kodar tokenordningen inneboende, argumenterar rapporten för att du kan ta bort positionskodning helt och hållet och sluta vara bunden till den längdfördelning du tränade på. RoPE, i detta perspektiv, är det som begränsar extrapolering; ta bort den och taket är inte längre en funktion av din träningsdata.

1M-siffran är ett designpåstående, inte en mätning

Det argumentet är elegant och det är också hela grunden för 1M-token-rubriken. Den tekniska rapporten publicerar ingen RULER, inget needle-in-a-haystack, ingen long-context-svit av något slag. Fönstret argumenteras utifrån arkitektur, inte demonstreras på ett benchmark. Samtidigt är den enda offentliga driftsättningsbeskrivning vi kunde hitta — Backend.AI, som servar den kvantiserade modellen över två DGX Spark-system — satt max-model-len till 200 000, inte 1 048 576. Det arkitektoniska taket kan mycket väl vara verkligt. Vilken kvalitet som överlever vid 500K eller 1M tokens finns helt enkelt inte i rapporten.

Effektivitetspåståendet har samma asterisk: rapporten anger att hybridstacken behöver ungefär en fjärdedel av minnet och beräkningarna jämfört med en all-softmax-stack vid 1M kontext, och separat att hybriddesignen nådde målförlusten med cirka 3,2× färre träningstokens än all-softmax på MMLU. Båda är Upstages egna siffror. Inga genomströmnings- eller latenssiffror publiceras alls.

Benchmark-kortet, läst ärligt.

På den engelska sviten, mot DeepSeek V4 Flash, noterar Solar Open 2 250B 86.2 på MMLU-Pro mot 85.9 och 92.4 på LiveCodeBench v6 mot 92.3 — skillnaderna är tillräckligt små för att vara mätbrus. Sedan noterar den 16.6 på APEX-Agents mot 13.2, vilket är det enda verkliga gapet och, föga förvånande, det tal som Upstage leder med.

Förlusterna finns i samma rapport och får mindre utrymme. SWE-Bench Verified: 70.4 mot 73.8. GDPval-AA v2, på ELO: 1128 mot 1187. Terminal Bench Hard: 28.3, mot 41.7 för MiMo-V2.5. ArtifactsBench: 55.9, bakom båda frontier-baslinjerna. Till Upstages förtjänst namnger rapporten dessa brister och vart de pekar — mjukvaruteknik på repository- och terminalnivå, samt numerisk precision i kontorsleveranser — snarare än att sopa dem under mattan.

Den jämförelse som faktiskt imponerar är intern. Mot Solar Open 1: LiveCodeBench v6 går från 56,5 till 92,4, SWE-Bench Verified från 15,4 till 70,4, APEX-Agents från 2,4 till 16,6. Vad du än tycker om de direkta jämförelserna, är det ett äkta generationssprång på sex månader.

På koreanska är genomsnittet över testsviten 85,4 mot DeepSeek V4 Flashs 84,9 — men genomsnittet gör jobbet. Solar Open 2 250B förlorar KMMLU-Pro (78,4 mot 78,9) och Ko-AIME'25 (97,7 mot 98,0) och vinner Ko-GDPval (86,8 mot 85,0). Ledningen kommer från benchmarken för leverabler, inte från kunskap eller matematik.

Vilket leder oss till den linje som gick längst: att Solar Open 2 250B matchar en modell som är mer än sex gånger så stor. Grunden är Ko-GDPval, där den får 86.8 mot DeepSeek-V4-Pro:s 86.9. Det är ett koreanskt riktmärke, och det är oavgjort snarare än en seger – medan på den engelska testsviten slår V4-Pro:s mindre syskon redan Solar Open 2 250B på SWE-Bench Verified. Ett riktmärke kan inte generaliseras till en lag om storlekseffektivitet. En relaterad varning: baslinjesiffrorna för APEX-Agents skiljer sig något mellan rapporten och sekundär rapportering (13.2 mot 13.4 för samma modeller), så betrakta rangordningen som riktgivande snarare än exakt.

Vid preferensmätning hamnade Solar Open 2 250B före med 44,1% mot 26,6% i ett blindt parvis test över 835 koreanska konversationer. Rapporten tillskriver vinsten i alignment och ärlighet till kulturell förankring snarare än extra säkerhetsträning. Värt att notera är vad som saknas: rapporten innehåller ingen kvantitativ utvärdering av skada, vägran eller jailbreak av något slag.

Hugging Face-kortet har sedan dess fått ytterligare några siffror i sitt avsnitt för utvärderingsresultat — GPQA Diamond 86.3, HLE 28.8 och MathArena AIME 2026 95.7 — men de hämtades från själva modellkortet snarare än från en oberoende körning, så de bär samma etikett som allt ovan: Upstages siffror, ej reproducerade.

En extern siffra har nu dykt upp som inte kommer från Upstages labb. Den 13 augusti rapporterade koreanska finansmedier – Edaily, Seoul Economic Daily, ITDaily och iNews24, alla med samma siffror – regeringens andra utvärderingsomgång för det statliga AI-programmet, mätt på Artificial Analysis Intelligence Index (AAII v4.1.1): Motif 3 på 47, Solar Open 2 250B på 37, SK Telecoms A.X-K2 på 35 och LG AI Researchs K-EXAONE 2.0 0803 på 31. De 37 placerar Solar Open 2 250B tvåa av de fyra koreanska finalisterna, tio poäng efter Motif 3. Låt oss vara precisa: detta är pressrapporterat – poängen har inte dykt upp på Artificial Analysis egen leaderboard, som fortfarande inte ger något för denna modell – och samma rapportering noterar att AAII inte innehåller några koreanskspråkiga riktmärken, en verklig blind fläck för en modell vars inhemska resultat är centrala för dess erbjudande. Men det är den första avläsningen av Solar Open 2 250B som inte går att spåra till Upstage, och den överensstämmer med resten av denna artikel: starka agent- och leveranspoäng, med mycket av resten fortfarande obevisat av någon utanför leverantören.

Varför ingen kan servera det på standardprogramvara

Modellkortet berättar historien bättre än någon kommentar. Nedladdningarna förra månaden ligger nu på över 26 000, tillsammans med 743 gillamarkeringar, sexton community-kvantiseringar och tre finjusteringar – och i rutan Inference Providers står fortfarande raden ”Den här modellen är inte driftsatt av någon inferensleverantör”, med ett dussin personer nu listade som ber kortet om leverantörsstöd. Verkligt intresse, noll hostade slutpunkter.

Följ de fungerande driftsättningarna så leder de alla till en fork. Nota AI:s NVFP4-bygge låser installationen till git+https://github.com/UpstageAI/vllm.git vid taggen v0.22.0-solar-open2 — Upstages egen vLLM. Backend.AI:s DGX Spark-genomgång behövde den forken plus en patchad FlashInfer, eftersom FlashInfer i huvudgrenen saknade stöd för expert-parallellism och inte accepterade compressed-tensors-formatet.

Stöd för huvudlinjen är pull request 51129 mot vllm-project/vllm, öppnad den 5 augusti av en bidragsgivare som går under namnet oesni. Den är fortfarande öppen: den 10 augusti flaggade mergify merge-konflikter, så PR:n har nu en needs-rebase-etikett och väntar fortfarande på granskning. Vad den PR:n var tvungen att bygga är den mest ärliga beskrivningen av den här modellens svårighetsgrad som finns offentligt:

• Ett Solar-specifikt KimiGatedDeltaAttention-lager i en ny solar_open2.py, som bär 2·sigmoid(b)-betan från den negativa egenvärdesändringen.

• Operationen vllm::solar_open2_kda_attention registrerades som en CUDA-grafuppdelningsoperation.

En KDA-prefill-uppvärmning vid profileringstid, med ett tak på 2048 tokens, lades till specifikt eftersom riktiga prefills utan den körde cirka 23 % långsammare.

• Parser för resonemangsutdata och verktygsanrop för både strömmande och icke-strömmande lägen

• Serveringsvalidering på 8×B200 som rapporterar 107.02 GiB per rank av KV-cache, tillsammans med 463 godkända enhetstester

Det är PR-författarens siffror, inte reproducerade av någon annan, och koden kan fortfarande ändras innan den slås samman. Men läs den listan tillsammans med arkitekturavsnittet så blir problemets form uppenbar: de två val som gör Solar Open 2 250B billig att köra med lång kontext — KDA i tre fjärdedelar av lagren, och ingen RoPE — är precis de val för vilka allmänna inferensstackar saknar befintlig kodväg. Öppenhet för vikter och öppenhet för vägen att köra dem är två olika saker, och bara den ena släpptes den 22 juli.

Vad det kostar att stå upp

Börja med minnesgolvet. 500,6 GB bfloat16-vikter mot en H200:s 141 GB innebär att fyra GPU:er ger dig 564 GB — ungefär 63 GB kvar över hela noden för KV-cache och aktiveringar innan en enda begäran landar. Det är därför kortet listar fyra H200:or som minimum och rekommenderar åtta, och varför FlexAI erbjuder det som en dedikerad 8×H100-endpoint med prissättning på begäran snarare än på ett delat per-token-API.

Kvantisering flyttar golvet långt. Nota AI:s NVFP4-bygge (4-bitars vikter och aktiveringar, gruppstorlek 16, i compressed-tensors-format) tar modellen från 500,6 GB till 153,3 GB, och deras egen utvärdering sätter noggrannhetskostnaden till 0,22 poäng i genomsnitt över fyra riktmärken — 81,57 till 81,35, med Tau2-Bench 75,20 till 75,08, GPQA-Diamond 86,26 till 85,45, MMLU-Pro 86,19 till 86,15, och LiveCodeBench som rör sig åt andra hållet, 87,03 till 88,55, vilket är kvantiseringsbrus snarare än en förbättring. Haken är hårdvaran: NVFP4 kräver FP4-tensorkärnorna som introducerades med Blackwell, så bara B200 eller GB200, inget på Hopper. Om du kör H100:or är varianten du vill ha deras INT4-bygge med global beskärning — 117,8 GB efter beskärning, dimensionerat för att rymmas på två av dem.

Nu är det aritmetiken som avgör. DeepSeek V4 Flash — återigen den modell som Upstage valde att mätas mot — kostar $0,15 per miljon input-tokens och $0,29 per miljon output på OrcaRouter, vilket är DeepSeeks listpris som skickas vidare rakt igenom med 0 % påslag. Vid en 3:1-blandning av input och output landar det på ungefär $0,185 per miljon. Lägg ett illustrativt pris på $2 per GPU-timme på en nod med åtta GPU:er så hamnar du på cirka $11 700 i månaden innan någon skickar en förfrågan — motsvarande ungefär 63 miljarder blandade tokens av API-trafik, eller 2,1 miljarder tokens om dagen, varje dag, bara för att nå break-even. Kvantiserar du ner till en nod med två GPU:er sjunker break-even till något i stil med 16 miljarder tokens i månaden. Sätt in din egen GPU-taxa; formen rör sig inte. Att self-hosta en 250B-modell är ett beslut om utnyttjande och kontroll, inte en rabatt.

För att vara exakt med vad som finns och inte finns tillgängligt: Solar Open 2 250B finns inte på OrcaRouter, och enligt dess eget modellkort finns den inte hos någon inferensleverantör. Det som finns på OrcaRouter är fältet som den mäts mot — DeepSeek V4 Flash, Qwen3.8-Max och ett par hundra andra bakom en enda nyckel till leverantörens listpris, med failover mellan leverantörer om en går ner. Vilket spelar roll här av en snäv, praktisk anledning: om frågan du faktiskt vill ha svar på är "slår en agenttrimmad modell det vi redan kör i produktion", kan du köra den halvan av jämförelsen genom att ändra en modellsträng i eftermiddag, medan GPU-offerten för den andra halvan fortfarande är i upphandling.

Två strängar på licensen

Upstage Solar-licensen tillåter kommersiell användning, finjustering och destillering, och Upstage beskriver den som baserad på Apache-2.0 med tillagda varumärkesvillkor. De två tillagda förpliktelserna är de man bör läsa noggrant: en härledd modell måste bära prefixet "Solar" i sitt namn, och du måste visa tillskrivningen "Built with Solar".

För intern driftsättning är det en icke-händelse. Om du planerar att destillera detta till något du levererar under ditt eget produktvarumärke, är namnklausulen ett varumärkesbeslut förklätt till ett licensvillkor, och det är värt tjugo minuter av en advokats tid innan du startar en träningskörning. Läs klausulen på repot istället för att lita på bevakningen av den — rapporteringen om denna licens har varit slarvig, inklusive minst en text som rakt av beskriver den som Apache 2.0.

Vem bör flytta nu, och vem bör vänta

Ta steget om koreansk eller japansk leveranskvalitet är din produkt och du kan lägga vikterna på hårdvara du redan äger — den kombinationen är precis vad "öppna vikter, ingen slutpunkt" är bra för, och Upstages egen beskrivning är tydlig: suveränitet innebär att själv kunna driftsätta och verifiera en modell, inte bara att den tränades inhemskt. Ta steget om du har outnyttjade GPU:er och en agentarbetsbelastning med tillräcklig volym för att fylla dem, för vid verklig utnyttjandegrad vänder per-token-kalkylen. Ta steget om revisions- eller datalagringskrav innebär att ett API aldrig var aktuellt.

Vänta om du vill ha en per-token-slutpunkt. Upstage har sagt att de avser att lista Solar Open 2 250B på en tredjepartsplattform; i skrivande stund har det inte skett — Playground-testet pågick bara till 31 juli, och modellkortet visar fortfarande ingen leverantör. Vänta om du sitter på Hopper och räknade med 4-bitarsversionen, eftersom NVFP4-versionen kräver Blackwell. Och vänta innan du designar något kring 1M-kontextnumret, som för närvarande är en egenskap hos arkitekturen snarare än ett uppmätt resultat.

Det man bör hålla koll på är pull request 51129, som den 10 augusti fick en needs-rebase-etikett efter att Mergify flaggade mergekonflikter. Den dag Solar Open 2 250B dyker upp i en taggad vLLM-utgåva är den dag det slutar vara ett infrastrukturprojekt och blir en modell som vem som helst helt enkelt kan prova. Den pressrapporterade AAII på 37 är en början – en första extern avläsning, så provisorisk den än är, och en som fortfarande inte visas på Artificial Analysis egen ledartavla. Det verkliga testet är det som körs på standardprogramvara, och det har ännu inget datum.