DeepSeek nova tecnologia transplantada para chips da Apple! Modelos grandes locais no Mac aceleram 60%

DSpark acabou de ser de código aberto há uma semana e já foi transferido para o Mac.

A versão portada chama-se mlx-dspark e executa os modelos Gemma-4 12B e Qwen3-4B.

Depois de instalados, a velocidade de geração destes dois modelos no Mac aumentou 1,6 vezes e 1,4 vezes, respetivamente.

O mais difícil é que conseguiu algo que a maioria das versões portadas não consegue — a saída é exatamente igual byte a byte ao modelo original, sem um único caractere de diferença.

Ou seja, ganhou-se velocidade sem perder qualidade.

A pessoa que fez isto é Abdur Rahim, um engenheiro que mexe em projetos de código aberto nos tempos livres. A primeira versão nativa para Mac desde que o DSpark foi aberto foi feita por ele sozinho.

Modelos grandes a correr no Mac, velocidade 60% mais rápida

Em relação ao DSpark, que a DeepSeek abriu a 27 de junho, os números oficiais indicam uma aceleração de 60% a 85% em cenários de servidor.

No entanto, na altura, esta tecnologia só tinha implementação em GPUs de centros de dados, sem versão adaptada ao chip da Apple.

O mlx-dspark é a primeira versão nativa para chip Apple desta tecnologia.

A ideia do DSpark é atribuir um modelo mais pequeno para ajudar o modelo alvo: o modelo pequeno gera primeiro várias palavras candidatas, e o modelo alvo verifica-as todas de uma vez: as corretas são aceites, as erradas são rejeitadas e o modelo tenta de novo.

O custo deste processo é diferente num centro de dados e num Mac.

Nas GPUs dos centros de dados, verificar um lote de candidatos é como um aluguer de autocarro: paga-se o mesmo preço independentemente do número de passageiros. A descodificação já é um gargalo de memória, verificar mais algumas palavras quase não custa tempo extra.

No chip Apple, é mais como um táxi: quanto mais candidatos se verificam, mais o taxímetro aumenta.

O Rahim testou e, para o Gemma-4 12B, cada token extra verificado custa cerca de 14 milissegundos. Ele transformou estas contas num modelo de custos e concluiu que o teto de velocidade no chip Apple é de cerca de 2,2 vezes.

Resumindo, o Rahim transferiu o modelo pequeno auxiliar do checkpoint do HuggingFace e atribuiu-o aos dois modelos alvo: Gemma-4 12B e Qwen3-4B.

Ele também reimplementou o processo de verificação no framework MLX e quantificou os pesos para 4-bit.

Como resultado, no M4 Pro, comparando com a ferramenta oficial da Apple MLX, a velocidade de geração do Gemma-4 12B subiu de 18,4 tok/s para cerca de 30 tok/s, cerca de 1,6 vezes o original; a do Qwen3-4B subiu de 52,9 tok/s para cerca de 73 tok/s, cerca de 1,4 vezes o original.

Além disso, no mlx-dspark, o Rahim fez algo que a maioria dos trabalhos de portabilidade não fez.

Versão portada também pode ter alta precisão de reconstrução

A maioria das versões que trazem modelos grandes para o local só suporta descodificação gananciosa, ou seja, escolhe sempre a palavra com maior probabilidade.

No mlx-dspark, o Rahim implementou também o método de amostragem por temperatura originalmente descrito no artigo do DSpark: o modelo rascunho dá palavras candidatas, a probabilidade de aceitação é min(1, p/q), e a parte não aceite é reamostrada a partir do resíduo.

Ele próprio verificou que a saída deste processo é estritamente igual à distribuição exata que o modelo alvo daria à mesma temperatura, não uma versão aproximada com perdas.

A maioria das descodificações especulativas só faz versões gananciosas porque é simples verificar a correção do modo ganancioso — basta comparar byte a byte.

O passo extra que o Rahim deu foi verificar ele próprio a distribuição de saída no modo de amostragem, confirmando que não houve desvio.

A precisão a usar no modelo alvo responsável pela verificação foi um problema que ele descobriu por tentativa.

Se o modelo pequeno fosse combinado com a versão base do modelo alvo sem fine-tuning por instruções, apenas 47% das palavras candidatas passavam na verificação; trocando para a versão com fine-tuning por instruções, a percentagem subia para 82%.

Ele também testou mudar o modelo alvo para precisão bf16, mas o custo de verificação aumentou mais do que a taxa de aprovação, tornando-se mais lento. Por isso, o modelo alvo fica por defeito em 8-bit, que é o mais vantajoso.

O modelo pequeno que avança primeiro a gerar palavras candidatas usa outra precisão.

O próprio modelo rascunho foi comprimido: com quantificação de 4-bit, tem apenas 1,8 GB, cabe na memória sem pressão e corre sem perdas.

O resultado é que o DSpark não só conseguiu acelerar, como também reproduziu no lado do dispositivo o aumento de 16% a 18% na taxa de aceitação mencionado no artigo.

O DFlash também foi integrado, tarefas de código mais rápidas

Após a publicação do tweet, chegou um comentário: Jian Chen, um dos autores do artigo do DFlash, perguntou se era possível testar o modelo da equipa deles.

O DFlash é outro esquema de descodificação especulativa proposto no artigo publicado pelo z-lab em maio deste ano. O líder da equipa de autores é Zhijian Liu, professor assistente na UCSD e também investigador científico na NVIDIA.

A ideia do DFlash é diferente da do DSpark: usa uma "difusão em bloco" paralela para desruido de um bloco inteiro de 16 tokens, em vez de adivinhar passo a passo com dependências como no DSpark.

O Rahim agiu rapidamente.

Usou o script de portabilidade escrito pelo próprio Jian e ligou o gemma4-12B-it-DFlash, publicado pelo z-lab, ao modelo alvo Gemma-4 do mlx-vlm. No mesmo Mac, fez uma nova comparação frente a frente com o DSpark que acabara de testar.

Em tarefas de código e matemática, o comprimento de aceitação da descodificação em bloco do DFlash chegou a 5,95 a 6,20, com velocidade de cerca de 36 tok/s, cerca de 2,1 vezes, superando o DSpark.

No entanto, o DFlash tem de gerar um bloco inteiro de 16 tokens de uma vez, mas o modelo alvo pode não aprovar todos; apenas uma parte passa na verificação. A indústria chama a isto "comprimento de aceitação", e nem sempre se consegue preencher os 16.

Assim, em cenários como conversas abertas, onde o conteúdo é difícil de prever, o comprimento de aceitação não sobe, o bloco não se enche e o DFlash não mostra vantagem.

A cabeça Markov do DSpark foi precisamente criada para lidar com o mesmo problema: gera um bloco inteiro de palavras em paralelo, mas as posições posteriores são calculadas independentemente, podendo não combinar bem. A cabeça Markov adiciona uma camada de dependência entre essas posições, corrigindo especificamente este problema.

O resultado é que, em cenários de conversa, o DSpark é mais rápido que o DFlash.

Depois, a versão atualizada mlx-dspark v0.0.3 integrou oficialmente o DFlash original do z-lab no pacote, e adicionou um parâmetro para encurtar manualmente o comprimento efetivo do bloco do DFlash: blocos curtos para conversas, e blocos completos de 16 para código e matemática.

A partir daí, o mesmo Mac e o mesmo pacote podem realizar simultaneamente tarefas de conversa, código e matemática, sem necessidade de alternar entre os projetos DSpark e DFlash.

O Rahim disse no tweet que o mesmo método deve funcionar também com modelos rascunho maiores, como Qwen3-8B e 14B.

Fonte: Quantum Bit

Aviso de risco e termos de isenção de responsabilidade

        O mercado tem risco, investir requer cautela. Este artigo não constitui uma recomendação de investimento pessoal, nem considera os objetivos de investimento, situação financeira ou necessidades específicas de utilizadores individuais. Os utilizadores devem considerar se as opiniões, pontos de vista ou conclusões neste artigo se adequam à sua situação específica. O investimento com base nisto é da responsabilidade do próprio.