Ollama ou llama.cpp sur un VPS CPU ?

Ollama ou llama.cpp : sur quelle couche voulez-vous exécuter le service ?

Ollama et llama.cpp ne sont pas concurrents au sens où la question le suggère. 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éférence 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 voulez 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 le serveur est de petite taille et que vous devez choisir précisément le fichier de modèle, la taille du contexte et le nombre de threads. 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 de l’inférence de transformers en C et C++, basée sur la bibliothèque ggml. Il lit les fichiers GGUF. GGUF (GGML universal file format) est un conteneur mono-fichier 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 plutôt que par une version sémantique. Le tag actuel est b10224, publié le 2 août 2026, et un nouveau tag paraît 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. Les deux s’appuient sur un registry disponible sur ollama.com, qui contient des modèles prépackagés. Ollama utilise les 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 tout l’écart entre ces deux modes de packaging. Ollama choisit pour vous la quantification, le template et la longueur de contexte, et vous fournit un seul nom à retenir. llama.cpp ne choisit rien et vous fournit des flags.

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 standard. Le nommage GGUF devient lisible une fois que vous connaissez le modèle : Q4_K_M signifie une quantification K sur 4 bits, de taille moyenne. Un nombre plus élevé 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
  }
]

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 GiB. 6 builds d’un même modèle sont disponibles ; 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 choix détermine à lui seul si le modèle peut être chargé.

Avec llama.cpp, vous indiquez le nom du fichier. Vous 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 uniquement équipée 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 indique ce qui est réellement présent sur le disque. Si le registry ne contient pas le build voulu, 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 ne les voie. La réponse peut donc être très assurée tout en étant erronée à propos 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 key/value) stocke une entrée par couche et par token de contexte. Il augmente avec la longueur de la conversation.

Faites 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, à raison de 2 octets chacune en f16. Le calcul est donc de 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 pour le cache et la mémoire d’exécution. 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 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 vous fiez pas à 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 utilisant uniquement le CPU montre ce que chaque palier de 8 à 64 GB peut réellement contenir.

Ollama amplifie ce phénomène. OLLAMA_NUM_PARALLEL vaut 1 par défaut, et la mémoire nécessaire au modèle évolue selon le 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 la quantité de RAM prévue. Ce même calcul détermine aussi la limite du nombre 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 à administrer

Le script d’installation d’Ollama écrit une unité systemd, crée un utilisateur système ollama et active le service. Vous disposez ainsi de la gestion du cycle de vie sans avoir à l’implémenter. 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 avec CPU qu’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 l’intégralité du 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 valeur keep-alive élevée réduit cette latence, mais consomme durablement de la RAM. Les 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é, comme /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 évitez ainsi les rechargements imprévus, 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, il s’agit du même modèle que l’exécution de vos propres services avec systemd sur un VPS.

Axe 3 : l’API avec laquelle votre application communiquera

Cet axe s’est beaucoup resserré. Les deux projets utilisent désormais le format de chat OpenAI, et 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 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 également des routes opérationnelles qu’Ollama ne fournit 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 superviser ce service, cette différence sera probablement déterminante.

Aucun des deux serveurs n’active l’authentification automatiquement. Par défaut, ils écoutent sur l’interface 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 à Internet.

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

Un VPS sans GPU exécute les petits modèles lentement. 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 ce serveur :

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 la vitesse de génération des tokens, toutes deux en tokens par seconde. Avec une offre à 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 la partie la plus pénalisante : l’intégralité du prompt est traitée avant l’apparition du premier token de sortie. Un long system prompt ajoute donc un délai à chaque requête.

Sur CPU, les usages réalistes sont les modèles 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 à raison de quatre secondes par appel prend une minute avant de produire quoi que ce soit. Si vous prévoyez tout de même d’utiliser un assistant de programmation, orienter un agent vers un modèle que vous hébergez vous-même explique quels travaux un petit modèle local peut réellement prendre en charge et lesquels doivent rester sur une API hébergée.

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 simultanément un même modèle, le choix du moteur change, et la comparaison entre Ollama et vLLM pour un service concurrent couvre ce cas. Si le problème vient de la vitesse brute, la réponse est un VPS équipé d’un GPU, où -ngl commence à devenir pertinent. 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 reproductible de VPS mérite d’y consacrer une heure.

Installer llama.cpp avec une build figée

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 figer une build précise, utilisez plutôt l’archive tarball précompilée disponible sur la page des releases. La build b10224 est le tag actuel au 2 August 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 plans les plus petits. Compilez donc sur une machine plus grande, puis copiez les binaires si la petite machine manque de ressources.

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 release connue comme fonctionnelle au lieu d’installer celle 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 envoyer un script vers 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 en évacue à chaque token. La génération passe à plusieurs secondes par token et le disque reste à 100 %. Passez --no-mmap pour forcer une allocation réelle. Le programme échouera immédiatement au lieu de se dégrader progressivement. 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 conçu pour une famille de modèles plus récente que votre moteur renvoie une erreur qui indique l’architecture inconnue :

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 écoute sur 127.0.0.1:11434. Un autre hôte obtient 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 pare-feu 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 devez-vous utiliser ?

Utilisez Ollama lorsque vous voulez que les modèles soient gérés automatiquement et disposer d’un endpoint compatible avec OpenAI sans configuration particulière. C’est le choix par défaut pour un premier déploiement et pour les environnements où le modèle utilisé changera 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 flag qu’Ollama n’expose pas. C’est le choix adapté sur un VPS où le modèle tient tout juste en mémoire, car les paramètres qui permettent de le faire tenir sont précisément ceux qu’Ollama choisit à votre place.

Exécuter les deux est normal. Utilisez Ollama pour les expérimentations et llama.cpp pour le modèle déployé en production, dont vous ne voulez jamais voir changer la version.

FAQ

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

Presque, mais le wrapper effectue un vrai travail. Le README d’Ollama indique llama.cpp comme backend d’inférence (vérifié le 2 août 2026). Ollama ajoute par-dessus un registre de modèles, le prompt template qui transforme les messages du chat en prompt, un ensemble de paramètres d’échantillonnage par défaut, un daemon avec déchargement après une période d’inactivité 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 ?

Ils utilisent le même moteur. Avec le même fichier de modèle, la même quantisation, la même taille de contexte et le même nombre de threads, leurs performances sont proches. Les écarts rapportés 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 fichier 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 le répertoriera à côté des modèles récupérés depuis le registre. Cette méthode permet d’utiliser une quantisation 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 le disque. 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 environ 4 GiB de cache à lui seul. Avec Ollama, n’oubliez pas que ce besoin augmente également avec OLLAMA_NUM_PARALLEL.