Les nouvelles technologies de DeepSeek transplantent sur les puces Apple ! Accélération de 60 % des grands modèles locaux sur Mac.

DSpark vient d'être open source depuis une semaine, et il a déjà été porté sur les ordinateurs Apple.

La version portée s'appelle mlx-dspark, et elle exécute les modèles Gemma-4 12B et Qwen3-4B.

Une fois installée, la vitesse de génération de ces deux modèles sur Mac a été respectivement multipliée par 1,6 et 1,4.

Plus difficile encore, elle a réalisé une chose que la plupart des versions portées ne peuvent pas faire : la sortie est identique octet par octet au modèle original, sans la moindre différence.

C'est-à-dire que la vitesse a été améliorée, sans aucune perte de qualité.

La personne derrière cela est Abdur Rahim, un ingénieur qui bricole des projets open source pendant son temps libre. Il a créé la première version native Mac de DSpark depuis son ouverture.

Les ordinateurs Apple exécutent des grands modèles, avec une accélération de 60 %

Pour DSpark, open sourcé par DeepSeek le 27 juin, les chiffres officiels indiquent une accélération de 60 % à 85 % dans les scénarios côté serveur.

Cependant, cette technologie n'était disponible à l'époque que sur les GPU des centres de données, sans version adaptée aux puces Apple.

mlx-dspark est la première version native pour puces Apple de cette technologie.

L'idée de DSpark est d'associer un modèle plus petit pour assister le modèle cible : le petit modèle génère d'abord plusieurs mots candidats, puis le modèle cible les vérifie en une fois, accepte les bons et renvoie les mauvais pour une nouvelle estimation.

Le coût de cette étape diffère entre un centre de données et un ordinateur Apple.

Sur les GPU des centres de données, vérifier un lot de mots candidats revient à louer un bus : le prix est fixe quel que soit le nombre de passagers. Le décodage étant déjà un goulot d'étranglement mémoire, vérifier plusieurs mots supplémentaires ne prend presque pas de temps supplémentaire.

Les puces Apple ressemblent plutôt à un taxi au compteur : plus on vérifie de mots candidats, plus le compteur augmente.

Rahim a mesuré que pour Gemma-4 12B, chaque token supplémentaire vérifié coûte environ 14 millisecondes. Il a transformé ces calculs en un modèle de coûts, concluant que le plafond de vitesse sur puces Apple est d'environ 2,2 fois.

En résumé, Rahim a transféré ce petit modèle d'assistance depuis le checkpoint HuggingFace et l'a associé respectivement aux modèles cibles Gemma-4 12B et Qwen3-4B.

Il a également reconstruit le processus de vérification dans le framework MLX, en quantifiant les poids en 4 bits.

Résultat, sur un M4 Pro, par rapport à l'outil MLX officiel d'Apple, la vitesse de génération de Gemma-4 12B est passée de 18,4 tok/s à environ 30 tok/s, soit environ 1,6 fois ; celle de Qwen3-4B est passée de 52,9 tok/s à environ 73 tok/s, soit environ 1,4 fois.

De plus, dans mlx-dspark, Rahim a également fait une chose que la plupart des travaux de portage n'ont pas faite.

La version portée peut également restituer avec une haute précision

La plupart des versions qui portent de grands modèles en local ne supportent que le décodage glouton, c'est-à-dire choisir à chaque étape le mot avec la probabilité la plus élevée.

Dans mlx-dspark, Rahim a également implémenté la méthode d'échantillonnage par température décrite dans l'article original de DSpark : le modèle de brouillon fournit des mots candidats, la probabilité d'acceptation est min(1, p/q), et les parties non acceptées sont rééchantillonnées à partir du résidu.

Il a lui-même vérifié que la sortie de ce processus est strictement égale à la distribution précise que le modèle cible produirait à la même température, et non une version approximative dégradée.

La plupart des décodages spéculatifs ne font que la version gloutonne, car vérifier l'exactitude du mode glouton est simple : une comparaison mot à mot.

L'étape supplémentaire de Rahim a consisté à vérifier lui-même la distribution de sortie produite en mode d'échantillonnage, confirmant qu'elle n'était pas déformée.

La précision à associer au modèle cible chargé de la vérification est un piège qu'il a lui-même découvert.

Si le petit modèle est associé à un modèle cible de base non affiné par des instructions, seulement 47 % des mots candidats générés passent la vérification ; en passant à la version affinée par instructions, ce taux augmente à 82 %.

Il a également testé le remplacement du modèle cible par une précision bf16, ce qui a augmenté le coût de vérification plus que le taux de passage, rendant le processus plus lent. Donc, le plus avantageux est de laisser le modèle cible par défaut en 8 bits.

Le petit modèle chargé de générer les mots candidats utilise un autre jeu de précisions.

Le modèle de brouillon lui-même a été compressé : après quantification en 4 bits, il ne fait que 1,8 Go, ce qui permet de le charger en mémoire sans problème, et son exécution reste sans perte.

Le résultat est que DSpark a non seulement accéléré, mais a également reproduit sur l'appareil l'augmentation du taux d'acceptation de 16 % à 18 % mentionnée dans l'article.

DFlash a également été intégré, accélérant les tâches de code

Après la publication du tweet, un commentaire est apparu dans la section des commentaires : Jian Chen, l'un des co-auteurs de l'article DFlash, a demandé s'il était possible d'essayer le modèle de leur équipe.

DFlash est une autre méthode de décodage spéculatif proposée dans un article publié par z-lab en mai de cette année. Le chef de l'équipe d'auteurs est Zhijian Liu, professeur assistant à UCSD et également chercheur scientifique chez NVIDIA.

L'idée de DFlash est différente de celle de DSpark : elle utilise un « bloc de diffusion » parallèle pour débruiter un bloc entier de 16 tokens, plutôt que de deviner étape par étape avec des dépendances comme DSpark.

Rahim a rapidement agi.

En utilisant le script de portage écrit par Jian lui-même, il a connecté le gemma4-12B-it-DFlash publié par z-lab au modèle cible Gemma-4 de mlx-vlm, sur le même Mac, et a effectué une nouvelle comparaison directe avec son DSpark qu'il venait de tester.

Pour les tâches de code et de mathématiques, la longueur d'acceptation du décodage par blocs de DFlash peut atteindre 5,95 à 6,20, avec une vitesse d'environ 36 tok/s, soit environ 2,1 fois, surpassant DSpark.

Cependant, DFlash doit générer un bloc entier de 16 tokens en une fois, mais le modèle cible peut ne pas tous les accepter. Seule une partie est réellement vérifiée, ce que l'industrie appelle « longueur d'acceptation » ; le bloc n'est pas toujours complètement rempli à 16.

Ainsi, dans des scénarios de chat ouverts où le contenu est difficile à prédire, la longueur d'acceptation n'augmente pas, le bloc n'est pas rempli, et l'avantage de DFlash ne se manifeste pas.

La tête Markov de DSpark existe justement pour résoudre ce même problème : en générant un bloc entier de mots en parallèle, les positions ultérieures sont calculées indépendamment, ce qui peut entraîner un manque de cohérence. La tête Markov ajoute une couche de dépendance entre ces positions, corrigeant précisément ce problème.

Le résultat est que, dans les scénarios de chat, DSpark est en fait plus rapide que DFlash.

La mise à jour suivante, mlx-dspark v0.0.3, a officiellement intégré le DFlash original de z-lab dans le package, et a ajouté un paramètre permettant de réduire manuellement la longueur de bloc effective de DFlash : utiliser des blocs courts pour les scénarios de chat, et des blocs complets de 16 pour les tâches de code et de mathématiques.

Ainsi, sur le même Mac et dans le même package, il est possible d'effectuer à la fois des tâches de chat et des tâches de code/mathématiques, sans avoir à basculer entre les deux projets DSpark et DFlash.

Rahim a déclaré dans son tweet que la même méthode devrait également fonctionner avec les modèles de brouillon plus grands Qwen3-8B et 14B.

Source : Quantum Bit

Avis de risque et clause de non-responsabilité

        Le marché comporte des risques, investissez avec prudence. Cet article ne constitue pas un conseil d'investissement personnel, et ne tient pas compte des objectifs d'investissement, de la situation financière ou des besoins spécifiques de chaque utilisateur. Les utilisateurs doivent déterminer si les opinions, points de vue ou conclusions de cet article correspondent à leur situation particulière. Les investissements effectués sur cette base sont de votre propre responsabilité.