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 choses pour l’exécution autonome d’un modèle : 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 de travail consiste à utiliser un modèle conversationnel quantifié de 7B à 27B pour répondre à une personne à la fois, à générer des embeddings en faible volume ou à transcrire de la parole avec Whisper small, un VPS CPU standard disposant de suffisamment de RAM suffit déjà. Commencez avec le CPU, mesurez la valeur qui vous pose problème, puis augmentez les ressources si nécessaire.

La raison est 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 nécessite donc de déplacer environ 4.7 GB. Divisez la bande passante mémoire de la machine par cette valeur pour obtenir la limite théorique en tokens par seconde. Cette simple division explique presque tous les benchmarks que vous trouverez.

Ce que vous apporte réellement un GPU

Bande passante. La mémoire DDR5 d’un serveur moderne transfère des dizaines de gigaoctets par seconde. La mémoire d’un GPU (VRAM, video RAM) en transfère des centaines, voire plus de 1 000. Le rapport entre ces valeurs détermine l’accélération, qui est importante.

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

Débit par batch. C’est le point que l’on sous-estime le plus. Lorsqu’un GPU génère du texte pour un seul utilisateur, la majeure partie de sa puissance de calcul reste inutilisée, car le GPU attend la mémoire. Traitez 20 requêtes simultanément : la même lecture des poids sert aux 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. Sur un serveur équipé d’un CPU, deux utilisateurs simultanés se partagent à peu près les performances par deux. Si vous développez une API appelée par de nombreux clients, le batching est l’argument principal en faveur d’un GPU, davantage que la vitesse brute sur un flux unique.

Traitement du prompt. La lecture d’un long prompt dépend de la puissance de calcul, et non de la bande passante mémoire. C’est dans ce domaine que les GPU offrent le plus grand avantage. Un contexte de 30 000 tokens qu’un CPU traite en une minute ne prend que quelques secondes sur un GPU. Les architectures de retrieval qui insèrent des documents dans chaque requête en bénéficient constamment.

Ordres de grandeur et interprétation

Le bloc ci-dessous présente des valeurs publiées typiques en flux unique pour un modèle 8B avec une quantification sur 4 bits, en juillet 2026. Elles donnent un ordre de grandeur et ne constituent pas une garantie. Votre quantification, la longueur du contexte et votre moteur d’inférence modifieront 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 du GPU de 24 GB indique 50 tokens par seconde, contre 11 pour une machine équipée d’un CPU 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 division de la bande passante 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 vitesse donne déjà l’impression d’une frappe normale pour un lecteur unique. C’est pourquoi de nombreuses configurations utilisant uniquement un CPU conviennent tout à fait.

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 key-value, c’est-à-dire la mémoire par token conservée par le mécanisme d’attention), plus environ 1 GB de surcharge.

En pratique, en juillet 2026, prenez la taille du fichier du modèle en gigaoctets et ajoutez 20 pour cent pour un contexte normal 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 environ 20 GB. Un modèle 70B en 4 bits fait environ 40 GB et nécessite une carte de 48 GB, ou deux cartes plus petites.

Les contextes longs rendent cette règle inexacte. Le KV cache augmente linéairement avec la longueur du contexte. À 128k tokens, il peut dépasser le volume des poids. Si vous prévoyez d’utiliser des contextes longs, dimensionnez d’abord le cache et vérifiez les options de quantification du cache proposées par votre moteur.

Vérifier 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. Le message 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, la correction 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 exposer 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 l’intérieur d’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 indiquant une fonctionnalité GPU qu’il 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 la commande de redémarrage. Dans Compose, l’équivalent est une entrée deploy.resources.reservations.devices dont le driver vaut nvidia et dont la liste des capabilities contient gpu. Cette entrée s’intègre aux définitions de service standard 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 Ollama pour héberger vous-même un LLM sur un VPS, il suffit d’ajouter un flag :

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 valeurs indiquent quelle mise à niveau sera utile : une valeur eval rate faible révèle un problème de bande passante mémoire, tandis qu’une valeur prompt eval rate faible avec de longues entrées révèle 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 tout tient dans le GPU, ou une valeur telle que 43%/57% CPU/GPU dans le cas contraire. Un partage partiel donne généralement de moins bons résultats que prévu, car chaque token doit tout de même attendre la moitié 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 pour les tokens produits. Une instance GPU toujours active qui traite seulement quelques requêtes par jour est la solution la plus coûteuse pour exécuter de l’inférence. 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 un gaspillage pur.

Trois approches fonctionnent réellement. Gardez les traitements réguliers à faible volume sur un VPS CPU. Envoyez les requêtes difficiles occasionnelles vers une API hébergée et payez par token. Louez un GPU à l’heure pour les traitements par lots, le fine-tuning ou une opération d’embedding en masse, puis détruisez-le. Il est normal de combiner ces approches. La discipline budgétaire décrite dans contrôle des coûts d’un agent IA sur un VPS toujours actif s’applique également ici, à ceci près que la fuite de coûts 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 que vous construisez une seule fois n’a pas besoin d’être rapide.

Whisper small et base pour la transcription. Faster-whisper sur CPU transcrit presque en temps réel avec le modèle small. Cela suffit 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 un détail 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 est 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 de surcharge. 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 le cache séparément, car il peut devenir plus volumineux que les poids.

Puis-je exécuter Ollama sans GPU ?

Oui. Ollama bascule automatiquement sur le CPU et nécessite uniquement assez de RAM pour contenir le modèle. Pour un modèle 8B en 4 bits, prévoyez environ 5 à 12 tokens par seconde selon la vitesse de la mémoire. Cela correspond presque à la vitesse de lecture pour un seul utilisateur. Les longs prompts sont le principal problème sur CPU. La lecture de 30,000 tokens de contexte dépend fortement de la puissance de calcul et prend beaucoup 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 habituelle est que le modèle ne tient pas entièrement dans la VRAM. Certaines couches s’exécutent donc 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 elle indique une répartition, utilisez une quantification plus petite ou un modèle plus petit. L’autre cause fréquente est un benchmark court, dans lequel le temps de chargement du modèle domine la mesure.

Un GPU VPS est-il rentable pour un seul utilisateur ?

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

Dois-je louer un GPU à l’heure ou en exécuter un en permanence ?

Louez-le à l’heure si 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 utilisée. Une instance GPU est facturée en fonction de sa durée d’exécution, et non du 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.