De combien de RAM un VPS basique a-t-il besoin ?

Pour un seul bot, une petite API ou un site statique, 1 Go suffit — souvent avec de la marge. 2 Go, c'est la valeur confortable dès qu'on ajoute une base de données ou Docker. En dessous de 1 Go, les gestionnaires de paquets et runtimes modernes commencent à souffrir.

Combien de RAM faut-il pour faire tourner un LLM sur un VPS ?

À peu près la taille du modèle à sa quantification, plus un ou deux gigaoctets pour le contexte. Un modèle 7–8B en 4 bits demande environ 5 à 6 Go, un 14B environ 10 Go, un 32B autour de 20 Go et un 70B autour de 40 à 45 Go. C'est pour cela que les serveurs de 64 Go existent : un modèle 70B y tient, avec de la place pour le reste de votre stack.

Le swap peut-il remplacer la RAM ?

Non. Le swap est un filet de sécurité pour les pics courts : il évite qu'un build ou une sauvegarde soit tué. Si une charge vit dans le swap toute la journée, tout devient lent ; c'est le signal qu'il faut monter d'une offre.

Comment voir la RAM réellement utilisée par mon serveur ?

Lancez 'free -h' et regardez la colonne 'available', pas 'free' — Linux utilise la mémoire libre comme cache disque et la rend à la demande. 'ps aux --sort=-rss | head' montre les plus gros processus, et 'docker stats --no-stream' la consommation par conteneur.

Quand un VPS de 64 Go a-t-il du sens ?

Quand une seule grosse chose doit tenir en mémoire : un modèle local de 32 à 70B, un gros index vectoriel pour du RAG ou une flotte d'agents avec leurs propres runtimes. Pour les sites, les bots et la plupart des API, c'est de l'argent jeté.

De combien de RAM un VPS a-t-il besoin ? Chiffres réels

La plupart des gens choisissent leur RAM au hasard. Soit ils en achètent beaucoup trop « au cas où », soit ils font connaissance avec l'OOM killer à 3 h du matin. Pourtant la mémoire est l'une des choses les plus simples à dimensionner, car les charges sont prévisibles dès qu'on connaît les ordres de grandeur. Les voici — du serveur de 1 Go pour un bot jusqu'aux serveurs de 64 Go que l'on cherche quand on veut faire tourner un gros modèle en local.

Ordres de grandeur par usage

Ce sont des valeurs réelles en régime établi pour une installation typique, pas des minimums de documentation.

Usage	RAM réellement utilisée	Offre adaptée
Bot Telegram/Discord (Python, Node.js)	100–300 Mo	Nano 1 Go
Site statique + Caddy/Nginx	50–150 Mo	Nano 1 Go
WordPress + MariaDB, trafic normal	0,8–1,5 Go	Micro-IP 2 Go
PostgreSQL pour une petite application	0,5–2 Go (vous décidez via `shared_buffers`)	Micro / Small
n8n avec quelques workflows	0,5–1,5 Go	Micro 2 Go
Hôte Docker avec 5 à 10 petits services	2–4 Go	Small 4 Go
Coolify + builds + une base de données	3–4 Go	Small-IP 4 Go
LLM 7–8B, 4 bits, inférence CPU	5–6 Go	Medium 6 Go
LLM 14B, 4 bits	~10 Go	Pro-32
LLM 32B, 4 bits	~20 Go	Pro-32
LLM 70B, 4 bits	~40–45 Go	Pro-48 / Pro-64

Deux choses sautent aux yeux. D'abord, l'écart entre les usages « normaux » et les LLM est énorme — un bot et un modèle 70B diffèrent d'un facteur deux cents. Ensuite, la plupart des services se contentent de 1 à 4 Go ; on surdimensionne parce qu'on prévoit pour un avenir qui arrive rarement.

La formule pour les LLM

Pour les modèles de langage, il existe une estimation simple : paramètres × bits par poids ÷ 8, plus la surcharge. Un modèle 8B à environ 4,5 bits (une quantification Q4 typique) représente 8 × 4,5 ÷ 8 ≈ 4,5 Go de poids. Ajoutez 1 à 2 Go pour la fenêtre de contexte (le cache KV grandit avec la longueur du contexte) et le runtime, et vous arrivez à 5 à 6 Go.

La partie honnête : sur un serveur uniquement CPU, la mémoire n'est que la moitié de l'histoire. Comptez un nombre de tokens par seconde à un chiffre pour un modèle 7–8B sur quelques vCPU, et environ un token par seconde pour un 70B. C'est très bien pour des traitements par lots, des agents en arrière-plan et des expériences privées ; ce n'est pas un chat pour de nombreux utilisateurs simultanés. Si vous appelez surtout des API de modèles hébergées, votre agent a besoin de bien moins — voir dimensionner un VPS pour des agents IA.

Mesurer plutôt que deviner

Si vous avez déjà un serveur, les chiffres sont là :

free -h                              # look at "available", not "free"
ps aux --sort=-rss | head -n 8       # the biggest processes, by resident memory
docker stats --no-stream             # per-container usage

Linux utilise la RAM inoccupée comme cache disque, donc « free » est toujours faible et c'est sain. Available est le chiffre qui compte : la mémoire que le noyau peut donner aux programmes tout de suite. Si available reste au-dessus d'environ 25 % à votre heure la plus chargée, vous êtes bien dimensionné. S'il tombe régulièrement à zéro et que le swap grossit, montez d'un cran.

Vérifiez aussi les OOM passés :

journalctl -k | grep -i "out of memory"

Le swap : une ceinture de sécurité, pas un moteur

Un fichier swap de 1 à 2 Go sur un petit serveur est une assurance bon marché : une mise à jour de paquets ou un build Docker qui a brièvement besoin de plus de mémoire survit au lieu d'être tué. Mais si un service vit dans le swap, chaque requête attend le disque. Le swap, c'est pour les pics. Un swap permanent veut dire qu'il vous faut l'offre suivante.

Alors, combien acheter ?

1 Go — un bot, une petite API, un site statique.
2 Go — la valeur raisonnable pour tout ce qui a une base de données ou Docker.
4 à 6 Go — plusieurs services sur une machine, des builds sur le serveur, un petit modèle local.
32 à 64 Go — uniquement quand une grosse chose doit vivre en mémoire : un modèle local au-delà de 14B, un gros index RAG, une flotte d'agents. C'est à cela que servent les offres à grande mémoire.

Partez une taille en dessous de ce que votre instinct vous dicte, surveillez free -h pendant une semaine et montez si les chiffres le disent. Chez EQVPS, un changement d'offre conserve vos données et ne facture que la différence au prorata (comment fonctionne le changement d'offre).