Faire tourner un LLM sur un VPS sans GPU avec Ollama : le guide réaliste

Faire tourner un modèle de langage sur son propre serveur a un intérêt évident : les données envoyées au modèle ne quittent jamais la machine, et le coût ne dépend plus du nombre de requêtes. Mais la plupart des guides partent du principe que vous disposez d'une carte graphique. Sur un VPS classique, sans GPU, que peut-on réellement attendre ?

La réponse courte : beaucoup plus qu'on ne le croit pour certains usages, beaucoup moins qu'on ne l'espère pour d'autres. Ce guide donne des ordres de grandeur concrets pour décider avant de commander, puis montre comment installer Ollama et l'utiliser depuis n8n.

1. Pourquoi un LLM peut tourner sans GPU

Deux techniques rendent l'exécution sur processeur possible. La première est la quantification : les paramètres du modèle, stockés à l'origine sur 16 bits, sont compressés sur environ 4 bits. Le modèle occupe alors près de quatre fois moins de mémoire, pour une perte de qualité modérée sur la plupart des tâches. La seconde est le moteur llama.cpp, sur lequel repose Ollama, optimisé pour exploiter les instructions vectorielles des processeurs modernes.

Sur CPU, le facteur limitant n'est pas tant la puissance de calcul que la vitesse à laquelle la mémoire transfère les données au processeur. Pour générer chaque mot, le moteur doit parcourir l'ensemble des paramètres du modèle. Plus le modèle est gros, plus ce trajet est long, et au-delà d'un certain nombre de cœurs, en ajouter ne change presque plus rien.

2. Combien de RAM prévoir

Le modèle doit tenir entièrement en mémoire vive, avec une marge pour le système, le contexte de conversation et les autres services du serveur. Avec la quantification 4 bits la plus courante, les besoins sont à peu près les suivants :

Si n8n et PostgreSQL tournent sur le même serveur, ajoutez 2 à 4 Go à ces valeurs. Et gardez en tête qu'un contexte long, par exemple un document entier passé au modèle, consomme lui aussi de la mémoire en plus des paramètres.

3. Quelle vitesse attendre

La vitesse se mesure en tokens par seconde, un token représentant en moyenne trois quarts de mot. Les mesures publiées sur processeur donnent les ordres de grandeur suivants :

• Modèle de 3 milliards de paramètres : de l'ordre de 15 à 30 tokens par seconde sur 6 à 12 vCPU. La réponse s'affiche à une vitesse de lecture confortable.
• Modèle de 7 à 8 milliards : de l'ordre de 5 à 15 tokens par seconde sur 8 à 12 vCPU. Une réponse de 300 tokens prend donc entre 20 secondes et une minute.
• Modèle de 14 milliards : quelques tokens par seconde seulement. Utilisable pour un traitement de nuit, pas pour une interaction.

Un second délai surprend souvent : avant de produire le premier mot, le modèle doit lire l'intégralité du texte fourni. Sur GPU, cette phase est quasi instantanée ; sur CPU, un document de plusieurs pages peut demander plusieurs dizaines de secondes avant le début de la réponse. Pour des textes longs, découpez-les en morceaux ou résumez-les par étapes.

Enfin, un serveur sur CPU traite efficacement une requête à la fois. Dix utilisateurs simultanés ne verront pas dix réponses rapides, mais une file d'attente.

4. Ce qui marche, ce qui ne marche pas

Les usages adaptés

• Classer et trier : attribuer une catégorie à un e-mail, un ticket de support ou un avis client. La réponse tient en quelques tokens, donc arrive vite, même avec un modèle de 7 milliards de paramètres.
• Extraire des données : transformer un e-mail ou une facture en JSON structuré, avec les champs dont votre workflow a besoin.
• Résumer en arrière-plan : produire chaque nuit un résumé de documents, de conversations ou de rapports, quand personne n'attend la réponse.
• Générer des embeddings : les modèles d'embeddings, spécialisés dans la recherche sémantique, sont petits et rapides sur processeur. C'est la brique de base d'un moteur de recherche documentaire interne.
• Traiter des données sensibles : pseudonymiser, analyser ou reformuler des contenus qui ne doivent pas être envoyés à un fournisseur externe.

Les usages à éviter

• Un chat en temps réel pour plusieurs utilisateurs : la file d'attente rend l'expérience rapidement pénible.
• Des raisonnements complexes ou de la génération de code avancée : les petits modèles y sont nettement moins bons que les grands modèles accessibles par API.
• L'analyse de longs documents à la volée : la phase de lecture initiale devient trop longue.

5. Installer Ollama sur le VPS

Avec Docker, l'installation tient en une commande. Notez l'adresse 127.0.0.1 devant le port : Ollama n'a pas d'authentification, et il ne doit jamais être exposé directement sur Internet.

docker run -d --name ollama \
  --restart unless-stopped \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  ollama/ollama

Téléchargez ensuite un modèle, puis vérifiez qu'il répond :

docker exec -it ollama ollama pull llama3.2:3b
curl http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.2:3b",
  "prompt": "Classe ce message en urgent ou non urgent : le serveur ne répond plus.",
  "stream": false
}'

Par défaut, Ollama décharge le modèle de la mémoire après quelques minutes d'inactivité, et le rechargement ajoute plusieurs secondes à la requête suivante. Si le serveur est dédié à cet usage, gardez le modèle chargé en ajoutant -e OLLAMA_KEEP_ALIVE=24h à la commande de lancement.

6. Brancher Ollama sur n8n

Si vous avez installé n8n avec Docker Compose en suivant notre guide d'installation de n8n, le plus simple est d'ajouter Ollama comme service dans le même fichier. Les deux conteneurs partagent alors un réseau privé, sans aucun port ouvert :

  ollama:
    image: ollama/ollama
    restart: unless-stopped
    environment:
      OLLAMA_KEEP_ALIVE: 24h
    volumes:
      - ollama_data:/root/.ollama

Ajoutez ollama_data: dans la section volumes en bas du fichier, relancez avec docker compose up -d, puis téléchargez le modèle avec docker compose exec ollama ollama pull llama3.2:3b.

Dans n8n, créez un identifiant de type Ollama avec l'adresse http://ollama:11434. Vous pouvez ensuite utiliser le nœud Ollama Chat Model comme modèle d'un nœud AI Agent ou d'une chaîne LLM, exactement comme vous le feriez avec un modèle OpenAI ou Anthropic.

Un schéma efficace consiste à combiner les deux : le modèle local trie, extrait et traite tout ce qui est sensible ou répétitif, et seules les demandes complexes partent vers un modèle accessible par API.

7. API ou modèle local : comment trancher

Soyons clairs : pour la qualité brute des réponses, les grands modèles accessibles par API restent loin devant ce qu'un processeur peut faire tourner. Et pour des volumes modérés, leur coût par requête est souvent faible. Le modèle local se justifie pour trois raisons précises :

• la confidentialité, quand les données ne doivent pas sortir de votre infrastructure ;
• le volume, quand des milliers de petites tâches répétitives rendraient la facture d'API significative ;
• l'indépendance, quand vous ne voulez pas dépendre de la disponibilité ou des changements de tarifs d'un fournisseur.

Si aucune de ces raisons ne s'applique, commencez par un modèle via API : n'importe quel VPS fera tourner les workflows qui l'appellent. Si l'une d'elles s'applique, un serveur de 16 Go de RAM avec un modèle de 7 à 8 milliards de paramètres est le point de départ le plus équilibré, et 32 Go laissent de la place pour n8n, sa base de données et un modèle d'embeddings.

À lire ensuite

Quand passer du VPS au serveur dédié ?

CPU steal, saturation RAM, virtualisation… Les signaux concrets qui indiquent qu'un VPS ne suffit plus, et comment migrer vers un dédié sans coupure.

Combien de vCPU et de RAM pour un VPS ?

Site web, bot Discord, serveur de jeux, base de données… Combien de vCPU, de RAM et de NVMe prévoir pour votre VPS sans sur-payer. Guide pratique 2026.

Intel Xeon Gold : ce que ça change pour un VPS

Xeon Gold, mémoire ECC, AVX-512 : ce que ces caractéristiques apportent réellement à un VPS par rapport à un processeur grand public, et pour quels usages.

Questions fréquentes