Peut-on faire tourner Ollama ou un petit LLM sur un VPS à vCPU dédiés sans GPU ?

Quels modèles tiennent dans la RAM de chaque offre ?

Sur un CPU, la RAM décide quel modèle tourne et les vCPU décident à quelle vitesse il tourne. Le modèle entier réside en mémoire système, et la taille du téléchargement affichée par Ollama est une bonne première estimation de la mémoire qu'il occupe. Le contexte, le système et tout le reste sur le VPS viennent en plus : la documentation d'Ollama indique que la RAM nécessaire croît avec OLLAMA_NUM_PARALLEL fois OLLAMA_CONTEXT_LENGTH, et le contexte par défaut est de 4 096 tokens.

Quelle est la vitesse d'inférence d'un LLM sur un CPU ?

L'inférence sur CPU est plus lente qu'un GPU, d'un écart fixé par les threads, la bande passante mémoire et la quantification. Cobaltfell ne publie aucun chiffre de tokens par seconde qui lui soit propre : Nos propres résultats YABS et Geekbench 6, ainsi que le steal time que nous mesurons, seront publiés avec leur date dès la livraison de notre première machine de test. D'ici là, nous ne citons aucune performance de notre cru.

Le chiffre public le plus utile est un test publié par Leaseweb le 5 avril 2026 (page mise à jour le 20 août 2026). Sur un serveur doté de deux processeurs AMD EPYC 9334 (Zen 4) tournant sur 24 threads, le test a généré 27,8 tokens par seconde avec un modèle 8B en quantification 4 bits (DeepSeek-R1-0528-Qwen3-8B, Q4_K_M), et 8,1 tokens par seconde avec le même modèle en FP16. Un GPU NVIDIA L4 a atteint 16,7 tokens par seconde sur ce modèle en FP16. Le temps jusqu'au premier token en Q4 allait de 3,6 à 4,8 secondes selon les modèles testés.

Comment exécuter Ollama sur un VPS sans GPU ?

Installez Ollama avec le script officiel, téléchargez un modèle qui tient dans l'offre, et confirmez qu'il tourne entièrement sur le CPU. ollama ps montre où réside un modèle chargé : sa colonne PROCESSOR indique 100% CPU sur un VPS. Ollama écoute sur 127.0.0.1, port 11434, par défaut ; accédez-y via un tunnel SSH, ou placez un reverse proxy avec authentification devant avant de changer OLLAMA_HOST.

# official install script for Linux
curl -fsSL https://ollama.com/install.sh | sh

# pull and run a model that fits the plan (here about 2.5 GB)
ollama run qwen3:4b "Summarize what a dedicated vCPU is in one sentence."

# where the model is loaded: expect 100% CPU
ollama ps

# service settings: add these two lines under [Service]
sudo systemctl edit ollama
#   Environment="OLLAMA_CONTEXT_LENGTH=4096"
#   Environment="OLLAMA_NUM_PARALLEL=1"
sudo systemctl daemon-reload
sudo systemctl restart ollama

Faut-il utiliser llama.cpp directement ?

llama.cpp est le bon choix quand la quantization, le nombre de threads et les flags du serveur comptent. Son README liste le support AVX, AVX2, AVX512 et AMX sur x86, et la quantization entière de 1,5 bit à 8 bits pour réduire la mémoire utilisée et accélérer l'inférence. Il fournit llama-bench, un outil de test de performance dont les valeurs par défaut traitent un prompt de 512 tokens et génèrent 128 tokens, et qui essaie plusieurs nombres de threads en une seule exécution.

Deux vérifications prennent une minute sur n'importe quel VPS : quelles instructions vectorielles le processeur expose, et si le modèle tourne plus vite sur autant de threads que de vCPU ou sur un thread par cœur physique. Chez Cobaltfell, Un vCPU correspond à un thread matériel du processeur hôte. Les vôtres sont épinglés un à un à votre VPS et ne sont jamais prêtés à un autre client, et les deux threads d'un cœur physique restent ensemble : ainsi, chaque 2 vCPU forment un cœur entier que nul voisin ne partage, donc Fell 16 donne 16 threads sur 8 cœurs pour comparer ; la règle est expliquée dans un vCPU dédié est-il un cœur ou un thread.

# vector instructions the VPS can use
grep -o -w -E 'avx2|avx512f|avx512_bf16|amx_tile' /proc/cpuinfo | sort -u

# prompt 512 tokens, generate 128, on 8 and then 16 threads
llama-bench -m qwen3-8b-q4_k_m.gguf -p 512 -n 128 -t 8,16

Que changent des vCPU dédiés pour l'inférence ?

La génération occupe tous les threads pendant toute la durée d'une réponse, donc du temps CPU perdu se traduit directement par des tokens plus lents. Sur un vCPU partagé, le burst d'un voisin allonge chaque réponse en steal time, expliqué dans ce qu'est le steal time CPU et comment le vérifier sur un VPS, et les plafonds de fair-use sur les longues périodes à pleine charge limitent l'inférence en premier.

Chez Cobaltfell : La pleine charge est autorisée aussi longtemps que votre travail l'exige : aucun crédit CPU, aucune fenêtre de burst et aucun throttling après quelques minutes à 100 %. La RAM de votre offre vous est réservée pour votre VPS et n'est pas surallouée, donc un modèle chargé n'est jamais poussé hors de la RAM par l'hôte. La famille de processeurs est AMD EPYC 9004/9005 (Zen 4 / Zen 5). Faire tourner un modèle à 100 % est autorisé ; la limite est ailleurs : Le minage de toute cryptomonnaie est interdit, sur toute offre et avec tout logiciel. Votre propre travail CPU lourd, comme les builds, l'encodage, l'inférence ou les bases de données, peut tourner à pleine charge, et un nœud qui ne fait que valider une blockchain ne constitue pas du minage.

Les hébergeurs qui vendent des vCPU dédiés, et le prix d'un cœur, sont comparés dans combien coûte un VPS à CPU dédié par cœur en novembre 2026.

Quand un GPU est-il la bonne réponse pour un LLM ?

Un GPU est la bonne réponse quand la vitesse par utilisateur, le nombre d'utilisateurs ou la taille du modèle comptent plus que le coût. Le test de Leaseweb trace la même ligne : le CPU convient aux charges par lots, asynchrones et légères, tandis que les GPU restent en tête pour les travaux critiques en latence, la forte concurrence et les modèles au-delà de 20 milliards de paramètres sans quantization. Trois autres cas pointent vers un GPU :

• Les modèles plus gros que la RAM. Fell 16 a 32 GB ; un modèle 70B à 43 GB ne tient dans aucune offre.
• Les longs prompts. La recherche documentaire et le chat sur documents injectent des milliers de tokens avant le premier mot, et c'est dans cette phase de prompt qu'un CPU attend le plus longtemps.
• L'entraînement et le fine-tuning. Ce sont des tâches GPU en pratique.

Cobaltfell ne vend pas de GPU. Pour ces cas, un serveur GPU est la bonne location, avec un VPS CPU gardé pour l'API, la file d'attente et la base de données vectorielle autour du modèle. L'encodage vidéo pose la même question, traitée dans un VPS peut-il transcoder de la vidéo avec FFmpeg sans GPU.