Infrastructure

La vague bleue pourrait ne pas freiner les ambitions de Musk pour ses centres de données au Texas

Elon Musk a su investir tôt dans des centres de données d'intelligence artificielle au Tennessee et au Mississippi, et il en a tiré les bénéfices. Il prépare maintenant un projet ambitieux au Texas pour SpaceX, où OpenAI et d'autres acteurs ont déjà pris de l'avance. Des documents publics, des offres d'emploi et des structures d'acier qui s'élèvent rapidement, avec des turbines à gaz garées à côté, indiquent que SpaceX a commencé à construire un « Starbase supercomputer » de plusieurs gigawatts. Le terme figure dans l'une de ses annonces de recrutement. Le site se trouve dans la cité de Starbase, en pleine expansion. Cette vaste propriété de SpaceX est située à la frontière entre le Texas et le Mexique, dans la vallée du Rio Grande. C'est de là que décolle sa gigantesque fusée Starship. L'élection surprise de la démocrate Gina Hinojosa au poste de gouverneur, cette semaine, pourrait changer la donne. Elle ne devrait pas faire dérailler complètement les projets de Musk, mais elle pourrait en retarder certains volets. Les plans de SpaceX pourraient faire l'objet d'un examen sévère de sa part. Pour l'industrie, c'est un signal que le Texas, longtemps perçu comme un terrain très favorable aux grands projets énergétiques et numériques, pourrait devenir plus exigeant. Les installations de cette taille consomment d'énormes quantités d'électricité et s'appuient ici sur des turbines à gaz, ce qui attire naturellement l'attention des autorités et des riverains. Ce dossier s'inscrit dans la course effrénée aux capacités de calcul pour l'IA, où chaque entreprise cherche à sécuriser terrains, énergie et autorisations avant ses concurrents. Musk a déjà montré, au Tennessee et au Mississippi, qu'il privilégiait la rapidité d'exécution. Au Texas, il fait face à OpenAI et à d'autres groupes déjà plus avancés. La suite dépendra des mesures que la nouvelle gouverneure choisira de prendre, notamment en matière de permis, d'énergie et d'environnement, et de la manière dont SpaceX y répondra.

💬 Selon Le Fil IA, la course au calcul ne se joue plus sur les puces mais sur les permis : celui qui verrouille terrain, électricité et autorisations avant l'élection suivante garde un an d'avance sur les autres. Musk l'a compris au Tennessee et au Mississippi, où il a foncé sans trop demander la permission. Au Texas, avec des turbines à gaz garées à côté d'un supercalculateur de plusieurs gigawatts, la nouvelle gouverneure aura de quoi l'embêter. Reste à voir si ça freine vraiment, ou si ça se résume à quelques mois de paperasse en plus.

Buoyant lance Kinference, un plan de contrôle d'inférence open source pour Kubernetes et vLLM

Buoyant, l'entreprise à l'origine du service mesh Linkerd, a publié Kinference, un projet open source sous licence Apache 2.0 destiné à bâtir des plateformes d'inférence sur Kubernetes. Écrit en Rust et disponible dans sa version v0.1.0-alpha.7, il joue le rôle de plan de contrôle devant une flotte de workers vLLM : vLLM reste le plan de données, Kinference décide où part chaque requête. Le système repose sur une passerelle de trafic et un gestionnaire d'inférence exposant une interface gRPC, qui renvoie le point d'arrivée choisi et un corps de requête éventuellement modifié. Il s'associe à un proxy comme la Buoyant Gateway, surveille les événements de cache KV et les métriques des moteurs, et utilise la crate dynamo-kv-router de NVIDIA. La configuration passe par cinq CRD : GatewayBackend, InferencePolicy, InferencePool, InferenceProvider et InferenceWorkerSet. Les politiques, versionnées dans git et validables hors ligne avec la CLI kinfctl, filtrent selon le locataire, le modèle demandé, l'état du pool de GPU ou des étiquettes sémantiques, puis minimisent en général le TTFT prédit à partir du recouvrement de cache et de la longueur des files. Les gains annoncés sont importants sur le trafic riche en préfixes communs, mais ces chiffres sont publiés par Buoyant lui-même. Le test a mobilisé trois pods vLLM 0.31.0, chacun sur un GPU L40S, avec le modèle Qwen3.8-27B-FP8 et la charge générée par GuideLLM 0.8.1. Face à un simple Service ClusterIP, le TTFT médian passe de 6,88 s à 0,31 s (environ -95 %) sur une charge à préfixe partagé, et de 1,70 s à 0,59 s (environ -65 %) en multitour. La latence médiane de bout en bout recule de 45 % et 32 %. Le débit utile, c'est-à-dire les requêtes par minute respectant un objectif de TTFT, atteint 103,0 contre 14,0 requêtes par minute (environ 7,4 fois plus) sur préfixe partagé, et 82,7 contre 23,8 en multitour. Sans préfixe partagé, la médiane ne bouge pas (6,92 s contre 6,83 s), même si le TTFT au 95e centile baisse de 21,46 s à 12,33 s grâce à l'équilibrage tenant compte des files. Pour les équipes qui servent plusieurs modèles ouverts à de nombreux clients internes, Kinference offre dans une seule couche le routage, la limitation de débit en jetons et les métriques par locataire. Les exemples de politiques montrent des usages concrets : envoyer les prompts simples vers un modèle plus petit sauf si le cache rend le grand modèle plus rapide, déborder vers un fournisseur cloud comme Bedrock quand plus de deux prompts sont en file, garder les données personnelles en local avec un rejet par défaut, réserver les requêtes batch aux GPU sous 70 % d'utilisation du cache, ou publier un alias stable de modèle. Cela déplace la logique de gouvernance hors du code applicatif et vers des règles déclaratives auditables. Ces résultats demandent toutefois de la prudence. La référence est un routage aléatoire par kube-proxy, et non un routeur déjà conscient du cache comme llm-d ou Dynamo, ce qui avantage mécaniquement Kinference. Buoyant précise aussi que ses objectifs de latence (8 s et 4 s) conviennent à des agents hors ligne plutôt qu'à du chat interactif. Le projet, encore en alpha, s'inscrit dans la course à l'orchestration de l'inférence sur Kubernetes, où Buoyant cherche à étendre son expertise réseau au monde des LLM face à des projets soutenus par NVIDIA et par l'écosystème cloud natif.

💬 Le vrai sujet, c'est que le routage devient une couche de gouvernance : qui a le droit d'utiliser quel modèle, à quel coût, avec quelles données. Les -95 % de TTFT sont à prendre avec des pincettes (la référence est un routage aléatoire, pas llm-d ni Dynamo, donc forcément flatteur), et sans préfixe partagé la médiane ne bouge pas d'un poil. Mais des politiques versionnées dans git, validables hors ligne, qui gardent les données perso en local ou débordent vers Bedrock quand ça sature, c'est le genre de truc qu'on attendait pour sortir cette logique du code applicatif. Reste à voir si ça tient en prod, v0.1.0-alpha.7 oblige.

SageMaker Inference prend désormais en charge le GPU multi-instance pour optimiser l'utilisation des GPU des endpoints de modèles

Amazon SageMaker Inference prend désormais en charge le partitionnement des GPU grâce à la technologie Multi-Instance GPU (MIG) de NVIDIA, qui découpe un accélérateur physique en partitions indépendantes. Chaque partition reçoit une part fixe des unités de calcul et un bloc dédié de mémoire, avec une isolation garantie au niveau matériel. Jusqu'ici, la plus petite unité réservable pour un point de terminaison GPU était un accélérateur entier : une instance ml.p4d.24xlarge, dotée de huit GPU A100, ne pouvait héberger que huit modèles, qu'ils aient besoin de 40 Go ou de 14 Go. Le MIG permet de scinder un GPU en sept instances au maximum selon le modèle, de placer un modèle différent dans chacune et de mélanger des tailles de tranches sur un même composant. La fonction repose sur les « inference components », la construction qui permet de déployer plusieurs modèles sur un même point de terminaison et de fixer les ressources de chacun. Une partition y devient une ressource demandée au même titre que le processeur ou la mémoire. Les points de terminaison à modèle unique, les points de terminaison serverless et les pools d'instances hétérogènes ne peuvent pas être partitionnés. L'enjeu est double pour les équipes qui exploitent des modèles en production. Elles peuvent d'abord héberger davantage de modèles que de GPU, avec une latence prévisible, puisque chaque partition dispose de sa propre bande passante mémoire et qu'un pic de trafic sur un modèle n'affecte pas le p99 d'un autre. Une panne ou une erreur mémoire reste confinée à sa partition, et la protection mémoire appliquée par le matériel simplifie les revues de sécurité et de conformité. Ensuite, la finesse du découpage évite un dilemme coûteux : à mesure que la concurrence et la longueur des requêtes augmentent, un GPU entier d'ancienne génération devient insuffisant, alors qu'un GPU entier de génération récente dépasse les besoins du modèle. Choisir une fraction d'un accélérateur récent permet d'ajuster la capacité au plus près. Chaque modèle reste chargé dans sa partition, sans démarrage à froid ni éviction, et un test de charge prédit fidèlement le comportement en production, ce qui facilite aussi la répartition des coûts par modèle ou par équipe. Cette annonce répond aux limites des solutions utilisées jusqu'ici. Regrouper les modèles sur des points de terminaison plus gros n'améliore l'utilisation que si les modèles sont interchangeables, ce qui n'est pas le cas de variantes affinées ou de modèles propres à chaque client. Les points de terminaison multi-modèles chargent et déchargent les modèles à la demande, ce qui convient à un trafic sporadique, mais sans isolation entre eux et avec une pénalité au premier appel. Les clients ayant besoin d'un vrai partitionnement se sont donc tournés vers Kubernetes autogéré, au prix d'une charge lourde : versions de pilotes, configuration des partitions, plugin de périphérique, ordonnancement et cohérence sur toute une flotte. SageMaker intègre désormais cette capacité matérielle, déjà présente sur ses instances, dans un service géré.

💬 Selon Le Fil IA, le vrai coût d'un GPU en inférence n'est plus le silicium, c'est la granularité à laquelle tu peux le louer. Payer huit A100 pour héberger huit modèles dont la moitié tient dans 14 Go, c'était du gâchis structurel, pas un choix. Avec le MIG, SageMaker rattrape enfin ce que les équipes bricolaient sur Kubernetes autogéré, et l'isolation matérielle simplifie les revues de conformité. Bon, sur le papier. Reste à voir si ça tient en prod, parce que ni les endpoints à modèle unique ni le serverless ne sont concernés.

Zyphra ZYFA : FlashAttention en FP8 pour l'AMD MI355X, jusqu'à 1,76 fois plus rapide

Zyphra a publié ZYFA (Zyphra FlashAttention on AMD), un ensemble de noyaux d'attention FP8 et BF16 pour la phase de prefill, conçu pour les GPU AMD Instinct MI355X et distribué en open source sous licence Apache 2.0. Sur des activations de modèles réels, les noyaux FP8 tournent 1,16 à 1,76 fois plus vite qu'AITER, la bibliothèque de noyaux par défaut d'AMD, avec une erreur FP8 inférieure de 62 à 78 % pour une dimension de tête de 128. Le meilleur résultat atteint 2 672 TFLOP/s en FP8 pour 32 000 tokens, soit 53 % du pic théorique FP8 (39 % pour AITER). Sur des benchmarks gaussiens, la forme MLA (192/128) atteint 2 464 TFLOP/s contre 1 237, soit un rapport de 1,99. Sur couches réelles à 16 000 tokens, les gains sont de 1,16x pour Mistral-7B, 1,17x pour Qwen3-8B et 1,76x pour DeepSeek-V2-Lite. En BF16, les performances sont quasi identiques (1,01 à 1,02x). Les noyaux BF16 sont écrits en HIP, tandis que les noyaux FP8 sont de l'assembleur ordonnancé à la main, produit par un générateur Python. ZYFA fonctionne uniquement sur MI355X (CDNA4, gfx950) avec ROCm 7.2.3 et PyTorch 2.12. Ces résultats comptent pour quiconque exploite des modèles à contexte long sur du matériel AMD. Le prefill est l'étape coûteuse quand les prompts s'allongent, et ZYFA y gagne aussi en efficacité énergétique : 1,94 et 1,91 TFLOP/J sur des couches de Mistral-7B et Qwen3-8B, contre 1,60 et 1,56 pour AITER. La précision progresse également : face à une référence en fp64, l'erreur de ZYFA représente 0,22 fois celle d'AITER sur Mistral-7B et 0,38 fois sur Qwen3-8B, à quelques pourcents de Composable Kernel et Triton. Sur le modèle Mistral-7B complet, la divergence KL par rapport au fp64 est de 3,4×10⁻³ avec ZYFA contre 5,9×10⁻³ avec AITER, et les sorties sont identiques au bit près sur 7 200 lancements. Le moteur alimente aussi l'optimiseur ZOE, qui fait tourner Zyphra Cloud. Le contexte tient à un déséquilibre matériel. Les instructions matricielles FP8 vont deux fois plus vite qu'en BF16, mais seuls les deux produits matriciels (QKᵀ et PV) en profitent : le softmax, exécuté sur l'unité vectorielle, ne s'accélère pas. Pour 32 requêtes contre 128 clés, le calcul matriciel FP8 prend 1 024 cycles et le softmax exact 896, ce qui exige un recouvrement quasi parfait. Les traces de Zyphra montrent le pipeline matriciel d'AITER inactif 31,7 % du temps, car le MI355X ne suit pas l'achèvement des instructions matricielles en matériel. ZYFA répond par trois techniques. La première, « Lean P », exploite le fait qu'un motif e4m3 lu comme entier croît de 8 à chaque doublement de la valeur : une multiplication-addition remplace l'exponentielle, ramenant le softmax de 896 à 384 cycles par bloc. La deuxième est un ordonnancement « ping-pong » à deux vagues par SIMD, qui porte l'occupation du pipeline matriciel de 60 % à 86 %. La troisième met chaque bloc de 64 clés à l'échelle par une puissance de 2, grâce à l'instruction matricielle à échelle de CDNA4, et divise par la somme des probabilités arrondies. Les gains réels restent inférieurs à ceux des benchmarks, car la fréquence du MI355X dépend du nombre de bits qui basculent : sur Mistral-7B, ZYFA tourne à 1 628 MHz contre 2 108 MHz pour AITER, dont les petites probabilités deviennent zéros ou subnormaux. Zyphra recommande donc de tester sur activations réelles et à fréquence soutenue.

💬 Le vrai message de ZYFA, c'est que le FP8 ne se gagne plus dans la multiplication matricielle mais dans le softmax, là où le matériel n'accélère rien. Zyphra remplace l'exponentielle par une simple multiplication-addition sur le motif e4m3, et ça change tout. Bon, sur le papier le 1,76x sur DeepSeek-V2-Lite est joli, mais sur Mistral-7B on tombe à 1,16x parce que la fréquence du MI355X s'effondre (1 628 MHz contre 2 108). Reste à voir si ça tient en prod, et avec de l'assembleur écrit à la main pour une seule puce, je ne parierais pas sur la portabilité.

Serveur MCP sans serveur à gérer pour l'accès des agents IA à un data lake sur Amazon ECS Fargate

Des équipes d'Amazon chargées du réseau North America Sort Center (NASC) ont conçu un serveur Model Context Protocol (MCP) sans serveur, déployé sur Amazon ECS avec AWS Fargate, afin de donner à des agents d'IA un accès conversationnel au data lake de l'entreprise. Le serveur sert de passerelle centralisée et indépendante des agents entre les modèles de langage et des milliers de jeux de données couvrant les indicateurs opérationnels, l'analyse métier et des données spécialisées. Ajouter un jeu de données ne demande qu'un fichier de métadonnées JSON, que le serveur détecte automatiquement lors de la prochaine synchronisation du pipeline. L'architecture repose sur quatre couches, chacune évolutive et déployable séparément : client, serveur MCP, outils et rafraîchissement de la base de connaissances. Une requête passe par Amazon Route 53, puis par un Application Load Balancer protégé par HTTPS et AWS WAF, avant l'authentification via Amazon Cognito. Le trafic authentifié entre ensuite dans un sous-réseau privé où la couche cliente tourne sur ECS Fargate. Cette approche règle un problème récurrent : chaque équipe intégrait ses propres agents avec sa propre génération SQL, sa connaissance des schémas et sa gestion des connexions. Une modification de schéma obligeait donc à corriger chaque agent individuellement. Le contrôle d'accès était fragmenté, sans point d'audit unique, et l'ouverture d'une nouvelle table exigeait du code d'outil sur mesure, une validation des requêtes et un redéploiement, soit typiquement plusieurs jours de travail par table. Désormais, les droits sont appliqués une seule fois, au niveau du serveur MCP, et tout client compatible MCP (chat web, Slack, extension d'IDE ou agent externe) peut appeler les mêmes outils. L'intégration d'une source de données passe d'un chantier d'ingénierie à une simple configuration, et l'infrastructure élastique absorbe les pics de charge propres aux usages de l'IA. Le projet répond à quatre exigences posées dès le départ : un accès au data lake piloté par la configuration, des interfaces d'outils indépendantes des agents, une application centralisée des permissions et une infrastructure capable de suivre des charges irrégulières. Au cœur du dispositif, un catalogue de métadonnées stocke les descriptions de schémas, la sémantique des colonnes et les relations entre tables, que l'agent consulte au moment de générer le SQL. Les structures de tables n'étant pas codées en dur, un changement de schéma n'impose aucun redéploiement, et la couche de rafraîchissement indexe en continu les nouvelles métadonnées. Le choix s'inscrit dans la montée en puissance de MCP comme standard de connexion entre agents et sources de données, et il illustre une tendance plus large des grandes organisations à mutualiser l'accès aux données plutôt que de multiplier les intégrations ponctuelles. Les équipes de planification du réseau NASC, qui s'appuient sur ces données pour gérer capacité, main-d'œuvre et flux de colis, en sont les premières bénéficiaires, dans un environnement multi-locataire où plusieurs agents et applications partagent la même infrastructure.

💬 Sur le papier, c'est un détail d'infra. En vrai, ce que montre Amazon, c'est que le goulot d'étranglement des agents n'est plus le modèle, c'est la porte d'entrée vers les données. Un serveur MCP central avec les droits appliqués une seule fois, ça tue le bricolage où chaque équipe recodait sa génération SQL dans son coin. Passer de plusieurs jours par table à un simple fichier JSON, c'est le genre de truc qu'on attendait depuis 2 ans. Reste à voir si ça tient en prod quand les schémas se compliquent.

Gouvernez l'accès des agents IA avec Okta Cross App Access et Amazon Bedrock AgentCore (partie 2)

Amazon Web Services a publié la deuxième partie de son guide sur la gouvernance des agents d'IA avec Okta Cross App Access (XAA) et Amazon Bedrock AgentCore. La première partie décrivait un agent de tâches tournant sur le runtime AgentCore, qui agit pour le compte d'utilisateurs connectés. Okta décide quel agent peut agir pour quel utilisateur, et AgentCore Identity échange le jeton d'autorisation d'Okta à l'intérieur de l'agent. Cette seconde partie conserve la configuration Okta, le fournisseur d'identifiants et les deux serveurs MCP (Model Context Protocol) d'origine, mais remplace la topologie. AgentCore Gateway devient le point d'entrée unique et échange lui-même l'autorisation Okta (l'ID-JAG, Identity Assertion JWT Authorization Grant) pour chaque cible. Une politique Cedar, refusant tout par défaut, est évaluée au niveau du Gateway avant chaque listage ou appel d'outil. Un second agent, hébergé sur Amazon EKS avec sa propre identité Okta, utilise son propre Gateway. AgentCore Observability, associé à CloudWatch Transaction Search, collecte les spans OpenTelemetry. Le journal système d'Okta y est acheminé via Amazon EventBridge. Le changement répond à trois limites de la première architecture, acceptables pour un agent et deux outils mais ingérables avec des centaines d'agents et des milliers d'outils. Auparavant, chaque agent connaissait l'identifiant de chaque serveur MCP et l'appelait directement, ce qui crée une matrice de câblage où chaque nouvel outil touche tous les agents concernés. Le rôle de l'agent détenait aussi les droits d'échange de jetons et l'accès au secret du fournisseur, ouvrant à chaque agent un chemin d'identifiants vers chaque ressource. Enfin, chaque serveur répétait le même contrôle de groupes dans son code, avec un risque de dérive et sans audit centralisé possible. Désormais, le rôle de l'agent ne porte plus aucune permission d'échange de jetons ni de secret, et une règle unique, modifiable et auditable en un seul endroit, lie chaque outil à l'agent et au périmètre délégué par Okta. Un appel refusé par Cedar ne déclenche même pas l'échange du jeton. Le fait que l'agent B tourne sur EKS montre que le point d'entrée est indépendant du lieu d'exécution. Le contexte est celui du déploiement d'agents autonomes en entreprise, où la question centrale devient qui peut agir au nom de qui, et avec quels droits. Le flux détaillé reste le suivant : l'utilisateur se connecte, le backend for frontend échange son jeton d'identité contre un ID-JAG destiné à l'agent A, l'agent le transmet au Gateway comme jeton porteur, et l'autorisateur entrant n'accepte que les ID-JAG de cet agent. Le serveur MCP vérifie encore les groupes et le périmètre de l'utilisateur et consigne chaque décision dans un span authz.check. L'article compare aussi XAA avec le consentement OAuth par utilisateur, pour les applications incapables d'accepter la délégation d'Okta.

💬 Selon Le Fil IA, la gouvernance des agents ne se joue plus dans chaque agent mais à la porte d'entrée : celui qui contrôle le Gateway décide qui peut faire quoi, et le reste n'est que de la plomberie. AWS déplace l'échange de jetons et la règle Cedar (tout refusé par défaut) hors du code de l'agent, et c'est enfin une archi qui tient avec des centaines d'agents au lieu d'un seul. Bon, sur le papier, c'est propre. Reste à voir si les équipes acceptent de centraliser autant de pouvoir sur un seul point, qui devient aussi un point de défaillance.

TSMC envisage de produire des puces mémoire avancées pour capter une plus grande part des dépenses liées à l'IA

TSMC envisage de se lancer dans la fabrication de mémoires avancées, une extension qui lui donnerait une part encore plus grande de la chaîne d'approvisionnement du matériel d'IA, selon deux sources au fait du dossier. Le premier fondeur mondial a récemment commencé à élaborer des plans pour produire un type précis de puce mémoire avancée, la DRAM 3D, à la demande de Nvidia, son plus gros client. Cette démarche reste à l'état de réflexion, et aucune décision définitive n'a été annoncée à ce stade. L'enjeu est considérable pour toute la filière. Une pénurie aiguë de puces mémoire, alimentée par l'essor du matériel destiné à l'intelligence artificielle, a fait flamber les prix et poussé des concepteurs de puces comme Nvidia et Apple à chercher des sources d'approvisionnement supplémentaires. Apple a d'ailleurs relevé cette année les prix de ses appareils en invoquant la hausse du coût de la mémoire. Si TSMC se positionnait sur ce segment, il pourrait capter une part plus importante des dépenses liées à l'IA, tout en offrant à ses grands clients une alternative aux fournisseurs actuels, dont l'offre peine à suivre la demande. Pour les utilisateurs finaux, un élargissement de la production pourrait à terme réduire les tensions sur les prix des appareils électroniques et des serveurs. Ce projet s'inscrit dans un contexte où la mémoire est devenue un goulot d'étranglement majeur de l'industrie de l'IA, au même titre que la capacité de gravure avancée et d'assemblage des puces. TSMC domine déjà la fabrication des processeurs d'IA les plus performants, notamment ceux de Nvidia, et la mémoire constitue pour lui un prolongement naturel. La DRAM 3D, qui empile les cellules mémoire en couches pour augmenter la densité et les performances, est présentée comme une piste technologique d'avenir. Reste à savoir si TSMC franchira le pas face à des acteurs établis du secteur de la mémoire, et à quel rythme.

💬 Selon Le Fil IA, la mémoire est devenue le vrai verrou de l'IA, et celui qui la maîtrise tient le robinet, pas seulement celui qui grave les GPU. TSMC fait déjà la loi sur les puces de calcul, s'il met un pied dans la DRAM 3D à la demande de Nvidia, il cherche surtout à ne plus laisser les fournisseurs de mémoire encaisser la marge. Bon, pour l'instant c'est une réflexion, pas une annonce, et passer de la logique à la production en volume, ça prend des années. Reste à voir si ça soulagera nos factures de serveurs avant que la bulle ne se dégonfle.

Après la claque électorale, des promesses pour amadouer les réfractaires aux datacenters

Les démocrates ont remporté une victoire écrasante aux élections de mi-mandat américaines, un scrutin nourri par le ras-le-bol face au coût de la vie, mais où la question de l'intelligence artificielle et des centres de données a aussi pesé. Dans ce contexte, les géants du secteur multiplient les engagements envers les riverains de leurs infrastructures. Dès le 2 octobre, Matt Garman, directeur général d'Amazon Web Services, a publié un billet promettant de ne pas faire grimper les factures d'électricité des habitants, en couvrant l'énergie consommée et le coût des améliorations de réseau nécessaires. AWS affirme aussi vouloir favoriser l'économie locale par des recrutements et des achats sur place, cesser de faire signer des accords de confidentialité aux responsables publics, informer les habitants le plus tôt possible lors de rencontres publiques, utiliser des énergies décarbonées, respecter les normes locales de bruit, privilégier l'eau non potable et publier chaque année des indicateurs de consommation d'énergie et d'eau. L'entreprise s'engage en outre à verser un milliard de dollars sur cinq ans aux collectivités, libres de l'affecter à la formation, à l'éducation, aux coûts de l'énergie ou à la préservation des ressources. Le 5 novembre, OpenAI a publié deux documents: un « Community Compact » listant ses engagements envers les riverains, et un « Compute Campus Policy Blueprint » proposant aux pouvoirs publics un cadre pour encadrer et faciliter la construction de ces sites. Ces annonces comptent parce que les centres de données sont devenus un sujet politique concret pour les électeurs américains. Les critiques portent sur l'opacité des décisions d'implantation, l'impact environnemental, le bruit et l'envolée des factures d'énergie. Les engagements d'OpenAI vont dans le même sens que ceux d'Amazon: payer ses propres besoins énergétiques sans les reporter sur les autres consommateurs, fournir des garanties financières si un projet est retardé, réduit ou annulé, réduire temporairement sa consommation en cas de surcharge du réseau, désigner un interlocuteur local, abandonner les accords de confidentialité, limiter sa consommation d'eau et publier les impacts de chaque site, des emplois aux impôts en passant par le bruit. Pour les collectivités, cela pourrait offrir un levier de négociation inédit. Pour l'industrie, c'est la reconnaissance implicite que l'acceptabilité locale est devenue une condition du déploiement de l'IA. Reste à savoir si ces promesses seront tenues. Sur la transparence, Amazon fait partie des géants du numérique qui ne publient pas de données précises sur les volumes d'eau prélevés ni sur leur consommation électrique, et les indicateurs partiels disponibles sont peu exploitables. OpenAI, de son côté, associe ses engagements à une demande de règles qui facilitent les permis de construire, ce qui nuance la portée de sa démarche. Ces initiatives interviennent alors que les entreprises de l'IA, qui veulent multiplier les centres de données à grande vitesse, sentaient monter la défiance bien avant le scrutin. Avec un paysage politique rebattu par la victoire démocrate, la pression pour obtenir des engagements contraignants plutôt que volontaires pourrait s'accentuer, et la manière dont ces promesses seront vérifiées sera déterminante.

💬 Selon Le Fil IA, quand OpenAI et Amazon promettent de ne plus faire de cachotteries aux riverains, c'est la preuve que l'acceptabilité locale est devenue une contrainte de déploiement de l'IA au même titre que l'énergie ou les puces. Le milliard de dollars d'AWS et le « Community Compact » d'OpenAI, c'est enfin du concret côté communication. Mais bon, sur le papier. Amazon ne publie toujours pas ses vrais chiffres d'eau et d'électricité, et OpenAI colle une demande de permis facilités juste à côté de ses engagements. Tant que ce n'est pas contraignant, ça reste de la négociation, pas de la garantie.

OpenAI renonce aux accords de confidentialité (NDA) pour ses projets de centres de données

OpenAI a annoncé de nouveaux engagements envers les communautés qui accueillent ses projets de centres de données. Le principal est de ne plus recourir à des accords de confidentialité (NDA) avec les responsables publics. L'entreprise précise n'admettre désormais que des protections étroites, limitées aux informations de sécurité légitimes, aux secrets commerciaux et aux informations propriétaires ou sensibles sur le plan concurrentiel. L'annonce tombe en pleine semaine des élections de mi-mandat aux États-Unis, où les électeurs ont exprimé avec netteté leur opposition à l'expansion des centres de données. Ce changement répond à une critique récurrente. De nombreux projets ont été mis en cause pour s'être appuyés sur des NDA afin de masquer les discussions entre promoteurs et élus locaux. Pour les habitants et leurs représentants, cela ouvre la possibilité d'une plus grande transparence sur des installations qui transforment durablement les territoires. La formulation reste toutefois souple : la notion d'information « sensible sur le plan concurrentiel » laisse une marge d'interprétation, et son application réelle déterminera la portée de l'engagement. Cette décision s'inscrit dans une défiance croissante des riverains face à la course aux infrastructures d'intelligence artificielle. Amazon avait déjà annoncé en octobre une démarche allant dans le même sens, ce qui suggère un mouvement plus large chez les grands acteurs du secteur. Pour ces entreprises, l'enjeu est d'obtenir l'acceptation locale, devenue un facteur politique et opérationnel pour poursuivre leurs chantiers. La suite dépendra de l'alignement des autres développeurs et de la pression des élus, qui pourraient exiger les mêmes garanties pour chaque nouveau projet.

💬 Selon Le Fil IA, quand une entreprise renonce aux NDA avec les élus, c'est que l'acceptation locale pèse désormais plus lourd que le secret des chantiers. Bon, sur le papier, c'est une vraie bonne nouvelle pour les riverains, et le timing avec les midterms n'a rien d'un hasard. Mais « sensible sur le plan concurrentiel », c'est une porte grande ouverte : reste à voir si ça tient quand un maire demandera combien d'eau et d'électricité le site va avaler.

Vera combine le meilleur débit et les agents les plus rapides

NVIDIA a présenté Vera, son processeur pour l'ère des agents d'IA, en affirmant qu'une seule puce peut à la fois rivaliser avec les CPU x86 les plus rapides et avec les plus économes en énergie. Dans une comparaison portant sur un centre de données de 100 mégawatts, l'entreprise indique que Vera offre la meilleure vitesse d'exécution des agents du marché tout en permettant d'exploiter 1,6 fois plus d'agents par watt que le CPU x86 le plus rapide. Face au CPU x86 le plus efficace énergétiquement, Vera serait deux fois plus rapide tout en conservant une efficacité de premier plan. Plusieurs partenaires rapportent des résultats en conditions proches de la production. Perplexity a exécuté des tâches de programmation agentique 1,5 fois plus vite qu'avec des CPU traditionnels et prévoit de déployer Vera dans un prochain système de production. DeepInfra a obtenu jusqu'à 2,2 fois la vitesse du meilleur processeur x86 sur l'orchestration d'agents, la meilleure performance parmi les quatre architectures testées. ClickHouse a vu son binaire standard, sans optimisation spécifique, monter en charge de façon quasi linéaire sur 176 cœurs et prendre la tête du classement matériel ClickBench. DuckLabs a mesuré environ 1,5 fois la performance médiane de TPC-H SF1000 d'un Intel Xeon 6, tandis que Modal a atteint jusqu'à deux fois le débit de bacs à sable par cœur face à du x86 comparable. L'enjeu tient à la nature même du travail des agents. Un agent ne se contente pas de générer du texte : il cherche des informations, interroge des bases de données, écrit et teste du code, puis agit. À chaque étape, la tâche passe du raisonnement sur GPU à l'exécution sur CPU, ce qui fait du processeur généraliste un maillon critique. Chez Daytona, 1 000 bacs à sable d'agents ont été lancés en 10,8 secondes avec Vera, contre 88,4 secondes sur x86, et la plateforme a atteint 12,7 tâches terminées par seconde avec 2 000 bacs à sable simultanés. Pour les fournisseurs d'infrastructure, cela signifie pouvoir servir davantage d'agents sans allonger le temps d'attente de chacun, avec une seule référence de CPU plutôt qu'un mélange de puces rapides et de puces denses selon les charges. Ces annonces s'inscrivent dans une contrainte désormais centrale pour l'industrie : les « usines d'IA » sont limitées par la puissance électrique disponible, et non plus seulement par le nombre de puces. Les opérateurs cherchent donc à maximiser le travail accompli par watt, ce qui rend la question de l'efficacité du CPU aussi stratégique que celle du GPU à mesure que les entreprises déploient des agents à grande échelle. En proposant un processeur maison, NVIDIA étend sa présence au-delà des accélérateurs et vient concurrencer directement les offres x86 d'Intel et d'AMD dans les centres de données. Il faut toutefois noter que ces chiffres proviennent de NVIDIA et de ses partenaires, et que leur validation indépendante, ainsi que l'adoption à grande échelle en production, détermineront si Vera s'impose face à un écosystème x86 très établi.

L'IA moins chère peut-elle devancer la fronde contre les centres de données ?

Au lendemain des élections américaines de mardi, qui ont porté au pouvoir des élus favorables à une limitation de l'expansion des centres de données, plusieurs dirigeants et investisseurs du secteur technologique redoutent que de nouveaux retards dans la mise en service de capacités de calcul n'augmentent le coût d'exploitation des serveurs d'IA existants. Depuis le début de l'année, le coût d'utilisation de l'IA a pourtant baissé, alors que le prix de location des serveurs a grimpé. Le modèle GPT-6.1 Sol d'OpenAI, sorti fin septembre, offre des performances comparables à celles du modèle phare GPT-6 Astra lorsqu'il est utilisé avec un niveau de raisonnement élevé, mais pour environ un cinquième du coût par tâche, selon le cabinet Artificial Analysis. Anthropic met en avant des gains d'efficacité similaires avec ses derniers modèles. Cette évolution se produit malgré le renchérissement de l'achat et de la location de matériel Nvidia cette année. Si le calcul devient encore plus cher, la baisse du coût de l'IA pourrait ralentir, ce qui inquiète à l'heure où les entreprises font de ces dépenses une préoccupation majeure. La tendance devra se poursuivre, faute de quoi les clients pourraient réduire leurs usages. Un cadre dirigeant d'un fonds de capital-investissement propriétaire et développeur de centres de données estime que les prix des modèles continueront de baisser grâce aux « gains d'efficacité en tokens », c'est-à-dire la capacité de l'IA à produire davantage avec moins de calcul, par le biais d'avancées matérielles et logicielles, ce qui compenserait les contraintes sur les nouveaux sites. Ce discours est toutefois intéressé, compte tenu des paris financiers déjà engagés par son entreprise. Les marchés ont, dans un premier temps, anticipé une hausse des prix de location : mercredi, les actions des grands fournisseurs de cloud ont progressé, tandis que celles des petits acteurs, qui attendent encore des autorisations pour de nouvelles installations, ont chuté. Les grands groupes ont cédé une partie de leurs gains jeudi. Le contexte reste celui d'une résistance locale croissante aux projets de centres de données. Amazon a ainsi dû abandonner un projet en Virginie cette année, même si Matt Garman, patron d'Amazon Web Services, s'est dit optimiste mercredi lors d'un événement organisé par Blackstone : « Nous sommes plutôt bien placés, et je pense que d'autres ont davantage de travail à faire. » Il n'a pas indiqué s'il anticipait de nouvelles hausses des prix de location. Beaucoup d'installations prévues pour 2027 disposent déjà de tout ou partie des autorisations étatiques ou locales nécessaires, de sorte que l'impact du revirement électoral pourrait surtout toucher les sites visés pour 2028 et au-delà. Enfin, le prospectus d'introduction en Bourse d'Anthropic indique des marges brutes d'environ 85 % sur les neuf premiers mois de l'année, hors coûts de développement des modèles, ce qui lui laisse une marge de manœuvre pour baisser ses prix si nécessaire afin de soutenir la demande.

💬 Le vrai sujet n'est plus le prix du GPU, c'est la vitesse à laquelle les modèles apprennent à faire pareil avec moins de calcul. GPT-6.1 Sol à un cinquième du coût par tâche, c'est ce qui amortit la fronde contre les centres de données, pour l'instant. Bon, sur le papier, ça rassure. Mais si le calcul se renchérit pour de bon, ce sont les clients qui rognent leurs usages, et là les 85 % de marge brute d'Anthropic deviennent un coussin, pas une garantie. Reste à voir si l'efficacité court plus vite que les permis refusés.

Plus de performance par octet : comment la co-conception complète (matériel et logiciel) répond au défi de la mémoire pour l'IA

Nvidia affirme que la réponse à la pénurie de mémoire dans l'IA ne consiste pas à empiler toujours plus de mémoire sur les GPU, mais à concevoir conjointement GPU, CPU, réseau, stockage et logiciels. Le groupe rappelle avoir été le premier à intégrer la HBM3e puis la HBM4 dans une pile de calcul accéléré. Il met en avant un chiffre : entre Blackwell Ultra et la plateforme Vera Rubin, la capacité de HBM par GPU n'a progressé que d'environ 3 %, alors que le débit agentique par dollar a augmenté jusqu'à 30 fois sur le benchmark AgentX de SemiAnalysis. Cette pression vient de modèles de pointe qui comptent désormais des milliers de milliards de paramètres, et d'un cache KV (le contexte que le modèle conserve pour chaque requête active sans avoir à le retraiter) qui enfle. Les trajectoires d'agents transportent le contexte d'appel en appel et peuvent atteindre 3 millions de jetons, tandis que la génération augmentée par récupération (RAG) ajoute encore du contexte à retenir. Parmi les techniques citées, le format NVFP4 réduit l'espace occupé par les poids par rapport au FP8, la précision la plus basse disponible sur Hopper, et ces poids sont répartis sur le domaine NVL72. L'enjeu est économique autant que technique. La HBM est le niveau de mémoire le plus rapide, le plus cher et le plus disputé, car les poids du modèle et le cache KV s'y font concurrence. Nvidia compare la HBM à un entrepôt et la bande passante à ses quais de chargement : un entrepôt plus grand stocke davantage, mais ce sont les quais qui limitent ce qui entre et sort à chaque instant. Chaque utilisateur supplémentaire partage le même calcul et la même bande passante. Quand chacun exige des réponses rapides, la bande passante ne parvient plus à alimenter le calcul, et c'est ce que les ingénieurs appellent le mur de la mémoire. Au-delà, la capacité de HBM ajoutée ne peut plus être exploitée, mais elle continue de coûter de l'argent et de consommer de l'énergie. Pour les opérateurs d'usines d'IA, le rendement de chaque octet compte donc plus que le volume total installé. Ce discours s'inscrit dans un marché où l'offre de mémoire se tend et où les prix montent, une tendance que Nvidia juge appelée à durer à court terme. Le constructeur travaille étroitement avec ses partenaires mémoire pour adopter rapidement les nouvelles générations de HBM, mais il insiste sur la hiérarchie complète d'une usine d'IA : HBM du GPU, mémoire du CPU, SSD locaux et stockage partagé, chaque niveau sacrifiant de la vitesse pour davantage de capacité à moindre coût par bit. La performance dépend alors de la capacité à réduire ce qu'il faut stocker, à le placer sur le bon niveau et à le ramener vers le GPU avant qu'il ne soit nécessaire. Cette approche de codesign vertical, qui s'appuie sur la maîtrise de toute la chaîne par Nvidia, vise à défendre sa position face à des concurrents tentés de rivaliser sur la seule capacité mémoire par puce.

Après la déroute aux élections de mi-mandat, OpenAI cherche à rallier les communautés dont elle a besoin pour son expansion dans l'IA

Les électeurs américains ont massivement rejeté les nouveaux centres de données lors des élections de mi-mandat : sur 41 référendums locaux consacrés à ces projets, 40 se sont soldés par un refus. OpenAI réagit en annonçant une série d'engagements volontaires pour ses futurs sites, destinés à rassurer les communautés locales dont l'entreprise dépend pour étendre son infrastructure d'intelligence artificielle. Ces promesses restent toutefois limitées : elles ne s'appliquent qu'aux installations qu'OpenAI exploite elle-même, alors qu'une large part de ses capacités de calcul est construite et gérée par des partenaires, Oracle en tête. Ce périmètre restreint réduit fortement la portée de l'initiative. Si l'essentiel des centres de données qui alimentent les modèles d'OpenAI échappe à ces engagements, les habitants concernés par les projets les plus nombreux et les plus massifs n'obtiennent aucune garantie de la part de l'entreprise. Le score de 40 refus sur 41 montre que l'opposition n'est plus marginale : elle devient un risque industriel concret, capable de retarder ou d'annuler des projets coûteux, de faire monter les coûts d'implantation et de forcer les acteurs du secteur à négocier site par site. Pour les communes, la question porte sur la consommation d'électricité, la pression sur les réseaux, l'usage de l'eau et les retombées économiques réelles, souvent jugées insuffisantes au regard des nuisances. Cette réaction s'inscrit dans la course à l'échelle que mènent OpenAI et ses concurrents, qui multiplient les annonces de sites géants et de contrats de capacité avec des partenaires comme Oracle. Cette dépendance à des tiers permet d'accélérer les déploiements, mais elle dilue la responsabilité à l'égard des riverains. La suite dépendra de la capacité de l'entreprise à étendre ses engagements à l'ensemble de sa chaîne d'infrastructure, et de la réponse que les élus locaux et les autres opérateurs apporteront à ce signal électoral.

IA agentique : Passer du pilote à la production : la bataille se joue sur l’infrastructure

À la GTC Berlin 2026, ASUS a présenté une gamme d'infrastructures d'intelligence artificielle de bout en bout, dont NVIDIA fournit le moteur. Le constructeur taïwanais a annoncé que ses systèmes HGX Rubin, bâtis sur la prochaine génération d'accélérateurs de NVIDIA, seront prêts à être livrés au quatrième trimestre 2026. L'offre vise à couvrir l'ensemble de la chaîne, du matériel de calcul aux systèmes destinés à faire tourner des modèles en production. L'enjeu dépasse l'annonce commerciale. Avec la bascule vers l'IA agentique, des agents qui enchaînent des tâches de façon autonome, la charge de travail se déplace de l'entraînement vers une inférence permanente. Les modèles ne répondent plus à quelques requêtes ponctuelles : ils fonctionnent en continu, ce qui fait peser sur les entreprises des questions de coût et de consommation énergétique. Pour les directions informatiques, la difficulté n'est donc plus de choisir le meilleur modèle, mais de disposer d'une infrastructure capable de l'exploiter à grande échelle sans que la facture ni la consommation d'électricité ne deviennent ingérables. Ce positionnement reflète le passage de nombreuses organisations du stade de pilote à celui de déploiement réel. Après deux années d'expérimentations, beaucoup butent sur l'industrialisation, où la performance, la fiabilité et l'efficacité énergétique deviennent décisives. NVIDIA reste le fournisseur central des puces, tandis que des constructeurs comme ASUS, en concurrence avec d'autres fabricants de serveurs, cherchent à se différencier par l'intégration et la rapidité de livraison. La suite dépendra de la capacité de ces acteurs à tenir leurs calendriers et à prouver, chiffres à l'appui, la maîtrise des coûts promise.

Together AI lance Together Compiler : des agents rendent l'inférence jusqu'à 2,6 fois plus rapide

Together AI a présenté Together Compiler (TKCC), un système d'optimisation piloté par des agents de codage qui réécrit en continu la passe avant (forward pass) d'un modèle en fonction de l'évolution du trafic de production. À partir d'une commande de lancement de serveur, d'un profil de trafic et d'une configuration matérielle, les agents proposent des versions plus rapides, qu'un moteur persistant mesure ; le code gagnant est intégré au moteur de service, et la boucle repart dès que le trafic dérive. Testé sur Kimi K3, GLM 5.3, MiniMax M3.1 Flash, DeepSeek v4.1 Flash et Llama 1B, sur des puces NVIDIA (B200, B300, GB300, H100), AMD MI355X et AWS Trainium2, avec au plus deux nœuds par modèle, il atteint jusqu'à 2,6 fois plus de tokens par seconde que les meilleures configurations publiées d'InferenceX, en moins de 24 heures par réglage. Le meilleur résultat concerne MiniMax M3.1 Flash sur B200 : 1 111 TPS par utilisateur au P90 contre 633, soit 1,8 fois plus. Le plus faible touche GLM 5.3 sur MI355X, de 463 à 480 TPS (environ 4 %). DeepSeek v4.1 Flash passe de 943 à 1 205 sur GB300, GLM 5.3 de 329 à 417 sur B200 et Kimi K3 de 423 à 450 sur GB300 (chiffres communiqués par l'entreprise). L'enjeu est qu'un moteur réglé une fois devient obsolète. Selon Together AI, la forme du trafic ne cesse de bouger : les prompts atteignent environ 97 000 tokens dans un pays contre 70 000 ailleurs, et la longueur d'entrée au P90 d'un client est passée de 18 000 à 33 000 tokens en trois jours. Optimiser sur des données aléatoires peut aussi tromper : elles activent 13 à 38 % d'experts MoE de plus que le trafic réel, et un noyau top-k écrit par un agent prenait 20 µs sur données aléatoires mais jusqu'à 62 ms sur données réelles à 70 000 tokens de contexte. Le système réduit en outre le coût des expériences. Là où les boucles classiques redémarrent vLLM, SGLang ou TensorRT-LLM à chaque essai (761 secondes de démarrage à froid pour MiniMax sur TensorRT-LLM), Together Compiler lance le moteur une seule fois, injecte les candidats par appel RPC, remplace le pointeur de fonction et recapture les graphes CUDA. Ce procédé donne un débit d'expériences 252 fois supérieur. Le contexte tient à la montée des modèles MoE géants et à la diversité du matériel. Un modèle de coût classe d'abord les dispositions de parallélisme (tenseur, experts, données, contexte) en combinant fiches techniques, microbenchmarks et passes mesurées : pour MiniMax, il a retenu TP8 plutôt que TP4, ce qui divise par deux le trafic mémoire des poids par GPU, et sur Kimi K3 il a trouvé une disposition de production gagnant jusqu'à 24 %. Deux niveaux de mesure, un rapide sur 12 couches et un lent sur 60, ont testé 8,1 fois plus de candidats (1 354 contre 168) et trouvé une solution 7,2 % plus rapide. Les équipes ont aussi constaté que les agents n'avaient pas besoin d'une base de connaissances d'experts : elle réduisait le gain de 25 à 31 % après 12 heures, et des agents naïfs ont dépassé les stratégies expertes (6,2x contre 4,9x). Ils reçoivent désormais le code source brut du moteur. Sur Llama 1B, le système devance les mégakernels de Hazy Research, Mirage et les bases CUDA graph jusqu'à 1,7 fois, et il accélère aussi huit modèles scientifiques.

💬 Un moteur d'inférence réglé une fois, c'est un moteur périmé dans trois jours : un client qui passe de 18 000 à 33 000 tokens au P90 suffit à ruiner l'optimisation. Selon Le Fil IA, la vraie bascule n'est pas le 2,6x (chiffres maison, à prendre avec des pincettes), c'est que l'optimisation d'inférence devient un processus continu calé sur le trafic réel, plus un réglage livré une fois. Le détail qui me parle le plus : des agents naïfs ont battu les stratégies expertes (6,2x contre 4,9x). Reste à voir si ça tient en prod, mais l'idée de benchmarker sur du vrai trafic plutôt que sur des données aléatoires, ça, c'est du bon sens enfin appliqué.

Le Texas, nouvel épicentre des centres de données d'IA, pourrait perdre cette place

Le Texas, premier marché de centres de données aux États-Unis et terrain des plus grands chantiers d'infrastructure d'IA des géants technologiques, a basculé politiquement lors des élections de mi-mandat. Le démocrate James Talarico a remporté le siège de sénateur face à Ken Paxton, et Gina Hinojosa a battu le gouverneur républicain sortant Greg Abbott. Les démocrates reprennent aussi la Chambre des représentants du Texas pour la première fois en 24 ans. Talarico et Hinojosa ont fait des centres de données un thème central de leur campagne. Hinojosa avait soutenu des allègements fiscaux pour ces sites en 2023, au nom de l'emploi dans la construction, mais elle plaidait désormais pour un moratoire complet. Abbott avait lui-même changé de cap dès septembre : le 21, il a demandé à un régulateur clé de l'État de suspendre les permis, et les développeurs affirment que son cabinet a cessé de répondre à leurs courriels. L'enjeu est considérable pour les hyperscalers. Stargate Frontier, dans le comté de Shackelford, doit atteindre 1 820 mégawatts, soit l'équivalent du plus grand centre de données du pays, Colossus 2 de SpaceX au Tennessee, et plus du double du plus grand site actuellement en service au Texas. Nexus Hubbard, destiné surtout à Anthropic, prévoit 6 400 mégawatts, ce qui en ferait le deuxième plus grand projet américain, derrière Hyperion de Meta en Louisiane. Des retards ou des moratoires alimenteraient la crainte d'un coup d'arrêt de la course à l'IA, alors que les banques deviennent déjà plus sélectives. Comme ces chantiers soutiennent une part importante de la croissance économique, les répercussions pourraient dépasser le secteur technologique. Le message des électeurs dépasse le seul Texas. Partout dans le pays, ils ont soutenu des mesures protégeant les consommateurs contre les hausses de factures d'électricité imputables aux centres de données, et certains ont même approuvé des interdictions plus larges de nouveaux sites. L'épisode illustre l'échec de la Big Tech à convaincre le public que l'abondance promise par l'IA améliorera les soins, baissera les prix et multipliera les découvertes scientifiques. Le lien entre vote et implantation des sites reste toutefois nuancé : le comté de Dallas et ses voisins ont voté démocrate, tout comme le comté de Cameron, près de la frontière sud, qui a basculé. En revanche, le comté d'Ellis, premier pour les demandes de permis, ainsi que ceux de Mitchell et de Scurry, où se concentrent des projets du Texas occidental, sont restés républicains. Aucune instance unique ne tranche : les villes, les comtés et l'État se partagent les décisions, si bien que le poids réel des nouveaux élus dépendra aussi des responsables locaux.

💬 Le Texas était censé être le terrain de jeu sans friction de l'IA américaine, et ce vote montre que la facture d'électricité est devenue le vrai juge de paix des centres de données. Quand même Abbott gèle les permis avant le scrutin, c'est que l'acceptabilité locale pèse désormais plus lourd que les allègements fiscaux. Pour Stargate et Nexus Hubbard, le risque n'est pas un moratoire total (les comtés républicains restent producteurs de permis), c'est des mois de retard et des banques qui deviennent frileuses. Bon, sur le papier le pouvoir est éclaté, mais reste à voir si ça tient en prod.

NVIDIA présente 3 méthodes pour accélérer l'inférence MoE sur DGX Spark, avec un gain de 42,5 % de débit pour Ling-3.0-flash

NVIDIA a publié un billet technique qui montre comment accélérer l'inférence des modèles à mélange d'experts (MoE) sur un seul DGX Spark. Le modèle de test est Ling-3.0-flash d'inclusionAI (Ant Group), un MoE de 124 milliards de paramètres dont 5,1 milliards sont actifs par token, avec un contexte natif de 256K. NVIDIA a empilé trois optimisations: un nouveau backend de noyaux MoE, une couche de sortie en FP8 et le décodage spéculatif intégré au modèle. Sur les 1 319 questions de GSM8K, le débit de décodage passe de 37,81 à 53,89 tokens par seconde, soit +42,5 %, avec une latence moyenne réduite de 24,5 % et une précision inchangée de façon statistiquement détectable (96,89 % contre 96,82 %). Concrètement, le backend Humming remplace les noyaux MXFP4 de FlashInfer et compile ses noyaux à la volée en quelques secondes, contre plusieurs dizaines de minutes pour la voie CUTLASS, ce qui apporte +9,3 %. La tête de langage (LM head), une matrice de 157 184 x 2 560 en BF16 lue en entier à chaque token, est quantifiée en FP8 au chargement via SGLANGENABLEFP8LMHEAD=1, pour 43,94 tokens par seconde combinés à Humming. Enfin, la couche de prédiction NEXTN livrée avec le modèle (MTP) propose trois tokens vérifiés par groupes de quatre. Sur un test synthétique, le débit atteint 102,88 tokens par seconde, soit +185,1 %. L'intérêt tient au fait que le DGX Spark est une machine de bureau et non un nœud de centre de données. Les mesures montrent qu'un MoE de 124 milliards de paramètres peut répondre à un seul utilisateur nettement plus vite sur cette machine posée sur un bureau. Le profilage à taille de lot 1 indique que le décodage est limité par la mémoire: lire les poids du modèle domine le temps d'exécution, en particulier le calcul MoE et la tête de langage. Deux leviers en découlent: déplacer moins d'octets par étape et générer plus de tokens par cycle de vérification. Les trois techniques ne se recoupent pas, les deux premières réduisant le coût de chaque étape et la troisième le nombre d'étapes. Les gains restent toutefois dépendants de la charge: sur GSM8K, le taux d'acceptation du MTP tombe de 3,90 à 2,68 tokens par cycle, ce qui explique l'écart entre +185,1 % en synthétique et +42,5 % en conditions réelles. Le DGX Spark repose sur la puce GB10 Grace Blackwell, avec 128 Go de mémoire unifiée, 273 Go/s de bande passante et jusqu'à un pétaFLOP en FP4 creux. NVIDIA le donne pour l'inférence de modèles jusqu'à 200 milliards de paramètres. La référence de départ suivait la recette officielle W4A8, avec des noyaux FlashInfer MXFP4, du GEMM dense CUTLASS et un chemin LM head en FP32, et affichait 27,71 ms par token (36,09 tokens par seconde) sur un test de 32K tokens en entrée et 2K en sortie. L'empilement n'est pas automatique: si la tête FP8 et le MTP sont activés ensemble, le brouillon doit partager le module complet de la tête de langage. Sinon, le framework retombe silencieusement sur un autre chemin et le brouillon lit les poids FP8 comme du BF16. La longueur d'acceptation tombe alors à 1,00 et le débit passe sous celui de la référence non optimisée. NVIDIA recommande donc de vérifier au démarrage que chaque optimisation est bien active, et renvoie vers le notebook du cookbook Ling pour reproduire la configuration.

💬 Le goulot, c'est la mémoire, pas le calcul : à taille de lot 1, un MoE se joue sur le nombre d'octets qu'on déplace par token, et NVIDIA le prouve sur une machine de bureau. Les +185 % en synthétique, c'est de la vitrine, les +42,5 % sur GSM8K sont le vrai chiffre, et c'est déjà très bien pour un 124 milliards qui tourne chez toi. Mais attention au piège : activer la tête FP8 et le MTP ensemble sans réglage fait tomber le débit sous la référence, sans aucune erreur visible. Reste à voir si ça tient en prod, parce qu'une optimisation qui échoue en silence, ça se vérifie au démarrage.

F3 Lightning : comment Meta accélère la mise en production des fonctionnalités de machine learning pour les publicités

Meta a présenté F3 Lightning, une couche d'infrastructure construite au-dessus de son Facebook Feature Framework (F3), le système qui permet de concevoir, compiler et servir les caractéristiques d'apprentissage automatique alimentant les modèles de classement publicitaire. Une seule requête peut nécessiter plus de 20 000 caractéristiques. F3, dévoilé à AI @ Scale 2020, compilait toutes les caractéristiques en un unique graphe fusionné, ce qui réduisait les coûts de calcul. Mais ce graphe servait aussi d'unité de livraison : une défaillance ou une définition invalide bloquait toute la chaîne. F3 Lightning découple les livraisons de l'exécution partagée, de sorte que chaque caractéristique est compilée, validée, déployée et annulée indépendamment. Résultat annoncé : des caractéristiques d'extraction comparables arrivent en production environ 3,6 fois plus vite qu'avec F3, sans hausse du coût d'infrastructure. Ce gain compte d'abord pour les équipes qui itèrent sur les modèles publicitaires. Un cycle de livraison plus court permet davantage d'itérations sur la même période, donc des modèles améliorés plus souvent. La difficulté était de conserver l'efficacité de F3. Les premiers prototypes de livraison par caractéristique faisaient grimper l'usage du CPU, car des caractéristiques indépendantes ne partageaient plus leurs calculs. Meta a comblé cet écart par quatre optimisations : des identifiants de calcul stables, un plan d'exécution partagé unique, un tampon mémoire commun à toutes les caractéristiques et une table d'index denses permettant l'accès direct aux tableaux. L'enjeu dépasse la publicité : tout système de serveur de caractéristiques à grande échelle doit arbitrer entre mutualisation des calculs et indépendance des déploiements. Le contexte tient à l'architecture de F3. Un système de production ne consomme presque jamais de données brutes : il lit des signaux stockés, filtre les événements sur une fenêtre temporelle, compte, somme, normalise et combine des résultats intermédiaires. Traiter chaque caractéristique comme une fonction isolée est simple, mais gaspilleur, car un compteur de clics sur sept jours et un compteur d'impressions sur sept jours lisent souvent la même source et appliquent le même filtre, qu'un taux de clics réutilise ensuite. F3 représente donc l'extraction sous forme de graphe orienté acyclique : chaque nœud réalise une opération, chaque arête une dépendance. Le compilateur fusionne les graphes de toutes les caractéristiques d'un service et regroupe les nœuds en double, si bien que le travail commun s'exécute une fois par requête. Le revers est apparu avec la croissance : F3 servait au départ quelques centaines de caractéristiques, où les fusions réussissaient presque toujours. Avec des milliers de définitions rédigées indépendamment, les échecs sont devenus fréquents. Dans l'exemple de Meta, sept caractéristiques dont deux erronées (D et G) exigent trois tentatives de construction avant que le graphe complet n'atteigne la production.

Présentation de l'inférence en Inde pour Kimi K3 sur Amazon Bedrock

Amazon Bedrock propose désormais l'inférence « en pays » en Inde pour Kimi K3, un modèle de fondation multimodal à poids ouverts développé par Moonshot AI, qui affirme avoir atteint à sa sortie un niveau de pointe en programmation et en intelligence agentique générale. Le modèle est accessible via des profils d'inférence inter-régions : le profil global (global.moonshotai.kimi-k3), recommandé pour la plupart des usages car le moins cher et le plus largement disponible, et le profil géographique indien (in.moonshotai.kimi-k3), qui garantit que le traitement reste dans les régions de Mumbai et d'Hyderabad. Les données sont chiffrées en transit entre régions et restent sur le réseau AWS, sans passer par l'internet public ni nécessiter d'infrastructure VPC multi-régions. AWS publie aussi un exemple de reconnaissance optique de caractères (OCR) sur des documents en langues indiennes, avec questions de suivi en hinglish, mélange de hindi et d'anglais. Cette option répond aux charges de travail soumises à des exigences strictes de résidence des données, fréquentes dans les services financiers et le secteur public indiens, où les formulaires KYC (connaissance du client), factures d'énergie et documents similaires doivent être numérisés. Kimi K3 lit et analyse directement des images contenant du texte multilingue, ce qui peut éviter de recourir à un service d'OCR ou de traduction distinct. Ultrahuman en fournit un témoignage de production : son assistant santé Jade, intégré à l'application, répond en langage naturel à partir des données de la bague connectée et de glycémie de chaque utilisateur, dans plus de 14 000 conversations par jour. Aditya Patawari, vice-président ingénierie, indique que la société a pu ajouter un modèle ouvert de premier plan via l'API déjà utilisée, avec des données de santé qui restent dans AWS et Mumbai comme région de repli. Grâce à la mise en cache des prompts, les coûts liés au modèle ont baissé de 80 % et les conversations à plusieurs tours sont 85 % plus rapides. Cette annonce s'inscrit dans la montée des exigences de souveraineté et de localisation des données, qui poussent les fournisseurs de cloud à multiplier les options d'inférence régionales plutôt qu'un traitement mondial unique. Pour les entreprises indiennes, notamment dans les secteurs réglementés, elle permet d'adopter des modèles à poids ouverts de dernière génération sans renoncer à la conformité. Le tutoriel d'AWS détaille la configuration : un compte AWS, Python 3.11 ou supérieur, la ligne de commande AWS et des autorisations IAM permettant d'invoquer le modèle via le profil indien, par exemple depuis la région ap-south-1 de Mumbai, avec accès aux régions ap-south-1 et ap-south-2. Le code complet est disponible sur GitHub, et la fiche du modèle Kimi K3 sur Bedrock recense les profils disponibles, les régions d'appel et les régions de destination possibles, appelées à évoluer.

💬 Le vrai sujet n'est pas Kimi K3, c'est que la résidence des données devient une option de catalogue : un profil d'inférence, un préfixe « in. », et la conformité se règle en une ligne de config. Selon Le Fil IA, les modèles ouverts chinois passent désormais par les clouds américains pour entrer dans les secteurs réglementés, et c'est AWS qui encaisse la confiance. Bon, sur le papier. Les chiffres d'Ultrahuman (80 % de coûts en moins grâce au cache) sont tentants, mais reste à voir si ça tient hors d'un cas client soigneusement choisi.

L'IA transforme le fonctionnement des usines de semi-conducteurs et accélère le travail des ingénieurs

L'industrie des semi-conducteurs mise sur l'intelligence artificielle pour accélérer le travail de ses ingénieurs, dans ce que Nvidia appelle une « usine définie par l'IA ». L'accélération du calcul raccourcit les simulations multiphysiques, qui modélisent les interactions entre chaleur, comportement électrique et contraintes mécaniques. Grâce à la bibliothèque NVIDIA cuDSS, l'éditeur COMSOL annonce des gains allant jusqu'à 10 fois. Applied Materials indique que sa plateforme Ginestra, dédiée à la découverte de matériaux à l'échelle atomique, tourne jusqu'à 10 fois plus vite qu'avec des processeurs seuls. Avec PhysicsNeMo, sa plateforme ACE+ simule la topographie jusqu'à 35 fois plus vite. Siemens intègre cuLitho à son logiciel de lithographie Calibre, pour jusqu'à 17 fois plus de vitesse sur certaines charges clés. Lam Research a montré que PhysicsNeMo prédit le comportement d'un plasma de gravure en quelques millisecondes, contre plusieurs jours pour une simulation complète. Applied Materials utilise aussi des jumeaux numériques bâtis sur Omniverse pour optimiser l'agencement, le débit, les coûts et le contrôle des procédés d'une usine. L'enjeu est très concret pour les ingénieurs de process. Les essais physiques sur une ligne de production sont lents et coûteux, et une mauvaise décision sur le rendement ou la qualité a des conséquences financières directes. Pouvoir comparer davantage de variantes en simulation avant de lancer un essai réel réduit ce risque et le temps d'attente. Dans certains cas, l'accélération rend même possible ce qui ne l'était pas : les calculs de lithographie computationnelle, qui définissent comment les motifs de circuits sont imprimés sur le silicium, sont trop lourds pour être menés à l'échelle de production sur CPU. Les ingénieurs conservent la décision, mais passent moins de temps à attendre des réponses, ce qui peut raccourcir les cycles de développement de puces avancées. Ces annonces s'inscrivent dans un contexte de demande croissante pour les puces de pointe, alors que leur fabrication se complexifie et que la marge d'erreur se réduit. Nvidia, fournisseur des bibliothèques de calcul accéléré, positionne ses outils au coeur des logiciels de simulation que les fabricants d'équipements et de logiciels de conception utilisent déjà, avec COMSOL, Applied Materials, Siemens et Lam Research comme partenaires. L'article évoque aussi des agents d'IA chargés d'enchaîner des tâches d'ingénierie qui mobilisaient auparavant des heures de travail, ainsi que des jumeaux numériques pour tester les changements avant tout essai physique. La suite dépendra de la capacité de ces outils à tenir leurs promesses à l'échelle de la production, là où le coût d'une erreur reste le plus élevé.

Votre PC a-t-il assez de RAM pour l’IA ? Microsoft prépare une classification en 4 niveaux et 8 Go de RAM suffisent

Microsoft s'apprêterait à classer ses PC dopés à l'intelligence artificielle en quatre niveaux, selon une présentation officielle qui circule sur le réseau social X et que relaie Frandroid. L'échelle part des ordinateurs portables dotés de 8 gigaoctets de mémoire vive et monte jusqu'à des machines de type supercalculateur, qui dépasseraient 128 gigaoctets de RAM. La capacité mémoire servirait de critère central pour situer chaque appareil dans cette hiérarchie. Le document n'a pas été confirmé officiellement par l'éditeur à ce stade. Pour les acheteurs, une telle grille offrirait un repère simple dans un marché où les mentions « PC IA » se sont multipliées sans définition claire. Le fait que 8 Go suffisent pour entrer dans la première catégorie suggère que certaines fonctions d'IA locales pourraient tourner sur des configurations modestes, alors que les usages les plus lourds, comme l'exécution de grands modèles de langage en local, seraient réservés aux niveaux supérieurs. Les constructeurs, eux, disposeraient d'un cadre pour positionner leurs gammes, de l'ultraportable d'entrée de gamme à la station de travail. Cette classification s'inscrit dans la stratégie de Microsoft, qui pousse Windows et Copilot vers l'IA exécutée directement sur l'appareil. Jusqu'ici, la marque « Copilot+ PC » reposait surtout sur la puissance de l'unité de calcul neuronal, avec des exigences de mémoire plus élevées. Un système à plusieurs paliers pourrait élargir le parc d'appareils concernés, au moment où Intel, AMD et Qualcomm rivalisent sur les puces dédiées à l'IA. Reste à savoir si Microsoft officialisera cette grille et selon quel calendrier.

OpenAI rebaptise discrètement ses centres de données en « campus de calcul

OpenAI a commencé à parler de «campus de calcul» (compute campuses) plutôt que de centres de données. L'entreprise a introduit ce vocabulaire lundi, dans l'annonce de son nouveau «Grid Protectors Program». Cette initiative débute avec un futur site dans le comté d'Effingham, en Géorgie. Le changement de terminologie n'a pas fait l'objet d'une communication à part. Il apparaît dans le texte de présentation du programme, ce qui explique que la presse parle d'un rebranding discret. Le campus Stargate d'Abilene, au Texas, sert d'illustration à ce type d'infrastructure. L'enjeu est d'abord politique. Les centres de données sont perçus comme bruyants, gourmands en ressources et inesthétiques. Leur impopularité est telle qu'elle a produit une rareté dans le paysage américain actuel: une opposition bipartisane. Pour OpenAI, cette hostilité menace directement le déploiement des infrastructures qui alimentent le boom de l'IA. Elle peut se traduire par des blocages locaux, des refus de permis ou des pressions sur les élus. Un vocabulaire plus avenant pourrait désamorcer une partie de ces résistances. Le nom du programme, qui évoque la protection du réseau électrique, vise aussi à répondre aux craintes des riverains sur la consommation d'énergie. Ce choix de mots s'inscrit dans la course aux capacités de calcul que mènent OpenAI et ses concurrents. Elle les oblige à multiplier les sites géants et à composer avec les communautés qui les accueillent. Reste à savoir si un simple changement d'étiquette suffira à convaincre des habitants et des élus. Ceux-ci jugent surtout ces projets sur leur impact concret, et non sur leur nom.

Anthropic vante les compétences de Claude en conception de puces auprès des investisseurs de son introduction en Bourse

Anthropic affirme à ses futurs investisseurs que ses propres modèles Claude lui donnent un avantage dans un domaine qui lui est pourtant étranger : la conception de puces d'intelligence artificielle. Selon quatre personnes au fait des discussions, l'entreprise a indiqué lors de récentes réunions que sa nouvelle équipe de conception de puces, composée de 15 personnes, utilise déjà Claude pour le travail d'ingénierie et de design de ses puces sur mesure. Les ingénieurs ont constaté que le modèle réduit le temps nécessaire pour concevoir une puce, par rapport à leurs estimations des méthodes de travail traditionnelles chez de grands concepteurs comme Nvidia et Advanced Micro Devices (AMD), d'après certaines de ces sources. Ces échanges ont lieu alors qu'Anthropic se dirige vers une introduction en bourse prévue plus tard ce mois-ci, qui pourrait la valoriser autour de 1 500 milliards de dollars. L'argument vise à montrer que les modèles d'Anthropic ne se limitent pas aux usages où ils ont déjà fait leurs preuves. Si ces résultats se confirment, une équipe de seulement 15 personnes pourrait rivaliser en rapidité avec les processus de groupes établis de longue date, ce qui suggère qu'un modèle d'IA peut compenser un manque d'expérience et d'effectifs dans un métier très spécialisé. Pour les investisseurs, c'est aussi un signal sur la capacité de l'entreprise à mieux maîtriser l'un de ses principaux postes de dépense, le matériel de calcul. Il faut toutefois relever que ces comparaisons reposent sur des estimations internes des ingénieurs et non sur des mesures indépendantes. Claude s'est déjà fait remarquer pour avoir aidé à mettre au jour de graves vulnérabilités informatiques et pour avoir transformé la profession de développeur. La conception de ses propres puces représente un terrain d'un autre ordre, où Anthropic affronte indirectement des acteurs dominants comme Nvidia et AMD, dont elle reste par ailleurs cliente dans l'écosystème de l'IA. Pour une entreprise qui s'apprête à entrer en bourse avec une valorisation aussi élevée, démontrer que sa technologie accélère son propre développement matériel nourrit le récit d'un cercle vertueux entre modèles et infrastructures. La suite dépendra de la capacité de cette petite équipe à livrer des puces concrètes, et de l'accueil que les marchés réserveront à cette promesse lors de l'introduction en bourse.

💬 Selon Le Fil IA, quand une équipe de 15 personnes prétend battre Nvidia et AMD sur le temps de conception, ce qu'Anthropic vend aux investisseurs n'est pas une puce, c'est la preuve que Claude accélère son propre développement. Bon, sur le papier, c'est un joli cercle vertueux. Mais les gains sont des estimations internes, sans mesure indépendante, et à 1 500 milliards de valorisation, ça ressemble beaucoup à un argument de roadshow. Reste à voir si une vraie puce sort, et si elle tient en prod.

Des villes dans le monde déploient des services d'IA avec les technologies NVIDIA d'IA physique et d'agents autonomes

NVIDIA et ses partenaires étendent à des villes du monde entier le déploiement d'IA physique et d'agents d'IA, en prolongeant les initiatives annoncées au GTC Berlin. En Espagne, 1MillionBot associe les modèles ouverts ALIA, entraînés au Barcelona Supercomputing Center, à NVIDIA Nemotron pour des agents destinés aux résidents. Ils équipent Madrid Digital (Comunidad de Madrid), l'Administració Oberta de Catalunya et plus de 150 déploiements, et traitent démarches municipales, demandes de rendez-vous, incidents d'urbanisme et questions de service. Dans la région de la baie de San Francisco, LiveX développe des hôtes conversationnels fondés sur Cosmos, Nemotron, Omniverse et Metropolis, sur des GPU RTX PRO, pour les aéroports, hôpitaux et événements locaux. À Wrocław, en Pologne, K2K bâtit une infrastructure partagée qui transforme les flux de caméras existants en renseignements exploitables pour la mobilité, la sécurité et la gestion d'événements. En Malaisie, ITMAX propose des services gérés à long terme. Ses agents de vision SamurAI V2, déployés sur des GPU RTX PRO 6000, doivent couvrir plus de 17 000 caméras d'ici 2027. L'intégration du simulateur open source TeraSim, de Laplace Intelligence, pour tester les cycles de feux aurait réduit jusqu'à 26 % les temps de trajet en heure de pointe. Au Nigeria, Honeywell utilise des agents Nemotron à la raffinerie Dangote de Lekki, avec un jumeau numérique prévu, tandis qu'à Taïwan, Linker Vision et le cabinet néerlandais MVRDV conçoivent des agents ESG évaluant l'impact environnemental de projets d'urbanisme. L'enjeu pour les municipalités est de transformer des données massives, issues de caméras, de capteurs et de systèmes opérationnels, en décisions concrètes de planification, de maintenance et de service public. NVIDIA souligne que le ticket d'entrée reste modeste : selon la charge de travail, des stations RTX ou un petit système GPU peuvent suffire. Une infrastructure de calcul mutualisée permet à plusieurs services municipaux, communes voisines et développeurs locaux de partager les mêmes ressources, sans que chacun doive acheter et gérer son propre matériel. Les collectivités gardent en outre la maîtrise du traitement de leurs données sensibles. Les chiffres d'ITMAX montrent que l'IA peut produire des gains mesurables sur des problèmes très quotidiens comme la congestion routière, et la réutilisation de la même infrastructure pour plusieurs fonctions, comme à Wrocław, améliore le retour sur investissement. Ces annonces s'inscrivent dans la stratégie de NVIDIA de faire de l'IA physique et agentique un marché à part entière, bien au-delà des centres de données des grands acteurs du cloud. Les villes sont un terrain naturel, car elles disposent déjà de vastes parcs de caméras et de capteurs sous-exploités. L'utilisation de modèles ouverts comme ALIA et Nemotron répond aussi à des préoccupations de souveraineté, de langues locales et de transparence, particulièrement sensibles dans le secteur public européen. Les jumeaux numériques, bâtis sur Omniverse, étendent cette logique de la relation avec les habitants vers l'infrastructure critique, de la planification urbaine aux sites industriels. La suite dépendra de la capacité de ces projets à passer de déploiements pilotes à des services durables, financés par des contrats de long terme, tout en respectant les exigences de protection des données.

💬 Selon Le Fil IA, la vraie bascule n'est pas l'agent qui répond au guichet, c'est la caméra municipale qui devient un capteur à tout faire : NVIDIA ne vend plus des GPU aux villes, il leur vend l'idée que leur parc existant dort sur une mine de données. Les 26 % de trajets en moins à Kuala Lumpur viennent d'une simulation et d'un conditionnel, donc je garde mes réserves. Mais côté Europe, des modèles ouverts comme ALIA dans des administrations espagnoles, c'est enfin du concret sur la souveraineté. Reste à voir si ça tient en prod, avec des budgets publics qui durent plus de deux ans.

ChatGPT subit des perturbations : ce que l’on sait de la panne en cours

ChatGPT connaît des perturbations chez une partie de ses utilisateurs ce lundi 2 novembre 2026. Le service d'OpenAI fonctionne de façon irrégulière, certains internautes parvenant à l'utiliser normalement pendant que d'autres rencontrent des erreurs ou des lenteurs. Un site d'information indien met en cause une panne du réseau de Cloudflare, le prestataire d'infrastructure qui achemine et protège une part considérable du trafic web mondial. Cette hypothèse n'a toutefois reçu aucune confirmation officielle à ce stade, ni de la part d'OpenAI ni de celle de Cloudflare. Pour les utilisateurs, l'enjeu est concret. ChatGPT est devenu un outil de travail quotidien pour des millions de particuliers, d'étudiants et de professionnels, qui l'emploient pour rédiger, programmer ou analyser des documents. Une interruption, même partielle, suffit à bloquer des tâches en cours. Elle rappelle aussi à quel point des services d'intelligence artificielle très populaires reposent sur un nombre restreint de fournisseurs d'infrastructure, ce qui concentre les risques. Ce n'est pas la première fois qu'une défaillance d'un acteur de l'infrastructure internet se répercute sur de nombreux sites à la fois. Fin 2025, des pannes de Cloudflare avaient déjà rendu inaccessibles plusieurs plateformes majeures, dont ChatGPT. La cause exacte de l'incident du jour reste donc à établir. Il faudra attendre les pages d'état officielles des deux entreprises, ou une communication de leur part, pour savoir si le réseau de Cloudflare est réellement en cause et quand le service sera pleinement rétabli.

OpenAI propose des centrales électriques pour ses centres de données afin de protéger les riverains

OpenAI a annoncé lundi le lancement pilote de son « Grid Protectors Program » sur un futur centre de données du comté d'Effingham, en Géorgie. L'entreprise promet de libérer jusqu'à 1 000 mégawatts de puissance en cas de conditions météorologiques extrêmes ou d'urgence sur le réseau, soit de quoi alimenter la climatisation d'environ 700 000 foyers. Le dispositif repose sur l'idée que le site, doté de ses propres capacités de production, pourrait réduire son prélèvement sur le réseau public, voire lui restituer de l'énergie, lorsque la demande des habitants atteint ses pics. L'enjeu est considérable pour les riverains et les gestionnaires de réseaux. Les grands centres de données sont de plus en plus accusés de peser sur les capacités électriques locales, de faire grimper les factures et de fragiliser l'approvisionnement lors des canicules ou des tempêtes. En s'engageant à effacer une partie de sa consommation au moment critique, OpenAI cherche à transformer un facteur de risque en garantie de sécurité pour les communautés voisines. Reste à voir si cet engagement sera contraignant, vérifiable et appliqué dans les faits, car il repose pour l'instant sur une promesse de l'entreprise plutôt que sur une obligation réglementaire. Cette annonce intervient alors que l'opposition aux centres de données s'étend aux États-Unis, en réaction à des projets massifs lancés, souvent avec peu ou pas de consultation des habitants. Dans l'Utah, des résidents ont protesté après que les commissaires du comté de Box Elder ont validé un centre de données censé consommer plus du double de l'électricité actuellement utilisée par l'État. Face à cette défiance, les géants de l'IA multiplient les gestes envers les collectivités pour sécuriser leurs autorisations. Le résultat du pilote en Géorgie pourrait servir de modèle, ou de contre-exemple, pour les prochains sites.

Les bandes magnétiques ont encore de beaux jours devant elles, notamment grâce à l’IA

Fujifilm a annoncé des investissements significatifs pour produire davantage de bandes magnétiques, et l'article évoque une production multipliée par cinq. La demande repart en effet fortement. Selon le consortium LTO, piloté par IBM, HPE et Quantum, la capacité totale des cartouches livrées l'an dernier a atteint 160,3 exaoctets. C'est 9 % de moins que le record de 2024, mais le deuxième plus haut niveau de l'histoire. Au premier trimestre 2026, le marché a rebondi de 57 % sur un an, porté par les cartouches LTO de dernière génération. Fujifilm et Sony sont les derniers fabricants de ces bandes au standard LTO (Linear Tape-Open), conçu par HP, IBM et Seagate. La génération 10 du LTO Ultrium atteint 40 To non compressés, jusqu'à 100 To compressés. Elle combine des particules de ferrite de baryum (BaFe) et de ferrite de strontium (SrFe). La débit annoncé est d'environ 400 Mo/s en lecture et en écriture avec le LTO-9. Cette reprise s'explique par l'explosion des données produites par l'IA générative et les services cloud. Il faut conserver les jeux de données d'entraînement et ceux utilisés pour l'exécution des modèles, et la bande offre un stockage froid à faible coût pour de très gros volumes. Son autre atout est la durée de conservation : Fujifilm affirme que ses performances magnétiques durent plus de 50 ans sans influence externe. Les cartouches peuvent aussi être isolées physiquement des réseaux. Cela intéresse de plus en plus les entreprises qui veulent se protéger des rançongiciels, car une sauvegarde hors ligne reste hors d'atteinte d'une attaque informatique. À 40 To par cartouche, la capacité rejoint celle des disques durs HAMR et MAMR actuels, mais l'avantage tient au prix et à la longévité. L'histoire de la bande est longue. Dans les années 1970 et 1980, les micro-ordinateurs enregistraient leurs programmes sur de simples cassettes audio, cousines lointaines des cartouches conçues ensuite pour le numérique. Fujifilm a lancé ses premiers modèles LTO Ultrium en 2000. En 2011, le groupe s'est présenté comme le premier au monde à passer aux particules de ferrite de baryum. La feuille de route prévoit quatre générations supplémentaires. La génération 14 viserait 365 To non compressés, soit 913 To compressés. Les bandes entièrement à base de SrFe sont attendues dès la génération 11, avec 70 To et plus. Le fabricant espère atteindre 580 To non compressés par cartouche. Cette progression se fait en parallèle de celle des disques durs : Seagate valide en laboratoire des modèles de 69 To et garde les 100 To en ligne de mire. Les deux technologies se partagent donc le stockage de masse, chacune avec ses usages.

💬 Le stockage froid revient par la porte de l'IA : quand chaque jeu de données d'entraînement doit être gardé des années, le support qui coûte le moins cher au To gagne, même s'il date de 1950. Ce que ça dit surtout, c'est que l'IA n'a pas seulement besoin de GPU, elle fabrique des montagnes de données que personne n'osera jeter. Et la bande a un argument que le disque n'a pas, la sauvegarde hors ligne contre les rançongiciels (un pirate n'efface pas une cartouche posée sur une étagère). Bon, la "production multipliée par cinq", je la prends avec des pincettes tant que Fujifilm ne chiffre rien de plus précis.

« C’est assez terrible » : pour Sam Altman, la RAM de votre PC serait mieux dans un data center

Sam Altman, le patron d'OpenAI, a jugé « assez terrible » que les particuliers conservent dans leur PC de la mémoire vive qui, selon lui, ne servirait que 5 % du temps. Il s'exprimait dans un podcast mis en ligne le 29 octobre 2026, en suggérant implicitement que ces ressources seraient mieux employées dans des centres de données. Cette position intervient alors qu'OpenAI prévoit d'absorber jusqu'à 900 000 plaques de DRAM par mois pour alimenter ses propres infrastructures, soit une part considérable de la production mondiale de mémoire. Ces propos résonnent particulièrement mal auprès des consommateurs et des fabricants de matériel informatique. La demande massive de l'intelligence artificielle en mémoire vive tire les prix vers le haut et réduit l'offre disponible pour les ordinateurs personnels, les smartphones et les consoles. Les particuliers qui souhaitent monter ou mettre à niveau une machine paient déjà le prix de cette tension. Présenter la RAM domestique comme une ressource gaspillée revient à renverser la charge : ce ne serait plus l'appétit des géants de l'IA qui crée la pénurie, mais l'usage jugé trop faible qu'en font les utilisateurs. L'argument ignore aussi que la mémoire d'un PC est dimensionnée pour absorber des pics d'utilisation, et non pour tourner en continu. Le contexte est celui d'une course effrénée aux capacités de calcul. OpenAI, comme Microsoft, Google, Meta ou Amazon, multiplie les annonces de data centers géants et les accords d'approvisionnement avec les fabricants de puces mémoire, notamment Samsung, SK hynix et Micron, qui orientent leurs lignes de production vers les mémoires destinées à l'IA, plus rentables. Cette réorientation pénalise le marché grand public et nourrit les critiques sur l'impact de l'IA sur l'accès au matériel. La sortie de Sam Altman pourrait alimenter ce débat, alors que la pression sur les prix de la RAM ne montre pas de signe d'apaisement.

💬 Selon Le Fil IA, quand un patron d'IA qualifie ta RAM de "gaspillée", il ne décrit pas ton usage : il justifie sa propre demande. Le raisonnement est un peu retors, parce que 900 000 plaques de DRAM par mois, ça crée la pénurie, et on te présente ensuite le résultat comme ton problème. Et puis soyons sérieux, une RAM qui dort 95 % du temps, c'est exactement ce qu'on attend d'une machine dimensionnée pour les pics. Tu ne loues pas ton PC à OpenAI, tu l'utilises quand tu en as besoin. Bon, sur le papier, mutualiser, ça se défend. Sauf que ça ne ressemble pas à de la mutualisation, plutôt à de l'accaparement.

Gérer les coûts d'Amazon Bedrock de bout en bout : guide pratique pour les équipes FinOps et plateforme

Les équipes qui pilotent les coûts de l'IA générative sur Amazon Bedrock se heurtent souvent aux mêmes limites. Beaucoup commencent par comparer les tarifs par token des modèles et par demander aux développeurs de raccourcir leurs prompts. Ces gestes aident, mais ils ne répondent pas aux questions des directions financières et techniques à mesure que l'usage grandit: quelle équipe a dépensé cette somme, sur quelle charge de travail, et dans le cadre de quel budget approuvé? Les workflows agentiques aggravent le problème. Un assistant conversationnel émet en général une invocation de modèle par tour de parole. Un agent, comme un assistant de programmation qui planifie une modification, lit des fichiers, appelle des outils et itère, multiplie les invocations par tâche, avec un contexte plus volumineux à chaque appel. La consommation de tokens dépend donc du degré d'autonomie accordé et de la taille du contexte, et non du nombre d'interactions humaines. AWS recommande de modéliser les tarifs avec son calculateur de prix et la page de tarification de Bedrock, puis de mesurer la consommation réelle plutôt que de se fier à des moyennes publiées. Selon AWS, la solution n'est ni un modèle moins cher ni un prompt plus court, mais un modèle d'exploitation: une boucle répétable en cinq étapes. Il s'agit d'attribuer chaque dollar à un responsable, de rendre chaque requête observable, de contrôler les dépenses par des budgets assortis d'alertes et de blocages, d'optimiser les paramètres par défaut de la plateforme, puis d'instaurer un rythme de revue. Le guide vise deux publics: les praticiens FinOps, qui gèrent l'attribution, la refacturation, les budgets et l'analyse des anomalies, et les équipes d'ingénierie de plateforme, responsables de la journalisation, des métadonnées de requête, de l'application des règles et du routage. Les premiers pilotent l'attribution et la revue, les seconds l'observabilité, le contrôle et l'optimisation, la revue finale étant conjointe. Cet ordre est voulu: les équipes qui optimisent sans attribution ni observabilité, avertit AWS, travaillent à l'aveugle. La première étape, l'attribution, conditionne tout le reste: refacturation, budgets, application des limites et détection d'anomalies. Elle repose sur l'attribution granulaire des coûts de Bedrock, qui impute automatiquement les coûts d'inférence au principal IAM ayant émis l'appel, pour tous les modèles et sans ressource à gérer. L'ARN de l'appelant apparaît dans la colonne lineitemiam_principal du rapport AWS Cost and Usage Report (CUR) 2.0, et la couverture inclut les utilisateurs IAM, les rôles, les identités fédérées et les clés d'API. La mise en place commence par l'activation des données de principal IAM dans l'export CUR 2.0, puis par l'étiquetage des principaux IAM avec des attributs métier tels que l'équipe ou l'application. Ce chantier s'inscrit dans l'essor des déploiements agentiques en entreprise, où la facture cloud devient un sujet de gouvernance autant que d'architecture, et où la discipline FinOps doit s'étendre aux coûts d'inférence.

💬 Le vrai sujet, c'est que la facture IA ne se pilote plus au prix du token mais à l'identité de celui qui appelle. Un agent multiplie les invocations et gonfle le contexte à chaque tour, donc comparer les tarifs des modèles ou raccourcir les prompts, c'est soigner le symptôme. Attribuer chaque dollar à un principal IAM, enfin du concret, et c'est le genre de truc qu'on attendait depuis que les agents tournent en prod. Bon, sur le papier c'est propre, reste à voir si les équipes taggent leurs rôles proprement, parce que sans ça tu auras juste une jolie colonne vide dans ton CUR.

Le serveur d'IA satellite de Google transmet sa première réponse à la Terre

Google a réussi à faire générer une première réponse à un satellite équipé de puces d'intelligence artificielle depuis l'espace. Dans un billet de blog publié vendredi, l'entreprise explique avoir démarré avec succès les Tensor Processing Units (TPU) embarqués, ce qui a permis au modèle Gemma 4 installé à bord d'exécuter une consigne simple : composer un haïku sur la vie en orbite. Le texte produit évoque une « planète bleue » en contrebas, des données qui circulent « en silence » et la lumière des étoiles qui alimente le « cœur » de la machine. Google précise avoir aussi testé d'autres invites sur le thème de l'espace, dont des limericks, ainsi que des requêtes liées à la télémétrie. Le satellite avait été lancé en orbite plus tôt, dans le cadre d'un programme expérimental. L'exercice paraît anecdotique, mais il valide une étape technique réelle : faire fonctionner des accélérateurs d'IA conçus pour les centres de données terrestres dans l'environnement spatial, avec ses contraintes de rayonnement, de température et d'énergie. Si l'approche se confirme, elle pourrait ouvrir la voie à des capacités de calcul alimentées directement par l'énergie solaire, sans les besoins en électricité, en eau de refroidissement et en foncier qui pèsent de plus en plus sur les centres de données au sol. Pour les opérateurs de satellites, traiter les données à bord plutôt que de les renvoyer vers la Terre permettrait aussi de réduire les délais et la bande passante nécessaires. Ce test s'inscrit dans le projet Suncatcher, une initiative expérimentale de Google qui vise à terme à installer des centres de données dédiés à l'IA dans l'espace. Il répond à l'explosion des besoins de calcul liés à l'IA générative, qui met les réseaux électriques et les collectivités locales sous tension. Plusieurs acteurs du numérique et du spatial explorent des pistes similaires, et la question de la rentabilité, du coût de lancement et de la maintenance des équipements en orbite reste largement ouverte. Les prochaines étapes devraient montrer si ce prototype peut passer à une échelle industrielle.

💬 Un haïku depuis l'orbite, c'est du marketing. Mais faire tourner des TPU conçus pour le sol sous radiations et écarts de température, ça, c'est la vraie validation. Selon moi, le calcul en orbite ne se jouera pas sur la technique mais sur le coût de lancement et la maintenance : un data center qu'on ne peut pas réparer, ça s'amortit très différemment. Bon, sur le papier le solaire gratuit fait rêver, reste à voir si l'addition tient en prod.

Fujifilm va multiplier par cinq sa production de bandes magnétiques face à la demande d'archivage liée à l'IA

Fujifilm a annoncé jeudi un investissement d'environ 10 milliards de yens (près de 63 millions de dollars) pour multiplier par cinq sa capacité de production de bandes magnétiques, un support que l'on n'attendait guère parmi les gagnants de l'ère de l'IA. Le chantier concerne l'usine de Kanagawa, sur le site d'Odawara, et s'étendra des exercices fiscaux 2026 à 2028. Il financera l'extension des lignes de fabrication ainsi que des recrutements, avec pour objectif principal de produire la dernière génération de cartouches, la « FUJIFILM LTO Ultrium10 ». La hausse de cinq fois se mesure par rapport aux niveaux de production de l'exercice 2025. Fujifilm précise qu'il s'agit du plus gros investissement jamais consacré à ses installations dédiées aux bandes LTO. Selon le groupe japonais, cette décision répond à une envolée de la demande d'archivage portée par la diffusion de l'intelligence artificielle générative, qui provoque selon ses termes une « croissance exponentielle » des besoins en données dans le monde. Chaque modèle entraîné, chaque jeu de données conservé et chaque contenu généré doit être stocké quelque part, souvent pour de longues durées et à moindre coût. Pour les entreprises, les fournisseurs de cloud et les centres de données, la bande reste une solution de stockage froid attractive, car elle coûte peu par téraoctet, consomme très peu d'énergie lorsqu'elle n'est pas utilisée et offre une bonne protection contre les cyberattaques puisque les cartouches peuvent être déconnectées du réseau. Cet investissement confirme que l'explosion des volumes de données profite aussi à des technologies anciennes, et pas seulement aux puces et aux serveurs. Ce mouvement s'inscrit dans un contexte où les capacités de stockage, longtemps considérées comme secondaires face aux processeurs graphiques, deviennent un maillon sous tension de la chaîne de l'IA. Le format LTO, standard de l'industrie évoluant par générations successives, reste dominé par un petit nombre d'acteurs, dont Fujifilm est l'un des principaux fabricants de supports. En misant massivement sur la dixième génération, l'entreprise cherche à prendre de l'avance sur ses concurrents et à sécuriser des contrats avec les grands opérateurs de données. Reste à savoir si la demande se maintiendra au rythme actuel, mais l'ampleur de la somme engagée montre que Fujifilm anticipe une croissance durable de l'archivage.

💬 Selon Le Fil IA, l'IA ne fait pas que dévorer du GPU : elle fabrique des montagnes de données que personne n'ose effacer, et c'est le stockage froid qui encaisse la facture. Fujifilm qui met 63 millions de dollars sur de la bande LTO, c'est le signe que le goulot d'étranglement se déplace des puces vers l'archivage. Bon, la bande, ça fait un peu 1985 sur le papier. Mais pour garder des pétaoctets de jeux de données à bas coût, hors réseau et à l'abri des ransomwares, rien ne la bat, reste à voir si la demande tient au-delà de l'effet d'annonce.

Avec 60 millions de dollars, vous pouvez acheter ce supercalculateur Nvidia sur eBay (ou 7 500 RTX 5090)

Un revendeur américain de matériel informatique a mis en vente sur eBay un supercalculateur Nvidia décommissionné, doté de 9 600 GPU et d'autres composants, pour un prix d'environ 60 millions de dollars. L'annonce, très inhabituelle pour une plateforme habituée aux produits d'occasion du quotidien, propose l'ensemble de l'infrastructure en un seul lot. À ce tarif, l'acheteur pourrait aussi, selon la comparaison mise en avant par la presse, se procurer environ 7 500 cartes graphiques grand public RTX 5090, ce qui donne une idée de l'échelle de la transaction. Cette vente illustre la seconde vie que peuvent connaître les infrastructures d'IA et de calcul haute performance lorsque leurs propriétaires les remplacent par des machines plus récentes. Pour des laboratoires, des start-ups ou des entreprises disposant de moyens importants mais pas de délais d'attente de plusieurs mois, racheter un système déjà assemblé peut représenter un raccourci pour accéder à une puissance de calcul rare. L'épisode montre aussi que le marché secondaire des GPU professionnels devient un segment à part entière, où les prix se comptent en dizaines de millions et où des places de marché généralistes servent de vitrine. Il soulève enfin des questions pratiques : coût de l'énergie, du refroidissement, du transport et de la remise en service d'une telle machine. Le contexte est celui d'une course mondiale aux puces d'accélération, dominée par Nvidia, dont les GPU sont devenus la ressource centrale de l'intelligence artificielle générative. La demande dépasse régulièrement l'offre, ce qui pousse les acteurs à explorer toutes les pistes, y compris l'occasion. Les cycles de renouvellement rapides des architectures rendent par ailleurs certains systèmes obsolètes pour leurs premiers utilisateurs, tout en restant très performants pour d'autres usages. Reste à savoir si un acquéreur se manifestera à ce prix et si ce type d'annonce se multipliera.

Nvidia s'apprête à garantir un projet de 45 milliards de dollars d'un fournisseur de cloud pour Anthropic

Nvidia négocie pour fournir à Nscale, jeune fournisseur de cloud spécialisé dans l'IA, des garanties de crédit de plusieurs milliards de dollars. Ces garanties couvriraient la dette destinée à financer un centre de données de 460 mégawatts qu'Anthropic prévoit d'utiliser, dans un projet évalué à 45 milliards de dollars. Selon des personnes informées des discussions, l'accord n'est pas encore signé et ses conditions peuvent encore évoluer. Ni Nvidia ni Nscale n'ont, à ce stade, officialisé le montage. Si elle se concrétise, la garantie permettrait à Nscale de s'endetter plus facilement et à moindre coût, car les prêteurs s'appuieraient sur la solidité financière de Nvidia plutôt que sur celle d'une entreprise encore jeune. Pour Anthropic, c'est l'assurance de voir sa future capacité de calcul effectivement construite. Pour Nvidia, c'est une nouvelle manière de soutenir la demande de ses propres puces en finançant indirectement ses clients, ce qui accroît son exposition à leurs éventuelles difficultés. Ce dossier s'inscrit dans une série de signaux par lesquels Nvidia affiche son soutien financier aux « neoclouds », ces fournisseurs spécialisés comme Nscale, CoreWeave ou Firmus. Ces sociétés subissent la pression des investisseurs, inquiets de la dette déjà levée et de celle qu'elles devront encore lever pour bâtir des centres de données dédiés à l'IA. La suite dépendra de la signature de l'accord et de l'accueil que lui réserveront les marchés de crédit.

💬 Selon Le Fil IA, quand Nvidia garantit la dette de ceux qui achètent ses puces, ce n'est plus de la vente, c'est du financement de sa propre demande. Le centre de 460 MW pour Anthropic ne tient que parce que le bilan de Nvidia se porte garant d'un neocloud trop jeune pour emprunter seul. Bon, sur le papier, c'est malin : Anthropic a son calcul, Nscale a son crédit moins cher. Mais si la demande en IA se tasse, c'est Nvidia qui encaisse deux fois, et ça, personne ne le chiffre encore.

Prime Intellect lance Prime Mega MoE : un kernel MoE fusionné entraînable, passe avant 3,11 fois plus rapide

Prime Intellect a publié Prime Mega MoE, une extension d'entraînement du noyau fusionné Mega MoE de DeepSeek, qui n'exécutait jusqu'ici que la passe avant. L'entreprise a écrit la passe arrière manquante, elle aussi à recouvrement entre calcul et communication, ce qui rend le noyau utilisable pour l'entraînement et plus seulement pour l'inférence. Il fonctionne sur les GPU NVIDIA Hopper (FP8 par blocs) et Blackwell (MXFP8), ainsi qu'en BF16 sur les deux. Les chiffres, auto-déclarés, ont été mesurés sur des nœuds 8×H200, avec 32 à 128 GPU, des séquences de 16 384 tokens et un checkpointing complet des activations. Dans le moteur d'entraînement prime-rl, un pas d'entraînement complet passe de 2,78 à 2,08 secondes sur Qwen3-30B-A3B (32 GPU, soit 34 % de gain) et de 12,72 à 9,65 secondes sur Qwen3-235B-A22B (128 GPU, soit 32 %). Face à TorchTitan en FP8, les gains atteignent 48 % et 55 %, avec un débit de 5 337 à 7 886 tokens par seconde et par GPU sur le 30B, et de 1 094 à 1 697 sur le 235B. Sur une seule couche MoE, la passe avant est jusqu'à 3,11 fois plus rapide (12,0 à 3,9 ms sur le 30B), tandis que la passe arrière progresse moins, de 1,24 fois sur le 235B (30,5 à 24,6 ms) à 1,87 fois sur le 30B. Pour les équipes qui entraînent des modèles à mélange d'experts, ces gains se traduisent directement en heures de GPU économisées. Le chiffre de 3,11 fois ne concerne que la passe avant, et le gain réaliste sur un entraînement complet se situe autour d'un tiers par rapport à une base déjà optimisée. L'écart est notable sur le plus gros modèle, où la passe arrière, plus difficile à accélérer, limite le bénéfice. Le noyau fonctionne aussi bien sur Hopper que sur Blackwell, ce qui élargit son usage au parc de machines réellement déployé. Prime Intellect propose en outre un mode fp8_bwd, qui combine une passe avant en BF16 et une passe arrière en FP8, pour arbitrer entre précision et vitesse. Le goulot d'étranglement vient de la nature même des MoE : chaque token est routé vers un petit sous-ensemble d'experts répartis sur plusieurs GPU, ce qui impose à chaque couche d'envoyer les tokens, de calculer, puis de rapatrier les résultats, dans les deux passes. Dans une implémentation classique, ces étapes sont des opérations séparées entre lesquelles le GPU attend. Le noyau Mega MoE, ajouté à la bibliothèque open source DeepGEMM de DeepSeek en avril 2026, fusionne la répartition en parallélisme d'experts, les deux couches linéaires, SwiGLU et la recombinaison en un seul appel, et calcule un groupe de tokens pendant qu'un autre est en transit. Il existe des approches concurrentes : TorchTitan avec DeepEP, qui garde des noyaux de dispatch séparés, ou Primus MegaMoE d'AMD pour les GPU MI355X. La publication de Prime Intellect, dont les résultats restent à confirmer de façon indépendante, prolonge ainsi le travail de DeepSeek vers l'entraînement.

Partagez des ressources entre équipes avec la gestion des quotas d'AWS Batch pour les jobs d'entraînement SageMaker

AWS Batch, le service de planification de charges de travail d'Amazon Web Services, introduit une fonctionnalité de gestion des quotas destinée aux jobs d'entraînement Amazon SageMaker. Elle complète la prise en charge de SageMaker Training par AWS Batch, qui permettait déjà de mettre en file d'attente, de planifier et de relancer automatiquement des entraînements de machine learning sans construire sa propre infrastructure. Les administrateurs peuvent désormais répartir la capacité de calcul en « quota shares », des parts organisées par équipe, projet ou type de charge. Chacune comprend des limites de capacité et une stratégie de partage des ressources inactives, avec trois options : RESERVE, qui garde la capacité en attente de jobs, LEND, qui la prête aux autres parts ayant du travail, et LENDANDBORROW, qui prête quand la part est inactive et emprunte quand elle a besoin de plus. Une part fonctionne comme une file virtuelle imbriquée dans une file de jobs. La configuration passe par une politique d'ordonnancement contenant une quotaSharePolicy et un environnement de service, et s'utilise avec le SDK Python de SageMaker v3. Lors de l'ordonnancement, AWS Batch traite en priorité les parts qui n'ont pas atteint leur limite. Si un job arrive dans une part ayant prêté sa capacité, le service réalise une préemption inter-parts : il récupère les ressources prêtées, sans que l'administrateur ait à repérer et arrêter lui-même les jobs qui les empruntaient. Si une part a atteint sa limite, le service cherche de la capacité à emprunter chez une autre part. Une préemption interne à la part, activable à la configuration, permet en outre d'interrompre les jobs de moindre priorité (planifiés, en démarrage ou en cours) pour faire passer plus vite ceux de priorité supérieure en tête de file. L'enjeu est d'abord économique et organisationnel. Les GPU sont rares et coûteux, et leur partage entre plusieurs équipes impose aujourd'hui des files séparées, des ajustements manuels de limites et une coordination constante. Automatiser le prêt, l'emprunt et la récupération de capacité réduit cette charge d'administration et limite les GPU laissés inactifs, tout en garantissant à chaque équipe son allocation quand elle en a besoin. Pour les organisations qui multiplient les équipes IA, cela évite de surdimensionner les clusters ou de se disputer les ressources. Cette annonce répond à une demande récurrente des clients gérant des environnements d'entraînement multi-équipes : définir des allocations par équipe ou projet, partager automatiquement la capacité inutilisée et exécuter d'abord les charges les plus prioritaires. L'amélioration de l'utilisation du calcul est l'un des arguments centraux d'AWS Batch, et la croissance des besoins en entraînement la rend plus pertinente. Cette approche rejoint les mécanismes de partage équitable et de quotas des ordonnanceurs de clusters GPU, qu'AWS intègre ici à un service entièrement géré, en concurrence avec les solutions que les entreprises assemblent elles-mêmes autour de Kubernetes ou de Slurm.

💬 Selon Le Fil IA, le vrai sujet du GPU n'est plus d'en acheter plus, c'est d'arrêter d'en laisser dormir : AWS vend ici de l'ordonnancement, pas de la puissance. Le prêt et l'emprunt entre équipes, avec récupération automatique quand le propriétaire revient, c'est le genre de truc que tout le monde bricolait à la main sur Kubernetes ou Slurm. Bon, sur le papier c'est propre, mais la préemption qui coupe un job d'une autre équipe en plein entraînement, reste à voir comment ça passe en prod (et dans les relations entre équipes).

Résoudre le problème d'énergie de l'IA

La course à l'IA se jouait jusqu'ici sur la vitesse à laquelle les entreprises parvenaient à déployer des GPU. Elon Musk et d'autres dirigeants s'attendent désormais à ce que des goulets d'étranglement physiques, au premier rang desquels le manque d'électricité pour alimenter les centres de données, ralentissent les concurrents. Face aux compagnies d'électricité qui annoncent des délais de plusieurs années pour de nouveaux raccordements, la « vitesse d'accès à l'énergie » est devenue le mot d'ordre du secteur. Lors d'une table ronde animée par Steve LeVine, de The Information, trois dirigeants ont présenté leurs approches : William Mao (Delta Electronics), Allan Schurr (ERock) et Brian Janous (Cloverleaf Infrastructure). Selon Janous, le réseau électrique est sous-utilisé d'environ 45 % en moyenne, car il doit absorber les pics de consommation. Quand un opérateur annonce qu'il n'y a pas de puissance disponible avant cinq ans, cela signifie qu'il ne peut pas couvrir les nuits d'hiver les plus froides et les journées d'été les plus chaudes, alors que la capacité suffit la plupart des heures. Ce constat change la nature du problème : il s'agit moins de trouver des gigawatts supplémentaires que de mieux exploiter ceux qui existent. Plusieurs acteurs, dont les start-up GridCARE, Emerald AI, Cloverleaf et Nvidia, cherchent à tirer parti de cette capacité inutilisée. Pour les développeurs, l'enjeu est de ne pas attendre des années pour mettre en service des sites. Certains construisent leurs propres centrales, mais Schurr juge cette voie « très coûteuse et fortement carbonée » à long terme. Il préconise un microréseau local, alimenté par des sources variées, qui sert de relais jusqu'au raccordement au réseau public, puis couvre les pointes de demande et maintient le site en service en cas de panne. Là où un poste de transformation prend trois à quatre ans à bâtir, ERock affirme construire un microréseau de 350 MW en 16 mois. Janous met en garde contre l'autonomie totale : le réseau assure l'équilibrage entre offre et demande et le redémarrage après un black-out, des services difficiles à reproduire derrière le compteur. Ces débats s'inscrivent dans un contexte où les charges d'IA bouleversent la conception des installations. Les centres de données tiraient autrefois une puissance stable et prévisible ; selon Mao, les charges se mesurent désormais en mmégawatts et fluctuent à la milliseconde, ce qui fragilise le réseau et exige des systèmes de contrôle et de tampon plus sophistiqués. Delta Electronics s'attaque au tronçon entre le réseau et la baie de serveurs avec des transformateurs à semi-conducteurs, qui convertissent le courant alternatif moyenne tension en courant continu 800 volts en moins d'étapes, ce qui peut réduire les pertes d'énergie et le nombre de points de défaillance. Cloverleaf, de son côté, repère des sites disposant de capacité réseau et développe des terrains « prêts à l'alimentation » : l'entreprise dit avoir livré environ 7 GW en 18 mois, avec 10 à 12 GW supplémentaires en préparation. Mao observe que l'électricité, longtemps reléguée au second plan, est devenue un sujet très recherché.

💬 Le réseau électrique tourne à environ 45 % de sous-utilisation, et ça change tout : la pénurie d'énergie de l'IA est en bonne partie un problème de gestion des pics, pas de gigawatts manquants. Quand un opérateur te dit "rien avant cinq ans", il parle de deux ou trois nuits d'hiver, pas de l'année entière. Bon, sur le papier, le microréseau en 16 mois face à 3-4 ans pour un poste de transformation fait rêver. Reste à voir si ça tient en prod, mais l'avantage ira à celui qui sait se brancher vite, pas à celui qui empile le plus de GPU.

Le casse-tête des « dark GPU » : pourquoi Amazon empile des milliards de dollars en puces IA inutilisées

Amazon accumule dans ses entrepôts des serveurs Nvidia représentant des milliards de dollars, faute d'électricité pour les mettre en service, selon des courriels internes consultés par Business Insider. Ces machines, surnommées « dark GPU » parce qu'elles restent éteintes, ne produisent donc aucun revenu. Le groupe continue pourtant d'en recevoir pour environ 3 milliards de dollars chaque mois. Le matériel s'entasse ainsi en attendant que les centres de données soient raccordés à une alimentation suffisante, ce qui crée un décalage croissant entre les commandes passées et la capacité réellement exploitable. Cette situation montre que le goulot d'étranglement de l'intelligence artificielle ne se limite plus à l'accès aux puces. Désormais, ce sont l'énergie, le raccordement au réseau et la construction des sites qui freinent le déploiement. Pour Amazon, chaque serveur immobilisé représente un capital gelé qui se déprécie, alors que les puces perdent de la valeur à mesure que de nouvelles générations arrivent. Pour les clients d'AWS, cela peut signifier une capacité de calcul plus rare ou plus lente à obtenir, au moment où la demande en IA reste très forte. Les investisseurs peuvent aussi y voir un risque sur la rentabilité des dépenses d'infrastructure colossales engagées par les géants du cloud. Ce problème s'inscrit dans la course aux investissements menée par Amazon, Microsoft, Google et Meta, qui ont multiplié leurs commandes de GPU Nvidia pour entraîner et faire tourner des modèles toujours plus gourmands. Or les délais de raccordement électrique, parfois de plusieurs années, ne suivent pas le rythme des livraisons de matériel. Les réseaux sont saturés dans plusieurs régions, ce qui pousse les entreprises à chercher de nouvelles sources, du nucléaire aux centrales dédiées sur site. La suite dépendra de la capacité des opérateurs à débloquer cette énergie, mais aussi de leur choix de ralentir ou non leurs achats, ce qui pourrait avoir des conséquences pour Nvidia.

💬 Le vrai goulot de l'IA n'est plus la puce, c'est la prise électrique. Amazon reçoit 3 milliards de dollars de GPU Nvidia par mois et les laisse éteints, faute de courant : un serveur qui dort, c'est du capital qui se déprécie pendant que la génération suivante arrive. Selon Le Fil IA, la course à l'IA se joue désormais sur les transformateurs et les raccordements au réseau, et celui qui sécurise l'énergie avant les puces gagne. Reste à voir si les géants du cloud freinent leurs commandes, et là c'est Nvidia qui devrait commencer à transpirer.

4 millions de coeurs CPU en plus : GitHub muscle son infrastructure pour faire face au code généré par IA

GitHub a profité de sa conférence Universe pour mesurer publiquement l'ampleur de la vague provoquée par les agents IA sur sa plateforme. La filiale de Microsoft a ajouté environ 4 millions de coeurs CPU à son infrastructure pour absorber l'afflux de code généré par intelligence artificielle. Elle ne s'est pas contentée d'empiler des serveurs. Elle a aussi dû repenser l'architecture de son système pour qu'il tienne la charge. Cet effort illustre un changement de nature de l'usage. Les agents de programmation ne se comportent pas comme des développeurs humains. Ils ouvrent des dépôts, lancent des builds et des tests, et soumettent des modifications en continu, à une cadence et à un volume que la plateforme n'avait pas été conçue pour supporter. Pour les millions de développeurs et d'entreprises qui dépendent de GitHub, la fiabilité et la rapidité du service deviennent un enjeu direct. Cette pression se traduit aussi en coûts matériels considérables pour l'hébergeur. Ce cas s'inscrit dans l'essor rapide des assistants et agents de codage, dont GitHub Copilot est l'un des principaux représentants, face à une concurrence de plus en plus vive. Microsoft, propriétaire de GitHub, doit concilier cette croissance avec la stabilité d'un outil devenu central pour l'industrie logicielle. D'autres plateformes d'hébergement de code devront probablement faire face au même phénomène, ce qui pourrait relancer la course aux capacités de calcul et pousser à de nouvelles refontes d'architecture.

DLSS 5 : comment Nvidia veut rendre vos jeux plus réalistes grâce à l’IA [Sponso]

Nvidia présente la cinquième version de son DLSS, la technologie de rendu par intelligence artificielle de ses cartes graphiques GeForce RTX. Jusqu'ici, le DLSS servait surtout à gagner en performances, en améliorant la fluidité des jeux vidéo. Avec la version 5, Nvidia ajoute un travail sur le rendu des éclairages et des matériaux, avec un objectif affiché : rapprocher l'image de jeu d'un rendu réaliste. L'article, publié par Frandroid sous la mention « Sponso », relève d'un contenu sponsorisé autour de cette annonce. Ce changement modifie la promesse du DLSS. Longtemps, cette technologie répondait à une question de performances : afficher plus d'images par seconde sans sacrifier la qualité visuelle. Désormais, l'IA intervient aussi sur la qualité de l'image elle-même, notamment sur la façon dont la lumière se comporte et dont les surfaces (métal, tissu, peau, eau) réagissent. Pour les joueurs équipés de cartes Nvidia, cela peut offrir des scènes plus crédibles sans exiger autant de puissance de calcul. Pour les studios, c'est un moyen d'atteindre un rendu plus poussé avec moins de ressources. Cette évolution s'inscrit dans la stratégie de Nvidia de faire de l'IA le moteur du rendu graphique, au lieu de se limiter à la puissance brute des processeurs graphiques. Après l'upscaling des premières versions, la génération d'images intermédiaires, puis la reconstruction du ray tracing, le DLSS 5 poursuit ce mouvement. Cette stratégie renforce l'avantage de Nvidia face à ses concurrents AMD et Intel, qui développent leurs propres technologies équivalentes. Reste à voir quels jeux seront compatibles, à quel rythme les éditeurs l'adopteront et quelles cartes en bénéficieront.

💬 Avec le DLSS 5, Nvidia ne vend plus des images en plus, il vend une image « corrigée » par son IA, et c'est un vrai changement de nature. Le jour où le rendu dépend du modèle de la carte, la direction artistique du jeu se négocie avec le fabricant de GPU. Bon, sur le papier, des lumières et des matériaux plus crédibles sans exploser la puissance de calcul, c'est séduisant (enfin, surtout pour Nvidia, qui verrouille un peu plus son écosystème face à AMD et Intel). Reste à voir si les éditeurs suivent, et si ça tient en prod, sachant que l'article est un contenu sponsorisé.

Construire une plateforme d'IA à base d'agents sur Amazon Bedrock AgentCore

Faire passer un agent en production se heurte moins au modèle ou aux outils qu'à tout ce qui les entoure : comment de nombreuses équipes peuvent construire dans un environnement sécurisé, qui possède chaque modèle et chaque outil, comment l'exploitation des agents et la gestion des erreurs restent dans un cadre prédéfini, et comment les équipes plateforme, métier et finance suivent les coûts et la santé du parc sur plusieurs comptes. AWS détaille une architecture de référence pour une plateforme d'IA agentique d'entreprise fondée sur Amazon Bedrock et Amazon Bedrock AgentCore, ce dernier fournissant des services modulaires (runtime, gateway, identité, mémoire, politiques, registre, évaluations). Le « Enterprise Agentic AI Platform Blueprint » y ajoute, sous forme d'infrastructure as code déployable, les contrats d'entreprise : propriété, frontières de comptes, livraison logicielle, observabilité, gouvernance des coûts et retrait. L'architecture repose sur un modèle multi-comptes, un plan de contrôle géré par l'équipe Plateforme, un schéma de déploiement reproductible pour chaque « Workstream » (équipe produit ou métier qui construit et possède ses agents), des passerelles distinctes pour l'inférence et les outils, et un pipeline d'évaluation qui conditionne la mise en production de chaque agent. L'enjeu est d'éviter que chaque équipe réassemble ses propres contrôles, ce qui provoque une dérive, des goulets d'étranglement sur les services partagés et une propriété difficile à auditer. Chaque Workstream doit disposer d'une « voie balisée » : modèles et outils approuvés, identité de charge de travail à courte durée de vie, runtime et mémoire isolés, évaluation automatisée, retour arrière, télémétrie et attribution des coûts. Pour les organisations, cela signifie que les équipes peuvent livrer et revenir en arrière de façon autonome, sans attendre l'équipe plateforme ni disposer d'un accès direct en écriture à l'infrastructure. Les ingénieurs d'exploitation obtiennent journaux, métriques, traces et quotas, les responsables de Workstream voient le coût par agent face à leur budget, la finance peut facturer par équipe ou unité via AWS Cost Explorer et le rapport CUR, et les responsables sécurité disposent de preuves indiquant quelle charge de travail a appelé quel modèle ou outil. Ces principes répondent à cinq besoins récurrents exprimés par les clients. Premièrement, un accès gouverné aux modèles : toute requête d'inférence non fiable passe par une passerelle approuvée qui applique les garde-fous (Amazon Bedrock Guardrails ou un fournisseur tiers), limite les modèles et les Régions AWS autorisés par Workstream, impose limites de débit, quotas de jetons et budgets pour qu'aucune équipe n'épuise la capacité partagée, et transporte l'identité tout en émettant les données d'attribution. Deuxièmement, un accès gouverné aux outils : les agents ne découvrent et n'invoquent que des outils approuvés via une passerelle Model Context Protocol (MCP) authentifiée, avec cibles exactes, rôles d'exécution à moindre privilège, décisions de politique et propriétaire auditable. S'y ajoutent la livraison déléguée, les opérations de parc avec suivi des coûts, ainsi que la preuve bornée et la gestion du cycle de vie de chaque version d'agent. Face à la multiplication des cas d'usage agentiques en entreprise, AWS positionne ainsi la plateforme comme un produit à concevoir et à exploiter, plutôt qu'un assemblage laissé à chaque équipe.

Entraînement distribué avec les DLC Ray Train et EFA sur EKS

Le principal obstacle au passage à l'échelle d'un entraînement PyTorch sur un cluster tient moins au code du modèle qu'au conteneur. Chaque nœud doit disposer du même runtime CUDA, d'un PyTorch compilé pour cette version, de NCCL, des bibliothèques utilisateur de l'Elastic Fabric Adapter (EFA), du plugin AWS OFI NCCL qui relie NCCL à EFA, et d'une version de Ray compatible avec l'opérateur du cluster. AWS propose désormais le Ray Train Deep Learning Container (DLC), une image qu'elle assemble, teste comme un tout, publie sur Amazon ECR Public et maintient à jour. Le tag utilisé dans l'exemple, public.ecr.aws/deep-learning-containers/ray:train-ml-cuda-v1.1, embarque Ray 2.58.0 (Train, Tune, Data), PyTorch 2.13.0, torchvision 0.28.0, CUDA 13.0.2, NCCL 2.29.7, la pile EFA avec le plugin AWS OFI NCCL et GDRCopy, ainsi que DeepSpeed, flash-attn, Transformer Engine, PyTorch Lightning et les bibliothèques Hugging Face. Les NCCL tests, dont allreduceperf, sont déjà compilés. L'exemple fine-tune Qwen2.5-1.5B avec PyTorch FSDP sur huit GPU NVIDIA L4, répartis sur deux instances g6.12xlarge, sans qu'aucune image ne soit construite. L'intérêt est de ramener l'entraînement distribué à de la configuration. Le code d'entraînement tient en une fonction, le cluster en un manifeste RayCluster accompagné d'un fichier de variables. Les choix d'instances, le nombre de GPU par pod, le transport réseau utilisé par NCCL et les paquets Python supplémentaires se règlent tous depuis l'extérieur de l'image. Comme le DLC contient déjà la pile EFA, les communications collectives entre les deux machines passent par EFA dès que les pods le demandent. Pour les équipes, c'est la fin d'un chantier annexe qui n'a rien à voir avec le modèle : reconstruire et réaligner l'image à chaque évolution d'un composant. La couche réseau, que la plupart des équipes hésitent à aborder, devient ainsi accessible sans expertise particulière. L'architecture repose sur KubeRay, un opérateur Kubernetes open source. Kubernetes ne connaît pas la notion de cluster Ray, alors que Ray fonctionne avec deux rôles : un nœud head, qui coordonne, héberge le magasin de contrôle global, le tableau de bord et le serveur de jobs, et des nœuds workers qui fournissent les GPU. KubeRay ajoute une ressource RayCluster : on décrit un groupe head et un groupe de workers dans un manifeste, et l'opérateur crée les pods, démarre Ray dans le bon rôle, relie les workers au head et remplace les pods défaillants. Sur Amazon EKS, un nœud CPU m7i.xlarge héberge l'opérateur et le head, tandis que deux nœuds g6.12xlarge compatibles EFA, placés dans une même zone de disponibilité, accueillent les huit workers, un par GPU. La même image sert pour le head et les workers, que KubeRay la lance sur EKS ou qu'on la démarre soi-même sur Amazon EC2. La solution complète est publiée dans un dépôt d'exemple, qui reprend le socle KubeRay sur EKS d'un précédent tutoriel consacré à Ray Serve multi-nœuds.

Annonce des images indexées SOCI pour accélérer les jobs SageMaker AI

Amazon Web Services a annoncé l'indexation Seekable OCI (SOCI) pour les jobs d'entraînement et de traitement d'Amazon SageMaker AI. Cette technologie retire le téléchargement complet de l'image de conteneur du chemin critique de chaque job. Au lieu de récupérer toute l'image avant de démarrer, SageMaker AI charge les images « à la demande ». Le service ne télécharge que les fichiers nécessaires au lancement du conteneur, puis diffuse le reste en arrière-plan pendant l'exécution du code. Un job démarre ainsi en quelques secondes plutôt qu'en quelques minutes. L'index SOCI est une métadonnée qui cartographie chaque fichier de l'image. Il est stocké dans Amazon ECR comme artefact conforme à OCI, lié à l'image d'origine, dont le condensat (digest) et les signatures restent donc valides. À la création d'un job, SageMaker AI vérifie automatiquement la présence d'un index. S'il existe, l'image est chargée progressivement. S'il n'existe pas, le téléchargement standard s'applique. Si l'index est illisible ou si le chargement échoue, le job bascule sur le téléchargement classique et continue. Les tests d'AWS portent sur huit images de 1,8 à 35,4 Go compressées, sur des instances GPU et CPU (ml.g4dn, g5, g6, g6e, g7, g7e, p4d, p5, m7i, de xlarge à 48xlarge), dans les régions us-west-2 et us-east-1. Selon AWS, le temps d'inactivité des GPU pendant le téléchargement des images baisse jusqu'à 90 %, sans impact sur les performances d'entraînement. L'enjeu est d'abord financier et opérationnel. Les images de deep learning dépassent couramment 10 Go, et leur téléchargement ajoute plusieurs minutes à chaque job, facturées comme du temps de calcul alors qu'elles ne font avancer aucun modèle. Ce coût pèse surtout là où la vitesse d'itération compte le plus : les campagnes d'optimisation d'hyperparamètres qui lancent des centaines de jobs, les expériences rapides et les traitements courts, où le téléchargement peut représenter l'essentiel de la durée totale. Réduire ce délai diminue le coût par job et libère du temps pour les équipes. L'adoption est volontairement simple : il suffit de pointer vers une image AWS Deep Learning Container (DLC) déjà indexée, ou d'ajouter un index à sa propre image. La définition du job, le point d'entrée et les canaux de données ne changent pas. Comme le repli vers le téléchargement standard est automatique, ajouter un index ne peut pas empêcher un job de s'exécuter, ce qui limite le risque pour les flux existants. Cette annonce répond à un problème qui s'aggrave avec la taille des images et des frameworks d'IA, souvent alourdies par les bibliothèques CUDA, les outils d'entraînement distribué et les dépendances. SOCI est une technologie open source de chargement différé de conteneurs, déjà portée par AWS, qui s'appuie sur ECR pour stocker les index comme artefacts séparés. En l'intégrant à SageMaker AI, AWS étend cette approche à ses services de machine learning gérés, où le temps de démarrage se traduit directement en facturation. Pour les équipes qui multiplient les petits jobs, c'est un levier d'économie notable et un argument face aux plateformes concurrentes de calcul GPU. La suite dépendra de l'élargissement des images DLC pré-indexées et de l'adoption par les clients qui maintiennent leurs propres images.

💬 Enfin un correctif sur un gaspillage qu'on paie sans le voir : les minutes de téléchargement d'image, facturées comme du calcul alors qu'aucun modèle n'avance. Selon Le Fil IA, avec SOCI, AWS ne vend plus seulement de la puissance GPU, il s'attaque au temps mort entre le clic et le premier calcul, et c'est là que se joue le coût réel des petits jobs. Le repli automatique rassure, donc zéro risque à tenter. Reste à voir si les images DLC pré-indexées suivent, et si ça tient aussi hors des deux régions américaines testées.

Présentation : l'avantage méconnu du cache KV pour servir des LLM à grande échelle

Lors d'une présentation consacrée au déploiement de grands modèles de langage à grande échelle, Khawaja Shams propose un regard issu des systèmes distribués sur l'optimisation des piles d'inférence. Il passe en revue plusieurs leviers concrets : mieux exploiter les GPU, gérer les « falaises » mémoire du cache clé-valeur (KV cache), s'appuyer sur un stockage hiérarchisé, réduire la latence de queue, et séparer les phases de préremplissage (prefill) et de décodage (décodé) sur des architectures distinctes. L'enjeu est d'abord économique. Les GPU représentent le poste de dépense dominant de l'inférence, et un cache saturé provoque des dégradations brutales de performance au lieu d'un ralentissement progressif. Maîtriser ces seuils permet d'augmenter le nombre de requêtes servies par machine, de réduire le coût par jeton et de lisser les temps de réponse pour les utilisateurs. La réduction de la latence de queue compte particulièrement pour les applications interactives, où quelques requêtes lentes suffisent à dégrader l'expérience. Le gain porte aussi sur la disponibilité de l'ensemble de la flotte, pas seulement sur la vitesse d'une requête isolée. Ce discours s'inscrit dans un mouvement plus large : à mesure que les modèles se généralisent en production, la difficulté se déplace de l'entraînement vers l'exploitation. Les techniques classiques des systèmes distribués, comme la hiérarchisation du stockage, la séparation des responsabilités et la gestion de la latence de queue, sont désormais appliquées à l'inférence. La séparation du prefill et du décodé, qui sollicitent le matériel de manière très différente, illustre cette convergence. Elle intéresse les fournisseurs de modèles, les opérateurs de cloud et les entreprises qui hébergent leurs propres modèles et cherchent à contenir leurs coûts.

« Hors de notre contrôle » : le pari d’Anthropic sur le gaz naturel pour alimenter ses data centers

Dans le prospectus de son introduction en Bourse, publié lundi 26 octobre, Anthropic reconnaît qu'une partie de ses futurs data centers fonctionnera au gaz naturel produit sur place. Le groupe précise que le prix de cette énergie échappe en grande partie à son contrôle, d'où la formule « hors de notre contrôle » employée dans le document. Le texte exprime aussi des doutes sur la capacité du solaire, de l'éolien ou du nucléaire à être disponibles à temps pour répondre à ses besoins. Cet aveu, formulé dans un document destiné aux investisseurs, change la lecture des ambitions climatiques du secteur. Anthropic indique que la vitesse de déploiement du calcul prime sur la nature de l'énergie, au moins à court terme. Pour les futurs actionnaires, le gaz expose l'entreprise à la volatilité des cours et alourdit un risque de coûts déjà élevé. Pour les riverains et les collectivités qui accueilleront ces sites, cela signifie des émissions locales et une dépendance aux infrastructures gazières. Ce choix s'inscrit dans une course à la puissance de calcul où l'électricité est devenue le principal goulot d'étranglement. Les délais de raccordement aux réseaux, la lenteur des chantiers nucléaires et l'intermittence des renouvelables poussent les grands acteurs de l'IA vers des solutions autonomes sur site, souvent fondées sur le gaz. Anthropic suit ainsi une trajectoire déjà empruntée par d'autres géants du secteur. La question est désormais de savoir si les investisseurs et les régulateurs accepteront ce compromis, et si l'entreprise pourra tenir ses engagements environnementaux.

💬 Le gaz sur site, c'est l'aveu que l'électricité est devenue le vrai goulot d'étranglement de l'IA, bien avant les puces. Anthropic dit noir sur blanc à ses futurs actionnaires que la vitesse de calcul passe avant la propreté de l'énergie, et que le prix du gaz lui échappe. Bon, c'est cash, et c'est plutôt sain dans un prospectus. Mais ça veut dire que les promesses climatiques du secteur se négocient désormais derrière le délai de raccordement au réseau. Reste à voir si les riverains des futurs sites trouveront ça aussi lucide que les investisseurs.

Anthropic brûle du gaz pour alimenter le boom de l'IA

Dans le document S-1 déposé lundi auprès de la Securities and Exchange Commission américaine, dans le cadre de sa préparation à une introduction en bourse, Anthropic reconnaît que ses centres de données dépendent de plus en plus du « gaz naturel ». Ce terme est celui qu'emploie l'industrie des énergies fossiles pour désigner ce qui est essentiellement du méthane. L'entreprise écrit que la concurrence pour l'accès à l'électricité et aux sites de centres de données disposant d'une puissance suffisante est « intense ». Elle admet que cette dépendance expose son déploiement d'infrastructures à la hausse du coût des combustibles et aux contraintes déjà présentes dans la chaîne d'approvisionnement. Le document évoque aussi un possible cercle vicieux lié à la hausse de certains coûts mondiaux, mais l'extrait disponible s'interrompt avant d'en détailler la nature. Cet aveu a du poids, car il figure dans un document réglementaire où les facteurs de risque doivent être décrits sans enjolivement. Il montre que la croissance de l'IA générative repose concrètement sur des énergies fossiles, ce qui pèse sur le bilan climatique du secteur. Il signale aussi aux investisseurs que l'accès à l'énergie, et non seulement aux puces, peut limiter les perspectives de l'entreprise. Cette situation s'inscrit dans la course à la capacité de calcul que se livrent les grands laboratoires d'IA et leurs partenaires du cloud. Les besoins en électricité des centres de données sont devenus un goulot d'étranglement, et le gaz reste la source la plus rapidement mobilisable pour les alimenter. Le méthane étant un gaz à effet de serre puissant, l'enjeu dépasse la facture énergétique. L'introduction en bourse d'Anthropic va multiplier les regards sur ces engagements.

💬 Le S-1 d'Anthropic écrit noir sur blanc que l'énergie, pas seulement les puces, plafonne la croissance de l'IA. Quand une boîte qui vend de la "sécurité" et de la "responsabilité" met le mot gaz dans un document de la SEC, c'est que le risque est trop gros pour être enjolivé. Je trouve ça plutôt sain, enfin presque, parce qu'on attend maintenant de voir ce que l'introduction en bourse fera de ces engagements climat. Reste à voir si l'argument "on compense" tient quand la facture de combustible s'envole.

Test du GMKtec EVO-X5 Pro avec Max+ PRO 495 et 196 Go de RAM : le meilleur prix au Go de mémoire face à Nvidia et Apple

Le GMKtec EVO-X5 Pro fait partie des premières machines équipées du Ryzen AI Max+ PRO 495, la mise à jour de la puce Strix Halo d'AMD. Frandroid l'a testé dans une configuration annoncée à 196 Go de mémoire vive. Sur le plan du calcul, le processeur ne progresse presque pas par rapport à la génération précédente. La vraie nouveauté tient à la mémoire maximale, qui passe de 128 à 192 Go. Cette capacité permet de charger sur un mini PC des modèles d'intelligence artificielle qu'aucune machine de ce format n'acceptait jusqu'ici. L'intérêt est surtout économique. Pour faire tourner localement de très gros modèles de langage, la quantité de mémoire accessible compte davantage que la vitesse brute du processeur. Le test conclut que cette machine offre le meilleur prix au gigaoctet de mémoire face aux solutions de Nvidia et d'Apple. Pour les développeurs, les chercheurs et les passionnés qui veulent exécuter des modèles chez eux, sans dépendre d'un service en ligne ni payer un serveur coûteux, cela rend accessible une catégorie de modèles réservée jusque-là à du matériel bien plus cher. Ce lancement s'inscrit dans la course à l'IA locale. Les puces Strix Halo d'AMD reposent sur une mémoire partagée entre processeur et circuit graphique, une approche proche de celle des puces Apple. Nvidia propose ses propres machines compactes dédiées à l'IA, et Apple mise sur la mémoire unifiée de ses Mac haut de gamme. AMD et ses partenaires comme GMKtec cherchent donc à s'imposer par la capacité et le tarif. Reste à voir si les logiciels suivront pour exploiter pleinement ces 192 Go.

💬 Le calcul n'a presque pas bougé, mais les 192 Go changent la donne : pour l'IA locale, c'est la mémoire qui décide de ce que tu peux lancer, pas la fréquence du processeur. Selon Le Fil IA, la bataille de l'IA en local ne se joue plus sur la puissance de calcul mais sur le prix du gigaoctet accessible, et là AMD prend une longueur d'avance sur Nvidia et Apple. Bon, sur le papier c'est très séduisant. Reste à voir si les logiciels suivent et si la bande passante tient la route sur les gros modèles, parce que charger un modèle de 150 Go et le faire tourner à une vitesse utilisable, ce n'est pas la même histoire.

Créer une recherche à base d'agents sur une Knowledge Base Amazon Bedrock managée avec CDK

Les systèmes de génération augmentée par récupération (RAG) classiques suivent tous le même schéma : la question est convertie en vecteur, les fragments les plus proches sont extraits d'un seul index, un modèle les reçoit et produit la réponse. Une récupération, une génération. Amazon détaille désormais, dans un guide technique, comment construire une récupération « agentique » d'entreprise sur une Managed Knowledge Base d'Amazon Bedrock, avec l'AWS Cloud Development Kit (CDK) en Python. Une seule commande déploie l'ensemble : un agent qui choisit entre deux bases de connaissances, interroge les données via une Gateway et renvoie une réponse sourcée et citée. L'application provisionne aussi deux tableaux de bord Amazon CloudWatch couvrant sept couches de télémétrie, ainsi que deux formes d'évaluation, à la demande et en continu. CDK déduit lui-même l'ordre de déploiement, là où il fallait auparavant séquencer les piles à la main. Le design en une passe a ses limites. Si la réponse couvre deux corpus, une seule récupération n'en ramène que la moitié, ce qui est pire que rien : la réponse paraît fluide mais reste incomplète. Si la bonne source dépend de la question, un index unique n'a aucun moyen de choisir. Si un second regard sur le corpus est nécessaire après le premier résultat, rien ne le permet. Placer un agent de raisonnement dans la boucle résout ces trois cas, puisqu'il décide s'il faut récupérer, quelle base consulter et s'il doit y retourner avant de répondre. Le prix à payer est opérationnel : un agent emprunte un chemin différent à chaque question, et par défaut on ne voit ni ce chemin ni la qualité de la réponse. L'observabilité devient alors la seule façon de savoir si le système fonctionne, d'où l'intérêt de la fournir dès le déploiement plutôt que de l'ajouter après coup. Ce guide fait suite à un article d'août 2024 qui déployait l'architecture en une passe : un bucket Amazon S3, une collection et un index OpenSearch Serverless, une base de connaissances et une source de données. Trois évolutions ont changé la donne. Amazon Bedrock propose maintenant une base de connaissances gérée (Type: MANAGED), qui prend en charge l'ingestion, le stockage, l'indexation et la récupération, ce qui supprime la collection OpenSearch et ses unités de calcul facturées. Amazon Bedrock AgentCore fournit la partie agentique : une Gateway expose chaque base comme outil via le Model Context Protocol (MCP), un Runtime héberge l'agent, et l'API AgenticRetrieveStream reclasse les résultats en interne et renvoie une réponse synthétisée et citée. Cette récupération agentique n'est disponible que sur la base gérée. Le chemin du bucket S3 à la base reste familier, mais le magasin vectoriel disparaît, et environ la moitié de ce que l'application déploie sert à rendre compte de ce que l'agent a fait.

💬 Un RAG classique, c'est une question, une récupération, une réponse. Dès que la réponse se trouve dans deux corpus, tu obtiens un texte fluide qui répond à moitié, et c'est pire qu'une erreur franche. Amazon met donc un agent dans la boucle, et le plus intéressant n'est pas là : environ la moitié de ce que l'application déploie sert à observer ce que l'agent a fait. Selon Le Fil IA, avec un agent, la question n'est plus de savoir s'il répond bien, mais si tu peux voir le chemin qu'il a pris, et l'observabilité devient le vrai produit. Bon, sur le papier c'est propre, reste à voir si ça tient en prod.

Meta au OCP Global Summit 2026 : des réseaux ouverts pour l'IA à l'échelle du rack, du centre de données et entre sites

Lors de l'Open Compute Project (OCP) Global Summit 2026, Meta a dévoilé les innovations réseau qui soutiennent ses derniers modèles d'IA, dont Muse Wonder et Muse Spark, ainsi que son cluster Prometheus à l'échelle du gigawatt. L'entreprise a présenté IcePack et IceCube, son premier rack réseau refroidi par liquide, équipé de lames de commutation de 102,4 Tbit/s (128 ports de 800G), déclinées en versions Broadcom Tomahawk 6C et NVIDIA Spectrum-6 et pilotées par FBOSS. Pour le « scale-out », elle a détaillé le Flattened Planar Fabric, développé avec NVIDIA, où chaque GPU se connecte à huit plans réseau, avec une architecture Clos passant de trois à deux niveaux, un « packet spraying » au niveau de la carte réseau et un plan de contrôle combinant hôte et commutateur. Pour le « scale-across », elle a présenté BAG, un super-spine de l'ordre du pétabit qui relie bâtiments, campus et régions, ainsi que des backbones régionaux SRv6 sur FBOSS et SAI. Côté « scale-up », Tahan, un commutateur Ethernet fondé sur Tomahawk5, équipe l'accélérateur MTIA 300, et Meta a montré en avant-première un rack de 72 accélérateurs sur silicium 102,4T. La norme ESUN passe de la version 1.0 à 1.1. Enfin, MetaRoCE, son transport RDMA pour réseaux d'IA, devient open source. L'enjeu est de taille pour l'industrie. Meta affirme que les progrès de l'IA dépendent désormais autant du réseau que du calcul, et que les entraînements croissent plus vite que l'infrastructure capable de les accueillir. Le choix d'Ethernet et de standards ouverts, y compris pour la communication interne aux racks, réduit la dépendance à des solutions propriétaires et permet à des fournisseurs concurrents d'interopérer. Les travaux sur l'optique, notamment la validation de l'optique co-packagée 51,2T, les modules linéaires qui suppriment le DSP de retiming par module et le déploiement massif de câbles de cuivre actifs 800G, visent à réduire la consommation, la chaleur et le coût sur des millions de liens. Les opérateurs de cloud partenaires et les équipementiers peuvent s'appuyer sur ces conceptions partagées. Cette annonce s'inscrit dans la course à des clusters d'IA de plus en plus grands, où l'on dépasse la capacité d'un seul bâtiment ou d'un seul site, d'où la nécessité de relier des régions entières. Meta s'appuie sur l'OCP, qu'elle a contribué à fonder, et lance l'initiative OSPA, codirigée avec Microsoft et Alibaba, pour standardiser la couche plateforme des commutateurs. La spécification v1.0 a été soumise à l'OCP. Parmi les intervenants figuraient Santosh Janardhan, responsable de l'infrastructure de Meta, Omar Baldonado et Vipul Deokar, ainsi que des représentants de Cisco pour le volet scale-across. Les prochaines étapes seront l'adoption de ces spécifications par l'écosystème, l'ouverture effective du code de MetaRoCE et le passage à grande échelle des racks de 72 accélérateurs.

💬 Selon Le Fil IA, la bataille de l'IA se joue de moins en moins sur la puce et de plus en plus sur les câbles qui les relient : en ouvrant son réseau, Meta cherche à rendre le fournisseur de GPU interchangeable. Ethernet partout, jusque dans le rack, MetaRoCE en open source, une norme de plateforme poussée avec Microsoft et Alibaba, c'est une façon polie de dire à NVIDIA que son verrou propriétaire a une date de péremption. Bon, sur le papier. Reste à voir si ça tient en prod, et surtout si les autres jouent le jeu (NVIDIA est quand même dans la boucle avec Spectrum-6).

Des centaines de RTX 5090 neuves désossées en usine pour l’IA ? Le business secret qui priverait les joueurs de GPU

Une vidéo du média hongkongais HKEPC montre des usines chinoises en train de démonter des centaines de GeForce RTX 5090 neuves. Ces cartes graphiques haut de gamme de Nvidia, conçues pour les joueurs, sont désossées pour que leurs composants servent à fabriquer des cartes destinées aux serveurs d'intelligence artificielle. Les images révèlent une activité de transformation à échelle quasi industrielle, avec des ateliers où les cartes sont retirées de leur boîtier d'origine puis reconditionnées. Dans le même temps, la RTX 5090 devient de plus en plus difficile à trouver dans les magasins. Si la pratique se confirme, elle pèse directement sur les joueurs et les créateurs de contenu. Chaque carte détournée vers l'IA manque sur les étagères, ce qui entretient la pénurie et tire les prix vers le haut sur un produit déjà très cher. Elle montre aussi que les cartes grand public sont devenues une ressource de substitution pour les acteurs qui n'ont pas accès aux accélérateurs professionnels. Le lien entre la rareté observée en boutique et ces démontages reste toutefois à établir avec précision, la vidéo ne chiffrant pas l'ampleur réelle du phénomène. Ce business s'inscrit dans une demande mondiale d'IA qui dépasse l'offre de puces. Les restrictions américaines sur l'exportation de composants avancés vers la Chine poussent des entreprises locales à chercher des alternatives, et les cartes grand public, plus faciles à se procurer, en font partie. Nvidia, qui privilégie ses gammes professionnelles très rentables, pourrait être appelé à réagir, par des contrôles de distribution ou des limitations techniques. La question de la disponibilité pour les particuliers reste ouverte.