¡La nueva tecnología de DeepSeek se trasplanta a chips de Apple! Los grandes modelos locales en Mac se aceleran un 60%.

DSpark acaba de ser de código abierto durante una semana y ya se ha trasladado a las computadoras Apple.

La versión移植ada se llama mlx-dspark y ejecuta los modelos Gemma-4 12B y Qwen3-4B.

Después de instalarlos, la velocidad de generación de estos dos modelos en Mac aumentó 1.6 veces y 1.4 veces respectivamente.

Lo más difícil es que logró algo que la mayoría de las versiones移植adas no pueden hacer: la salida es idéntica byte por byte al modelo original, sin un solo error de palabra.

Es decir, se ganó velocidad sin perder calidad en absoluto.

Quien lo hizo es Abdur Rahim, un ingeniero que trabaja en proyectos de código abierto en su tiempo libre. La primera versión nativa para Mac de DSpark desde que se abrió el código, fue creada por él solo.

Las computadoras Apple ejecutan modelos grandes, aumentando la velocidad en un 60%

Para DSpark, que DeepSeek abrió en código el 27 de junio, las cifras oficiales indican que puede aumentar la velocidad entre un 60% y un 85% en escenarios del lado del servidor.

Sin embargo, esta tecnología solo tenía implementación en GPU de centros de datos, sin versión adaptada para el chip de Apple.

mlx-dspark es la primera versión nativa para el chip de Apple de esta tecnología.

La idea de DSpark es asignar un modelo más pequeño para ayudar al modelo objetivo. El modelo pequeño primero genera varias palabras candidatas de una sola vez, y luego el modelo objetivo las verifica todas juntas: acepta las correctas y descarta las incorrectas para que el modelo pequeño vuelva a adivinar.

El costo de este paso es diferente en un centro de datos y en una computadora Apple.

En la GPU del centro de datos, verificar un lote de palabras candidatas es más como un viaje en autobús: el precio es fijo sin importar cuántas personas viajen. La decodificación ya es un cuello de botella de memoria, por lo que verificar más palabras casi no añade tiempo.

En el chip de Apple, es más como un taxi con taxímetro: cuantas más palabras candidatas se verifican, más sube el contador.

Rahim midió que por cada token adicional que verifica Gemma-4 12B, se añaden aproximadamente 14 milisegundos. Modeló este costo en un modelo de costos y concluyó que el límite de velocidad en el chip de Apple es de alrededor de 2.2 veces.

En resumen, Rahim trasladó el modelo pequeño auxiliar desde el checkpoint de HuggingFace y lo asignó a los dos modelos objetivo: Gemma-4 12B y Qwen3-4B.

También reconfiguró el proceso de verificación en el marco MLX y cuantificó los pesos a 4 bits.

Como resultado, en M4 Pro, en comparación con la herramienta MLX oficial de Apple, la velocidad de generación de Gemma-4 12B aumentó de 18.4 tok/s a aproximadamente 30 tok/s, aproximadamente 1.6 veces; la de Qwen3-4B aumentó de 52.9 tok/s a aproximadamente 73 tok/s, aproximadamente 1.4 veces.

Además, en mlx-dspark, Rahim hizo algo que la mayoría de los trabajos de移植ación no hacen.

Versión移植ada también puede lograr una reproducción de alta precisión

La mayoría de las versiones que llevan modelos grandes al dispositivo local solo admiten decodificación greedy, es decir, seleccionan la palabra con mayor probabilidad en cada paso.

Rahim, en mlx-dspark, también implementó el método de muestreo por temperatura descrito originalmente en el documento de DSpark. El modelo borrador proporciona palabras candidatas, la probabilidad de aceptación es min(1, p/q), y las no aceptadas se vuelven a muestrear a partir del residual.

Él mismo verificó que la salida generada por este proceso es estrictamente igual a la distribución exacta que el modelo objetivo daría a la misma temperatura, no una versión aproximada reducida.

La mayoría de las decodificaciones especulativas solo hacen la versión greedy, porque verificar la corrección del modo greedy es simple: comparar byte por byte.

El paso adicional que Rahim hizo fue verificar la distribución de salida en modo de muestreo para confirmar que no hubo distorsión.

Determinar la precisión del modelo objetivo encargado de la verificación fue un problema que él mismo descubrió.

Si el modelo pequeño se combina con el modelo objetivo base sin ajuste de instrucciones, solo el 47% de las palabras candidatas generadas pasan la verificación; al cambiarlo a la versión ajustada por instrucciones correspondiente, esta proporción aumenta al 82%.

También probó cambiar el modelo objetivo a precisión bf16; el costo de verificación aumentó más que la tasa de aprobación, resultando más lento, por lo que dejar el modelo objetivo por defecto en 8 bits es lo más rentable.

El modelo pequeño encargado de generar palabras candidatas utiliza un conjunto diferente de precisión.

El modelo borrador en sí fue comprimido, y después de la cuantización a 4 bits, solo ocupa 1.8 GB, sin presión en la memoria, y se ejecuta sin pérdida.

El resultado es que DSpark no solo logró aceleración, sino que también reprodujo en el dispositivo el aumento del 16% al 18% en la tasa de aceptación mencionado en el documento.

DFlash también se integró, tareas de código más rápidas

Después de que se publicó el tweet, apareció un comentario en la sección de respuestas: Jian Chen, uno de los autores del documento de DFlash, preguntó si podían probar el modelo de su equipo.

DFlash es otro esquema de decodificación especulativa propuesto en un documento publicado por z-lab en mayo de este año. El líder del equipo de autores es Zhijian Liu, profesor asistente en UCSD, también científico investigador en NVIDIA.

La idea de DFlash es diferente de DSpark: utiliza una "difusión de bloque" paralela para denoising de un bloque completo de 16 tokens, en lugar de adivinar paso a paso con dependencias como DSpark.

Rahim actuó rápidamente.

Usó el script de移植ación escrito por el propio Jian para conectar gemma4-12B-it-DFlash publicado por z-lab al modelo objetivo Gemma-4 de mlx-vlm, y en la misma Mac, realizó otra comparación cara a cara con DSpark que acababa de probar.

En tareas de código y matemáticas, la longitud de aceptación de la decodificación de bloque completa de DFlash puede alcanzar de 5.95 a 6.20, con una velocidad de aproximadamente 36 tok/s, aproximadamente 2.1 veces, superando a DSpark.

Sin embargo, DFlash debe generar un bloque completo de 16 tokens de una sola vez, pero es posible que el modelo objetivo no los acepte todos; solo una parte pasa la verificación, lo que en la industria se llama "longitud de aceptación", que no siempre puede llenar los 16 completamente.

Por lo tanto, en escenarios de conversación abierta donde el contenido es difícil de predecir, la longitud de aceptación no puede aumentar, el bloque no se llena y DFlash no puede aprovechar su ventaja.

El cabezal Markov de DSpark existe precisamente para solucionar el mismo problema. Al generar un bloque completo de palabras en paralelo, las posiciones posteriores se calculan de manera independiente, lo que tiende a hacer que no encajen entre sí. El cabezal Markov agrega una capa de dependencia entre estas posiciones para corregir este problema.

El resultado es que, en escenarios de conversación, DSpark es más rápido que DFlash.

Posteriormente, en la actualización mlx-dspark v0.0.3, el DFlash original de z-lab se integró oficialmente en el paquete, y se agregó un parámetro para ajustar manualmente la longitud efectiva del bloque de DFlash: usar bloques cortos en escenarios de conversación, y bloques completos de 16 en escenarios de código y matemáticas.

A partir de entonces, la misma Mac y el mismo paquete pueden completar simultáneamente tareas de conversación, código y matemáticas, sin tener que cambiar entre los proyectos DSpark y DFlash.

Rahim dijo en su tweet que el mismo método debería funcionar también con modelos borrador más grandes como Qwen3-8B y 14B.

Fuente: Quantum Bit

Aviso de riesgo y términos de exención de responsabilidad

        El mercado tiene riesgos, la inversión debe ser cautelosa. Este artículo no constituye asesoramiento de inversión personal y no tiene en cuenta los objetivos de inversión, situación financiera o necesidades específicas de usuarios individuales. Los usuarios deben considerar si las opiniones, puntos de vista o conclusiones de este artículo se ajustan a sus circunstancias particulares. Las inversiones basadas en esto son bajo su propia responsabilidad.