Solar Open 2 250B : Des scores d'agent de pointe, mais nulle part où les exécuter

La fiche Hugging Face pour Solar Open 2 250B 250B vous donne une commande de service, et cette commande ne fonctionne pas. Elle demande à vLLM un analyseur de raisonnement nommé solar_open2, un analyseur d'appels d'outils nommé solar_open2, et un processeur de logits nommé SolarOpen2TemplateLogitsProcessor — trois éléments qui n'existent dans aucune version publiée de vLLM. La prise en charge de l'architecture est apparue dans la branche principale sous la forme d'une pull request non fusionnée le 5 août, deux semaines après la publication des poids par Upstage le 22 juillet. Cet écart reste le fait le plus intéressant à propos de Solar Open 2 pour l'instant, et c'est la partie que tous les articles de lancement ont ignorée au profit du tableau de références. Voici donc l'autre version : ce qu'Upstage a réellement livré, ce que ses propres chiffres établissent et n'établissent pas, ce que change le seul score externe désormais officiel, et ce qu'il faut pour obtenir un seul token de la chose — mesuré par rapport à DeepSeek V4 Flash, le modèle qu'Upstage a choisi comme étalon principal.

Ce qu'Upstage a réellement livré

Tout ce qui suit provient du fichier config.json du dépôt lui-même et du rapport technique Solar Open 2 (arXiv 2607.20062) — des sources primaires, certes, mais qui émanent du fournisseur. Aucun laboratoire indépendant n’a publié ses propres mesures de ce modèle. Un chiffre externe a toutefois fait surface, un score de 37 à l’indice Artificial Analysis Intelligence Index rapporté par la presse, issu de l’évaluation de deuxième round du gouvernement, et il mérite son propre paragraphe dans la section des benchmarks ci-dessous, car il est rapporté, non reproduit.

• Taille — 250,287,794,944 paramètres au total, environ 15B actifs par jeton

• Sparsité — 320 experts routés plus 1 expert partagé, top-8 routés par jeton, et first_k_dense_replace défini sur 0, ce qui signifie que le mélange commence dès la couche zéro sans aucune des couches de préchauffage denses que les conceptions MoE comparables conservent habituellement.

Forme — 48 couches, taille cachée 4096, dimension des têtes 128, 64 têtes de requête contre 8 têtes de clé/valeur

• Attention — 12 couches softmax (GQA), aux indices 0, 4, 8 et ainsi de suite jusqu’à 44 ; les 36 autres couches sont de l’attention linéaire. Les trois quarts de la pile ne contiennent aucun softmax.

• Positions — use_rope est false. Il n'y a aucun encodage positionnel du tout.

Contexte — max_position_embeddings de 1,048,576

• Vocabulaire — 196 608 jetons, couvrant l'anglais, le coréen et le japonais

• Poids — bfloat16, ce qui équivaut à 500,6 Go. Cela représente simplement 250,29 milliards de paramètres multipliés par deux octets, et cela correspond à l'empreinte que Nota AI rapporte pour le modèle non quantifié.

• Entraînement — environ 11,9 T de jetons selon le rapport : 10 T de pré-entraînement général, 1 T sur un sous-ensemble de haute qualité sélectionné, 0,9 T pour l'extension de longueur, avec un ratio réel-synthétique annoncé de 4:6, l'anglais au-dessus de 80 % et les mathématiques et le code chacun au moins 15 %.

• Licence — la licence Upstage Solar, assortie de conditions (ci-dessous)

Le prédécesseur, Solar Open 1, était un modèle de 100B lancé en janvier. Solar Open 2 n'est pas tant une mise à jour de celui-ci qu'un animal différent.

L'architecture est la véritable histoire.

Le schéma de couches est une couche softmax suivie de trois couches d'attention linéaire, répété douze fois. C'est ce qui a été rapporté. Ce qui ne l'a pas été, c'est quelle attention linéaire, et pourquoi cela importe.

Les couches linéaires sont KDA — Kimi Delta Attention, le mécanisme que Moonshot AI a introduit pour Kimi Linear. Upstage n'a pas inventé une nouvelle attention linéaire ; il a adopté celle d'un autre et a changé une chose. Le changement est visible dans la configuration via kda_allow_neg_eigval défini à true, et le rapport explique ce que cela apporte : le KDA standard contraint les valeurs propres de la transition d'état à l'intervalle [0,1], de sorte que chaque étape ne peut qu'ajouter à l'état récurrent ou l'atténuer. Activer ce drapeau élargit la force d'écriture à beta = 2·sigmoid(·), un intervalle de (0,2), ce qui repousse les valeurs propres vers [-1,1]. Une étape peut désormais inverser le signe de ce qui est déjà stocké. En termes simples : l'état peut se corriger lui-même plutôt que seulement accumuler, ce qui est le mécanisme déclaré par Upstage pour maintenir une longue trajectoire d'agent cohérente à travers de nombreux appels d'outils.

Les douzaines de couches softmax sont des GQA avec une porte de sortie sigmoïde par élément — use_gqa_gate est vrai dans la configuration — ce que le rapport attribue à l'ajout de non-linéarité et à la suppression des puits d'attention.

Et la raison pour laquelle il n'y a pas de RoPE découle des couches linéaires. Parce qu'un état récurrent encode intrinsèquement l'ordre des tokens, le rapport soutient que l'on peut supprimer entièrement l'encodage positionnel et cesser d'être lié à la distribution de longueur sur laquelle on a entraîné le modèle. Dans ce cadre, RoPE est ce qui limite l'extrapolation ; supprimez-le et le plafond n'est plus une fonction de vos données d'entraînement.

Le nombre de 1M est une revendication de conception, pas une mesure.

Cet argument est élégant, et c'est aussi toute la base du titre annoncé d'un million de jetons. Le rapport technique ne publie aucun RULER, aucun test d'aiguille dans la botte de foin, aucune suite de tests long-contexte d'aucune sorte. La fenêtre est justifiée par l'architecture, pas démontrée sur un benchmark. Pendant ce temps, le seul compte rendu de déploiement public que nous ayons trouvé — Backend.AI, servant le modèle quantifié sur deux systèmes DGX Spark — fixait max-model-len à 200 000, et non à 1 048 576. Le plafond architectural pourrait bien être réel. La qualité qui survit à 500K ou 1M de jetons n'est tout simplement pas dans l'article.

L'affirmation d'efficacité comporte le même astérisque : le rapport indique que la pile hybride nécessite environ un quart de la mémoire et du calcul d'une pile tout-softmax avec un contexte de 1M, et séparément que la conception hybride a atteint la perte cible avec environ 3,2× moins de tokens d'entraînement que le tout-softmax sur MMLU. Ces deux chiffres émanent d'Upstage. Aucun chiffre de débit ni de latence n'est publié.

La carte de référence, lue honnêtement

Sur la suite en anglais, contre DeepSeek V4 Flash, Solar Open 2 250B obtient 86,2 sur MMLU-Pro contre 85,9, et 92,4 sur LiveCodeBench v6 contre 92,3 — des différences suffisamment faibles pour relever du bruit de score. Puis il enregistre 16,6 sur APEX-Agents contre 13,2, ce qui constitue le seul écart réel et, sans surprise, le chiffre sur lequel Upstage mène.

Les pertes figurent dans le même rapport et reçoivent moins de temps d'antenne. SWE-Bench Verified : 70,4 contre 73,8. GDPval-AA v2, sur ELO : 1128 contre 1187. Terminal Bench Hard : 28,3, contre 41,7 pour MiMo-V2.5. ArtifactsBench : 55,9, derrière les deux références de pointe. Au crédit d'Upstage, le rapport nomme ces écarts et ce à quoi ils renvoient — l'ingénierie logicielle au niveau du dépôt et du terminal, ainsi que la précision numérique des livrables bureautiques — au lieu de les passer sous silence.

La comparaison qui impressionne vraiment est interne. Contre Solar Open 1 : LiveCodeBench v6 passe de 56.5 à 92.4, SWE-Bench Verified de 15.4 à 70.4, APEX-Agents de 2.4 à 16.6. Quelle que soit votre lecture des confrontations directes, c'est un véritable saut générationnel en six mois.

Sur le coréen, la moyenne globale de la suite est de 85.4 contre 84.9 pour DeepSeek V4 Flash — mais la moyenne fait tout le travail. Solar Open 2 250B perd sur KMMLU-Pro (78.4 contre 78.9) et Ko-AIME'25 (97.7 contre 98.0), et gagne sur Ko-GDPval (86.8 contre 85.0). L'avance vient du benchmark livrable, pas des connaissances ni des mathématiques.

Ce qui nous amène à l’affirmation qui est allée le plus loin : Solar Open 2 250B égalerait un modèle plus de six fois plus grand. La base est Ko-GDPval, où il obtient 86,8 contre 86,9 pour DeepSeek-V4-Pro. C’est un benchmark coréen, et c’est une égalité plutôt qu’une victoire directe — alors que sur la suite anglaise, le petit frère de V4-Pro bat déjà Solar Open 2 250B sur SWE-Bench Verified. Un benchmark ne se généralise pas en une loi d’efficacité par taille. Une mise en garde connexe : les chiffres de référence pour APEX-Agents diffèrent légèrement entre le papier et la couverture secondaire (13,2 contre 13,4 pour les mêmes modèles), donc considérez l’ordre comme directionnel plutôt que précis.

En ce qui concerne la préférence, un test de comparaison par paires en aveugle portant sur 835 conversations coréennes a placé Solar Open 2 250B en tête avec 44,1 % contre 26,6 %, le rapport attribuant cette victoire en matière d'alignement et d'honnêteté à un ancrage culturel plutôt qu'à un entraînement de sécurité supplémentaire. Il convient de noter ce qui est absent : le rapport ne contient aucune évaluation quantitative des préjudices, des refus ou des jailbreaks.

La fiche Hugging Face a depuis gagné quelques chiffres supplémentaires dans sa section des résultats d'évaluation — GPQA Diamond 86,3, HLE 28,8 et MathArena AIME 2026 95,7 — mais ils ont été extraits de la fiche du modèle lui-même plutôt que d'un test indépendant, ils portent donc la même étiquette que tout ce qui précède : les chiffres d'Upstage, non reproduits.

Un chiffre externe a maintenant fait surface, qui ne provient pas du laboratoire d'Upstage. Le 13 août, les médias financiers coréens — Edaily, Seoul Economic Daily, ITDaily et iNews24, qui ont tous publié les mêmes chiffres — ont rapporté les scores d'évaluation du deuxième tour du programme d'IA souveraine du gouvernement, mesurés sur l'indice d'intelligence d'Artificial Analysis (AAII v4.1.1) : Motif 3 à 47, Solar Open 2 250B à 37, le A.X-K2 de SK Telecom à 35, et le K-EXAONE 2.0 0803 de LG AI Research à 31. Ce 37 place Solar Open 2 250B deuxième des quatre finalistes coréens, à dix points de Motif 3. Qualifions-le précisément : c'est une information rapportée par la presse — le score n'est pas apparu sur le classement propre d'Artificial Analysis, qui ne renvoie toujours rien pour ce modèle — et les mêmes articles notent que l'AAII ne comporte aucun benchmark en langue coréenne, un véritable angle mort pour un modèle dont les résultats nationaux sont au cœur de l'argumentaire. Mais c'est la première évaluation de Solar Open 2 250B qui ne provienne pas d'Upstage, et elle est cohérente avec le reste de cet article : de bons scores sur les plans agent et livrables, avec une grande partie du reste qui n'est toujours pas prouvée par quiconque en dehors du fournisseur.

Pourquoi personne ne peut le servir sur un logiciel standard

La fiche du modèle raconte mieux l'histoire que n'importe quel commentaire. Les téléchargements du mois dernier dépassent désormais 26 000, accompagnés de 743 likes, seize quantifications communautaires et trois finetunes — et, dans la boîte Inference Providers, la ligne « Ce modèle n'est déployé par aucun fournisseur d'inférence » tient toujours, avec une douzaine de personnes désormais listées comme demandant le support d'un fournisseur sur la fiche. Un intérêt réel, zéro endpoint hébergé.

Si l'on suit les déploiements en production, ils mènent tous à un fork. Le build NVFP4 de Nota AI verrouille son installation sur git+https://github.com/UpstageAI/vllm.git au tag v0.22.0-solar-open2 — le propre vLLM d'Upstage. L'article de Backend.AI sur le DGX Spark nécessitait ce fork ainsi qu'un FlashInfer patché, car le FlashInfer en amont ne prenait pas en charge l'expert-parallel et n'acceptait pas le format compressed-tensors.

Le support dans la branche principale est la pull request 51129 contre vllm-project/vllm, ouverte le 5 août par un contributeur utilisant le nom oesni. Elle est toujours ouverte : le 10 août, mergify a signalé des conflits de fusion, de sorte que la PR porte désormais l’étiquette « needs-rebase » et attend toujours une revue. Ce que cette PR devait construire est la description la plus honnête de la difficulté de ce modèle qui existe en public :

• Une couche KimiGatedDeltaAttention spécifique à Solar dans un nouveau solar_open2.py, portant le bêta 2·sigmoid(b) issu du changement de valeur propre négative.

L'opération vllm::solar_open2_kda_attention enregistrée comme op de découpage de graphe CUDA.

• Un warmup de prefill KDA au moment du profilage, plafonné à 2048 jetons, ajouté spécifiquement parce que les prefills réels étaient environ 23 % plus lents sans lui.

• Analyseurs de sortie de raisonnement et d'appels d'outils pour les modes streaming et non-streaming

• Validation du serving sur 8×B200 rapportant 107,02 GiB par rang de cache KV, ainsi que 463 tests unitaires réussis.

Ce sont les chiffres de l'auteur de la PR, non reproduits par quiconque, et le code peut encore changer avant d'être fusionné. Mais lisez cette liste à côté de la section sur l'architecture et la forme du problème devient évidente : les deux choix qui rendent Solar Open 2 250B peu coûteux à exécuter en contexte long — KDA dans les trois quarts des couches, et pas de RoPE — sont précisément les choix pour lesquels les piles d'inférence à usage général n'ont aucun chemin de code existant. L'ouverture des poids et l'ouverture du chemin pour les exécuter sont deux choses différentes, et une seule d'entre elles a été livrée le 22 juillet.

Ce qu'il en coûte de se lancer

Commençons par le plancher mémoire. 500,6 Go de poids bfloat16 contre les 141 Go d'un H200 signifient que quatre GPU offrent 564 Go — soit environ 63 Go restants sur l'ensemble du nœud pour le cache KV et les activations avant qu'une seule requête n'arrive. C'est pourquoi la fiche indique quatre H200 comme minimum et en recommande huit, et pourquoi FlexAI le propose en tant que endpoint dédié 8×H100 avec une tarification sur demande plutôt que sur une API partagée facturée au jeton.

La quantification abaisse fortement ce plancher. La version NVFP4 de Nota AI (poids et activations en 4 bits, taille de groupe 16, au format compressed-tensors) fait passer le modèle de 500,6 Go à 153,3 Go, et leur propre évaluation chiffre le coût en précision à 0,22 point en moyenne sur quatre benchmarks — 81,57 à 81,35, avec Tau2-Bench de 75,20 à 75,08, GPQA-Diamond de 86,26 à 85,45, MMLU-Pro de 86,19 à 86,15, et LiveCodeBench qui évolue dans l'autre sens, de 87,03 à 88,55, ce qui relève du bruit de quantification plutôt que d'une amélioration. Le hic, c'est le matériel : NVFP4 nécessite les cœurs tensoriels FP4 introduits avec Blackwell, donc uniquement B200 ou GB200, rien sur Hopper. Si vous êtes sur des H100, la variante qu'il vous faut est leur version INT4 avec élagage global — 117,8 Go après élagage, dimensionnée pour en tenir deux.

Voici maintenant le calcul qui tranche. DeepSeek V4 Flash — encore une fois, le modèle qu'Upstage a choisi comme référence — coûte 0,15 $ par million de tokens en entrée et 0,29 $ par million en sortie sur OrcaRouter, soit le prix catalogue de DeepSeek transmis directement sans aucune majoration. Avec un ratio entrée/sortie de 3:1, le coût mixte revient à environ 0,185 $ par million. Prenons un tarif illustratif de 2 $ de l'heure de GPU sur un nœud de huit GPU : cela donne environ 11 700 $ par mois avant que quiconque n'envoie une requête — soit l'équivalent de près de 63 milliards de tokens mixtes de trafic API, ou 2,1 milliards de tokens par jour, chaque jour, juste pour atteindre le seuil de rentabilité. Réduisez à un nœud de deux GPU et le seuil de rentabilité tombe à environ 16 milliards de tokens par mois. Remplacez par votre propre tarif GPU ; la structure ne change pas. Auto-héberger un modèle de 250B est une décision sur l'utilisation et le contrôle, pas une réduction de coût.

Pour être précis sur ce qui est disponible et ce qui ne l'est pas : Solar Open 2 250B n'est pas sur OrcaRouter, et selon sa propre fiche modèle, il n'est sur aucun fournisseur d'inférence. Ce qui est sur OrcaRouter, c'est le champ contre lequel il est mesuré — DeepSeek V4 Flash, Qwen3.8-Max et quelques centaines d'autres derrière une seule clé au prix catalogue du fournisseur, avec bascule automatique entre fournisseurs si l'un d'eux tombe en panne. Cela importe ici pour une raison pratique et restreinte : si la question à laquelle vous voulez réellement répondre est « est-ce qu'un modèle optimisé pour les agents bat ce que nous appelons déjà en production ? », vous pouvez exécuter cette moitié de la comparaison en changeant une chaîne de modèle cet après-midi, pendant que le devis GPU pour l'autre moitié est encore en cours d'achat.

Deux chaînes sur la licence

La licence Upstage Solar permet l'utilisation commerciale, le fine-tuning et la distillation, et Upstage la décrit comme étant basée sur Apache-2.0, avec des conditions de marque ajoutées. Les deux obligations ajoutées sont celles à lire attentivement : un modèle dérivé doit porter le préfixe « Solar » dans son nom, et vous devez afficher l'attribution « Built with Solar ».

Pour un déploiement interne, cela ne pose aucun problème. Si vous comptez en distiller quelque chose à commercialiser sous votre propre marque, la clause de dénomination est une décision de marque déguisée en terme de licence, et elle mérite les vingt minutes d'un avocat avant de lancer un entraînement. Lisez la clause sur le dépôt plutôt que de vous fier aux articles à son sujet — la couverture de cette licence a été imprécise, avec au moins un article qui la décrit purement et simplement comme Apache 2.0.

Qui devrait bouger maintenant, et qui devrait attendre ?

Franchissez le pas si votre produit, c'est la qualité des livrables en coréen ou en japonais, et si vous pouvez placer les poids sur du matériel que vous possédez déjà — cette combinaison est exactement ce à quoi sert {{1}}« poids ouverts, sans endpoint »{{/1}}, et Upstage le formule explicitement : {{2}}la souveraineté, c'est pouvoir déployer et vérifier un modèle soi-même, pas seulement qu'il ait été entraîné sur le territoire national{{/2}}. Franchissez le pas si vous avez des GPU inactifs et une charge de travail d'agents d'un volume suffisant pour les occuper, car en utilisation réelle, l'arithmétique par jeton s'inverse. Franchissez le pas si des exigences d'audit ou de résidence des données excluent d'emblée le recours à une API.

Attention si vous voulez un endpoint par token. Upstage a déclaré qu’il a l’intention de lister Solar Open 2 250B sur une plateforme tierce ; au moment où nous écrivons, cela ne s’est pas produit — l’essai Playground n’a duré que jusqu’au 31 juillet, et la fiche du modèle n’affiche toujours aucun fournisseur. Attention si vous êtes sur Hopper et comptiez sur la version 4 bits, car la version NVFP4 nécessite Blackwell. Et attention avant de concevoir quoi que ce soit autour du nombre de contexte de 1M, qui est actuellement une propriété de l’architecture plutôt qu’un résultat mesuré.

Ce qu'il faut surveiller, c'est la pull request 51129, qui a reçu le 10 août un label « needs-rebase » après que Mergify a signalé des conflits de fusion. Le jour où Solar Open 2 250B apparaîtra dans une version vLLM taguée sera le jour où il cessera d'être un projet d'infrastructure pour devenir un modèle que tout le monde peut simplement essayer. L'AAII de 37 rapporté par la presse est un début — une première lecture externe, certes provisoire, et qui ne figure toujours pas sur le leaderboard d'Artificial Analysis. Le vrai test est celui qui tourne sur un logiciel standard, et il n'a pas encore de date.