VPS haute mémoire pour agents IA : quand votre flotte a vraiment besoin de la RAM

L'erreur que je vois le plus souvent avec l'hébergement d'agents, c'est de dimensionner pour la mauvaise chose. Quelqu'un fait tourner un agent, il utilise 400 Mo, et il conclut que les agents sont peu coûteux à héberger. Puis il passe à une vraie équipe et la machine se met à swapper à 3 h du matin.

Un agent est peu coûteux. Ce n'est pas le cas intéressant.

Où va réellement la mémoire

Un agent qui ne fait que lancer des appels d'API vers un modèle est léger — il attend surtout sur le réseau. Vous pourriez en faire tourner une douzaine sur une petite offre sans jamais le remarquer.

La RAM disparaît quand les agents commencent à conserver un état. Un historique de conversation qui grandit à chaque tour. Un ensemble de travail que plusieurs agents lisent et écrivent. Un stockage vectoriel pour la mémoire à long terme dans le même processus. Dès l'instant où votre architecture cesse d'être « appeler l'API, oublier » et devient « se souvenir, coordonner, transmettre », la mémoire devient la contrainte, pas le CPU.

Les boucles de type CrewAI, LangGraph, AutoGPT — elles tendent toutes vers cela à mesure qu'elles deviennent sérieuses. Ce n'est pas le framework qui consomme la RAM ; c'est l'état.

Dimensionnement approximatif, honnêtement

Je ne prétendrai pas qu'il y a une formule, car il n'y en a pas — cela dépend entièrement de ce que chaque agent garde. Mais un ressenti pratique après avoir fait tourner ces systèmes :

• Agents légers, liés à l'API — vous n'avez pas du tout besoin de Pro ici ; une offre NAT ou à IP dédiée (3–20 $) le gère. Pro gagne sa place dès que l'état partagé vous pousse au-delà de ~32 Go.
• 32 Go — le point idéal pour un vrai système multi-agents : 5 à 10 agents avec mémoire partagée plus une base de données vectorielle réellement utile. La plupart des gens atterrissent ici.
• 64 Go — flottes plus grandes, historiques plus longs, un index mémoire de plusieurs millions de vecteurs, ou plusieurs services co-localisés. C'est ici qu'une machine remplace les trois plus petites que vous jongleriez autrement.
• 80 Go — travail lourd, limité par la mémoire : grands jeux de données en mémoire, nombreux agents concurrents, ou agents plus inférence de modèle local sur le même hôte.

Commencez en dessous de là où vous pensez devoir être. Surveillez htop une journée. Redimensionnez à la hausse quand vous voyez du swap, pas avant — viser trop haut ne fait que gaspiller de l'argent.

La partie difficile à acheter

Voici ce qui rend cela délicat : louer 64 Go de RAM est facile. La louer en crypto et sans vérification d'identité ne l'est pas. La plupart des hébergeurs qui vendent de la mémoire sérieuse à bas prix le font derrière une carte et un formulaire KYC.

Si votre agent provisionne son propre serveur, ou si la charge touche des données que vous préférez ne pas lier à un nom, cette combinaison — haute mémoire, crypto, sans KYC, et commandable par l'agent lui-même via MCP — est le produit réel. Ce n'est pas moins cher au gigaoctet, et j'ai écrit séparément sur pourquoi cette comparaison induit en erreur. C'est disponible à des conditions que presque personne n'offre.

Alors que faire

Si vos agents sont légers et liés à l'API, ne compliquez pas — une petite offre NAT ou à IP dédiée suffit amplement, sautez toute la question de la haute mémoire. Si vous faites tourner une vraie flotte qui conserve un état, dimensionnez selon ce qui est réellement en mémoire, commencez à 32 Go, et montez quand le graphe vous le dit.

Quand vous y êtes, la gamme Pro couvre de 32 à 80 Go avec une IP dédiée et des sauvegardes nocturnes. Choisissez le palier qui correspond à votre ensemble de travail, pas à vos ambitions.