Héberger un LLM avec Ollama sur un VPS

Héberger un grand modèle de langage sur sa propre infrastructure permet de garder la maîtrise des prompts, des documents et des réponses générées. Avec une API hébergée par un fournisseur américain, ces données quittent votre environnement et sont traitées selon les conditions du service utilisé. Un déploiement en self-host réduit cette dépendance et facilite la mise en place de règles adaptées aux données sensibles.

Ollama simplifie l’installation et l’exécution locale de modèles comme Llama, Phi ou Mistral. Son API HTTP permet ensuite de connecter le modèle à une application, un outil d’automatisation ou une interface de chat.

Il faut toutefois poser une limite claire : un VPS classique sans GPU n’est pas une machine d’inférence haute performance. Il convient surtout au développement, aux tests, aux petits modèles quantifiés et aux usages modérés. Les modèles volumineux, les contextes longs et les réponses rapides nécessitent généralement un GPU adapté.

Dans une logique de souveraineté, un VPS situé en France permet de conserver les données sur une infrastructure française. TalCloud propose des VPS avec serveurs en France, stockage NVMe, protection Anti-DDoS Netrix incluse et support humain, à partir de 4,99 € par mois. Cette offre ne comprend pas de VPS GPU.

Prérequis pour héberger Ollama

Le serveur doit utiliser une distribution Linux récente, par exemple Ubuntu 22.04 ou 24.04, Debian 12 ou une distribution équivalente. Vous devez disposer d’un accès SSH (voir notre guide se connecter en SSH) et de droits sudo.

Le dimensionnement dépend principalement du modèle choisi :

• 4 Go de RAM : très petits modèles uniquement, avec une marge réduite pour le système
• 8 Go de RAM : point de départ plus réaliste pour un modèle quantifié de 1 à 3 milliards de paramètres
• 16 Go de RAM : configuration plus confortable pour un petit modèle ou certains modèles 7B en quantification Q4
• 32 Go de RAM et plus : davantage de marge pour le contexte, les modèles plus lourds et plusieurs processus, sans garantir de bonnes performances sur CPU

La mémoire nécessaire ne dépend pas seulement du fichier du modèle. Ollama doit également stocker le contexte, le cache et les données temporaires en RAM. Un modèle qui tient tout juste en mémoire risque de provoquer du swap, puis une forte dégradation des performances.

Prévoyez aussi suffisamment d’espace disque. Les modèles occupent souvent plusieurs gigaoctets chacun. Un volume NVMe de 30 à 50 Go constitue un minimum pratique pour le système, Ollama, un ou deux modèles et les journaux.

Enfin, vérifiez les capacités du processeur. Le nombre de cœurs et les instructions disponibles influencent directement la vitesse de génération.

CPU ou GPU : choisir un usage réaliste

Ollama fonctionne sur CPU, mais cela ne signifie pas qu’un VPS CPU peut exécuter rapidement n’importe quel LLM.

Sur un VPS sans GPU, privilégiez des modèles quantifiés comme :

• Llama 3.2 3B
• Phi dans une variante compacte
• Mistral 7B en Q4, avec suffisamment de RAM

La quantification réduit la taille du modèle et sa consommation mémoire en stockant ses poids avec une précision plus faible. Elle rend l’inférence CPU possible, au prix d’une légère perte de qualité et d’une vitesse qui reste limitée.

Cette configuration convient à un prototype, un assistant interne peu sollicité, une classification de texte ou une intégration n8n à faible volume. Elle convient moins à un chatbot public très fréquenté, à la génération interactive rapide ou à des modèles de plusieurs dizaines de milliards de paramètres.

Pour ces usages, il faut envisager une machine équipée d’un GPU disposant de suffisamment de VRAM. TalCloud n’annonçant pas encore d’offre VPS GPU, le scénario présenté ici reste volontairement centré sur les petits modèles et les charges CPU modérées.

Installer Ollama sur un VPS Linux

Connectez-vous au VPS en SSH, puis utilisez le script d’installation officiel :

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

Le script installe Ollama et configure normalement un service systemd. Vérifiez son état :

sudo systemctl status ollama

Si nécessaire, activez et démarrez le service :

sudo systemctl enable --now ollama

Contrôlez ensuite la version installée :

ollama --version

Le service doit rester exécuté sous un compte dédié avec des permissions limitées. Évitez de lancer Ollama en tant que root pour un déploiement permanent.

Vous pouvez suivre les journaux pendant un diagnostic :

sudo journalctl -u ollama -f

Ces journaux permettent notamment d’identifier un manque de mémoire, un problème de chargement du modèle ou une erreur de configuration réseau.

Télécharger et lancer un modèle

Pour récupérer Llama 3.2 3B :

ollama pull llama3.2:3b

Le téléchargement peut prendre plusieurs minutes selon la taille du modèle et la connexion du serveur. Listez ensuite les modèles disponibles :

ollama list

Pour ouvrir une session interactive :

ollama run llama3.2:3b

Vous pouvez alors saisir directement un prompt. La première réponse est souvent plus lente, car le modèle doit être chargé en mémoire.

Il est également possible de lancer directement une requête :

ollama run llama3.2:3b "Résume les avantages du self-hosting en cinq lignes."

Surveillez la consommation pendant les essais avec top, htop ou free -h. Si le serveur commence à utiliser massivement le swap, choisissez un modèle plus petit, une quantification plus forte ou davantage de RAM.

Utiliser l’API Ollama sur le port 11434

Ollama fournit une API HTTP sur le port 11434. Depuis le VPS, testez-la avec :

curl http://127.0.0.1:11434/api/generate \
  -d '{
    "model": "llama3.2:3b",
    "prompt": "Explique le principe du RAG en trois phrases.",
    "stream": false
  }'

L’option "stream": false demande une réponse JSON complète. Pour une application interactive, le mode streaming peut afficher progressivement les fragments générés.

Par défaut, il est préférable de conserver Ollama sur l’adresse locale. N’exposez pas directement le port 11434 sur Internet : l’API ne doit pas être considérée comme une interface publique sécurisée avec authentification intégrée.

La variable OLLAMA_HOST contrôle l’adresse d’écoute. Pour la définir avec systemd :

sudo systemctl edit ollama

Ajoutez :

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

Rechargez ensuite la configuration :

sudo systemctl daemon-reload
sudo systemctl restart ollama

Vérifiez l’écoute réseau :

ss -ltnp | grep 11434

Le résultat doit indiquer 127.0.0.1:11434 si le reverse proxy se trouve sur le même VPS.

Sécuriser l’accès avec un reverse proxy

Pour rendre l’API accessible à une application distante, placez Nginx, Caddy ou Traefik devant Ollama. Notre guide installer Nginx sur un VPS couvre la mise en place, et celui pour activer HTTPS avec Let’s Encrypt le certificat. Le reverse proxy doit assurer au minimum :

• le chiffrement HTTPS
• une authentification par jeton, Basic Auth, SSO ou mTLS
• une limitation du nombre de requêtes
• des délais adaptés aux générations longues
• une restriction par adresse IP lorsque cela est possible

Un bloc Nginx minimal peut transmettre les requêtes à Ollama :

location /ollama/ {
    proxy_pass http://127.0.0.1:11434/;
    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

Cette configuration n’ajoute pas encore d’authentification. Elle doit être intégrée dans un serveur HTTPS avec un certificat valide et un contrôle d’accès. Le pare-feu UFW doit laisser le port 11434 fermé publiquement et n’autoriser que les ports nécessaires, généralement 22, 80 et 443.

Si l’application consommatrice réside sur le même réseau privé, vous pouvez éviter toute exposition Internet et limiter l’accès aux seules adresses internes.

Connecter Ollama à n8n ou à une application

n8n peut utiliser Ollama à travers son intégration dédiée lorsqu’elle est disponible dans la version installée, ou avec un nœud HTTP Request.

L’URL de base sera généralement :

https://llm.example.fr/ollama

Le nom du modèle doit correspondre exactement à celui affiché par ollama list, par exemple llama3.2:3b.

Si n8n fonctionne dans un conteneur Docker, 127.0.0.1 désigne le conteneur lui-même, pas le VPS. Utilisez alors un nom DNS interne, l’adresse privée appropriée ou un réseau Docker partagé. Ne contournez pas ce problème en ouvrant sans protection le port 11434.

Dans une application, un appel à /api/chat permet de transmettre une conversation structurée :

{
  "model": "llama3.2:3b",
  "messages": [
    {
      "role": "user",
      "content": "Analyse ce ticket de support."
    }
  ],
  "stream": false
}

Ajoutez des délais d’attente suffisants, une limite de taille pour les prompts et une file d’attente si plusieurs utilisateurs peuvent lancer des générations simultanées.

Limites et bon dimensionnement

Commencez avec un seul modèle compact et mesurez trois éléments : la RAM réellement utilisée, le temps avant le premier fragment et le nombre de tokens générés par seconde. Testez avec des prompts représentatifs, car un essai court ne reflète pas un contexte documentaire volumineux.

Sur CPU, limitez la concurrence. Plusieurs générations simultanées peuvent saturer les cœurs, augmenter fortement la latence et provoquer un manque de mémoire. Un système de file d’attente est souvent plus fiable qu’une ouverture directe à de nombreux clients.

Surveillez aussi l’espace disque, les journaux, les mises à jour d’Ollama et les versions de modèles. Sauvegardez la configuration, les modèles personnalisés et les données applicatives utiles. Les modèles publics peuvent généralement être téléchargés de nouveau.

Pour un premier déploiement, une configuration avec 8 à 16 Go de RAM, un stockage NVMe et un modèle quantifié de 1B à 3B constitue une base cohérente. Un modèle 7B Q4 demande davantage de mémoire et restera lent sur CPU. Pour un service fortement sollicité ou exigeant une réponse rapide, prévoyez une infrastructure GPU plutôt que de surdimensionner uniquement le nombre de cœurs CPU.