Le portage d’un modèle d’IA d’une famille de puces à une autre se mesurait autrefois en mois. Anthropic affirme désormais avoir fait fonctionner une charge de travail de Claude sur des GPU AMD MI355X en environ trois jours, avec une intervention humaine minimale, grâce à Mythos. Cette annonce ne décrit pas seulement un gain de productivité : elle révèle une stratégie où la diversité matérielle devient un multiplicateur de calcul, de coût et de capacité d’adaptation.
Anthropic entraîne et déploie Claude sur AWS Trainium, les TPU de Google, les GPU NVIDIA et les GPU AMD. L’enjeu pour les entreprises dépasse la concurrence entre fabricants de puces : il concerne la possibilité de rendre le calcul plus interchangeable, de négocier davantage les capacités d’infrastructure et d’accélérer les cycles de développement des modèles.
Le multiplicateur d’Anthropic ne désigne pas une puce plus rapide
L’idée centrale d’Anthropic consiste à augmenter le calcul effectif sans dépendre d’un unique type d’accélérateur. Un multiplicateur de calcul peut venir de plusieurs sources : une meilleure utilisation des puces, une orchestration plus fine des workloads, une réduction du temps de portage ou la capacité à affecter chaque tâche au matériel le plus adapté.
Cette approche distingue la puissance théorique d’un accélérateur de la quantité de travail réellement accomplie. Une puce plus performante sur le papier ne produit pas automatiquement davantage de résultats si les logiciels, les kernels ou les outils de déploiement ne suivent pas. À l’inverse, une architecture capable d’exploiter plusieurs familles de puces peut augmenter la capacité disponible en réduisant les périodes d’attente et les dépendances à un seul fournisseur.
Anthropic présente sa stratégie comme une architecture multi-puces, c’est-à-dire un ensemble logiciel et opérationnel permettant d’entraîner et de servir Claude sur plusieurs familles d’accélérateurs. L’entreprise affirme que cette organisation lui permet d’orchestrer les workloads afin d’optimiser le prix et la performance.
À retenir : le multiplicateur ne correspond pas à un coefficient unique publié par Anthropic. Il décrit un avantage cumulé obtenu en combinant matériel, orchestration logicielle et automatisation du portage.
La logique est particulièrement importante pour les modèles de frontière, dont les besoins en entraînement et en inférence augmentent rapidement. Dans ce contexte, ajouter des puces ne suffit pas : il faut aussi réduire le temps nécessaire pour les rendre exploitables.
Mythos ramène un portage AMD à trois jours
L’exemple le plus concret concerne le passage d’une charge de travail de Claude vers des GPU AMD Instinct MI355X. Tom Brown, cofondateur et Chief Compute Officer d’Anthropic, a déclaré lors de la présentation destinée aux investisseurs que Mythos avait permis de faire fonctionner Claude sur AMD en environ trois jours, avec « basically no human intervention ».
Le délai annoncé concerne le démarrage du prompt processing, c’est-à-dire le traitement initial des tokens d’une requête, pour un modèle d’Anthropic sur des GPU AMD MI355X à un niveau de performance jugé utile. Il ne signifie pas que l’ensemble de Claude, de ses charges de production et de ses optimisations a été transféré en trois jours.
Anthropic indique que Mythos a écrit ou porté presque tous les kernels nécessaires. Ces kernels sont des routines spécialisées qui exécutent les calculs sur une puce donnée. Leur adaptation représente traditionnellement une part importante du travail lorsqu’un modèle doit passer d’un écosystème matériel à un autre.
Des comptes rendus de la présentation évoquent une durée habituelle de six à douze mois pour ce type de portage, contre environ trois jours dans le cas présenté par Anthropic. Cette comparaison mesure une accélération du travail d’adaptation, pas un benchmark indépendant de la performance globale de Claude sur AMD.
La nuance est essentielle pour les directions techniques. Un portage rapide peut réduire le délai avant expérimentation, mais une mise en production exige généralement d’autres validations : stabilité, observabilité, sécurité, compatibilité avec les bibliothèques, rendement énergétique, coût par token et comportement sous forte charge.
Quatre familles d’accélérateurs, quatre leviers pour l’entreprise
Anthropic déclare entraîner et servir Claude sur AWS Trainium, les TPU de Google, les GPU NVIDIA et les GPU AMD. Cette combinaison donne à l’entreprise plusieurs options pour répartir ses charges, plutôt qu’un seul chemin matériel.
| Famille d’accélérateurs | Rôle stratégique documenté | Effet potentiel pour une entreprise |
|---|---|---|
| AWS Trainium | Entraînement et déploiement de Claude au sein de l’architecture multi-puces | Accès à une capacité dédiée et intégration avec l’infrastructure AWS |
| TPU de Google | Entraînement et déploiement de Claude dans l’architecture multi-puces | Diversification des capacités et des fournisseurs |
| GPU NVIDIA | Entraînement et déploiement de Claude dans l’architecture multi-puces | Compatibilité avec un écosystème logiciel largement utilisé |
| GPU AMD | Portage de charges de Claude, dont le prompt processing sur MI355X | Option supplémentaire pour réduire la dépendance à un seul écosystème |
Cette diversification ne garantit pas automatiquement un coût inférieur. Elle crée toutefois les conditions nécessaires pour comparer les prix, la disponibilité et la performance sur plusieurs plateformes. L’entreprise qui possède une couche d’abstraction efficace peut déplacer une charge plus facilement qu’une entreprise dont les modèles sont profondément liés à une seule architecture.
Le bénéfice ne se limite pas au prix unitaire d’une heure de calcul. La disponibilité compte autant que le tarif affiché : une capacité moins chère mais inaccessible au moment d’un entraînement critique ne constitue pas nécessairement une meilleure option. Une architecture multi-puces peut donc fonctionner comme une assurance contre les goulets d’étranglement.
Pour les équipes d’achat, cela modifie aussi le rapport de force. La possibilité de faire fonctionner une charge sur plusieurs familles de puces donne davantage de crédibilité aux négociations avec les fournisseurs. Elle permet de mettre en concurrence la capacité, les délais de livraison et les conditions contractuelles, à condition que les coûts de portage restent maîtrisés.
Les montants engagés montrent l’échelle du pari
Les documents liés à l’introduction en Bourse d’Anthropic décrivent une stratégie d’infrastructure de très grande ampleur. Selon Tom’s Hardware, l’entreprise a déclaré au moins 110 milliards de dollars d’engagements auprès d’AWS pour la période allant de mai 2026 à avril 2036.
Le même compte rendu rapporte au moins 114,5 milliards de dollars d’engagements auprès de Google entre avril 2026 et juillet 2033. Il mentionne également des engagements futurs supplémentaires liés aux TPU, dont l’estimation se situe entre 125 et 150 milliards de dollars pour certaines périodes.
Anthropic a aussi indiqué que son architecture couvrait quatre familles de puces, sans publier de répartition précise des capacités entre AWS Trainium, TPU, GPU NVIDIA et GPU AMD. Les montants contractuels ne permettent donc pas d’attribuer une part exacte des dépenses à chaque type d’accélérateur.
Les dépenses déjà observées illustrent néanmoins le poids de la recherche. Tom’s Hardware rapporte qu’au premier semestre 2026, Anthropic a consacré 8,95 milliards de dollars au calcul et à l’infrastructure pour l’ensemble des workloads, contre 2,38 milliards de dollars aux coûts liés au service des clients.
Ces chiffres changent la lecture de l’avantage multi-puces. Il ne s’agit pas seulement de trouver une alternative à NVIDIA lorsque les GPU manquent. Il s’agit d’optimiser une enveloppe d’infrastructure qui comprend l’entraînement, la recherche, les évaluations internes et le service des utilisateurs.
Pour une entreprise cliente, la leçon est directe : les économies les plus importantes peuvent venir de l’architecture complète, pas d’un simple changement de fournisseur. Le coût d’un modèle dépend du matériel, mais aussi du taux d’utilisation, des transferts de données, des optimisations, de la maintenance et du temps d’ingénierie.
Ce que cette stratégie change pour les directions techniques
Le premier changement concerne la conception des applications. Les équipes ne peuvent plus considérer le modèle comme un simple appel API isolé de l’infrastructure. Derrière chaque requête se trouvent une famille de puces, un mode de traitement, une latence, un coût et une disponibilité.
Une stratégie inspirée d’Anthropic pousse à séparer davantage l’application de la plateforme matérielle. Les composants utiles comprennent notamment :
- une couche d’orchestration capable de répartir les workloads ;
- des tests de performance exécutés sur plusieurs environnements ;
- une mesure du coût par requête et du coût par token ;
- des mécanismes de bascule en cas de saturation ;
- une validation des kernels et bibliothèques utilisés en production ;
- un suivi distinct de la latence, du débit et de la qualité des réponses.
Le deuxième changement concerne les compétences. Les entreprises auront besoin de profils capables de comprendre à la fois les modèles, les runtimes, les compilateurs et les accélérateurs. La frontière entre équipe machine learning et équipe infrastructure devient moins nette lorsque le coût d’un modèle dépend de la manière dont ses opérations sont distribuées sur plusieurs puces.
Le troisième changement concerne les critères de sélection d’un fournisseur d’IA. La qualité d’un modèle reste déterminante, mais elle ne suffit plus à évaluer une solution. La portabilité, la capacité à absorber une hausse de trafic et la transparence sur les performances deviennent des critères opérationnels.
Une entreprise qui utilise un modèle exclusivement via une API ne contrôlera pas tous ces paramètres. Elle peut cependant demander des indicateurs concrets : latence par niveau de charge, stabilité des capacités, options de déploiement, localisation des données et mécanismes de continuité de service.
À retenir : la portabilité matérielle devient un sujet de gouvernance informatique, pas seulement une question réservée aux équipes de recherche.
Le vrai avantage se situe dans la boucle d’apprentissage
L’effet le plus difficile à reproduire ne vient pas uniquement du nombre de puces disponibles. Il vient de la boucle complète entre recherche, développement logiciel et infrastructure. Chaque portage réussi fournit des informations sur les kernels, les performances et les limites d’une architecture, ce qui peut accélérer les portages suivants.
Mythos illustre cette boucle. Le modèle ne se contente pas de générer du code applicatif : il intervient sur des routines bas niveau destinées à exploiter une architecture matérielle spécifique. Si les validations humaines se concentrent sur les points critiques plutôt que sur l’écriture manuelle de chaque routine, le temps d’adaptation peut diminuer fortement.
Cette automatisation ne supprime pas le besoin d’expertise. Elle déplace la valeur vers la définition des contraintes, la construction des tests et l’analyse des écarts. Un kernel généré rapidement doit encore être vérifié sur la justesse numérique, la stabilité, la consommation mémoire et les performances réelles.
L’avantage potentiel s’accroît lorsque la même infrastructure sert à la fois à entraîner un modèle et à améliorer les outils qui permettront de l’exécuter. C’est cette boucle d’amélioration qui explique pourquoi Anthropic présente les multiplicateurs comme un avantage difficile à reproduire, notamment à l’approche de systèmes capables d’automatiser une part croissante de leur propre développement.
L’expression amélioration auto-récursive désigne ici une dynamique dans laquelle des modèles contribuent à améliorer les logiciels, les outils ou les méthodes utilisés pour entraîner et déployer des modèles ultérieurs. Elle ne signifie pas qu’Anthropic a annoncé une autonomie générale du développement, ni qu’un tel système fonctionnerait sans contrôle humain.
La différence entre automatisation locale et avantage structurel est importante. Une entreprise peut utiliser un outil qui génère un kernel. Elle ne dispose pas pour autant du réseau de données de performance, de la capacité de calcul, des environnements de test et de l’expérience accumulée nécessaires pour transformer cette génération en avantage durable.
Les limites à surveiller avant de parler de rupture
Le cas AMD présenté par Anthropic est significatif, mais il doit être interprété avec précision. Le délai de trois jours concerne une charge de prompt processing pour un modèle et une plateforme déterminés. Il ne constitue pas une preuve que toutes les charges d’entraînement et d’inférence de Claude sont désormais équivalentes sur les quatre familles de puces.
Les informations publiées ne rapportent pas de benchmark public indépendant comparant, sur la même charge, la performance, le coût et la consommation des GPU AMD MI355X, des GPU NVIDIA, des TPU de Google et d’AWS Trainium. Il serait donc prématuré de conclure qu’une architecture particulière domine les autres dans tous les scénarios.
La portabilité comporte également des coûts cachés. Une application peut fonctionner sur plusieurs accélérateurs tout en affichant des performances différentes. Les écarts peuvent venir de la précision numérique, de la mémoire, des interconnexions, des bibliothèques disponibles ou de la maturité des outils de supervision.
Les directions informatiques doivent aussi distinguer trois niveaux de portabilité :
- faire démarrer un modèle sur une puce ;
- atteindre une performance utile sur une charge précise ;
- maintenir une production fiable et économiquement compétitive à grande échelle.
Anthropic a documenté un résultat relevant du deuxième niveau pour le prompt processing sur AMD MI355X, avec un portage réalisé en environ trois jours. Le passage au troisième niveau exige des informations opérationnelles plus larges que celles rapportées dans la présentation.
Enfin, la diversification ne supprime pas la dépendance aux fournisseurs. Elle la distribue. Une entreprise doit encore gérer des contrats, des interfaces, des politiques de disponibilité et des contraintes de localisation. L’architecture multi-puces réduit une concentration, mais elle augmente aussi la complexité de pilotage.
Notre avis : le multiplicateur devient un avantage d’infrastructure
Anthropic ne gagne pas seulement du temps en faisant fonctionner Claude sur AMD. L’entreprise démontre surtout qu’elle traite le calcul comme une capacité interchangeable, pilotée par logiciel et soutenue par l’automatisation. Avec AWS Trainium, les TPU de Google, les GPU NVIDIA et les GPU AMD, elle construit une marge de manœuvre que les architectures mono-fournisseur possèdent moins facilement.
Pour les entreprises, le message est concret : la prochaine bataille ne portera pas uniquement sur le meilleur modèle, mais sur la capacité à l’exécuter au bon coût, sur la bonne infrastructure et avec un délai d’adaptation réduit. Les organisations qui investissent dans l’observabilité, les tests multi-plateformes et la séparation entre application et accélérateur seront mieux placées pour changer de fournisseur lorsque les prix, les capacités ou les performances évolueront.
Le portage AMD réalisé en trois jours ne transforme pas à lui seul le marché des GPU. Il montre toutefois que l’automatisation du code bas niveau peut réduire l’un des principaux coûts de la diversification matérielle. Si Anthropic généralise cette méthode à davantage de workloads, son avantage pourrait venir moins d’une puce particulière que de sa vitesse à exploiter toutes les puces disponibles.
Dans les six prochains mois, le signal à surveiller sera donc la reproductibilité : Anthropic publiera-t-elle des comparaisons détaillées entre ses plateformes, étendra-t-elle Mythos à d’autres charges et les entreprises pourront-elles obtenir des gains comparables sur leurs propres modèles ?