Apple relance un débat matériel : rétro-ingénierie de l'Apple Neural Engine

Le Neural Engine M1 d'Apple fait de nouveau l'objet d'un examen attentif, malgré une interruption de trois ans du projet de pilote Linux créé pour le comprendre. Retrospectively Reverse-Engineering Apple's Neural Engine explique pourquoi cet accélérateur excellait avec les anciens réseaux neuronaux, mais peine face aux charges de travail des transformeurs actuels.

Eileen Yoon, ancienne contributrice d'Asahi Linux, est revenue sur ce travail abandonné après le changement de direction matérielle d'Apple. La M5 intègre un Neural Accelerator dans chaque cœur GPU tout en conservant un Neural Engine distinct à 16 cœurs. Cette combinaison remet en cause l'idée qu'un unique accélérateur à fonction fixe devrait prendre en charge les charges de travail d'IA générative croissantes d'Apple.

Il s'agit de bien plus qu'une analyse matérielle tardive. L'enquête relie les choix effectués pour les réseaux neuronaux convolutionnels de 2017, ou CNN, à la réponse d'Apple aux modèles de langage modernes. Les GPU exercent désormais une pression sur le Neural Engine autonome, car les transformeurs dépendent d'une planification souple et de mouvements de mémoire soutenus.

Un pilote M1 en sommeil est devenu une autopsie matérielle

Ce nouveau travail transforme un pilote Linux inachevé en récit de ce qu'Apple pensait initialement que l'apprentissage automatique deviendrait.

Yoon avait auparavant créé un pilote Linux ANE capable de communiquer avec le Neural Engine des puces M1. Le projet comprenait un module noyau, une bibliothèque en espace utilisateur, des tests et des liaisons Python. Il offrait une voie de contournement de l'abstraction logicielle publique d'Apple, sans pour autant rendre le matériel largement programmable.

Le projet est ensuite resté silencieux pendant trois ans. Yoon écrit que l'ANE semblait trop spécialisé pour justifier davantage de travail sur le pilote. Ouvrir son interface matérielle ne modifierait pas les opérations que son chemin de données fixe pouvait exécuter efficacement.

Cette distinction est importante. Un pilote conventionnel peut exposer des capacités déjà présentes dans le matériel. Il ne peut pas transformer un accélérateur de flux de données conçu pour un usage précis en processeur généraliste.

La rétrospective architecturale de Yoon pose donc une question différente de l'effort initial autour du pilote. Au lieu de demander comment Linux peut soumettre des tâches, elle examine le réseau de calcul, l'ordonnanceur, le système mémoire et le modèle d'exécution. Ces composants révèlent les hypothèses de charge de travail intégrées à la conception du M1.

L'enquête décrit 16 cœurs de calcul organisés autour d'un bloc central de mémoire locale. Chaque cœur contient des unités parallèles de multiplication-accumulation, ou MAC, qui multiplient les entrées et ajoutent les résultats à des accumulateurs. Ces opérations sous-tendent les convolutions, la multiplication matricielle et les produits scalaires utilisés par les mécanismes d'attention.

Les unités MAC n'expliquent pas à elles seules la spécialisation du Neural Engine. Les CNN comme les transformeurs nécessitent multiplication et accumulation. La différence décisive réside dans la manière dont les poids et les activations atteignent ces unités, restent disponibles et se déplacent dans la puce.

Apple a introduit son premier Neural Engine avec l'A11 Bionic en 2017. À cette époque, les réseaux neuronaux grand public étaient centrés sur la classification d'images, l'analyse faciale et d'autres charges de travail CNN denses. Ces réseaux présentaient des formes de tenseurs régulières et une réutilisation prévisible.

La M1 a hérité de cette lignée de conception lorsqu'Apple a introduit ses propres processeurs sur Mac. Son Neural Engine était optimisé pour des modèles compilés dont les dimensions et les schémas de déplacement étaient largement connus à l'avance. Cette spécialisation réduisait la latence et la consommation d'énergie pour les tâches prises en charge.

La rétrospective ne prétend pas que le Neural Engine M1 ne peut pas exécuter d'opérations de transformeur. Elle soutient que le flux de données environnant rend certains schémas de transformeurs inefficaces, notamment le décodage autorégressif. Ce processus génère un jeton à la fois tout en relisant à plusieurs reprises les poids du modèle et un cache d'attention grandissant.

Ce recadrage crée la tension centrale de l'article. Apple a conçu un moteur efficace en contraignant les mouvements de données autour d'une charge de travail attendue. L'IA moderne a modifié la charge de travail dominante plus rapidement qu'une architecture matérielle fixe ne pouvait évoluer.

La rétro-ingénierie de l'Apple Neural Engine révèle la véritable contrainte

La limitation déterminante du Neural Engine M1 n'est pas sa capacité arithmétique ; c'est le chemin que les données doivent emprunter autour de cette arithmétique.

Le pilote rétro-ingéniéré n'envoie jamais directement au matériel des commandes de haut niveau telles que CONV, MATMUL ou RELU. Le compilateur d'Apple a déjà converti ces opérations neuronales en descripteurs de tâches avant le début de l'exécution.

Un descripteur de tâche est un bloc structuré de données de configuration. Il programme des groupes de registres qui contrôlent les dimensions des tenseurs, les adresses mémoire, les fonctions d'activation, les dépendances et les transferts de données. Le pilote place le descripteur en mémoire, oriente le gestionnaire de tâches vers celui-ci et déclenche une « sonnette » matérielle.

Après cette soumission, le Neural Engine contrôle la tâche jusqu'à son achèvement. Il déclenche une interruption lorsque la tâche est terminée. Le processeur hôte ne dirige pas chaque instruction mathématique pendant l'exécution de l'opération.

Yoon conclut que l'ANE ne possède pas de jeu d'instructions au sens habituel du CPU ou du GPU. Ses descripteurs de tâches configurent un chemin de données spécialisé au lieu de fournir un programme arbitraire. Chaque descripteur représente un passage dans ce chemin de données.

La tâche commence par le chargement des registres de configuration. Des blocs de transfert dédiés déplacent ensuite les poids et les activations d'entrée de la mémoire principale vers des mémoires locales distinctes. Les cœurs de calcul effectuent des réductions, un post-traitement applique une activation, puis un autre bloc de transfert renvoie le résultat.

Cette séquence favorise les opérations à réutilisation prévisible. Une convolution peut appliquer le même ensemble compact de filtres appris à de nombreuses régions d'une image. L'accélérateur peut maintenir ses voies arithmétiques occupées sans récupérer à répétition un important nouvel ensemble de poids.

Le décodage des transformeurs modifie cet équilibre. Chaque nouveau jeton peut nécessiter de parcourir en flux une part substantielle des paramètres du modèle. L'arithmétique reste reconnaissable, mais le mouvement des données devient le coût limitant.

L'agencement du M1 aggrave le problème, car il sépare la mémoire utilisée pour les poids de la mémoire locale utilisée pour les tuiles d'activation. Yoon identifie environ 1 Mio de mémoire de noyau et 2 Mio de mémoire de tuiles dans cette conception. L'enquête soutient que l'architecture n'a pas été organisée pour réinterpréter efficacement comme des poids les tenseurs produits localement.

C'était une hypothèse raisonnable pour les modèles visés par Apple en 2017. L'inférence CNN traite généralement les poids appris comme des noyaux fixes et les activations comme des données circulant entre les couches. L'attention des transformeurs brouille cette distinction, car les valeurs produites durant l'exécution peuvent alimenter des opérations matricielles ultérieures.

Un cache clé-valeur illustre le problème. Le cache stocke les représentations des jetons précédents afin que le modèle puisse les réutiliser pendant la génération. Son contenu augmente à mesure que la conversation ou le document s'allonge, ce qui rend l'accès efficace à la mémoire de plus en plus important.

Les dimensions fixes des tenseurs ne constituent pas l'obstacle central. Une tâche compilée peut boucler sur une longueur de cache variable, et la surcharge de soumission des tâches peut rester faible. Le problème le plus difficile consiste à alimenter à répétition les données via des chemins conçus autour de la réutilisation des CNN.

C'est pourquoi les chiffres bruts d'opérations par seconde offrent une comparaison incomplète. Le débit arithmétique de pointe décrit la vitesse à laquelle le réseau MAC peut travailler dans des conditions favorables. Il ne révèle pas à quelle fréquence ces unités attendent des poids, des activations ou des résultats intermédiaires.

Des recherches indépendantes sont parvenues à une conclusion compatible depuis un angle différent. L'article de recherche Orion de 2026 décrit 20 contraintes rencontrées lors de la programmation de l'ANE par le biais d'interfaces privées. Ses auteurs identifient la compilation, l'agencement mémoire et le comportement numérique comme des obstacles pratiques.

Orion rapporte néanmoins des résultats significatifs avec les transformeurs. Sur une M4 Max, le système a produit plus de 170 jetons par seconde pour GPT-2 comptant 124 millions de paramètres. Il a également entraîné un modèle de 110 millions de paramètres pendant 1 000 étapes en 22 minutes.

Ces mesures montrent que l'ANE peut exécuter des charges de travail de modèles de langage. Elles n'établissent pas qu'il constitue la meilleure cible pour chaque grand modèle ou chaque étape de l'inférence. La distinction entre possibilité technique et adéquation architecturale reste essentielle.

Le logiciel public d'Apple maintient le matériel à distance

Les développeurs peuvent solliciter le Neural Engine via Core ML, mais Apple conserve le contrôle de la compilation, de la répartition et de l'envoi des charges de travail.

Apple expose principalement le Neural Engine via Core ML, son framework public de déploiement de modèles d'apprentissage automatique. Les développeurs fournissent un modèle compatible, tandis que le framework décide si chaque opération doit utiliser le CPU, le GPU ou le Neural Engine.

Les contrôles des unités de calcul d'Apple permettent à une application d'autoriser des combinaisons de ces processeurs. Un développeur peut autoriser toutes les unités disponibles ou exclure le GPU ou le Neural Engine. L'interface publique ne propose pas de programmation directe des descripteurs de tâches de l'ANE.

Ce modèle protège la portabilité entre les appareils Apple. Une application peut décrire la prédiction dont elle a besoin sans encoder la disposition des registres d'une génération particulière de puces. Apple peut réviser ses compilateurs et ses politiques de planification tout en conservant une interface applicative stable.

Le compromis est la visibilité. Les développeurs ne peuvent pas compter sur Core ML pour placer chaque opération prise en charge sur un moteur précis. Ils ne peuvent pas non plus inspecter le programme final de bas niveau avec le niveau de contrôle attendu des API de calcul GPU.

Apple explique que l'exécution de Core ML peut utiliser le CPU, le GPU et le Neural Engine tout en réduisant la consommation de mémoire et d'énergie. Cette approche convient aux applications cherchant une inférence efficace sur l'appareil sans réglage spécifique au matériel.

Elle est moins satisfaisante pour les chercheurs qui étudient les limites architecturales. Un benchmark peut se replier sur un autre processeur, répartir un graphe entre plusieurs processeurs ou rencontrer des transformations de compilateur qui masquent le comportement matériel sous-jacent.

Le travail de rétro-ingénierie réduit une partie de cette incertitude. Il examine les descripteurs de tâches, les écritures de registres, les files d'attente, les interruptions et les chemins mémoire sous Core ML. Cette vue aide à distinguer les restrictions imposées par le logiciel des contraintes créées par le silicium.

Cependant, les interfaces privées créent leur propre incertitude. Elles ne bénéficient pas des garanties de compatibilité publique d'Apple et peuvent changer lors d'une mise à jour du système d'exploitation. Un code de recherche fonctionnant aujourd'hui pourrait échouer après une modification du compilateur, du format de modèle ou du service d'exécution.

Cet écart place Apple dans une position inhabituelle. L'entreprise livre du matériel spécialisé pour l'apprentissage automatique sur ses téléphones, tablettes, Mac et casques. Pourtant, les développeurs indépendants disposent d'un contrôle limité sur l'un des blocs les plus distinctifs intégrés à ces processeurs.

Pour les applications grand public, cette limitation peut relever d'un choix de produit intentionnel. Apple optimise l'appareil dans son ensemble et décide où chaque opération s'exécute. La plupart des développeurs tirent davantage profit d'un déploiement prévisible que d'un accès direct aux registres.

Les développeurs d'IA générative ont souvent besoin de l'inverse. Ils expérimentent des formats de quantification, des noyaux d'attention, des agencements de cache et des opérations fusionnées. Ils comparent également les performances entre des architectures de modèles en évolution rapide.

Les GPU permettent cette expérimentation parce que leurs modèles de programmation exposent un calcul plus généraliste. Les développeurs peuvent implémenter de nouveaux kernels sans attendre un parcours de compilation dédié. En contrepartie, ils doivent davantage gérer la synchronisation, les accès mémoire et l’optimisation des performances.

Le Neural Engine autonome représente l’autre extrémité de ce spectre. Son compilateur et son chemin de données fixe peuvent assurer une exécution efficace lorsqu’un modèle lui convient. Lorsque la charge de travail évolue, cette spécialisation devient une contrainte plutôt qu’un avantage.

La stratégie logicielle d’Apple empêche les développeurs de résoudre directement cette tension. Core ML peut masquer les variations matérielles, mais il ne peut pas faire en sorte qu’un système mémoire orienté CNN se comporte comme un GPU flexible. La rétro-ingénierie révèle la limite que le framework dissimule habituellement.

Le M5 fait du GPU le principal rival

Le M5 d’Apple ne supprime pas le Neural Engine autonome, mais il confère au GPU un rôle plus direct dans la feuille de route IA de l’entreprise.

Apple a annoncé le M5 en octobre 2025, avec un GPU à 10 cœurs intégrant un Neural Accelerator dans chaque cœur. La puce conserve également un Neural Engine amélioré à 16 cœurs. Cette conception place du matériel matriciel spécialisé des deux côtés du débat architectural.

Selon l’annonce de la puce M5 d’Apple, le nouveau GPU offre plus de quatre fois les performances de calcul IA maximales du GPU M4. Apple a également porté la bande passante de la mémoire unifiée à 153GB/s, soit près de 30 % de plus que le M4.

Il s’agit de mesures contrôlées par Apple, et les détails de la charge de travail déterminent les performances réelles des applications. Pourtant, l’emplacement des nouveaux accélérateurs est plus révélateur que ce multiplicateur mis en avant. Apple les a placés dans des cœurs GPU programmables au lieu de s’appuyer uniquement sur le Neural Engine séparé.

Le GPU combine une exécution matricielle spécialisée avec un environnement déjà adapté aux algorithmes changeants. Apple indique que les développeurs peuvent programmer les Neural Accelerators via des API tensor dans Metal 4. Cela ouvre une voie publique vers des charges de travail IA sur GPU sans exposer le format de commande privé de l’ANE autonome.

Yoon interprète ce changement comme le début de la fin pour le NPU autonome, ou unité de traitement neuronal. La formulation est volontairement provocatrice, et les décisions produit d’Apple ne confirment pas encore un abandon effectif.

Le M5 intègre toujours un Neural Engine séparé. Apple le décrit comme plus rapide et l’associe à des fonctions système, notamment le traitement de photos et la génération de Persona spatiale. Ces tâches ressemblent aux charges d’inférence délimitées et prévisibles que les accélérateurs dédiés gèrent efficacement.

La conclusion la plus défendable est plus limitée. Apple considère désormais le GPU comme une destination principale pour les charges de travail exigeantes d’IA générative, tandis que le Neural Engine conserve un rôle dans l’inférence système efficace.

Cette répartition correspond aux éléments issus de la rétro-ingénierie. Un GPU peut combiner accélération matricielle, opérations mémoire flexibles, kernels généralistes et accès direct des développeurs. Un NPU à fonction fixe peut réduire les surcoûts pour des graphes stables aux schémas d’exécution connus.

Aucune de ces conceptions ne l’emporte pour toutes les charges de travail. Un processeur généraliste consacre de la surface et de l’énergie à une flexibilité qu’un pipeline fixe évite. Un moteur spécialisé perd en adaptabilité lorsque les modèles exigent de nouveaux schémas de déplacement des données.

Le M5 suggère qu’Apple veut les deux. Son Neural Engine séparé peut prendre en charge des fonctions établies sur l’appareil, tandis que les GPU Neural Accelerators ciblent les modèles dont les opérateurs et le comportement mémoire continuent d’évoluer.

Cette stratégie hybride met aussi sous pression la pile logicielle d’Apple. Core ML doit choisir entre des processeurs de plus en plus capables. Metal doit donner aux développeurs suffisamment de contrôle pour tirer parti des nouvelles unités GPU. Le compilateur doit éviter de déplacer des données entre processeurs si souvent que les coûts de transfert annulent l’accélération.

La pression ne se résume donc pas à Nvidia contre Apple, ou macOS contre Linux. Il s’agit d’une compétition au sein même du silicium d’Apple entre l’efficacité des fonctions fixes et l’accélération programmable.

Cette compétition a commencé bien avant l’IA générative. Les puces d’Apple répartissent déjà le travail entre CPU, GPU, moteurs multimédias, processeurs d’image et matériel de sécurité. La différence est aujourd’hui que la conception des modèles IA évolue à un rythme qui rend les longs cycles de planification matérielle particulièrement risqués.

Un bloc dédié peut demander des années de conception et de validation. Les architectures Transformer, les variantes d’attention et les techniques de quantification peuvent évoluer en quelques mois. Intégrer une accélération plus adaptable au GPU réduit le coût d’un mauvais pari.

La rétro-ingénierie ne prouve pas que le Neural Engine est terminé

Cette rétrospective explique une inadéquation architecturale, mais elle ne peut pas établir le plan produit futur d’Apple ni mesurer chaque implémentation plus récente de l’ANE.

Les conclusions les plus approfondies concernent la génération M1. Apple a depuis commercialisé plusieurs familles de processeurs, et les détails internes peuvent changer sans documentation publique. Les conclusions sur les puces ultérieures nécessitent des mesures directes plutôt qu’une similitude visuelle ou des noms marketing.

Yoon reconnaît l’incertitude entourant certaines parties de l’analyse de la disposition physique. Les images du die peuvent révéler les principaux blocs mémoire et les structures de calcul répétées, mais elles n’expliquent pas chaque décision de routage. Certaines conclusions restent des interprétations éclairées.

L’enquête se concentre également sur la structure matérielle plutôt que sur un benchmark complet d’applications. Elle montre pourquoi le mouvement des données devrait limiter certaines charges de travail. Elle ne compare pas chaque modèle sur l’ANE, le GPU et le CPU avec des limites de puissance identiques.

Orion fournit des mesures récentes utiles, mais il utilise des API privées et des logiciels de recherche. Ses expériences avec GPT-2 et TinyStories démontrent l’accès et les capacités, non une maturité de production généralisée pour les modèles de langage actuels de grande taille.

Un autre projet ouvert a signalé un entraînement direct via des interfaces privées rétro-ingéniérées. Ses mesures sur M4 situent le débit FP16 autour de 18,6 billions d’opérations par seconde et le débit INT8 autour de 35,1 billions d’opérations par seconde. Ces chiffres dépendent de configurations de convolution sélectionnées et ne doivent pas être généralisés à des modèles complets.

La maturité logicielle compte autant que le matériel. Un compilateur très optimisé peut restructurer les graphes, fusionner les opérations et réduire les transferts. Un pilote de recherche peut exposer correctement le moteur tout en laissant une grande partie des performances inutilisée.

Le risque inverse s’applique également. Les microbenchmarks de pointe peuvent maintenir les unités arithmétiques occupées dans des conditions idéales tout en masquant les véritables goulets d’étranglement des modèles. La latence de bout en bout, l’utilisation mémoire, la consommation énergétique et le temps de compilation déterminent si un accélérateur aide une application.

Apple pourrait aussi redéfinir le Neural Engine autonome tout en conservant son nom de produit. Une mémoire partagée plus grande, des chemins de données révisés ou de nouveaux formats de tâches pourraient résoudre les limites constatées sur le M1. L’annonce du M5 ne révèle pas ce niveau de détail.

La sécurité constitue une autre raison de contrôler l’accès. Apple utilise le matériel Neural Engine dans des flux biométriques protégés. Sa documentation sur la sécurité de la plateforme décrit des réinitialisations d’état et des contrôles mémoire permettant un fonctionnement sécurisé du Neural Engine sur les systèmes plus récents.

Ce rôle n’exige pas d’ouvrir ce même matériel à des charges de travail Linux arbitraires. Il signifie également que la présence continue de ce bloc peut refléter une architecture système allant au-delà des modèles de langage grand public.

L’efficacité énergétique demeure une autre comparaison manquante. Le décodage autorégressif peut fonctionner plus naturellement sur du matériel GPU programmable, mais un moteur dédié peut toujours le surpasser pour les tâches de vision, d’audio et de classification. Apple vend des appareils alimentés par batterie, où ces économies importent.

L’affirmation crédible n’est donc pas que le Neural Engine est mort. C’est que ses hypothèses de conception initiales ne couvrent plus l’ensemble des charges de travail IA stratégiquement importantes.

Cette distinction permet à Retrospectively Reverse-Engineering Apple's Neural Engine de rester ancré dans les preuves. Le projet éclaire une bifurcation architecturale, tandis que les sorties produit d’Apple détermineront jusqu’où l’entreprise suivra l’une ou l’autre voie.

Trois signaux indiqueront quelle architecture l’emporte

Les prochaines API, benchmarks et dispositions de puces d’Apple révéleront si le Neural Engine du M1 était un modèle durable ou une branche spécialisée.

Le premier signal est l’accès des développeurs aux Neural Accelerators du GPU du M5. Metal 4 doit exposer des opérations tensor utiles sans masquer une part si importante de l’ordonnancement que les chercheurs se retrouvent face à une nouvelle boîte noire.

Des outils fonctionnels renforceraient l’idée qu’Apple a choisi l’accélération GPU programmable pour les modèles en évolution rapide. Des API limitées ou une prise en charge restreinte des opérateurs affaibliraient cette interprétation et préserveraient un rôle plus important pour le matériel géré par Core ML.

Le deuxième signal est la performance de bout en bout sur des charges de travail Transformer représentatives. Les comparaisons utiles doivent inclure le traitement des prompts, la génération de tokens, le comportement mémoire avec de longs contextes, la consommation d’énergie et le temps de chargement des modèles.

Les microbenchmarks ne suffiront pas à trancher. Un processeur peut dominer en débit matriciel tout en perdant du temps dans les transferts de poids, les mouvements de cache ou la compilation de graphes. Les mesures devraient également indiquer quelle unité de calcul a exécuté chaque opération.

Les résultats d’applications M5 seront particulièrement importants. Les modèles de langage locaux et les logiciels de diffusion peuvent tester les nouveaux accélérateurs GPU dans les charges de travail qu’Apple a explicitement mises en avant. Des gains constants valideraient l’orientation vers une accélération au sein de cœurs programmables.

Le troisième signal est l’architecture du prochain Neural Engine autonome d’Apple. Apple peut conserver l’étiquette de 16 cœurs tout en modifiant sous celle-ci la taille de mémoire, les interconnexions, l’ordonnancement et les précisions prises en charge.

Un système de mémoire locale repensé remettrait en cause l’idée que le bloc autonome approche de sa fin. Des changements minimes, combinés à des investissements GPU plus importants, conforteraient l’interprétation de Yoon.

Les progrès sous Linux offrent une voie de vérification secondaire. La communauté Asahi possède une vaste expérience de la documentation du silicium Apple par l’observation et l’expérimentation en salle blanche. Ses travaux de rétro-ingénierie ont déjà produit des pilotes ouverts pour d’autres blocs non documentés.

Un pilote ANE utilisable permettrait aux chercheurs de comparer les choix de Core ML à une soumission directe de tâches. Il pourrait également révéler si des compilateurs alternatifs peuvent récupérer des performances que le framework public d’Apple laisse inaccessibles.

Toutefois, la prise en charge de Linux ne doit pas être confondue avec l’issue commerciale principale. Le pilote importe parce qu’il transforme le comportement matériel caché en preuves testables. Les appareils, frameworks et charges de travail d’Apple détermineront l’avenir de cette architecture.

Les développeurs devraient observer où Apple place une nouvelle programmabilité publique. Ils devraient également distinguer le débit théorique des performances complètes d’une application. Le processeur affichant le plus grand chiffre phare n’est pas nécessairement celui qui déplace les données du modèle le plus efficacement.

Les équipes menant des investigations techniques similaires ont besoin d’un registre durable des expériences, résultats de registres, benchmarks et hypothèses écartées. Une base de connaissances d’ingénierie consultable peut préserver les liens entre ces éléments lorsque les outils et les générations de puces changent.

Retrospectively Reverse-Engineering Apple's Neural Engine saisit finalement un moment rare où un ancien silicium explique une nouvelle stratégie. Le M1 montre les avantages et les coûts d’inscrire des hypothèses CNN dans le matériel. Le M5 montre qu’Apple ajoute de la flexibilité sans abandonner immédiatement la spécialisation.

La prochaine question est concrète : les futures puces Apple étendront-elles l’accélération GPU programmable tout en réservant le Neural Engine aux tâches système stables, ou Apple reconstruira-t-elle le bloc autonome pour les Transformers ? Surveillez les API et le comportement mémoire, pas seulement le chiffre TOPS.