Solar Open 2 250B: un agente de frontera que obtiene puntuaciones sin tener dónde ejecutarlo
Engineering & Research

Solar Open 2 250B: un agente de frontera que obtiene puntuaciones sin tener dónde ejecutarlo

Autor

Rowan Sterling

Fecha de publicación

Últimos modelos · 20Ver todos los modelos →
Benchmarks: Artificial Analysis · actualizado a diario
Volver a todas las publicaciones

La tarjeta de Hugging Face para Solar Open 2 250B 250B te da un comando para servir el modelo, y el comando no funciona. Le pide a vLLM un parser de razonamiento llamado solar_open2, un parser de llamadas a herramientas llamado solar_open2, y un procesador de logits llamado SolarOpen2TemplateLogitsProcessor — tres cosas que no existen en ninguna versión publicada de vLLM. El soporte para la arquitectura apareció en la rama principal como un pull request sin fusionar el 5 de agosto, dos semanas después de que Upstage publicara los pesos el 22 de julio. Esa brecha sigue siendo el dato más interesante sobre Solar Open 2 hoy por hoy, y es la parte que todos los artículos de lanzamiento omitieron en favor de la tabla de benchmarks. Así que aquí está la otra versión: lo que Upstage realmente lanzó, qué establecen y qué no establecen sus propios números, qué cambia la única puntuación externa que consta hasta ahora, y qué se necesita para sacar un solo token de la cosa — medido contra DeepSeek V4 Flash, el modelo que Upstage eligió como su principal referencia.

Lo que Upstage realmente lanzó

Todo lo que sigue proviene del config.json del propio repositorio y del informe técnico de Solar Open 2 (arXiv 2607.20062) — fuentes primarias, pero las fuentes primarias del proveedor. Ningún laboratorio independiente ha publicado sus propias mediciones de este modelo. Ahora ha surgido una cifra externa, una puntuación de 37 en el Índice de Inteligencia de Artificial Analysis reportada por la prensa, procedente de la evaluación de segunda ronda del gobierno, y recibe su propio párrafo en la sección de benchmarks a continuación porque es un dato reportado, no reproducido.

• Tamaño — 250,287,794,944 parámetros en total, aproximadamente 15B activos por token

• Sparsity — 320 expertos enrutados más 1 experto compartido, top-8 enrutados por token, y first_k_dense_replace establecido en 0, lo que significa que la mezcla comienza en la capa cero, sin ninguna de las capas de calentamiento densas que los diseños MoE comparables suelen mantener.

Forma — 48 capas, tamaño oculto 4096, dimensión de cabeza 128, 64 cabezas de consulta frente a 8 cabezas de clave/valor

• Atención — 12 capas softmax (GQA), en los índices 0, 4, 8 y así sucesivamente hasta 44; las otras 36 capas son de atención lineal. Tres cuartas partes de la pila no contienen softmax.

• Posiciones — use_rope es falso. No hay codificación posicional en absoluto.

• Contexto — max_position_embeddings de 1,048,576

• Vocabulario — 196.608 tokens, en inglés, coreano y japonés

• Pesos — bfloat16, lo que equivale a 500,6 GB. Eso es simplemente 250,29 mil millones de parámetros por dos bytes, y coincide con la huella que Nota AI reporta para el modelo sin cuantizar.

• Entrenamiento: alrededor de 11,9 T de tokens según el informe: 10 T de preentrenamiento general, 1 T en un subconjunto curado de alta calidad, 0,9 T para la extensión de longitud, con una proporción declarada de 4:6 real a sintético, con inglés por encima del 80 % y matemáticas y código cada uno al menos el 15 %.

• Licencia — la Licencia Upstage Solar, que tiene condiciones adjuntas (a continuación)

El predecesor, Solar Open 1, era un modelo de 100B lanzado en enero. Solar Open 2 no es tanto una actualización de aquel como un animal diferente.

La arquitectura es la verdadera historia

El patrón de capas consiste en una capa softmax seguida de tres capas de atención lineal, repetido doce veces. Eso ya se ha informado. Lo que no se ha informado es qué atención lineal se utiliza y por qué es importante.

Las capas lineales son KDA — Kimi Delta Attention, el mecanismo que Moonshot AI introdujo para Kimi Linear. Upstage no inventó una nueva atención lineal; adoptó la de otro y cambió una cosa. El cambio es visible en la configuración como kda_allow_neg_eigval establecido en true, y el informe explica qué aporta: la KDA estándar restringe los autovalores de transición de estado al rango [0,1], por lo que cada paso solo puede añadir al estado recurrente o atenuarlo. Activar esa bandera amplía la fuerza de escritura a beta = 2·sigmoid(·), un rango de (0,2), lo que empuja los autovalores hacia [-1,1]. Un paso ahora puede invertir el signo de lo que ya está almacenado. En términos simples: el estado puede corregirse a sí mismo en lugar de solo acumular, que es el mecanismo declarado de Upstage para mantener unida una trayectoria de agente larga a través de muchas llamadas a herramientas.

Las doce capas softmax son GQA con una puerta de salida sigmoide elemento a elemento — use_gqa_gate es true en la configuración — a la que el informe atribuye añadir no linealidad y suprimir sumideros de atención.

Y la razón de que no haya RoPE se deriva de las capas lineales. Debido a que un estado recurrente codifica el orden de los tokens de forma intrínseca, el informe argumenta que se puede eliminar por completo la codificación posicional y dejar de estar sujeto a la distribución de longitud con la que se entrenó. RoPE, en este marco, es lo que limita la extrapolación; elimínalo y el techo deja de ser una función de los datos de entrenamiento.

El número 1M es una afirmación de diseño, no una medición

Ese argumento es elegante y también es la base completa del titular de 1M de tokens. El informe técnico no publica ningún RULER, ni prueba de aguja en el pajar, ni suite de contexto largo de ningún tipo. La ventana se argumenta desde la arquitectura, no se demuestra en un benchmark. Mientras tanto, el único informe de despliegue público que pudimos encontrar — Backend.AI, sirviendo el modelo cuantizado en dos sistemas DGX Spark — estableció max-model-len en 200,000, no en 1,048,576. El techo arquitectónico bien podría ser real. Qué calidad sobrevive a 500K o 1M de tokens simplemente no está en el artículo.

La afirmación de eficiencia lleva el mismo asterisco: el informe indica que la pila híbrida necesita aproximadamente una cuarta parte de la memoria y el cómputo de una pila totalmente softmax en un contexto de 1M, y por separado que el diseño híbrido alcanzó la pérdida objetivo con alrededor de 3,2× menos tokens de entrenamiento que la pila totalmente softmax en MMLU. Ambas son cifras propias de Upstage. No se publican cifras de rendimiento ni de latencia en absoluto.

La ficha de benchmark, leída honestamente

En la suite en inglés, frente a DeepSeek V4 Flash, Solar Open 2 250B obtiene 86.2 en MMLU-Pro frente a 85.9, y 92.4 en LiveCodeBench v6 frente a 92.3: diferencias lo bastante pequeñas como para ser ruido de puntuación. Luego obtiene 16.6 en APEX-Agents frente a 13.2, que es la única brecha real y, como era de esperar, la cifra con la que Upstage lidera.

Las pérdidas están en el mismo informe y reciben menos atención. SWE-Bench Verified: 70,4 frente a 73,8. GDPval-AA v2, en ELO: 1128 frente a 1187. Terminal Bench Hard: 28,3, frente a 41,7 para MiMo-V2.5. ArtifactsBench: 55,9, por detrás de ambos referentes de vanguardia. Para ser justos con Upstage, el informe menciona estas brechas y hacia dónde apuntan —ingeniería de software a nivel de repositorio y terminal, y precisión numérica en entregables de oficina— en lugar de ocultarlas.

La comparación que realmente impresiona es la interna. Frente a Solar Open 1: LiveCodeBench v6 pasa de 56.5 a 92.4, SWE-Bench Verified de 15.4 a 70.4, APEX-Agents de 2.4 a 16.6. Sea cual sea tu opinión sobre los enfrentamientos directos, eso es un auténtico salto generacional en seis meses.

En coreano, el promedio del conjunto es 85.4 frente al 84.9 de DeepSeek V4 Flash — pero el promedio está haciendo el trabajo. Solar Open 2 250B pierde KMMLU-Pro (78.4 frente a 78.9) y Ko-AIME'25 (97.7 frente a 98.0), y gana Ko-GDPval (86.8 frente a 85.0). La ventaja proviene del benchmark entregable, no del conocimiento ni de las matemáticas.

Lo que nos lleva a la afirmación que más lejos llegó: que Solar Open 2 250B iguala a un modelo más de seis veces su tamaño. La base es Ko-GDPval, donde obtiene 86.8 frente a los 86.9 de DeepSeek-V4-Pro. Eso es un único benchmark coreano, y es un empate más que una victoria en el enfrentamiento directo — mientras que en el conjunto en inglés, el hermano menor de V4-Pro ya supera a Solar Open 2 250B en SWE-Bench Verified. Un único benchmark no se generaliza hasta convertirse en una ley de eficiencia por tamaño. Una advertencia relacionada: las cifras de referencia de APEX-Agents difieren ligeramente entre el artículo y la cobertura secundaria (13.2 frente a 13.4 para los mismos modelos), así que trate el orden como orientativo, no exacto.

En cuanto a preferencia, una prueba comparativa a ciegas sobre 835 conversaciones en coreano situó a Solar Open 2 250B por delante con un 44,1 % frente al 26,6 %, y el informe atribuye su victoria en alineación y honestidad al arraigo cultural más que a un entrenamiento adicional de seguridad. Vale la pena señalar lo que falta: el informe no contiene ninguna evaluación cuantitativa de daños, rechazos o jailbreak de ningún tipo.

La tarjeta de Hugging Face ha sumado desde entonces algunos números más a su sección de resultados de evaluación — GPQA Diamond 86.3, HLE 28.8 y MathArena AIME 2026 95.7 — pero se extrajeron de la propia tarjeta del modelo en lugar de una ejecución independiente, así que llevan la misma etiqueta que todo lo anterior: cifras de Upstage, no reproducidas.

Ahora ha aparecido una cifra externa que no proviene del laboratorio de Upstage. El 13 de agosto, los medios financieros coreanos — Edaily, Seoul Economic Daily, ITDaily e iNews24, todos publicando las mismas cifras — reportaron las puntuaciones de la segunda ronda de evaluación del programa gubernamental de IA soberana, medidas según el Intelligence Index de Artificial Analysis (AAII v4.1.1): Motif 3 con 47, Solar Open 2 250B con 37, A.X-K2 de SK Telecom con 35 y K-EXAONE 2.0 0803 de LG AI Research con 31. Ese 37 sitúa a Solar Open 2 250B en segundo lugar entre los cuatro finalistas coreanos, diez puntos por detrás de Motif 3. Definámoslo con precisión: esto es lo que ha publicado la prensa — la puntuación no ha aparecido en la propia clasificación de Artificial Analysis, que aún no devuelve nada para este modelo — y la misma cobertura señala que el AAII no incluye pruebas de referencia en coreano, un verdadero punto ciego para un modelo cuyos resultados nacionales son centrales en su propuesta. Pero es la primera lectura de Solar Open 2 250B que no proviene de Upstage, y es coherente con el resto de este artículo: puntuaciones sólidas en agente y entregables, con gran parte del resto aún sin demostrar por nadie ajeno al proveedor.

¿Por qué nadie puede servirlo en software estándar?

La tarjeta del modelo cuenta la historia mejor que cualquier comentario. Las descargas del último mes ya superan las 26.000, junto con 743 me gusta, dieciséis cuantizaciones comunitarias y tres ajustes finos — y, en el cuadro de Inference Providers, la línea "Este modelo no está implementado por ningún Inference Provider" sigue vigente, con una docena de personas ahora listadas pidiendo a la tarjeta soporte de proveedores. Interés real, cero endpoints alojados.

Sigue los despliegues en funcionamiento y todos conducen a un fork. La compilación NVFP4 de Nota AI fija su instalación en git+https://github.com/UpstageAI/vllm.git en la etiqueta v0.22.0-solar-open2 — el vLLM propio de Upstage. El artículo de Backend.AI sobre DGX Spark necesitaba ese fork más un FlashInfer parcheado, porque el FlashInfer oficial no tenía soporte de paralelismo de expertos y no aceptaba el formato compressed-tensors.

El soporte principal es el pull request 51129 contra vllm-project/vllm, abierto el 5 de agosto por un colaborador conocido como oesni. Sigue abierto: el 10 de agosto mergify marcó conflictos de fusión, por lo que el PR ahora lleva la etiqueta needs-rebase y aún espera revisión. Lo que ese PR tuvo que construir es la descripción más honesta de la dificultad de este modelo que existe públicamente:

• Una capa KimiGatedDeltaAttention específica de Solar en un nuevo solar_open2.py, que lleva el beta 2·sigmoid(b) del cambio de autovalor negativo.

La operación vllm::solar_open2_kda_attention se registró como una operación de división de grafos CUDA.

• Un calentamiento de prefill KDA en tiempo de perfil, limitado a 2048 tokens, añadido específicamente porque los prefills reales se ejecutaban aproximadamente un 23% más lento sin él.

Analizadores de salida de razonamiento y llamadas a herramientas para modos de streaming y no streaming

• Validación de serving en 8×B200 que reporta 107.02 GiB por rango de caché KV, junto con 463 pruebas unitarias aprobadas.

Esas son las cifras del autor del PR, que nadie más ha reproducido, y el código aún puede cambiar antes de que se fusione. Pero lee esa lista junto a la sección de arquitectura y la forma del problema es obvia: las dos decisiones que hacen que Solar Open 2 250B sea barato de ejecutar en contexto largo — KDA en tres cuartos de las capas, y la ausencia de RoPE — son precisamente las decisiones para las que los stacks de inferencia de propósito general no tienen ninguna ruta de código existente. La apertura de los pesos y la apertura de la ruta para ejecutarlos son cosas diferentes, y solo una de ellas se publicó el 22 de julio.

Lo que cuesta alzar la voz

Comencemos por el mínimo de memoria. Los 500.6 GB de pesos en bfloat16 frente a los 141 GB de una H200 significan que cuatro GPU proporcionan 564 GB, unos 63 GB libres en todo el nodo para la caché KV y las activaciones antes de que llegue una sola solicitud. Por eso la ficha técnica indica cuatro H200 como mínimo y recomienda ocho, y por eso FlexAI lo ofrece como un endpoint dedicado de 8×H100 con precios bajo petición en lugar de una API compartida por token.

La cuantización desplaza ese suelo una gran distancia. La compilación NVFP4 de Nota AI (pesos y activaciones de 4 bits, tamaño de grupo 16, en formato compressed-tensors) reduce el modelo de 500.6 GB a 153.3 GB, y su propia evaluación sitúa el coste de precisión en 0.22 puntos de media en cuatro benchmarks — de 81.57 a 81.35, con Tau2-Bench de 75.20 a 75.08, GPQA-Diamond de 86.26 a 85.45, MMLU-Pro de 86.19 a 86.15, y LiveCodeBench moviéndose en la otra dirección, de 87.03 a 88.55, lo cual es ruido de cuantización, no una mejora. El inconveniente es el hardware: NVFP4 necesita los núcleos tensoriales FP4 introducidos con Blackwell, así que solo B200 o GB200, nada en Hopper. Si estás en H100, la variante que quieres es su compilación INT4 con poda global — 117.8 GB después de la poda, con un tamaño que permite alojar dos de ellos.

Ahora, la aritmética que lo decide. DeepSeek V4 Flash —una vez más, el modelo contra el que Upstage eligió medirse— cobra $0,15 por millón de tokens de entrada y $0,29 por millón de tokens de salida en OrcaRouter, que es el precio de lista de DeepSeek trasladado directamente con un margen del 0%. Con una mezcla 3:1 de entrada a salida, el costo combinado es de aproximadamente $0,185 por millón. Si ponemos un costo ilustrativo de $2 por hora de GPU en un nodo de ocho GPU, la cifra es de unos $11.700 al mes antes de que nadie envíe una solicitud, lo que equivale a unos 63 mil millones de tokens combinados de tráfico de API, o 2,1 mil millones de tokens al día, todos los días, solo para alcanzar el punto de equilibrio. Si reduces a un nodo de dos GPU, el punto de equilibrio cae a unos 16 mil millones de tokens al mes. Sustituye tu propia tarifa de GPU; la forma no cambia. Autoalojar un modelo de 250B es una decisión de utilización y control, no un descuento.

Para ser exactos sobre qué hay y qué no hay disponible: Solar Open 2 250B no está en OrcaRouter y, según su propia ficha de modelo, tampoco está en ningún proveedor de inferencia. Lo que sí está en OrcaRouter es la competencia contra la que se mide: DeepSeek V4 Flash, Qwen3.8-Max y un par de cientos más con una sola clave al precio de lista del proveedor, con conmutación por error entre proveedores si uno se cae. Esto importa aquí por una razón concreta y práctica: si la pregunta que en realidad quieres responder es «¿supera un modelo ajustado para agentes a lo que ya tenemos en producción?», puedes ejecutar esa mitad de la comparación cambiando una cadena de modelo esta misma tarde, mientras la cotización de GPU para la otra mitad sigue en proceso de adquisición.

Dos cadenas en la licencia.

La Licencia Solar de Upstage permite uso comercial, ajuste fino y destilación, y Upstage la describe como basada en Apache-2.0 con términos de marca añadidos. Las dos obligaciones añadidas son las que hay que leer con atención: un modelo derivado debe llevar el prefijo "Solar" en su nombre, y debe mostrar la atribución "Built with Solar".

Para el despliegue interno, eso no es un problema. Si planeas destilar esto en algo que distribuyas bajo tu propia marca de producto, la cláusula de nombres es una decisión de marca disfrazada de término de licencia, y vale la pena veinte minutos de un abogado antes de comenzar una ejecución de entrenamiento. Lee la cláusula en el repositorio en lugar de confiar en la cobertura de la misma: la información sobre esta licencia ha sido imprecisa, incluido al menos un artículo que la describe directamente como Apache 2.0.

Quién debería moverse ahora, y quién debería esperar.

Muévete si la calidad de los entregables en coreano o japonés es tu producto y puedes poner los pesos en hardware que ya posees — esa combinación es exactamente para lo que sirve "pesos abiertos, sin endpoint", y el propio planteamiento de Upstage es explícito en que la soberanía significa poder desplegar y verificar un modelo uno mismo, no solo que fue entrenado en el país. Muévete si tienes GPUs ociosas y una carga de trabajo de agente con suficiente volumen para llenarlas, porque con una utilización real las matemáticas por token se invierten. Muévete si los requisitos de auditoría o de residencia de datos significan que una API nunca estuvo sobre la mesa.

Espera, si quieres un endpoint por token. Upstage ha dicho que tiene la intención de listar Solar Open 2 250B en una plataforma de terceros; al momento de escribir esto, eso no ha ocurrido: la prueba de Playground solo duró hasta el 31 de julio, y la tarjeta del modelo todavía no muestra ningún proveedor. Espera, si estás en Hopper y contabas con la versión de 4 bits, ya que la versión NVFP4 necesita Blackwell. Y espera antes de diseñar cualquier cosa en torno al número de contexto de 1M, que actualmente es una propiedad de la arquitectura más que un resultado medido.

Lo que hay que vigilar es la pull request 51129, que el 10 de agosto recibió la etiqueta needs-rebase después de que Mergify señalara conflictos de fusión. El día en que Solar Open 2 250B aparezca en una versión etiquetada de vLLM será el día en que deje de ser un proyecto de infraestructura y se convierta en un modelo que cualquiera pueda probar sin más. El AAII de 37 reportado por la prensa es un comienzo: una primera lectura externa, aunque provisional, y que todavía no aparece en el propio ranking de Artificial Analysis. La prueba real es la que se ejecuta con software estándar, y aún no tiene fecha.

Comparados en este artículo2

Detectado en este artículo · Benchmarks: Artificial Analysis · actualizado a diario