Solar Open 2 250B: Punteggi da agente di frontiera senza un posto dove eseguirli

La scheda Hugging Face per Solar Open 2 250B 250B ti dà un comando di serving, e il comando non funziona. Chiede a vLLM un parser di reasoning chiamato solar_open2, un parser di tool-call chiamato solar_open2 e un logits processor chiamato SolarOpen2TemplateLogitsProcessor — tre cose che non esistono in nessuna versione rilasciata di vLLM. Il supporto per l'architettura è apparso nel ramo principale come una pull request non ancora unita il 5 agosto, due settimane dopo che Upstage ha pubblicato i pesi il 22 luglio. Questo divario è ancora il fatto più interessante su Solar Open 2 in questo momento, ed è la parte che ogni articolo di lancio ha tralasciato a favore della tabella dei benchmark. Quindi ecco l'altra versione: cosa ha effettivamente rilasciato Upstage, cosa i suoi stessi numeri stabiliscono e non stabiliscono, cosa cambia l'unico punteggio esterno ora agli atti, e cosa serve per ottenere un singolo token dalla cosa — misurato rispetto a DeepSeek V4 Flash, il modello che Upstage ha scelto come proprio principale termine di paragone.

Ciò che Upstage ha effettivamente lanciato

Tutto ciò che segue proviene dal config.json del repository stesso e dal rapporto tecnico di Solar Open 2 (arXiv 2607.20062) — fonti primarie, ma fonti primarie del fornitore. Nessun laboratorio indipendente ha pubblicato proprie misurazioni di questo modello. È emerso ora un dato esterno, un punteggio di 37 sul Artificial Analysis Intelligence Index riportato dalla stampa, proveniente dalla valutazione del secondo ciclo del governo, e merita un paragrafo dedicato nella sezione benchmark qui sotto perché è riportato, non riprodotto.

• Dimensione — 250.287.794.944 parametri in totale, circa 15B attivi per token

• Sparsità — 320 esperti instradati più 1 esperto condiviso, top-8 instradati per token, e first_k_dense_replace impostato a 0, il che significa che la miscela inizia al layer zero senza nessuno dei layer densi di warm-up che i progetti MoE comparabili di solito mantengono.

• Forma — 48 layer, hidden size 4096, head dim 128, 64 query head contro 8 key/value head

• Attenzione — 12 strati softmax (GQA), agli indici 0, 4, 8 e così via fino a 44; gli altri 36 strati sono attenzione lineare. Tre quarti dello stack non contengono softmax.

• Posizioni — use_rope è false. Non c'è alcuna codifica posizionale.

• Contesto — max_position_embeddings di 1.048.576

• Vocabolario — 196.608 token, in inglese, coreano e giapponese

• Pesi — bfloat16, che corrisponde a 500,6 GB. Sono solo 250,29 miliardi di parametri moltiplicati per due byte, e corrisponde all'ingombro riportato da Nota AI per il modello non quantizzato.

• Addestramento — circa 11,9T token secondo il report: 10T di pre-addestramento generale, 1T su un sottoinsieme curato di alta qualità, 0,9T per l'estensione della lunghezza, con un rapporto dichiarato di 4:6 tra dati reali e sintetici, con inglese superiore all'80% e matematica e codice ciascuno almeno al 15%

• Licenza — la Upstage Solar License, che prevede alcune condizioni (di seguito)

Il predecessore, Solar Open 1, era un modello da 100B rilasciato a gennaio. Solar Open 2 non è tanto un aggiornamento di quest'ultimo quanto un animale diverso.

L'architettura è la vera storia.

Lo schema dei layer è composto da un layer softmax seguito da tre layer di attenzione lineare, ripetuto dodici volte. Questo è quanto è stato riportato. Ciò che non è stato riportato è quale attenzione lineare venga utilizzata, e perché è importante.

I layer lineari sono KDA — Kimi Delta Attention, il meccanismo che Moonshot AI ha introdotto per Kimi Linear. Upstage non ha inventato una nuova attenzione lineare; ha adottato quella di qualcun altro e ha cambiato una cosa. Il cambiamento è visibile nella config come kda_allow_neg_eigval impostato su true, e il report spiega cosa comporta: la KDA standard vincola gli autovalori della transizione di stato all'intervallo [0,1], quindi ogni passo può solo aggiungere allo stato ricorrente o attenuarlo. Impostare quel flag amplia la forza di scrittura a beta = 2·sigmoid(·), un intervallo di (0,2), che spinge gli autovalori fino a [-1,1]. Un passo ora può invertire il segno di ciò che è già memorizzato. In termini semplici: lo stato può correggersi invece di limitarsi ad accumulare, che è il meccanismo dichiarato da Upstage per tenere insieme una lunga traiettoria di agente attraverso molte chiamate di strumenti.

I dodici layer softmax sono GQA con un gate di output sigmoideo elementwise — use_gqa_gate è true nella config — a cui il report attribuisce il merito di aggiungere non-linearità e sopprimere i sink di attenzione.

E il motivo per cui non c'è RoPE deriva dai layer lineari. Poiché uno stato ricorrente codifica intrinsecamente l'ordine dei token, il report sostiene che si possa eliminare del tutto l'encoding posizionale e smettere di essere vincolati alla distribuzione di lunghezze su cui ci si è addestrati. RoPE, in questa ottica, è ciò che limita l'estrapolazione; rimuovilo e il tetto non sarà più una funzione dei tuoi dati di addestramento.

Il numero 1M è un'affermazione progettuale, non una misurazione.

Quell'argomentazione è elegante ed è anche l'intera base del titolo da 1 milione di token. Il report tecnico non pubblica alcun RULER, nessun ago nel pagliaio, nessuna suite di contesto lungo di alcun tipo. La finestra è sostenuta dall'architettura, non dimostrata su un benchmark. Nel frattempo, l'unico resoconto di deployment pubblico che siamo riusciti a trovare — Backend.AI, che serve il modello quantizzato su due sistemi DGX Spark — ha impostato max-model-len a 200.000, non a 1.048.576. Il soffitto architetturale potrebbe ben essere reale. Quale qualità sopravviva a 500K o 1 milione di token semplicemente non è nel documento.

L'affermazione sull'efficienza porta lo stesso asterisco: il rapporto dichiara che lo stack ibrido richiede all'incirca un quarto della memoria e della potenza di calcolo di uno stack interamente softmax a un contesto di 1M, e separatamente che il design ibrido ha raggiunto la loss target con circa 3,2× token di addestramento in meno rispetto all'interamente softmax su MMLU. Entrambi sono dati forniti da Upstage stessa. Non vengono pubblicati numeri relativi a throughput o latenza.

La scheda di benchmark, letta onestamente

Nella suite inglese, contro DeepSeek V4 Flash, Solar Open 2 250B ottiene 86.2 su MMLU-Pro contro 85.9 e 92.4 su LiveCodeBench v6 contro 92.3 — differenze abbastanza piccole da essere rumore di punteggio. Poi ottiene 16.6 su APEX-Agents contro 13.2, che è l'unico divario reale e, prevedibilmente, il numero con cui Upstage è in testa.

Le perdite sono nello stesso report e ricevono meno attenzione. SWE-Bench Verified: 70.4 contro 73.8. GDPval-AA v2, su ELO: 1128 contro 1187. Terminal Bench Hard: 28.3, contro 41.7 per MiMo-V2.5. ArtifactsBench: 55.9, dietro entrambe le baseline di frontiera. A merito di Upstage, il report nomina queste lacune e a cosa puntano — ingegneria del software a livello di repository e terminale, e precisione numerica nei deliverable da ufficio — piuttosto che nasconderle.

Il confronto che impressiona davvero è interno. Rispetto a Solar Open 1: LiveCodeBench v6 passa da 56,5 a 92,4, SWE-Bench Verified da 15,4 a 70,4, APEX-Agents da 2,4 a 16,6. Qualunque cosa pensi dei confronti diretti, si tratta di un vero salto generazionale in sei mesi.

In coreano, la media dell'intera suite è 85,4 contro l'84,9 di DeepSeek V4 Flash — ma è la media a fare il lavoro. Solar Open 2 250B perde su KMMLU-Pro (78,4 contro 78,9) e Ko-AIME'25 (97,7 contro 98,0), e vince su Ko-GDPval (86,8 contro 85,0). Il vantaggio deriva dal benchmark di consegna, non dalla conoscenza o dalla matematica.

Il che ci porta alla tesi che si è spinta più lontano: Solar Open 2 250B eguaglia un modello più di sei volte più grande di sé. Il riferimento è Ko-GDPval, dove ottiene 86.8 contro l'86.9 di DeepSeek-V4-Pro. Si tratta di un singolo benchmark coreano, ed è un pareggio più che una vittoria in un confronto diretto — mentre sulla suite inglese, il fratello più piccolo di V4-Pro batte già Solar Open 2 250B su SWE-Bench Verified. Un singolo benchmark non basta a stabilire una legge di efficienza dimensionale. Una cautela correlata: i valori di base per APEX-Agents differiscono leggermente tra il paper e la copertura secondaria (13.2 contro 13.4 per gli stessi modelli), quindi trattate l'ordinamento come indicativo piuttosto che preciso.

{{1}}In termini di preferenza, un test comparativo alla cieca su 835 conversazioni coreane ha posto Solar Open 2 250B{{/1}} {{2}}davanti con il 44.1% contro il 26.6%,{{/2}} {{3}}con il rapporto che attribuisce la sua vittoria in allineamento e onestà al radicamento culturale piuttosto che a un addestramento aggiuntivo sulla sicurezza.{{/3}} {{4}}Vale la pena notare ciò che è assente: il rapporto non contiene alcuna valutazione quantitativa di danno, rifiuto o jailbreak di alcun tipo.{{/4}}

La scheda Hugging Face ha da allora aggiunto qualche numero in più nella sezione dei risultati di valutazione — GPQA Diamond 86.3, HLE 28.8 e MathArena AIME 2026 95.7 — ma sono stati estratti dalla scheda del modello stesso piuttosto che da un'esecuzione indipendente, quindi portano la stessa etichetta di tutto ciò che è sopra: cifre di Upstage, non riprodotte.

È ora emerso un numero esterno che non proviene dal laboratorio di Upstage. Il 13 agosto, i media finanziari coreani — Edaily, Seoul Economic Daily, ITDaily e iNews24, tutti con le stesse cifre — hanno riportato i punteggi di valutazione del secondo round del programma governativo di IA sovrana, misurati sull'Intelligence Index di Artificial Analysis (AAII v4.1.1): Motif 3 a 47, Solar Open 2 250B a 37, A.X-K2 di SK Telecom a 35 e K-EXAONE 2.0 0803 di LG AI Research a 31. Il 37 colloca Solar Open 2 250B al secondo posto tra i quattro finalisti coreani, a dieci punti da Motif 3. Diciamolo con precisione: è un dato riportato dalla stampa — il punteggio non è apparso sulla classifica di Artificial Analysis, che per questo modello restituisce ancora nulla — e la stessa copertura segnala che l'AAII non include benchmark in lingua coreana, un vero punto cieco per un modello i cui risultati domestici sono centrali per la sua proposta. Ma è la prima lettura su Solar Open 2 250B che non risale a Upstage, ed è coerente con il resto di questo articolo: punteggi forti su agente e deliverable, con gran parte del resto ancora non comprovato da nessuno al di fuori del fornitore.

Perché nessuno può servirlo su software standard.

La scheda del modello racconta la storia meglio di qualsiasi commento. I download dell'ultimo mese hanno ormai superato i 26.000, insieme a 743 like, sedici quantizzazioni della community e tre fine-tuning — e, nella casella Inference Providers, la scritta "Questo modello non è distribuito da alcun Inference Provider" regge ancora, con una dozzina di persone che ora risultano aver chiesto il supporto di un provider tramite la scheda. Interesse reale, zero endpoint ospitati.

Segui le distribuzioni funzionanti e portano tutte a un fork. La build NVFP4 di Nota AI fissa la propria installazione a git+https://github.com/UpstageAI/vllm.git al tag v0.22.0-solar-open2 — la vLLM di Upstage. L'approfondimento di Backend.AI su DGX Spark richiedeva quel fork oltre a un FlashInfer patchato, perché il FlashInfer upstream non aveva supporto expert-parallel e non accettava il formato compressed-tensors.

Il supporto mainline è la pull request 51129 su vllm-project/vllm, aperta il 5 agosto da un contributore noto come oesni. È ancora aperta: il 10 agosto mergify ha segnalato conflitti di merge, quindi la PR ora porta l'etichetta needs-rebase e attende ancora una revisione. Ciò che quella PR ha dovuto costruire è la descrizione più onesta della difficoltà di questo modello che esista pubblicamente:

• Un layer KimiGatedDeltaAttention specifico per Solar in un nuovo solar_open2.py, che trasporta la beta 2·sigmoid(b) dalla modifica dell'autovalore negativo.

L'operazione vllm::solar_open2_kda_attention registrata come op di splitting del grafo CUDA

• Un riscaldamento del prefill KDA al momento del profiling, con un tetto di 2048 token, aggiunto specificamente perché i prefill reali giravano circa il 23% più lentamente senza di esso.

• Parser per l'output di reasoning e le chiamate agli strumenti, sia in modalità streaming che non-streaming

• Validazione del serving su 8×B200 che riporta 107,02 GiB per rank di cache KV, insieme a 463 unit test superati.

Quelle sono le cifre dell'autore della PR, non riprodotte da nessun altro, e il codice può ancora cambiare prima del merge. Ma leggete quell'elenco accanto alla sezione sull'architettura e i contorni del problema sono evidenti: le due scelte che rendono Solar Open 2 250B economico da eseguire con un contesto lungo — KDA in tre quarti dei layer e nessuna RoPE — sono esattamente le scelte per le quali gli stack di inferenza generici non hanno alcun percorso di codice esistente. L'apertura dei pesi e l'apertura del percorso per eseguirli sono cose diverse, e solo una delle due è stata rilasciata il 22 luglio.

Quanto costa alzarsi

Partiamo dal limite minimo di memoria. 500.6 GB di pesi bfloat16 contro i 141 GB di un H200 significano che quattro GPU offrono 564 GB — circa 63 GB rimasti sull’intero nodo per la cache KV e le attivazioni prima che arrivi una singola richiesta. Questo è il motivo per cui la scheda elenca quattro H200 come minimo e ne raccomanda otto, e per cui FlexAI lo offre come endpoint dedicato 8×H100 con prezzo su richiesta anziché tramite un’API condivisa per-token.

La quantizzazione sposta quel limite minimo molto in basso. La build NVFP4 di Nota AI (pesi e attivazioni a 4 bit, dimensione del gruppo 16, in formato compressed-tensors) porta il modello da 500,6 GB a 153,3 GB, e la loro valutazione stima il costo in accuratezza a 0,22 punti in media su quattro benchmark — da 81,57 a 81,35, con Tau2-Bench da 75,20 a 75,08, GPQA-Diamond da 86,26 a 85,45, MMLU-Pro da 86,19 a 86,15, e LiveCodeBench che si muove nella direzione opposta, da 87,03 a 88,55, il che è rumore di quantizzazione piuttosto che un miglioramento. Il problema è l'hardware: NVFP4 richiede i tensor core FP4 introdotti con Blackwell, quindi solo B200 o GB200, niente su Hopper. Se sei su H100, la variante che vuoi è la loro build INT4 con potatura globale — 117,8 GB dopo la potatura, dimensionata per stare su due di essi.

Ora l'aritmetica che decide la questione. DeepSeek V4 Flash — di nuovo, il modello rispetto a cui Upstage ha scelto di essere misurato — costa $0.15 per milione di token in input e $0.29 per milione in output su OrcaRouter, che è il prezzo di listino di DeepSeek applicato direttamente con markup dello 0%. Con un mix input-output di 3:1, il costo medio è di circa $0.185 per milione. Mettiamo un costo illustrativo di $2 per GPU-ora su un nodo a otto GPU: si arriva a circa $11.700 al mese prima che qualcuno invii una richiesta — l'equivalente di circa 63 miliardi di token misti di traffico API, ovvero 2,1 miliardi di token al giorno, ogni giorno, solo per raggiungere il pareggio. Riducendo a un nodo a due GPU, il pareggio scende a circa 16 miliardi di token al mese. Sostituisci la tua tariffa GPU; la struttura non cambia. Ospitare da sé un modello da 250B è una decisione che riguarda utilizzo e controllo, non uno sconto.

Per essere precisi su cosa è e cosa non è disponibile: Solar Open 2 250B non è su OrcaRouter e, secondo la sua stessa scheda del modello, non è su nessun provider di inferenza. Ciò che è su OrcaRouter è il campo di confronto — DeepSeek V4 Flash, Qwen3.8-Max e un paio di centinaia di altri dietro un'unica chiave al prezzo di listino del provider, con failover tra provider se uno si interrompe. Il che è rilevante qui per un motivo ristretto e pratico: se la domanda a cui vuoi davvero una risposta è "un modello ottimizzato per agenti batte ciò che già chiamiamo in produzione", puoi eseguire quella metà del confronto cambiando una stringa del modello oggi pomeriggio, mentre il preventivo GPU per l'altra metà è ancora in fase di approvvigionamento.

Due stringhe sulla licenza

La licenza Upstage Solar consente l'uso commerciale, il fine-tuning e la distillazione, e Upstage la descrive come basata su Apache-2.0 con termini di brand aggiunti. I due obblighi aggiunti sono quelli da leggere attentamente: un modello derivato deve portare il prefisso "Solar" nel proprio nome e deve essere mostrata l'attribuzione "Built with Solar".

Per la distribuzione interna è un non evento. Se hai intenzione di distillare questo in qualcosa da distribuire sotto il tuo marchio di prodotto, la clausola di denominazione è una decisione di branding mascherata da termine di licenza, e vale venti minuti di un avvocato prima di iniziare un run di addestramento. Leggi la clausola sul repository piuttosto che fidarti di ciò che viene riportato su di essa — le segnalazioni su questa licenza sono state approssimative, incluso almeno un articolo che la descrive semplicemente come Apache 2.0.

Chi dovrebbe muoversi ora, e chi dovrebbe aspettare?

Passa se la qualità dei risultati in coreano o giapponese è il tuo prodotto e puoi mettere i pesi su hardware che già possiedi — quella combinazione è esattamente ciò per cui "open weights, no endpoint" è indicato, e la stessa impostazione di Upstage è esplicita: la sovranità significa poter distribuire e verificare un modello da soli, non solo che sia stato addestrato a livello nazionale. Passa se hai GPU inattive e un carico di lavoro di agenti con volume sufficiente a riempirle, perché con un utilizzo reale la matematica per token si inverte. Passa se i requisiti di audit o di residenza dei dati significano che un'API non è mai stata un'opzione.

Aspetta se vuoi un endpoint per token. Upstage ha dichiarato che intende elencare Solar Open 2 250B su una piattaforma di terze parti; al momento in cui scriviamo non è ancora accaduto — la prova su Playground è durata solo fino al 31 luglio e la scheda del modello non mostra ancora alcun provider. Aspetta se sei su Hopper e contavi sulla build a 4 bit, dato che la versione NVFP4 richiede Blackwell. E aspetta prima di progettare qualsiasi cosa attorno al numero di contesto di 1M, che attualmente è una proprietà dell'architettura piuttosto che un risultato misurato.

La cosa da tenere d'occhio è la pull request 51129, che il 10 agosto ha ricevuto l'etichetta needs-rebase dopo che Mergify ha segnalato conflitti di merge. Il giorno in cui Solar Open 2 250B apparirà in una release vLLM taggata sarà il giorno in cui smetterà di essere un progetto di infrastruttura e diventerà un modello che chiunque può semplicemente provare. L'AAII di 37 riportato dalla stampa è un inizio — una prima lettura esterna, per quanto provvisoria, e che ancora non compare nella classifica di Artificial Analysis. Il vero test è quello che gira su software standard, e non ha ancora una data.