A.X-K2-DSpark: El modelo borrador de decodificación especulativa de SK Telecom ha llegado sin anunciar

A.X-K2-DSpark es un modelo al que probablemente nunca llamarás directamente — y es precisamente por eso que vale la pena leer sobre él. SK Telecom lo publicó discretamente en Hugging Face, sin publicación de lanzamiento ni comunicado de prensa detrás; la ficha del modelo simplemente comienza diciendo que el checkpoint está «actualmente en validación final y tiene previsto su lanzamiento público en los próximos días». Es un checkpoint de solo borrador para decodificación especulativa, construido para un único trabajo: hacer que el buque insignia A.X K2 de SK Telecom, de 688 mil millones de parámetros, sea más rápido y más barato de servir, proponiendo tokens que A.X K2 luego verifica. Esto es lo que el repositorio nos dice realmente, lo que aún no está confirmado y por qué un pequeño modelo auxiliar como este es donde se esconden los próximos recortes de costos de servicio de LLM.

Qué es realmente A.X-K2-DSpark

A.X-K2-DSpark no es un modelo independiente en ningún sentido significativo. La tarjeta del modelo lo indica en sus notas de uso previsto: es un "checkpoint solo para redactor" sin "uso independiente", que vLLM carga junto con su modelo objetivo, A.X K2, dentro de un bucle de decodificación especulativa. Es la etapa de borrador de un generador de dos etapas: un modelo pequeño propone tokens candidatos rápidamente, y el modelo objetivo los verifica antes de que cualquier token se comprometa a la salida.

El objetivo, para contexto, es uno de los modelos de pesos abiertos más grandes que existen. A.X K2 es el modelo Mixture-of-Experts de SK Telecom con 688B en total y 33B activos, publicado en Hugging Face a finales de julio de 2026 bajo la licencia Apache 2.0, construido sobre una arquitectura base que combina Multi-head Latent Attention con DeepSeek Sparse Attention y añade la modificación de contexto largo Sparse Gate Attention de SK Telecom. A.X-K2-DSpark se condiciona a los estados ocultos de A.X K2 y añade un modelado ligero de dependencias locales entre posiciones candidatas, por lo que puede proponer varios tokens en paralelo en lugar de redactar estrictamente de forma autorregresiva. Cada candidato es luego verificado por A.X K2 antes de ser confirmado — por eso la ficha denomina el resultado "lossless by construction": la distribución de salida no cambia por el redactor; solo cambia la velocidad de servicio.

Cómo funciona la decodificación especulativa y por qué un MoE de 688B la necesita.

La decodificación especulativa existe porque la generación autoregresiva es serial y está limitada por la memoria. Generar cada token implica leer los pesos del modelo desde la memoria, y para un modelo de 688B eso supone mover una cantidad enorme de bytes por cada token individual, incluso cuando solo 33B parámetros están activos en cada pasada hacia adelante. El truco es gastar un poco de cómputo adicional en un pequeño modelo borrador que adivine los próximos varios tokens de una sola vez, y luego hacer que el modelo grande verifique todas las adivinanzas en una única pasada hacia adelante y conserve el prefijo más largo que coincida con su propia distribución. Cuando el borrador es bueno, se obtienen dos o tres tokens por pasada del modelo grande en lugar de uno, sin cambiar la salida final.

Todo se reduce a la tasa de aceptación. Un modelo borrador que adivina mal ve rechazadas sus propuestas, y la pasada de verificación sigue costando el mismo ancho de banda de memoria, así que la aceleración se evapora. Por eso los modelos borradores se han convertido en un serio tema de investigación por derecho propio: para un modelo del tamaño de A.X K2, la diferencia entre una aceleración de 1.5x y una de 3x es la diferencia entre una flota de servicio de diez GPUs y una de cinco. Capas de eficiencia como esta son de donde saldrá la próxima ronda de recortes de precios en las API de LLM hospedadas — no de las cifras de calidad del modelo base, sino de la pila de servicio que las envuelve.

DSpark es el método — y viene del equipo DeepSeek

El "DSpark" en el nombre del modelo es una técnica específica, y no es una invención de SK Telecom. La ficha del modelo cita el artículo "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation" (arXiv 2607.05147), un preprint del 6 de julio de 2026 de un equipo de 33 autores de DeepSeek que desplegó el método en el sistema de servicio de la era V4 de los propios autores bajo tráfico real. SK Telecom ha adaptado la misma técnica a su propio modelo objetivo.

Las dos contribuciones del artículo se corresponden directamente con lo que describe la tarjeta A.X-K2-DSpark. Primero, el borrado semiautoregresivo: un backbone paralelo propone tokens a lo largo de una ventana, mientras que un módulo secuencial ligero modela las dependencias entre las posiciones candidatas, corrigiendo el problema clásico de que las tasas de aceptación de los borradores paralelos disminuyen bruscamente a lo largo de la secuencia propuesta. Segundo, la verificación programada por confianza: en lugar de verificar siempre un número fijo de tokens de borrador, el sistema estima la probabilidad de que cada prefijo sobreviva y establece la longitud de verificación por solicitud, ajustada al perfil de rendimiento del motor — de modo que el esfuerzo de verificación depende de la carga en lugar de ser uniforme.

Según las cifras del propio artículo —que son mediciones de los autores, no verificadas de forma independiente—, DSpark logró una generación por usuario entre un 60 % y un 85 % más rápida que la línea base de producción MTP-1 con el mismo rendimiento, y evitó una severa degradación del rendimiento bajo estrictas restricciones de interactividad. Dos advertencias son importantes para interpretar este comunicado. Esos resultados se midieron en la propia pila y plataforma objetivo de los autores, no en A.X K2; y la ficha del modelo A.X-K2-DSpark dice explícitamente que su propia evaluación todavía está en curso. El artículo demuestra que el método funciona en producción. No demuestra que el checkpoint de SK Telecom reproduzca esas mejoras —esa es precisamente la parte no confirmada.

Lo que dice el repo — y lo que no dice

Esto es lo que se puede saber del repositorio en este momento, todo ello de la tarjeta del modelo:

• Función — checkpoint solo de borrador para A.X K2; sin uso independiente; no validado con ningún otro objetivo e "incompatible con modelos no relacionados".

• Target — A.X K2, 688B en total / 33B activos, mezcla de expertos.

• Longitud de contexto — 262,144 tokens (256K), que coincide con la configuración nativa de A.X K2.

• Licencia — Apache 2.0.

• Mecanismo — Generación de borradores semiautoregresiva de DSpark; cada candidato verificado por A.X K2 antes de la confirmación (sin pérdidas).

• Estado — "actualmente en validación final"; lanzamiento previsto "para los próximos días".

Y aquí está lo que explícitamente aún no está confirmado:

• Precisión y tamaño del checkpoint — ambos indicados como TBD en la tarjeta del modelo.

• Rendimiento, TPOT y longitud media aceptada — los tres números que te dirían si el redactor realmente funciona, todos por determinar, con «la evaluación está actualmente en curso».

• Resultados por dominio — la tarjeta promete desgloses de coreano, matemáticas, ciencias y código "más adelante", sin fecha.

• Un anuncio formal — SK Telecom no ha anunciado A.X-K2-DSpark en ningún lugar que podamos encontrar; el repositorio es el anuncio.

• Puntuaciones independientes — no existen. Todo lo que aparece en la tarjeta es una afirmación de la propia SK Telecom, y la mayor parte sigue siendo una promesa.

El número no confirmado más importante es la longitud media aceptada: la cantidad promedio de tokens de borrador que A.X K2 acepta por pasada de verificación. Ese único número decide si este redactor es una mejora menor de 1.2x o una actualización de servicio de 2.5x, y también es el número con más probabilidades de circular sin procedencia una vez que el lanzamiento esté disponible. Trátalo con escepticismo cuando aparezca: la cifra del 60–85 % del artículo de DSpark se midió en la pila de servicio de un modelo diferente, y A.X K2 tiene sus propias características de aceptación de borradores.

Cómo lo ejecutarías realmente

Ejecutar el drafter implica servir A.X K2 desde el fork de vLLM de SK Telecom. El ejemplo de la ficha del modelo, ligeramente recortado, es:

vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'

con el fork instalado desde el repositorio vLLM de SKT-AI en la rama axk2-v0.23.0. La tarjeta es transparente sobre algunas advertencias: la configuración apunta a la configuración nativa de contexto de 256K del A.X K2, y la aceleración depende de la carga de trabajo — la concurrencia, la longitud de salida, la tasa de aceptación y el costo relativo de generar borradores frente a la verificación influyen en el resultado. En otras palabras, esto es infraestructura de servidor, no un script de descargar y ejecutar. Necesitas los pesos del A.X K2, un clúster lo suficientemente grande para tensor-parallel 8 y la paciencia para ajustar num_speculative_tokens según tu propio tráfico. Eso es un proyecto significativo para un equipo que ya sirve A.X K2; no es una razón para poner uno en marcha.

La economía: las capas de eficiencia superan las afirmaciones de calidad

La razón por la que vale la pena seguirle la pista a un modelo borrador para un modelo de 688B es que la carrera de benchmarks del modelo base se ha saturado en su mayoría, mientras que la carrera por el costo de inferencia no. El propio lanzamiento de SK Telecom ya se apoyaba en la eficiencia — se afirmaba que el cambio de Sparse Gate Attention aumentaba el throughput total de tokens en un 67,7% frente a la generación anterior con entradas de 120K tokens — y un borrador aplica la misma tesis a la decodificación. Cada token borrador aceptado es una pasada hacia adelante del modelo grande por la que no pagaste.

{{1}}Para cualquiera que consuma estos modelos a través de una API en lugar de alojarlos, el drafter es invisible — y ese es el punto.{{/1}} {{2}}Cuando un proveedor añade decodificación especulativa a su stack de servicio, no ves un modelo nuevo; ves el mismo modelo volverse más rápido y más barato por token.{{/2}} {{3}}La capa de precios importa por la misma razón: en OrcaRouter transmitimos el precio de lista del proveedor tal cual, con un margen del 0%, así que cuando el trabajo de eficiencia de servicio de un proveedor se traduce en una bajada de precio, esa bajada está activa en nuestro lado el mismo día — sin renegociación, sin cambio de contrato.{{/3}} {{4}}Y para un modelo no probado que puede o no dar resultado, el enrutamiento con failover automático es la forma de probarlo sin apostar una ruta de producción en él: una sola clave de API, y la solicitud se redirige a otro proveedor si el primero se degrada.{{/4}}

Una nota de honestidad específica de esta versión: A.X-K2-DSpark es un checkpoint solo para drafters, por lo que no es algo que ninguna API de modelo alojado pueda enrutar, incluida la nuestra. Los drafters son un componente del lado del servidor, no un producto invocable. Cuando el drafter se lance y lleguen los números de evaluación, lo que aparecerá en la lista de precios es un A.X K2 más rápido y más barato, no un nuevo endpoint llamado "DSpark".

Unas cuantas preguntas que vale la pena responder.

¿Puedo usar A.X-K2-DSpark por sí solo? No — ese es el hecho definitorio de la versión. Es un checkpoint de solo drafter, sin uso independiente ni API pública; existe únicamente como auxiliar dentro de un bucle de decodificación especulativa de vLLM que sirve a A.X K2, y la ficha indica que no ha sido validado con ningún otro objetivo.

¿Es A.X-K2-DSpark un competidor de A.X K2? Todo lo contrario. Es un acelerador para A.X K2: el mismo modelo se vuelve más rápido, con la distribución de salida sin cambios. Piénselo como una pieza de eficiencia adicional, no como una nueva incorporación a la línea.

¿Cuándo se publicará realmente? La tarjeta del modelo dice que está en validación final y que su lanzamiento público está previsto "para los próximos días". Eso es todo lo que se ha confirmado. La fecha clave es el día en que se completen las cifras TBD —rendimiento, TPOT y longitud media aceptada—, porque es entonces cuando el lanzamiento deja de ser una promesa y se convierte en algo que se puede evaluar.

¿Tengo que tenerlo en cuenta si uso A.X K2 a través de una API? Probablemente no directamente. El stack de servicio detrás de una API decide si un modelo borrador está en el bucle; ves el resultado como un precio y una latencia, no como un indicador. Importa sobre todo a los equipos que autoalojan A.X K2, donde activarlo es un cambio de configuración de vLLM que ellos controlan.

{{1}}La historia aquí no es el borrador en sí — es lo que el borrador señala.{{/1}} {{2}}El trabajo de eficiencia está convirtiéndose silenciosamente en una categoría de lanzamiento propia,{{/2}} {{3}}y los modelos nuevos más interesantes de este año son cada vez más ayudantes que abaratan los modelos grandes, no modelos más grandes.{{/3}} {{4}}A.X-K2-DSpark es el ejemplo más claro hasta ahora:{{/4}} {{5}}un checkpoint sin uso independiente,{{/5}} {{6}}publicado antes del anuncio,{{/6}} {{7}}que carga con la mayor parte de su propia evidencia como TBD.{{/7}} {{8}}Vigila el número de longitud aceptada cuando llegue,{{/8}} {{9}}trata las ganancias del paper de DSpark como procedencia del método, no como una promesa para este checkpoint,{{/9}} {{10}}y si sirves A.X K2 por tu cuenta,{{/10}} {{11}}presupuesta para el benchmark{{/11}} — {{12}}esa es la única manera de saber si el borrador publicado silenciosamente es una mejora de 1.2x o lo auténtico.{{/12}}