Coucou Amazon, coucou NVIDIA

Alors qu’AWS vient de lancer son TorchNeuron pour permettre aux entreprises intéressées d’entrainer leurs modèles sur les puces maison Trainium, Google a fait une annonce similaire avec TorchTPU. Comme le nom l’indique, il s’agit cette fois d’orienter les calculs vers les puces TPU fournies par Google. Celle-ci met cependant en avant son partenariat avec Meta pour PyTorch.

Google propose désormais sa propre pile logicielle permettant d’exécuter PyTorch directement sur ses TPU, sans passer par une couche d’adaptation. L’annonce, faite durant la PyTorch Conference 2026, suit de près celle d’Amazon Web Services avec son TorchNeuron.

• Avec TorchNeuron, Amazon veut faciliter l’entraînement des modèles sur ses puces Trainium

Rappelons que PyTorch est une bibliothèque permettant, entre autres, de construire et d’entrainer des modèles IA. Comme nous l’indiquions dans notre actualité sur TorchNeuron, PyTorch a besoin d’une couche intermédiaire pour traduire les opérations en instructions reconnues par le matériel. Dans la grande majorité des cas, cette couche est CUDA, une technologie propriétaire que NVIDIA travaille depuis longtemps pour s’assurer que tous types de calculs pourront être exécutés sur ses GPU.

• Pourquoi tout le monde se jette encore sur les GPU NVIDIA pour l’IA

Au tour des puces TPU

Si l’objectif d’AWS avec TorchNeuron était de pouvoir rediriger ces calculs facilement vers ses puces Trainium, Google fait maintenant de même avec ses TPU.

• Avec ses TPU Ironwood, Google passe à « l’ère de l’inférence »… avec de gros chiffres

Jusqu’à présent, pour exploiter ces puces dans le cloud de Google depuis PyTorch, il fallait passer par XLA, une solution que Google présente désormais comme peu naturelle. Le dépôt GitHub de XLA a d’ailleurs été mis à jour pour indiquer que le projet est à présent déprécié et remplacé par TorchTPU. Il sera archivé le 15 novembre, tout va donc aller très vite.

Le dépôt de TorchTPU est bien sûr déjà en ligne, le projet étant sous licence Apache 2.0 et donc open source. Deux modes d’exécution sont proposés. Le premier, eager, consiste à exécuter immédiatement le programme ligne par ligne, un cas jugé notamment utile pour chercher une erreur. Le second, torch.compile, analyse au contraire l’ensemble du programme avant de l’exécuter. TorchTPU permet de commencer avec le premier et de basculer dans le second si besoin.

Comme pour TorchNeuron, TorchTPU permet d’utiliser les puces de Google aussi bien pour l’entraînement que pour l’inférence. Google met largement en avant la compatibilité avec l’écosystème existant. TorchTitan, conçu pour répartir les calculs d’entraînement sur des milliers de puces, est par exemple de la partie. Selon Google, son fonctionnement a affiché une montée en charge linéaire jusqu’à 8 129 TPU. VeRL, pour l’apprentissage par renforcement, Ray, pour la répartition des étapes des chaînes de traitement, vLLM, un serveur faisant tourner les modèles de langage, ou encore SDLang et llm-d sont cités.

Pour Google, il s’agit d’un point clé dans son annonce. Cette logique de compatibilité apparait clairement dans plusieurs cas. Pour vLLM et SGLang par exemple, l’annonce précise que les ordonnanceurs, les modèles de travail et les serveurs d’API d’origine sont conservés, et que les piles d’inférence existantes peuvent être reprises telles quelles. Pour VeRL, le code des modèles et des algorithmes reste indépendant du matériel. Pour Hugging Face, également de la partie, un paramètre (device_map= »tpu ») suffit.

Le même goulot que chez Amazon

Les problématiques et les enjeux sont à peu près les mêmes que chez AWS. Google a tout intérêt à appuyer dans cette direction pour réduire la dépendance très présente de l’écosystème IA à NVIDIA. En réduisant autant que possible les frictions à utiliser les puces TPU, Google cherche donc à s’assurer une nouvelle place de choix dans l’entraînement des modèles comme dans leur inférence.

Il y a tout de même une différence notable dans TorchTPU : Meta participe directement au projet. Ayant créé PyTorch initialement (le projet est géré par la Linux Foundation depuis 2022), l’entreprise reste très impliquée dans son développement. Selon Digitimes, Meta est l’un des plus gros clients de NVIDIA. Elle chercherait donc activement à réduire sa dépendance, l’entreprise ayant également testé la location de capacité TPU auprès de Google Cloud.

Notez que Google, pas plus qu’Amazon, ne parle ouvertement de lutte contre NVIDIA. Mais il est difficile d’évoquer un PyTorch « plus indépendant » sans faire un clin d’œil à la firme de Santa Clara.

Alors que les élections de midterms approchent aux États-Unis (3 novembre), l’IA fait partie des sujets les plus importants dans la campagne électorale. L’installation des datacenters IA est notamment devenue un boulet électoral pour les républicains.

Jusque-là, Donald Trump faisait la sourde oreille et soutenait l’industrie de l’IA. Il a encore récemment enterré toute régulation de l’IA, misant sur la « responsabilité » des acteurs.

Le dirigeant états-unien a réagi ce mercredi 21 octobre à l’impopularité croissante de l’installation des datacenters IA. Il affirmé sur Truth Social : « J’ai imposé aux nouveaux centres de données, de grande taille, voire gigantesques dans certains cas, de produire leur propre électricité et de céder ou de vendre tout excédent à la communauté locale ou au réseau électrique, ce qui entraîne une hausse du prix de l’électricité. En fait, on pourrait assister à une baisse considérable. ».

Mais la réaction du leader du parti Républicain arrive bien tard. En effet, un nouveau sondage de l’Institut Ipsos pour le Washington Post et ABC News auprès de 2 545 Américains montre que 57 % d’entre eux pensent que l’IA est une mauvaise chose pour la société alors que 50 % pensent qu’elle est une bonne chose pour eux, personnellement.

Deux tiers des sondés estiment que le gouvernement fédéral des États-Unis ne régule pas assez l’IA alors qu’ils ne sont que 9 % à penser qu’il régule trop cette technologie.

Si l’industrie insiste régulièrement sur de supposés risques d’extinction des humains dus à l’intelligence artificielle, les sondés sont plus inquiets du piratage de la sécurité des systèmes informatiques, des capacités des utilisateurs à prendre leurs propres décisions et de la suppression des emplois et de la montée des inégalités économiques :

Quand on leur demande en quoi l’IA peut apporter de bonnes choses, les Américains interrogés citent d’abord à 34 % le fait qu’elle pourrait avoir de grandes chances de faciliter les tâches du quotidien plus facilement et accentuer la domination de leur pays dans le domaine. Ils ne sont que 20 % à penser qu’il y a de grandes chances qu’elle permette aux personnes d’être plus productives. De même, peu d’entre eux (13 %) pensent qu’il est fortement possible que l’IA permette la création de nombreux emplois :

Réécrivons tout en Rust

OpenAI a de nouvelles envies de conquête, cette fois dans le champ de ce qu’elle nomme « les langages à faibles ressources ». L’entreprise vise explicitement cette fois les vieux, voire très vieux langages, au premier rang desquels le COBOL. La promesse est de faire exploser le nombre de projets de migration grâce à ses soins.

Selon OpenAI, les dernières avancées de ses modèles ont renforcé leurs capacités à créer et à migrer des logiciels dans des langages comme COBOL, Fortran et Visual Basic. Des langages dits « à faibles ressources », car ils ont moins de code et de documentation pour entrainer les modèles que d’autres bien plus courants comme Python et JavaScript.

« COBOL fait fonctionner⁠ plus de 40 % des systèmes bancaires en ligne, 80 % des transactions par carte de crédit en personne et 95 % des transactions aux distributeurs automatiques », indique OpenAI, montrant l’ampleur du marché. Des chiffres familiers ? Nous avions les mêmes dans notre article de juillet 2025 consacré au COBOL et à sa présence toujours importante. Ils sont issus d’une enquête réalisée par Reuters en 2024. Dans notre article, nous montrions d’ailleurs que le langage restait vivant, mais qu’il y avait un déficit de développeurs formés à ce langage. Fortran, utilisé pour les prévisions météorologiques⁠ et l’analyse de sûreté des réacteurs nucléaires⁠, fait aussi partie des langages visés.

OpenAI dit avoir reçu de nombreux retours sur la difficulté à travailler avec l’IA sur ces langages. « La documentation peut être incomplète, les développeurs d’origine peuvent avoir quitté l’entreprise, et des règles métier importantes peuvent n’exister que dans le code », indique OpenAI. Autant de problématiques que nous avions abordées dans notre article.

OpenAI s’est fabriqué deux évaluations

L’entreprise souhaitait savoir si ses modèles avaient progressé. La question est presque rhétorique : le billet d’OpenAI est là pour montrer à quel point ses LLM ont justement progressé.

Pour les mesurer, OpenAI dit avoir créé deux évaluations. La première, MultiLang, vérifie si un modèle peut créer un moteur de base de données compatible avec SQLite dans 20 langages, en partant d’une page blanche. La seconde est une évaluation plus spécifique aux migrations COBOL pour vérifier si le modèle peut migrer des programmes existants en préservant leur comportement. En somme, l’une vérifie la création de nouveaux logiciels, tandis que l’autre s’assure que les migrations réussissent.

Sans surprise, OpenAI indique que les progrès de ses modèles sont « considérables ». Astra a ainsi atteint un score de 87,4 % sur le premier test en moyenne, contre 26,8 % pour GPT-5.6 Sol, avec des progrès sur l’ensemble des 20 langages. « GPT‑6 Luna surpasse également GPT‑5.6 Sol, atteignant 40,3 % pour un coût estimé de l’API inférieur d’environ 78 % », ajoute OpenAI.

Les règles particulières du COBOL

L’évaluation spécifique au COBOL est plus intéressante, car le problème initial est plus complexe. OpenAI rappelle ainsi que la réussite d’une migration dépend d’une pleine compréhension de la logique métier et des comportements propres au langage. « Par exemple, l’arithmétique à virgule fixe de COBOL supprime les décimales excédentaires, sauf si un arrondi est explicitement demandé. Une réécriture qui arrondit ces valeurs à la place peut s’exécuter sans erreur tout en produisant des résultats financiers différents », affirme l’entreprise.

La vérification se base sur des « tests cachés » qui exigent des sorties observables identiques, à l’octet près. La migration n’est considérée réussie que si tous les tests sont validés. Dans le cas présent, les projets en COBOL devaient être convertis en C++, Java, Kotlin, Python ou Rust.

Dans cette évaluation, GPT‑6.1 Sol a atteint 86,6 % d’exactitude avec un faible effort de raisonnement, contre à peine 5,4 % pour GPT‑5.6 Sol, le tout avec un coût inférieur de 39 %. OpenAI ajoute qu’avec un effort de raisonnement plus élevé (on ne connait pas l’effort de départ), le score grimpe à 97,9 %.

Le message est donc clair : on peut utiliser Astra et GPT-6.1 Sol pour migrer les projets ou en bâtir de nouveaux compatibles. Une conclusion qu’OpenAI met d’autant plus en avant que l’IA fait exploser depuis plusieurs mois les projets de réécriture, de nombreux développeurs (confirmés ou en herbe) se lançant notamment dans une course aux performances.

OpenAI ajoute toutefois que même si les résultats obtenus vont dans le bon sens, « leur application à des logiciels en production exige toujours une vérification par des experts et des tests tenant compte des règles métier et des dépendances du système ».

Des résultats à prendre avec des pincettes

Le principal problème de cette annonce est son opacité. C’est particulièrement vrai dans le cas de COBOL.

On ne sait pratiquement rien en effet de l’évaluation construite par OpenAI, alors que MultiLang a son dépôt GitHub. Rien sur le nombre de programmes, leur origine, leur taille ou même leur degré de ressemblance avec du COBOL réellement utilisé en production. L’évaluation étant opaque, elle ne peut pas être reproduite par des tiers indépendants et il faut donc croire OpenAI sur parole. Que les modèles progressent sur des langages comme COBOL ou Fortran ne fait pas de doute, mais il est difficile de se rendre compte de l’évolution concrète sur la seule base des affirmations d’OpenAI, les évaluations étant proposées par la même entreprise qui propose les modèles testés.

Notons également que les deux évaluations envisagent des tests très différents dans leur approche. SQLite est un projet présent depuis longtemps et aux nombreuses réimplémentations, des portages existant dans plusieurs des langages testés. Il n’est donc pas étonnant qu’un modèle récent s’en sorte bien, puisqu’il restitue en partie des connaissances présentes dans les données d’entraînement. À l’inverse, la situation est plus complexe pour COBOL, Fortran et d’autres anciens langages, les ressources étant nettement moins nombreuses.

Toujours des noms simples à prononcer

Mistral a lancé récemment deux modèles spécialisés, Voxtral 3 pour transcription et la synthèse vocale et Timestral pour les « séries temporelles ». Ce dernier doit permettre des prévisions sans réentrainement.

Mistral avait lancé son premier modèle Voxtral en juillet 2025. Il s’agissait alors de son premier modèle audio, que Mistral mettait en avant comme plus performant et moins cher que les solutions concurrentes. Plusieurs tailles étaient proposées, selon la durée des contenus audio que l’on souhaitait traiter.

Ce LLM spécialisé a beaucoup évolué, puisque la version 3 est maintenant disponible. La communication de Mistral braque largement les projecteurs sur les agents. Selon l’entreprise française, un agent vocal fiable doit ainsi maitriser quatre capacités : écouter avec précision, raisonner en profondeur sur ce que les utilisateurs veulent dans un contexte donné, parler naturellement et agir en plusieurs étapes.

Un SDK d’agents locaux

Voxtral 3 est la réponse de Mistral à ces quatre objectifs, dont un fonctionnement fiable et en temps réel « reste un défi ». Voxtral 3, comme le premier, désigne une famille de modèles spécialisés dans la reconnaissance et la synthèse vocales. Cette fois, elle est accompagnée d’un SDK (kit de développement logiciel) pour utiliser des agents locaux. Le SDK (bâti sur LiveKit) réunit dans un même pipeline de traitement l’écoute, la réflexion, l’appel d’outils et la parole.

La famille compte quatre modèles :

• Small Transcribe 3 : transcription groupée de meilleure précision, 50 langues, à 0,004 dollar la minute
• Mini Transcribe 3 : 4 milliards de paramètres, 0,0035 dollar la minute
• Mini Transcribe Realtime 3 : transcription en direct, latence revendiquée à moins de 500 ms, 0,008 dollar la minute
• Voxtral Speech 3 (ou Mini TTS 3.0) : synthèse vocale, plus de 35 langues et 50 dialectes, 13 dollars le million de caractères

Mistral vante l’émotion dans la voix pour « sonner naturellement » (prosodie, rythme, débit, accentuation et transitions), les performances en diarisation (reconnaître qui parle) et la prise en charge des biais contextuels. Pour ce dernier point, Mistral précise que l’on peut ainsi fournir des termes clés et du texte libre pour « orienter la transcription et améliorer le rappel des termes techniques ». L’entreprise ajoute le support de la prédiction de fin de tour, les modèles étant capables de prédire quand une personne a fini de parler, en se basant sur des informations acoustiques et sémantiques.

Selon l’annonce, les performances de ces modèles sont à « l’état de l’art », dépassant de nombreuses références du secteur, dont Whisper d’OpenAI. L’agent complet, lui, est facturé 0,04 dollar la minute avec Small et 0,08 dollar avec un autre modèle de raisonnement. L’accès se fait via l’API de Mistral ou depuis l’infrastructure sur site.

Signalons que les quatre modèles sont en préversion publique et que certaines informations manquent. Par exemple, la taille de Small n’est pas donnée. En outre, aucun poids ouvert n’a encore été annoncé. En revanche, les performances revendiquées par Mistral semblent confirmées par Artificial Analysis.

Timestral : c’est quoi des « séries temporelles » ?

Le 15 octobre, Mistral avait également lancé un autre modèle, Timestral, premier représentant d’une nouvelle famille de LLM. Il est spécialisé dans les séries temporelles, c’est-à-dire des séries de mesures datées (capteurs, consommation, flux financiers…), afin d’établir des prévisions.

Timestral est fourni en quatre tailles : 5, 28, 123 et 209 millions de paramètres. Le modèle peut prévoir les séries sans réentraînement sur des données spécifiques, produire des prévisions avec une fourchette d’incertitude (21 quantiles) et accepter jusqu’à 32 768 pas d’historique. Selon Mistral, il peut traiter plusieurs séries liées à la fois ainsi que des facteurs connus à l’avance (calendrier de production, météo, etc.).

Timestral fonctionne également sans carte graphique. Mistral annonce à ce sujet un temps allant de 10 à 140 ms pour prévoir une journée, en fonction de la taille du modèle utilisé, sur un « CPU de serveur standard avec 8 threads » et sur la base de trois semaines d’historique au pas de 15 min. Comme toujours avec la taille des modèles, plus elle est importante, plus la précision augmente et plus le temps de calcul s’allonge.

Le code du modèle est sous licence Apache 2.0. Cependant, comme relevé par Pix Geeks, les poids sont sous une licence MIT modifiée « qui exclut les entreprises dont le chiffre d’affaires mensuel consolidé dépasse 20 millions de dollars. Celles-là doivent demander une licence commerciale à Mistral ou passer par ses services hébergés ». Sous ce seuil, l’utilisation de Timestral est gratuite.

Coucou NVIDIA

Amazon Web Services a présenté un nouveau projet open source, TorchNeuron. Il se propose de simplifier le passage aux puces Trainium d’AWS pour entrainer les modèles. Bien que NVIDIA ne soit pas nommée, le projet est clairement pensé comme une alternative à CUDA.

PyTorch est initialement une bibliothèque logicielle créée par Meta (Facebook à l’époque). Depuis 2022, elle dépend de la Linux Foundation, tant elle est devenue importante. Elle sert en effet à construire et entraîner des modèles d’intelligence artificielle.

Cette bibliothèque est l’une des raisons pour lesquelles NVIDIA est autant sur le devant de la scène aujourd’hui. Entre PyTorch et le matériel utilisé pour les opérations, il faut justement une couche logicielle pour traduire les opérations en instructions que ce matériel peut comprendre. C’est précisément ce que fait CUDA depuis longtemps chez NVIDIA. Cette technologie propriétaire de type GPGPU (General-Purpose Computing on Graphics Processing Units) sert à faire basculer sur le GPU des calculs qui seraient autrement destinés au CPU.

Sans le dire aussi clairement, c’est ce lien fort qu’AWS veut remettre en question avec TorchNeuron, comme le relève notamment TechCrunch.

Direction les puces Trainium

Amazon Web Services dispose de ses propres puces en matière d’IA : les Trainium, dont la troisième génération a été lancée en décembre 2025. Ces puces peuvent servir aussi bien à l’entraînement qu’à l’inférence. Amazon n’est pas la seule entreprise à concevoir ses propres puces dans ce domaine : Microsoft possède Maia et Google a ses TPU (Tensor Process Units).

TorchNeuron est ainsi aux puces Trainium ce que CUDA est à NVIDIA, une couche de traduction. Elle s’appuie sur le mécanisme d’extension que PyTorch propose pour accueillir du matériel tiers et propose aux développeurs – dans le cas le plus simple – de remplacer dans leur code le périphérique cible cuda par neuron.

Est-ce aussi simple ? En théorie oui, mais l’exemple cité par AWS montre que la situation est plus complexe en pratique. Le billet évoque en effet le cas de Deepgram, un concurrent d’ElevenLabs dans le secteur de la synthèse vocale. Ainsi, non seulement certaines fonctions de PyTorch ne sont pas encore prises en charge, mais une partie des tests officiels de PyTorch est tout simplement ignorée, faute de traduction d’une partie des opérateurs de calcul. Deepgram est mis en avant comme ayant réussi à obtenir 70 % d’audio en plus pour chaque dollar dépensé, mais la mise en place de ce flux de travail a nécessité plusieurs mois de travail.

Boire au goulot

Officiellement, Amazon met en avant la réduction du coût de changement de puce pour les développeurs. Ces derniers seraient ainsi plus libres de comparer les options qui s’offrent à eux. Si l’on peut changer de puce sans pénalité particulière, les fabricants doivent mériter la clientèle, affirme même Amazon.

Auprès de TechCrunch, Colin Brace d’Annapurna Labs (la filiale qui conçoit les puces d’Amazon) met bien sûr en avant l’infrastructure et l’écosystème d’AWS. En outre, le responsable pointe la possibilité d’utiliser la même puce pour l’entraînement et l’inférence, avec à la clé la possibilité de réaffecter la capacité inutilisée.

La lutte contre la dépendance à NVIDIA s’inscrit en filigrane dans l’annonce, de manière plus ou moins intense selon les passages. L’un d’entre eux est cependant très clair : « L’approche d’Amazon va au-delà de son propre matériel. L’entreprise apporte des modifications en amont de PyTorch lui-même, en travaillant avec la communauté PyTorch pour supprimer le code liant le framework à des puces spécifiques. L’objectif est de rendre PyTorch plus indépendant du matériel pour toute la communauté des développeurs, pas seulement pour les utilisateurs de Trainium ». Une précision qui n’est pas tellement « pour » les utilisateurs de Trainium que « contre » NVIDIA, car cette dépendance peut signifier une configuration plus longue.

Cette lutte à peine voilée n’est pas le seul élément masqué. Sans même parler d’arracher les clients à un écosystème pour les plonger dans le sien, Amazon doit se débarrasser d’un goulot d’étranglement. L’intérêt des puces Trainium est en effet d’autant plus réduit que les clients ne peuvent pas les utiliser facilement. C’est ce goulot que NeuronTorch doit essayer de lever. AWS essaye donc de réaliser un coup double : réduire les spécificités de PyTorch pour CUDA et fluidifier l’accès à ses puces.

TorchNeuron est cependant un projet neuf. Le code est présenté sous licence Apache 2.0 (open source) dans un dépôt GitHub ouvert le 17 octobre, même si AWS annonce sa disponibilité pour le 20 octobre. Dans sa forme actuelle, le projet prend en charge les puces Trainium 2 et 3. Reste pour Amazon à concrétiser sa vision en alimentant son projet, dont le succès dépendra de l’adoption par les développeurs concernés.

La direction générale de l’administration et de la fonction publique (DGAFP) a présenté sa revue stratégique de la fonction publique à l’horizon 2035 - 2050. Parmi les « grandes transitions » que la fonction publique doit absorber, le numérique et l’IA figurent en bonne place, avec la transition démographique, la transition écologique ou encore l’instabilité sécuritaire croissante.

Le rapport consacre quatre pages au numérique et à l’IA, dans lesquelles la DGAFP fait notamment un constat problématique : si 82 % des démarches administratives peuvent aujourd’hui se faire en ligne, 44 % des personnes interrogées ont déclaré avoir des difficultés à les faire. La direction générale en conclut qu’un accueil humain, au guichet ou au téléphone, reste nécessaire, surtout pour les publics fragiles et les dossiers complexes. Elle ajoute que le numérique doit servir à dégager du temps pour l’accompagnement individualisé, pas à supprimer des postes d’agents de la fonction publique.

Le même rapport aborde la dépendance de l’État envers ses prestataires informatiques. Dans ce domaine, il reprend la recommandation de la Dinum (Direction interministérielle du numérique) d’un seuil minimal d’emploi interne de 37 %. Cependant, il le compare à la moyenne mondiale de 67 %, tous secteurs confondus.

Dans ce domaine, l’Espagne est érigée en exemple. Nos voisins ont ainsi mis en place un vaste plan de numérisation sur la période 2021 - 2025, doté d’un budget de 2,6 milliards d’euros. L’objectif sur 2026 était ensuite l’ouverture de 1 700 postes dans les corps de fonctionnaires du numérique. Des spécialités en IA, cybersécurité et science des données y apparaissent pour la première fois. Le rapport de la DGAFP préconise ainsi une forte réinternalisation des compétences.

L’exposition à l’IA, selon le rapport, varie très fortement selon les secteurs. Plus de la moitié des agents seraient très peu concernés, l’exposition se concentrant dans les fonctions administratives et de support. 20 % des agents seraient en revanche significativement exposés, soit 1,1 million de personnes.

Selon la DGAFP, « l’IA transformerait davantage les tâches que les métiers dans leur ensemble ». La direction générale estime que le temps libéré par l’IA devrait être réaffecté vers « l’expertise, le contrôle et la relation aux usagers ». Elle ajoute que des formations, mobilités voire reconversions devront être organisées. De plus, le déploiement de l’IA va « contribuer à une recomposition profonde des emplois et une évolution des modalités de recrutement pour privilégier l’esprit critique sur la capacité de synthèse, par exemple ».

Moi, moche et virtualisé

Apple a publié un article de recherche sur Minions, une infrastructure permettant d’agréger les ressources GPU inutilisées sur des grappes de Mac dotés de puce Apple Silicon. Si le concept n’a rien de nouveau, les travaux d’Apple prolongent l’existant et inscrivent un peu plus les Mac dans le paysage de l’IA.

Les Mac sont décidément appréciés par les entreprises désireuses de faire tourner localement des LLM plus ou moins gros. Pourquoi les Mac ? Parce qu’ils embarquent une mémoire dite « unifiée », servant à la fois pour les parties CPU et GPU des puces Apple Silicon. Si votre Mac est équipé de 32 Go de mémoire vive, le GPU peut puiser dedans. Cette mémoire est certes moins rapide que la VRAM des cartes graphiques dédiées (sans même parler de la HBM), mais ce scénario d’usage compense par le volume.

Apple sait que ses Mac Mini et Studio partent comme des petits pains auprès d’entreprises comme OpenAI, Anthropic et Meta. C’est dans ce contexte qu’elle a mis en ligne un document de recherche (prépublication sur Arxiv) exposant le fonctionnement de Minions, une infrastructure GPU virtuelle dédiée aux charges d’inférence d’apprentissage automatique à grande échelle.

Rassembler l’inaction

L’architecture proposée repose sur quatre éléments. D’abord, un serveur central reçoit les requêtes via une interface web ou des API (REST). Il s’occupe de les valider puis de les découper de manière asynchrone en sous-tâches stockées dans une base PostgreSQL. En d’autres termes, le serveur est chargé de créer une file d’attente.

Ensuite, les exécuteurs. Ils tournent sur les Mac mis à contribution et traitent localement les sous-tâches sur le GPU, avant d’écrire le résultat des calculs dans une zone de stockage S3. Ils n’accèdent jamais directement à la base PostgreSQL : ils réservent des sous-tâches en utilisant l’API du serveur, via une table de la base dotée d’une contrainte d’unicité. Même chose pour mettre à jour l’état de la base, envoyer leur signal de vie (un message bref envoyé au superviseur pour indiquer qu’il fonctionne encore) et livrer leurs résultats.

Le superviseur, justement, est ici nommé « Watchdog » (littéralement « chien de garde »). Son rôle est de surveiller les exécuteurs en cours de traitement et de remettre en file d’attente les sous-tâches des exécuteurs devenus muets. Ce silence peut provenir de multiples causes : perte réseau, veille, extinction, arrêt volontaire, etc. Ce fonctionnement autorise donc une certaine souplesse.

Quant au dernier composant, c’est tout simplement le tableau de bord pour le suivi de l’ensemble en temps réel.

De fortes limitations

Le tout permet, comme relevé par Apple Insider, de mettre à disposition la puissance inutilisée des GPU pour les mettre à contribution lors d’un travail d’inférence. Ainsi, des équipes qui lancent de grands lots asynchrones d’inférence (index de recherche, génération de texte en masse pour l’évaluation ou l’étiquetage…) n’ont plus besoin d’attendre qu’une grappe de GPU se libère. C’est du moins le fonctionnement sur le papier.

Si le document est intéressant dans le fond, il est aussi très court. Apple ne fournit aucune information mesurée : pas de tests de débits, pas de coût énergétique, de taux de reprise ou aucune comparaison quelle qu’elle soit. Il est donc difficile de se rendre compte des performances.

Les cas présentés ont également un périmètre limité. La publication n’évoque que deux types de charges : les modèles de vecteurs de représentation chargés via la bibliothèque Transformers de Hugging Face, et la génération de texte via Ollama. Il n’y a pas d’ordonnanceur central, il ne s’agit donc pas d’un modèle découpé et réparti entre les machines.

En fait, chaque exécuteur doit pouvoir faire tourner intégralement le modèle en local, ce qui limite d’autant les cas. La mémoire a beau être universelle sur les Mac Apple Silicon, sa quantité détermine directement ce que l’on peut y faire résider. Pas question par exemple d’y faire tourner le tout récent Muse Spark Open.

• Avec Muse Spark Open, Meta ouvre les poids et se rapproche d’Apple

Et si vous vous posez la question : non, l’entrainement n’est pas pris en charge, en tout cas pour l’instant. Apple compte prendre en charge l’entraînement distribué à l’avenir, sans plus de détails.

Quel intérêt ?

Au sein d’une organisation, l’infrastructure présentée peut avoir des avantages, mais il ne s’agit pas d’un projet « magique » capable de fonctionner avec tous les modèles. Il y a quand même plusieurs avantages : pas d’achat de GPU dédiés, un coût d’infrastructure considéré comme « nul », une capacité générale qui grandit avec le nombre de Mac présents sur place, ou encore un fonctionnement local puisque les données ne sortent pas de l’organisation.

L’intérêt d’Apple est d’avancer discrètement sur l’argument commercial que les Mac sont des machines taillées pour l’IA. Sur ce point, la présentation de Minions rejoint les annonces autour de Muse Spark Open et du rapprochement avec Meta, Apple ayant publié des mesures et de la documentation MLX.

En filigrane, le papier raconte également une autre histoire : celle des propres limites d’Apple. L’entreprise le dit elle-même dans son article, elle manque de GPU centraux. Ainsi, avant que Minions ne soit utilisé (montrant au passage que l’infrastructure n’est pas que théorique), certaines tâches d’inférence pouvaient attendre plus de 10 heures avant de commencer. Avec Minions, le temps ne serait plus que de quelques minutes, mais Apple ne donne aucun détail supplémentaire.

Dans l’absolu, Minions ne crée aucune rupture, car la récupération de cycles, le calcul bénévole ou encore l’inférence répartie existent déjà. C’est dans les grandes lignes le schéma adopté par l’infrastructure de calcul distribué BOINC, qui exploite les GPU depuis vingt ans. On peut également citer Petals pour répartir un grand modèle en blocs de couches sur des machines bénévoles réparties sur internet. Mais l’idée pourrait séduire les organisations déjà dotées de nombreux Mac, surtout s’ils sont récents et accompagnés d’une bonne quantité de mémoire.

« Plus largement, Minions ouvre une perspective inédite pour la communauté de l’apprentissage automatique : si les appareils macOS inactifs, à l’échelle de plusieurs organisations, voire de la communauté mondiale, pouvaient être fédérés de manière sûre, ils formeraient un vaste parc de GPU partagé, au bénéfice de l’ensemble de l’écosystème », indique Apple dans une conclusion plus ambitieuse.

Poids ouverts pour le poids lourd

Avec Muse Spark Open, Meta revient à ses premières amours, c’est à dire les modèles IA à poids ouverts. Et pour faire tourner ce poids lourd en local, l’entreprise s’est trouvé un partenaire inattendu : Apple.

Avec son ancienne famille de modèles Llama, Meta pensait avoir trouvé la botte secrète face aux LLM propriétaires d’OpenAI, d’Anthropic ou de Google : des modèles à poids ouverts, autrement dit qu’il est possible de télécharger et d’exploiter en local (sous certaines conditions). Patatras : la version 4 des modèles Llama livrée en avril 2025 a été entachée par des accusations de manipulation de benchmarks.

Derrière les modèles chinois

Piqué au vif, Mark Zuckerberg a décidé de tout remettre à plat et de créer de toutes pièces un nouveau labo dont les membres ont été débauchés à prix d’or partout dans la Silicon Valley et au-delà. Les premiers résultats sont apparus un an plus tard avec Muse Spark, un modèle… fermé.

L’idée des poids ouverts n’était cependant pas perdue. Alors que le débat autour des modèles ouverts battait son plein cet été, Meta livrait Muse Glimmer, un modèle déjà conséquent de 30 milliards de paramètres assorti d’une licence open source permissive (Apache 2.0). L’entreprise en rajoute une couche avec Muse Spark Open, « le modèle à poids ouverts américain le plus capable ».

Muse Spark Open est un modèle multimodal de 816 milliards de paramètres (42 milliards actifs pour chaque token utilisé selon une architecture Mixture of Experts) avec une fenêtre de contexte de 1 million de tokens, autrement dit la quantité d’informations qu’il peut prendre en compte durant une interaction. C’est désormais courant pour les modèles frontières, y compris Muse Wonder. Spark Open accepte du texte, des images, de la vidéo et de l’audio en entrée, mais il ne génère que du texte.

Meta présente Spark Open comme « conçu pour la programmation et les tâches agentiques », avec une prédilection pour « les travaux de longue haleine, le développement logiciel complexe et le raisonnement en plusieurs étapes. » Face à des modèles à poids ouverts concurrents, il figure en tête dans deux des trois benchmarks sur les tâches agentiques (JobBench et MCP-Atlas). Sur GDPval-AA v2 en revanche, il est dépassé par trois modèles chinois et Mistral Large 4.

En matière de programmation, Spark Open n’occupe aucune première place du podium : il est derrière quatre rivaux sur Terminal-Bench 2.1, et il se trouve dans la moyenne sur DeepSWE. Le modèle affiche de bons résultats sur les tests de connaissances et de raisonnement, et il se montre solide sur le multimodal. En tout, sur onze benchs, Meta décroche six premières places. Il manque également au tableau ses comparaisons avec les modèles fermés d’OpenAI et d’Anthropic.

Deux Mac Studio pour un modèle poids lourd

Le modèle donnera la pleine mesure de son talent sur le Mac Studio avec puce M5 Ultra, et même deux. Meta et Apple ont en effet travaillé ensemble pour que Spark Open exploite à plein le GPU intégré au silicium Apple, sa mémoire unifiée et la bande passante de la puce (jusqu’à 1,2 To/s).

Connecter deux Mac Studio dotés de 512 Go de mémoire permet de répartir le modèle entre les deux machines, qui disposent ainsi d’un téraoctet de mémoire au total : les 816 milliards de paramètres , stockés dans une version quantifiée en 4 bits, restent ainsi disponibles en mémoire (même si 42 milliards sont réellement mobilisés pour chaque token traité).

On parle d’une configuration qui devrait aisément dépasser les 30 000 euros pour deux Mac Studio M5 Ultra, Apple n’ayant pas encore annoncé le prix de l’option mémoire de 512 Go… Et Meta a indiqué qu’on pouvait même monter à quatre Mac Studio. Le tout est réalisable grâce à MLX, un framework d’Apple qui répartit l’exécution de modèles à poids ouverts entre plusieurs Mac reliés en Thunderbolt 5.

La haine recuite entre les deux entreprises est oubliée : l’IA rapproche donc même les pires ennemis ! « On est ravis que papa et maman s’entendent à nouveau », s’est amusé Alexandr Wang, le patron de l’IA chez Meta, auprès d’Axios. Les deux entreprises ont bûché pendant plusieurs mois pour cette annonce, mais cela ne les empêchera pas de conserver leur rivalité sur d’autres terrains. « Quand il est pertinent de collaborer et de nouer des partenariats, nous voulons pouvoir le faire », ajoute le dirigeant.

Les poids de Muse Spark Open sont disponibles sur Hugging Face. La licence Muse Model n’est pas aussi permissive que celle de Glimmer, même s’il est autorisé de modifier le modèle, de le distiller, de le redistribuer et même d’en vendre des copies sous réserve de respecter la licence et d’afficher une attribution. Certains usages militaires, la création de logiciels malveillants et le contournement des restrictions ou mesures de sécurité sont prohibés. Meta ne revendique aucun droit de propriété sur les sorties du modèle.