Ollama ou llama.cpp sur un VPS CPU : que choisir ?

Ollama ou llama.cpp : sur quelle couche voulez-vous travailler ?

Ollama et llama.cpp ne sont pas concurrents au sens où la question le laisse entendre. llama.cpp est le moteur d’inférence : il charge un fichier de modèle et transforme un prompt en tokens. Ollama est un gestionnaire de modèles, un daemon en arrière-plan et une API HTTP qui s’appuie sur ce moteur. Le README d’Ollama répertorie toujours llama.cpp comme backend d’inférence (vérifié le 2 août 2026). La vraie question est donc de savoir sur quelle couche vous voulez intervenir sur votre VPS, et non laquelle est la plus rapide.

Utilisez Ollama si vous voulez un service qui récupère les modèles par leur nom et continue de fonctionner sans intervention. Utilisez directement llama.cpp si la machine est de petite taille et que vous devez choisir précisément le fichier de modèle, la taille exacte du contexte et le nombre exact de threads, car sur un petit VPS chacun de ces paramètres consomme de la mémoire dont vous ne disposez pas.

Ce que chaque projet est réellement

llama.cpp est une implémentation C et C++ de l’inférence de modèles Transformer, basée sur la bibliothèque ggml. Elle lit les fichiers GGUF. GGUF (GGML universal file format) est un conteneur à fichier unique qui contient les poids, le tokenizer et les métadonnées nécessaires à l’exécution du modèle. Le projet fournit des binaires distincts pour des tâches distinctes. llama-server est un serveur HTTP, llama-cli est une invite interactive et llama-bench mesure le débit. Les versions sont identifiées par un numéro de build, et non par une version sémantique. Le tag actuel est b10224, publié le 2 août 2026, et un nouveau tag est publié la plupart des jours ouvrés.

Ollama est un programme Go. Un daemon en arrière-plan, démarré avec ollama serve, charge les modèles et répond aux requêtes HTTP, tandis qu’un client en ligne de commande communique avec ce daemon. Derrière ces deux composants se trouve un registre hébergé sur ollama.com, qui contient des modèles préconditionnés. Ollama utilise des versions sémantiques, et la version v0.32.5 est sortie le 27 juillet 2026. ollama pull télécharge un fichier GGUF avec un modèle de prompt et un ensemble de paramètres par défaut, puis le stocke sous /usr/share/ollama/.ollama/models sur Linux. Ces fichiers se trouvent sur le disque racine et atteignent plusieurs gigaoctets chacun. Sur un VPS avec un volume racine de 25 GB, il est donc utile de savoir ce que le téléchargement laisse sur le disque et comment déplacer le répertoire des modèles ailleurs avant que le troisième téléchargement ne le remplisse.

C’est tout ce qui différencie ces deux méthodes de distribution. Ollama choisit pour vous la quantification, le modèle de prompt et la longueur du contexte, et vous fournit un seul nom à retenir. llama.cpp ne choisit rien et vous fournit des options.

Axe 1 : contrôle du modèle et de la quantification

La quantification réduit chaque poids de 16 ou 32 bits à 4, 5 ou 8 bits. C’est ce qui permet à un modèle de 8 milliards de paramètres de tenir dans la RAM d’un VPS ordinaire. La nomenclature GGUF devient lisible une fois le format compris : Q4_K_M signifie une quantification K sur 4 bits, de taille moyenne. Une valeur plus élevée conserve davantage de précision, mais consomme plus de mémoire.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Il s’agit des tailles de fichiers publiées dans le dépôt bartowski/Meta-Llama-3.1-8B-Instruct-GGUF sur Hugging Face, relevées le 2 août 2026 et converties des octets en Gio. 6 builds d’un même modèle sont disponibles, et le plus petit fait 2.96 Gio, contre 7.95 Gio pour le plus grand. Le choix courant par défaut, Q4_K_M, fait 4.58 Gio. Sur un VPS de 4 Gio, ce seul choix détermine si le modèle peut être chargé. La taille ne représente que la moitié de la décision : une ligne que vous pouvez vous permettre n’est pas forcément une ligne intéressante à utiliser, et ce que Q4, Q8 et fp16 coûtent réellement en qualité de réponse permet de déterminer si les gigaoctets supplémentaires apportent une différence perceptible.

Avec llama.cpp, vous indiquez le nom du fichier et choisissez donc vous-même cette ligne.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c correspond à la taille du contexte en tokens, -t au nombre de threads et -ngl définit le nombre de couches transférées vers un GPU (0 sur une machine équipée uniquement d’un CPU). Rien n’est deviné à votre place.

Avec Ollama, la quantification est incluse dans le tag que vous récupérez, et ollama ls affiche ce qui est réellement présent sur le disque. Si le registry ne contient pas le build souhaité, importez vous-même un fichier GGUF. Écrivez un Modelfile :

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Construisez-le ensuite et vérifiez le résultat :

ollama create llama31-q4 -f ./Modelfile
ollama ls

La longueur du contexte est le paramètre qui pose le plus souvent problème. Ollama choisit sa valeur par défaut selon la VRAM disponible, et une machine sans GPU tombe dans la plus petite catégorie : 4096 tokens. Si vous lui transmettez un document de 20 000 tokens, les tokens supplémentaires sont supprimés avant même que le modèle ne les voie. La réponse peut alors être formulée avec assurance tout en étant incorrecte sur un fichier qu’il n’a lu qu’en partie. Augmentez cette valeur avec OLLAMA_CONTEXT_LENGTH sur le daemon, ou avec PARAMETER num_ctx dans un Modelfile. Si une seule tâche nécessite une fenêtre plus grande, num_ctx peut être défini par requête plutôt qu’à l’échelle du serveur, ce qui évite d’ajouter ce cache à toutes les autres tâches traitées par le daemon. llama.cpp n’a pas non plus de valeur par défaut suffisamment fiable. Définissez -c explicitement et vérifiez la valeur configurée.

L’arithmétique de la mémoire que personne ne vous montre

Le fichier du modèle ne représente pas tout le coût. Le cache KV (key/value cache) contient une entrée par couche et par token de contexte. Il augmente avec la longueur de la conversation.

Faisons le calcul pour Llama 3.1 8B. Le modèle comporte 32 couches, 8 têtes key/value et une dimension de tête de 128. Chaque token stocke une key et une value de 2 octets chacune en f16, soit 2 x 8 x 128 x 2 = 4096 octets par couche. Sur 32 couches, cela représente 128 KiB par token. Un contexte de 4096 tokens coûte donc 512 MiB, et un contexte de 32,768 tokens coûte 4 GiB.

Un modèle Q4_K_M 8B avec un contexte de 4k nécessite donc environ 4.58 GiB pour les poids, auxquels il faut ajouter environ 0.5 GiB de cache et le runtime lui-même. Il ne tient pas dans 4 GiB de RAM. Il tient dans 8 GiB, avec suffisamment de marge pour fonctionner. Si vous augmentez le contexte à 32k sur cette même machine de 8 GiB, le cache consomme à lui seul toute la marge disponible. Surveillez la consommation en temps réel avec free -h pendant le chargement du modèle. Ne faites pas confiance à une estimation que vous n’avez pas mesurée. Si vous dimensionnez une machine pour un modèle nettement supérieur à 8B, le même calcul appliqué à un modèle 27B sur un VPS équipé uniquement d’un CPU montre ce que chaque palier de 8 à 64 GB permet réellement de charger.

Ollama amplifie cet effet. OLLAMA_NUM_PARALLEL vaut 1 par défaut, et la mémoire nécessaire à un modèle évolue en fonction de ce nombre multiplié par la longueur du contexte. Si vous augmentez les deux simultanément, le daemon demande discrètement plusieurs fois la quantité de RAM prévue. Ce même calcul détermine votre limite d’utilisateurs simultanés, car chaque requête concurrente a besoin de sa propre portion du cache KV. C’est pourquoi un serveur qui fonctionne bien pour une seule personne se bloque à cinq.

Axe 2 : le daemon à exploiter

Le script d’installation d’Ollama écrit une unité systemd, crée un utilisateur système ollama et active le service. Vous bénéficiez de la gestion du cycle de vie sans avoir à en écrire les éléments vous-même. La configuration passe par systemd :

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE est encore plus important sur un VPS CPU que partout ailleurs. Par défaut, les modèles restent en mémoire pendant 5 minutes, puis sont déchargés. La requête suivante doit relire tout le fichier depuis le disque avant de pouvoir répondre. Sur un stockage lent, le rechargement d’un fichier de 4.58 Gio transforme une réponse de deux secondes en une réponse de trente secondes. Une durée de keep-alive élevée élimine cette latence, mais mobilise la RAM en permanence. Les deux options ont un coût réel. Choisissez celle qui vous pénalise le moins. Si vous décidez de laisser le modèle en mémoire en permanence, configurer keep_alive pour qu’il survive aux périodes d’inactivité et aux redémarrages ne demande que quelques lignes et vous évite de réchauffer le modèle manuellement à chaque redémarrage du serveur.

llama.cpp ne fournit aucun daemon. Vous devez donc écrire l’unité vous-même avec /etc/systemd/system/llama-server.service :

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Activez-la avec sudo systemctl enable --now llama-server. Le processus conserve alors le modèle pendant toute sa durée de vie. Rien n’est déchargé en cas d’inactivité. Vous n’avez donc ni surprise liée à un rechargement, ni moyen de récupérer la mémoire sans arrêter le service. Si l’écriture d’unités est nouvelle pour vous, il s’agit du même modèle que l’exécution de vos propres services sous systemd sur un VPS.

Axe 3 : l’API avec laquelle votre application communiquera

Cet axe s’est beaucoup réduit. Les deux projets utilisent désormais le format de chat OpenAI, et la plupart des bibliothèques clientes fonctionnent avec l’un ou l’autre après une simple modification de l’URL de base.

Ollama écoute sur 127.0.0.1:11434. Sa route compatible avec OpenAI est http://localhost:11434/v1/chat/completions, et il conserve également une API native sur /api/chat. Une route compatible avec Anthropic est également documentée.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server écoute sur 127.0.0.1:8080 et fournit /v1/chat/completions, /v1/completions et /v1/embeddings, ainsi que son propre endpoint /completion et une interface web intégrée. Il expose aussi des routes opérationnelles qu’Ollama ne propose pas : /health pour une sonde de disponibilité, /props pour les paramètres du modèle chargé, /slots pour indiquer ce que fait chaque slot de requête, et /metrics au format Prometheus. Si vous prévoyez de monitorer ce service, cette différence sera probablement déterminante.

Aucun des deux serveurs n’active l’authentification pour vous. Par défaut, les deux écoutent sur loopback, pour de bonnes raisons. Accédez-y via un tunnel SSH ou derrière un reverse proxy, et n’exposez jamais 11434 ou 8080 sur Internet.

Ce qu’un VPS uniquement CPU peut réellement faire

Un VPS uniquement CPU exécute lentement les petits modèles. C’est le résumé honnête. L’essentiel est de savoir où se situe la limite. Mesurez avant de concevoir quoi que ce soit autour de cette configuration :

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

La colonne pp indique la vitesse de traitement du prompt et la colonne tg indique la vitesse de génération des tokens, toutes deux en tokens par seconde. Avec une offre vCPU partagée, un modèle 8B en Q4_K_M atteint généralement quelques tokens par seconde pour tg. Le traitement du prompt est la partie la plus pénalisante : le prompt complet est traité avant l’apparition du premier token de sortie. Un long prompt système ajoute donc une attente à chaque requête. La longueur de la réponse est la moitié du coût que vous pouvez réellement contrôler. À trois tokens par seconde, un modèle qui génère 600 tokens occupe la machine pendant trois minutes. Limiter la sortie avec num_predict est donc le moyen le moins coûteux d’empêcher une réponse trop longue de provoquer un timeout.

Utilisable sur CPU : un modèle de 1B à 4B pour la classification, l’extraction, les résumés courts ou le routage. Les réponses arrivent en quelques secondes et la mémoire nécessaire tient sur une offre standard. Pour un exemple concret de cette taille, plutôt qu’une simple plage de tailles, Nemotron 3.5 Lightning téléchargé et mesuré sur un VPS indique le tag exact, la quantité de RAM réellement demandée et la vitesse obtenue sans GPU. Inutilisable sur CPU : le chat interactif à vitesse de lecture, les assistants de programmation, le traitement de documents longs ou toute tâche avec une boucle d’agent effectuant de nombreux appels successifs. Une boucle qui effectue douze appels de quatre secondes prend une minute avant de produire le moindre résultat. Si vous envisagiez malgré tout un assistant de programmation, diriger un agent vers un modèle que vous hébergez vous-même précise quelles tâches un petit modèle local prend réellement en charge et lesquelles doivent rester sur une API hébergée.

Deux solutions existent lorsque les chiffres ne conviennent pas. Si le problème vient de la concurrence, c’est-à-dire de nombreux utilisateurs qui sollicitent simultanément un même modèle, le choix du moteur change, et la comparaison entre Ollama et vLLM pour le serving concurrent traite ce sujet. Si le problème vient de la vitesse brute, la solution est un VPS équipé d’un GPU, où -ngl commence à devenir significatif. Avant cela, établissez une référence pour le matériel lui-même, car la bande passante du disque et de la mémoire influence le temps de chargement autant que le CPU. Un benchmark VPS reproductible mérite l’heure nécessaire.

Installez llama.cpp sur une version précise

Les deux projets évoluent chaque semaine. Notez donc la version déployée. La commande fournie par le projet amont installe la version actuelle :

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Pour utiliser une version précise, téléchargez plutôt l’archive tar précompilée depuis la page des versions. La version b10224 est le tag actuel au 2 août 2026 :

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Vous pouvez aussi compiler ce même tag depuis les sources :

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev est la dépendance documentée pour les fonctionnalités HTTPS. La compilation prend plusieurs minutes et nécessite plus de mémoire que les plus petites offres. Compilez donc sur une machine plus grande, puis copiez les binaires si la petite machine manque de mémoire.

Installer Ollama en épinglant une version

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Le script lit OLLAMA_VERSION. Vous pouvez ainsi conserver une version connue comme fonctionnelle au lieu d’installer celle qui a été publiée ce matin. La version v0.32.5 a été publiée le 27 juillet 2026. Une procédure manuelle est également disponible si vous préférez ne pas transmettre un script à un shell avec un pipe :

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

La procédure manuelle ne crée ni l’unité systemd ni l’utilisateur de service. Vous devez donc les ajouter vous-même. Le guide complet d’Ollama sur un VPS décrit cette configuration du service étape par étape.

Modes d’échec et messages affichés

Ollama refuse de charger le modèle. ollama run renvoie une ligne de cette forme :

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama vérifie la taille avant le chargement. Il échoue donc immédiatement et indique la cause. Descendez d’un niveau de quantification, réduisez la longueur du contexte ou choisissez un modèle plus petit.

llama.cpp n’échoue pas, il devient extrêmement lent. llama.cpp utilise par défaut le memory mapping du fichier GGUF. Un fichier plus grand que la RAM peut donc quand même démarrer. Le kernel charge ensuite les poids depuis le disque et les y décharge à chaque token. La génération peut alors prendre plusieurs secondes par token, avec un disque utilisé à 100 %. Passez --no-mmap pour forcer une allocation réelle. Le programme échoue ainsi immédiatement au lieu de devenir progressivement plus lent. Lorsque le kernel intervient, dmesg affiche la cause :

Out of memory: Killed process 1234 (llama-server)

Le fichier du modèle ne se charge pas du tout. Un fichier GGUF conçu pour une famille de modèles plus récente que votre moteur renvoie une erreur indiquant l’architecture qu’il ne connaît pas :

error loading model architecture: unknown model architecture: 'qwen3next'

La solution consiste à mettre à niveau le moteur, pas à choisir un autre fichier. C’est le coût du pinning, et c’est pourquoi vous devez noter le numéro de build. Vous devez savoir depuis quelle version vous effectuez la mise à niveau.

L’API répond localement, mais pas depuis votre application. Ollama écoute sur 127.0.0.1:11434. Un autre hôte reçoit donc un refus de connexion. Définissez OLLAMA_HOST=0.0.0.0:11434 via systemctl edit ollama uniquement lorsque le port est derrière un firewall ou sur un réseau privé, car l’API n’a aucune authentification en amont.

La première réponse après une pause est très lente. Le déchargement après 5 minutes d’inactivité a eu lieu et le modèle est de nouveau lu depuis le disque. ollama ps exécuté juste avant la requête n’affiche aucun modèle chargé, ce qui le confirme. Augmentez OLLAMA_KEEP_ALIVE.

Alors, lequel faut-il utiliser ?

Utilisez Ollama lorsque vous voulez que les modèles soient gérés automatiquement et disposer immédiatement d’un endpoint compatible avec OpenAI. C’est le choix par défaut pour un premier déploiement, ainsi que lorsque le modèle utilisé est amené à changer régulièrement.

Utilisez directement llama.cpp lorsque la mémoire est suffisamment limitée pour vous obliger à choisir vous-même la ligne de quantification, lorsque vous voulez /health, /slots et /metrics pour la supervision, ou lorsque vous avez besoin d’un paramètre qu’Ollama n’expose pas. C’est le choix le plus adapté sur un VPS où le modèle tient tout juste, car les paramètres qui lui permettent de tenir sont précisément ceux qu’Ollama choisit à votre place.

Utiliser les deux est courant. Ollama pour les expérimentations, llama.cpp pour le modèle que vous déployez en production et dont vous ne voulez plus voir changer la version.

FAQ

Ollama est-il simplement une surcouche de llama.cpp ?

C’est presque le cas, mais la surcouche effectue un véritable travail. Le README d’Ollama indique que llama.cpp est son backend d’inférence (vérifié le 2 août 2026). Ollama ajoute par-dessus un registre de modèles, le template de prompt qui transforme les messages du chat en prompt, un ensemble de paramètres d’échantillonnage par défaut, un daemon qui décharge les modèles inactifs et une API HTTP. Lorsque vous comparez le nombre de tokens par seconde avec des paramètres identiques, vous comparez le même moteur à lui-même. Le véritable choix porte sur la couche de gestion.

Lequel est le plus rapide sur un VPS utilisant uniquement le CPU ?

Les deux utilisent le même moteur. Avec le même fichier de modèle, la même quantification, la même taille de contexte et le même nombre de threads, leurs performances sont proches. Les différences rapportées proviennent généralement de paramètres par défaut différents, le plus souvent de la longueur du contexte et du nombre de threads, plutôt que du moteur. Mesurez-les avec llama-bench -m <file> -p 512 -n 128 et comparez la colonne tg sur votre propre serveur avant de vous fier à une valeur publiée.

Puis-je utiliser mon propre fichier GGUF avec Ollama ?

Oui. Placez le fichier sur le serveur, écrivez un Modelfile dont la première ligne est FROM ./your-model.gguf, ajoutez les lignes PARAMETER nécessaires, par exemple num_ctx, puis exécutez ollama create your-name -f ./Modelfile. ollama ls l’affichera à côté des modèles récupérés depuis le registre. Cette méthode permet d’utiliser une quantification qui n’est pas proposée dans le registre.

De combien de RAM ai-je besoin pour un modèle 8B ?

Prévoyez la taille du fichier, le cache KV et le runtime. Une version Q4_K_M de Llama 3.1 8B occupe environ 4.58 GiB sur disque. Un contexte de 4096 tokens ajoute environ 512 MiB de cache. Ainsi, 8 GiB de RAM offrent une marge confortable, tandis que 4 GiB ne suffisent pas. Le cache augmente avec la taille du contexte : avec le même modèle et un contexte de 32,768 tokens, il faut environ 4 GiB de cache à lui seul. Avec Ollama, gardez également à l’esprit que cette exigence augmente avec OLLAMA_NUM_PARALLEL.