DeepSeek hace open source DSpark, un nuevo marco para acelerar la inferencia de LLM hasta en un 85%.

A medida que la conversación geopolítica en torno a la IA continúa complicándose tras las acciones del gobierno de EE. UU. para limitar los nuevos modelos de Anthropic y OpenAI, el querido de código abierto chino DeepSeek ha vuelto con otra publicación abierta que podría cambiar nuevamente el desarrollo de IA en todo el mundo. Durante el fin de semana, la empresa lanzó DSpark, un nuevo sistema con licencia MIT diseñado para hacer que los modelos de lenguaje grandes respondan más rápido sin cambiar lo que el modelo subyacente intenta decir. La manera más sencilla de entenderlo es así: la mayoría de los chatbots de IA escriben como alguien que cruza un río, un paso a la vez. Eligen un pequeño fragmento de texto, luego el siguiente, y luego el siguiente. DSpark le da al sistema un explorador que corre unos pasos adelante, adivina el camino probable y permite que el modelo más grande verifique rápidamente qué pasos son seguros. Cuando las adivinanzas son buenas, el modelo se mueve más rápido. Cuando las adivinanzas son débiles, DSpark intenta no perder tiempo verificándolas. DeepSeek publicó el trabajo con un documento técnico, puntos de control de modelo y DeepSpec, una base de código para entrenar y evaluar sistemas de decodificación especulativa. La publicación está disponible a través de las páginas públicas de GitHub y Hugging Face de DeepSeek, ambas bajo la licencia MIT permisiva, amigable y común, lo que hace que la nueva técnica sea ampliamente utilizable por desarrolladores, investigadores y operaciones comerciales que desean estudiar o adaptar el enfoque. El sistema está dirigido a uno de los problemas más costosos en la implementación de IA: servir modelos grandes con la suficiente rapidez para usuarios reales, utilizando el hardware de manera suficientemente eficiente para que la economía funcione. Eso es importante para chatbots de consumo, asistentes de codificación, flujos de trabajo automáticos y sistemas de IA empresarial donde los usuarios esperan respuestas largas que se transmitan rápidamente en lugar de arrastrarse palabra por palabra. DeepSeek está aplicando DSpark a su propio último modelo abierto en la frontera, DeepSeek-V4. Específicamente, DeepSeek utilizó su nuevo marco DSpark en DeepSeek-V4-Flash, su modelo de mezcla de expertos de 284 mil millones de parámetros ya optimizado para velocidad, con 13 mil millones de parámetros activos, y DeepSeek-V4-Pro, su modelo más reflexivo y poderoso de 1.6 billones de parámetros con 49 mil millones de parámetros activos (ambos soportan ventanas de contexto de hasta un millón de tokens). Pero la importancia más amplia es que DSpark no está conceptualmente limitado a DeepSeek-V4. Las propias pruebas de DeepSeek y los puntos de control publicados cubren otras familias de modelos abiertos, incluidos los pesos abiertos Qwen de Alibaba y los pesos abiertos Gemma de Google. Eso significa que los equipos empresariales que ejecutan modelos de pesos abiertos podrían, en principio, entrenar o ajustar módulos de borrador al estilo DSpark para sus propios modelos objetivo. No es un interruptor que cualquier cliente de API pueda activar desde fuera, pero es un método que puede trasladarse a otros modelos cuando el operador controla los pesos y la pila de servicio. Incrementos de velocidad sorprendentes para la generación de tokens durante la inferencia En las pruebas de producción en vivo de DeepSeek, DSpark mejoró el rendimiento agregado en un 51% para DeepSeek-V4-Flash con un objetivo de servicio de 80 tokens por segundo por usuario, y en un 52% para DeepSeek-V4-Pro con un objetivo de 35 tokens por segundo por usuario. Con capacidad de sistema igualada, DeepSeek informa mejoras de velocidad de generación por usuario del 60% al 85% para V4-Flash y del 57% al 78% para V4-Pro sobre su línea base de producción anterior MTP-1. Las diferentes afirmaciones de velocidad miden cosas diferentes. La cifra del 60% al 85% para V4-Flash, y la cifra del 57% al 78% para V4-Pro, describen cuán más rápido reciben los tokens generados los usuarios individuales cuando DeepSeek compara DSpark con MTP-1 en capacidad de sistema práctica igual. Esos son los números más limpios de "velocidad de generación". DeepSeek también informa aumentos mucho mayores de 661% y 406%, pero estos miden el rendimiento agregado bajo objetivos de velocidad muy estrictos: 120 tokens por segundo por usuario para V4-Flash y 50 tokens por segundo por usuario para V4-Pro. En esos objetivos, DeepSeek dice que su línea base MTP-1 más antigua se aproxima a un límite operativo, lo que significa que solo puede mantener un pequeño número de solicitudes concurrentes mientras preserva ese nivel de capacidad de respuesta. DSpark evita más de ese colapso, por lo que la diferencia porcentual en la salida total del sistema se convierte en mucho mayor. En pocas palabras: el número del 85% está más cerca de "cuán más rápida se siente la experiencia para un usuario" en condiciones comparables, mientras que las cifras del 661% y 406% están más cerca de "cuánto tráfico puede llevar todavía la carretera" cuando el antiguo sistema ya está generando cuellos de botella. Por qué importa la decodificación especulativa Los LLM generalmente generan texto un token a la vez. Un token puede ser una palabra, parte de una palabra, un signo de puntuación u otra pequeña pieza de texto. Cada nuevo token depende del texto ya producido, por lo que el modelo tiene que seguir pausando, verificando el contexto completo y eligiendo la siguiente pieza. Eso es preciso, pero lento. Es como si un editor senior aprobara cada palabra antes de que un escritor pueda pasar a la siguiente. El editor puede ser excelente, pero el proceso crea un cuello de botella. La decodificación especulativa, desarrollada en la era temprana de los Transformadores, intenta arreglar ese cuello de botella. En lugar de pedirle al gran modelo que produzca cada token uno por uno, el sistema utiliza un componente de borrador más pequeño o más ligero para sugerir varios tokens siguientes probables. El modelo grande luego verifica ese lote de adivinanzas en paralelo. Si el borrador adivinó correctamente, el sistema avanza varios tokens a la vez. Si el borrador hizo una mala adivinanza, el sistema rechaza el token malo y cualquier cosa después de él, agrega un token corregido y lo intenta de nuevo. El objetivo es velocidad sin cambiar la salida pretendida del modelo más grande. En la configuración estándar de decodificación especulativa, el modelo de borrador no reemplaza al modelo objetivo. Actúa más como un asistente que prepara una próxima frase en bruto para que el editor senior la apruebe o rechace. La idea no apareció de la nada con los modelos de lenguaje grandes de hoy. Un precursor clave fue en 2018, cuando Mitchell Stern, Noam Shazeer y Jakob Uszkoreit propusieron la decodificación paralela por bloques para modelos autoregresivos profundos. Su método predecía múltiples pasos futuros en paralelo, luego mantenía el prefijo más largo validado por el modelo principal. Ese documento estableció gran parte de la intuición de borrador y verificación detrás del trabajo de decodificación especulativa posterior. La línea de investigación se volvió más explícita en 2022. Heming Xia, Tao Ge y coautores introdujeron SpecDec, un enfoque de borrador y verificación para la generación de secuencia a secuencia. Más tarde ese año, Yaniv Leviathan, Matan Kalman y Yossi Matias publicaron “Inference rápida desde transformadores a través de la decodificación especulativa”, que ayudó a definir la versión moderna de la técnica para modelos de lenguaje basados en transformadores. Los investigadores de DeepMind siguieron en 2023 con un método relacionado llamado muestreo especulativo. Esos documentos de 2022 y 2023 son los antecesores más claros de cómo se discute la decodificación especulativa en el trabajo actual de inferencia de LLM: un proceso de borrador más rápido propone tokens, y el modelo más grande verifica esos tokens de una manera diseñada para preservar la distribución de salida del modelo objetivo. Desde entonces, el campo se ha movido rápidamente a través de varias variantes, incluidos modelos de borrador separados, cabezales de predicción de múltiples tokens, verificación basada en árboles, métodos a nivel de características como EAGLE, auto-especulación, cabezales adicionales al estilo Medusa y borradores paralelos/bloque como DFlash. La métrica clave no es cuántos tokens puede adivinar un modelo de borrador. Es cuántas de esas adivinanzas acepta realmente el modelo más grande. Bloques especulativos largos ayudan solo si suficientes de los tokens propuestos sobreviven a la verificación. De lo contrario, el sistema gasta recursos verificando adivinanzas que descarta. Ese es el contexto para DSpark. La decodificación especulativa ya es una técnica de inferencia establecida antes del lanzamiento de DeepSeek, con soporte en pilas de servicio principales y múltiples enfoques de investigación en competencia. Pero todavía no es un problema resuelto. Los aumentos de velocidad dependen en gran medida del modelo de borrador, la carga de trabajo, la configuración del servicio y el nivel de tráfico actual. La contribución de DSpark es mejorar ambos lados de la compensación: intenta redactar bloques de tokens más coherentes y luego verificar solo las partes de esos bloques que probablemente valgan la pena en condiciones de servicio reales. Qué cambia DSpark DSpark aborda dos problemas relacionados: malas adivinanzas y verificación desperdiciada. Primero, el sistema utiliza lo que DeepSeek llama generación semi-autoregresiva. En inglés sencillo, eso significa que DSpark intenta combinar velocidad con un poco más de conciencia de la secuencia. Un borrador completamente paralelo puede adivinar varios tokens a la vez, lo cual es rápido, pero sus adivinanzas posteriores pueden volverse menos coherentes porque cada posición se predice de manera demasiado independiente. Un borrador puramente paso a paso puede llevar un mejor control de cómo un token conduce al siguiente, pero pierde gran parte de la ventaja de velocidad. DSpark intenta mantener lo mejor de ambos. Utiliza un esqueleto paralelo para la mayor parte del trabajo de borrador, luego agrega un cabezal secuencial ligero que permite al borrador tener en cuenta las relaciones de tokens cercanos. En el ejemplo del documento, un borrador paralelo podría confundir finales de frases probables como "por supuesto" y "sin problema", produciendo combinaciones awkward debido a que está adivinando posiciones demasiado separadas. El componente secuencial de DSpark ayuda al sistema a acomodar los tokens posteriores a los anteriores. En segundo lugar, DSpark agrega verificación programada por confianza. En lugar de pedirle siempre al modelo objetivo que verifique el mismo número de tokens de borrador, DSpark estima qué prefijo del borrador es probable que sobreviva. Un programador consciente del hardware luego ajusta cuánto de cada borrador debe ser verificado en función tanto de la confianza del modelo como de la carga de servicio actual. Una analogía simple: cuando un restaurante está tranquilo, el chef principal puede inspeccionar más del trabajo del cocinero de prep. Cuando la cocina está a tope, el chef dedica atención solo a los platos más propensos a estar listos. DSpark aplica una idea similar al servicio de IA. Bajo tráfico más ligero, el sistema puede permitirse verificar prefijos de borrador más largos. Bajo tráfico más pesado, recorta las adivinanzas finales de baja confianza antes de que consuman capacidad de lotes que podría utilizarse para otros usuarios. DeepSeek enmarca esto como una respuesta a un compromiso común de producción. La redacción de múltiples tokens estáticos puede parecer atractiva en aislamiento, pero puede perjudicar el rendimiento bajo alta concurrencia porque el sistema sigue verificando tokens que probablemente serán rechazados. El programador de DSpark hace que el presupuesto de verificación sea flexible en lugar de fijo. Resultados fuera de línea: mejor aceptación de borradores en Qwen y Gemma DeepSeek probó DSpark fuera de línea en los modelos objetivo Qwen3-4B, Qwen3-8B, Qwen3-14B y Gemma4-12B en benchmarks de matemáticas, codificación y chat. En esas pruebas, el equipo comparó DSpark con DFlash, un borrador paralelo, y Eagle3, un borrador autoregresivo. El documento informa la longitud aceptada por cada ronda de decodificación, una medida de cuántos tokens sobreviven en promedio a la verificación. A través de los tres tamaños de modelo Qwen3, DSpark mejoró la longitud aceptada promedio macro en un 30.9%, 26.7% y 30.0%, respectivamente. En comparación con DFlash, mejoró la longitud aceptada en un 16.3%, 18.4% y 18.3%. El documento también menciona que las ganancias se generalizaron a Gemma4-12B. Eso apoya un punto destacado por el desarrollador Daniel Han, quien enfatizó en X que DeepSeek demostró que DSpark funcionaba más allá de los modelos V4 de DeepSeek, incluidos Gemma y Qwen. Incluiría a Han como una reacción de la comunidad, no como la única evidencia del reclamo. El apoyo más fuerte proviene de los propios benchmarks de DeepSeek y puntos de control publicados. Los resultados fuera de línea también muestran por qué la carga de trabajo importa. Las tareas estructuradas como matemáticas y código tienden a tener longitudes aceptadas más altas que el chat abierto. Eso tiene sentido intuitivo: una finalización de código o un paso matemático a menudo tiene menos movimientos razonables siguientes que una conversación en formato libre. Para las empresas, esto significa que los métodos al estilo DSpark pueden ser especialmente atractivos para asistentes de codificación, agentes de análisis de datos, automatización de flujos de trabajo estructurados y otros entornos donde las salidas siguen patrones más predecibles. Cómo las empresas podrían usar DSpark sin DeepSeek-V4 Una de las preguntas más importantes es si DSpark es una optimización exclusiva de DeepSeek o un método más amplio que se puede aplicar a otros modelos. La respuesta es: método más amplio, pero no es un complemento automático. Para los modelos de pesos abiertos, la ruta es relativamente clara. Una empresa que ejecute Qwen, Gemma, Llama, Mistral, Granite, pesos abiertos estilo Command u otro modelo que aloje ella misma podría entrenar o ajustar un módulo de borrador al estilo DSpark contra ese modelo objetivo. El equipo luego mediría la aceptación en sus propias cargas de trabajo e integraría el programador de verificación en su pila de inferencia. Eso es diferente de simplemente descargar el módulo DSpark de DeepSeek y adjuntarlo a cualquier modelo. La decodificación especulativa depende de la alineación entre el módulo de borrador y el modelo objetivo. El borrador tiene que aprender qué es probable que acepte el modelo objetivo. Un borrador entrenado para DeepSeek-V4 no será automáticamente el borrador correcto para un modelo diferente, especialmente uno ajustado en los datos internos de una empresa o configurado para un comportamiento de razonamiento diferente. El flujo de trabajo de DeepSpec refleja esto. El proceso implica preparación de datos, regeneración de respuestas del modelo objetivo, construcción de una caché de destino, entrenamiento del modelo de borrador y evaluación de aceptación de la decodificación especulativa. Para el uso específico de dominio, es posible que el modelo de borrador necesite ajustes adicionales, especialmente si el modelo objetivo funciona en un modo de pensamiento o razonamiento. Para los modelos propietarios, la respuesta depende de lo que la empresa controla. Si una empresa posee o aloja completamente los pesos del modelo y la pila de servicio, podría teóricamente entrenar y desplegar un borrador al estilo DSpark. Si el modelo está disponible solo a través de una API alojada de un proveedor, el cliente no puede agregar DSpark directamente desde el exterior. El proveedor de API podría implementar una optimización similar internamente, pero el cliente generalmente no puede acceder al ciclo de verificación de tokens, logits, comportamiento de lotes o programador de servicio necesarios para hacer que DSpark funcione. Esa distinción es importante para los compradores empresariales. DSpark refuerza el caso para la infraestructura de IA abierta o auto-alojada porque le da a los equipos avanzados otra palanca para mejorar la velocidad y el costo. Pero también muestra por qué el servicio de modelos se está convirtiendo en una disciplina especializada. El valor no está solo en elegir un modelo, sino en cómo se ejecuta ese modelo de manera inteligente. Lo que los desarrolladores obtienen de DeepSpec Para los desarrolladores, DeepSpec ofrece un camino de implementación concreto para entrenar y evaluar modelos de borrador de decodificación especulativa. Incluye preparación de datos, pasos de entrenamiento y evaluación de benchmarks, junto con puntos de control publicados para varias familias de modelos abiertos. Esto hace que la publicación sea útil no solo para ejecutar DeepSeek-V4 con DSpark, sino también para investigadores y equipos de infraestructura que estudian cómo agregar decodificación más rápida a otros modelos abiertos. Hay advertencias reales sobre la implementación. El propio README de DeepSpec dice que la configuración predeterminada de preparación de datos de Qwen3-4B puede requerir aproximadamente 38 TB de almacenamiento en caché de destino, y los scripts predeterminados asumen un solo nodo con ocho GPU. Eso hace que la publicación sea más relevante de inmediato para laboratorios de IA, equipos de nube y grupos sofisticados de infraestructura de IA empresarial que para desarrolladores de aplicaciones ordinarias. Aun así, el lanzamiento del pipeline de entrenamiento es importante. Muchas optimizaciones de inferencia aparecen solo como documentos, benchmarks vagos o afirmaciones de producción cerradas. DeepSpec le da a los desarrolladores algo más cercano a un conjunto de planos: no un producto terminado para empresas, sino una manera de reproducir, adaptar y evaluar el método. Pruebas de comunidad tempranas La publicación ya ha atraído la rápida atención de los desarrolladores. El desarrollador Rafael Caricio publicó una solicitud de extracción en GitHub documentando el trabajo de DSpark en DeepSeek-V4-Flash, informando anclajes de benchmarks calculados de 26.33 tokens por segundo sin decodificación especulativa, 39.88 tokens por segundo con MTP-1, y aproximadamente 60 tokens por segundo con DSpark, un aumento de aproximadamente 1.5 veces sobre MTP-1 y de 2.3 veces sobre la decodificación sin especulación. Un compromiso posterior en el mismo hilo registró una media de cinco ejecuciones de 60.31 tokens por segundo, con una ganancia de 1.51 veces sobre MTP-1 y 2.29 veces sobre la decodificación no especulativa. El mismo trabajo también señala un límite práctico importante: en sesiones de codificación de múltiples turnos realistas, el rendimiento puede degradarse a medida que la aceptación de borrador disminuye con el crecimiento del contexto. En otras palabras, DSpark puede hacer que la decodificación sea más rápida, pero la calidad de aceptación aún determina cuánta velocidad realiza realmente el sistema. Esa es una comprobación de realidad útil. DSpark no es magia. Todavía depende de cuán predecibles sean los siguientes tokens y de cuán bien el borrador se mantenga alineado con el modelo objetivo. Pero el trabajo de implementación temprana sugiere que las afirmaciones de DeepSeek no son puramente académicas. Los desarrolladores ya están probando el método en entornos de servicio prácticos y reportando ganancias cercanas a las expectativas de flujo único del documento. La conclusión DSpark muestra cuánto rendimiento permanece disponible en la capa de inferencia, incluso cuando la arquitectura del modelo subyacente se mantiene igual. A medida que las empresas de IA compiten en calidad de modelo, longitud de contexto y precios, la eficiencia de decodificación se está convirtiendo en otro campo de batalla importante. Una generación más rápida significa menor latencia para los usuarios, mayor rendimiento para los proveedores y mejor economía para los equipos que sirven modelos abiertos a gran escala. La publicación de DeepSeek es notable porque combina un método probado en producción, código abierto, puntos de control públicos y un documento detallado. La principal innovación no es solo redactar más tokens. Se trata de hacer que el sistema sea más selectivo acerca de qué trabajo especulativo vale la pena verificar. Para los equipos empresariales, la lección más amplia es que la próxima ola de ganancias de rendimiento en IA no vendrá solo de modelos más grandes. También vendrá de maneras más inteligentes de ejecutar los modelos que las empresas ya poseen, especialmente cuando esas empresas controlan suficiente de la pila para ajustar el modelo, entrenar un módulo de borrador compatible y optimizar el motor de servicio en torno a cargas de trabajo reales.