Héberger un LLM en local sur un VPS avec Ollama : le guide pratique

Faire tourner un modèle de langage chez soi, sur sa propre machine, sans envoyer une seule ligne de texte chez OpenAI, Anthropic ou Google : l'idée séduit beaucoup de développeurs et d'indépendants. Et la bonne nouvelle, c'est qu'avec un outil comme Ollama, le côté technique tient désormais en trois commandes. La moins bonne nouvelle, c'est que sur un VPS classique sans GPU, les performances n'ont rien à voir avec ce que vous connaissez d'une API cloud. Ce guide pose les choses honnêtement, à partir d'un serveur type que beaucoup d'entre nous louent : 4 vCPU, 12 Go de RAM, pas de carte graphique.

Pourquoi héberger un LLM en local ?

Deux raisons principales reviennent toujours.

Le coût. Une API cloud se facture au token. Pour un usage ponctuel, c'est dérisoire. Mais dès qu'un script tourne en boucle (génération de contenu, classification de masse, enrichissement de données 24h/24), la facture grimpe et devient imprévisible. Un VPS à prix fixe transforme ce coût variable en abonnement mensuel connu d'avance.

Les données privées. Tout ce qui transite par une API part sur des serveurs tiers. Pour des données clients, des documents internes, du code propriétaire ou tout ce qui touche au RGPD, garder le traitement sur sa propre infrastructure simplifie énormément la conformité et supprime la dépendance à un fournisseur.

À cela s'ajoutent l'absence de quotas et de limites de débit, et le plaisir, non négligeable, de maîtriser sa stack de bout en bout.

Prérequis matériels : soyons honnêtes

La RAM est le premier facteur limitant. Un modèle doit tenir entièrement en mémoire pour fonctionner correctement. En version quantifiée (format q4/q8, qui réduit la précision des poids pour gagner de la place), comptez en ordre de grandeur :

Modèle 3B : autour de 2 à 3 Go de RAM
Modèle 7B/8B : autour de 5 à 7 Go de RAM
Modèle 14B : autour de 9 à 11 Go de RAM, à la limite de nos 12 Go

Ajoutez la RAM consommée par le système et vos autres services : sur 12 Go, un 8B passe confortablement, un 14B se joue au gramme près.

Le point qui fâche : le CPU sans GPU est lent

C'est le message le plus important de ce guide. Un GPU traite les multiplications matricielles d'un LLM en parallèle massif ; un CPU les traite quasiment en série. Résultat sur nos 4 vCPU : on parle de quelques tokens par seconde seulement. Concrètement, une réponse de quelques centaines de mots prend de plusieurs dizaines de secondes à plusieurs minutes, selon la taille du modèle et la longueur du prompt.

Pour un 7B/8B, attendez-vous à des générations qui se comptent en minutes dès que le contexte est un peu chargé. Ce n'est pas un bug, c'est la réalité physique de l'inférence sur CPU. Tout usage interactif « comme ChatGPT » sera frustrant ; les usages asynchrones (un cron qui génère pendant la nuit) s'en accommodent très bien.

Le swap, votre filet de sécurité

Même si le modèle tient en RAM, un pic d'usage peut faire passer le serveur en mémoire saturée et déclencher l'OOM killer (le système tue le processus le plus gourmand, donc Ollama). Configurez un fichier de swap pour absorber ces pics. Il ne rendra rien rapide — le disque est mille fois plus lent que la RAM — mais il évitera les crashs brutaux.

# Créer un swap de 4 Go
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# Le rendre permanent
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Installer Ollama

L'installation officielle tient en une ligne et met en place le binaire ainsi qu'un service systemd :

curl -fsSL https://ollama.com/install.sh | sh

Vérifiez que le service tourne :

systemctl status ollama

Téléchargez ensuite un modèle. Pour un 8B récent et polyvalent :

ollama pull qwen3:8b

Pour tester immédiatement en ligne de commande :

ollama run qwen3:8b "Résume en trois points ce qu'est un VPS."

La première réponse met un peu plus de temps : le modèle se charge en mémoire. Les suivantes repartent du modèle déjà chargé.

L'API locale et l'endpoint compatible OpenAI

C'est là qu'Ollama devient vraiment utile : il expose une API HTTP sur localhost:11434. Exemple d'appel direct :

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "Bonjour",
  "stream": false
}'

Mieux encore, Ollama propose un endpoint compatible OpenAI, ce qui permet de réutiliser n'importe quel SDK existant sans le réécrire :

curl http://localhost:11434/v1/chat/completions -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "Bonjour"}]
}'

Pointez simplement la base_url de votre client OpenAI vers http://localhost:11434/v1 et une clé d'API factice. Votre code croit parler à OpenAI ; il parle en réalité à votre VPS.

Exposer (ou non) Ollama au réseau

Par défaut, Ollama n'écoute que sur localhost. C'est le bon réglage : laissez votre application appeler l'API en local et ne l'exposez pas directement sur Internet sans authentification. Si une autre machine doit y accéder, passez par un reverse proxy (Nginx) avec authentification et HTTPS plutôt que d'ouvrir le port 11434 au monde entier.

Pour modifier le comportement, on édite le service systemd :

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Puis sudo systemctl daemon-reload && sudo systemctl restart ollama.

Désactiver la « réflexion » pour gagner en vitesse

Les modèles récents comme qwen3 intègrent un mode raisonnement : avant de répondre, le modèle génère une longue chaîne de réflexion interne. Sur GPU c'est un atout pour les tâches complexes ; sur CPU c'est un gouffre à secondes, car chaque token de réflexion se paie au prix fort.

Pour la plupart des tâches (rédaction, classification, reformulation), cette réflexion est superflue. On la coupe en ajoutant /no_think dans le prompt :

ollama run qwen3:8b "/no_think Rédige un titre accrocheur pour un article sur les VPS."

Le gain de temps est immédiat et souvent spectaculaire. Réservez le mode réflexion aux problèmes de logique ou de mathématiques où il apporte réellement quelque chose.

Tableau récapitulatif des modèles

Modèle	RAM approx.	Vitesse sur CPU (4 vCPU)	Usage conseillé
3B (ex. `llama3.2:3b`)	2 à 3 Go	La moins lente, quelques tokens/s en mieux	Classification, extraction simple, tâches courtes
7B / 8B (ex. `qwen3:8b`, `gemma2:9b`)	5 à 7 Go	Lente, réponses en dizaines de secondes à quelques minutes	Rédaction, résumé, le bon compromis qualité/poids
14B (ex. `qwen3:14b`)	9 à 11 Go	Très lente, plusieurs minutes par réponse	Qualité supérieure si la latence n'est pas un problème

Les vitesses sont des ordres de grandeur : la longueur du prompt, le contexte et la quantification les font varier fortement.

Les limites du local sur CPU

Soyons clairs : un VPS CPU n'est pas fait pour servir un chatbot en temps réel. La latence rend l'expérience pénible pour un usage interactif. Et au-delà de la vitesse, il y a la qualité : un 8B quantifié qui tourne sur votre VPS reste, en valeur absolue, bien en dessous des grands modèles propriétaires servis par API. Il hallucine plus, suit moins bien les instructions complexes et gère moins bien les longs contextes.

Le point qui surprend beaucoup d'auto-hébergeurs : une API comme Mistral (acteur européen, donc intéressant côté souveraineté des données) est souvent à la fois plus rapide ET de meilleure qualité que votre modèle local — pour un coût qui, en usage modéré, reste très bas. Le « gratuit » du local se paie en temps de calcul, en RAM et en qualité moindre.

Local vs cloud : comment choisir

Posez-vous trois questions.

Mon usage est-il interactif ou asynchrone ? Si un humain attend la réponse, privilégiez le cloud. Si c'est un batch nocturne, le local convient.
Mon volume justifie-t-il un coût fixe ? Un usage intense et continu rentabilise un VPS. Un usage ponctuel coûtera moins cher en API.
Mes données peuvent-elles sortir ? Si la confidentialité est non négociable et que l'API ne suffit pas, le local devient un vrai argument — quitte à investir plus tard dans un serveur GPU.

Notre lecture

Pour la majorité des indépendants, le bon schéma n'est pas « tout local » ou « tout cloud », mais hybride. Le VPS Ollama est excellent pour les tâches de fond, non urgentes, où la confidentialité prime et où quelques minutes de latence n'ont aucune importance : enrichissement de bases, génération de brouillons la nuit, classification de flux. Pour tout ce qui est interactif ou exigeant en qualité, une API cloud reste imbattable. Le mode compatible OpenAI d'Ollama facilite justement le va-et-vient entre les deux : le même code peut basculer d'un fournisseur à l'autre en changeant une base_url.

L'erreur classique est de croire que l'auto-hébergement va « remplacer ChatGPT » à coût nul. Il remplace un certain type d'usage, pas tous.

À surveiller

La RAM en pic, surtout si vous faites tourner plusieurs services à côté d'Ollama. Surveillez avec htop et gardez le swap configuré.
Le déchargement du modèle : Ollama libère la mémoire après quelques minutes d'inactivité, ce qui rallonge la première requête suivante. Réglable via OLLAMA_KEEP_ALIVE si vos requêtes sont espacées.
L'arrivée de modèles plus efficaces : les petits modèles (3B/4B) progressent vite et rendent le CPU de plus en plus viable pour des tâches ciblées.
Le coût réel d'un GPU : si le local devient central dans votre activité, un VPS avec GPU dédié change radicalement la donne — au prix d'un budget mensuel nettement supérieur.

En résumé : Ollama rend l'hébergement d'un LLM trivial à installer, mais la physique du CPU impose ses limites. Utilisé à bon escient, pour les bons usages, c'est un outil redoutable. Attendu là où il n'est pas fait pour briller, il déçoit. À vous de placer le curseur.