Google et AWS rendent PyTorch natif sur leurs puces et desserrent l’étau de CUDA
Le 22 octobre 2026, à la PyTorch Conference North America, Google a open-sourcé TorchTPU pour ses TPU et AWS a lancé TorchNeuron en bêta publique pour ses puces Trainium, deux backends PyTorch natifs qui évitent les dépendances JAX ou CUDA. Le passage est simple, mais le pic de performance exige encore des optimisations spécifiques, avec une pénalité de 30 à 40 % pour l’approche par défaut de TorchTPU.
22 octobre 2026. À la PyTorch Conference North America 2026, Google open-source TorchTPU, un stack PyTorch natif pour ses TPU, et AWS lance TorchNeuron en bêta publique, son backend PyTorch natif pour Trainium. Avril 2026. TorchTPU était en aperçu auprès de clients choisis, après un travail engagé à la mi-2025. Les deux sorties visent la même cible : desserrer l’emprise de CUDA, l’écosystème logiciel de Nvidia qui domine le développement IA depuis des années.
Pour un responsable d’infrastructure IA qui regarde sa facture de GPU, l’annonce tient en une phrase : il existe désormais deux chemins officiels pour exécuter PyTorch sur des accélérateurs non-Nvidia, mais la simplicité d’accès ne se traduit pas encore par la performance de pointe — et c’est précisément ce qui décidera de votre migration.
Deux backends natifs pour sortir de CUDA
Le raisonnement des deux hyperscalers est identique, exprimé presque mot pour mot. Google veut rendre son écosystème logiciel TPU « plus ouvert et plus convivial » pour la communauté PyTorch ; AWS prolonge la même approche vers ses propres puces. L’objectif commun est de faire des TPU et des Trainium des options pratiques pour les développeurs qui utilisent déjà PyTorch, sans leur imposer une réécriture.
Le contexte donne la mesure du changement. Pendant des années, exécuter PyTorch sur un TPU relevait d’une « danse inconfortable » : les charges passaient par JAX ou par des chemins XLA qui obligeaient à adapter le code. Sur Trainium, il fallait comprendre le Neuron SDK avant d’espérer un gain. Les deux nouveaux backends court-circuitent cette friction en plaçant PyTorch au centre, là où vivent déjà la plupart des équipes.
TorchTPU : PyTorch sur TPU sans JAX
TorchTPU, développé en collaboration avec l’équipe PyTorch de Meta, permet d’exécuter des charges PyTorch existantes sans dépendance JAX au runtime. Plutôt que d’imposer des modifications de code importantes, la migration se résume, selon PyTorch, à des « changements de code triviaux ».
Deux modes d’exécution couvrent le cycle de vie d’un modèle. L’eager execution sert à déboguer, en exécutant les opérations au fur et à mesure comme on le ferait en local. torch.compile optimise ensuite l’utilisation du TPU et réduit la surcharge mémoire. La promesse est donc un continuum : on débogue simplement, puis on compile pour la production.
La sortie s’accompagne d’un train d’intégrations annoncé à la conférence — Hugging Face, vLLM, SGLang, llm-d, TorchTitan, Ray et TorchRec — et d’une contribution de LiteRT à l’écosystème PyTorch. Google les présente comme des briques « conçues pour vous aider à exécuter PyTorch efficacement sur Google Cloud ou dans votre propre infrastructure », un signal que la cible dépasse le seul cloud maison.
TorchNeuron : PyTorch sur Trainium en bêta
AWS joue la même carte avec TorchNeuron, un backend PyTorch natif pour Trainium, la gamme de puces IA dédiées à l’entraînement et à l’inférence. La bêta publique supporte les instances Trainium2 et Trainium3.
La simplicité annoncée tient dans une ligne de code : déplacer un modèle vers Trainium peut se résumer à basculer le device sur neuron avec la méthode .to(), pour l’exécution eager. Les modèles compilés doivent, eux, sélectionner le backend Neuron, soit par défaut, soit dans un appel à torch.compile. TorchNeuron s’intègre aussi à la Neuron Kernel Interface (NKI), le langage et compilateur bare-metal de programmation des Trainium et Inferentia, pour créer des opérateurs sur mesure et optimiser la performance.
AWS et PyTorch ont publié un guide détaillé sur les modes d’exécution du backend et leurs compromis — un aveu que le chemin « trivial » et le chemin « performant » ne sont pas le même.
La simplicité d’accès n’est pas le pic de performance
C’est le point que les deux annonces n’affichent pas en une. PyTorch reconnaît qu’un simple changement de code fait tourner les modèles sur TPU, mais que le pic de performance exige des optimisations propres au TPU.
Le chiffre le plus parlant concerne les charges distribuées : l’approche par défaut de TorchTPU, les Skinny Collectives, peut infliger une pénalité de bout en bout d’environ 30 à 40 % par rapport à une approche optimisée, parce qu’elle empêche le compilateur XLA de superposer calcul et communication. Pour qui vise le pic, PyTorch recommande un réglage supplémentaire et des stacks de production — « des noyaux Pallas et des stacks comme vLLM-TorchTPU, SGLang-TorchTPU ou TorchTitan-TorchTPU ».
AWS est plus prudent dans ses formulations : les équipes peuvent essayer Trainium avec un changement de configuration plutôt qu’une réécriture de code « dans la plupart des cas » — ce qui laisse ouverte la question des cas restants. Une étude de cas le montre : pour adapter le modèle Laplace 3B de i14 à Trainium2, le Generative AI Innovation Center d’AWS a dû opérer trois changements — utiliser PyTorch natif pour le noyau d’attention GLA, redessiner la communication de Muon et compiler la passe arrière séquentielle.
Verdict
Si votre parc tourne massivement sur CUDA et que votre coût de GPU explose, ouvrez un dossier d’évaluation : TorchTPU et TorchNeuron abaissent le coût d’entrée vers des accélérateurs alternatifs, et un premier test « trivial » en quelques jours vous dira si vos modèles passent sans réécriture.
Si vous visez le pic de performance sur un modèle critique, ne prenez pas la promesse « trivial » pour argent comptant : budgetez les optimisations propres à chaque puce — noyaux Pallas ou NKI, réglage des collectives — et mesurez la pénalité de 30 à 40 % de l’approche par défaut avant de comparer les prix. Le coût de bascule n’est plus dans le code, mais dans l’optimisation ; c’est lui qu’il faut chiffrer avant de signer.