La critique des GPU par Pat Gelsinger révèle le véritable problème du matériel d’IA
- Olivia Johnson

- 6 août
- 16 min de lecture
Pat Gelsinger a suscité un titre sans détour dans Google News en affirmant que certaines charges de travail fonctionnent mal sur les GPU, malgré leur rôle dominant dans l’intelligence artificielle. L’ancien dirigeant d’Intel n’a pas rejeté l’informatique sur GPU comme inutile. Il a remis en question l’hypothèse selon laquelle une seule architecture de processeur devrait gérer chaque étape d’un système d’IA de plus en plus complexe.
Cette nuance change le récit. Gelsinger a salué les progrès de Nvidia dans l’entraînement tout en s’interrogeant sur la capacité d’une infrastructure GPU généraliste à fournir une inférence abordable à très grande échelle. L’inférence est le processus qui exécute un modèle entraîné chaque fois qu’un utilisateur demande une réponse, une image, une prédiction ou une action.
Sa critique contient aussi un aveu inconfortable pour Intel. L’entreprise a sous-estimé la stratégie GPU de Nvidia à une époque où les CPU dominaient encore les centres de données. Nvidia a ensuite développé CUDA, fédéré les développeurs et fait du traitement parallèle le fondement de l’entraînement moderne de l’IA.
L’argument dépasse désormais Intel contre Nvidia. Il porte sur les GPU face à l’informatique hétérogène, où CPU, GPU, processeurs réseau et accélérateurs spécialisés se répartissent le travail selon leurs atouts.
Le renversement frappant est que Nvidia semble accepter une grande partie de ce principe à l’échelle du système. Ses plateformes les plus récentes associent des GPU à des CPU personnalisés, du silicium réseau, des unités de traitement des données et des technologies orientées vers l’inférence. Le différend porte sur qui peut assembler ce mélange le plus efficacement, et non sur la disparition soudaine des GPU.
Le titre de Google News omet le véritable argument de Gelsinger
La critique de Gelsinger vise la pensée centrée exclusivement sur les GPU, et non tous les GPU ou toutes les charges de travail d’IA.
La formule « GPUs suck » condense une discussion technique plus longue en un jugement absolu. Ses commentaires réels étaient plus précis et plus utiles pour les acheteurs de centres de données.
Dans une interview de Gelsinger détaillée, l’analyste des semi-conducteurs Ian Cutress l’a interrogé sur la variété croissante des architectures informatiques. Gelsinger a soutenu que la charge de travail doit déterminer l’architecture.
Il a déclaré que les GPU offrent d’excellentes performances lorsqu’un problème comporte de grandes quantités de calcul parallèle. L’entraînement moderne de l’IA correspond à ce schéma, car les processeurs exécutent de manière répétée des opérations matricielles sur de nombreux éléments de données.
Les opérations de flux de contrôle se comportent toutefois différemment. Elles comprennent les branches conditionnelles, l’orchestration, l’exécution d’outils, les fonctions du système d’exploitation et les analyses suivant des chemins moins prévisibles.
Gelsinger a proposé une formulation délibérément provocatrice : « There are things that run like crap on a GPU. » Il a ensuite identifié la logique if-then-else élémentaire comme peu adaptée à un long pipeline GPU.
Cette affirmation n’équivaut pas à dire que tous les GPU sont mauvais. Elle signifie qu’une architecture conçue pour le débit parallèle perd en efficacité lorsque la charge de travail bifurque, s’interrompt ou change de direction à répétition.
L’IA agentique rend cette différence plus visible. Un agent d’IA peut appeler une base de données, exécuter du code, examiner un résultat, choisir un autre outil et mettre à jour son plan. Seules certaines étapes impliquent les calculs matriciels denses qui favorisent les GPU.
Les étapes restantes consomment toujours du temps processeur, de la bande passante mémoire, de la capacité réseau et de l’énergie. Un GPU peut en exécuter beaucoup, mais la compatibilité technique ne garantit pas l’efficacité économique.
Gelsinger appelle son modèle privilégié la « trinité de l’informatique ». Les processeurs classiques gèrent le travail orienté contrôle, les accélérateurs d’IA prennent en charge les algorithmes intensifs en données, et les machines quantiques traiteront à terme certains problèmes au-delà des capacités pratiques de l’informatique classique.
La composante quantique reste spéculative pour les infrastructures d’IA quotidiennes. La répartition entre CPU et accélérateurs est déjà visible dans les systèmes de centres de données commercialisés et annoncés.
Cela rend le cadrage de Google News utile comme point de départ, mais incomplet comme conclusion. Gelsinger remet en question le modèle de déploiement de l’industrie, et non l’architecture qui a rendu possible le boom actuel de l’IA.
Son argument distingue également l’entraînement de l’inférence. L’entraînement crée ou met à jour un modèle en traitant de grands ensembles de données. L’inférence applique ce modèle entraîné à des requêtes en direct.
Les GPU restent centraux dans les deux étapes. Pourtant, l’inférence introduit d’autres priorités, notamment le temps de réponse, le coût par token, la consommation électrique, la capacité mémoire et des niveaux de service prévisibles.
Le marché des puces d’inférence comprend déjà AMD, Intel, Cerebras, Groq, d-Matrix et d’autres spécialistes. Leur opportunité vient de l’optimisation de ces priorités plutôt que de la reproduction de toute la plateforme d’entraînement de Nvidia.
Le langage de Gelsinger paraît catégorique. Sa position technique dépend de la charge de travail.
Pourquoi les puces d’inférence d’IA mettent l’économie des centres de données sous pression
Le débat sur le matériel se concentre désormais sur le coût récurrent de l’utilisation de l’IA, et non seulement sur le coût spectaculaire de son entraînement.
Un modèle peut subir un nombre limité de grands cycles d’entraînement. Il peut ensuite répondre à des milliards de requêtes, recherches, images générées, actions d’agents et demandes internes d’entreprise.
Chaque requête ajoute du travail d’inférence. Des modèles de raisonnement plus capables peuvent produire plusieurs étapes de traitement avant de renvoyer une réponse. Les agents ajoutent des étapes supplémentaires en appelant des outils et en révisant leurs plans.
Cette tendance déplace l’attention des performances maximales d’entraînement vers le coût par résultat utile. Les opérateurs de centres de données doivent évaluer combien de tokens un système fournit par watt, par serveur, par rack et par unité de capital.
Gelsinger a soutenu que l’inférence doit devenir 10 000 fois plus efficace pour approcher l’échelle de la recherche et de l’utilisation généralisée des agents. Il a reconnu que ce chiffre était une estimation fondée sur des hypothèses de calcul, d’énergie et de coût.
Il ne s’agit pas d’une exigence sectorielle démontrée de manière indépendante. Il faut donc l’interpréter comme une déclaration sur l’ampleur du défi, et non comme un benchmark vérifié.
La pression sous-jacente reste néanmoins réelle. Un agent d’entreprise utile ne peut pas consacrer une puissance de calcul illimitée à chaque recherche de document, tâche logicielle ou interaction client.
La latence compte également. Un modèle qui génère rapidement de nombreux tokens peut tout de même sembler lent si le système environnant attend des bases de données, des transferts réseau, des contrôles de sécurité ou du code applicatif.
C’est là que l’utilisation des GPU devient importante. Les accélérateurs coûteux créent de la valeur lorsqu’ils traitent un travail adapté. Ils deviennent une charge économique lorsqu’ils sont bloqués par le déplacement des données ou l’attente d’une tâche sérielle.
Les puces d’inférence d’IA cherchent à améliorer cette équation grâce à des conceptions plus spécialisées. Certaines placent davantage de mémoire près du calcul. D’autres utilisent des architectures dataflow, une précision numérique réduite, une exécution déterministe ou des logiciels adaptés à des modèles précis.
Ces approches impliquent des compromis. Une puce spécialisée peut surpasser un GPU sur une charge de travail donnée, mais prendre en charge moins de modèles, de bibliothèques ou d’outils de déploiement.
L’intégration peut également effacer les économies théoriques. Les entreprises ont besoin de supervision, de sécurité, d’orchestration, de prise en charge des modèles et d’ingénieurs qui comprennent la plateforme.
C’est l’une des raisons pour lesquelles la position logicielle de Nvidia reste si importante. CUDA offre aux développeurs un environnement de programmation mature, tandis que les bibliothèques de Nvidia couvrent l’entraînement des modèles, l’inférence, le réseau et le traitement des données.
Un concurrent ne l’emporte pas simplement en publiant un benchmark de puce favorable. Il doit fournir un système fiable que les clients peuvent installer, programmer, exploiter et mettre à jour.
L’économie de l’inférence varie également selon l’application. Le chat interactif exige une faible latence. Le traitement hors ligne de documents peut privilégier le débit. La génération vidéo demande des schémas de mémoire et de calcul différents de ceux des systèmes de recommandation.
La taille des lots modifie aussi le résultat. Un fournisseur traitant de nombreuses requêtes simultanées peut maintenir un grand accélérateur plus occupé qu’un déploiement d’entreprise plus modeste.
Cette variabilité affaiblit toute affirmation universelle selon laquelle les GPU sont intrinsèquement trop coûteux. Elle renforce l’argument plus restreint de Gelsinger : le choix de l’architecture doit commencer par la charge de travail.
Les enjeux dépassent les fournisseurs de puces. Les fournisseurs de cloud doivent décider quels processeurs acheter et comment les tarifer. Les entreprises de logiciels doivent choisir entre portabilité et optimisation spécifique au matériel.
Les acheteurs d’entreprise font face à une autre question. Ils peuvent louer de la capacité, exploiter une infrastructure privée ou utiliser des services de modèles gérés qui masquent le matériel sous-jacent.
Le bon choix dépend de l’utilisation, des contrôles sur les données, de la latence et des effectifs. Le nom d’un processeur à la mode ne règle pas ces exigences.
Google a reconnu cette distinction des années avant le cycle actuel de l’IA générative. Son Tensor Processing Unit d’origine ciblait les charges de travail de réseaux neuronaux avec une conception spécifique au domaine.
Le nouvel Ironwood TPU de Google est explicitement positionné pour l’inférence et les grands modèles de raisonnement. Ce produit constitue un autre test de la thèse de Gelsinger.
Le marché évolue donc vers plusieurs types d’accélérateurs. La difficulté consiste à les faire fonctionner comme un environnement informatique fiable unique.
La stratégie CPU de Nvidia étaye la thèse de l’informatique hétérogène
La réponse de Nvidia aux limites des GPU n’est pas de les abandonner. Elle consiste à les entourer de processeurs conçus pour des usages précis et de logiciels étroitement intégrés.
Cette stratégie est visible dans Vera, le CPU personnalisé de Nvidia pour les charges de travail agentiques. L’entreprise indique que Vera gère l’orchestration, l’analytique, le traitement des données et d’autres tâches limitées par le CPU autour des accélérateurs d’IA.
Vera contient 88 cœurs Olympus conçus par Nvidia et un sous-système mémoire LPDDR5X. Nvidia affirme que le processeur fournit jusqu’à 1,2 téraoctet par seconde de bande passante mémoire.
Le CPU se connecte aux GPU Rubin via NVLink-C2C. Nvidia annonce jusqu’à 1,8 téraoctet par seconde de bande passante cohérente sur cette connexion.
Il s’agit de spécifications de l’entreprise, et non de résultats de performance indépendants. L’architecture importe néanmoins, car elle montre comment Nvidia définit le problème.
L’entreprise ne vend plus un GPU comme composant isolé. Elle décrit une plateforme d’informatique accélérée comprenant des CPU, des GPU, des composants réseau, des processeurs de stockage, des commutateurs, des bibliothèques et des conceptions à l’échelle du rack.
L’annonce du CPU Vera par Nvidia indique que le processeur cible les environnements d’exécution Python, le code en bac à sable, l’analytique et l’orchestration d’agents. Ce sont précisément les charges de travail à embranchements qui sous-tendent la critique de Gelsinger.
Ce chevauchement crée le renversement central de l’article. Gelsinger attaque les limites des GPU tandis que Nvidia investit massivement dans les composants nécessaires pour compenser ces limites.
Nvidia ne présente pas cet investissement comme un recul. L’entreprise présente l’intégration CPU-GPU comme une extension de l’informatique accélérée.
Gelsinger est arrivé à une conclusion semblable après la conférence GTC de Nvidia en mars 2026. Dans des images de Reuters, il a qualifié la connectivité CPU-GPU de cruciale pour la conception des systèmes.
Il a également salué la présentation technique de Nvidia tout en avertissant que l’entreprise devait encore tenir ses promesses. Cette réaction est bien plus nuancée que ne le suggère le titre viral.
La position de Nvidia se renforce grâce à son contrôle de la plateforme qui l’entoure. L’entreprise peut coordonner la conception des processeurs avec NVLink, le réseau, les bibliothèques logicielles et des racks complets.
Cette coordination peut réduire les coûts de communication et simplifier le déploiement. Elle accroît également la dépendance des clients à l’architecture d’un seul fournisseur.
La stratégie de plateforme crée une cible difficile à atteindre pour les concurrents. Une puce rivale peut offrir de meilleures performances par watt tout en ne disposant pas d’un réseau ou d’un support logiciel équivalent.
Nvidia peut aussi améliorer ses performances économiques sur plusieurs couches simultanément. Une interconnexion plus rapide peut accroître l’utilisation des GPU sans modifier leurs unités arithmétiques.
Les optimisations logicielles peuvent réduire l’usage de la mémoire. De nouveaux formats numériques peuvent augmenter le débit. Un processeur d’inférence spécialisé peut prendre en charge des charges de travail qui ne conviennent pas à un GPU conventionnel.
Cela signifie que les critiques de Pat Gelsinger à l’égard des GPU ne prédisent pas automatiquement le déclin de Nvidia. Nvidia peut réagir en redéfinissant ce qui constitue un système Nvidia.
L’entreprise se décrit déjà comme une plateforme de calcul accéléré plutôt que comme un simple fabricant de GPU. Sa feuille de route matérielle étaye cette caractérisation.
Les clients doivent néanmoins confronter ces affirmations à leurs propres applications. Une plateforme étroitement intégrée peut être efficace à grande échelle tout en restant excessive pour un déploiement plus modeste.
Elle peut également introduire une concentration opérationnelle. Un problème touchant le calendrier matériel, la couche réseau ou la pile logicielle d’un seul fournisseur peut affecter l’ensemble du système.
Toutefois, l’intégration procure un avantage commercial clair lorsque les clients privilégient la rapidité de déploiement. Les acheteurs acceptent souvent un certain verrouillage pour éviter d’assembler eux-mêmes plusieurs composants encore immatures.
La compétition immédiate n’oppose donc pas les GPU aux CPU. Elle oppose la plateforme intégrée de Nvidia à un assemblage plus ouvert de processeurs provenant de plusieurs fournisseurs.
Intel fait face au test le plus difficile de la thèse de Gelsinger
Intel adhère à l’argument selon lequel les charges de travail doivent primer, mais l’entreprise doit prouver que les clients veulent sa combinaison particulière de CPU, GPU, réseau et logiciels.
L’analyse de Gelsinger revêt un poids supplémentaire parce qu’Intel occupait autrefois la position la plus forte dans l’informatique de centres de données. Elle s’accompagne aussi d’un passif plus lourd.
Intel a sous-estimé le rôle à long terme des GPU de Nvidia et de sa plateforme pour développeurs. Ses propres efforts dans les accélérateurs d’IA ont eu du mal à atteindre une adoption comparable.
Cette histoire fait de Gelsinger à la fois un critique averti et un participant intéressé. Il travaille désormais avec des entreprises technologiques par le biais d’investissements en capital-risque et d’activités de conseil.
Certaines entreprises de son portefeuille développent le calcul par flux de données, la résilience des réseaux, les connexions optiques et d’autres alternatives aux architectures conventionnelles. Les lecteurs devraient tenir compte de ce contexte lorsqu’ils évaluent son enthousiasme.
La stratégie actuelle d’Intel suit néanmoins la même logique de systèmes. L’entreprise a présenté les CPU comme le plan de contrôle de l’IA agentique tout en développant un nouveau GPU de centre de données orienté inférence.
Crescent Island est conçu pour l’inférence en entreprise plutôt que comme une réplique directe des plus grands systèmes d’entraînement. Intel indique qu’il utilisera l’architecture Xe3P et intégrera 160 gigaoctets de mémoire LPDDR5X.
L’entreprise a présenté ce GPU comme adapté aux serveurs refroidis par air. Elle indique également que la conception vise la capacité mémoire, la bande passante, l’efficacité énergétique et les types de données d’inférence courants.
Intel prévoit des échantillons clients au cours du second semestre 2026. Tant que ces échantillons n’auront pas produit de résultats indépendants, Crescent Island restera un ensemble d’objectifs de conception.
La feuille de route officielle de Crescent Island illustre à la fois l’opportunité et le risque. Intel s’attaque à un problème reconnu, mais de nombreux concurrents voient la même ouverture.
Un vaste pool de mémoire peut aider à servir des modèles de grande taille. Il n’établit pas la compatibilité logicielle, le débit réel des applications, la fiabilité ou un coût total d’exploitation favorable.
Intel doit également expliquer comment les développeurs déplaceront leurs charges de travail vers la nouvelle plateforme. Ses ambitions en matière de logiciels ouverts concurrencent un environnement CUDA construit au fil de nombreuses années.
L’ouverture peut attirer les clients qui n’apprécient pas la dépendance à un fournisseur unique. Elle peut également générer de la complexité si les pilotes, compilateurs, bibliothèques et frameworks se comportent différemment selon les processeurs.
Ce problème logiciel est au cœur du calcul hétérogène. Répartir le travail entre plusieurs architectures crée des possibilités d’efficacité, mais chaque frontière introduit des mouvements de données et une surcharge de programmation.
Un avantage théorique de vitesse disparaît lorsqu’une application passe trop de temps à copier des informations ou à convertir des formats. Les équipes opérationnelles ont également besoin d’outils cohérents pour le débogage et la supervision.
Gelsinger a reconnu que le secteur ne dispose pas d’une couche logicielle consolidée pour l’IA hétérogène. Intel avait auparavant promu oneAPI comme moyen de programmer plusieurs architectures à l’aide d’outils communs.
L’objectif reste séduisant. Les preuves du marché restent mitigées.
Le plus grand avantage d’Intel pourrait être son parc installé de CPU. Les entreprises exploitent déjà des applications, des bases de données, des outils de sécurité et des environnements de virtualisation sur des systèmes x86.
Ces charges de travail ne disparaissent pas lorsqu’une entreprise adopte l’IA. Un agent doit souvent interagir avec elles.
Intel peut soutenir que ses CPU, ses produits Ethernet et ses accélérateurs d’inférence s’intègrent dans ces environnements existants. Nvidia peut répondre que ses racks intégrés offrent de meilleures performances de bout en bout.
AMD, Google, les fournisseurs de cloud et les startups de l’inférence ajoutent une pression supplémentaire. Chacun propose une combinaison différente de portabilité, spécialisation, disponibilité et contrôle.
Ce marché encombré rend la formule « les GPU sont nuls » moins utile pour les décisions d’achat. Les acheteurs ont besoin de résultats mesurés à partir de leurs propres modèles et schémas de service.
Ils devraient comparer le temps jusqu’au premier token, le débit soutenu, la consommation électrique, la capacité mémoire, l’utilisation, la récupération après incident et le travail logiciel. Le coût d’acquisition seul offre une image incomplète.
Les équipes ont également besoin d’archives rigoureuses de ces tests. Une base de connaissances d’ingénierie consultable peut préserver les conditions de benchmark, les décisions d’architecture et les rapports d’incident au fil des cycles d’évaluation.
Sans ce contexte, les organisations peuvent comparer des chiffres produits avec des modèles, tailles de lots, précisions et objectifs de latence différents. La décision qui en résulte peut récompenser le marketing plutôt que les performances du système.
L’affirmation « les GPU sont nuls » doit encore être confrontée à la réalité
Un argument architectural provocateur ne prouve pas qu’un matériel alternatif offrira de meilleurs résultats commerciaux.
La première incertitude concerne le périmètre. Les GPU traitent de nombreuses charges de travail, de l’entraînement et du calcul scientifique au rendu et à l’inférence.
Un résultat faible sur du code à embranchements n’annule pas de bons résultats en calcul parallèle dense. De même, de solides performances d’entraînement ne garantissent pas le coût le plus bas pour chaque service d’inférence.
La deuxième incertitude concerne l’objectif d’efficacité de Gelsinger, fixé à un facteur de 10 000. Il l’a décrit comme une estimation issue de l’économie des déploiements à l’échelle des moteurs de recherche.
Ce nombre exprime une ambition. Il ne décrit pas un écart vérifié partagé par toutes les applications d’IA.
Les comparaisons d’efficacité exigent un dénominateur. Les chercheurs peuvent mesurer les tokens par joule, les requêtes par seconde, la latence sous charge ou le coût total par tâche achevée.
Chaque métrique peut favoriser une architecture différente. La qualité du modèle complique davantage la comparaison, car une sortie plus rapide a une valeur limitée lorsqu’elle produit des résultats moins utiles.
La troisième incertitude concerne la demande. Les volumes d’inférence augmentent, mais l’économie des applications reste incertaine.
Certains agents créent une valeur claire en automatisant des tâches coûteuses. D’autres consomment de nombreux tokens tout en produisant des résultats que les employés doivent examiner de manière approfondie.
Une inférence moins chère peut étendre l’usage via le paradoxe de Jevons, où l’efficacité réduit les coûts et stimule une demande suffisante pour accroître la consommation totale. Elle ne garantit pas des applications rentables.
La quatrième incertitude est le logiciel. Les processeurs spécialisés débutent souvent avec des démonstrations impressionnantes. Une adoption large exige des compilateurs stables, le support des frameworks, des outils de sécurité, de l’orchestration et une disponibilité dans le cloud.
Les développeurs ont également besoin de portabilité. Une entreprise peut hésiter à optimiser en profondeur pour une puce de startup si une migration ultérieure devenait coûteuse.
La base logicielle installée de Nvidia lui donne la possibilité d’améliorer ses points faibles. Sa plateforme Rubin associe un CPU personnalisé, un GPU, du réseau, du traitement des données et des composants liés au stockage.
Nvidia affirme que Rubin peut réduire jusqu’à dix fois le coût des tokens d’inférence par rapport à Blackwell. Cette comparaison provient de Nvidia et requiert une validation indépendante sur des applications variées.
Elle remet néanmoins directement en cause l’idée selon laquelle la domination des GPU empêcherait des gains d’efficacité majeurs. Nvidia peut repenser le système environnant tout en maintenant la compatibilité avec sa plateforme logicielle.
La cinquième incertitude concerne l’infrastructure des centres de données. Les processeurs avancés nécessitent de l’électricité, du refroidissement, du réseau et de la capacité physique.
Une puce théoriquement efficace peut malgré tout créer des problèmes de déploiement si elle exige des configurations de refroidissement ou de réseau peu familières. À l’inverse, un accélérateur refroidi par air peut s’intégrer plus facilement aux installations existantes.
Les grands clusters soulèvent également des problèmes de fiabilité. À mesure que le nombre de composants augmente, les pannes deviennent plus fréquentes et les points de contrôle consomment des ressources supplémentaires.
Gelsinger a soutenu que des configurations gigantesques nécessitent une résilience matérielle et logicielle accrue. Nvidia considère la conception au niveau du rack et la co-conception comme faisant partie de sa réponse.
Aucune de ces positions ne peut être tranchée par un titre. Les opérateurs ont besoin de preuves en production couvrant la disponibilité, le temps de récupération, l’utilisation et l’effort de maintenance.
Le rôle passé de Gelsinger chez Intel ajoute une autre raison d’être prudent. Intel a manqué des aspects importants de la transition vers les GPU, alors que lui-même et d’autres dirigeants ont passé des années à défendre une informatique centrée sur les CPU.
Son argument actuel est plus nuancé que cette ancienne position. Pourtant, l’histoire d’Intel démontre qu’identifier une limite technique ne garantit pas une exécution réussie.
Nvidia mérite un examen tout aussi rigoureux. Une plateforme dominante peut façonner les benchmarks, les définitions et les attentes en matière d’achats autour de ses forces.
Les clients devraient vérifier si un système Nvidia complet améliore leurs charges de travail de bout en bout ou s’il augmente simplement l’ampleur de l’achat.
Le jugement le plus juste est plus nuancé que la rhétorique de l’un ou l’autre camp. Les GPU sont des accélérateurs exceptionnellement efficaces, mais ils ne sont pas des processeurs universels.
Les systèmes hétérogènes offrent une réponse crédible. Ils transfèrent aussi la difficulté de la conception des puces vers l’intégration, les logiciels et les opérations.
Ce que les lecteurs de Google News devraient surveiller ensuite
Trois signaux concrets montreront si Gelsinger a identifié une transition du marché ou s’il a simplement reformulé un principe architectural familier.
Le premier signal sera les tests indépendants des échantillons Crescent Island d’Intel. Intel prévoit l’échantillonnage au cours du second semestre 2026, ce qui fait des preuves fournies par les clients le test pratique le plus proche.
Les résultats utiles devraient couvrir de vrais modèles, plusieurs tailles de lots, des charges soutenues et la latence de bout en bout. Les comparaisons doivent également inclure la maturité logicielle et la puissance du système.
Des résultats solides et reproductibles étayeraient l’argument de Gelsinger selon lequel des alternatives optimisées pour l’inférence peuvent exercer une pression sur les déploiements de GPU généralistes. Des retards ou des démonstrations limitées l’affaibliraient.
Le deuxième signal sera l’adoption en production des systèmes Vera et Rubin de Nvidia. Nvidia a cité de grands laboratoires d’IA, fournisseurs de cloud et fabricants qui prévoient d’utiliser Vera.
Les plans ne sont pas des déploiements. Les acheteurs doivent surveiller l’utilisation mesurée, l’économie des tokens, les calendriers de livraison et la fiabilité lorsque les systèmes seront mis en service à plus grande échelle.
Si Vera maintient les GPU occupés en traitant efficacement le travail de flux de contrôle, Nvidia aura validé le calcul hétérogène au sein de sa propre plateforme. Ce résultat soutient le mécanisme de Gelsinger tout en renforçant Nvidia sur le plan commercial.
Le troisième signal est la portabilité des charges de travail entre des puces d’inférence d’IA concurrentes. Les clients doivent pouvoir déplacer leurs modèles entre Nvidia, Intel, AMD, Google et des accélérateurs spécialisés sans reconstruire des applications entières.
Les progrès des compilateurs, des runtimes d’inférence et des formats de modèles ouverts réduiraient l’avantage logiciel de Nvidia. La fragmentation ou des résultats incohérents préserveraient la position de l’acteur établi.
Le prochain titre de Google News mettra probablement l’accent sur un benchmark, un partenariat ou une déclaration spectaculaire d’un dirigeant. Les lecteurs devraient regarder au-delà pour trouver des preuves concernant des systèmes complets.
Demandez quel processeur a pris en charge chaque étape, quelle quantité de données a circulé entre les composants et si le logiciel est resté maintenable. Examinez ensuite le résultat sous une demande de production soutenue.
L’argument de Gelsinger compte parce que l’infrastructure d’IA se diversifie au moment même où la dépendance à son égard augmente. Ses propos ne doivent pas se substituer à la vérification.
Pour les développeurs et les acheteurs d’entreprise, l’action pratique est simple. Documentez votre charge de travail, testez plusieurs architectures et mesurez l’ensemble du parcours, de la requête au résultat utile.
Le système gagnant ne sera pas celui qui formule l’affirmation la plus tapageuse. Ce sera celui qui fournit un travail fiable dans les contraintes réelles d’alimentation, de latence, de logiciel et d’exploitation.


