Ollama ou llama.cpp sur un VPS CPU ?

Ollama ou llama.cpp : sur quelle couche souhaitez-vous agir ?

Ollama et llama.cpp ne sont pas concurrents au sens où le suggère la question. 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 indique toujours llama.cpp comme backend d’inférence (vérifié le 2 août 2026). La vraie question est donc de savoir quelle couche vous souhaitez exploiter 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 limitée 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 qu’est réellement chaque projet

llama.cpp est une implémentation C et C++ de l’inférence des transformers, basée sur la bibliothèque ggml. Il lit les fichiers GGUF. GGUF (GGML universal file format) est un conteneur dans un fichier unique qui contient les poids, le tokenizer et les métadonnées nécessaires à l’exécution du modèle par le moteur. 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 releases sont identifiées par un numéro de build plutôt que 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, lancé avec ollama serve, charge les modèles et répond aux requêtes HTTP. Un client en ligne de commande communique avec ce daemon. Les deux s’appuient sur un registry situé sur ollama.com, qui contient des modèles prépackagés. Ollama utilise des versions sémantiques, et la version v0.32.5 est sortie le 27 juillet 2026. ollama pull récupère un fichier GGUF avec un template de prompt et un ensemble de paramètres par défaut, puis le stocke sous /usr/share/ollama/.ollama/models sur Linux.

C’est toute la différence entre ces deux modes de packaging. Ollama choisit pour vous la quantisation, le template et la longueur du contexte, et vous donne un seul nom à retenir. llama.cpp ne choisit rien et vous fournit des flags.

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

La quantisation réduit le poids de chaque paramètre 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 courant. La nomenclature GGUF devient lisible une fois le principe compris : Q4_K_M signifie une quantification K sur 4 bits, de taille moyenne. Une valeur plus élevée conserve davantage de précision et 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
  }
]

Ce sont les 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 GiB. Il existe 6 builds d’un même modèle, et le plus petit fait 2.96 GiB contre 7.95 GiB pour le plus grand. Le choix courant par défaut, Q4_K_M, fait 4.58 GiB. Sur un VPS de 4 GiB, ce seul choix détermine si le modèle peut se charger.

Avec llama.cpp, vous indiquez le nom du fichier. Vous choisissez donc vous-même la ligne correspondante.

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 est la taille du contexte en tokens, -t est le nombre de threads et -ngl définit le nombre de layers 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 quantisation est incluse dans le tag que vous récupérez, et ollama ls affiche ce qui se trouve réellement sur le disque. Si le registry ne propose 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 envoyez un document de 20,000 tokens, les tokens supplémentaires sont supprimés avant même que le modèle les voie. La réponse peut alors être assurée, mais erronée, au sujet d’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. llama.cpp n’a pas non plus de valeur par défaut fiable. Définissez explicitement -c 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 le coût total. Le cache KV (cache clé/valeur) contient une entrée par couche et par token de contexte. Il augmente donc avec la longueur de la conversation.

Faites le calcul pour Llama 3.1 8B. Le modèle comporte 32 couches, 8 têtes clé/valeur et une dimension de tête de 128. Chaque token stocke une clé et une valeur 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.

Ainsi, un modèle 8B Q4_K_M avec un contexte de 4k nécessite 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 une marge suffisante pour fonctionner. Si vous augmentez le contexte à 32k sur cette même machine équipée de 8 GiB, le cache consomme à lui seul toute la marge disponible. Surveillez la consommation réelle avec free -h pendant le chargement du modèle. Ne faites pas confiance à une estimation que vous n’avez pas mesurée.

Ollama amplifie ce phénomène. OLLAMA_NUM_PARALLEL vaut 1 par défaut, et la mémoire nécessaire à un modèle varie proportionnellement au produit de cette valeur par la longueur du contexte. Si vous augmentez les deux en même temps, le daemon demande discrètement plusieurs fois plus de RAM que prévu.

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 ainsi de la gestion du cycle de vie sans devoir l’implémenter 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 plus important sur un VPS équipé uniquement d’un 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. Ainsi, le rechargement d’un fichier de 4.58 Gio transforme une réponse de deux secondes en réponse de trente secondes sur un stockage lent. Une valeur keep-alive élevée réduit cette latence, mais mobilise durablement la RAM. Ces deux options ont un coût réel. Choisissez celle qui vous pénalise le moins.

llama.cpp ne fournit aucun daemon. Vous devez donc écrire vous-même l’unité sous la forme suivante, 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 fonctionnement. Rien n’est déchargé en cas d’inactivité. Vous évitez ainsi les rechargements inattendus, mais vous ne pouvez pas récupérer la mémoire sans arrêter le service. Si l’écriture d’unités est nouvelle pour vous, le principe est le même que pour exécuter vos propres services avec systemd sur un VPS.

Axe 3 : l’API que votre application utilisera

Cet axe s’est beaucoup resserré. Les deux projets utilisent désormais le format de chat OpenAI. La plupart des bibliothèques clientes fonctionnent donc 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 OpenAI est http://localhost:11434/v1/chat/completions. Il conserve également une API native sur /api/chat. Une route compatible Anthropic est aussi 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 également des routes opérationnelles qu’Ollama ne propose pas : /health pour une readiness probe, /props pour les paramètres du modèle chargé, /slots pour connaître l’opération en cours dans chaque emplacement 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 automatiquement. Par défaut, ils écoutent tous les deux sur loopback, pour de bonnes raisons. Accédez-y via un tunnel SSH ou derrière un reverse proxy. N’ouvrez jamais 11434 ou 8080 sur Internet.

Ce qu’un VPS sans GPU peut réellement faire

Un VPS sans GPU 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. Sur une offre avec vCPU partagé, un modèle 8B en Q4_K_M atteint généralement quelques unités par seconde pour tg. Le traitement du prompt est le principal facteur pénalisant : le prompt entier est traité avant l’apparition du premier token de sortie. Un long prompt système ajoute donc un délai à chaque requête.

Sur CPU, vous pouvez utiliser 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. En revanche, le CPU ne convient pas au chat interactif à vitesse de lecture, aux assistants de programmation, au traitement de documents longs ni aux tâches avec une boucle d’agent qui enchaîne de nombreux appels. Une boucle qui effectue douze appels à quatre secondes chacun attend une minute avant de produire quoi que ce soit.

Lorsque les chiffres ne conviennent pas, deux solutions sont possibles. Si le problème vient de la concurrence, c’est-à-dire de nombreux utilisateurs qui sollicitent le même modèle simultanément, le choix du moteur devient déterminant. La comparaison entre Ollama et vLLM pour le serving concurrent traite ce sujet. Si le problème est la vitesse brute, la solution est un VPS avec un GPU attaché, où -ngl devient réellement pertinent. Avant cela, établissez une base de 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 reproductible d’un VPS mérite d’y consacrer une heure.

Installer llama.cpp en épinglant une build

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

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

Pour épingler une build précise, téléchargez plutôt l’archive tar précompilée depuis la page des releases. La build 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 RAM que les offres les plus petites. Compilez donc sur une machine plus grande, puis copiez les binaires si la petite machine manque de ressources.

Installer Ollama avec une version figée

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 release connue comme fiable au lieu d’installer celle publiée ce matin. 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 envoyer un script directement à un shell :

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. Passez à une ligne de quantification inférieure, réduisez la longueur du contexte ou choisissez un modèle plus petit.

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

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

Le fichier du modèle ne se charge pas du tout. Un fichier GGUF construit 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 à utiliser un autre fichier. C’est le prix du pinning. C’est aussi 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 est bindé 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 se trouve derrière un firewall ou sur un réseau privé, car l’API ne possède 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 devez-vous utiliser ?

Utilisez Ollama si vous voulez que les modèles soient gérés automatiquement et disposer immédiatement d’un endpoint compatible avec l’API OpenAI. C’est le choix par défaut pour un premier déploiement et pour tout environnement où le choix du modèle changera régulièrement.

Utilisez directement llama.cpp lorsque la mémoire est suffisamment limitée pour que vous deviez 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 flag 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 sélectionne à votre place.

Les utiliser tous les deux est normal. Ollama pour les expérimentations, llama.cpp pour le modèle déployé en production que vous ne voulez plus voir changer.

FAQ

Ollama est-il seulement un wrapper autour de llama.cpp ?

C’est presque le cas, mais le wrapper effectue un vrai travail. Le README d’Ollama indique que llama.cpp est son backend d’inférence (vérifié le 2 août 2026). Ollama ajoute au-dessus un registre de modèles, le template de prompt qui transforme les messages de la conversation 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. En pratique, vous choisissez surtout entre les couches de gestion.

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

Ils 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, et non 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, comme num_ctx, puis exécutez ollama create your-name -f ./Modelfile. ollama ls listera ce modèle avec ceux que vous avez récupérés depuis le registre. C’est ainsi que vous utilisez une quantification que le registre ne propose pas.

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

Prévoyez la taille du fichier, ainsi que le cache KV et le runtime. Une version Q4_K_M de Llama 3.1 8B occupe environ 4.58 GiB sur le disque, et un contexte de 4096 tokens ajoute environ 512 MiB de cache. 8 GiB de RAM offrent donc 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 à lui seul environ 4 GiB de cache. Avec Ollama, n’oubliez pas que le besoin augmente également avec OLLAMA_NUM_PARALLEL.