K-EXAONE-2.0-750B-A37B-DSpark: El MoE coreano de 750B de LG llega a vLLM

El 9 de agosto de 2026, se abrió una pull request en el repositorio de vLLM para añadir K-EXAONE-2.0-750B-A37B-DSpark — la variante de decodificación especulativa del buque insignia coreano de 750 mil millones de parámetros de LG AI Research. Cuatro días después, el 13 de agosto, una segunda PR, más fundamental, hizo concreta la filtración: vLLM ahora tiene una ruta de configuración genérica DSparkDraftModel, que asigna cualquier checkpoint de Hugging Face que declare architectures=DSparkDraftModel con model_type=qw​en​3 al reconocido Qw​en3DSparkModel, con un plan de pruebas que efectivamente sirve el drafter RadixArk Qw​en​3.8-2.4T-A95B-DSpark mediante el método de especulación dspark. El modelo base K-EXAONE-2.0-750B-A37B se publicó el 31 de julio bajo Apache 2.0, y en su lanzamiento vLLM podía servirlo con el método de borrador MTP pero no con DSpark — el drafter que LG también distribuye y del que afirma que vale una aceleración de decodificación de 3–5×. DSpark en sí es el método de Deep​Seek, el mismo drafter semi-autorregresivo que se ejecuta en Deep​Seek-V4-Pro-DSpark y Deep​Seek-V4-Flash-DSpark, por lo que, en conjunto, estas dos PRs son la señal más clara hasta ahora de que la pila de decodificación especulativa de Deep​Seek se está convirtiendo en el estándar por defecto para pesos abiertos.

Esto es un artículo de «lo que sabemos hasta ahora», no una historia de lanzamiento. Ambas pull requests están abiertas y sin fusionar, el checkpoint de DSpark no tiene un benchmark independiente, y la cifra de aceleración de LG es una afirmación del proveedor. Todo lo siguiente está etiquetado en consecuencia. Lo que es real hoy: los pesos están en Hugging Face, el modelo base se lanzó, el decodificador especulativo DSpark de vLLM ya sirve checkpoints de Deep​Seek y Kim​i, y la ruta de configuración genérica que permitiría cargar un drafter DSpark de terceros — la pieza que esta filtración esperaba — ahora está en una pull request pública, probada pero no lanzada.

La versión corta

• La PR #51558, abierta el 9 de agosto de 2026, añade K-EXAONE-2.0-750B-A37B-DSpark a vLLM; sigue abierta sin aprobaciones todavía.

• PR #52197, abierto el 13 de agosto de 2026, incorpora soporte genérico de configuración de DSparkDraftModel — architectures=DSparkDraftModel con model_type=qw​en​3, normalizado a Qw​en3DSparkModel — y su plan de pruebas ejecuta el drafter de RadixArk Qw​en​3.8-2.4T-A95B-DSpark con el método dspark spec y siete tokens spec. También abierto, también sin fusionar.

• DSpark es el drafter de la familia EAGLE que Deep​Seek publicó como código abierto y que se incluye en Deep​Seek-V4-Pro-DSpark y Deep​Seek-V4-Flash-DSpark; LG es la adopción de mayor perfil por parte de otro laboratorio hasta ahora, y el drafter Qw​en3.8 de RadixArk es un segundo drafter independiente.

La variante DSpark es el MoE de 750B con 78 capas más cinco capas de borrador adicionales; LG afirma que DSpark y MTP ofrecen cada uno aproximadamente una aceleración de decodificación de 3 a 5 veces, dirigido a cargas de trabajo agénticas de largo horizonte.

• En el lanzamiento, vLLM admitía MTP para K-EXAONE 2.0, pero no para DSpark; el PR específico del modelo y la ruta de configuración genérica son la incorporación del soporte para DSpark.

• Ningún proveedor aloja hoy ningún checkpoint de K-EXAONE 2.0, y todos los benchmarks de la ficha son propios de LG.

Qué son (y qué no son) las pull requests

vLLM PR #51558, "[Model] Add K-EXAONE-2.0-750B-A37B-DSpark," fue abierto por lkm2835 — el mismo colaborador detrás del soporte anterior de K-EXAONE en vLLM (#50524 para el modelo base) y en SGLang (#33648). Es un PR de fork etiquetado con la etiqueta de nuevo modelo, se solicitó revisión a los propietarios del código de vLLM, y aún no tiene aprobaciones. La descripción tiene tres líneas: agrega soporte para el checkpoint DSpark "desarrollado por LG AI Research", enlaza la tarjeta del modelo en Hugging Face y el informe técnico de K-EXAONE 2.0 (arXiv 2608.04505), y hace referencia al trabajo anterior en vLLM en #50524.

El PR del 13 de agosto es diferente en su naturaleza. #52197, "Soporte de configuraciones DSpark con architectures=DSparkDraftModel + model_type=qw​en​3," añade una capa de normalización genérica: un checkpoint de borrador de Hugging Face que se declara como DSparkDraftModel en un tipo de modelo qw​en​3 se reasigna a un Qw​en3DSparkModel que el decodificador de especulación existente de vLLM puede cargar. El modelo de referencia en su plan de pruebas es RadixArk/Qw​en​3.8-2.4T-A95B-DSpark — un especulador DSpark para el objetivo Qw​en​3.8-2.4T-A95B de clase máxima — servido con el método de especulación dspark y una ventana de especulación de siete tokens. El mensaje del commit es toda la idea: "architectures=DSparkDraftModel+model_type=qw​en​3." El objetivo del cambio es que un modelo de borrador DSpark de terceros debería poder cargarse mediante configuración en lugar de necesitar código específico por modelo, que es como se integra actualmente cada checkpoint DSpark compatible. Está abierto y sin fusionar, al igual que #51558.

Lee ese estado literalmente. "Se está añadiendo soporte" no es "el soporte está disponible": hasta que una de las dos PR se fusione y se lance en una versión, una compilación estándar de vLLM todavía no cargará la variante DSpark. La propia tarjeta del modelo dice que servir K-EXAONE 2.0 con DSpark no está actualmente soportado en vLLM, que utiliza MTP en su lugar. Estas dos PR son los pasos que cambian esa frase — si y cuando se fusionen.

Por qué DSpark es la verdadera historia aquí

El nombre del modelo hace mucho trabajo pesado. «A37B» significa 37 mil millones de parámetros activos por token. «DSpark» es el drafter de decodificación especulativa que Deep​Seek introdujo este año: un modelo borrador semiautorregresivo de la familia EAGLE que propone un bloque de tokens en una sola pasada y permite que el modelo objetivo los verifique, de modo que la calidad de salida no cambia mientras la generación se vuelve más rápida. Deep​Seek lo publicó en código abierto e incluye el drafter con sus propios checkpoints Deep​Seek-V4-Pro-DSpark y Deep​Seek-V4-Flash-DSpark, con aceleraciones reportadas por la comunidad en el rango de 60–85% para Flash y 57–78% para Pro frente a una línea base MTP de un solo token.

Lo que el nuevo PR deja claro es que el soporte de DSpark en vLLM nunca fue la cuestión abierta. Los propios documentos de vLLM ya enumeran módulos DSpark para los checkpoints de Deep​Seek-V4, Kimi K3 y Gem​ma​4, y el equipo redactó el diseño en una publicación de ingeniería de julio. Sin embargo, cada una de esas integraciones está conectada manualmente: una lista bendecida de checkpoints, no una ruta que cualquiera pueda usar. El checkpoint K-EXAONE simplemente no está en esa lista. El #52197 es el intento de hacer genérica la ruta: un mapeo de configuración (DSparkDraftModel más qw​en​3) en lugar de otra clase de modelo hecha a medida, y un modelo borrador de terceros como caso de prueba de referencia en lugar de un modelo Deep​Seek. Por eso una historia de fuga de un checkpoint borrador es, en realidad, una historia de infraestructura.

K-EXAONE-2.0-750B-A37B-DSpark conserva las 78 capas del modelo base y añade cinco capas de borrador DSpark, y la ficha técnica de LG afirma que tanto DSpark como MTP aceleran la generación en aproximadamente 3–5× — cifras propias, dirigidas a "cargas de trabajo de horizonte largo, como las tareas agénticas," donde la latencia de decodificación es el cuello de botella. De ahí se siguen dos cosas. Primero, la decodificación especulativa se está convirtiendo en una característica de primera clase de los modelos frontera abiertos, y no en un truco de servidor que se añade después. Segundo, es la pila de borrador de Deep​Seek la que se está convirtiendo en la opción por defecto — que es exactamente por lo que un buque insignia soberano respaldado por el gobierno coreano que lo incluya importa más allá de la típica noticia de "nuevo modelo".

El modelo detrás del PR

K-EXAONE-2.0-750B-A37B-DSpark es una variante de K-EXAONE 2.0, la secuela de la línea K-EXAONE de 236B de LG y el modelo fundacional autóctono más grande de Corea del Sur, construido bajo el programa de IA soberana del gobierno. El modelo base — 750B de parámetros totales, 37B activos, Mezcla de Expertos con 256 expertos y 8 activos por token, una ventana de contexto de 262 144 tokens, diez idiomas, Apache 2.0 — se publicó en Hugging Face el 31 de julio de 2026, obtenido mediante upcycling del predecesor de 236B en lugar de entrenado desde cero.

Los propios promedios de benchmarks de LG (24 benchmarks, 70.1 en general) muestran la forma esperada para un modelo soberano coreano: sólidos resultados reportados en recuperación de contexto largo, seguridad societaria coreana y codificación agéntica, junto con cifras que quedan por detrás de Qwen3.5 de Alibaba en razonamiento general (83.5 vs 89.8 en MMLU-Pro, por ejemplo). Nada de ello está verificado de forma independiente todavía. La variante DSpark no altera ninguna de esas puntuaciones — es un artefacto de servicio, una forma más rápida de ejecutar el mismo modelo — que es exactamente por lo que aparece en pull requests de frameworks de inferencia en lugar de en un anuncio.

La realidad de servir un MoE de 750B

Aquí es donde el soporte de DSpark realmente importa. K-EXAONE-2.0-750B-A37B-DSpark es un checkpoint de 751 mil millones de parámetros en BF16/F32, y la guía de LG recomienda un mínimo de dos nodos de ocho GPUs NVIDIA H200 (16 GPUs, tensor-parallel 16). A esa escala, el rendimiento de decodificación lo es todo — tokens por segundo y el costo de un turno agéntico largo — y eso es precisamente lo que ataca el decodificado especulativo. Una aceleración de decodificación de 3–5×, si se mantiene fuera del banco de pruebas de LG, es la diferencia entre que un clúster de H200 sea económico o no. LG también documenta un problema de colapso de generación en GPUs B200 que requiere la solución alternativa --disable-prefill-cuda-graph hasta que se solucione — un recordatorio de que esto es servir en la vanguardia, no algo llave en mano.

Lo que cuesta, y cómo puedes probarlo realmente

Ninguna API sirve K-EXAONE 2.0 hoy en día. La tarjeta de Hugging Face para la variante DSpark todavía dice "este modelo no está desplegado por ningún proveedor de inferencia", y una huella de 16×H200 significa que solo llega a una API alojada cuando alguien con ese hardware decide alojarlo. Ese es el verdadero punto de fricción: la frontera de pesos abiertos es cada vez más un problema de servicio, no un problema de disponibilidad.

Cuando un proveedor lo incorpore, la aceleración de la decodificación especulativa se reflejará en el precio por token, y el coste de cambiar para probarlo debería ser casi cero si tu aplicación ya es agnóstica al modelo. En OrcaRouter — un endpoint compatible con Open​AI para más de 200 modelos, con el precio de lista del proveedor transmitido sin margen (0% de recargo) — un modelo que aterrice en cualquier proveedor upstream se convierte en un cambio de enrutamiento en lugar de una reintegración, y la conmutación automática por error significa que un MoE de 750B completamente nuevo que resulte lento o inestable vuelve a un modelo conocido y fiable sin incidentes. Para ser explícitos: OrcaRouter no aloja hoy K-EXAONE-2.0-750B-A37B-DSpark, y tampoco ninguna otra API que hayamos podido encontrar. El objetivo de la capa de enrutamiento es estar preparada para el día en que uno de ellos lo haga.

Lo que estamos viendo

• Los dos PRs que se fusionan. #51558 (específico del modelo) y #52197 (configuración genérica) están ambos abiertos sin aprobaciones. El merge más el release es lo que convierte el "soporte DSpark" de pull requests en flags que realmente puedes pasar.

• El alcance de la ruta genérica. Si #52197 se fusiona, cualquier DSparkDraftModel tipado como qwen3 en Hugging Face se vuelve cargable mediante configuración — la diferencia entre DSpark siendo una lista de checkpoints bendecidos y DSpark siendo un estándar abierto.

• Un primer puntaje independiente. Cada benchmark en la tarjeta es realizado por LG. El primer punto de datos de Artificial Analysis o arena en un MoE coreano de 750B será el primer número no impreso por el proveedor.

• DSpark más allá de Deep​Seek. LG y RadixArk son ahora dos productizadores independientes del método de borrador de Deep​Seek, y la vía genérica de vLLM es una tercera señal de que la pila se está consolidando.

• Servicio cuantizado. LG distribuye checkpoints FP8 y NVFP4 del modelo base; una variante DSpark cuantizada que quepa en menos GPUs cambiaría la economía más rápido que cualquier benchmark.

Preguntas frecuentes

¿Se ha lanzado K-EXAONE-2.0-750B-A37B-DSpark?

Los pesos están en Hugging Face bajo Apache 2.0, pero esto no es una noticia de lanzamiento: el soporte de vLLM son dos pull requests abiertas y sin fusionar (#51558 y #52197), la cifra de aceleración es propia de LG, y ningún proveedor aloja el modelo. Lo que "confirmado" significa aquí es la ruta de servicio — el soporte genérico de configuración de DSparkDraftModel ahora existe en un PR público con un plan de pruebas ejecutable — no que ninguna versión publicada de vLLM pueda servirlo todavía.

¿Cuál es la diferencia entre K-EXAONE-2.0-750B-A37B y la variante DSpark?

Las 78 capas del modelo base más cinco capas de borrador DSpark para decodificación especulativa — los mismos pesos subyacentes, los mismos benchmarks y un artefacto de servicio más rápido de decodificar, en lugar de un modelo diferente.

¿DSpark es de LG o de Deep​Seek?

DSpark es el método de decodificación especulativa de código abierto de Deep​Seek, también incluido en Deep​Seek-V4-Pro-DSpark y Deep​Seek-V4-Flash-DSpark; LG es el adoptante de mayor perfil hasta ahora, y el Qw​en3.8-2.4T-A95B-DSpark de RadixArk es un segundo redactor independiente construido con el mismo método. La ficha del modelo de LG afirma el mismo rango de aceleración de 3–5×.

¿Puedo ejecutar K-EXAONE-2.0-750B-A37B-DSpark en mi propio hardware hoy?

Solo mediante autoalojamiento: la guía de LG exige un mínimo de dieciséis GPU NVIDIA H200, y las versiones estándar de vLLM, SGLang y Transformers aún necesitan forks sin fusionar o la ruta de configuración genérica pendiente para reconocer la arquitectura. El soporte de DSparkDraftModel en #52197 es lo más parecido a una vía compartida, pero sigue siendo una pull request abierta.

Lo que hace que valga la pena ver esto no son los pull requests en sí, sino lo que señalan. Un buque insignia soberano coreano de 750 mil millones de parámetros, con licencia Apache-2.0, eligió incorporar la pila de decodificación especulativa de Deep​Seek, una empresa independiente de inferencia ha construido un drafter DSpark para un Qw​en​3.8 de clase max, y vLLM está respondiendo con una ruta de configuración genérica en lugar de un parche por modelo. Así es como los modelos abiertos de frontera se vuelven reales — no en el momento en que se publican los pesos, sino en el momento en que se fusionan los drafters.