Un modèle PyTorch écrit pour les GPU Nvidia peut désormais tourner sur les puces d'Amazon ou de Google avec un changement de configuration ou des « modifications de code minimales », selon les deux groupes. Chez Deepgram, seul client à avoir détaillé un portage, le modèle de transcription Nova-3 a exécuté toutes ses opérations sur Trainium2 dès sa compilation avec TorchNeuron. Le gain de coût, lui, a pris plusieurs mois. Il porte sur une configuration retravaillée : noyaux de calcul réécrits avec les ingénieurs d'AWS, une convolution écrite de zéro, un moteur de service neuf en Rust. Aucun document des deux groupes ne prévoit d'exécuter les noyaux maison écrits en CUDA ou en Triton : ils restent à reprendre dans le langage de chaque puce.

Tous les chiffres viennent des éditeurs et de leurs clients. Aucune mesure indépendante n'est disponible. TorchNeuron, en bêta publique, exige PyTorch 2.14.0, alors que la version 2.15 est prévue le 28 octobre. Les deux piles remplacent des passerelles plus anciennes fondées sur PyTorch/XLA. Le même 20 octobre, AMD et Intel ont annoncé vouloir réunir leurs optimisations PyTorch pour processeurs x86 dans la bibliothèque oneDNN, sans calendrier.

Ce qui tourne sans réécriture

Amazon promet, dans son annonce du 19 octobre, d'exécuter du code PyTorch existant avec une seule modification de configuration. Le blog technique publié par les équipes d'AWS sur le site de PyTorch précise la portée. Le modèle est déplacé vers le périphérique « neuron », puis compilé au besoin par torch.compile avec le backend du même nom. Le code écrit avec l'API torch.accelerator tourne sans modification, selon ce blog. Hugging Face indique dans un billet que 89 % des 100 architectures de génération de texte les plus utilisées sont « prises en charge d'emblée » (citations traduites de l'anglais) avec Transformers. Le taux était de 46 % avec Optimum Neuron 0.4.5, la bibliothèque qu'il proposait jusque-là pour Trainium et qu'il recommande désormais de délaisser. Le billet ne dit ni ce que la prise en charge recouvre, ni comment elle a été testée.

Google parle de « modifications de code minimales » dans son billet du 20 octobre. Le code vise le périphérique « tpu ». Avec Transformers v5, l'argument device_map="tpu" suffit, selon Google. TorchTPU, codéveloppé avec l'équipe PyTorch de Meta, remplace PyTorch/XLA : la documentation de Google recommande d'y migrer les charges existantes. La compilation passe toujours par OpenXLA et StableHLO, à la place d'Inductor.

Les deux piles passent par PrivateUse1, l'interface que PyTorch réserve au matériel tiers. Le dépôt de TorchNeuron, en bêta publique sous licence Apache 2.0 depuis le 20 octobre, ne cite que les instances Trn2 et Trn3, avec Python 3.12 à 3.14. Le dépôt de TorchTPU, en version 0.2.0 sous la même licence, n'indique pas la version de PyTorch requise. Sa documentation valide quatre générations : TPU v5e, v5p, v6e et v7 (Ironwood). Les v8i et v8t sont visées.

Les noyaux à réécrire et les fonctions absentes

Les noyaux personnalisés s'écrivent avec les outils de chaque puce. Amazon propose NKI, Google Pallas et la bibliothèque Tokamax. Helion, le langage de noyaux portables de PyTorch, est classé expérimental dans la documentation de TorchTPU, qui renvoie à Pallas et Tokamax pour la production. Le programme de la PyTorch Conference annonce pour Helion deux backends, l'un pour les GPU Nvidia, l'autre pour les TPU, à partir d'un même code source de noyau.

Le dépôt d'Amazon liste ses limites. torch.compile n'accepte que des formes fixes : chaque nouvelle forme d'entrée déclenche une recompilation. Les calculs en float64 s'exécutent en float32. La quantification FP8 par TorchAO reste en bêta privée. Amazon dit tester en continu 100 000 modèles de Hugging Face, qui représentent 99,9 % de l'usage mesuré par les téléchargements selon le blog, et « des centaines de milliers » selon l'annonce. Aucun taux de réussite n'est publié.

Le blog détaille l'exécution d'août 2026 de la suite de tests de PyTorch : environ 154 000 résultats, dont 69 000 écartés. PyTorch en écarte lui-même 30 000, propres à CUDA ou au CPU. Amazon en écarte 39 000, en trois groupes. Environ 22 000 visent des opérateurs sans prise en charge native, dont les cellules LSTM et GRU fusionnées. Le deuxième groupe réunit les tests des CUDA graphs et des collectives NCCL. Le troisième couvre les fonctions laissées hors de la première version faute de demande des clients, selon le blog : tenseurs creux, NestedTensor, masques d'attention arbitraires, quantification par canal, formes dynamiques.

Le billet de Google ne mentionne aucune limite. Sa documentation classe comme expérimentaux les entiers symboliques, les tenseurs irréguliers, les cellules LSTM et GRU, les modèles Mamba et FSDPv2, « à faible performance ». Les opérations dynamiques y déclenchent encore une recompilation : les exécuter sans recompiler figure parmi les objectifs à court terme. Un billet technique d'avril 2026 tenait déjà les recompilations et la latence de la première itération pour des chantiers ouverts. Il conseillait des têtes d'attention de dimension 128 ou 256 plutôt que 64.

Deepgram : plusieurs mois de portage pour Nova-3

Le billet du 19 octobre est signé par six auteurs d'AWS et un ingénieur de Deepgram. L'équipe a d'abord exécuté Nova-3 en mode eager sur Trainium2 pour repérer les replis vers le processeur, puis l'a compilé avec torch.compile : « toutes les opérations du modèle sur Trainium2, sans repli détecté sur le processeur ». Le portage, mené avec l'équipe Forward Deployed Engineering d'AWS, a duré « plusieurs mois ».

L'équipe a remplacé des couches par des noyaux de la bibliothèque NKILib, puis en a réécrit : le noyau du réseau à propagation avant divise par deux la latence du noyau de référence au lot de 96. NKILib n'avait pas de convolution 2D. Elle a été écrite de zéro en NKI, pour un gain allant jusqu'à 50 fois sur ce module aux lots de 32 au plus. Deepgram sert ses modèles depuis une pile en Rust : l'équipe a construit un moteur d'exécution d'où Python et PyTorch sont absents, qui gagne 7,5 % de débit sur une version Python de référence.

La configuration finale fait tourner huit copies du modèle sur une seule instance trn2.3xlarge. Sur des traitements par lots hors ligne, elle traite 11 à 70 % d'audio en plus par dollar que « les options de calcul » utilisées jusque-là par Deepgram, aux tarifs des instances au moment de l'évaluation. Ces options ne sont pas nommées. La fourchette n'est pas décomposée. Le taux d'erreur de transcription devait rester conforme aux références de Deepgram : aucune valeur n'est donnée.

Trois chiffres d'AWS et de Deepgram pour un même cas

Le billet AWS donne 11 à 70 %. Le blog de TorchNeuron cite Adam Sypniewski, directeur technique de Deepgram, pour « environ 60 % » de secondes d'audio en plus par dollar face à ses GPU. Colin Brace, vice-président chargé du logiciel chez Annapurna Labs, la filiale d'Amazon qui conçoit Trainium, a avancé 70 % auprès de TechCrunch, le haut de la fourchette. Aucun des trois chiffres ne vient d'un tiers.

L'annonce d'Amazon ne donne aucun chiffre de performance. Google revendique, pour l'entraînement de Qwen 3 8B avec TorchTitan, jusqu'à 52 % d'utilisation de la puissance de calcul théorique des puces, avec une montée en charge quasi linéaire jusqu'à 8 192 TPU Ironwood, sans détailler la configuration. Son client Zenteiq est passé de 1,47 à 5,97 milliards de tokens générés par jour par tranche de 1 000 TPU v6e, plus de quatre fois plus. Le billet attribue ce gain au routage de GKE Inference Gateway et de llm-d, deux outils de service d'inférence, sans dire la part de TorchTPU.

AMD et Intel : un projet commun pour les processeurs x86

Selon le communiqué d'AMD du 20 octobre, les deux groupes prévoient de regrouper leurs optimisations PyTorch pour processeurs x86 dans oneDNN, sur recommandation du x86 Ecosystem Advisory Group. Ils ont retenu cette bibliothèque open source, gouvernée par la fondation UXL, comme voie par défaut pour l'accélération x86 dans PyTorch. AMD y verse ZenDNN et entre parmi les membres directeurs de la fondation. ACE, un futur jeu d'instructions x86 pour la multiplication matricielle, doit arriver dans PyTorch par des mises à jour d'oneDNN. Le communiqué ne précise ni versions, ni processeurs, ni calendrier.

Amazon annonce la disponibilité générale du FP8 pour sa prochaine version, sans date. TorchNeuron reste fixé à PyTorch 2.14.0, à une semaine de la sortie prévue de la 2.15. Google ne qualifie le statut de TorchTPU ni dans son billet, ni dans son dépôt, ni dans sa documentation. Seuls la suite d'agents TPU et VeRL y sont marqués en préversion.

Nos articles remonteront en priorité dans « À la une » de Google.