2026 : Ollama et LLM open source sur GPU VPS économique — VRAM, CUDA/Docker et coûts API FAQ

Pour faire tourner Llama 3, Qwen, Mistral et d'autres poids ouverts sur une infra que vous contrôlez, l'un des chemins les plus simples en 2026 reste Ollama : tirer un modèle, exposer un point de terminaison local compatible OpenAI /v1, et suivre l'installation documentée Linux + NVIDIA CUDA. Ce guide répond à l'intention de recherche derrière cheap GPU VPS, ollama vps et run ollama cloud : décider si un hôte GPU bat les API au token, dimensionner la VRAM, exécuter une checklist d'acceptation CUDA / Docker copiable-collable, et comparer la location GPU mensuelle aux factures API — avec une formule paramétrée, sans tarifs vpszap inventés.

Qui doit faire tourner Ollama sur un GPU VPS (inférence privée, conformité, batch vs API temps réel)

Ollama auto-hébergé sur un serveur GPU convient quand : (1) les prompts ou données d'entraînement ne doivent pas sortir de votre périmètre — inférence privée et pistes d'audit comptent ; (2) les nuits et week-ends portent de gros jobs de résumé, étiquetage ou indexation RAG où le batch hors ligne bat le paiement à la requête ; (3) un ensemble fixe de services internes (environ 3–20 appelants concurrents) frappe le même modèle et la dépense API croît linéairement chaque mois ; (4) vous devez épingler versions de modèles et paliers de quantification (Q4_K_M, Q5, etc.) au lieu de swaps silencieux côté fournisseur.

Les API commerciales au token gagnent encore quand les pics sont imprévisibles, que vous avez besoin des derniers modèles fermés, ou que personne ne maintiendra pilotes et disques. Si le volume mensuel est minuscule (par exemple sous ~5M tokens) et que la latence est souple, un loyer GPU fixe peut rester inoccupé la plupart du temps. Limite : des petites quants CPU-only peuvent être testées sur un VPS pas cher sans GPU, mais la longueur de contexte et les tokens/s s'effondrent — cet article suppose Ollama + GPU NVIDIA.

VRAM et taille de modèle (avec chemins de dégradation si la VRAM manque)

Le dimensionnement n'est pas « paramètres ÷ 2 ». Budgétisez paramètres × bits de quant + cache KV, qui grossit avec la longueur de contexte et les sessions concurrentes. Le tableau ci-dessous reflète des paliers d'inférence 2026 courants (instance unique, contexte ~8k) ; validez avec nvidia-smi sur votre machine.

Les hôtes GPU VPS pas cher type RTX 4090 sont le sweet spot habituel pour les quants 7B–13B. Les paliers Cloud GPU A100 / H100 visent le 70B, le long contexte ou plus de parallélisme. Ordre de dégradation : baisser la concurrence → raccourcir le contexte → quant plus petite → modèle plus petit → découper les jobs batch — évitez de lancer d'abord les plus gros poids et de boucler sur des OOM.

Docker et CUDA bare metal : deux checklists d'installation

Voie A : Linux bare metal + pilote NVIDIA (défaut production courant)

• Après provisionnement d'une instance GPU, SSH ; prévoyez ≥ 80 Go de disque — le cache modèle grossit vite.
• Installez le pilote NVIDIA ; validez avec nvidia-smi (nom GPU, version pilote, VRAM totale).
• Installez Ollama selon la doc : curl -fsSL https://ollama.com/install.sh | sh, puis sudo systemctl enable --now ollama (nom d'unité variable).
• Tirez un modèle : ollama pull qwen2.5:7b-instruct-q4_K_M (tag selon la bibliothèque).
• Santé : curl -s http://127.0.0.1:11434/api/tags renvoie du JSON ; n'exposez vers l'extérieur qu'avec TLS et auth.
• Probe compat OpenAI : curl http://127.0.0.1:11434/v1/models.

Voie B : Docker + NVIDIA Container Toolkit

• Installez nvidia-container-toolkit, exécutez sudo nvidia-ctk runtime configure --runtime=docker, redémarrez Docker.
• Démarrez : docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama (vérifiez le tag sur Docker Hub).
• Dans le conteneur : docker exec -it ollama ollama run llama3.2.
• Mêmes contrôles : curl http://127.0.0.1:11434/api/tags ; logs via docker logs -f ollama.

Si vous déboguez déjà des stacks conteneurisées sur une passerelle, l'état d'esprit de contrôle de santé en couches décrit dans le dépannage du déploiement OpenClaw Docker Compose se transpose bien à Linux GPU + Ollama (volumes, sondes, « processus up mais handshake en échec »).

Performance et coût : benchmark tokens/s et calcul du seuil de rentabilité

Benchmark léger (copier-coller)

# 1) VRAM de base
nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv -l 1

# 2) Exécution streamée — estimez tokens/s (nom du modèle tiré)
time ollama run qwen2.5:7b-instruct-q4_K_M "En 200 mots, listez une checklist d'acceptation pour l'hébergement d'inférence IA."

# 3) Smoke HTTP (installez hey ou wrk ; limitez le débit d'abord)
hey -n 20 -c 2 -m POST -H "Content-Type: application/json" \
  -d '{"model":"qwen2.5:7b-instruct-q4_K_M","prompt":"hi","stream":false}' \
  http://127.0.0.1:11434/api/generate

Enregistrez trois chiffres pour votre matrice de décision : temps jusqu'au premier token, tokens/s stable, et si concurrence = 2 déclenche un OOM. Les comparaisons relatives sur la même machine comptent plus que les classements publics.

Cadre de coût mensuel (remplissez vos propres prix)

Soit G = loyer mensuel de l'hôte GPU (ou $/GPU-heure × 730), E = électricité/colocation si auto-hébergé, A = surcharge ops (optionnel). Dépense API ≈ T × P où T est le volume mensuel de tokens (séparez entrée/sortie si tarifé à part) et P le $/1M tokens du fournisseur sur ses pages publiques actuelles.

Seuil (approximatif) : quand G + E + A < T × P et que vous pouvez garder le GPU occupé, l'auto-hébergement devient attractif ; sinon gardez les API — ou un hybride (API pour les pics, Ollama pour les creux).

Exemples placeholders (remplacez par vos devis) : si G = 280 $/mois pour un Cloud GPU type 4090, T = 50M tokens, P ≈ 0,6 $/1M en blend, API ≈ 30 $ — l'API semble moins chère en cash, mais exclut résidence des données et contrôle de version. À T = 500M, API ≈ 300 $ et l'auto-hébergement commence à rivaliser — si vous opérerez pilotes, disques et sécurité. Pour le routage multi-fournisseurs (Ollama restant le cœur d'inférence), voir la config multi-fournisseurs et le failover OpenClaw.

Renforcement production : systemd, redémarrages, disque, logs, limitation de débit

• systemd : Restart=on-failure ; arrêtez Ollama avant les mises à niveau pour éviter des blobs à moitié écrits.
• Disque : alerte quand /var/lib/ollama ou le volume Docker passe sous ~15 % libre ; les pulls parallèles remplissent vite.
• Logs : rotation journal ou docker logs ; notez tag modèle, quant et concurrence pour les post-mortems OOM.
• Limites : plafonnez QPS et taille de corps sur /v1/chat/completions au reverse proxy ; n'exposez jamais 11434 sur 0.0.0.0 sans auth.
• Config as code : reconstruisez le cache modèle depuis les pulls ; gardez Modelfiles et politique dans Git.

Un GPU VPS signifie en général SSH seulement — pas de VNC. Prévoyez bastion + port forwarding pour les endpoints admin, comme pour verrouiller un hôte de build.

Matrice d'erreurs (CUDA, OOM, pulls lents, ports exposés)

Note de bas de page : les équipes qui ont besoin de batching continu et de swaps LoRA à chaud évaluent parfois vLLM à part. Cet article reste sur Ollama pour la surface d'installation et la compatibilité /v1 des petites et moyennes équipes.

Quand un GPU VPS pas cher n'est pas le bon défaut (limites)

• Très peu de tokens mensuels et aucun opérateur Linux — achetez du temps via les API plutôt que des pilotes.
• 70B pleine précision ou multimodal lourd — un 4090 ne suffit pas ; ne forcez pas le SKU le moins cher.
• VRAM annoncée ne correspond pas à nvidia-smi — changez de SKU ou région, n'optimisez pas les prompts autour d'une arnaque.
• Conformité exige des attestations matériel dédié — vérifiez contrats et journaux, pas seulement le $/heure.

FAQ

• Serveur GPU pas cher vs Cloud GPU ? Location carte unique style VPS vs pools GPU-heure. Choisissez selon besoin 24/7 ou batch intermittent.
• Ollama peut-il remplacer OpenAI entièrement ? Pour poids ouverts et latence tolérante sur outils internes, souvent oui ; pour derniers modèles fermés ou SLA strict, gardez de la capacité API.
• Minimum pour déploiement LLM local ? 7B Q4 veut ≥ ~8 Go VRAM utilisable ; en production on vise souvent 24 Go de marge pour KV et concurrence.
• Comment accepter un hébergement d'inférence IA ? nvidia-smi, /api/tags, et une baseline tokens/s à prompt fixe avant bascule de trafic.
• « Run Ollama cloud » géré vs DIY ? Le géré économise l'ops ; le DIY contrôle données et unit economics. Sur vpszap vous provisionnez des instances GPU et exécutez cette checklist sur la machine.

Aligner le palier GPU sur la taille du modèle — valider Ollama avant d'élargir

vpszap est une plateforme d'infrastructure pour développeurs IA : au-delà du Mac cloud, vous pouvez choisir GPU VPS / Cloud GPU pour l'hébergement LLM — classe RTX 4090 pour quants 7B–13B, classe A100 pour poids plus lourds ou plus de flux parallèles. Après provisionnement, lancez ollama pull et /api/tags depuis cet article, puis ajoutez des instances quand les benchmarks le justifient. Placez l'inférence près de votre app (Singapour, Tokyo, Séoul, Hong Kong, US Est/Ouest — voir console). Démarrez depuis Tarifs, Configurer et commander, ou l'accueil vpszap pour GPU VPS et inférence IA — pas un VPS Linux sans GPU pensé pour WordPress.