Solar Open 2 250B: Frontier-Agent punktet, doch es gibt keinen Ort, um sie auszuführen

Die Hugging-Face-Karte für Solar Open 2 250B 250B gibt dir einen Serving-Befehl, und der Befehl funktioniert nicht. Er verlangt von vLLM einen Reasoning-Parser namens solar_open2, einen Tool-Call-Parser namens solar_open2 und einen Logits-Prozessor namens SolarOpen2TemplateLogitsProcessor — drei Dinge, die in keiner veröffentlichten Version von vLLM existieren. Unterstützung für die Architektur tauchte im mainline als ein nicht zusammengeführter Pull-Request am 5. August auf, zwei Wochen nachdem Upstage die Gewichte am 22. Juli veröffentlicht hatte. Diese Lücke ist derzeit immer noch die interessanteste Tatsache über Solar Open 2, und sie ist der Teil, den jeder Launch-Artikel zugunsten der Benchmark-Tabelle übersprungen hat. Hier also die andere Version: was Upstage tatsächlich ausgeliefert hat, was seine eigenen Zahlen belegen und was sie nicht belegen, was der eine externe Score, der jetzt offiziell erfasst ist, verändert, und was es braucht, um ein einziges Token aus dem Ding herauszubekommen — gemessen an DeepSeek V4 Flash, dem Modell, das Upstage als seinen Hauptmaßstab gewählt hat.

Was Upstage tatsächlich ausgeliefert hat

Alles unten stammt aus dem config.json des Repositorys und dem technischen Bericht von Solar Open 2 (arXiv 2607.20062) – Primärquellen, aber die Primärquellen des Anbieters. Kein unabhängiges Labor hat eigene Messungen dieses Modells veröffentlicht. Inzwischen ist eine externe Zahl aufgetaucht, ein von der Presse berichteter Artificial Analysis Intelligence Index-Wert von 37 aus der Bewertung der zweiten Runde der Regierung, und sie bekommt im Benchmark-Abschnitt unten einen eigenen Absatz, weil sie berichtet, nicht reproduziert wurde.

• Größe — 250.287.794.944 Parameter insgesamt, etwa 15 Mrd. aktive pro Token

• Sparsity — 320 geroutete Experten plus 1 gemeinsamer Experte, Top-8 pro Token geroutet, und first_k_dense_replace auf 0 gesetzt, was bedeutet, dass die Mischung ab Schicht null startet, ohne die dichten Warmup-Schichten, die vergleichbare MoE-Designs normalerweise beibehalten.

• Form — 48 Layer, Hidden Size 4096, Head-Dim 128, 64 Query-Heads gegenüber 8 Key/Value-Heads

• Aufmerksamkeit — 12 Softmax- (GQA-) Schichten bei den Indizes 0, 4, 8 und so weiter bis 44; die anderen 36 Schichten sind lineare Aufmerksamkeit. Drei Viertel des Stapels enthalten kein Softmax.

• Positionen — use_rope ist false. Es gibt überhaupt keine Positionskodierung.

• Kontext — max_position_embeddings von 1,048,576

• Wortschatz — 196.608 Token, in Englisch, Koreanisch und Japanisch

• Gewichte — bfloat16, das entspricht 500,6 GB. Das sind genau 250,29 Milliarden Parameter mal zwei Bytes, und es stimmt mit dem Speicherbedarf überein, den Nota AI für das unquantisierte Modell angibt.

• Training — etwa 11,9 Billionen Token laut Bericht: 10 Billionen für allgemeines Pre-Training, 1 Billion für eine kuratierte, qualitativ hochwertige Teilmenge, 0,9 Billionen für die Längenerweiterung, bei einem angegebenen Verhältnis von 4:6 real zu synthetisch, wobei Englisch über 80 % und Mathematik sowie Code jeweils mindestens 15 % ausmachen.

• Lizenz — die Upstage Solar Lizenz, die mit Bedingungen verbunden ist (unten)

Der Vorgänger, Solar Open 1, war ein 100B-Modell, das im Januar veröffentlicht wurde. Solar Open 2 ist weniger eine Aktualisierung davon als vielmehr ein anderes Tier.

Die Architektur ist die eigentliche Geschichte.

Das Schichtmuster besteht aus einer Softmax-Schicht, gefolgt von drei Linear-Attention-Schichten, und wird zwölfmal wiederholt. So viel wurde berichtet. Was nicht berichtet wurde, ist, welche Linear-Attention verwendet wird und warum das wichtig ist.

Die linearen Schichten sind KDA – Kimi Delta Attention, der Mechanismus, den Moonshot AI für Kimi Linear eingeführt hat. Upstage hat keine neue lineare Attention erfunden; es hat die eines anderen übernommen und eine Sache geändert. Die Änderung ist in der Konfiguration als kda_allow_neg_eigval sichtbar, das auf true gesetzt ist, und der Bericht erklärt, was das bringt: Standard-KDA beschränkt die Eigenwerte des Zustandsübergangs auf den Bereich [0,1], sodass jeder Schritt den rekurrenten Zustand nur vergrößern oder abklingen lassen kann. Das Setzen dieses Flags erweitert die Schreibstärke auf Beta = 2·Sigmoid(·), einen Bereich von (0,2), wodurch die Eigenwerte auf [-1,1] ausgedehnt werden. Ein Schritt kann nun das Vorzeichen dessen, was bereits gespeichert ist, umkehren. Einfach ausgedrückt: Der Zustand kann sich selbst korrigieren, statt nur zu akkumulieren – das ist laut Upstage der Mechanismus, mit dem eine lange Agenten-Trajektorie über viele Tool-Aufrufe hinweg zusammengehalten wird.

Die zwölf Softmax-Ebenen sind GQA mit einem elementweisen Sigmoid-Ausgabe-Gate — use_gqa_gate ist in der Konfiguration auf true gesetzt — dem der Bericht zuschreibt, Nichtlinearität hinzuzufügen und Attention Sinks zu unterdrücken.

Und der Grund, warum es kein RoPE gibt, folgt aus den linearen Schichten. Da ein rekurrenter Zustand die Token-Reihenfolge intrinsisch kodiert, argumentiert der Bericht, man könne die Positionskodierung vollständig entfernen und sei nicht länger an die Längenverteilung gebunden, auf der man trainiert hat. RoPE ist in dieser Darstellung das, was die Extrapolation begrenzt; entfernt man es, ist die Obergrenze keine Funktion der Trainingsdaten mehr.

Die 1M-Zahl ist eine Designangabe, keine Messung.

Dieses Argument ist elegant, und es ist auch die gesamte Grundlage für die 1M-Token-Schlagzeile. Der technische Bericht veröffentlicht kein RULER, keinen Needle-in-a-Haystack-Test, keine Long-Context-Suite irgendeiner Art. Das Fenster wird aus der Architektur heraus begründet, nicht an einem Benchmark demonstriert. In der Zwischenzeit setzt der einzige öffentliche Deployment-Bericht, den wir finden konnten – Backend.AI, das das quantisierte Modell über zwei DGX-Spark-Systeme ausliefert – max-model-len auf 200.000, nicht auf 1.048.576. Die architektonische Obergrenze mag durchaus real sein. Welche Qualität bei 500K oder 1M Token überlebt, steht schlicht nicht in dem Paper.

Die Effizienzbehauptung trägt dasselbe Sternchen: Der Bericht besagt, dass der Hybrid-Stack bei 1M Kontext ungefähr ein Viertel des Speichers und der Rechenleistung eines reinen Softmax-Stacks benötigt, und separat, dass das hybride Design das angestrebte Loss mit etwa 3,2× weniger Trainings-Tokens als reines Softmax bei MMLU erreichte. Beides sind Upstages eigene Zahlen. Es werden überhaupt keine Durchsatz- oder Latenzzahlen veröffentlicht.

Die Benchmark-Karte, ehrlich gelesen.

Bei der englischen Suite erzielt Solar Open 2 250B gegenüber DeepSeek V4 Flash 86,2 bei MMLU-Pro gegenüber 85,9 und 92,4 bei LiveCodeBench v6 gegenüber 92,3 — die Unterschiede sind klein genug, um Messrauschen zu sein. Anschließend erzielt es 16,6 bei APEX-Agents gegenüber 13,2, was die eine echte Lücke ist und, wie nicht anders zu erwarten, der Wert, mit dem Upstage führt.

Die Verluste stehen im selben Bericht und finden weniger Beachtung. SWE-Bench Verified: 70,4 gegenüber 73,8. GDPval-AA v2, in der ELO-Wertung: 1128 gegenüber 1187. Terminal Bench Hard: 28,3 gegenüber 41,7 für MiMo-V2.5. ArtifactsBench: 55,9, hinter beiden Frontier-Baselines. Upstage ist zugutezuhalten, dass der Bericht diese Lücken benennt und aufzeigt, worauf sie hindeuten — Softwareentwicklung auf Repository- und Terminal-Ebene sowie numerische Präzision bei Office-Deliverables — anstatt sie unter den Teppich zu kehren.

Der Vergleich, der wirklich beeindruckt, ist der interne. Gegenüber Solar Open 1: LiveCodeBench v6 steigt von 56,5 auf 92,4, SWE-Bench Verified von 15,4 auf 70,4, APEX-Agents von 2,4 auf 16,6. Wie auch immer man die Direktvergleiche bewertet, das ist ein echter Generationssprung in sechs Monaten.

Beim Koreanischen liegt der Durchschnitt über die Suite bei 85,4 gegenüber 84,9 von DeepSeek V4 Flash – aber der Durchschnitt verdeckt das eigentliche Bild. Solar Open 2 250B verliert bei KMMLU-Pro (78,4 zu 78,9) und Ko-AIME'25 (97,7 zu 98,0) und gewinnt bei Ko-GDPval (86,8 zu 85,0). Der Vorsprung stammt aus dem Deliverable-Benchmark, nicht aus Wissen oder Mathematik.

Damit kommen wir zu der am weitesten verbreiteten Aussage: dass Solar Open 2 250B mit einem Modell mithält, das mehr als sechsmal so groß ist. Die Grundlage ist Ko-GDPval, wo es 86,8 erreicht, während DeepSeek-V4-Pro 86,9 erzielt. Das ist ein koreanischer Benchmark, und es ist ein Gleichstand und kein Sieg im direkten Vergleich – während V4-Pros kleineres Schwestermodell Solar Open 2 250B in der englischen Suite bei SWE-Bench Verified bereits schlägt. Ein einzelner Benchmark lässt sich nicht zu einem Gesetz der Größeneffizienz verallgemeinern. Eine damit zusammenhängende Warnung: Die Baseline-Werte für APEX-Agents weichen zwischen dem Paper und der sekundären Berichterstattung leicht ab (13,2 gegenüber 13,4 für dieselben Modelle); betrachten Sie die Reihenfolge also als richtungsweisend und nicht als exakt.

In Bezug auf Präferenzen brachte ein blinder paarweiser Test über 835 koreanische Konversationen Solar Open 2 250B mit 44,1 % gegenüber 26,6 % in Führung, wobei der Bericht den Sieg bei Alignment und Ehrlichkeit auf kulturelle Verankerung statt auf zusätzliches Sicherheitstraining zurückführt. Bemerkenswert ist, was fehlt: Der Bericht enthält keinerlei quantitative Bewertung von Schaden, Verweigerung oder Jailbreak.

Die Hugging-Face-Karte hat inzwischen ein paar weitere Zahlen in ihrem Abschnitt mit den Evaluierungsergebnissen aufgenommen — GPQA Diamond 86,3, HLE 28,8 und MathArena AIME 2026 95,7 — aber sie stammen aus der Modellkarte selbst und nicht aus einem unabhängigen Durchlauf, also tragen sie dasselbe Etikett wie alles oben: Upstages Zahlen, nicht reproduziert.

Eine externe Zahl ist nun aufgetaucht, die nicht aus dem Labor von Upstage stammt. Am 13. August berichteten koreanische Finanzmedien – Edaily, Seoul Economic Daily, ITDaily und iNews24, alle mit denselben Zahlen – über die Ergebnisse der zweiten Bewertungsrunde des staatlichen Sovereign-AI-Programms, gemessen am Intelligence Index von Artificial Analysis (AAII v4.1.1): Motif 3 mit 47, Solar Open 2 250B mit 37, SK Telecoms A.X-K2 mit 35 und LG AI Researchs K-EXAONE 2.0 0803 mit 31. Die 37 bringt Solar Open 2 250B auf den zweiten Platz der vier koreanischen Finalisten, zehn Punkte hinter Motif 3. Man muss es präzise benennen: Dies ist presseberichtet – der Wert ist nicht auf dem eigenen Leaderboard von Artificial Analysis erschienen, das für dieses Modell weiterhin nichts anzeigt – und dieselbe Berichterstattung merkt an, dass der AAII keine koreanischsprachigen Benchmarks enthält, ein echtes Problem für ein Modell, dessen nationale Ergebnisse zentral für seine Positionierung sind. Aber es ist die erste Einschätzung zu Solar Open 2 250B, die nicht auf Upstage zurückgeht, und sie passt zum Rest dieses Artikels: starke Agent- und Deliverable-Werte, während vieles andere von niemandem außerhalb des Anbieters verifiziert ist.

Warum niemand es mit Standardsoftware bereitstellen kann.

Die Modellkarte erzählt die Geschichte besser als jeder Kommentar. Die Downloads im letzten Monat liegen inzwischen bei über 26.000, dazu kommen 743 Likes, sechzehn Community-Quantisierungen und drei Finetunes – und im Feld „Inference Providers" steht weiterhin der Satz „This model isn't deployed by any Inference Provider", wobei inzwischen ein Dutzend Personen aufgeführt sind, die auf der Karte um Provider-Support bitten. Echtes Interesse, null gehostete Endpunkte.

Wer den funktionierenden Deployments folgt, landet bei einem Fork. Nota AIs NVFP4-Build pinnt seine Installation auf git+https://github.com/UpstageAI/vllm.git bei Tag v0.22.0-solar-open2 — Upstages eigenes vLLM. Backend.AIs DGX-Spark-Bericht benötigte diesen Fork plus ein gepatchtes FlashInfer, da das Upstream-FlashInfer keine Expert-Parallel-Unterstützung hatte und das Compressed-Tensors-Format nicht akzeptierte.

Mainline-Unterstützung ist Pull-Request 51129 gegen vllm-project/vllm, eröffnet am 5. August von einem Mitwirkenden namens oesni. Er ist noch offen: Am 10. August markierte Mergify Merge-Konflikte, sodass der PR jetzt ein Needs-Rebase-Label trägt und weiterhin auf Review wartet. Was dieser PR aufbauen musste, ist die ehrlichste Beschreibung der Schwierigkeit dieses Modells, die es öffentlich gibt:

• Eine Solar-spezifische KimiGatedDeltaAttention-Schicht in einer neuen solar_open2.py, die die 2·sigmoid(b)-Beta aus der Änderung des negativen Eigenwerts übernimmt.

• Die Operation vllm::solar_open2_kda_attention ist als CUDA-Graph-Splitting-Op registriert.

• Zur Profilzeit wurde ein KDA-Prefill-Warmup mit einem Limit von 2048 Tokens hinzugefügt, speziell weil echte Prefills ohne dieses etwa 23 % langsamer liefen.

• Parser für Reasoning-Ausgaben und Tool-Aufrufe für Streaming- und Nicht-Streaming-Modi

• Serving-Validierung auf 8×B200 mit 107,02 GiB KV-Cache pro Rang sowie 463 bestandenen Unit-Tests

Das sind die Zahlen des PR-Autors, die von niemand anderem reproduziert wurden, und der Code kann sich noch ändern, bevor er gemerged wird. Aber wenn man diese Liste neben dem Architektur-Abschnitt liest, ist die Form des Problems offensichtlich: Die beiden Entscheidungen, die Solar Open 2 250B bei langem Kontext günstig im Betrieb machen — KDA in drei Vierteln der Schichten und kein RoPE — sind genau die Entscheidungen, für die Allzweck-Inferenz-Stacks keinen bestehenden Codepfad haben. Offenheit der Gewichte und Offenheit des Pfads, sie auszuführen, sind verschiedene Dinge, und nur eines davon wurde am 22. Juli ausgeliefert.

Was es kostet, aufzustehen

Beginnen wir mit der Speicheruntergrenze. 500,6 GB an bfloat16-Gewichten bei 141 GB des H200 bedeuten, dass vier GPUs 564 GB ergeben – etwa 63 GB bleiben über den gesamten Knoten für KV-Cache und Aktivierungen übrig, bevor eine einzige Anfrage eintrifft. Deshalb führt die Karte vier H200 als Minimum auf und empfiehlt acht, und deshalb bietet FlexAI sie als dedizierten 8×H100-Endpoint mit Preis auf Anfrage an, statt über eine gemeinsame API mit Abrechnung pro Token.

Quantisierung senkt diese Grenze erheblich. Nota AIs NVFP4-Build (4-Bit-Gewichte und -Aktivierungen, Gruppengröße 16, im compressed-tensors-Format) reduziert das Modell von 500,6 GB auf 153,3 GB, und ihre eigene Auswertung beziffert den Genauigkeitsverlust auf durchschnittlich 0,22 Punkte über vier Benchmarks hinweg — von 81,57 auf 81,35, wobei Tau2-Bench von 75,20 auf 75,08, GPQA-Diamond von 86,26 auf 85,45, MMLU-Pro von 86,19 auf 86,15 und LiveCodeBench sich in die andere Richtung bewegt, von 87,03 auf 88,55, was eher Quantisierungsrauschen als eine Verbesserung ist. Der Haken ist die Hardware: NVFP4 benötigt die mit Blackwell eingeführten FP4-Tensor-Cores, also nur B200 oder GB200, nichts auf Hopper. Wenn Sie auf H100s unterwegs sind, ist die Variante, die Sie wollen, ihr INT4-Build mit globalem Pruning — 117,8 GB nach dem Pruning, so dimensioniert, dass er auf zwei davon passt.

Nun die Rechnung, die entscheidet. DeepSeek V4 Flash – erneut das Modell, gegen das sich Upstage messen lassen wollte – kostet auf OrcaRouter 0,15 $ pro Million Eingabe-Token und 0,29 $ pro Million Ausgabe-Token, was dem Listenpreis von DeepSeek entspricht, der ohne Aufschlag (0 % Marge) direkt durchgereicht wird. Bei einem 3:1-Mischverhältnis von Eingabe zu Ausgabe ergibt sich ein Mischpreis von ungefähr 0,185 $ pro Million. Setzt man als Rechenbeispiel 2 $ pro GPU-Stunde auf einen Acht-GPU-Knoten an, liegt man bei etwa 11.700 $ pro Monat, bevor auch nur eine Anfrage gesendet wird – das entspricht ungefähr 63 Milliarden gemischten Token an API-Traffic bzw. 2,1 Milliarden Token pro Tag, und das jeden Tag, nur um die Gewinnschwelle zu erreichen. Reduziert man auf einen Zwei-GPU-Knoten, sinkt die Gewinnschwelle auf etwa 16 Milliarden Token pro Monat. Setze deinen eigenen GPU-Preis ein; die Form bleibt unverändert. Das Selbst-Hosten eines 250B-Modells ist eine Entscheidung über Auslastung und Kontrolle, nicht über einen Rabatt.

Um genau zu sagen, was verfügbar ist und was nicht: Solar Open 2 250B ist nicht auf OrcaRouter, und laut eigener Modellkarte auch bei keinem Inferenzanbieter. Was auf OrcaRouter zu finden ist, ist das Feld, gegen das es gemessen wird — DeepSeek V4 Flash, Qwen3.8-Max und ein paar hundert weitere hinter einem einzigen Schlüssel zum Listenpreis des Anbieters, mit Failover zwischen den Anbietern, falls einer ausfällt. Das ist hier aus einem engen, praktischen Grund von Bedeutung: Wenn die Frage, die Sie tatsächlich beantwortet haben möchten, lautet: „Schlägt ein auf Agenten abgestimmtes Modell das, was wir in der Produktion bereits einsetzen?“, dann können Sie diese Hälfte des Vergleichs heute Nachmittag durchführen, indem Sie eine Modellbezeichnung ändern, während das GPU-Angebot für die andere Hälfte noch in der Beschaffung steckt.

Zwei Zeichenketten auf der Lizenz.

Die Upstage-Solar-Lizenz erlaubt kommerzielle Nutzung, Fine-Tuning und Destillation, und Upstage beschreibt sie als auf Apache-2.0 basierend mit ergänzten Markenbestimmungen. Die beiden zusätzlichen Verpflichtungen sollte man genau lesen: Ein abgeleitetes Modell muss das Präfix „Solar“ in seinem Namen tragen, und man muss den Hinweis „Built with Solar“ anzeigen.

Für die interne Bereitstellung ist das kein Problem. Wenn Sie vorhaben, dies zu etwas zu destillieren, das Sie unter Ihrer eigenen Produktmarke ausliefern, ist die Namensklausel eine Markenentscheidung im Gewand einer Lizenzbedingung, und es ist zwanzig Minuten Anwaltszeit wert, bevor Sie einen Trainingslauf starten. Lesen Sie die Klausel im Repository, anstatt sich auf Berichte darüber zu verlassen — die Berichterstattung über diese Lizenz war ungenau, einschließlich mindestens eines Artikels, der sie schlichtweg als Apache 2.0 beschreibt.

Wer sollte jetzt handeln, und wer sollte warten?

Wechseln Sie, wenn koreanische oder japanische Ergebnisqualität Ihr Produkt ist und Sie die Gewichte auf Hardware legen können, die Sie bereits besitzen — genau für diese Kombination ist „Open Weights, kein Endpoint“ gedacht, und Upstage selbst betont ausdrücklich, dass Souveränität bedeutet, ein Modell selbst bereitstellen und verifizieren zu können, nicht nur, dass es im Inland trainiert wurde. Wechseln Sie, wenn Sie ungenutzte GPUs haben und eine Agent-Workload mit genügend Volumen, um sie auszulasten, denn bei realer Auslastung kehrt sich die Pro-Token-Rechnung um. Wechseln Sie, wenn Audit- oder Datenresidenz-Anforderungen bedeuten, dass eine API nie in Frage kam.

Moment, falls du einen Endpunkt pro Token möchtest. Upstage hat angekündigt, Solar Open 2 250B auf einer Drittanbieter-Plattform zu listen; zum Zeitpunkt des Schreibens ist das noch nicht geschehen — der Playground-Testlauf ging nur bis zum 31. Juli, und die Modellkarte zeigt weiterhin keinen Anbieter. Moment, falls du auf Hopper bist und auf den 4-Bit-Build gesetzt hast, denn die NVFP4-Version benötigt Blackwell. Und warte, bevor du irgendetwas rund um die 1M-Kontextzahl entwirfst, die derzeit eine Eigenschaft der Architektur ist, kein gemessener Wert.

Worauf man achten sollte, ist Pull-Request 51129, der am 10. August ein needs-rebase-Label erhielt, nachdem Mergify Merge-Konflikte festgestellt hatte. Der Tag, an dem Solar Open 2 250B in einem getaggten vLLM-Release erscheint, ist der Tag, an dem es aufhört, ein Infrastrukturprojekt zu sein, und zu einem Modell wird, das jeder einfach ausprobieren kann. Der von der Presse berichtete AAII von 37 ist ein Anfang — eine erste externe Messung, so vorläufig sie auch sein mag, und eine, die immer noch nicht auf Artificial Analysis' eigener Bestenliste erscheint. Der eigentliche Test ist der, der auf unveränderter Software läuft, und er hat noch kein Datum.