Vous ne trouvez pas de RAM ? Merci OpenAI qui a réservé 40% du stock mondial

Broadcom refuserait de fabriquer la puce personnalisée d'OpenAI si Microsoft n'en achète pas 40 %

Le projet de puce IA sur mesure développé par OpenAI en collaboration avec Broadcom se heurte à un obstacle financier majeur. Selon des informations rapportées par The Decoder, Broadcom refuse de financer la production de ces processeurs à moins que Microsoft ne s'engage à en acheter 40 % du volume total. Or, Microsoft n'a toujours pas donné son accord. La première phase du projet représente à elle seule un coût estimé à 18 milliards de dollars. Sachin Katti, un dirigeant d'OpenAI, a qualifié cette dépendance de "financièrement peu attractive" dans un message interne. Cette impasse met en lumière la fragilité de la stratégie d'indépendance technologique d'OpenAI. La start-up cherche depuis plusieurs mois à réduire sa dépendance à Nvidia pour ses besoins en calcul, mais cette ambition se retrouve bloquée faute de garanties commerciales suffisantes. Pour Broadcom, assumer seul le risque industriel d'un projet de cette envergure sans acheteur garanti est tout simplement hors de question. La décision de Microsoft conditionne donc directement la viabilité du programme. Ce projet s'inscrit dans une tendance plus large où les grandes plateformes d'IA cherchent à concevoir leurs propres puces spécialisées, à l'image de Google avec ses TPU ou d'Amazon avec ses Trainium. OpenAI avait annoncé des ambitions dans ce sens dans le cadre de l'initiative Stargate, le mégaprojet d'infrastructure à 500 milliards de dollars soutenu par l'administration Trump. La relation complexe entre OpenAI et Microsoft, à la fois partenaire stratégique et investisseur dominant, continue de peser sur chaque grande décision opérationnelle de la société.

💬 OpenAI veut son indépendance vis-à-vis de Nvidia, mais pour financer la puce qui lui donnera cette indépendance, il faut que Microsoft signe. La dépendance a juste changé d'adresse. Broadcom ne prend pas 18 milliards de risque sans acheteur garanti, c'est du bon sens, et ça dit beaucoup sur l'état de la stratégie Stargate en ce moment.

OpenAI envisage de publier un outil interne qui affaiblirait l'avantage logiciel de Nvidia

OpenAI envisage de rendre public un outil logiciel développé en interne qui permettrait d'exécuter des charges de travail d'intelligence artificielle sur des puces de différents fabricants, sans se limiter à celles de Nvidia. C'est Sachin Katti, responsable des infrastructures et du calcul chez OpenAI, qui a évoqué cette possibilité lors d'une table ronde. OpenAI a récemment conclu des accords pour utiliser les puces d'Amazon, de Cerebras et d'AMD, tout en développant ses propres puces personnalisées. Katti a décrit cet outil comme une "capacité d'optimisation agentique" et affirmé vouloir "rendre cette capacité disponible pour le monde entier". Il a également indiqué qu'OpenAI disposait déjà d'échantillons précoces des prochaines puces Vera Rubin de Nvidia, dont le déploiement est attendu d'ici fin 2025, et prévoit de les intégrer à ses entraînements d'ici la fin de l'année. Si OpenAI publie effectivement cet outil, les conséquences pour Nvidia pourraient être significatives. L'avantage concurrentiel du géant des semi-conducteurs repose en grande partie sur CUDA, son écosystème propriétaire de compilateurs, de bibliothèques et d'outils d'optimisation que la quasi-totalité des grands développeurs d'IA utilisent pour faire tourner leurs logiciels sur ses puces. Un outil capable d'abstraire cette dépendance, c'est-à-dire de permettre aux équipes d'OpenAI de lancer des charges de travail sans se soucier du matériel sous-jacent, ouvrirait la voie à une concurrence matérielle que Nvidia a jusqu'ici réussi à étouffer grâce à son écosystème logiciel. Katti a également suggéré que l'IA elle-même pourrait générer du code optimisé pour différentes architectures de puces, réduisant encore davantage la valeur de l'exclusivité de CUDA. Cette annonce s'inscrit dans une tendance de fond que l'on observe chez tous les grands laboratoires d'IA : OpenAI, Anthropic et Meta cherchent tous à diversifier leurs fournisseurs de calcul pour ne pas dépendre d'un seul acteur. Katti a résumé cette évolution par une formule claire : "Nous allons nous retrouver dans un monde très hétérogène." PyTorch, le framework développé à l'origine par Meta, avait déjà commencé à éroder l'hégémonie de CUDA en facilitant l'écriture de code pour plusieurs types de puces. Des startups proposent désormais des outils de traduction automatique de ce code vers des instructions bas niveau adaptées directement au matériel. OpenAI, en s'inspirant du système Borg de Google qui permet de gérer des charges de calcul sur des infrastructures hétérogènes, ambitionne d'accélérer ce mouvement à l'échelle de l'ensemble de l'industrie.

Le startup qui aide OpenAI à optimiser son IA pour les puces Cerebras

OpenAI a fait appel à la startup Gimlet Labs pour optimiser ses modèles d'intelligence artificielle sur les puces de Cerebras Systems. Selon Zain Asgar, PDG de Gimlet Labs, cette collaboration permet à OpenAI de faire tourner Codex-Spark, une version accélérée de son outil de programmation destiné aux développeurs, sur l'infrastructure Cerebras. L'annonce intervient alors que Cerebras se prépare à une introduction en bourse imminente cette semaine. Ce recours à une startup spécialisée illustre un défi technique souvent sous-estimé : chaque type de puce exige une adaptation spécifique du code qui entraîne et exécute les modèles. Ce travail d'optimisation bas niveau, peu visible mais indispensable, conditionne directement les performances et les coûts d'exploitation des grands modèles de langage. Pour les utilisateurs de Codex-Spark, cela se traduit concrètement par des temps de réponse plus rapides dans les tâches d'assistance au code. Cette dynamique s'inscrit dans un mouvement plus large de diversification des sources de calcul au sein de l'industrie de l'IA. Alors que les puces Nvidia restent difficiles à obtenir en quantité suffisante, des acteurs comme OpenAI et Meta cherchent activement des alternatives : Cerebras, mais aussi d'autres fabricants de puces spécialisées. Cette stratégie multi-fournisseurs crée un besoin croissant d'intermédiaires techniques capables d'adapter les modèles à des architectures matérielles variées, ouvrant un nouveau segment de marché pour des startups comme Gimlet Labs.

Ce que les benchmarks IA ne mesurent pas dans les conditions réelles

Les benchmarks utilisés par les équipes d'infrastructure IA ne reflètent pas les conditions réelles de production, et cet écart coûte cher aux entreprises. C'est le constat que dressent des ingénieurs de F5 et MinIO, qui ont mené des tests de débit dans des conditions réseau dégradées. Leurs résultats sont frappants : dès qu'on introduit une latence modeste dans le chemin vers le stockage objet S3, le débit chute drastiquement. Et à mesure que la latence augmente, comme c'est le cas sur des distances longue portée, la dégradation devient sévère. Autre surprise : la latence s'est révélée bien plus destructrice que le jitter réseau, à l'inverse de ce que l'équipe anticipait. Paul Pindell, architecte solutions chez F5, le formule clairement : "Les tests benchmark sont construits pour produire les meilleurs résultats possibles, pas les plus réalistes. Introduire une latence constante dans le chemin de test est indispensable pour que les chiffres aient un sens." Le problème concret est que les GPU, ressource la plus visible et la plus coûteuse de tout déploiement IA, ne génèrent de la valeur que si le chemin de données qui les alimente fonctionne correctement. Or ce chemin passe par le stockage, le réseau, les bases de données, les couches de sécurité et d'orchestration, souvent assemblées depuis plusieurs fournisseurs. Quand ce chemin se dégrade, les effets se cumulent : sous-utilisation des GPU, dégradation des sorties IA, hausse des coûts de transfert liés à la réplication inutile de données, et complexité opérationnelle croissante. Tanu Mutreja, directrice produit chez F5, souligne que les charges de travail IA sont structurellement plus exposées à ces défaillances que les applications traditionnelles. Contrairement aux bases de données ou aux systèmes ERP, qui absorbent les délais transitoires via des caches et des tampons, les clusters GPU massivement parallèles n'ont aucun mécanisme équivalent. Le moindre pic de latence ou goulot d'étranglement peut se propager immédiatement à l'ensemble du pipeline. Cette prise de conscience change la manière dont les architectes d'entreprise doivent concevoir leur infrastructure IA. Hunter Smit, responsable marketing produit chez F5, résume le paradoxe : "Les entreprises achètent suffisamment de GPU et de stockage, puis supposent que le chemin entre les deux tiendra. Mais le trafic IA est par rafales, très concurrent, et aléatoire dans ses lectures, d'une manière que les réseaux de stockage classiques n'ont jamais été conçus pour absorber." La réponse qui émerge dans l'industrie est le déploiement de contrôleurs de livraison applicative (ADC) ou de plateformes de livraison et sécurité (ADSP) en amont du stockage, pour créer un point de contrôle résilient. Le message central est que les décisions d'infrastructure fondées sur des benchmarks en environnement contrôlé exposent les organisations à des surprises coûteuses en production, et que la performance du chemin de données est devenue un levier stratégique au même titre que la capacité de calcul brute.