VPS avec GPU : en avez-vous vraiment besoin ?

Avez-vous besoin d’un VPS avec GPU, ou un CPU suffit-il ?

Un VPS avec GPU change deux aspects de l’exécution d’un modèle en local : la vitesse de génération des tokens et la taille maximale du modèle qui tient en mémoire. Il ne change rien d’autre. Si votre charge consiste à faire répondre une personne à la fois à un modèle de chat quantifié de 7B à 27B, à exécuter un job d’embeddings à faible volume ou à transcrire de la voix avec Whisper small, un VPS CPU classique disposant de suffisamment de RAM suffit déjà. Commencez avec le CPU, mesurez le chiffre qui vous gêne, puis augmentez les ressources.

La raison tient à la bande passante mémoire. Lorsqu’un modèle de langage génère un token, il lit en mémoire tous les poids dont il a besoin. Un modèle 8B quantifié sur 4 bits occupe environ 4.7 GB sur disque et à peu près autant en mémoire. La génération d’un token implique donc de déplacer environ 4.7 GB. Divisez la bande passante mémoire de la machine par cette valeur : vous obtenez le plafond de tokens par seconde. Cette simple division explique presque tous les benchmarks que vous lirez.

Ce qu’un GPU vous apporte réellement

Bande passante. La mémoire DDR5 d’un serveur moderne transfère des dizaines de gigaoctets par seconde. La mémoire du GPU (VRAM, video RAM) en transfère des centaines, voire plus de mille. Le rapport entre les deux détermine l’accélération, et l’écart est important.

Capacité et rapidité. Un serveur avec un CPU et 64 GB de RAM peut charger un modèle 70B en 4 bits. Il fonctionnera, à un rythme plus proche de la lecture que de la conversation. Un GPU n’est utile dans ce cas que si le modèle tient dans la VRAM, car dès que des layers débordent vers la RAM système, le chemin lent reprend le dessus.

Débit par batch. C’est le point que l’on sous-estime souvent. Un GPU qui génère une réponse pour un seul utilisateur laisse la majeure partie de sa capacité de calcul inutilisée, car il attend la mémoire. Traitez 20 requêtes à la fois : la même lecture des weights sert les 20 requêtes. Le nombre total de tokens par seconde augmente plusieurs fois, tandis que la vitesse par utilisateur baisse à peine. Un CPU ne fonctionne pas ainsi. Deux utilisateurs simultanés sur un serveur avec un CPU réduisent approximativement de moitié la vitesse de traitement de chacun. Si vous construisez une API appelée par de nombreux clients, le batching est le principal argument en faveur d’un GPU, davantage que la vitesse brute sur un flux unique.

Traitement du prompt. La lecture d’un prompt long dépend de la puissance de calcul, et non de la bande passante mémoire. C’est dans ce domaine que les GPU ont l’avantage le plus net. Un contexte de 30,000 tokens qu’un CPU traite en une minute est traité en quelques secondes par un GPU. Les architectures de retrieval qui injectent des documents dans chaque requête le montrent constamment.

Ordres de grandeur et interprétation

Le bloc ci-dessous présente des chiffres publiés typiques pour un modèle 8B à quantification 4 bits, en juillet 2026, avec un seul flux. Ils donnent un ordre de grandeur et ne constituent pas une garantie. La quantification, la longueur du contexte et le moteur d’inférence peuvent modifier ces valeurs.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

La ligne correspondant au GPU de 24 GB indique 50 tokens par seconde, contre 11 pour une machine équipée d’un processeur DDR5. Cela représente environ cinq fois plus, ce qui correspond au rapport de bande passante plutôt qu’à une différence de puissance de calcul brute. Le débit réel reste également inférieur au résultat de la bande passante divisée par la taille du modèle, car l’attention appliquée à un contexte qui s’allonge ajoute une charge que cette division simplifiée ne prend pas en compte.

À titre de comparaison, une personne lit environ 5 à 10 mots par seconde. À partir de 15 tokens par seconde, la saisie semble déjà normale pour un seul lecteur. C’est pourquoi de nombreuses configurations utilisant uniquement le CPU sont parfaitement suffisantes.

Dimensionner la VRAM avant l’achat

La taille du fichier du modèle est un minimum, pas la capacité requise. Prévoyez les poids, le KV cache (cache clé-valeur, c’est-à-dire la mémoire conservée par le mécanisme d’attention pour chaque token), ainsi qu’environ 1 GB de surcharge.

Règle pratique en juillet 2026 : prenez la taille du fichier du modèle en gigaoctets et ajoutez 20 % pour un contexte courant de 8k à 16k. Un modèle 8B de 4.7 GB nécessite environ 6 GB de VRAM. Un modèle 27B en 4 bits fait environ 16 GB et nécessite approximativement 20 GB. Un modèle 70B en 4 bits fait environ 40 GB et nécessite une carte de 48 GB, ou deux cartes moins capacitaires. Le même calcul reste valable bien au-delà, et le calcul de VRAM pour un modèle de 2.8 billions de paramètres comme Kimi K3 montre à partir de quel moment le choix d’une carte n’est plus vraiment la question.

Les contextes longs invalident cette règle. Le KV cache augmente linéairement avec la longueur du contexte et peut dépasser le poids du modèle lui-même à 128k tokens. Si vous prévoyez d’utiliser de longs contextes, dimensionnez d’abord la capacité du cache et vérifiez les options de quantification du cache proposées par votre moteur.

Vérifiez ce que la machine possède réellement

Sur une instance GPU, vérifiez d’abord que le pilote détecte la carte.

nvidia-smi

Vous devez obtenir un tableau indiquant le nom du GPU, la version du pilote et la mémoire utilisée sur la mémoire totale. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver signifie que le pilote est absent ou que le module du noyau n’a pas été recompilé après une mise à niveau du noyau. Sur une image Ubuntu standard, le correctif consiste généralement à exécuter sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, puis à redémarrer la machine pour charger le nouveau module.

Pour les conteneurs, le pilote seul ne suffit pas. Docker a besoin de NVIDIA Container Toolkit pour transmettre le périphérique au conteneur.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Vérifiez ensuite que le passthrough fonctionne depuis un conteneur :

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Le même tableau doit s’afficher. Une ligne docker: Error response from daemon: could not select device driver, qui indique une capacité GPU qu’elle ne peut pas satisfaire, signifie que le toolkit est installé, mais que Docker n’a jamais été reconfiguré ou redémarré. Réexécutez donc la ligne nvidia-ctk, puis redémarrez Docker. Dans Compose, l’équivalent est une entrée deploy.resources.reservations.devices dont la valeur de driver est nvidia et dont la liste des capacités contient gpu. Cette entrée s’intègre aux définitions de service habituelles présentées dans Docker Compose sur un VPS.

Mesurez avant de mettre à niveau

Exécutez le modèle que vous comptez réellement utiliser sur le serveur CPU dont vous disposez déjà, puis relevez les chiffres. Avec l’auto-hébergement d’un LLM avec Ollama sur un VPS, une seule option suffit :

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

La sortie se termine par les temps d’exécution. eval rate correspond à votre vitesse de génération, en tokens par seconde. prompt eval rate indique la vitesse à laquelle la machine a lu votre entrée. Ces deux chiffres indiquent quelle mise à niveau sera utile : une valeur faible pour eval rate signale un problème de bande passante mémoire, tandis qu’une valeur faible pour prompt eval rate sur des entrées longues signale un problème de calcul.

Sur une machine équipée d’un GPU, vérifiez que le modèle y a bien été chargé :

ollama ps

La colonne PROCESSOR affiche 100% GPU lorsque le modèle tient entièrement sur le GPU, ou une valeur telle que 43%/57% CPU/GPU dans le cas contraire. Un partage partiel est généralement plus pénalisant que prévu, car chaque token doit malgré tout attendre la partie la plus lente.

La question du coût

Les instances GPU coûtent plusieurs fois plus cher qu’une instance CPU comparable. Elles sont facturées pour chaque heure d’existence, et non selon le nombre de tokens produits. Une instance GPU active en permanence pour traiter quelques requêtes par jour est la méthode d’inférence la plus coûteuse. Le seuil de rentabilité dépend du taux d’utilisation : un GPU très sollicité revient peu cher par token, tandis qu’un GPU inactif représente une dépense pure.

Trois modèles réalistes fonctionnent. Gardez les tâches régulières à faible volume sur un VPS CPU. Envoyez les requêtes complexes occasionnelles vers une API hébergée et payez au token. Louez un GPU à l’heure pour les traitements par lots, le fine-tuning ou une génération d’embeddings en volume, puis détruisez l’instance. Il est normal de combiner ces approches. La discipline budgétaire décrite dans Contrôler le coût d’un agent IA sur un VPS toujours actif s’applique également ici, à ceci près que la fuite budgétaire vient du temps d’inactivité, et non du nombre de tokens.

Ce qui fonctionne encore correctement sans GPU

Les embeddings à faible volume. Un petit modèle d’embeddings traite des centaines de documents courts par minute sur quelques cœurs CPU. Un index construit une seule fois n’a pas besoin d’être généré rapidement.

Whisper small et base pour la transcription. Faster-whisper sur CPU transcrit presque en temps réel avec le petit modèle. C’est suffisant pour un pipeline exécuté pendant la nuit.

Les modèles de chat quantifiés jusqu’à environ 27B, pour un ou deux utilisateurs. C’est lent, mais lisible et utilisable.

Tout ce que vous considéreriez comme un batch job. Si personne ne regarde l’écran, la durée d’exécution est une contrainte de planification, pas une exigence.

Ce qui nécessite réellement un GPU : l’entraînement ou le fine-tuning au-delà d’un petit adapter, le service pour de nombreux utilisateurs simultanés, la génération d’images et de vidéos, ainsi que la parole en temps réel lorsque la latence constitue le produit.

FAQ

De quelle quantité de VRAM ai-je besoin pour un modèle 7B ou 8B ?

Comptez environ 6 GB pour un modèle 8B quantifié en 4 bits avec un contexte normal de 8k à 16k. Les poids occupent environ 4.7 GB. Le reste correspond au cache KV et à environ 1 GB d’overhead. Une carte de 12 GB laisse une marge confortable pour des contextes plus longs. Si vous prévoyez d’utiliser un contexte de 128k, dimensionnez séparément le cache, car il peut devenir plus volumineux que les poids.

Puis-je utiliser Ollama sans GPU ?

Oui. Ollama bascule automatiquement sur le CPU et nécessite uniquement assez de RAM pour charger le modèle. Pour un modèle 8B en 4 bits, comptez environ 5 à 12 tokens par seconde selon la vitesse de la mémoire. C’est proche de la vitesse de lecture pour un seul utilisateur. Les longs prompts sont le principal problème sur CPU, car la lecture de 30,000 tokens de contexte sollicite fortement le calcul et prend bien plus de temps que la génération de la réponse.

Pourquoi mon GPU est-il à peine plus rapide que le CPU ?

La cause la plus fréquente est que le modèle ne tient pas entièrement dans la VRAM. Certaines couches s’exécutent alors sur le CPU, et chaque token attend la partie la plus lente. Exécutez ollama ps et vérifiez que la colonne PROCESSOR affiche 100% GPU. Si un partage apparaît, utilisez une quantification plus légère ou un modèle plus petit. L’autre cause courante est un benchmark trop court, dans lequel le chargement du modèle domine la mesure.

Un GPU VPS vaut-il le coût pour un seul utilisateur ?

En général, non. Une personne lit à raison de 5 à 10 mots par seconde, et un serveur CPU produit déjà les tokens plus rapidement que cela pour les modèles jusqu’à environ 13B. Les cas qui peuvent justifier le coût pour un seul utilisateur sont les longs prompts, la génération d’images et le fine-tuning. Servir plusieurs utilisateurs simultanément est l’argument le plus solide, car le batching permet à un seul GPU de répondre à vingt requêtes pour un coût proche de celui d’une seule réponse.

Dois-je louer un GPU à l’heure ou en laisser un fonctionner en permanence ?

Louez-le à l’heure lorsque la charge est ponctuelle : fine-tuning, génération groupée d’embeddings ou transcription par lots. Laissez-le fonctionner en permanence uniquement si la carte reste occupée, car une instance GPU est facturée pour son fonctionnement, et non pour le nombre de tokens produits. Un assistant peu sollicité coûte moins cher sur un CPU VPS ou via une API hébergée facturée au token que sur un GPU inactif.