« Faire tourner une IA » recouvre deux besoins qui n'appellent pas la même taille de serveur. Une application qui appelle un modèle par API se dimensionne comme n'importe quelle application web ; un modèle exécuté sur le serveur lui-même se dimensionne d'abord par sa mémoire. Ce guide sépare les deux cas, donne l'empreinte des modèles courants et la façon de la calculer.
La plupart des applications qui « utilisent de l'IA » (assistants, agents, résumés, extraction de données, recherche dans des documents) appellent un modèle hébergé par son éditeur, par une API. Le calcul se fait chez lui ; votre serveur prépare la requête, attend la réponse et la traite. Il se dimensionne alors comme n'importe quelle application web : par son langage, sa base de données et le nombre d'utilisateurs simultanés.
L'autre cas, c'est le modèle exécuté sur le serveur lui-même, avec Ollama, llama.cpp ou une bibliothèque Python. Les raisons sont connues : des données qui restent sur votre infrastructure, un coût fixe quel que soit le nombre de requêtes, un traitement de fond sur de gros volumes, un modèle spécialisé. Là, le modèle entier doit tenir en mémoire, et c'est lui qui fixe la taille.
| Ce que fait le serveur | La ressource qui décide | Point de départ |
|---|---|---|
| Appelle un modèle par API (assistant, agent, robot conversationnel) | La mémoire de l'application | 2 vCPU, 4 Go |
| Calcule aussi les embeddings et interroge une base vectorielle (pgvector) | La mémoire des vecteurs et de leur index | 2 à 4 vCPU, 6 à 8 Go |
| Exécute un petit modèle de 1 à 4 milliards de paramètres, en traitement de fond | La mémoire, puis le processeur | 4 vCPU, 8 Go |
| Exécute un modèle de 7 à 8 milliards de paramètres pour quelques utilisateurs | La mémoire et sa bande passante | 6 à 8 vCPU, 16 Go |
| Exécute un modèle de 12 à 14 milliards de paramètres, avec un contexte long | La mémoire | 8 vCPU, 24 Go |
Une requête à un modèle par API dure d'une à plusieurs dizaines de secondes, surtout quand la réponse est diffusée au fur et à mesure (streaming). Pendant ce temps, votre serveur ne calcule presque rien : il attend. Ce qui compte, c'est sa capacité à garder de nombreuses requêtes en attente sans bloquer les autres :
proxy_read_timeout).La mémoire à prévoir est celle de l'application et de sa base : 4 Go couvrent une application Python ou Node.js avec PostgreSQL au lancement. Une configuration courante, une interface Next.js, une API FastAPI et une base PostgreSQL qui appellent un modèle par API, tient dans 6 à 8 Go, compilation de l'interface comprise.
Une application qui cherche dans vos documents (RAG, retrieval-augmented generation) transforme chaque passage en vecteur, puis retrouve les plus proches d'une question. Deux postes à dimensionner :
Le type halfvec de pgvector stocke chaque dimension sur 2 octets au lieu de 4 : la moitié de la mémoire, pour une qualité de recherche qui reste très proche.
Un modèle de langage est un fichier de poids, chargé en entier en mémoire pour répondre. Sa taille dépend du nombre de paramètres et de la quantification, la précision avec laquelle chaque poids est stocké. Le format GGUF, celui de llama.cpp et d'Ollama, propose des quantifications de 2 à 16 bits ; la variante Q4_K_M, autour de 4 bits, est le compromis courant entre taille et qualité.
| Taille du modèle | Exemples | 4 bits (Q4_K_M) | 8 bits (Q8_0) | 16 bits |
|---|---|---|---|---|
| 1 à 3 milliards de paramètres | Llama 3.2 3B, Qwen2.5 3B | 1 à 2 Go | 1,3 à 3,5 Go | 2,5 à 6,5 Go |
| 7 à 8 milliards | Mistral 7B, Llama 3.1 8B, Qwen2.5 7B | 4,4 à 5 Go | 7,7 à 8,5 Go | 14,5 à 16 Go |
| 12 à 14 milliards | Mistral Nemo 12B, Qwen2.5 14B | 7,5 à 9 Go | 13 à 16 Go | 25 à 30 Go |
| 32 milliards | Qwen2.5 32B | environ 20 Go | environ 35 Go | environ 65 Go |
| 70 milliards | Llama 3.3 70B | environ 43 Go | environ 75 Go | environ 140 Go |
À ce poids s'ajoutent deux postes :
Exemple. Llama 3.1 8B en 4 bits, deux conversations simultanées de 8 000 jetons et une petite application : 5 Go de modèle, 2 Go de contexte, 2 Go pour l'application et le système, soit 9 Go, et environ 12 Go avec 25 % de marge.
Pour produire chaque jeton, le modèle relit l'ensemble de ses poids en mémoire. Sur processeur, la vitesse de génération est donc bornée par la bande passante mémoire plus que par le nombre de cœurs : un modèle de 5 Go, sur une machine qui lit 25 Go par seconde, plafonne autour de 5 jetons par seconde, avant même de compter le calcul.
Deux phases se distinguent :
En pratique, sur quelques vCPU, un modèle de 7 à 8 milliards de paramètres quantifié en 4 bits produit quelques jetons par seconde. C'est confortable pour un traitement de fond (classer des messages, extraire des champs d'un document, résumer la nuit ce qui est arrivé le jour) et pour un assistant interne. Les usages interactifs à grande échelle, et les modèles de plusieurs dizaines de milliards de paramètres, s'exécutent sur carte graphique (GPU).
La mesure tranche : llama-bench, fourni avec llama.cpp, donne la vitesse des deux phases sur votre serveur, pour votre modèle.
llama-bench -m modele-Q4_K_M.gguf -p 512 -n 128Un modèle occupe sur disque à peu près ce qu'il occupe en mémoire : 5 Go pour un modèle de 8 milliards de paramètres en 4 bits. Comptez de la place pour deux ou trois modèles ou versions, les index vectoriels, les documents sources et la base de données. Un SSD NVMe charge un modèle en quelques secondes au démarrage du service, ce qui compte à chaque redémarrage.
Ordre de grandeur : 50 Go pour une application qui appelle un modèle par API, 80 à 120 Go dès qu'un modèle et ses documents se trouvent sur le serveur.
Avec Ollama, la mise en route tient en deux commandes :
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8bOllama écoute par défaut sur 127.0.0.1:11434, c'est-à-dire depuis le serveur lui-même. Gardez ce réglage : son API ne demande aucune authentification, et une instance ouverte sur Internet sert n'importe qui, sur vos ressources. Votre application, sur le même serveur, lui parle en local ; si un autre serveur doit l'interroger, passez par un mandataire qui authentifie les requêtes ou par un réseau privé.
Réglez ensuite la taille du contexte (num_ctx) sur ce dont vos requêtes ont besoin : c'est elle qui fait grossir la mémoire occupée, conversation par conversation.
Le VPS Pro tourne sur processeurs Intel Xeon, mémoire ECC et SSD NVMe en miroir, avec l'accès root pour installer Ollama, llama.cpp, pgvector ou votre propre pile. L'Assistance intégrale est comprise : décrivez-nous votre projet, API ou modèle sur le serveur, nous vous conseillons la taille, puis nous diagnostiquons et vous indiquons quoi faire à chaque question, du système jusqu'au code de votre application.
Oui. llama.cpp et Ollama exécutent des modèles quantifiés sur processeur. Un modèle de 7 à 8 milliards de paramètres en 4 bits demande environ 5 Go de mémoire et produit quelques jetons (tokens) par seconde sur quelques vCPU, ce qui convient aux traitements de fond et aux assistants internes.
Environ 5 Go pour le modèle quantifié en 4 bits (Q4_K_M), plus 1 Go par conversation de 8 000 jetons (tokens), plus l'application et le système. Un serveur de 8 Go fait tourner le modèle seul ; 16 Go laissent de la place pour l'application, la base de données et plusieurs conversations.
L'API donne accès aux modèles les plus puissants, sans serveur particulier, avec un coût par requête. Le modèle sur le serveur garde les données chez vous et fixe le coût, avec un modèle plus compact. Beaucoup d'applications combinent les deux : embeddings et tri sur le serveur, rédaction par API.
Environ 50 Go pour une application qui appelle un modèle par API. Dès qu'un modèle se trouve sur le serveur, prévoyez 80 à 120 Go : un modèle de 8 milliards de paramètres en 4 bits pèse 5 Go, et l'on en garde souvent plusieurs versions, avec les documents et leurs index vectoriels.
Simafri
Parlons de votre site web
Dites-nous en deux mots votre projet : on revient vers vous rapidement.
Merci ! Votre demande a bien été envoyée. Nous vous répondrons rapidement.
Vous préférez l'email ? Écrivez-nous à support@simafri.com.