À mesure que les entreprises passent des prototypes d’IA générative à des agents autonomes capables de planifier, appeler des outils, manipuler du contexte et exécuter du code, la question de l’infrastructure devient centrale. Tout faire tourner sur des accélérateurs coûteux n’est pas toujours pertinent. C’est précisément le terrain sur lequel Arm et Google Cloud veulent positionner les processeurs Google Axion, des CPU serveur basés sur l’architecture Arm.
L’idée n’est pas de remplacer les GPU ou les accélérateurs spécialisés pour les grands modèles. Elle consiste plutôt à mieux découper les charges de travail : réserver les accélérateurs aux tâches lourdes de raisonnement, d’entraînement ou d’inférence massive, et confier aux CPU les opérations d’orchestration, de routage, de gestion mémoire et d’exécution sécurisée qui caractérisent les architectures d’IA agentique.
Pourquoi l’IA agentique change les besoins d’infrastructure
Un agent IA ne se limite pas à générer une réponse. Dans un scénario d’entreprise, il peut analyser une demande, consulter une base documentaire, appeler une API interne, déclencher un workflow, écrire du code temporaire, vérifier un résultat, puis relancer une étape si nécessaire. Cette logique crée une charge très différente d’une simple requête envoyée à un modèle de langage.
Les plateformes doivent donc gérer plusieurs types de calcul en parallèle :
- l’inférence du modèle, souvent adaptée aux GPU ou à d’autres accélérateurs ;
- l’orchestration des agents, qui consiste à coordonner des étapes, des outils et des appels réseau ;
- la gestion de l’état, par exemple l’historique de conversation, les variables intermédiaires ou les résultats partiels ;
- le routage sémantique, pour envoyer une requête vers le bon outil, modèle ou service ;
- l’exécution isolée de code généré, indispensable lorsque l’agent produit lui-même des scripts ou des commandes.
Dans ce contexte, l’enjeu n’est plus seulement la puissance brute. Il s’agit de choisir le bon type de calcul pour chaque étape afin d’éviter une architecture trop chère, trop rigide ou difficile à sécuriser.
Google Axion : des CPU Arm pensés pour le cloud et l’ère de l’IA
Google Axion est la première famille de processeurs serveur personnalisés de Google basée sur Arm. Annoncée en avril 2024, elle s’inscrit dans le portefeuille Compute Engine de Google Cloud, qui combine des instances généralistes et des offres spécialisées selon les besoins applicatifs.
Axion vise notamment les charges cloud à grande échelle, les applications généralistes, certaines charges IA exécutées sur CPU et les environnements qui ont besoin d’une compatibilité Arm native ou d’un accès matériel direct. Google met aussi en avant son expérience accumulée dans le silicium personnalisé, déjà visible avec ses TPU et d’autres composants conçus pour ses propres centres de données.
Pour les équipes techniques, l’intérêt est concret : disposer d’instances CPU plus efficaces pour les tâches distribuées et concurrentes qui entourent les modèles d’IA. Là où un accélérateur est pertinent pour générer des tokens ou exécuter un modèle complexe, un CPU peut être plus rationnel pour piloter des milliers de petites opérations, gérer de nombreuses connexions ou maintenir l’état d’agents actifs.
Associer chaque charge de travail au bon processeur
Le message porté par Arm et Google est simple : toutes les charges IA ne justifient pas le même type de matériel. Les GPU restent essentiels pour les grands modèles et les opérations très parallélisables, mais une architecture agentique comporte aussi beaucoup de tâches qui ressemblent davantage à du cloud natif classique qu’à du calcul matriciel intensif.
Bhumik Patel, Director of Software Ecosystem Development chez Arm, résume cette logique en expliquant que les tâches agentiques comme l’orchestration, la communication avec des API ou la gestion mémoire correspondent bien aux forces des CPU. Ce sont des charges distribuées, concurrentes, avec de nombreux allers-retours et une forte dimension système.
Dans une pile IA moderne, le bon découpage peut donc ressembler à ceci :
- les accélérateurs traitent les requêtes lourdes envoyées aux grands modèles ;
- les CPU Axion gèrent l’orchestration, le contexte, les appels API et la logique applicative ;
- les environnements isolés exécutent le code généré par les agents ;
- Kubernetes coordonne le placement, la montée en charge et la disponibilité.
Cette séparation permet de réduire ce que l’on pourrait appeler une « taxe d’inférence » : le fait de consommer des ressources accélérées coûteuses pour des tâches qui n’en ont pas réellement besoin. À grande échelle, ce point peut peser lourd dans le coût total d’exploitation.
GKE Agent Sandbox : sécuriser l’exécution du code généré par les agents
L’un des points les plus sensibles de l’IA agentique concerne l’exécution de code produit dynamiquement. Un agent capable d’écrire et de lancer du code peut devenir très utile pour automatiser des tâches, tester des hypothèses ou manipuler des données. Mais exécuté sans garde-fou, ce code peut aussi représenter un risque majeur pour les applications voisines, le cluster Kubernetes ou l’infrastructure sous-jacente.
C’est là qu’intervient Google Kubernetes Engine Agent Sandbox. Cette primitive Kubernetes native et open source est conçue pour exécuter du code généré par l’IA dans un environnement isolé. Sur des instances N4A alimentées par Google Axion, Google indique que cette approche peut offrir jusqu’à 30 % de meilleur rapport prix-performance que des charges comparables chez un autre hyperscaler.
Le mécanisme s’appuie notamment sur gVisor, un noyau applicatif open source développé par Google pour renforcer l’isolation des conteneurs. L’objectif est d’intercepter et de valider les appels système avant qu’ils n’atteignent le noyau hôte, afin de limiter les risques lorsqu’un code non fiable est exécuté.
GKE Agent Sandbox prend également en charge des politiques réseau Kubernetes en mode « default-deny », ainsi que des interfaces permettant d’intégrer d’autres solutions de sandbox open source, comme Kata Containers. Cette flexibilité est importante pour les organisations qui doivent adapter le niveau d’isolation à leurs exigences internes de sécurité, de conformité ou de performance.
Pourquoi l’isolation devient indispensable
Dans une architecture agentique, un agent peut recevoir une consigne ambiguë, générer un script incorrect ou manipuler des données sensibles. Même sans intention malveillante, une erreur peut provoquer des appels réseau inattendus, une consommation excessive de ressources ou une tentative d’accès à des fichiers non prévus.
Un environnement sandboxé réduit ces risques en séparant l’exécution de l’agent du reste du cluster. Pour les équipes DevOps et sécurité, c’est une condition essentielle avant de passer d’une démonstration IA à une exploitation en production.
Les snapshots de pods pour rendre les agents plus rapides et plus flexibles
Autre élément intéressant : les GKE Pod snapshots. Ils permettent de sauvegarder puis de restaurer l’état exact d’un environnement sandboxé. Pour des agents qui peuvent rester inactifs, être déplacés entre nœuds ou reprendre une tâche longue, cette capacité devient très utile.
Concrètement, les snapshots peuvent apporter quatre bénéfices importants :
- Démarrage plus rapide : un environnement peut repartir depuis un état préchauffé au lieu d’être initialisé depuis zéro.
- Agents longue durée : une sandbox peut être mise en pause puis reprise plus tard, sans perdre l’avancement du processus.
- Charges avec état : le contexte d’un agent, comme l’historique de conversation ou des calculs intermédiaires, peut être conservé.
- Reproductibilité : un état donné peut servir de base pour lancer plusieurs sandboxes identiques à des fins de test ou de production.
Cette approche répond à une difficulté fréquente des agents IA : leur comportement dépend fortement du contexte. Pouvoir figer, restaurer et répliquer cet état facilite le débogage, la mise à l’échelle et l’optimisation des coûts.
Ce que cela change pour les entreprises qui déploient des agents IA
Pour les DSI, équipes plateforme et responsables IA, le message est moins marketing qu’architectural : l’IA agentique impose de penser en infrastructure hétérogène. Les accélérateurs ne disparaissent pas, mais ils doivent être utilisés là où ils créent le plus de valeur. Les CPU, eux, redeviennent stratégiques pour toutes les couches de coordination, de sécurité et d’exécution applicative.
Une entreprise qui construit une plateforme d’agents devrait donc se poser plusieurs questions avant de généraliser son architecture :
- quelles tâches nécessitent réellement un GPU ou un accélérateur spécialisé ?
- quelles opérations peuvent être déplacées vers des instances CPU plus économiques ?
- comment isoler le code généré par les agents avant de l’exécuter ?
- comment conserver et restaurer l’état des agents sans surconsommer de ressources ?
- comment mesurer le coût par workflow complet, et pas seulement le coût par requête modèle ?
Cette grille de lecture est particulièrement pertinente pour les cas d’usage à forte concurrence : assistants internes d’entreprise, agents de support client, automatisation de tâches DevOps, analyse de données à la demande, génération et test de code, ou encore agents capables d’interagir avec des outils métier.
Une stratégie cloud plus rationnelle pour l’IA agentique
La combinaison de Google Axion, de Google Kubernetes Engine et d’Agent Sandbox illustre une évolution plus large du marché : l’IA ne se résume plus à empiler des GPU. Les plateformes gagnantes seront probablement celles capables de répartir dynamiquement les tâches entre plusieurs types de ressources, avec un bon équilibre entre performance, coût et sécurité.
Pour Google Cloud et Arm, les processeurs Axion servent ce positionnement : fournir une base CPU efficace pour les couches d’orchestration et d’exécution qui entourent les modèles. Pour les entreprises, l’intérêt est de construire des agents plus soutenables économiquement, sans sacrifier l’isolation ni la réactivité.
À mesure que les workflows autonomes, la génération de tokens et les interactions continues entre agents vont augmenter, exécuter chaque composant sur des ressources accélérées deviendra difficile à justifier. L’approche défendue ici consiste à utiliser la bonne machine pour la bonne tâche : accélérateurs pour les calculs intensifs, CPU Arm Axion pour l’orchestration massive et sandboxes sécurisées pour le code non fiable.
Les lecteurs qui souhaitent approfondir les aspects techniques peuvent consulter la publication originale de The New Stack ainsi que la documentation de Google Cloud consacrée à Axion et à Google Kubernetes Engine.