DSpark: la apuesta de DeepSeek por la velocidad que no traiciona la calidad

DeepSeek no ha presentado solo un nuevo enfoque para el speculative decoding; con DeepSpec está intentando transformarlo en una pipeline industrial reproducible. El paper se llama DSpark, las siglas son las enésimas de una larga serie que el laboratorio chino saca con frecuencia casi trimestral, y la tentación de leerlas distraídamente es fuerte. Sería un error, porque detrás del acrónimo se esconde una pregunta muy concreta: cuánto puede acelerar realmente la inferencia de un modelo de lenguaje si el modelo que genera los borradores de respuesta deja de ser ingenuo, y si el sistema que los controla aprende a no perder tiempo en los destinados a la papelera.

Para entender por qué la pregunta es relevante, conviene partir de un hecho incómodo que cualquiera que haya usado un chatbot ha experimentado sin saberlo. Cada palabra que un modelo de lenguaje produce nace de un paso completo de cálculo a través de miles de millones de parámetros, uno a uno, en secuencia. Es un poco como si un novelista tuviera que volver a leer todo el manuscrito desde el principio antes de escribir cada palabra siguiente. Funciona, pero es lento, y en un sistema que debe responder a cientos de peticiones simultáneamente esa lentitud se traduce en colas, costes eléctricos y usuarios mirando un cursor parpadeante.

El cuello de botella de la inferencia

El speculative decoding es la idea, ya no tan nueva, que ha intentado romper este esquema: en lugar de hacer trabajar solo al modelo grande y costoso, se le añade un modelo pequeño y rápido, llamado draft model, que arriesga una secuencia de tokens futuros. El modelo grande, al que llamaremos target, los comprueba todos juntos en un solo paso, aceptando el prefijo más largo compatible con lo que él mismo habría generado y descartando el resto. Si el draft acierta bien, el target cobra más palabras por cada paso de cálculo, y la generación se acelera sin perder ni un gramo de calidad, porque la regla de aceptación está construida para no alterar la distribución estadística del modelo grande.

El problema es que el diseño del draft model determina un compromiso incómodo. Los primeros drafts eran autorregresivos, es decir, generaban un token cada vez condicionando cada uno a los anteriores: buenos para mantener la coherencia interna, pero con un coste de generación que crece linealmente al aumentar el bloque de palabras propuestas, lo que los obliga a seguir siendo pequeños y a proponer bloques cortos. Las arquitecturas paralelas, como trabajos tipo DFlash, han resuelto el problema opuesto: producen todas las palabras del bloque en un solo paso, haciendo que el tiempo de generación sea casi independiente de la longitud del bloque, y esto permite arriesgar bloques mucho más largos. Pero la paralelización tiene un precio, porque cada posición se predice aislada de las demás, sin saber qué han "decidido" las posiciones vecinas.

Es la misma paradoja del cadáver exquisito surrealista, el juego querido por André Breton en el que varias personas escriben una frase por turnos viendo solo la última palabra dejada por el compañero anterior: el resultado puede ser sorprendente, pero a menudo colapsa en un conjunto de fragmentos con sentido individualmente e incoherentes juntos. Cuando un draft paralelo tiene que elegir entre "claro" y "ningún problema" como respuesta a un saludo, puede producir tranquilamente una mezcla ilegible de las dos, porque ninguna de las dos elecciones conoce la existencia de la otra. Los autores del paper llaman a este fenómeno colisión multimodal, y es la razón por la que los drafts paralelos, aunque empiecen fuerte, pierden fuelle rápidamente a medida que el bloque se alarga.

El segundo cuello de botella, menos contado pero igual de concreto, se refiere a la verificación. Incluso suponiendo que el draft produzca un bloque larguísimo de palabras plausibles, controlarlas todas cuesta cálculo del modelo target, y ese cálculo es el recurso más escaso en un sistema de producción con cientos de peticiones en cola. Verificar un token que tiene una probabilidad altísima de ser rechazado es como enviar a un candidato claramente no apto a una entrevista que podría asignarse a alguien con más posibilidades: no es gratis, resta capacidad a quien obtendría un beneficio real. El paper señala, con datos en la mano, que la aceptación varía muchísimo según el dominio: un problema de matemáticas o un fragmento de código tienen estructuras rígidas que el draft adivina mejor, una charla abierta es mucho más impredecible. Una longitud de verificación fija, igual para cada petición, ignora esta diferencia y desperdicia sistemáticamente recursos.

Un drafter que aprende a dudar de sí mismo

El primer movimiento de DSpark es arquitectónico, y el nombre dado al enfoque, generación semi-autorregresiva, describe bien la idea de mediación. El grueso del trabajo de borrador sigue siendo paralelo: un núcleo duro, lo que el paper llama backbone, produce en un solo paso las previsiones base para todas las posiciones del bloque, manteniendo la ventaja de velocidad de los drafts paralelos. Sobre este núcleo, sin embargo, se inserta un módulo secuencial ligerísimo, cuya única tarea es corregir las previsiones base introduciendo dependencia entre un token y el siguiente, sin repetir desde cero el trabajo pesado.

La imagen que mejor transmite la idea llega del jazz más libre, el que circulaba en la órbita de Sun Ra: toda una sección rítmica puede tocar simultáneamente leyendo la misma partitura base, pero es el solista quien, escuchando en tiempo real lo que acaban de tocar los demás, ajusta la frase siguiente para que suene coherente con el resto. El backbone paralelo es la partitura común, el módulo secuencial es el oído del solista. En el paper, este módulo existe en dos variantes: una versión mínima, que mira solo a la palabra inmediatamente anterior y usa una pequeña tabla de bajo rango para sugerir qué palabras son coherentes con ella, y una versión más rica, con memoria recurrente, que acumula información sobre todo el prefijo generado hasta ese momento en el bloque. La primera es más económica, la segunda captura dependencias más largas, y los dos diseños ofrecen un compromiso diferente entre coste de cálculo y calidad.

El resultado más contraintuitivo del paper se refiere precisamente a la comparación entre esta arquitectura y los drafts puramente autorregresivos como Eagle3. Uno esperaría que generar palabra por palabra, con plena dependencia secuencial, produzca siempre mejores resultados que un enfoque en parte paralelo. Los autores muestran que no es así, analizando la aceptación posición por posición: en la mismísima primera palabra del bloque, un draft paralelo puede permitirse una arquitectura mucho más profunda precisamente porque su coste no depende de la longitud del bloque, y esta ventaja de capacidad inicial se traduce en un margen neto, por ejemplo casi veinte puntos porcentuales más de aceptación en tareas de conversación abierta respecto a un drafter autorregresivo obligado a seguir siendo ligero. Como la primera palabra del bloque es la que tiene más palanca, un rechazo suyo invalida todo lo demás, esta ventaja inicial repercute en toda la cadena. El precio se paga más adelante en el bloque, donde el draft puramente paralelo pierde fuelle rápidamente mientras el autorregresivo mantiene mejor el rumbo. DSpark está pensado exactamente para sumar las dos ventajas, la potencia inicial del paralelo y la resistencia de cola del secuencial, sin heredar sus respectivas debilidades. Imagen tomada del paper

Verificar solo lo que importa

La segunda mitad de la propuesta es quizás la más original, y se refiere no al modo en que se genera el draft sino al modo en que se verifica. DSpark añade al backbone de generación una cabeza de confianza, un pequeño módulo que para cada posición del bloque estima la probabilidad de que ese token sobreviva al control del modelo target, condicionada al hecho de que todas las palabras anteriores en el mismo bloque hayan sido aceptadas. Es una estimación de riesgo, calculada incluso antes de que el target abra la boca.

Aquí, sin embargo, surge un problema típico de cualquier sistema que confía en estimaciones de confianza producidas por una red neuronal: tienden a estar demasiado seguras de sí mismas, un fenómeno bien documentado en la literatura sobre la calibración de modelos. Si el programador confiara ciegamente en las puntuaciones en bruto, acabaría sobreestimando sistemáticamente cuántas palabras sobrevivirán, descuadrando los cálculos. DSpark introduce por tanto una fase de calibración a posteriori, llamada escalado de temperatura secuencial, que corrige estas puntuaciones una a una procediendo de izquierda a derecha en el bloque, usando un pequeño conjunto de validación para encontrar el factor de corrección adecuado sin alterar el orden de mérito entre los tokens, solo su magnitud absoluta.

Con puntuaciones fiables en la mano, entra en juego el programador propiamente dicho, al que el paper bautiza como Hardware-Aware Prefix Scheduler. La idea es elegante en su sencillez: recoger todas las peticiones activas en un instante dado, ordenar todas las posibles prolongaciones de verificación de todas las peticiones según la probabilidad de supervivencia estimada, y admitirlas una a una en orden decreciente mientras el aumento del throughput global siga creciendo. En el momento en que añadir otro token empeora el throughput esperado, se detiene. Es un mecanismo que recuerda de cerca la lógica de los juegos de mesa de colocación de trabajadores, aquellos en los que cada turno se elige con cuidado dónde invertir un recurso escaso y la decisión, una vez tomada, no se puede deshacer: aquí el recurso escaso es la capacidad de cálculo del modelo target, y cada token verificado de más en una petición es una parte de esa capacidad restada a otra.

Hay un vínculo teórico delicado que los autores abordan con un cuidado casi maníaco en el apéndice: la decisión de cuántos tokens verificar no puede depender del contenido del token mismo, de lo contrario se introduce un sesgo de selección que rompe la garantía fundamental del speculative decoding, es decir, que el resultado final sea estadísticamente idéntico al que habría producido el modelo target solo. Los autores demuestran con un contraejemplo numérico que una búsqueda completamente retrospectiva, que evalúa cada posible corte del bloque antes de decidir, viola esta propiedad de causalidad y distorsiona silenciosamente la distribución de salida. La solución adoptada en el programador teórico es detenerse en cuanto el beneficio esperado empieza a caer, una especie de parada temprana que impide "espiar" información que no debería estar disponible todavía.

En producción, sin embargo, la teoría choca con el hardware real. La curva de capacidad de un motor de inferencia no es una curva suave como en los modelos matemáticos, está llena de escalones bruscos dictados por vínculos físicos de las GPU, y pretender recalcular la programación en cada paso de modo síncrono ralentizaría toda la pipeline. DeepSeek ha resuelto el conflicto haciendo el programador asíncrono: la capacidad de referencia se estima usando las previsiones de confianza de dos pasos anteriores, no las instantáneas, lo que introduce un leve retraso pero preserva la propiedad de causalidad requerida, porque la decisión nunca depende de la realización del token actual. Es un compromiso de ingeniería pragmático más que elegante, pero es exactamente el tipo de detalle que separa un paper académico de un sistema que realmente funciona con millones de peticiones al día.

Los números, puestos a prueba

En el frente de los benchmarks offline, DSpark se compara con Eagle3, representante de la escuela autorregresiva, y con DFlash, representante de la escuela paralela, sobre cuatro modelos target de diferente tamaño: la familia Qwen3 en las versiones de 4, 8 y 14 mil millones de parámetros, más Gemma4 de 12 mil millones. En los cuatro, midiendo cuántas palabras se aceptan de media en cada ciclo de verificación, DSpark supera sistemáticamente a ambos competidores. El margen respecto a Eagle3 oscila entre el 27% y el 31% según el tamaño del modelo, el respecto a DFlash se mantiene más contenido pero igualmente robusto, entre el 16% y el 18%. La ventaja se confirma transversalmente en matemáticas, generación de código y conversación, aunque con intensidades diferentes: como era de esperar, las tareas más estructuradas como el código toleran bloques de verificación más largos, las conversacionales mucho menos.

La prueba más interesante, sin embargo, no es la offline, sino la puesta en producción dentro del motor de servicio de DeepSeek-V4, tanto en la variante Flash como en la Pro, en comparación con el anterior estándar productivo interno llamado MTP-1, un drafter de un solo token que se había mantenido en uso precisamente porque variantes más agresivas de varios tokens fijos degradaban el throughput agregado bajo carga elevada. Aquí DeepSeek introduce el concepto de frontera de Pareto del servicio: el compromiso observable entre cuánta capacidad agregada logra servir el sistema y con qué rapidez ve cada usuario individual fluir su respuesta. A igual nivel de servicio, es decir, fijando un umbral mínimo de velocidad percibida por el usuario, DSpark aporta un incremento de velocidad por usuario que va del 60% al 85% en Flash y del 57% al 78% en Pro. Bajo vínculos de interactividad muy estrictos, aquellos en los que el viejo sistema de un solo token colapsaba casi por completo para mantenerse en tiempo, las ganancias relativas se convierten en números enormes, superiores al 600% en un caso: los mismos autores, con una honestidad que vale la pena subrayar, advierten de no leer estos picos como multiplicadores realistas, sino como prueba de que DSpark logra mantener un servicio digno justo donde antes el sistema dejaba prácticamente de funcionar.

El mecanismo que produce este resultado es visible en los datos de telemetría en vivo: bajo carga moderada el programador alarga el presupuesto de verificación por petición, pasando de los dos tokens fijos de MTP-1 a un intervalo dinámico entre cuatro y seis, mientras que cuando el número de peticiones concurrentes sube y la capacidad del target se satura, el presupuesto se reduce automáticamente, protegiendo la capacidad de cálculo residual en lugar de desperdiciarla en tokens con baja probabilidad de supervivencia. Es exactamente el comportamiento load-aware que la teoría prometía, observado en tráfico real y no en simulaciones.

Hay que decir, por completitud y sin triunfalismo, que los mismos autores señalan un límite no trivial: incluso cuando el programador evita desperdicios en el lado de la verificación, el coste de generar el bloque inicial de borrador mediante el backbone paralelo sigue siendo fijo y se paga igualmente, incluso para las peticiones más difíciles donde la tasa de aceptación final será baja de todos modos. Es un coste que de momento no se recupera, y el paper lo indica explícitamente como dirección de trabajo futuro, hipnotizando mecanismos de salida temprana sensibles a la dificultad de la petición. Imagen tomada del paper

Abrir los cajones: DeepSpec y sus costes ocultos

DeepSeek no se ha limitado a publicar un paper, también ha abierto el repositorio DeepSpec, una codebase completa para entrenar y evaluar draft models de este tipo, con DSpark y las implementaciones de referencia de DFlash y Eagle3 usadas para las comparaciones dentro. Junto al código se han liberado también los checkpoints listos para usar para las versiones preview de DeepSeek-V4-Pro con DSpark en Hugging Face, un detalle que cuenta mucho para quien quiera experimentar sin tener que volver a entrenar todo desde cero.

La estructura del repositorio sigue un flujo lineal y legible: primero la preparación de los datos, que incluye la descarga de los prompts, la regeneración de las respuestas mediante el modelo target y la construcción de lo que se llama target cache, luego la fase de entrenamiento propiamente dicha lanzada con un script que distribuye el trabajo en todas las GPU visibles, finalmente la evaluación en una suite de benchmarks que incluye, entre otros, GSM8K, MATH500, HumanEval y Arena-Hard-v2. Es un flujo pensado para quien ya tiene familiaridad con el entrenamiento distribuido, no para quien quiera probar DSpark en un solo portátil, y la propia documentación presupone un nodo con ocho GPU como configuración por defecto.

Hay un aviso, enterrado en la documentación de la fase de preparación de datos, que merece más atención de la que recibe habitualmente: construir la target cache para la configuración predeterminada basada en Qwen3-4B puede ocupar unos 38 terabytes de almacenamiento. No es un error de escritura, es la consecuencia directa del hecho de que el entrenamiento requiere guardar los estados ocultos del modelo target para un número enorme de posiciones, para evitar tener que volver a ejecutar el modelo grande en cada época de entrenamiento del draft. Para quien lea esta pieza pensando en replicar el experimento en hardware casero o incluso en un pequeño cluster empresarial, este único detalle redimensiona mucho la accesibilidad práctica del proyecto: el código es abierto, pero el coste infraestructural para usarlo a fondo sigue siendo el de un laboratorio con recursos importantes.

En el frente de la licencia, DeepSpec se libera con licencia MIT, la más permisiva entre las comunes en el open source, que permite la reutilización comercial, modificación y redistribución con poquísimas condiciones. El archivo NOTICE del repositorio, sin embargo, recuerda que no todo el código es cosecha propia de DeepSeek: partes consistentes de la implementación, en particular la de Eagle3, están adaptadas del framework SpecForge distribuido con licencia Apache 2.0, mientras que el diseño y la receta de entrenamiento de DFlash derivan de un repositorio de terceros también bajo licencia MIT. Es una práctica de atribución correcta y transparente, cada vez más rara de ver documentada con este cuidado en un panorama, el de los lanzamientos open source de los grandes laboratorios, en el que a menudo se limitan a citar los papers académicos sin rastrear con precisión la procedencia del código.

Quién gana, quién espera todavía

Mirando el conjunto del trabajo, los beneficiarios más inmediatos son los operadores de infraestructuras de servicio que gestionan tráfico de alta concurrencia: si los números de producción declarados se mantienen también fuera de los laboratorios DeepSeek, la posibilidad de ofrecer niveles de interactividad antes inalcanzables sin tener que duplicar la flota de GPU es un argumento económico difícil de ignorar, y no sorprendería ver ideas similares aparecer rápidamente en los motores de inferencia open source más difundidos, de SGLang a vLLM. Se benefician indirectamente también los usuarios finales de aplicaciones conversacionales y agénticas, para quienes la latencia percibida cuenta tanto como la calidad de la respuesta.

Quien se queda más atrás, al menos a corto plazo, es la parte de la comunidad que querría experimentar con autonomía partiendo de cero: entre los requisitos de hardware para el entrenamiento y el espacio de almacenamiento necesario para la caché del target, DeepSpec habla sobre todo un lenguaje de laboratorio industrial, no de aficionado con una sola tarjeta gráfica. Quedan además algunas preguntas abiertas que el propio paper no cierra del todo: cuán robusto es el programador asíncrono cuando el tráfico real es aún más irregular que el observado en las pruebas de DeepSeek, y si el coste fijo del backbone paralelo, el que los propios autores indican como límite, se convierte en un problema serio precisamente en los casos de uso más exigentes, los agénticos con bajísima tolerancia a la latencia, donde cada milisegundo de generación del borrador inicial pesa proporcionalmente más. Son las preguntas a las que la próxima iteración, casi con certeza en camino antes de que alguien haya terminado de pronunciar bien el acrónimo actual, intentará responder.