DeepSeek nova tecnologia移植苹果芯片！Mac本地大模型加速60%

DSpark foi lançado como código aberto há apenas uma semana e já foi portado para Macs.

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

Após a instalação, a velocidade de geração desses dois modelos no Mac aumentou 1,6x e 1,4x, respectivamente.

Mais difícil ainda, ele conseguiu algo que a maioria das portas não consegue — a saída é byte a byte idêntica ao modelo original, sem diferença alguma.

Ou seja, a velocidade foi ganha, mas a qualidade não foi perdida.

Quem fez isso foi Abdur Rahim, um engenheiro que mexe em projetos open source nas horas vagas. A primeira versão nativa para Mac desde o lançamento do DSpark foi feita inteiramente por ele.

Mac rodando modelos grandes, 60% mais rápido

Para o DSpark, lançado em código aberto pela DeepSeek em 27 de junho, os números oficiais indicam aceleração de 60% a 85% em cenários de servidor.

Porém, essa tecnologia só tinha implementação em GPUs de data center, sem versão adaptada para chips Apple.

O mlx-dspark é a primeira versão nativa para chips Apple dessa tecnologia.

A ideia do DSpark é emparelhar um modelo menor para ajudar o modelo alvo: o modelo menor primeiro gera algumas palavras candidatas de uma vez, e o modelo alvo verifica todas de uma vez, aceitando as corretas e rejeitando as erradas para retentar.

O custo disso é diferente entre data centers e Macs.

Em GPUs de data center, verificar um lote de candidatos é mais como alugar um ônibus: o preço é fixo independente de quantos passageiros. A decodificação já é limitada por memória, então verificar mais alguns tokens quase não gasta tempo extra.

Em chips Apple, é mais como um táxi com taxímetro: quanto mais candidatos para verificar, mais o taxímetro sobe.

Rahim testou e, para o Gemma-4 12B, cada token extra verificado gasta cerca de 14 ms. Ele transformou essa conta em um modelo de custo e concluiu que o teto de velocidade em chips Apple é cerca de 2,2x.

Em resumo, Rahim trouxe o modelo menor dos checkpoints do HuggingFace e o emparelhou com os dois modelos alvo: Gemma-4 12B e Qwen3-4B.

Ele também reimplementou o fluxo de verificação no framework MLX, com os pesos quantizados em 4-bit.

Resultado: no M4 Pro, comparado com a ferramenta oficial MLX da Apple, a velocidade de geração do Gemma-4 12B subiu de 18,4 tok/s para cerca de 30 tok/s, aproximadamente 1,6x; a do Qwen3-4B subiu de 52,9 tok/s para cerca de 73 tok/s, aproximadamente 1,4x.

Além disso, no mlx-dspark, Rahim fez algo que a maioria das portas não faz.

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

A maioria das versões que trazem modelos grandes para dispositivos locais só suporta decodificação gulosa, ou seja, escolher a palavra com maior probabilidade a cada passo.

Rahim, no mlx-dspark, implementou também o método de amostragem de temperatura descrito originalmente no artigo do DSpark: o modelo rascunho gera candidatos, a probabilidade de aceitação é min(1, p/q), e a parte não aceita é reamostrada do residual.

Ele mesmo verificou que a saída gerada por esse fluxo é estritamente igual à distribuição exata que o modelo alvo daria sob a mesma temperatura, não uma versão aproximada degradada.

A maioria das decodificações especulativas só faz versão gulosa porque verificar a correção do modo guloso é simples: comparação byte a byte.

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

A precisão do modelo alvo responsável pela verificação foi um problema que ele descobriu sozinho.

Se o modelo menor for emparelhado com o modelo alvo base (sem fine-tuning instrucional), apenas 47% das palavras candidatas passam na verificação; trocando para a versão com fine-tuning instrucional, essa taxa sobe para 82%.

Ele também testou trocar o modelo alvo para precisão bf16: o custo de verificação aumentou mais do que a taxa de aprovação, resultando em mais lentidão. Portanto, manter o modelo alvo em 8-bit é mais vantajoso.

O modelo menor responsável por gerar candidatos antecipadamente usa outra precisão.

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

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

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

Após o tweet, veio um comentário: Jian Chen, um dos autores do artigo do DFlash, perguntou se dava para testar o modelo da equipe deles.

DFlash é outra abordagem de decodificação especulativa proposta em um artigo do z-lab em maio deste ano. O líder da equipe de autores, Zhijian Liu, é professor assistente na UCSD e também cientista de pesquisa na NVIDIA.

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

Rahim agiu rapidamente.

Usando o script de portabilidade escrito pelo próprio Jian, ele conectou o gemma4-12B-it-DFlash publicado pelo z-lab ao modelo alvo Gemma-4 do mlx-vlm, no mesmo Mac, e fez uma comparação direta com o DSpark que acabara de testar.

Em tarefas de código e matemática, o DFlash teve comprimento de aceitação de decodificação em bloco de 5,95 a 6,20, velocidade de cerca de 36 tok/s, aproximadamente 2,1x, superando o DSpark.

Porém, o DFlash precisa 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. Na indústria, isso é chamado de "comprimento de aceitação", nem sempre preenchendo todos 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 é preenchido, e a vantagem do DFlash não se manifesta.

A cabeça Markov do DSpark existe justamente para lidar com esse mesmo problema: gerar um bloco inteiro de palavras em paralelo, mas as posições posteriores são calculadas independentemente, o que pode gerar incoerência. A cabeça Markov adiciona uma camada de dependência entre essas posições, corrigindo especificamente esse 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 ao pacote, e adicionou um parâmetro para ajustar manualmente o comprimento do bloco efetivo do DFlash: blocos curtos para conversas, blocos completos de 16 para código e matemática.

Assim, no mesmo Mac e no mesmo pacote, é possível realizar tarefas de conversa, código e matemática sem precisar alternar entre os projetos DSpark e DFlash.

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

Fonte: Quantum Bit

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

        O mercado tem riscos, invista com cautela. Este artigo não constitui aconselhamento de investimento pessoal e não considera os objetivos de investimento, situação financeira ou necessidades específicas de usuários individuais. Os usuários devem considerar se quaisquer opiniões, pontos de vista ou conclusões neste artigo são adequados à sua situação específica. Investir com base nisto é por conta e risco próprios.