Le discours véhiculé par le marché du cloud depuis des années est celui de la marchandisation : le matériel en dessous n'a pas d'importance, ce qui compte, c'est le service. Vous avez choisi le fournisseur en fonction du catalogue de services gérés, du prix par heure d'instance et du support. La puce était un détail d'infrastructure, invisible et interchangeable – pratique alors que tout le monde achetait le même silicium chez Intel et AMD et que la vraie différence résidait dans les logiciels et les opérations. Le problème est que ce récit n’est plus vrai et que les prestataires qui l’avaient compris auparavant récoltent des avantages que d’autres ne peuvent pas se permettre.
Pourquoi créer votre propre puce quand vous pouvez l'acheter
La réponse directe : parce qu’à l’échelle hyperscale, l’efficacité matérielle se transforme en chiffres de marge qui justifient tout investissement raisonnable en R&D. AWS traite des volumes de calcul qui permettent à tout gain en pourcentage par watt de se chiffrer en centaines de millions de dollars par an. Si une puce conçue spécifiquement pour vos charges de travail offre vingt pour cent de performances par watt en plus que son équivalent disponible dans le commerce, cette différence n'est pas une curiosité technique : c'est un avantage concurrentiel converti en prix, en marge ou les deux.
La deuxième raison est l'indépendance. Quiconque achète toute la capacité informatique auprès d’un seul fournisseur – dans le cas de l’IA, essentiellement auprès de Nvidia – est soumis à la file d’attente d’attribution, au prix dicté par celui qui détient un monopole pratique sur le produit et à la feuille de route technologique d’un autre. Pour une entreprise concurrente dans le cloud computing, il s’agit d’un risque stratégique au même titre que la dépendance à l’égard d’un seul client. Personne au conseil ne tolérerait la seconde solution ; le premier est devenu une routine jusqu’à ce que les grandes technologies décident du côté de leur propre production.
Comment chaque hyperscaler a joué cette main
AWS Graviton est le cas le plus lisible en tant que décision commerciale. Basé sur ARM, Graviton4 offre des gains de performances significatifs par dollar par rapport aux instances x86 équivalentes sur AWS lui-même – et AWS l'utilise à la fois pour réduire les coûts internes et pour proposer des instances moins chères aux clients en migration. L'adoption s'est développée parce que la proposition de valeur est quantifiable : vous exécutez la même charge de travail et payez moins, ou vous exécutez plus pour le même prix.
Google a pris la décision la plus radicale avec les TPU. L'unité de traitement tensoriel a été conçue à partir de zéro pour une charge de travail spécifique : la multiplication matricielle de haute dimension, qui constitue l'opération de base des réseaux de neurones. TPU v5p est utilisé à la fois pour la formation et l'inférence, profondément intégré à TensorFlow et JAX. Détail pertinent pour quiconque envisage de l'utiliser : le TPU n'existe pas en tant que matériel isolé. Vous accédez à la capacité via Google Cloud : l'adoption du TPU est une décision de plate-forme, pas seulement une décision de calcul. La performance est liée à l'obligation.
Apple est le cas le plus extrême d’intégration verticale et le plus ancien. Depuis le M1, Apple contrôle la puce, le système d’exploitation, le compilateur et le logiciel système. La conséquence pratique est que des optimisations qui seraient impossibles dans une pile fragmentée deviennent une routine : la puce connaît le cache, le système d'exploitation connaît la puce, le compilateur connaît les deux. Le M4 Ultra atteint les performances d'un serveur dans un format de bureau, non pas grâce à un seul miracle d'ingénierie, mais parce que chaque couche est conçue pour les autres.
Meta et Microsoft sont arrivés plus tard avec des objectifs plus chirurgicaux. Le MTIA de Meta a été conçu pour réduire la dépendance à l'égard de Nvidia spécifiquement pour les modèles de recommandation : des milliards d'inférences par jour à une norme suffisamment stable pour justifier un silicium spécialisé. Le Maia 100 de Microsoft couvre la formation et l'inférence sur Azure, y compris une partie de l'infrastructure GitHub Copilot. Dans les deux cas, l’objectif n’est pas de remplacer entièrement le GPU, mais de réduire la dépendance là où la charge prévisible rend la spécialisation économiquement évidente.
La puce comme fossé : pourquoi c'est difficile à copier
Ce qui fait du silicium personnalisé un avantage durable, c'est le coût et le temps de réplication. La conception d’une puce compétitive prend des années avant que la première tranche ne quitte l’usine. La fabrication à grande échelle nécessite des relations avec TSMC ou Samsung qui ne se construisent pas en trimestres. L’écosystème logiciel qui tire le meilleur parti de la puce prend encore plus de temps. Celui qui a débuté en 2016 – Google avec le TPU, Apple avec ses puces de transition – se trouve dans une position telle qu'un concurrent qui décide de se lancer demain n'atteindra pas avant 2030 dans le meilleur des cas. Ce n’est pas un avantage qui peut être acheté lors d’un cycle d’investissement ou copié lors d’un sprint produit.
Pour les petits fournisseurs de cloud, cela crée un problème de concurrence sans solution évidente. Vous pouvez acheter les mêmes puces Nvidia ou AMD que le concurrent, mais vous ne pouvez pas acheter l'efficacité que Graviton donne à AWS après des années d'itération à grande échelle. L’écart de performance par dollar se creuse à chaque génération – et il n’existe pas de raccourci.
Qu'est-ce que cela change pour ceux qui utilisent le cloud, pas pour ceux qui le vendent
Le changement le plus important pour ceux qui consomment des services cloud est que le benchmark des performances des instances a perdu une dimension. Comparer les vCPU et les gigaoctets de RAM entre fournisseurs comme si le matériel sous-jacent était équivalent est une analyse incomplète. Les instances AWS Graviton et les instances AWS x86 équivalentes représentent des charges de travail différentes sur différents siliciums, avec des normes de performances qui varient selon le type d'application.
Le deuxième changement est que le cloud lock-in a acquis une couche matérielle qui ne figurait pas dans le contrat initial. Une application optimisée pour le TPU a un coût de migration beaucoup plus élevé qu'une application sur le calcul générique. Ce n’est pas un argument pour éviter les puces spécialisées – les performances le justifient souvent – mais c’est le coût qui doit être inclus dans l’analyse avant l’adoption, et non après.
La troisième dimension est que les différences de coûts et de performances entre les fournisseurs vont se creuser. Graviton rend déjà certaines charges sensiblement moins chères sur AWS que sur les alternatives matérielles disponibles dans le commerce. À mesure que chaque hyperscaler fait mûrir son silicium, comparer les cloud nécessitera de comprendre quelle puce se trouve derrière quelle charge de travail – des connaissances techniques que de nombreuses entreprises délèguent aujourd'hui à l'intégrateur de garde, sans se rendre compte qu'elles délèguent également la décision au fournisseur.
A lire aussi
- Puces d'inférence et ASIC : quand le spécialisé bat le générique
- Les puces spécialisées et la fin de l'ère des CPU génériques
- Edge computing : pourquoi l'informatique quitte le cloud et se rapproche des données -Géopolitique du silicium : pourquoi la guerre des puces est importante pour ceux qui décident de la technologie -L'inférence à la périphérie : lorsque l'exécution de l'IA sur l'appareil a plus de sens que dans le cloud
- L'infrastructure comme avantage compétitif : ce que les startups apprennent des grandes techs