Quatre 9600X ont lâché en deux semaines sur des plateformes ASRock. Les symptômes sont identiques et les BIOS récents ne semblent pas y changer grand-chose.

ASRock Ryzen 5 9600X : séries de pannes et mêmes symptômes

Sur Reddit, quatre utilisateurs rapportent des Ryzen 5 9600X devenus inopérants sur cartes mères ASRock. Les systèmes postaient puis ont cessé de booter sans alerte, avec LED DRAM ou CPU figées et aucune amélioration après clear CMOS, permut’ de RAM ou d’alim.

Un cas est passé en RMA CPU après l’arrêt total du boot. Un autre mentionne deux 9600X morts consécutivement sur la même plateforme, le second avec BIOS v3.50.

Données communautaires : répartition par CPU et BIOS

Le megathread Reddit “CPU failures/deaths” de décembre place le Ryzen 5 9600X en troisième position : 183 rapports pour le Ryzen 7 9800X3D, 50 pour le Ryzen 7 9700X, 29 pour le Ryzen 5 9600X, puis 22 pour le Ryzen 9 9950X3D. Ces totaux n’intègrent pas les quatre signalements de janvier agrégés par Wccftech.

La répartition par BIOS au moment de la panne ne pointe pas un seul coupable : versions antérieures à 3.25/3.26 (103 cas, 30,6 %), 3.25/3.26 (75, 22,3 %), 3.30 (74, 22,0 %), 3.40 (48, 14,2 %), 3.50 (37, 11,0 %). Le dernier firmware n’élimine donc pas le risque.

Ces rapports restent déclaratifs et partiels, mais la tendance rejoint les incidents déjà observés autour des Ryzen 7 9800X3D sur cartes ASRock. Le constructeur publie de nouveaux BIOS et même des cartes AMD 800, sans prise de position publique spécifique sur ces cas.

Pour les utilisateurs AM5 concernés, la prudence impose un suivi étroit des versions BIOS, la désactivation de tout profil agressif côté mémoire/SoC, et une documentation précise des conditions de panne pour d’éventuels RMA. La visibilité croissante de ces incidents pourrait accélérer une réponse formelle d’ASRock ou un guidage AMD si une cause commune est confirmée.

Source: Wccftech, 9600X (Reddit), 9600X (Reddit), 9600X (Reddit), 9600X (Reddit), Megathread (Reddit)

Un ex-ingénieur de Google est inculpé pour espionnage économique sur des technologies IA clés ; la sécurité des accélérateurs maison de Mountain View se retrouve sur la sellette.

Google TPU au centre d’une enquête du DOJ

Le Department of Justice accuse l’ex-Googler Linwei Ding d’avoir volé jusqu’à 2 000 pages de documents confidentiels liés aux Tensor Processing Units (TPU) et à l’infrastructure IA de Google. L’enquête du FBI fait état d’informations dérobées couvrant l’architecture des puces, la connectivité externe, les systèmes GPU associés, les couches logicielles d’exécution/communication et l’orchestration de milliers de puces en supercalculateur.

Le DOJ estime que ces actes ont été commis au bénéfice de la République populaire de Chine. Google a collaboré avec le FBI et pointe un préjudice potentiel majeur sur une propriété intellectuelle développée sur plusieurs années et des milliards de dollars d’investissement.

Infrastructure TPU, SmartNIC et interconnexion à grande échelle

Les secrets industriels évoqués incluent également une SmartNIC maison, utilisée pour la communication haut débit au sein des supercalculateurs IA et des produits de cloud networking de Google. Ce maillon est critique pour soutenir la bande passante interne et la latence des grappes de TPUs.

Google exploite des architectures TPU pour limiter sa dépendance aux GPU AMD et NVIDIA. Le dernier modèle Gemini 3 a été entraîné et fonctionne exclusivement sur TPU. La société déploie le TPUv8ax « Sunfish » pour l’entraînement et le TPUv8x « Zebrafish » pour l’inférence à grande échelle. « Sunfish » est co-développé avec Broadcom, dont l’équipe custom gère design, mémoire, matériel d’accompagnement et packaging, afin de livrer un produit prêt à l’intégration dans les serveurs Google.

La valeur de l’ensemble ne tient pas qu’aux puces, mais à l’ingénierie d’interconnexion de dizaines de milliers de TPU, dimensionnée pour des runs d’entraînement massifs. C’est précisément ce tissu matériel-logiciel, difficile à reproduire, qui attire aujourd’hui les tentatives d’ingérence industrielle.

Au-delà du cas individuel, l’affaire illustre le basculement stratégique vers des accélérateurs propriétaires. En verrouillant l’entraînement et l’inférence de Gemini sur TPUv8, Google sécurise sa feuille de route et ses coûts, tout en exposant une surface d’attaque dont la valeur dépasse celle d’une simple puce isolée.

Source : TechPowerUp