Les exigences CPU de l’IA agentique de Google placent le calcul inactif sous surveillance

Google affirme que les agents d’IA créeront de nouvelles exigences en matière de CPU, alors même que leurs environnements d’exécution passent de longues périodes en attente. Les exigences CPU de l’IA agentique de Google posent donc un problème plus complexe que le simple ajout de processeurs : maintenir des travailleurs logiciels persistants disponibles sans réserver du matériel inactif. Les CPU, processeurs généralistes qui exécutent le code des applications, deviennent essentiels lorsque les agents dépassent la génération de réponses et commencent à piloter des logiciels.

Dans une interview accordée à EE Times le 30 octobre, Mark Lohmeyer, dirigeant de Google Cloud, a décrit des agents appelant des services, naviguant sur des sites web et exécutant du code. Ces activités élargissent le travail de calcul autour du modèle. Les GPU, processeurs optimisés pour les calculs parallèles, et les TPU de Google, puces spécialisées dans l’apprentissage automatique, assurent toujours une grande partie des calculs du modèle. L’application qui les entoure requiert sa propre capacité d’exécution.

Cette évolution exerce une pression sur les plateformes cloud et les équipes d’infrastructure des entreprises. Un système conçu autour de la vitesse de service des modèles peut néanmoins décevoir si les agents attendent leurs espaces de travail, perdent l’état de leur session ou réservent inutilement des ressources. AWS poursuit des services d’exécution similaires, offrant aux acheteurs un point de comparaison concurrentiel. L’enjeu central oppose les environnements réservés en continu à une infrastructure qui préserve le travail d’un agent tout en libérant le calcul inactif.

Les exigences CPU de l’IA agentique de Google vont au-delà du service des modèles

L’argument de Google porte sur l’infrastructure qui entoure un modèle d’IA, et non sur un remplacement des processeurs spécialisés pour l’IA.

Lohmeyer, vice-président et directeur général de l’IA et de l’infrastructure informatique chez Google, a décrit cette distinction dans la discussion sur les charges de travail des agents. Selon EE Times, les agents transforment la demande d’un utilisateur en sous-tâches impliquant l’exécution de logiciels ordinaires. La charge de travail qui en résulte est intermittente, ce qui crée des exigences différentes pour les processeurs, le stockage et la gestion des ressources.

L’importance réside dans ce qui se produit après qu’un modèle a sélectionné une action. Produire une instruction plausible et accomplir la tâche demandée consomment des ressources différentes. Un navigateur doit charger une page, un programme doit s’exécuter et une application doit renvoyer un résultat. Ajouter de l’intelligence à la décision ne supprime pas ces opérations.

Un agent, c’est-à-dire un logiciel qui utilise un modèle pour sélectionner et exécuter des actions vers un objectif, relie ces étapes. Son utilité dépend de la séquence complète. Une réponse rapide du modèle offre un bénéfice limité si l’environnement d’exécution suivant met trop de temps à devenir utilisable.

Cela aide à comprendre pourquoi les besoins en CPU méritent une attention parallèle à la capacité de service des modèles. Le service des modèles consiste à exécuter un modèle entraîné afin de produire des sorties. L’exécution globale d’un agent inclut cette opération, mais aussi le code et les services qui l’entourent. Ne mesurer que le modèle laisse une partie de l’application hors du champ des performances.

L’interview n’établit pas non plus un vainqueur universel parmi les processeurs. Lohmeyer a indiqué que Google Cloud utilise des processeurs Intel et AMD aux côtés de ses puces Axion basées sur Arm. Arm et x86 sont des familles de jeux d’instructions de processeurs, qui déterminent les instructions machine exécutées par les logiciels. Différentes charges de travail d’agents peuvent favoriser des combinaisons différentes de performances par cœur, de nombre de cœurs et de stockage associé.

Cette distinction est importante pour interpréter le titre. Davantage d’activité d’agents ne signifie pas automatiquement que chaque catégorie de CPU en bénéficie de la même manière. Une charge de travail dominée par l’exécution de programmes diffère d’une autre dominée par l’attente de services externes. Les acheteurs doivent encore comprendre le travail qu’ils exécutent réellement.

L’infrastructure d’agents de Google rend désormais cet argument plus concret. Le 22 octobre, Google a présenté Agent Compute Engine, décrivant un service qui prend déjà en charge les tâches de travail de Gemini. Son annonce visait une disponibilité en aperçu client dans les mois à venir. Au 1er novembre, cette formulation ne doit pas être interprétée comme une disponibilité générale.

Cette chronologie donne à l’interview un contexte précis. Google explique un problème d’exécution tout en préparant un service commercial destiné à le résoudre. Cela rend son analyse technique pertinente, tout en donnant aux lecteurs une raison de distinguer l’architecture documentée des bénéfices attendus pour les clients.

Les équipes d’infrastructure héritent du coût de l’attente

La pression immédiate s’exerce sur les équipes chargées de maintenir les environnements d’agents prêts entre les phases de travail utile.

Un environnement persistant conserve les éléments de travail entre les interactions. Cela peut inclure des fichiers, des logiciels installés et l’état de l’application. La persistance rend un agent utile sur une tâche étendue, mais complique la gestion des ressources. Maintenir des informations disponibles et maintenir un processeur alloué sont deux exigences distinctes.

Prenons l’exemple d’un assistant de programmation travaillant sur une modification de dépôt. Il lit des fichiers, exécute un programme, attend la sortie d’un modèle et demande l’approbation d’un développeur. L’espace de travail reste pertinent pendant toutes ces pauses. Le processeur n’a pas nécessairement besoin de rester réservé pendant la même période.

Il s’agit d’une charge de travail illustrative, et non d’un déploiement client mesuré. Elle montre pourquoi le temps écoulé d’une session peut représenter de façon trompeuse la demande réelle d’exécution. Une session peut rester précieuse tout en étant inactive. Considérer chaque session ouverte comme continuellement occupée masque cette distinction.

La conséquence atteint le modèle économique de l’application. Un acheteur qui acquiert une expérience agentique veut un travail accompli et une continuité fiable. Le fournisseur d’infrastructure doit fournir ces résultats tout en décidant quelle quantité de matériel réserver. Une mauvaise allocation peut accroître les dépenses d’exploitation sans améliorer le résultat pour l’utilisateur.

L’utilisation CPU des agents, soit la part de la capacité disponible du processeur consacrée à l’exécution du travail, devient pertinente ici. Toutefois, un chiffre d’utilisation moyen ne décrit pas l’ensemble de l’expérience. Une plateforme peut afficher une faible utilisation moyenne tout en peinant lorsque de nombreux agents en attente redeviennent actifs simultanément.

Cela crée des exigences opérationnelles concurrentes. Les fournisseurs veulent partager la capacité efficacement, tandis que les utilisateurs attendent un accès immédiat lorsque le travail reprend. Regrouper étroitement les environnements n’aide que si le système peut gérer la reprise d’activité. Les retards pendant les périodes chargées peuvent annuler l’avantage de maintenir les sessions disponibles.

La description par Google, le 15 septembre, d’Agent Substrate aborde explicitement les environnements d’exécution inactifs et les pics d’activité. L’entreprise décrit un logiciel qui sépare l’exécution des agents de la gestion des machines sous-jacentes. Elle propose également différentes approches d’isolation, reflétant le fait que les charges de travail ne partagent pas des exigences de sécurité identiques.

La pression s’étend aux achats des entreprises. Les discussions sur la capacité doivent désormais inclure la façon dont un agent se met en pause, conserve son travail et reprend. Une spécification de processeur seule ne peut répondre à ces questions. Le comportement du service entre les salves d’exécution devient une partie du produit acheté.

Cela modifie également les responsabilités internes. Une équipe applicative peut choisir un framework d’agents tandis qu’une équipe de plateforme gère son runtime, l’environnement qui exécute son logiciel. Si aucune des deux équipes ne mesure l’allocation de ressources inactives, une consommation inutile peut échapper à leurs responsabilités respectives. Le problème résultant apparaît dans la facture d’infrastructure plutôt que dans l’évaluation du modèle.

Pour les développeurs, l’implication pratique est architecturale. Les expériences utilisateur de longue durée ne devraient pas exiger automatiquement des réservations de processeur d’une durée tout aussi longue. La capacité d’une plateforme à séparer ces durées détermine à quel point un prototype utile peut évoluer confortablement vers un service.

Les espaces de travail persistants remettent en question le calcul réservé en continu

La question centrale de conception est de savoir si un agent peut conserver son environnement de travail tout en abandonnant le matériel dont il n’a temporairement pas besoin.

Les applications traditionnelles gèrent déjà les périodes d’inactivité, de sorte que le problème sous-jacent a des précédents. Les charges de travail des agents l’accentuent en combinant du code potentiellement non fiable avec des espaces de travail personnalisés et continus. L’environnement doit rester utile malgré les interruptions sans devenir une allocation permanente inutile.

Une microVM est une machine virtuelle allégée qui utilise la virtualisation matérielle pour isoler son environnement d’exécution. Un sandbox est un environnement restreint destiné à contenir du code et à limiter ses accès. Ces concepts se recoupent dans les plateformes d’agents, mais ils décrivent des éléments différents : un mécanisme d’implémentation et un objectif de sécurité.

Le mécanisme ne règle pas à lui seul l’économie du système. Une petite machine isolée peut encore réserver des ressources sans rien faire. L’efficacité dépend de la façon dont le service gère l’ensemble de son cycle de vie. Démarrer, mettre en pause, préserver, restaurer et supprimer un environnement deviennent tous des opérations pertinentes.

Un snapshot, c’est-à-dire une représentation sauvegardée de l’état d’exécution, offre un moyen de préserver la continuité. Restaurer cet état peut éviter de reconstruire un environnement depuis le début. Toutefois, la sauvegarde et la restauration impliquent également du stockage et des mouvements de données. Déplacer une charge de travail hors de la mémoire active transfère les exigences ailleurs.

Cela rend la planification CPU indissociable de la planification du stockage. Libérer des processeurs aide moins lorsque la restauration d’un environnement crée un long délai. De même, tout préserver indéfiniment peut créer une obligation de stockage croissante. Une conception complète nécessite des politiques concernant l’état conservé autant que l’exécution active.

L’analyse technique de Google sur les environnements d’agents persistants décrit le checkpointing des sessions inactives tout en préservant les fichiers et la mémoire. Le checkpointing consiste à sauvegarder un état d’exécution récupérable. Google décrit également le maintien des identifiants de longue durée hors des environnements invités et le routage des requêtes par des passerelles contrôlées. Il s’agit de descriptions par l’entreprise de sa conception, et non de conclusions indépendantes en matière de sécurité.

Le point analytique plus large est que la continuité devient une propriété des systèmes. Les utilisateurs perçoivent un agent comme une tâche continue, tandis que l’infrastructure peut passer par différents états de ressources en arrière-plan. Une mise en œuvre réussie masque ces transitions sans perdre de travail ni affaiblir les contrôles d’accès.

AWS fournit une comparaison utile avec son introduction, le 22 juin, de Lambda MicroVMs. AWS décrit des environnements isolés pour du code écrit par des utilisateurs ou généré par l’IA, avec un contrôle direct du cycle de vie et un état préservé. Son implémentation repose sur Firecracker, la technologie de virtualisation légère de l’entreprise.

Cette comparaison confirme l’existence d’un problème d’infrastructure commun. Elle n’établit pas que les services de Google et d’AWS offrent des performances équivalentes, prennent en charge des charges de travail identiques ou imposent des contraintes opérationnelles comparables. Leurs descriptions publiées constituent un point de départ pour l’évaluation, plutôt qu’une comparaison achevée.

L’infrastructure d’agents de Google s’inscrit donc dans une transition plus large vers la gestion des environnements d’exécution comme partie intégrante de l’application agentique. La concurrence pertinente ne consiste pas simplement à savoir quel fournisseur propose le plus de cœurs de processeur. Elle consiste à déterminer quel service préserve le travail utile, gère la reprise d’activité et rend la consommation de ressources compréhensible.

Pour les acheteurs, cette distinction modifie la question d’évaluation. Demander à quelle vitesse un environnement vide démarre ne suffit pas. La question la plus révélatrice concerne un véritable espace de travail, avec ses dépendances et son travail conservé, remis en service après une interruption.

Une densité d’agents plus élevée ne permet pas d’établir une prévision de la demande en CPU

Une explication crédible d’un surcroît de travail CPU diffère des preuves indiquant la quantité de matériel supplémentaire dont le marché aura besoin.

Les besoins en CPU de l’IA agentique de Google comportent des forces opposées. Davantage de tâches agentiques créent un surcroît de travail d’exécution. Un meilleur partage des ressources réduit le matériel nécessaire pour prendre en charge une population donnée d’agents. Le résultat net dépend de l’adoption, de l’intensité des charges de travail et de l’efficacité des améliorations d’infrastructure.

Les propres documents d’ingénierie de Google illustrent l’importance de cette distinction. Dans un benchmark sur la densité d’agents publié le 30 juillet, l’entreprise a testé une charge de travail OpenClaw sur une configuration machine fixe. Elle a indiqué prendre en charge davantage d’agents grâce à des modifications de l’exécution et de la gestion des ressources. Ces résultats concernent une charge de travail et une configuration particulières.

Ils ne doivent pas devenir un multiplicateur universel pour les déploiements de production. Différents agents conservent des quantités de mémoire différentes, exécutent des logiciels différents et passent des durées variables en attente. Les configurations de sécurité affectent également les ressources disponibles pour les applications. Un résultat de densité doit conserver ses conditions environnantes pour rester significatif.

La même prudence s’applique dans l’autre sens. Une prévision d’expansion du travail CPU ne démontre pas que les processeurs deviennent la ressource limitante pour chaque agent. Certaines applications passeront davantage de temps à attendre les réponses des modèles. D’autres se heurteront à des restrictions de services externes ou à des délais de stockage.

L’utilisation CPU des agents est donc utile dans le cadre d’un ensemble de mesures plus large. Un chiffre élevé peut indiquer une exécution productive, mais il peut aussi accompagner des contentions et des tâches retardées. Un chiffre faible peut indiquer du gaspillage, mais il peut aussi refléter une capacité de réserve intentionnelle. L’interprétation exige les données de performance et de fiabilité de l’application.

L’unité commerciale compte également. Compter les agents lancés peut valoriser un service qui accomplit peu de travail utile. Compter les sessions actives peut masquer des échecs répétés ou des tâches abandonnées. Les résultats achevés et acceptés offrent une base plus exigeante pour déterminer si les améliorations d’infrastructure profitent aux clients.

Une autre incertitude entoure le mot « agent ». Une courte requête d’exécution de code et un espace de travail navigateur persistant peuvent tous deux porter cette étiquette. Leurs exigences en processeur et en persistance diffèrent. Les agréger dans une catégorie de demande indifférenciée masque la composition des charges de travail qui détermine les besoins réels en ressources.

C’est pourquoi l’analyse des CPU devrait éviter de désigner un vainqueur architectural. Les conceptions Intel, AMD et basées sur Arm rivalisent au sein de configurations de services plus larges. La compatibilité logicielle, la capacité mémoire et l’accès au stockage peuvent influencer le résultat en parallèle de la vitesse d’exécution du processeur. Une comparaison au niveau de l’application doit conserver des critères de réussite cohérents.

La conclusion la mieux étayée est plus restreinte qu’une prévision de marché. Google a identifié le travail d’exécution ordinaire comme un composant important des services d’agents. L’orientation de son produit répond à l’écart entre les sessions continues et l’activité intermittente. L’ampleur de la demande matérielle qui en résultera reste une question empirique.

Cela laisse la place à la fois à une adoption accrue et à une meilleure efficacité. Si les agents deviennent utiles dans davantage de flux de travail, l’exécution totale peut augmenter malgré un meilleur partage des ressources. Si l’adoption déçoit, une infrastructure améliorée à elle seule ne générera pas une demande durable. Le mécanisme technique explique une opportunité sans établir sa taille finale.

L’isolation doit résister à la recherche d’une meilleure utilisation

La récupération des ressources inactives ne crée de la valeur que lorsque la plateforme préserve les frontières de sécurité et l’état de travail dont les clients ont besoin.

Les agents peuvent exécuter du code influencé par la sortie d’un modèle et des informations externes. Cela crée une relation de confiance différente de celle qui consiste à exécuter uniquement des logiciels écrits et examinés par les développeurs d’une application. L’environnement d’exécution doit tenir compte d’actions que son opérateur n’a pas explicitement conçues.

L’isolation limite ce qu’un environnement d’exécution peut atteindre. L’autorisation détermine les actions qu’une identité est autorisée à effectuer. Ces contrôles résolvent des problèmes liés mais distincts. Un environnement isolé peut toujours faire un usage abusif d’un accès qu’un système lui accorde légitimement.

Cette distinction évite une erreur de catégorie courante. Une frontière d’exécution sécurisée ne démontre pas qu’un agent comprend correctement une demande. Elle ne démontre pas non plus que chaque action autorisée sert l’intention de l’utilisateur. Les contrôles d’infrastructure contiennent l’exécution, tandis que les contrôles applicatifs régissent la tâche.

La discussion sur l’efficacité doit préserver ces deux couches. Regrouper davantage de travail sur du matériel partagé accroît l’importance d’une séparation fiable. Préserver les sessions soulève des questions sur les données conservées et l’expiration des accès. La reprise d’un espace de travail ne devrait pas rétablir silencieusement des autorisations qui ne sont plus appropriées.

Prenons un agent de recherche d’entreprise qui lit des documents internes et prépare une note de synthèse. L’agent a besoin d’une continuité suffisante pour conserver ses progrès. Son accès doit néanmoins continuer à refléter les autorisations actuelles de l’utilisateur. Un espace de travail sauvegardé et une décision d’autorisation ne doivent pas être traités comme des enregistrements interchangeables.

Cet exemple relie également la conception de l’infrastructure à la qualité de l’information. Préserver un processus n’aide que si le système conserve les bonnes sources et le bon matériel de travail. Les équipes qui créent une base de connaissances interrogeable font face à un défi organisationnel analogue : maintenir les preuves techniques accessibles tout au long du travail en cours. Cette préoccupation complète la persistance d’exécution sans la remplacer.

La résilience opérationnelle mérite une attention égale. Un environnement qui reprend correctement dans des conditions normales peut se comporter différemment après une écriture interrompue ou une connexion échouée. Les acheteurs doivent comprendre ce qui survit à une pause et ce que l’application doit recréer. Sans cela, une continuité apparente peut masquer une récupération incomplète.

Le même principe s’applique au nettoyage. Un agent qui cesse de fonctionner devrait finir par libérer des ressources selon une politique de conservation explicite. Tout conserver indéfiniment crée des obligations inutiles. Supprimer trop agressivement compromet l’expérience continue que l’infrastructure a été conçue pour soutenir.

Ce sont autant de raisons d’examiner attentivement les affirmations de Google, sans écarter la conception sous-jacente. La documentation de l’entreprise explique les frontières et le comportement prévus. Les tests indépendants et l’expérience opérationnelle établissent le comportement de ces fonctionnalités dans des conditions applicatives réelles. Aucun ne devrait se substituer à l’autre.

L’implication pour les achats est concrète. Évaluez ensemble l’isolation, la continuité et l’efficacité des ressources. Un service qui optimise une dimension tout en laissant les autres floues ne résout pas le problème d’infrastructure dans son ensemble. Le résultat pertinent est un travail utile livré dans un modèle de sécurité et d’exploitation acceptable.

Les prochaines preuves devraient venir de l’accès, des charges de travail et des résultats

La prochaine étape de cette histoire dépend du comportement d’exécution visible par les clients, plutôt que d’affirmations supplémentaires selon lesquelles les agents ont besoin de CPU.

Le premier signal est l’accès pratique à Agent Compute Engine. L’annonce d’octobre de Google évoque une disponibilité en preview dans les mois à venir. Au cours des prochains mois, les conditions d’accès publiées, les configurations prises en charge et les limites opérationnelles montreront comment les clients peuvent évaluer cette architecture.

Une preview renforcerait l’analyse en déplaçant la discussion vers un comportement de service observable. Un accès limité fournirait tout de même des éléments utiles, mais restreindrait les comparaisons. La documentation devrait clarifier ces limites plutôt que de laisser les lecteurs les déduire des descriptions de l’usage interne de Google.

Le deuxième signal réside dans des tests de charges de travail représentatives. Les comparaisons utiles devraient inclure l’exécution active, l’attente, l’interruption et la récupération au sein d’une même tâche. Un environnement qui se lance rapidement mais reprend mal n’offre pas une continuité cohérente. De même, un état inactif efficace importe moins si des transitions répétées perturbent le travail.

Ces tests devraient divulguer la charge de travail et les conditions qui l’entourent. Les besoins en mémoire, les fichiers conservés, la concurrence et les paramètres d’isolation affectent tous l’interprétation. Les comparaisons deviennent plus instructives lorsqu’elles incluent AWS ou d’autres services d’exécution pertinents avec des exigences applicatives équivalentes.

Ces éléments renforceraient l’argument de Google si une meilleure gestion des ressources préserve les taux d’achèvement et la réactivité. Ils affaibliraient l’argument commercial si les économies exigent des délais inacceptables ou une compatibilité applicative plus limitée. Dans les deux cas, ils apporteraient davantage d’informations qu’un benchmark de processeur isolé.

Le troisième signal est le retour des clients sur le travail achevé. Les déploiements en entreprise peuvent révéler si l’infrastructure d’exécution demeure une contrainte importante après la sélection du modèle. Ils peuvent également montrer si les environnements persistants améliorent suffisamment l’achèvement des tâches pour justifier leur complexité opérationnelle.

Ces rapports devraient distinguer les problèmes de modèle des problèmes d’exécution. Un agent qui choisit la mauvaise action connaît un échec différent d’un environnement qui ne peut pas reprendre. Combiner les deux dans un unique indicateur de réussite rend l’infrastructure difficile à évaluer. Les séparer aide les acheteurs à comprendre quelles améliorations comptent.

Les besoins en CPU de l’IA agentique de Google deviendront plus faciles à évaluer lorsque ces signaux apparaîtront ensemble. L’accès au service établit ce que les clients peuvent utiliser. Les tests représentatifs établissent comment l’exécution se comporte. Les résultats clients établissent si le système obtenu produit suffisamment de valeur pour justifier un déploiement continu.

Pour l’instant, les informations disponibles étayent un changement d’accent clair. Les applications agentiques exigent une attention portée à l’exécution logicielle qui entoure un modèle, y compris durant les périodes où cette exécution s’arrête. Les CPU restent essentiels à ce travail, tandis que la persistance et la gestion des ressources déterminent avec quelle efficacité les plateformes les fournissent.

Commencez par un flux de travail que votre organisation souhaite réellement confier à un agent. Identifiez les étapes qui exécutent du code, celles qui attendent et celles qui nécessitent des fichiers ou des autorisations conservés. Demandez aux fournisseurs potentiels de démontrer ces transitions en utilisant la même tâche et les mêmes critères d’acceptation. Gardez l’évaluation centrée sur le travail achevé, l’état récupérable et une consommation de ressources compréhensible. Cette approche donne aux développeurs et aux acheteurs un moyen pratique d’évaluer l’argument de Google à mesure que de nouveaux services deviennent accessibles. La décision consiste moins à accepter une prévision générale de la demande en CPU qu’à établir si une plateforme soutient économiquement une expérience d’agent continue. Que devient l’ordinateur de votre agent lorsque celui-ci n’a rien à faire ?