FR
Sur Apple Silicon, les gains dépendent de la charge et du moteur d’exécution
Evaluating the Applicability of LLM Inference Optimizations on Apple Silicon · arXiv:2610.31479
En termes simples
L’article évalue quatre façons d’accélérer la génération de réponses par de grands modèles de langage sur Apple Silicon : réduire les informations mémorisées sur les jetons précédents, proposer des jetons à l’avance, modifier des opérations du GPU et réduire la précision des poids du modèle.
Les auteurs testent ces méthodes sur des charges de travail locales avec une seule requête à la fois et, lorsque c’est possible, comparent des configurations équivalentes. Les résultats varient.
Certaines méthodes ne sont utiles que dans des situations particulières, et aucune des six méthodes spéculatives n’a amélioré le débit de génération de la réponse complète dans la comparaison principale sur des conversations.
Les résultats suggèrent que la vitesse dépend de l’adéquation entre la méthode, l’appareil, le moteur d’exécution et la tâche.
La recherche
L’exécution locale sur Apple Silicon se déroule avec un matériel, un logiciel et un mode de traitement d’une seule requête différents de ceux des GPU de serveurs sur lesquels de nombreuses accélérations ont été mesurées.
On ne sait donc pas si ces optimisations restent utiles dans ce contexte ni si leurs hypothèses correspondent toujours au travail demandé à l’appareil.
Les auteurs comparent quatre familles d’optimisations de l’exécution sur Apple Silicon et montrent que les gains dépendent de l’adéquation entre chaque méthode, le moteur d’exécution, le matériel et la charge de travail.
Les auteurs évaluent quatre familles en isolant différentes méthodes, en adaptant à Metal et MLX des mécanismes conçus pour les GPU, puis en mesurant les effets au niveau des noyaux et de l’exécution complète sur quatre appareils Apple. Ils ajoutent des comparaisons avec RTX 4090 lorsque les configurations concordent.
Les résultats varient selon la méthode et la charge de travail : l’élagage peut réduire la latence de Qwen3-4B lors d’exécutions avec de longues invites, mais le décodage spéculatif n’a pas augmenté le débit de réponse complète dans la principale comparaison de conversations locales.
Les changements de noyau et la quantification ont aussi produit des gains circonscrits, ce qui étaye la conclusion des auteurs : la transférabilité dépend de l’adéquation entre la méthode, le moteur d’exécution, le matériel et la charge de travail.
Ces mesures de performance portent sur les charges de travail locales testées. Les expériences d’élagage n’ont pas évalué la qualité des réponses, l’étude exploratoire du méganoyau portait sur un seul modèle et une seule puce Apple, et le traitement de plusieurs requêtes à la fois n’a pas été testé.
Ce que montrent les preuves
- La question de la transférabilité
Cet article évalue empiriquement quatre familles d’optimisations de l’exécution de grands modèles de langage sur Apple Silicon. Les auteurs cherchent à savoir si des méthodes mesurées dans d’autres contextes restent utiles pour une exécution locale avec une seule requête à la fois, où le matériel, le moteur d’exécution et la charge de travail diffèrent.
Ils isolent les méthodes, adaptent des mécanismes conçus pour les GPU à Metal et MLX, puis mesurent leurs effets au niveau des noyaux et de l’exécution de bout en bout sur quatre appareils Apple.
- L’élagage a ses conditions
Le KV cache mémorise des informations sur les jetons précédents afin d’éviter de les recalculer. Son élagage peut réduire la latence, mais son effet dépend de la charge de travail : lors d’une génération Qwen3-4B avec une longue invite et une longue réponse, une méthode a réduit la latence sur les appareils Apple, tandis que le résultat correspondant sur RTX 4090 est resté juste sous la référence.
Une autre méthode d’élagage est restée plus lente dans toutes les configurations rapportées, ce qui montre que réduire le cache ne garantit pas une exécution plus rapide.
- La rédaction ne gagne pas dans le test principal
Le décodage spéculatif propose des jetons possibles pour la suite, que le modèle cible vérifie. Dans la comparaison principale, aucune des six méthodes n’a amélioré le débit de génération de la réponse complète par rapport à sa propre référence de génération ordinaire sur M2 Pro ou M3 Ultra.
La comparaison portait sur des invites de conversation locales et une seule requête à la fois. D’autres configurations ont montré des gains : le résultat décrit donc la charge de travail principale testée, et non tous les appareils Apple ni tous les usages de la spéculation.
- Les noyaux conviennent à certaines phases
Les résultats sur les noyaux montrent pourquoi les hypothèses d’une méthode comptent. Un noyau personnalisé qui rassemble les poids des experts a amélioré les performances de bout en bout sur les quatre machines Apple testées lors du décodage avec un seul jeton à la fois, car la planification par groupes n’a alors aucun groupe utile à traiter.
Sur M4 Pro, l’implémentation des auteurs fondée sur des opérations matricielles groupées était plus lente que l’opération standard pendant le traitement de l’invite, phase où la condition préalable au regroupement est bien présente. Le même noyau ne convient donc pas à toutes les phases.
- La quantification varie selon la puce
Réduire la précision des poids GGUF de 8 bits à 4 bits a augmenté le débit de décodage sur les deux puces Apple testées, mais le gain relatif était plus important sur M2 Pro que sur M3 Ultra.
Avec les résultats variables de l’élagage, de la spéculation et des noyaux, cela étaye l’interprétation des auteurs : les accélérations dépendent de l’adéquation entre la méthode, le moteur d’exécution, le matériel et la charge de travail, et non de la méthode seule.
Détails
- Auteurs de l’article original
- Kyrylo Yemets, Andrii Yaroshevych, Victor Muryn, Ostap Khomenko, Pavlo Kryven
- Soumis à arXiv
- Licence
- CC BY 4.0