Modèles et plateformes d’IA
E2B teste NVIDIA Vera pour des flottes de bacs à sable d’agents à haute densité
Ajouter Unite.AI à vos sources préférées sur Google
Le 9 novembre 2026, E2B a publié les résultats de tests en préproduction montrant que quatre exécutions optimisées sur un serveur NVIDIA Vera à deux sockets ont maintenu entre 1 400 et 1 550 bacs à sable en charge, tandis que des microtests distincts ont mesuré un débit processeur et mémoire supérieur à celui d’un système de référence AMD EPYC 9B45.
Cette évaluation ne constitue pas un déploiement en production. E2B fournit des microVM isolées par l’intermédiaire d’un SDK, permettant aux agents d’exécuter des commandes, de travailler avec des fichiers et de retrouver un état d’exécution préservé. Chaque bac à sable reprend à partir d’un instantané, en chargeant la mémoire au besoin. Une grande partie du travail effectué au cours de ces sessions repose sur le processeur, même lorsque le modèle s’exécute ailleurs ; E2B a donc testé à la fois des opérations individuelles et un grand nombre d’environnements simultanés.
Microtests du processeur et de la mémoire
Les tests de Vera ont eu lieu du 9 au 13 octobre 2026 sur un seul serveur à deux sockets en préproduction, doté de 176 cœurs physiques et de 1 479 Gio de RAM. Les mesures de référence AMD ont été effectuées en août 2026. Lors d’un test de calcul sur machine nue, à un seul thread, E2B indique 7 759 événements par seconde pour Vera et 5 131 pour l’AMD EPYC 9B45, soit un débit 1,51 fois supérieur à celui du système de référence, d’après la médiane d’au moins trois exécutions. Le test de calcul utilisait le noyau Vera configuré avec des pages de 64 Ko.
Le test mémoire a rempli une région de 2 Gio à l’aide de noyaux 4K et de pages géantes de 2 Mio, identiques à celles utilisées pour les bacs à sable d’E2B. E2B indique un débit de 62,8 Go/s pour Vera et de 17,4 Go/s pour AMD, soit un débit 3,61 fois supérieur. Cette mesure porte sur le remplissage de la mémoire, et non sur le démarrage complet d’un bac à sable ; il s’agit d’une opération importante pour un environnement d’exécution qui restaure régulièrement des environnements à partir d’instantanés.
La comparaison comporte des limites précises. Les graphiques portent sur des systèmes nommément désignés dans le cadre de microtests spécifiques et ne démontrent ni des gains équivalents en vitesse de bout en bout pour les agents, ni un avantage de capacité de flotte par rapport à AMD. E2B indique également que les gains varieront selon les outils et les applications.
Capacité de la pile complète et réglage de l’hôte
Pour les tests de la pile complète, E2B a utilisé E2B Embed, son conditionnement pour une seule machine de l’environnement d’exécution E2B à code source ouvert et de son tableau de bord, la pile s’exécutant directement sur l’hôte. Embed assure l’isolation par microVM Firecracker et prend en charge les SDK Python et JavaScript. L’évaluation a porté sur la création, l’exécution de commandes, la restauration d’instantanés, la capacité ainsi que des cycles répétés de création et de suppression.
E2B indique des démarrages séquentiels de bacs à sable à chaud en 50 ms et des allers-retours de commande en 3,8 ms à faible charge ; chacune de ces mesures provient de tests distincts sur Vera en métal nu, et non de mesures sous charge de flotte. Une campagne distincte de création et de suppression a mené à bien 22 145 cycles, sans aucune erreur.
Dans la charge de travail mixte servant à mesurer la capacité, chaque bac à sable effectuait à plusieurs reprises une rafale de calcul sur le processeur, une écriture de 10 Mio sur le disque et une pause, tandis qu’un bac sur 10 s’exécutait en continu. Dans la partie supérieure de la plage de capacité, E2B indique une latence des allers-retours de commande au 95e centile de 255 ms. Lors d’un test distinct où tous les bacs à sable s’exécutaient en continu, le système en a maintenu 550.
Ces tests de capacité réservaient 512 Mio par bac à sable. Les objectifs exigeaient que la latence au 95e centile reste dans une limite de 5× la référence de rafale après préchauffage de chaque exécution et imposaient une limite d’erreur de 1 % par étape. Le résultat décrit donc la capacité dans le respect d’objectifs définis de réactivité et de fiabilité, et non une limite absolue de charge.
La configuration de l’hôte constituait une contrainte majeure. Les paramètres par défaut permettaient de prendre en charge 320 bacs à sable ; le réglage des paramètres de voisinage réseau a porté ce nombre à 1 000, tout en maintenant une limite de 1 024 périphériques. Le réglage complet était nécessaire pour obtenir le principal résultat de capacité. E2B présente cette progression comme une comparaison de configurations sur le même serveur, et non comme un gain de vitesse de Vera par rapport à x86.
Limites de l’évaluation et tests prévus
Le statut de préproduction laisse plusieurs questions en suspens. E2B a constaté que les systèmes x86 de référence effectuaient encore certaines opérations de restauration plus rapidement, tandis que la virtualisation imbriquée nécessite des travaux supplémentaires. Aucune mesure des coûts ni de la consommation électrique n’a été effectuée ; les coûts d’exploitation ne font donc pas partie de l’évaluation.
Les prochaines étapes annoncées par E2B sont la mise en place d’un cluster Vera multinoeud, la reprise à froid à partir d’un stockage objet et une comparaison avec x86 utilisant le même conditionnement E2B et les mêmes réglages de l’hôte. La pertinence plus générale d’un déploiement dépend désormais de ces travaux complémentaires : les résultats de la pile complète se maintiennent-ils face à un système x86 conditionné et réglé de manière comparable, et les résultats de capacité obtenus sur un seul serveur se vérifient-ils à l’échelle d’un cluster ?
