DSpark: aceleración de la inferencia de LLM con speculative decoding [pdf]

 (github.com/deepseek-ai)
1 puntos por GN⁺ 7 시간 전 | 1 comentarios | Compartir por WhatsApp
  • DSpark: un framework de speculative decoding que combina generación semiautoregresiva (semi-autoregressive) y programación basada en confianza
  • Resuelve simultáneamente el problema de que un drafter paralelo (parallel drafter) proponga bloques largos de tokens con una sola pasada hacia adelante, pero sufra una caída abrupta de la tasa de aceptación (acceptance decay) en las posiciones finales por falta de dependencias entre tokens, mediante una estructura semiautoregresiva y verificación consciente de la carga
  • Combina un backbone paralelo pesado con un módulo secuencial ligero para inyectar dependencias dentro del bloque, manteniendo la velocidad de draft y mitigando el colapso del sufijo (suffix decay)
  • Un confidence head estima la probabilidad de supervivencia del prefijo por posición, y un scheduler consciente del hardware ajusta dinámicamente la longitud de verificación por solicitud según la curva de throughput del motor
  • En benchmarks offline, mejora de forma consistente la longitud aceptada (accepted length) frente al baseline autoregresivo (Eagle3) y el baseline paralelo (DFlash); al desplegarlo en producción con DeepSeek-V4, reduce el desperdicio de verificación
  • Frente a MTP-1, el baseline de producción existente, acelera la velocidad de generación por usuario en 60–85% con el mismo throughput, abre un rango de rendimiento antes inalcanzable bajo restricciones estrictas de interactividad y amplía la frontera de Pareto

Definición del problema: dos cuellos de botella de los drafters paralelos

  • Los LLM generan tokens de forma autoregresiva; cada token requiere una pasada hacia adelante condicionada por todos los tokens previos, por lo que la latencia de inferencia es proporcional a la longitud de salida. La baja utilización de GPU y la alta latencia actúan como cuellos de botella principales en el serving de producción
  • El speculative decoding acelera sin pérdida de calidad: un modelo draft ligero propone un bloque candidato y el modelo target lo verifica con una sola pasada hacia adelante, aceptando el prefijo más largo que coincide con la distribución target mediante rejection sampling

  • Limitaciones de los drafters autoregresivos

    • Tienen gran capacidad de modelado al condicionar cada posición en los tokens anteriores, pero el costo de drafting crece linealmente con el tamaño del bloque (𝑇draft ∝ 𝛾), lo que los restringe a bloques pequeños y estructuras poco profundas

  • Limitaciones de los drafters paralelos

    • Generan todas las posiciones de una vez, por lo que la latencia del draft casi no depende del tamaño del bloque y pueden usar bloques grandes (por ejemplo, 𝛾=16)
    • Predicen cada posición de forma independiente, sin poder modelar dependencias entre tokens, lo que provoca colisiones multimodales (multi-modal collision) y una caída abrupta de la tasa de aceptación en las posiciones finales
    • Verificar indiscriminadamente todo un bloque largo reduce el throughput; especialmente en entornos de alta concurrencia, tokens con alto riesgo de rechazo ocupan capacidad de batch
    • La longitud de verificación ideal varía en dos ejes: el de datos (solicitudes estructuradas como código tienen alta tasa de aceptación; chats abiertos, baja) y el de sistema (con baja carga, la verificación adicional es casi gratis; con alta carga, consume capacidad de otras solicitudes activas)

Arquitectura: dos componentes complementarios

  • La latencia por token es 𝐿 = (𝑇draft + 𝑇verify)/𝜏, y la aceleración se reduce a tres palancas: reducir 𝑇draft, aumentar 𝜏 y reducir el 𝑇verify efectivo

  • Ciclo de decodificación: a partir del prompt ABC, el modelo target genera el siguiente token D (que actúa como ancla) → el backbone paralelo y el head secuencial generan el draft EFGH y las puntuaciones de confianza c1–c4 → el scheduler conserva el prefijo EFG y elimina el token H de baja confianza → el modelo target verifica en paralelo; si acepta E y F y rechaza G, genera el token de corrección G*

  • Generación semiautoregresiva (Semi-Autoregressive Generation)

    • Un drafter paralelo, ante múltiples continuaciones posibles como “of course”/“no problem”, genera combinaciones incoherentes como “of problem” porque cada posición marginaliza sobre todos los tokens previos posibles, no sobre el token previo realmente muestreado
    • Etapa paralela (Parallel stage): el backbone paralelo (se adopta DFlash) realiza una sola pasada hacia adelante sobre todo el bloque, genera estados ocultos y logits base, trata el ancla misma como la primera posición de predicción y produce 𝛾 logits a partir de 𝛾 entradas, reduciendo el cómputo del draft
    • Etapa secuencial (Sequential stage): suma a los logits base un sesgo de transición dependiente del prefijo 𝐵𝑘, de modo que cada posición quede condicionada por los tokens previos muestreados dentro del bloque; induce una distribución causal del bloque mediante factorización autoregresiva y, al ser secuencial, debe ser lo suficientemente ligera frente a la etapa paralela (𝑇sequential ≪ 𝑇parallel)
      • Head Markov: simplifica a una transición de primer orden dependiente solo del token inmediatamente anterior; aproxima la matriz completa 𝑉×𝑉 con una descomposición de bajo rango 𝐵 = 𝑊1𝑊2 (𝑟=256 por defecto), minimizando almacenamiento y cómputo por paso; tras muestrear “of”, refuerza “course” y suprime “problem”, mitigando colisiones entre modos
      • Head RNN: acumula todo el historial de prefijo dentro del bloque en un estado recurrente 𝑠𝑘, y mediante actualizaciones con compuertas accede a información anterior al token inmediato previo; sin embargo, su complejidad de implementación es alta y sus características de despliegue son desfavorables

  • Verificación con programación basada en confianza (Confidence-Scheduled Verification)

    • La tasa de aceptación del draft varía por dominio (alta en código, baja en chat abierto), y el costo de verificar tokens adicionales cambia según la carga del motor, por lo que se necesita un mecanismo integrado que enrute cómputo del target solo a tokens con ganancia esperada positiva
    • Confidence Head: para cada posición 𝑘, emite una estimación escalar 𝑐𝑘 ∈ (0,1); modela la probabilidad condicional de que el token en la posición 𝑘 pase la verificación, dado que todos los tokens previos fueron aceptados; usa una proyección lineal ligera + sigmoid
      • Se entrena supervisadamente con la tasa analítica de aceptación por paso 𝑐*𝑘 = 1 − ½‖𝑝𝑑𝑘 − 𝑝𝑡𝑘‖1 (distancia de variación total entre las distribuciones draft y target)
    • Calibración posterior: Sequential Temperature Scaling (STS): la programación consciente del hardware requiere valores absolutos de la probabilidad acumulada de aceptación, pero la confianza de las redes neuronales tiende a ser excesiva (overconfident). Como cada 𝑐𝑖 es una probabilidad condicional, se factoriza mediante producto acumulado de prefijos; en un conjunto de validación held-out se realiza una búsqueda en grilla 1D de izquierda a derecha para minimizar el ECE. Al ser una transformación que preserva el orden, mantiene el ranking de tokens
    • Scheduler de prefijos consciente del hardware (Hardware-Aware Prefix Scheduler): formaliza la elección de la longitud de verificación como un problema de maximización del throughput global; para 𝑅 solicitudes activas, usa SPS(𝐵) (tabla de costos perfilada una vez al inicializar el motor) y maximiza 𝛩 = 𝜏·SPS(𝐵)
      • Como la probabilidad de supervivencia 𝑎𝑟,𝑗 es monótonamente no creciente respecto de 𝑗, el ordenamiento global y la selección greedy respetan naturalmente las dependencias de prefijo dentro del bloque, con consultas 𝑂(1) a la tabla de costos para admisión incremental
      • El speculative decoding sin pérdida requiere la propiedad non-anticipating; como las características Markov dependen de tokens previos muestreados, una búsqueda global posterior filtra información de 𝑥𝑟,𝑘 y provoca sesgo de selección
      • Mediante un mecanismo de early-stopping, se detiene de inmediato cuando cae el throughput; fuerza causalidad haciendo que la decisión de admitir dependa solo del prefijo procesado hasta ese paso, y garantiza el máximo global solo cuando el objetivo 𝛩 es unimodal

Entrenamiento (Training)

  • Se construyen datos de entrenamiento muestreando aleatoriamente múltiples posiciones ancla en la secuencia target y formando bloques de 𝛾 tokens
  • El modelo target permanece fijo (frozen) durante todo el proceso; el modelo draft comparte y mantiene fijas la capa de embeddings y el LM head; solo se actualizan el drafter backbone, el bloque secuencial y el confidence head
  • El objetivo de entrenamiento es una suma ponderada de tres términos: pérdida de entropía cruzada Lce, pérdida de alineación de distribuciones Ltv y pérdida de confianza Lconf
    • Todos los términos se ponderan por posición con 𝑤𝑘 = exp(−(𝑘−1)/𝛾), enfatizando las posiciones iniciales, que contribuyen más a la longitud esperada de aceptación en una verificación basada en prefijos
    • Ltv penaliza la distancia de variación total; como la probabilidad de aceptación por paso es igual a 1 − ½‖𝑝𝑑 − 𝑝𝑡‖1, minimizar Ltv equivale a maximizar la tasa esperada de aceptación
    • Pesos por defecto: 𝛼ce = 0.1, 𝛼tv = 0.9, 𝛼conf = 1.0

Experimentos: benchmarks offline

  • Configuración

    • Modelo target: Qwen3-{4B, 8B, 14B}, Gemma4-12B / drafters de comparación: DFlash, drafter paralelo SOTA; Eagle3, drafter autoregresivo
    • Se reentrenan todos con el mismo framework y datos; el horizonte TTT (7) de Eagle3 se alinea con el tamaño de bloque (7) de DFlash y DSpark; número de capas de draft: Eagle3 usa 1, DSpark y DFlash usan 5
    • Datos de entrenamiento: Open-PerfectBlend, 1.3 millones de muestras (chat 17.6%, matemáticas 39.4%, código 38.9%, seguimiento de instrucciones 4.1%); se usan solo los prompts y cada modelo target regenera las respuestas; entrenamiento por 10 epochs
    • Dominios de evaluación: matemáticas (GSM8K, MATH500, AIME25), código (MBPP, HumanEval, LiveCodeBench), chat cotidiano (MT-Bench, Alpaca, Arena-Hard), temperatura de muestreo 1.0; se reporta la longitud aceptada por ronda 𝜏

  • Resultados principales

    • La evaluación offline desactiva el scheduler de confianza para aislar la calidad pura del draft con bloque fijo
    • En Qwen3-4B, 8B y 14B, mejora la longitud de aceptación promedio macro frente a Eagle3 en 30.9%, 26.7% y 30.0%, y frente a DFlash en 16.3%, 18.4% y 18.3%; también muestra ganancias consistentes en Gemma4-12B, confirmando la generalización entre familias de modelos
    • La longitud de aceptación en tareas estructuradas es mayor que en chat abierto (para Qwen3-4B: matemáticas 5.57 y código 5.12 vs. chat 3.49); la variación en la predictibilidad de los datos provoca desperdicio con longitudes de verificación estáticas y motiva la programación basada en confianza

Análisis experimental

  • Por qué la generación paralela supera a la autoregresiva

    • Se analiza una observación contraintuitiva: los drafters paralelos y semiautoregresivos logran longitudes de aceptación mayores que el Eagle3 completamente autoregresivo, usando la tasa condicional de aceptación por posición (en el denominador solo se cuentan los casos en que todas las posiciones anteriores fueron aceptadas)
    • Ventaja de capacidad en la posición 1: la primera posición depende solo del contexto target. Eagle3 queda restringido a una red poco profunda por su latencia 𝑂(𝛾), mientras que un drafter paralelo 𝑂(1) puede usar una red profunda. DFlash empieza más alto que Eagle3 (matemáticas 0.88 vs. 0.81, chat 0.72 vs. 0.53); como el rechazo del primer token invalida todo el bloque, la ventaja inicial impacta mucho en la longitud final aceptada
    • Límite de independencia en posiciones finales: en las posiciones 2–7, Eagle3 aprovecha la certeza condicional y se mantiene o sube (chat 0.53→0.74), mientras que DFlash cae bruscamente (código 0.87→0.78, chat 0.72→0.63), generando sufijos incoherentes por colisiones multimodales
    • La semiautoregresión mitiga el colapso del sufijo: DSpark hereda la alta aceptación inicial del backbone paralelo profundo (empieza en 0.93 en matemáticas) y, con un head secuencial ligero, contiene el colapso posterior, manteniendo tasas de aceptación condicionales altas y estables en todo el bloque

  • Un poco de autoregresión alcanza para un gran efecto

    • Profundidad del drafter: con tamaño de bloque fijo en 7, el rendimiento de DSpark mejora monótonamente al aumentar las capas de 1 a 5; la ganancia marginal más grande ocurre de 1 a 2 capas, y DSpark de 2 capas supera a DFlash de 5 capas en todos los dominios, demostrando la eficiencia paramétrica del head secuencial
    • Longitud propuesta: con profundidad fija en 5, al ampliar la longitud de draft {4,8,12,16}, DSpark supera a DFlash en todas las longitudes; la brecha crece con 𝛾 (en 𝛾=7: matemáticas 16%, código 15%, chat 18%; en 𝛾=15: 30%, 26%, 22%). El head RNN aporta solo una pequeña ganancia adicional en longitudes largas, por lo que se adopta el head Markov por defecto
    • Overhead de latencia: con batch 128 y promedio sobre longitudes de contexto {512,1024,2048,4096}, la latencia del bloque secuencial es despreciable; al ampliar la longitud de draft de 4 a 16, solo añade 0.2–1.3% a la latencia total por ronda, mientras mejora hasta 30% la longitud aceptada

  • Rol del confidence head: no verificar más largo, sino con más inteligencia

    • Diagnóstico con barrido de umbrales estáticos usando Qwen3-4B: al subir el umbral, aumenta la tasa de aceptación al filtrar tokens rechazables; el efecto es mayor en chat (45.7%→95.7%), y más moderado en matemáticas (76.9%→92.5%) y código (67.6%→92.0%)
    • El umbral estático ignora la carga del sistema y es subóptimo en serving dinámico; el modelo de confianza tiene fuerte capacidad discriminativa (ROC-AUC 0.81–0.90), pero está sobreconfiado (ECE 3–8%). Tras aplicar STS, reduce el ECE promedio a cerca de 1%, obteniendo estimaciones de supervivencia confiables

Despliegue en producción

  • Entrenamiento escalable

    • Despliegue conjunto con previews de DeepSeek-V4-Flash y Pro; el backbone paralelo consta de 3 capas MoE con mHC y sliding window attention 128, tamaño máximo de bloque 𝛾=5, y usa head Markov; el confidence head se entrena end-to-end y luego se calibra con STS
    • Comunicación de estados ocultos (Hidden state communication): en lugar de transferir logits de vocabulario completo (𝑉≈10⁵), se comunican solo los estados ocultos previos al LM head, y el LM head se ejecuta localmente en el worker draft solo para las posiciones muestreadas, reduciendo la complejidad de comunicación por token a 𝑂(𝑑)
    • Empaquetado de secuencias limitado por anclas (Anchor-bounded sequence packing): se muestrea un número fijo de anclas draft y se empaquetan bloques de predicción aislados en batches densos; se mantiene el enmascaramiento causal entre múltiples secuencias independientes mediante índices de attention a nivel de token, evitando overhead de padding

  • Aplicación práctica del scheduler

    • Dos conflictos: el algoritmo asume una curva de capacidad unimodal y suave, pero el SPS(𝐵) real es discreto y cae en escalones; además, la programación dinámica de tokens por paso entra en conflicto con el replay continuo de CUDA graph y Zero-Overhead Scheduling (ZOS)
    • Adaptación mediante programación asíncrona: como ZOS requiere el tamaño del siguiente batch antes de completar el paso actual, aproxima la capacidad de verificación con las salidas de confianza de dos pasos atrás; los candidatos del paso actual se ordenan con la confianza acumulada más reciente, y las predicciones pasadas se usan solo para decidir la longitud de corte dinámica (𝐾), convirtiéndolo en selección top-𝐾 dinámica
    • Se elimina el early-stopping para habilitar una búsqueda global sin restricciones; al evaluar solo el historial de dos pasos atrás, queda aislado de la realización del token actual 𝑥𝑟,𝑘 y forma una barrera causal, haciendo compatibles la maximización del throughput físico al superar acantilados de hardware y la preservación exacta de la distribución target

  • Inferencia de alto throughput y baja latencia

    • El serving de producción optimiza simultáneamente la latencia por solicitud y el throughput total; en este despliegue, por limitaciones de capacidad de KV-cache y tráfico de usuarios, el tamaño efectivo de batch queda por debajo del umbral de saturación de GPU, por lo que ambos objetivos se simplifican a una relación altamente correlacionada en vez de competir
    • Un desafío es soportar consultas de longitud variable. Si se procesan de forma simple en kernels de decode de longitud fija, el padding y la carga desigual reducen la utilización de GPU; se aplanan todos los tokens de solicitudes como elementos independientes y las dependencias dentro de cada secuencia se transmiten con un marker tensor de sparse attention. En DeepSeek-V4, solo se modifican los kernels index-attention y compress para soportar enrutamiento de longitud variable

  • Rendimiento con tráfico de usuarios reales

    • Se compara DSpark-5 (𝛾=5) con el baseline MTP-1 en motores de producción V4-Flash y Pro; MTP-1 era una configuración de un solo token mantenida porque los drafters multitoken estáticos (MTP-3/5) reducían el throughput con alta concurrencia, y fue reemplazado por DSpark dos semanas después del lanzamiento de DeepSeek-V4-preview
    • V4-Flash: con SLA de 80 tok/s/user, mejora el throughput en 51%; a 120 tok/s/user, MTP-1 se acerca al límite operativo y DSpark muestra una ventaja nominal de 661% (interpretada no como un múltiplo absoluto, sino como evidencia de ampliación de la frontera de interactividad); con el mismo throughput, acelera la generación por usuario en 60–85%
    • V4-Pro: mejora 52% a 35 tok/s/user y muestra una ventaja nominal de 406% a 50 tok/s/user; con la misma capacidad, acelera 57–78% y, en general, desplaza hacia afuera la frontera throughput–interactividad
    • Comportamiento adaptativo a la carga: con concurrencia media (menos de 200 solicitudes en V4-Flash y 150 en V4-Pro), el scheduler expande los 2 tokens estáticos de MTP-1 a unos 4–6 tokens por solicitud, aumentando los tokens aceptados por pasada hacia adelante; al saturarse la concurrencia, reduce suavemente la longitud de verificación para podar tokens de baja confianza antes de que consuman capacidad de batch

  • Limitaciones

    • Aunque el scheduler de prefijos minimiza el desperdicio de verificación target, persiste el costo fijo de draft de generar el bloque inicial de 𝛾 tokens con el backbone paralelo; en consultas complejas con tasas de aceptación inherentemente bajas, ese cómputo previo no se puede recuperar
    • En el futuro, podría mejorarse con early exiting consciente de la dificultad dentro del modelo draft, para que esas solicitudes eviten la generación de todo el bloque

Conclusión

  • Desde el punto de vista estructural, el paradigma semiautoregresivo que combina un backbone paralelo pesado y un head secuencial ligero mitiga el colapso abrupto del sufijo en drafters paralelos independientes
  • Desde el punto de vista del sistema, formaliza la elección de la longitud de verificación como un problema de maximización del throughput global, y ajusta dinámicamente el presupuesto de verificación mediante un scheduler de prefijos consciente del hardware basado en probabilidades de supervivencia calibradas y carga del motor en tiempo real
  • En evaluaciones offline amplias supera a baselines SOTA autoregresivos y paralelos, y en un despliegue real de DeepSeek-V4 demuestra valor práctico al mantener alta concurrencia bajo carga, acelerar la generación por usuario y ampliar la frontera de Pareto del serving de LLM

Lecturas relacionadas

1 comentarios

 
GN⁺ 7 시간 전
Opiniones en Hacker News

  • DeepSeek no solo está empujando los límites, sino que además publica papers excelentes que explican cómo logró sus mejoras de rendimiento.
    Lamentablemente, los laboratorios de EE. UU. ya casi no publican este tipo de cosas, y parece que el trabajo más interesante en IA hoy lo están haciendo laboratorios chinos.

    • Google todavía publica bastante investigación sobre arquitecturas de LLM.
      En 2022 presentó el decodificado especulativo para LLM[1], y este año también publicó código para hacer decodificado especulativo con los modelos Gemma 4[2].

      [1] https://arxiv.org/abs/2211.17192

      [2] https://github.com/google-gemma/cookbook/blob/main/docs/mtp/...

    • Las empresas de IA de EE. UU. tienen que responder por inversiones enormes, así que parece que buscan algún foso mágico que justifique sus valuaciones.
      Si publicaran este tipo de optimizaciones, su ventaja competitiva se reduciría bastante.

    • Quizás sea una apertura por necesidad.
      Como los laboratorios de EE. UU. están abriendo camino en la frontera, la hipótesis es que DeepSeek intenta nivelar el campo de juego publicando como open source lo que tiene.

    • DeepSeek está comoditizando las mejoras de rendimiento de las que dependen los laboratorios estadounidenses para generar dinero para sus inversionistas.

    • Ya va siendo hora de que Occidente deje de ver a los chinos solo como “personas muy malas bajo una dictadura”.

  • Los modelos de Hugging Face ya están publicados, y parece que vienen con un módulo de decodificado especulativo integrado al modelo original; está bastante bueno.

    Flash: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-DSpark

    Pro: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

    Espero que también llegue a DwarfStar para inferencia local.
    He estado usando mucho el modelo Flash desde que antirez publicó la cuantización de 2 bits.

    • ¿Habrá posibilidad de que esto se aplique también a Qwen 27B?

  • Por ahora me da la impresión de que DeepSeek es casi la única empresa de IA que realmente intenta innovar, en lugar de simplemente apuntar al primer lugar en benchmarks.
    Lugares como OpenAI, Anthropic y Google parecen estar más concentrados en competir entre sí que en seguir innovando.

    • Creo que también habría que incluir a otros laboratorios chinos, como Moonshot (creadores de Kimi) y Z.ai (creadores de GLM).
      Ellos también están innovando y siguen compartiendo investigación de forma abierta.
      Tengo entendido que el fundador de Moonshot incluso subió a Twitter un video de 40 minutos explicando las técnicas que sostienen a Kimi.

    • Muchas empresas estadounidenses hace tiempo que adoptaron como estrategia retener al usuario, por cualquier medio.
      La calidad y la innovación son factores secundarios; buscan dominar el mercado, encerrar a los usuarios y luego usar regulación y lobby para mantener su poder.

    • Esas empresas también compiten entre sí mediante innovación.
      La innovación les da más utilidad a los clientes, pero la tecnología simplemente no se publica.
      Los secretos comerciales son secretos por una razón.

      La razón por la que DeepSeek parece “la más innovadora” puede ser que eso es lo observable desde afuera.
      Es una ilusión parecida a concluir que, como no todo el mundo publica fotos suyas al público, los modelos publicados son los más atractivos de toda la población.

    • Los grandes laboratorios ya llevaban al menos un año haciendo este tipo de cosas.

    • Qwen también.

  • Llevo un mes usando DeepSeek v4 pro en Kilo Code y es excelente.
    Es rápido, estable, tiene una ventana de contexto grande y es realmente barato.
    Este mes usé 1.500 millones de tokens y me costó 40 dólares; aunque la mayoría estaba cacheada, sigue siendo barato.

    • En omp estoy usando DeepSeek como agentes task y quicktask, y Sonnet para el resto.
      Mi gasto en IA bajó mucho, de 40 dólares por día a 10 dólares por día.
    • Me da curiosidad qué proveedor usaste.
      En OpenRouter gasté 40 dólares bastante rápido.
      No fueron tantas conversaciones de ida y vuelta; el contexto era de unas 300 mil líneas y la salida de unas 15 mil líneas.
      Estaba usando opencode, pero no sé bien si se puede hacer que muestre el total de tokens.
    • Me da curiosidad si comparaste Kilo con Pi u OpenCode.
      Conozco esos dos, pero siempre estoy buscando alternativas.
    • ¿Hay alguna forma de ver cuántos tokens usaste en Claude Code Pro?

  • ¿Esto es más nuevo o mejor que el decodificado especulativo de 2022? https://arxiv.org/abs/2211.17192

    • Ese paper se cita en las secciones “introduction” y “background” de este trabajo.
      Este paper trata sobre mejoras que eliminan varios cuellos de botella.
    • Parece enfocarse en mejorar el modelo borrador y la política de verificación para que, a la escala de DeepSeek, la especulación se traduzca en una mejora neta de velocidad y no en trabajo de verificación desperdiciado.

  • El momento no parece casual.
    Parece una demostración de apertura frente a una regulación fuerte.

    • China = abierta, EE. UU. = regulación fuerte; qué línea temporal tan extraña.
      Aunque esto es posible porque está alineado con los objetivos de Xi.
    • Nadie obligó a Anthropic a lanzar una ofensiva mediática exagerando los riesgos de los nuevos modelos de IA.
      Francamente, se lo buscaron.

  • El título es malo.
    No es el título del paper, sino la primera línea del resumen.
    El decodificado especulativo para inferencia de LLM ya se había publicado en 2022: https://arxiv.org/abs/2211.17192

    Este paper parece ser una mejora del decodificado especulativo, aunque todavía no lo leí.

  • Por el nombre, al principio pensé que estaba relacionado con DGX Spark.
    Casualmente, últimamente hubo mucho trabajo para mejorar el rendimiento de inferencia de DGX Spark, y con MTP se obtuvieron mejoras de velocidad del 50% al 100%, así que DSpark también parece bastante útil para ese objetivo.

  • Probablemente esto ya se venía usando en producción desde hace un tiempo, y tal vez fue una de las razones por las que pudieron bajar tanto los precios hace un mes.

    • Sí.
      El capítulo 5 trata sobre el despliegue real.
      En 5.1 dice “DSpark draft models are co-deployed with the preview versions of DeepSeek-V4-Flash and DeepSeek-V4-Pro”, y en 5.4 dice “MTP-1 represents the former production setup, having been superseded by DSpark two weeks following the DeepSeek-V4-preview release”.
    • Lookahead Sparse Attention probablemente también tuvo un papel importante.
      Porque reduce mucho el uso de memoria.
    • Buen punto.
      Bajaron los precios un 75%, y parece encajar exactamente con las ganancias de velocidad y de optimización de inferencia.

  • Creo que pronto llegaremos a un mundo con una gran variedad de modelos pequeños para decodificado especulativo, específicos para cada caso de uso, empresa e incluso persona.

    • Ojalá sea así, y ojalá el hardware no se vuelva imposible de conseguir.

    • Sí.
      Vendrán fuertemente restringidos por guardrails sofisticados.

      Definitivamente vamos en esa dirección.
      Los modelos gigantes que intentan devorarse el mundo tienen rendimientos decrecientes muy fuertes en comparación.

    • Parece que claramente no leíste los papers recientes sobre decodificado especulativo.
      Desde hace tiempo ya se puede usar prácticamente cualquier modelo para especular por otro.
      El problema de tokenización que antes lo impedía ya se resolvió.